Simon wrote:
> Actually, one thing that could be really cool would be a tool
> like Glade, but that would allow us to build interfaces made of
> Edje objects and Etk (or Ewl) widgets. For example, for Entrance,
> we could have the main interface still be an Edje object but we
> could replace the entry/buttons by themed Etk widgets. With the
> tool, we could place the widgets wherever we want in the interface
> (no fixed layout anymore). Same for elicit, the spinners could be
> spinners from Etk (just an example). The apps will look exactly
> the same, and will still be as themable as before, but it would
> combine the advantages of the both libraries (Edje and Etk):
> the high themability of Edje and the ease of use of Etk (there
> would be no need to reimplement the behavior of an entry or of
> a spinner in the code, there would natively be keyboard-navigation
> between the different widgets of the interface, ...). I'm not sure
> I'm clear here, but I really think it would be really nice thing
> to have.
Now that would be good indeed... What exactly would one need
from ewl or etk for this?
One'd also need to come up with a format for decribing such
gui-interfaces, one that would have the concepts of toolkit widget
types, and edje groups...
Any suggestions??? :)
Nathan wrote:
> Use what you like. If you are developing an application that
> a toolkit is sufficient for, then use a toolkit. If you are
> developing something with a highly custom interface, then use
> Edje. There are points in between where you can mix the two
> fairly easily. For example, using a toolkit to provide file
> chooser dialogs or standard widgets, or creating a custom
> theme for the toolkit to make your application look a specific
> way.
It'd be good to see a real example of this combined use
of toolkit-widgets + custom-edje-widgets in an app like "rage" or
"entrance" or "elicit" or whatever.
I also think, as I mentioned before, that it would be nice
if the toolkits allowed for 'widgets' obtained via run-time loadable
libs (rather than requiring included headers for custom/derived
widgets), ie. the 'gui-module' kind of thing I mentioned earlier.
Why? Well, I think the 'epplet' kinds of things that eg.
some of e17's modules now give would be nice to have *widely available*
and *easily added* in gui's - and I just don't see why an app should
need to know eg. internal headers for a "clock" gizmo? (maybe just
certain simple interfaces that such a thing might want to export..??).
This might be too unstructured, and there may be better ways..
but just thought I'd mention it. :)
jose.
-------------------------------------------------------------------------
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
