On 3/21/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I'd like to bring up some things about 'e' and gui-toolkits. > I know this has been a source of some friction here before, but > I'd like to be able to discuss various aspects in a serious and > rational way.. Hopefully, the toolkit devs themselves will be able > to help in this and see areas of interest they'd like to bring up.
No problem, I'll stock up on burn cream tonight, and try to limit myself to commenting on what I specifically know (EWL). > I wonder though if one can write apps with e's toolkits > that would allow for 'overriding' the toolkit's theme (with an > app-provided edje goup say), for a given toolkit widget? Also, is it > possible to build 'custom widgets' that can be given app-specific > theming? In EWL, you can set the theme data on a widget and override a specific key for that widget and all widgets contained in it. dan covered this in more detail, but we also have a test application that outlines one way to interact with a custom edje, it's available in ewl/src/bin/ewl_embed_test.c. > Just how flexible can/should 'theming' be? This last question is actually one of the most difficult parts of writing a toolkit around edje, it's a big balancing act. You can easily get wrapped up in theme-ability and kill consistency and performance, or make large sacrifices in theming to balance back the other direction, the middle ground is not trivial. I can outline a couple of the decisions we've made in EWL. Overall, we have taken the attitude that the GUI toolkit is used specifically for describing layouts with hints from the theme but not completely controlled by it, and as such, EWL is more like GTK+, QT, Swing, etc. I have looked at pushing some more responsibility into the theme, but I think it will complicate things to a degree I don't want to deal with until we've stabilized other aspects more. We also maintain some limited state information inside of the EWL widgets to allow for rebuilding edje object states as they are created or re-used. Because of this, we only have edje objects for the widgets that are currently visible in the window. This keeps the memory use down considerably as the number of widgets grows, and actually reduces CPU use as well, since the Evas rendering passes require less object traversal. We are actually able to easily outpace GTK+ in the CPU time and memory required to display a large number of widgets in a trivial scalability test. The downside of this trade-off is that we cannot rely on transient states inside of the Edje objects, so complex layouts and scripts may not behave as you'd like. > In a slightly different vein.. Is there something like the > equivalent of e17's modules for the gui-toolkits -- does something > like that even make sense? External libraries should be able to easily provide additional widgets, though we make no guarantees on API let alone ABI stability yet. I don't see much benefit to pushing a loading mechanism specifically into EWL at this time, as the application taking advantage of outside modules should be aware of its dependencies. This seems like a higher level function, like the KParts you mention below. > eg. I've sometimes seen references to kde's "kio slaves" > and "kparts"... Can anyone tell me exactly what these things are > and why they are considered useful? Are these kinds of things > something that a gui-toolkit should have, or are they more like > an ecore-lib? Is there a coherent relationship between such things > and say e_dbus, evfs, ....?? A good description of KIO is available on wikipedia: http://en.wikipedia.org/wiki/KIO As I understand, it's more like evfs than a toolkit layer. KParts on the other hand is like a communication layer for embedding higher level widgets inside applications. http://en.wikipedia.org/wiki/KPart > Much of this looks like a kind of multi-tiered jigsaw-puzzle > to me... What is the "big picture" here? And how do the "pieces" fit > together? A puzzle is a fairly good analogy, if you had pieces that overlapped one another and some that just didn't exist. :) Not only do we have the multiple toolkits, but we also have some widget-like features inside of Evas, Edje and some container features in Esmart. There are engine layers in evas, ecore, EWL and ETK, and IO mechanisms in Ecore, Ecore_File, EVFS, and EWL (though this is more for convenience for interfacing with widgets than a true IO API). At this point, I would say the big picture looks something like Trogdor. Nathan ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
