Re: [E-devel] E and gui-toolkits.
On Fri, 23 Mar 2007 13:21:33 +0100, Laurent Ghigonis [EMAIL PROTECTED] wrote : Thu, 22 Mar 2007 00:10:33 +0100, Simon TRENY [EMAIL PROTECTED] wrote : There is something I'd like to discuss here although I'm not sure it's really the right place to do so.. Since Etk and Ewl have begun to be usable enough, there has been a lot of new apps using one of these too. The thing is, too often those apps only copy existing apps and I just don't think this the right way. A lot of these apps would have been a lot better if they hadn't used a toolkit but if they had used directly Edje (and using Etk/Ewl only for the config dialogs). For example, if we want to have a nice, original and innovative image viewer, I really think its main interface should be directly coded with Edje (like what entice did but in a more complete way). Same thing for a filemanager, for an audio/video player or for an IM client... Toolkits are nice for config dialogs or for apps that need to offer a lot of control. If we really want to have a nice and innovative Enlightenment desktop environment, we should be different from the other desktop environments. We should have apps with a really nice and well-designed interface, and most of the time, this is just not possible with a toolkit. Elicit is a good example of an innovative application that blows your mind away when you first launch it. If it were using Etk or Ewl, it would just have been a common application. Hi, I agree with you that edje is a very powerful tool to create applications, and we should use it to create innovative user interfaces like in elicit or rage. But what about consistency between applications ? Do you have ideas how to maintain some king of consistency between apps, when creating you're own edje interfaces, or when using custom widgets in toolkits ? For example sharing color classes ... I agree, the biggest problem with Edje is the consistency issues: different looks, different behaviors... A glade-like tool could greatly help on this point I think. A tool like Glade, that would allow us to build interfaces made of Edje objects and Etk (or Ewl) widgets may be a part of the solution, but i believe it should be done at library level, not in a gui creator tool. What do you mean by at library level? There will indeed be functions to load the interface (in Etk, in Enhance, or in another lib, I don't know yet) but we'll still need a tool to build the interface (the tool will be used to assemble Edje objects and widgets/containers). Simon Just my thoughts =) laurent - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
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. src/bin/ewl_embed_test.c shows how to do this. It's a simple application, but it does show how the interaction can work. Ok, took a look.. and also at a similar 'embed_test' in etk. I imagined this completely backwards. You guys are 'embedding' toolkit widgets into evas objects! That's why Simon was talking about putting entry widgets into entrance's main edje. Ummm You know, Simon's suggestion for 'a tool that would allow us to build interfaces made of Edje objects and Etk (or Ewl) widgets' would be a great chance for both of you guys to work together and get something REALLY useful here - especially since a description format for such could be toolkit-agnostic. 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
On Fri, 23 Mar 2007 09:21:40 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote : 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. src/bin/ewl_embed_test.c shows how to do this. It's a simple application, but it does show how the interaction can work. Ok, took a look.. and also at a similar 'embed_test' in etk. I imagined this completely backwards. You guys are 'embedding' toolkit widgets into evas objects! That's why Simon was talking about putting entry widgets into entrance's main edje. Ummm The embed test of Etk indeed Embed widgets into an Evas object, but embedding Evas object in widgets is is also possible and even easier. You know, Simon's suggestion for 'a tool that would allow us to build interfaces made of Edje objects and Etk (or Ewl) widgets' would be a great chance for both of you guys to work together and get something REALLY useful here - especially since a description format for such could be toolkit-agnostic. Yes, it could be great to have a format that would be compatible with the both toolkits and it should be possible I guess. There just might be some problems for features that are supported by one toolkit and not by the other but I don't think there are a lot of these actually. I'll try to make a quick version of the tool and of the file format, we could discuss this later. For now, I'll use a xml-like format. Simon 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
Thu, 22 Mar 2007 00:10:33 +0100, Simon TRENY [EMAIL PROTECTED] wrote : There is something I'd like to discuss here although I'm not sure it's really the right place to do so.. Since Etk and Ewl have begun to be usable enough, there has been a lot of new apps using one of these too. The thing is, too often those apps only copy existing apps and I just don't think this the right way. A lot of these apps would have been a lot better if they hadn't used a toolkit but if they had used directly Edje (and using Etk/Ewl only for the config dialogs). For example, if we want to have a nice, original and innovative image viewer, I really think its main interface should be directly coded with Edje (like what entice did but in a more complete way). Same thing for a filemanager, for an audio/video player or for an IM client... Toolkits are nice for config dialogs or for apps that need to offer a lot of control. If we really want to have a nice and innovative Enlightenment desktop environment, we should be different from the other desktop environments. We should have apps with a really nice and well-designed interface, and most of the time, this is just not possible with a toolkit. Elicit is a good example of an innovative application that blows your mind away when you first launch it. If it were using Etk or Ewl, it would just have been a common application. Hi, I agree with you that edje is a very powerful tool to create applications, and we should use it to create innovative user interfaces like in elicit or rage. But what about consistency between applications ? Do you have ideas how to maintain some king of consistency between apps, when creating you're own edje interfaces, or when using custom widgets in toolkits ? For example sharing color classes ... A tool like Glade, that would allow us to build interfaces made of Edje objects and Etk (or Ewl) widgets may be a part of the solution, but i believe it should be done at library level, not in a gui creator tool. Just my thoughts =) laurent - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
On Wed, 21 Mar 2007 22:41:28 -0400, dan sinclair [EMAIL PROTECTED] wrote : On 21-Mar-07, at 7:10 PM, Simon TRENY wrote: In Etk, as in Ewl I think, you can change the theme of a specific widget or change globally the theme used by all the widgets. About custom widgets, it's indeed possible to build your own widget directly in the app's code, the only difficulty here will be the themability: either you use theme-parts from existing widgets and there will be no problem, or you use your own theme-file for this widget but it may look wrong with some Etk/Ewl themes. Ewl will allow you to specify the .edj file on a per widget basis if desired. Each widget has a /file along with a /group key that can be set. There is the same system in Etk as well. dan - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
On Thu, 22 Mar 2007 04:13:35 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote : From Nathan's, Simon's, and Dan's replies, it seems that both ewl and etk do have mechanisms for allowing app-specific theme overriding of the toolkit widgets, and in fairly general ways. Wow. So, one could write an app, to start with, that uses only the toolkit themes, and if desired one could then extend this to allow for further app-specific mods. Best of both worlds. Ok, could one take say raster's rage and do this? ie. could it be written with ewl/etk to use only (or mostly) the toolkit widgets/themes and then extend it to duplicate whatever its current theming? What about the same for say, entrance? Rage could be written quite easily with Etk (and Ewl I think), it would only require to implement a new container for the list of medias. But the thing is, there is no point of writting Rage with Etk/Ewl rather than directly with Edje. For Entrance, it's a bit more complicated since it doesn't have a fixed layout. With Etk/Ewl, you can theme each widgets individually, but you can't theme the layout. With Etk, you can still use glade + enhance to make the layout a bit themable, but it would never be as flexible as with Edje. Simon writes: 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? I'm not sure I understand what you mean here. You can have loadable widgets from a library, but there is no such things as modules (i.e. plugins that may change the behavior of an Etk apps). It may be a good idea, but I don't really see a use for this for now. Well, let's say 'gui-modules' as loadable libs that would provide additional interesting (but possibly somewhat more specific) functionality than buttons/menus/... For example, et's say we have an rss feed module, or a wether/forecast one, or just a clock, ... and that these could be embedded in normal toolkit widgets (in a menu or bar or whatnot). Yes, you can have additionnal widgets (clocks, rss, whatever, ...) in loadable libraries. In fact, you can build external widgets because you have access to all the methods for this in the Etk headers. Nathan writes: This seems like a higher level function, like the KParts you mention below. Ummm... Yeah, but possibly something more 'lightweight' would be good as well. I just took a quick look at kparts, this seems to be a mechanism for allowing functionality that some apps may have to be shared by others. It seems to require that 'part' to be given as a loadable shared lib with certain kinds of interfaces that are known, and the rest (gui controls) to be specified in an xml file in certain ways. This is something that doesn't seem to need a source app at all, but likely obtained that way from existing ones. It also seems to me that this kind of thing could be achieved via a sufficiently extended notion of a 'vfs'. Anyway... it does seem to be a useful idea. Simon writes: There is something I'd like to discuss here although I'm not sure it's really the right place to do so.. Since Etk and Ewl have begun to be usable enough, there has been a lot of new apps using one of these too. The thing is, too often those apps only copy existing apps and I just don't think this the right way. A lot of these apps would have been a lot better if they hadn't used a toolkit but if they had used directly Edje (and using Etk/Ewl only for the config dialogs)... Ummm.. I know what you're trying to say.. But there are several sides to this. One is that most people will find it MUCH easier to use a toolkit, and that seems to me to be the way to start unless you want a mostly stand-alone app, and are very good with edje. If e can have nearly as many apps written in its toolkits as there are now for gtk.. then I'd say that alone would be great achievement! Actually, I see no real point in coding with Etk/Ewl an aplication that already exists with Gtk or Qt. It would only offer more consistency with an E desktop, and some eye-candy effects but it's quite a waste of time imho. We should try to think differently, because we have tools (Edje/Evas) that allow us to do things differently. But some apps can't indeed be done really differently (for example, an Email client or a FTP client in Gnome/Kde/E will always look the same, we can't be really innovative here). If indeed one can extend ewl/etk in the ways you mention, then one could later optionally extend the theming and/or widgetry to be as unique as desired - hence allowing for both app-unique and toolkit-common 'lookfeel' for a large number of apps that people may be inclined to write. Actually, when the basic widgets will be completely done in Etk, I'm planning to add a bunch of other widgets which only aims to
Re: [E-devel] E and gui-toolkits.
On Thu, 22 Mar 2007 11:00:59 +0100 Simon TRENY [EMAIL PROTECTED] wrote: On Thu, 22 Mar 2007 04:13:35 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote : Simon writes: 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? I'm not sure I understand what you mean here. You can have loadable widgets from a library, but there is no such things as modules (i.e. plugins that may change the behavior of an Etk apps). It may be a good idea, but I don't really see a use for this for now. Well, let's say 'gui-modules' as loadable libs that would provide additional interesting (but possibly somewhat more specific) functionality than buttons/menus/... For example, et's say we have an rss feed module, or a wether/forecast one, or just a clock, ... and that these could be embedded in normal toolkit widgets (in a menu or bar or whatnot). Yes, you can have additionnal widgets (clocks, rss, whatever, ...) in loadable libraries. In fact, you can build external widgets because you have access to all the methods for this in the Etk headers. I think this is what raster eventually wants with gadgets. To embed them in lots of interesting places apart from shelves. signature.asc Description: PGP signature - 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.phpp=sourceforgeCID=DEVDEV___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
Simon writes: Yes, you can have additionnal widgets (clocks, rss, whatever, ...) in loadable libraries. In fact, you can build external widgets because you have access to all the methods for this in the Etk headers. Sure. But the questions is really more of wether the toolkits themselves should provide a 'simple mechanism' for making these available in a 'standard' way (as well as a repo of common such that it might want to include). If e can have nearly as many apps written in its toolkits as there are now for gtk.. then I'd say that alone would be great achievement! Actually, I see no real point in coding with Etk/Ewl an aplication that already exists with Gtk or Qt. It would only offer more consistency with an E desktop, and some eye-candy effects but it's If no 'existing' gtk/qt apps are ever written with ewl/etk, then there never going to be any image viewer apps, any text editors, or any of the other 20,000+ apps that exist -- you're going to have to think real hard to make up a 'brand new' kind of app that no one has ever done before in gtk/qt, just to make it 'worth' doing in e's toolkits?? quite a waste of time imho. We should try to think differently, because we have tools (Edje/Evas) that allow us to do things They aren't as known or as simple to use for building large or common stuff, as more 'standard' gui-toolkits.. they require much more initial effort, time, etc.. IF you do have the initiative, the time, the desire, the creative drive.. to really want to make something completely different, THEN yes that would be the way to go from the start. For many others, it might just not be worth it and instead opt to use more familiar tools and concepts.. especially if the built-in theming is already quite satisfactory. differently. But some apps can't indeed be done really differently (for example, an Email client or a FTP client in Gnome/Kde/E will always look the same, we can't be really innovative here). How do you know? Sure you can, you just have to The point isn't wether one can or cannot make some things really new, better, different.. nor wether one should or should not do it. It's letting people make those decisions themselves by giving them the ability to have the 'best of both worlds' if they so desire. :) 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
On Thu, Mar 22, 2007 at 02:31:57PM +, [EMAIL PROTECTED] wrote: Simon writes: Actually, I see no real point in coding with Etk/Ewl an aplication that already exists with Gtk or Qt. It would only offer more consistency with an E desktop, and some eye-candy effects but it's If no 'existing' gtk/qt apps are ever written with ewl/etk, then there never going to be any image viewer apps, any text editors, or any of the other 20,000+ apps that exist -- you're going to have to think real hard to make up a 'brand new' kind of app that no one has ever done before in gtk/qt, just to make it 'worth' doing in e's toolkits?? quite a waste of time imho. We should try to think differently, because we have tools (Edje/Evas) that allow us to do things I think the sentiment he's trying to get across, which is one I share, is that there is little point in rewriting a gtk/kde app in an e widget set if it looks and functions exactly the same. E.g. using emphasis (or whatever the glade lib is) with a gnome app's glade file is a lot of effort (recreating the backend functionality) with the only gain being glinty buttons. The point is NOT that we can't use new, innovate image viewers, text editors, etc. But, we need to sit and think about how we can improve on the current 'desktop app' idioms. Elicit is a simple enough application that it can have its gui entirely defined in edje. I've thought several times about breaking some of its layout out into some smart objects (e.g. the a simple notebook smartobj). However, this would severly dampen what is possible from the theming standpoint. Tokyo has done some amazing versions of pared down single panel (no tabs) themes for elicit. You'll also notice that elicit has no proper configuration dialogs. So, if a theme doesn't provide a theme selector, then you can't switch themes. For small apps like this, this is an arena where traditional packed widgets fit in. Many larger apps (image viewers, music players, etc) could probably be done in a similar fashion. E.g. a free form edje ui for the primary functionality, with a packed widget set for dialogs. But, it really depends on the app in question (and the imagination of the author). rephorm - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
On Thu, 22 Mar 2007 09:59:02 -0500, Brian Mattern [EMAIL PROTECTED] wrote : On Thu, Mar 22, 2007 at 02:31:57PM +, [EMAIL PROTECTED] wrote: Simon writes: Actually, I see no real point in coding with Etk/Ewl an aplication that already exists with Gtk or Qt. It would only offer more consistency with an E desktop, and some eye-candy effects but it's If no 'existing' gtk/qt apps are ever written with ewl/etk, then there never going to be any image viewer apps, any text editors, or any of the other 20,000+ apps that exist -- you're going to have to think real hard to make up a 'brand new' kind of app that no one has ever done before in gtk/qt, just to make it 'worth' doing in e's toolkits?? quite a waste of time imho. We should try to think differently, because we have tools (Edje/Evas) that allow us to do things I think the sentiment he's trying to get across, which is one I share, is that there is little point in rewriting a gtk/kde app in an e widget set if it looks and functions exactly the same. E.g. using emphasis (or whatever the glade lib is) with a gnome app's glade file is a lot of effort (recreating the backend functionality) with the only gain being glinty buttons. Exactly what I meant :) Btw, the glade-like lib is enhance, emphasis is the mpd client (audio player). 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. Simon The point is NOT that we can't use new, innovate image viewers, text editors, etc. But, we need to sit and think about how we can improve on the current 'desktop app' idioms. Elicit is a simple enough application that it can have its gui entirely defined in edje. I've thought several times about breaking some of its layout out into some smart objects (e.g. the a simple notebook smartobj). However, this would severly dampen what is possible from the theming standpoint. Tokyo has done some amazing versions of pared down single panel (no tabs) themes for elicit. You'll also notice that elicit has no proper configuration dialogs. So, if a theme doesn't provide a theme selector, then you can't switch themes. For small apps like this, this is an arena where traditional packed widgets fit in. Many larger apps (image viewers, music players, etc) could probably be done in a similar fashion. E.g. a free form edje ui for the primary functionality, with a packed widget set for dialogs. But, it really depends on the app in question (and the imagination of the author). rephorm - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
On Thursday 22 March 2007 16:36:46 Simon TRENY wrote: On Thu, 22 Mar 2007 09:59:02 -0500, Brian Mattern [EMAIL PROTECTED] wrote : On Thu, Mar 22, 2007 at 02:31:57PM +, [EMAIL PROTECTED] wrote: Simon writes: Actually, I see no real point in coding with Etk/Ewl an aplication that already exists with Gtk or Qt. It would only offer more consistency with an E desktop, and some eye-candy effects but it's If no 'existing' gtk/qt apps are ever written with ewl/etk, then there never going to be any image viewer apps, any text editors, or any of the other 20,000+ apps that exist -- you're going to have to think real hard to make up a 'brand new' kind of app that no one has ever done before in gtk/qt, just to make it 'worth' doing in e's toolkits?? quite a waste of time imho. We should try to think differently, because we have tools (Edje/Evas) that allow us to do things I think the sentiment he's trying to get across, which is one I share, is that there is little point in rewriting a gtk/kde app in an e widget set if it looks and functions exactly the same. E.g. using emphasis (or whatever the glade lib is) with a gnome app's glade file is a lot of effort (recreating the backend functionality) with the only gain being glinty buttons. Which one should one use when they want it to embed the widgets into an edje interface? Etk or Ewl? The other question I have: Why does two toolkits like these co-exist? Will ETK replace EWL? I was told that this isn't the case. I don't quite understand the reason, though. Wasn't ETK made to provide an API similar to GTK's, so the porting would be easier? And now you say, we should do Edje instead. Btw, where can I find an Edje how-to, which describes not only the .edc files, but the linking to the application, too? Peter - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
Brian wrote: I think the sentiment he's trying to get across, which is one I share, is that there is little point in rewriting a gtk/kde app in an e widget set if it looks and functions exactly the same. E.g. using emphasis (or whatever the glade lib is) with a gnome app's glade file is a lot of effort (recreating the backend functionality) with the only gain being glinty buttons. I'd have to disagree with this.. there are many reasons why, but again just from the point of view of 'initial effort', no matter what you might be writing, unless you are really comfortable with directly using evas+edje+ecore, it may be a difficult way to start, wheras many are likely far more comfortable with a more traditional gui-toolkit approach, its concepts, etc. Furthermore, and this was something that was on my mind from the start, if indeed the e-toolkits are well designed enough that they can allow you to override theming of built-in stuff, (as well as create custom widgets+theme), then it'll be easier to slowly work the app into further edje-based customization as the writer becomes more familiar with things. Eventually, more and more inovative 'mixes' will emerge, but I think you and Simon may be a bit too familiar with edjethings, and forget that not everyone else is similarly so. :) The point is NOT that we can't use new, innovate image viewers, text editors, etc. But, we need to sit and think about how we can improve on the current 'desktop app' idioms. Well, that was one of the things I'd hoped to see further discussion on by the toolkit authors.. there are many interesting aspects that can be explored here, both at the toolkit level and abovebelow that. 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
On 3/22/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: 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??? :) werkt put together an app called ewler that did a lot of the serialization necessary for describing EWL widgets. It hasn't been updated in a while, so I'm not sure if it works still. Some combination of this with an edje layout application could provide a basic framework. 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. src/bin/ewl_embed_test.c shows how to do this. It's a simple application, but it does show how the interaction can work. 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. :) I don't think this kind of gizmo support belongs directly in the toolkit library. It sounds more like a module loading wrapper around widgets that don't export any API calls. An external library, lets call it ewl-candy for now, could do this by defining a module hooks and simply returning an Ewl_Widget. That widget could then be placed inside of any EWL container. The library itself could be very simple, but provide some basic gizmos for re-use. These widgets could also be an extended widget type that exports additional interfaces beyond the base Ewl_Widget class. - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] E and gui-toolkits.
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. There are many aspects to something as complex as a high- level gui-toolkit lib, but one that is important for 'e' is themability. This allows for consistent and yet variable 'look feel' for apps built with them. 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? Just how flexible can/should 'theming' be? 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? There are of course many other aspects of interest, not necessarily related to theming, and I wonder if the toolkit devs have any thoughts or ideas they feel would be interesting, or things they feel 'e' should support, ... 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, ?? 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? 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
[EMAIL PROTECTED] wrote: 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? Just how flexible can/should 'theming' be? Ewl allows you to override the theme as needed. You can either a) write your own theme and use that to display, or b) you can override theme keys on the fly to add or remove theming as needed. Ewl uses a hierarcy of theme keys so you can be very specific in what you want to override. If you only want your buttons inside your hbox inside your window to change you can override /window/hbox/button/group and point it to a different theme group. The app doesn't need to know anything about the theme, it just needs to know the widget hierarchy that it's overridding (which it can trivially discover with --ewl-print-theme-keys on the command line.) The themes work by defining a data section in the main edc file that gives the key mappings for the theme itself. 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? Ewl has several pieces that are pluggable. You can add your own widgets, epdf does this to create an Ewl_Widget. You can add engines which Ewl will discover at runtime, the engines are also inheritable so you only need to write the pieces that are different. You can add IO Managers (these are still very much in flux and the API _will_ change.) You can also provide different views for the Ewl_Filepicker widget. (We use this to provide icon, list and column views.) The same view concept is used in the tree to allow us a plain display or a scrolled display. There are of course many other aspects of interest, not necessarily related to theming, and I wonder if the toolkit devs have any thoughts or ideas they feel would be interesting, or things they feel 'e' should support, ... 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, ?? kio slaves I take to be more inline with evfs. Evfs could be used by the Ewl filpicker widget but I believe there were some issues getting it to work on OSX, can't remember exactly. Kparts, at least my understanding, is that their just bigger, more complicated widgets? Ewl will be using e_dbus I think in the future to handle sending out configuration change notifications. This hasn't been built in yet, but it used to do this using the ecore_config IPC mechanism. dan - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list
Re: [E-devel] E and gui-toolkits.
On Wed, 21 Mar 2007 21:37:12 GMT, [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. There are many aspects to something as complex as a high- level gui-toolkit lib, but one that is important for 'e' is themability. This allows for consistent and yet variable 'look feel' for apps built with them. 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? Just how flexible can/should 'theming' be? In Etk, as in Ewl I think, you can change the theme of a specific widget or change globally the theme used by all the widgets. About custom widgets, it's indeed possible to build your own widget directly in the app's code, the only difficulty here will be the themability: either you use theme-parts from existing widgets and there will be no problem, or you use your own theme-file for this widget but it may look wrong with some Etk/Ewl themes. 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? I'm not sure I understand what you mean here. You can have loadable widgets from a library, but there is no such things as modules (i.e. plugins that may change the behavior of an Etk apps). It may be a good idea, but I don't really see a use for this for now. There are of course many other aspects of interest, not necessarily related to theming, and I wonder if the toolkit devs have any thoughts or ideas they feel would be interesting, or things they feel 'e' should support, ... There is something I'd like to discuss here although I'm not sure it's really the right place to do so.. Since Etk and Ewl have begun to be usable enough, there has been a lot of new apps using one of these too. The thing is, too often those apps only copy existing apps and I just don't think this the right way. A lot of these apps would have been a lot better if they hadn't used a toolkit but if they had used directly Edje (and using Etk/Ewl only for the config dialogs). For example, if we want to have a nice, original and innovative image viewer, I really think its main interface should be directly coded with Edje (like what entice did but in a more complete way). Same thing for a filemanager, for an audio/video player or for an IM client... Toolkits are nice for config dialogs or for apps that need to offer a lot of control. If we really want to have a nice and innovative Enlightenment desktop environment, we should be different from the other desktop environments. We should have apps with a really nice and well-designed interface, and most of the time, this is just not possible with a toolkit. Elicit is a good example of an innovative application that blows your mind away when you first launch it. If it were using Etk or Ewl, it would just have been a common application. I just wish that when someone will want to start a new application, he will consider making it using Edje and not jumping directly on Etk or Ewl. Or Enlighenment apps will just be a copy of Gnome/Kde apps (with some glint on the buttons though :)) Simon TRENY MoOm 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, ?? 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? 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - 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
Re: [E-devel] E and gui-toolkits.
On Thu, 22 Mar 2007 00:10:33 +0100 Simon TRENY [EMAIL PROTECTED] wrote: On Wed, 21 Mar 2007 21:37:12 GMT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote : There are of course many other aspects of interest, not necessarily related to theming, and I wonder if the toolkit devs have any thoughts or ideas they feel would be interesting, or things they feel 'e' should support, ... There is something I'd like to discuss here although I'm not sure it's really the right place to do so.. Since Etk and Ewl have begun to be usable enough, there has been a lot of new apps using one of these too. The thing is, too often those apps only copy existing apps and I just don't think this the right way. A lot of these apps would have been a lot better if they hadn't used a toolkit but if they had used directly Edje (and using Etk/Ewl only for the config dialogs). For example, if we want to have a nice, original and innovative image viewer, I really think its main interface should be directly coded with Edje (like what entice did but in a more complete way). Same thing for a filemanager, for an audio/video player or for an IM client... Like the recently committed rage video player for instance. signature.asc Description: PGP signature - 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.phpp=sourceforgeCID=DEVDEV___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
On 21-Mar-07, at 7:10 PM, Simon TRENY wrote: In Etk, as in Ewl I think, you can change the theme of a specific widget or change globally the theme used by all the widgets. About custom widgets, it's indeed possible to build your own widget directly in the app's code, the only difficulty here will be the themability: either you use theme-parts from existing widgets and there will be no problem, or you use your own theme-file for this widget but it may look wrong with some Etk/Ewl themes. Ewl will allow you to specify the .edj file on a per widget basis if desired. Each widget has a /file along with a /group key that can be set. dan - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E and gui-toolkits.
From Nathan's, Simon's, and Dan's replies, it seems that both ewl and etk do have mechanisms for allowing app-specific theme overriding of the toolkit widgets, and in fairly general ways. Wow. So, one could write an app, to start with, that uses only the toolkit themes, and if desired one could then extend this to allow for further app-specific mods. Best of both worlds. Ok, could one take say raster's rage and do this? ie. could it be written with ewl/etk to use only (or mostly) the toolkit widgets/themes and then extend it to duplicate whatever its current theming? What about the same for say, entrance? Simon writes: 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? I'm not sure I understand what you mean here. You can have loadable widgets from a library, but there is no such things as modules (i.e. plugins that may change the behavior of an Etk apps). It may be a good idea, but I don't really see a use for this for now. Well, let's say 'gui-modules' as loadable libs that would provide additional interesting (but possibly somewhat more specific) functionality than buttons/menus/... For example, et's say we have an rss feed module, or a wether/forecast one, or just a clock, ... and that these could be embedded in normal toolkit widgets (in a menu or bar or whatnot). Nathan writes: This seems like a higher level function, like the KParts you mention below. Ummm... Yeah, but possibly something more 'lightweight' would be good as well. I just took a quick look at kparts, this seems to be a mechanism for allowing functionality that some apps may have to be shared by others. It seems to require that 'part' to be given as a loadable shared lib with certain kinds of interfaces that are known, and the rest (gui controls) to be specified in an xml file in certain ways. This is something that doesn't seem to need a source app at all, but likely obtained that way from existing ones. It also seems to me that this kind of thing could be achieved via a sufficiently extended notion of a 'vfs'. Anyway... it does seem to be a useful idea. Simon writes: There is something I'd like to discuss here although I'm not sure it's really the right place to do so.. Since Etk and Ewl have begun to be usable enough, there has been a lot of new apps using one of these too. The thing is, too often those apps only copy existing apps and I just don't think this the right way. A lot of these apps would have been a lot better if they hadn't used a toolkit but if they had used directly Edje (and using Etk/Ewl only for the config dialogs)... Ummm.. I know what you're trying to say.. But there are several sides to this. One is that most people will find it MUCH easier to use a toolkit, and that seems to me to be the way to start unless you want a mostly stand-alone app, and are very good with edje. If e can have nearly as many apps written in its toolkits as there are now for gtk.. then I'd say that alone would be great achievement! If indeed one can extend ewl/etk in the ways you mention, then one could later optionally extend the theming and/or widgetry to be as unique as desired - hence allowing for both app-unique and toolkit-common 'lookfeel' for a large number of apps that people may be inclined to write. Nathan writes: 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. :) At this point, I would say the big picture looks something like Trogdor. Ahhh :) 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
