From: <jos...@ju...> - 2007-11-20 21:13:59
|
Gustavo wrote: > I'm using a shelf at the right border with size set to HUGE > (120px) and below all windows so it can be nice and use > transparency, staying at the bottom of my desktop and working > like KDE's superkaramba, GNOME desklets, Windows Vista gadgets > and ... > = > It works great, I'm using calendar, clock, forecast, cpu > frequency and battery. Most looks good, but some could use > better the big space, like calendar could scale the font, > battery could be centered (with power indicator relative to it). > = > I tried to fix calendar and could make some improvements, but > it's hard to make things good at 40 and 120 pixels... also, > 120 pixels is not that big, it could be 256 easily... > = > So, my idea is either to provide larger shelf size or provide > another shelf category, maybe desktop applets, that could be > placed everywhere (if it makers hard to efm icons, then maybe > disable those or make this new shelf attached to borders, with > icons evicting it). Larger shelf is easy to add, just change > the max constant, but I really thing the other option is more > interesting, we could have more specialized applets, like, > the calendar view could toggle between large Month-Day/Week-Day > and full edje-beauty calendar, other modules could provide more > information, like forecast could provide more info on click, > using Edje, instead of opening another popup... but how feasible > is this? Whats the directions to implement this? Ahhh... the desklets/applets thing. :) There was a thread about this sometime back. I have some questions about this myself.. Like, what exactly is an "icon"? (vs. say a "gadget") How does a fm (or a wm) know how to 'draw' such a thing? Where does it get info about the thing so that it knows what to do about it? If the desktop (and/or fm) component can do whatever it now does with "icons", and whatever else it does with "gadgets", then why can't it do anything with "whizblings"? Or with "wambots", or with ..... ? jose. _____________________________________________________________ It pays to Discover. = Apply now! 0% into APR on balance transfers. http://thirdpartyoffers.juno.com/TGL2121/fc/JKFkuJi7EM0epMP0mou33qRPD9g8= ZCKxKmBsOfUsEE0ICmUwcRCdTq/ |
From: <jos...@ju...> - 2007-11-21 08:50:24
|
> > If the desktop (and/or fm) component can do whatever it now > > does with "icons", and whatever else it does with "gadgets", then > > why can't it do anything with "whizblings"? Or with "wambots", or > > with ..... ? > = > = > you can. its a few trivial lines of module code to go put any evas > object on the desktop. anywhere. a few more to allow you to just > move it around anywhere - and a few more to resize. if you REALLY > want that. a shelf is NOT THE SOLUTION TO THIS. tyring to use the > shelf shows a fundamental mis-understanding of e's internal code > and how it all works, and just how trivial it is to do it yourself > with custom objects. You mean to tell me that someone(s) could write say a lib that has some sort of api for creating "worblets", which beasts are displayed as evas objects of a given evas canvas, and this could be used, via a suitable e17-module, to display such things on the e17 desktop? Maybe even on particular virtual desktops? How about on an instance of a fm view? Could they maybe use ewl or etk or python-efl or ruby-efl or ... to write such a worblets lib? Nah, I don't believe it. Show me the "big-clock" example. :) _____________________________________________________________ 0% intro APR on Balance Transfers Fraud protection and cashback bonus. Apply now! http://thirdpartyoffers.juno.com/TGL2121/fc/JKFkuJi7DeW1Oc5ATbJdnIUIPaZc= u8JJ4rvdzT3WjCtIFJxcX9cdbq/ |
From: Gustavo S. B. <bar...@gm...> - 2007-11-21 14:11:56
|
On Nov 21, 2007 5:48 AM, jos...@ju... <jos...@ju...> wrote: > > > > If the desktop (and/or fm) component can do whatever it now > > > does with "icons", and whatever else it does with "gadgets", then > > > why can't it do anything with "whizblings"? Or with "wambots", or > > > with ..... ? > > > > > > you can. its a few trivial lines of module code to go put any evas > > object on the desktop. anywhere. a few more to allow you to just > > move it around anywhere - and a few more to resize. if you REALLY > > want that. a shelf is NOT THE SOLUTION TO THIS. tyring to use the > > shelf shows a fundamental mis-understanding of e's internal code > > and how it all works, and just how trivial it is to do it yourself > > with custom objects. > > You mean to tell me that someone(s) could write say a lib > that has some sort of api for creating "worblets", which beasts are > displayed as evas objects of a given evas canvas, and this could be > used, via a suitable e17-module, to display such things on the e17 > desktop? Maybe even on particular virtual desktops? How about on an > instance of a fm view? > Could they maybe use ewl or etk or python-efl or ruby-efl > or ... to write such a worblets lib? I think so.... I didn't try, but seems that using "flames" as a baseline could work, ASAP I'll give it a try, but I don't promise it before 17-December. -- Gustavo Sverzut Barbieri -------------------------------------- Jabber: bar...@gm... MSN: bar...@gm... ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 |
From: Ed P. <epr...@co...> - 2007-11-21 17:17:00
|
Gustavo Sverzut Barbieri wrote: > On Nov 21, 2007 5:48 AM, jos...@ju... <jos...@ju...> wrote: >>>> If the desktop (and/or fm) component can do whatever it now >>>> does with "icons", and whatever else it does with "gadgets", then >>>> why can't it do anything with "whizblings"? Or with "wambots", or >>>> with ..... ? >>> >>> you can. its a few trivial lines of module code to go put any evas >>> object on the desktop. anywhere. a few more to allow you to just >>> move it around anywhere - and a few more to resize. if you REALLY >>> want that. a shelf is NOT THE SOLUTION TO THIS. tyring to use the >>> shelf shows a fundamental mis-understanding of e's internal code >>> and how it all works, and just how trivial it is to do it yourself >>> with custom objects. >> You mean to tell me that someone(s) could write say a lib >> that has some sort of api for creating "worblets", which beasts are >> displayed as evas objects of a given evas canvas, and this could be >> used, via a suitable e17-module, to display such things on the e17 >> desktop? Maybe even on particular virtual desktops? How about on an >> instance of a fm view? >> Could they maybe use ewl or etk or python-efl or ruby-efl >> or ... to write such a worblets lib? > > I think so.... I didn't try, but seems that using "flames" as a > baseline could work, ASAP I'll give it a try, but I don't promise it > before 17-December. > I actually wrote a desktop widgets library that uses EFL. It was called Eluminate and provided a modular scripting API via Python or Perl. I never finished the Ruby module, but it can easily be done. There were some security concerns and such, but I was able to pull off an XMMS2 controller as well as basic CPU/Memory monitors. I also had built in support for multi-instancing and a few other nice things. The project was called Eluminate and I was just about to dump it for good. I have lost interest in it and just don't have time to run it any more. It's BSD licensed and anyone who wants it is welcomed to take it over. If anybody cares to take a look, it's at http://www.eluminate.org Thanks, Ed (ekrunch on freenode) -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan |
From: <jos...@ju...> - 2008-01-28 08:58:31
|
Sometime back, Gustavo wrote: > So, my idea is either to provide larger shelf size or provide > another shelf category, maybe desktop applets, that could be > placed everywhere (if it makers hard to efm icons, then maybe > disable those or make this new shelf attached to borders, with > icons evicting it). Larger shelf is easy to add, just change the > max constant, but I really thing the other option is more > interesting, we could have more specialized applets, like, > the calendar view could toggle between large Month-Day/Week-Day > and full edje-beauty calendar, other modules could Then, Carsten wrote: > you can. its a few trivial lines of module code to go put any evas > object on the desktop. anywhere. a few more to allow you to just > move it around anywhere - and a few more to resize. if you REALLY > want that. a shelf is NOT THE SOLUTION TO THIS. tyring to use the > shelf shows a fundamental mis-understanding of e's internal code > and how it all works, and just how trivial it is to do it yourself > with custom objects. Has anyone followed up on this? It seems to me that this could be easily done in a way that would allow for a certain amount of re-usability of such 'gadgets', and yet enough flexibility to have custom designs as well. Likely there are multitudes of ways to go about doing something like this, but maybe a simple approach could be a good one to start with? _____________________________________________________________ Beauty Product Reviews Read unbiased beauty product reviews and join our product review team! http://thirdpartyoffers.juno.com/TGL2121/fc/JKFkuJi7GiXZ1FN7tCJs851A2aHo= l8FFGF7FH9KBYQcyzwXtUBv79u/ |
From: Gustavo S. B. <bar...@gm...> - 2008-01-28 13:26:13
|
On Jan 28, 2008 5:58 AM, jos...@ju... <jos...@ju...> wrote: > > Sometime back, Gustavo wrote: > > > So, my idea is either to provide larger shelf size or provide > > another shelf category, maybe desktop applets, that could be > > placed everywhere (if it makers hard to efm icons, then maybe > > disable those or make this new shelf attached to borders, with > > icons evicting it). Larger shelf is easy to add, just change the > > max constant, but I really thing the other option is more > > interesting, we could have more specialized applets, like, > > the calendar view could toggle between large Month-Day/Week-Day > > and full edje-beauty calendar, other modules could > > Then, Carsten wrote: > > > you can. its a few trivial lines of module code to go put any evas > > object on the desktop. anywhere. a few more to allow you to just > > move it around anywhere - and a few more to resize. if you REALLY > > want that. a shelf is NOT THE SOLUTION TO THIS. tyring to use the > > shelf shows a fundamental mis-understanding of e's internal code > > and how it all works, and just how trivial it is to do it yourself > > with custom objects. > > Has anyone followed up on this? It seems to me that this > could be easily done in a way that would allow for a certain amount > of re-usability of such 'gadgets', and yet enough flexibility to have > custom designs as well. Likely there are multitudes of ways to go > about doing something like this, but maybe a simple approach could be > a good one to start with? Raster sent this code as example, it's pretty simple, but no time to work on it still: http://www.rasterman.com/files/logo-0.0.1.tar.gz -- Gustavo Sverzut Barbieri -------------------------------------- Jabber: bar...@gm... MSN: bar...@gm... ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 |
From: <jos...@ju...> - 2008-01-29 05:50:42
|
Gustavo wrote: > > Has anyone followed up on this? It seems to me that this > > could be easily done in a way that would allow for a certain amount > > of re-usability of such 'gadgets', and yet enough flexibility to > > have custom designs as well. Likely there are multitudes of ways to > > go about doing something like this, but maybe a simple approach > > could be a good one to start with? > = > Raster sent this code as example, it's pretty simple, but no time to > work on it still: > = > http://www.rasterman.com/files/logo-0.0.1.tar.gz A very nice example :) Note that one could do much the same with many of the current gadcon based e17-modules - ie. display them directly on a zone's bg evas and have move/resize handlers if desired. And of course one could write whole new ones... But there are a couple of limitations with this: 1. All these nice gadgets are strictly "e17 only". Not much here that other apps/libs could use (except copy paste some code). 2. Even within e17 only, there are some undesirable aspects. eg. if you wanted to have a gadget that consists of a clock, plus a cpu-monitor, plus a mem-monitor, and you want these to be arranged in some interesting way relative to each other, and maybe have a nice background that contains them which does a nebula-effect (whatever that is) on mouse-over, then it's not clear wether you'd have to write all of these components from scratch... One would like to be able to address these things in as simple a way as possible - ie. make it easier to re-use exhisting 'gadgets', to create new ones from sets of given ones, etc. Note that one thing that all these kinds of 'gadgets' have in common is that they define evas objects on a given evas, preferably a 'themable' object - and commonly they simply define an edje object. They could also have certain 'properties' that might be varied, and this is usually done via some configuration gui. Does this seem like something one could use as a starting point for finding a means to address the above mentioned limitations? For example, let's say we take only the "core" aspects of these gadget modules so that one has only some loadable libs that expose certain functions - say a function that 'adds' an evas object to a given evas, and another to 'set' a theme/resource file on such a thusly created evas object, and maybe a function to set/get named property/values, .... and possibly other functions particular to a given gadget. Of course one might want a way to 'manage' such object-modules and thus maybe a lib to load them, init them, keep references, etc... Could these generic 'object-modules' (plus a 'managing' lib) be used for building 'gadgets' as desired?? _____________________________________________________________ Beauty Product Reviews Read unbiased beauty product reviews and join our product review team! http://thirdpartyoffers.juno.com/TGL2121/fc/JKFkuJi7GiXG07S2bI33ExQknali= rOMoYMTWHjW874ZiTMwMFZ1MiE/ |
From: Gustavo S. B. <bar...@gm...> - 2008-01-29 14:14:59
|
On Jan 29, 2008 2:49 AM, jos...@ju... <jos...@ju...> wrote: > > Gustavo wrote: > > > > Has anyone followed up on this? It seems to me that this > > > could be easily done in a way that would allow for a certain amount > > > of re-usability of such 'gadgets', and yet enough flexibility to > > > have custom designs as well. Likely there are multitudes of ways to > > > go about doing something like this, but maybe a simple approach > > > could be a good one to start with? > > > > Raster sent this code as example, it's pretty simple, but no time to > > work on it still: > > > > http://www.rasterman.com/files/logo-0.0.1.tar.gz > > > A very nice example :) Note that one could do much the same > with many of the current gadcon based e17-modules - ie. display them > directly on a zone's bg evas and have move/resize handlers if desired. > And of course one could write whole new ones... > > But there are a couple of limitations with this: > > 1. All these nice gadgets are strictly "e17 only". Not much > here that other apps/libs could use (except copy paste some code). > > 2. Even within e17 only, there are some undesirable aspects. > eg. if you wanted to have a gadget that consists of a clock, plus a > cpu-monitor, plus a mem-monitor, and you want these to be arranged > in some interesting way relative to each other, and maybe have a nice > background that contains them which does a nebula-effect (whatever > that is) on mouse-over, then it's not clear wether you'd have to > write all of these components from scratch... > > One would like to be able to address these things in as simple > a way as possible - ie. make it easier to re-use exhisting 'gadgets', > to create new ones from sets of given ones, etc. > > Note that one thing that all these kinds of 'gadgets' have in > common is that they define evas objects on a given evas, preferably a > 'themable' object - and commonly they simply define an edje object. > They could also have certain 'properties' that might be varied, and > this is usually done via some configuration gui. > > Does this seem like something one could use as a starting point > for finding a means to address the above mentioned limitations? > > For example, let's say we take only the "core" aspects of > these gadget modules so that one has only some loadable libs that > expose certain functions - say a function that 'adds' an evas object > to a given evas, and another to 'set' a theme/resource file on such > a thusly created evas object, and maybe a function to set/get named > property/values, .... and possibly other functions particular to a > given gadget. > Of course one might want a way to 'manage' such object-modules > and thus maybe a lib to load them, init them, keep references, etc... > > Could these generic 'object-modules' (plus a 'managing' lib) > be used for building 'gadgets' as desired?? Hi, I have no time to reply your mail as detailed as I would like, but one idea to do what you want is to make the gadcon usage recursive. Then we could have an object that exports its own gadcon api to children. Maybe it's an overkill and can be done by means similar to evas smart objects. -- Gustavo Sverzut Barbieri -------------------------------------- Jabber: bar...@gm... MSN: bar...@gm... ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 |
From: <jos...@ju...> - 2008-01-29 18:26:17
|
Gustavo wrote: > I have no time to reply your mail as detailed as I would like, > but one idea to do what you want is to make the gadcon usage > recursive. Then we could have an object that exports its own gadcon > api to children. Maybe it's an overkill and can be done by means > similar to evas smart objects. Well, gadcons are mostly evas smart objects that implement a certain simple layout policy on its member objects, so likely having gadcons that contain other gadcons as members wouldn't be too hard to achieve.. and of course one could also have all sorts of other layout/container objects as well. All this could be very useful to have for actual, real uses. What I was pointing to though was something a bit more abstract in nature. Basically, it's really just the notion of loadable, themable "evas-objects" (akin to what edje is in particular), eg. things like a 'clock-object', or a 'cpu-monitor-object', or a 'jumping-logo-object' etc... as well as various kinds of container/layout objects (possibly with some notion of a fg or bg), .... all are just examples - with some of them possibly exporting more functions unique to them, but all exporting (at least) the ability to add an object instance to a given evas, and of setting a theme/resource file on such instances. By abstracting this out into a lib that 'manages' these loadable, themable 'evas-object' modules, you can use them wherever you have an evas available, create new ones (using existing ones or not), put them where others can also use them, etc..... There's no need for many of these kinds of things to be e17- modules or e17 specific in any way, they really don't need to be restricted that way (any more than say let's just put edje inside e17), though some could also be 'e17-objects' or 'appX-objects' rather than generic 'evas-objects'. Again, I'm just proposing a simple mechanism to enable the notion of loadable, themable 'evas-objects', so that these interesting, compound, gadget-like things can be made available for use/re-use on a wider basis. There are a LOT of interesting 'objects' one can make using evas/ecore/edje/other-stuff... things from a simple boing-boing-logo to system-monitors to clocks to matrix-bgs to some-layout-object to some-gui-control to color-picker to virtual-keyboard to calculator to simple-video-playing-object to.... whatever. It's a shame not to be able to load/use/build these kinds of things, where appropiate, or explore what this kind of capability could evolve into with further refinements. _____________________________________________________________ Boost your business with a small business loan. Click now! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3no7b2odKd6a6lfu3Q6Kj4= XbEduIi8vxVpkcLCWGKildKgLu/ |
From: Gustavo S. B. <bar...@gm...> - 2008-01-29 19:26:01
|
On Jan 29, 2008 3:25 PM, jos...@ju... <jos...@ju...> wrote: > > Gustavo wrote: > > > I have no time to reply your mail as detailed as I would like, > > but one idea to do what you want is to make the gadcon usage > > recursive. Then we could have an object that exports its own gadcon > > api to children. Maybe it's an overkill and can be done by means > > similar to evas smart objects. > > Well, gadcons are mostly evas smart objects that implement > a certain simple layout policy on its member objects, so likely having > gadcons that contain other gadcons as members wouldn't be too hard > to achieve.. and of course one could also have all sorts of other > layout/container objects as well. All this could be very useful to > have for actual, real uses. > > What I was pointing to though was something a bit more abstract > in nature. Basically, it's really just the notion of loadable, themable > "evas-objects" (akin to what edje is in particular), eg. things like > a 'clock-object', or a 'cpu-monitor-object', or a 'jumping-logo-object' > etc... as well as various kinds of container/layout objects (possibly > with some notion of a fg or bg), .... all are just examples - with some > of them possibly exporting more functions unique to them, but all > exporting (at least) the ability to add an object instance to a given > evas, and of setting a theme/resource file on such instances. > > By abstracting this out into a lib that 'manages' these > loadable, themable 'evas-object' modules, you can use them wherever > you have an evas available, create new ones (using existing ones or > not), put them where others can also use them, etc..... > > There's no need for many of these kinds of things to be e17- > modules or e17 specific in any way, they really don't need to be > restricted that way (any more than say let's just put edje inside > e17), though some could also be 'e17-objects' or 'appX-objects' > rather than generic 'evas-objects'. > > Again, I'm just proposing a simple mechanism to enable the > notion of loadable, themable 'evas-objects', so that these interesting, > compound, gadget-like things can be made available for use/re-use > on a wider basis. > There are a LOT of interesting 'objects' one can make using > evas/ecore/edje/other-stuff... things from a simple boing-boing-logo > to system-monitors to clocks to matrix-bgs to some-layout-object to > some-gui-control to color-picker to virtual-keyboard to calculator > to simple-video-playing-object to.... whatever. > > It's a shame not to be able to load/use/build these kinds of > things, where appropiate, or explore what this kind of capability > could evolve into with further refinements. what you want is basically what KDE plasma provides, we already did it using python-efl for Canola, it's not as generic as you want, but it's more generic than what we need, working really well. Given some time, I'd really like to provide a layout library and possible some basic widget-like components, just get e_box, e_widget_* and make a lib. Maybe it should go into esmart, dunno. It works, it's easy to do, what lack is people actually doing it. -- Gustavo Sverzut Barbieri -------------------------------------- Jabber: bar...@gm... MSN: bar...@gm... ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 |
From: <jos...@ju...> - 2008-01-30 02:28:09
|
> > Again, I'm just proposing a simple mechanism to enable > > the notion of loadable, themable 'evas-objects', so that these > > interesting, compound, gadget-like things can be made available > > for use/re-use on a wider basis. > > There are a LOT of interesting 'objects' one can make > > using evas/ecore/edje/other-stuff... things from a simple boing- > > boing-logo to system-monitors to clocks to matrix-bgs to some- > > layout-object to some-gui-control to color-picker to virtual- > > keyboard to calculator to simple-video-playing-object to.... > > whatever. > > > > It's a shame not to be able to load/use/build these > > kinds of things, where appropiate, or explore what this kind of > > capability could evolve into with further refinements. > = > what you want is basically what KDE plasma provides, we already > did it using python-efl for Canola, it's not as generic as you > want, but it's more generic than what we need, working really well. That's actually very interesting about canola - you've never really mentioned much about it. :) I guess Kde's plasma (I know as much about it as I do about the surface of the moon, ie. seen a few pictures, read a few stories), could in part be an example of something like that.. and so is their "kparts" stuff (minus the merged-gui-controls bit). In the windows world there's this "DesktopX" framework which also seems similar, and it's built on something very close to edje - though I believe it's all developed via some gui builder and a scripting language, same as with Flash I'd imagine. I suppose many that have to do with "guis" could be said to have similar aspects... really anything that claims to have some kind of 'modules' system - it's mostly a matter of the functions/properties exported by the modules and the objects they deal with. For what we're talking about here it'd be evas objects, though I suppose one could do the same with ewl/etk-widgets or with something derived from these toolkit widgets. With certain kinds of 'object systems' one often sees libs that have a 'base' object which one can 'extend'. Invariably one then sees developed larger libs which attempt to collect a set of standard/ common 'objects' which depend on each other and work together somehow. They also allow for building on this by further 'extending', and often such further derived objects are offered via other known libs. Invariably though, one also sees 'objects' that are fairly self-contained or very specialized (regardless of how they're created), and these are sometimes best used at run-time, if desired, rather than linked-to beforehand, hence some sort of mechanism for querying/using these also seems to be common. I don't think it'll ever be the case that one will supplant the other, regardless of the kind of object-system or the programming language used -- especially if the objects in question allow for 'embedding' of objects into some others. > = > Given some time, I'd really like to provide a layout library and > possible some basic widget-like components, just get e_box, > e_widget_* and make a lib. Maybe it should go into esmart, dunno. > = That could be very useful to many. [NB. raster has often mentioned wanting to extend edje/edc in various ways.. eg. more scripting language support, but also possibly having more layout mechanisms and maybe some form of widgetry..?] > It works, it's easy to do, what lack is people actually doing it. Ummm... not a lot of work to write an intial pass at a lib to manage such an 'evas-object' modules system.. and the actual modules themselves would just be developed over time as desired. I suspect there are other reasons why things like this have 'problems' getting off the ground. _____________________________________________________________ Get the perfect student credit card by clicking now! http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3mIRRUD5M9ASNCepX4RYts= tkgdgX48tsxJdJVvRv0ajqfvJG/ |
From: Carsten H. (T. R. <ra...@ra...> - 2007-11-21 00:46:48
|
On Tue, 20 Nov 2007 21:11:46 GMT "jos...@ju..." <jos...@ju...> babbled: > Ahhh... the desklets/applets thing. :) There was a thread > about this sometime back. > > I have some questions about this myself.. Like, what exactly > is an "icon"? (vs. say a "gadget") an icon is something that is part of a filemanager widget. the desktop bg is covered by a filemanager widget (by default). the filemanager module creates on per zone (a zone is a region of a container that covers a whole root window generally. with xinerama you may have 2 or more zones per container, but single-head you will have just 1 zone the size of the container). manager objects manage a root window and create a container (in theory can create multiple - but don't). > How does a fm (or a wm) know how to 'draw' such a thing? > Where does it get info about the thing so that it knows what to do > about it? asks the manage to list all managers - walks all the containers in each manager, then walks all the zones in each container and per zone creates the object in the container evas canvas. there is no limitation for only shelf gadgets to be the only items that can be put on the screen by modules. they can do anything they author wants. people though seem to be blinkered into thinking that the shelf must do everything for them and have every possible use and option ever conceived. the shelf *IS* restrictive. it's MEANT to be. MOST people were organising the old gadgets into rows/edges of the screen and it was a pain to have to do it manually. the shelf provided a container to house this and a place to create a gadcon controller. the shelf doesn't arrange gadgets. it just tells gadcon "here you are, and this is the size i want you to be - by the way, what size can you be at a minimum?". > If the desktop (and/or fm) component can do whatever it now > does with "icons", and whatever else it does with "gadgets", then > why can't it do anything with "whizblings"? Or with "wambots", or > with ..... ? you can. its a few trivial lines of module code to go put any evas object on the desktop. anywhere. a few more to allow you to just move it around anywhere - and a few more to resize. if you REALLY want that. a shelf is NOT THE SOLUTION TO THIS. tyring to use the shelf shows a fundamental mis-understanding of e's internal code and how it all works, and just how trivial it is to do it yourself with custom objects. now if you absolutely MUST recycle gadgets (i don't see this as a good idea - gadgets generally would be designed to be small and live within some containering and management system. if you want full freedom objects i would imagine they should be designed subtley differently as they may not live along the edge of a screen anymore and be small. they many not be able to sanely pop up menus or popups etc. etc., but if it MUST be a gadget you want to just put a gadgon ON THE DESKTOP, and have a different layout smart manager that doesn't lay items out in a line. it's a lot more work, mind you. everyone is always just asking to have a big clock - then someone go and make a clock module that puts itself on the desktop. hell the clock module doesn't do ANYTHING but display an evas object loaded from a edje. the edje does all the work. ALL you need is a module that can select/load 1 or more specific .edj files and place them on your desktop and let you move/resize them. as this is not on the todo list though - i leave it up to someone to go write a module to do just that. it is an utterly trivial exercise to do it and it's not worth getting into a debate over it. the debate will be more work than the module code. > jose. > > _____________________________________________________________ > It pays to Discover. > Apply now! 0% into APR on balance transfers. > http://thirdpartyoffers.juno.com/TGL2121/fc/JKFkuJi7EM0epMP0mou33qRPD9g8ZCKxKmBsOfUsEE0ICmUwcRCdTq/ > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... |
From: Sebastian D. <seb...@ta...> - 2007-11-21 09:11:35
|
Carsten Haitzler (The Rasterman) wrote: > > you can. its a few trivial lines of module code to go put any evas object on > the desktop. anywhere. a few more to allow you to just move it around anywhere > - and a few more to resize. if you REALLY want that. a shelf is NOT THE > SOLUTION TO THIS. tyring to use the shelf shows a fundamental mis-understanding > of e's internal code and how it all works, and just how trivial it is to do it > yourself with custom objects. > > now if you absolutely MUST recycle gadgets (i don't see this as a good idea - > gadgets generally would be designed to be small and live within some > containering and management system. if you want full freedom objects i would > imagine they should be designed subtley differently as they may not live along > the edge of a screen anymore and be small. they many not be able to sanely pop > up menus or popups etc. etc., but if it MUST be a gadget you want to just put a > gadgon ON THE DESKTOP, and have a different layout smart manager that doesn't > lay items out in a line. it's a lot more work, mind you. > > everyone is always just asking to have a big clock - then someone go and make a > clock module that puts itself on the desktop. hell the clock module doesn't do > ANYTHING but display an evas object loaded from a edje. the edje does all the > work. ALL you need is a module that can select/load 1 or more specific .edj > files and place them on your desktop and let you move/resize them. > > as this is not on the todo list though - i leave it up to someone to go write a > module to do just that. it is an utterly trivial exercise to do it and it's not > worth getting into a debate over it. the debate will be more work than the > module code. And a tip would be to check out an old version of the ibar and the gadman code. Sebastian |