Am Thu, 19 Apr 2007 15:46:16 GMT schrieb "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
> > Hannes wrote: > > ... > > ... > > > > In short: there are a bunch of other modules that need to control > > how and where they appear on the desk; modules which might have > > multiple instance configurations to store. > > I would say engage, devian, calendar and all this desklet-stuff > > falls in this category for example. > > > > So what interfaces could be needed by such a module and how should > > the user configure these modules? > > > > Out of curiosity I looked up "desklet" and found references > to 'gdesklets' and 'SuperKaramba', which it seems are very popular > projects for gnome and kde respectively. > But there also came up something called 'adesklets', which > is a similar independent project that uses imlib2 for its gfx. > > To me, an edje based version of adesklets comes to mind > as natural possibility.. ie. building on whatever groundwork has > already been covered by the adesklets project/people. :) > > > ... > > ... > > Are there any objections to add something like this to e? > > I mean, it could simplify the work to create a desklet-like module > > a lot. > > If there is a better way to achieve what i want, please let me know! > > I wonder if it's a good idea to continue putting more and > more things into e17. > Wouldn't it be better to try and work with the adesklet > people (assuming they'd be interested) and maybe add edje based > capabilities? Maybe use edbus for better integration/communication > with e17..? Or even provide a 'kparts' like mechanism for these > desklets so they could be 'loaded' by e17 if desired, but have > them run independently by themselves in general... etc. > > Following Simon's and Brian's suggestions and ideas, I'd > say that these 'desklets' would also be perfect candidates for > mixed e-guitoolkit + custom-edje gadgets. Indeed a desktop independent etk/ewl based desklet framework would be nice to have =) Just an idea: Perhaps one could make a standalone module loader for e's modules, since a bunch of these could work without e. So people using another wm are able to use and develop e-modules. Hehe I still prefer a tighter integration with e, since some things are hard to achieve otherwise. For example listing to e's events. sending all events via dbus is much more work than what I would propose. Drawing to the desktop is also hard until evoak is in place or everyone uses xcomposite. Back to the point why it could be useful to add a new features to e. I think one can divide the ways a gadcon-client is displayed in these four categories: floating or edge and container or single module. (Drawing on the desktop or on a popup should be possible for each of these types) Atm only the container on an edge is supported by e(the shelf). For the other kinds one would have to write a lots of module-code for configuration and placement which _should_ be equal between modules. So the pros as far as i can see are: 1. less duplicated code 2. consistent configuration / instantiation 3. it's easier to write modules, so probably more people write modules 4. If one can't find a hypothetic module that doesn't fit in these categories then e is complete in one more sense :) Regards, Hannes > > jose. > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
