From: Christian K. <kre...@in...> - 2002-03-02 22:37:36
|
Hi folks, I spent some more time thinking about how to proceed widget-wise in e17. The following is probably unusual, if you think it's plain stupid, don't hesitate to speak up. You're welcome of course to speak up if you like it, too :) Sooner or later, we'll need a bunch of config dialogs and little helper tools (for configuring the icons of a file, setting permissions etc) for e17. The obvious problem is what widget set to use for that. Traditionally, E tried to stay neutral to the two big desktop movements, KDE and Gnome. It only half succeeded, because all helper apps have always been written in Gtk. A potential candidate is ewl, of course. To be honest, I think staying neutral by doing our own thing is stupid. The one thing I want more than anything from my desktop is look integrated. I almost exclusively use Gtk/Gnome apps, others are using KDE, but everybody would certainly like it best if e17's dialogs and tools would show up in the same familiar GUI style they're seeing in all their other apps, with all their benefits. Frankly, if we would use ewl for our GUI needs, the first thing I'd do is create a Gtk theme to make it fit the looks of everything else on my desktop. This is nothing against ewl, it just cannot possibly give me anything that Gtk can't and that I want (this is purely personal, but I couldn't care less if that okay button is translucent or not). But why should I waste my time cropping screenshots of Gtk apps, and others theirs by cropping screenshots of their Qt apps. While we will probably produce more flexible themes for e17 that don't cause people to produce green, blue, whatever versions of popular themes, we'd cause lots of copied looks for ewl. Now, how much work is actually necessary to write the code for these dialogs? It's minimal. Anyone could use the gui creation tools that are available for qt and gtk and whip up dialogs in the style we had in e16 in no time flat, since they are basically just simple tables of togglebuttons and checkboxes. The tools aren't much harder, efileinfo had ~1200 lines, the mimetype management will need a bit more, but much of that can be shared if GUI and functionality are properly separated. I think that for everyday use of e17, the number of dialogs and helper apps is very predictable and manageable. So, here it comes: can't we use dynamically loaded modules that follow the handle-envelope or bridge pattern, and that provide entry points like show_view_settings(), show_focus_settings() etc, and that themselves use qt, gtk, or ewl? It would save us all the hassle of doing these things ourselves, the result would be more integrated, and people don't get the impression of using yet another heterogeneous component on their system. We would need to duplicate effort, yes. But it's not like there are 25 widget sets out there that are commonly used -- there are two, and the ewl crew could provide a third. Plus all that the callbacks really need to do is read out the values of the checkboxes etc and update the config settings. I say let's go for it. I'd love to do the Gtk work, I'm sure it wouldn't be hard to find someone for the Qt part, and the ewl folks get a precise goal to work for that could show off ewl's capabilities in direct comparison to Gtk and Qt, for the people who want those features. *phew*. Now it's out. Flame away :) Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: Nathan I. <ningerso@d.umn.edu> - 2002-03-03 02:04:16
|
On Sat, Mar 02, 2002 at 11:33:23PM +0100, Christian Kreibich is quoted as saying: > So, here it comes: can't we use dynamically loaded modules that follow > the handle-envelope or bridge pattern, and that provide entry points > like show_view_settings(), show_focus_settings() etc, and that > themselves use qt, gtk, or ewl? It would save us all the hassle of doing > these things ourselves, the result would be more integrated, and people > don't get the impression of using yet another heterogeneous component on > their system. Well, I'm not really familiar with those particular design patterns, but I think I understand your basic idea. You want modules that provide a simplified interface to the various widget sets so that the dialog boxes use the user specified widget set? So in effect, the user only needs to match a window theme to one gtk/qt/ewl theme rather than needing to match a window theme to a qt/gtk theme as well as an ewl theme? > We would need to duplicate effort, yes. But it's not like there are 25 > widget sets out there that are commonly used -- there are two, and the > ewl crew could provide a third. Plus all that the callbacks really need > to do is read out the values of the checkboxes etc and update the config > settings. I say let's go for it. I'd love to do the Gtk work, I'm sure > it wouldn't be hard to find someone for the Qt part, and the ewl folks > get a precise goal to work for that could show off ewl's capabilities in > direct comparison to Gtk and Qt, for the people who want those features. > > *phew*. Now it's out. Flame away :) > > Christian. If I'm understanding you correctly, this doesn't sound like a bad idea to me. While I would probably use the ewl module (I'm biased ;-), I can understand wanting to use some other widget set. Ewl should have some definite visual features beyond the others, but some users may prefer gtk or qt, or need themes that aren't so pixmap intensive as most ewl themes will probably be. So as far as I'm concerned, let's start discussing design issues. (And if you have links to explanations of those particular design patterns I'd appreciate it. Design Patterns has been on my "buy ASAP" list for quite a while, unfortunately books required for classes, and a new car came first.) RbdPngn --------------------------------------------------------------------------- | Nathan Ingersoll | Computer Science/Mathematics | | mailto: ningerso@d.umn.edu | University of Minnesota-Duluth | | http://umn.edu/~ningerso | http://www.d.umn.edu | --------------------------------------------------------------------------- |
From: Corey D. <cdo...@me...> - 2002-03-03 02:46:23
|
* Nathan Ingersoll (ningerso@d.umn.edu) wrote: > On Sat, Mar 02, 2002 at 11:33:23PM +0100, Christian Kreibich is quoted as saying: > > So as far as I'm concerned, let's start discussing design issues. (And if you > have links to explanations of those particular design patterns I'd appreciate > it. Design Patterns has been on my "buy ASAP" list for quite a while, > unfortunately books required for classes, and a new car came first.) /me hugs his copy =) The idea sounds like an interesting alternative. I got a question though. We can link to qt stuff? I'm not really familiar with writing modules like this, and I wasn't aware we could link off C++ libs. I have a few more questions but I'll prolly read up before I ask any more dumb stuff. > > RbdPngn > > --------------------------------------------------------------------------- > | Nathan Ingersoll | Computer Science/Mathematics | > | mailto: ningerso@d.umn.edu | University of Minnesota-Duluth | > | http://umn.edu/~ningerso | http://www.d.umn.edu | > --------------------------------------------------------------------------- > > > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel __ Corey Donohoe at...@at... cdo...@me... |
From: Nathan I. <ningerso@d.umn.edu> - 2002-03-03 04:43:20
|
On Sat, Mar 02, 2002 at 08:46:04PM -0600, Corey Donohoe is quoted as saying: > /me hugs his copy =) Yeah, I actually had a class based on that book, but our prof messed up and selected a Java book (since it wasn't a prereq for the course) before he realized all of the standard Java API is online. > The idea sounds like an interesting alternative. I got a question > though. We can link to qt stuff? I'm not really familiar with writing > modules like this, and I wasn't aware we could link off C++ libs. I > have a few more questions but I'll prolly read up before I ask any more > dumb stuff. Not a dumb question at all, there are some issues linking C programs to C++ libs. There is or was a C binding library for Qt called QtC. Although the messages on list archives that I saw about it were from '97 and '98. The fact that it's a module might get around the issue. Someone set me straight if I'm wrong about this as my C++ experience is fairly limited. We would only build the module if Qt was present on the system. From there the modules presents an interface to E using only structs and functions, no classes or other C++'isms. In this way we avoid having a C++ requirement for E. Inside the module, we could use C++ to access Qt, and since it's built as a module, the modules is compiled with the necessary options, and the linker will take care of the rest if/when the module is loaded. Am I correct in my thinking on this issue? RbdPngn --------------------------------------------------------------------------- | Nathan Ingersoll | Computer Science/Mathematics | | mailto: ningerso@d.umn.edu | University of Minnesota-Duluth | | http://umn.edu/~ningerso | http://www.d.umn.edu | --------------------------------------------------------------------------- |
From: Christian K. <kre...@in...> - 2002-03-03 09:10:52
|
Nathan Ingersoll wrote: > > > The idea sounds like an interesting alternative. I got a question > > though. We can link to qt stuff? I'm not really familiar with writing > > modules like this, and I wasn't aware we could link off C++ libs. I > > have a few more questions but I'll prolly read up before I ask any more > > dumb stuff. > > Not a dumb question at all, there are some issues linking C programs to C++ Yup, not at all. > libs. There is or was a C binding library for Qt called QtC. Although the > messages on list archives that I saw about it were from '97 and '98. > > The fact that it's a module might get around the issue. Someone set me > straight if I'm wrong about this as my C++ experience is fairly limited. > > We would only build the module if Qt was present on the system. From there the > modules presents an interface to E using only structs and functions, no > classes or other C++'isms. In this way we avoid having a C++ requirement for E. > Inside the module, we could use C++ to access Qt, and since it's built as a > module, the modules is compiled with the necessary options, and the linker > will take care of the rest if/when the module is loaded. > > Am I correct in my thinking on this issue? Yeah. You can write the module in C++ basically, it's just the hooks that need to be available from C, and these can be normal functions. 'extern "C"' statements should help here... Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: Christian K. <kre...@in...> - 2002-03-03 09:10:51
|
Nathan Ingersoll wrote: > > Well, I'm not really familiar with those particular design patterns, but I Just look at the gang of four book, Design Patterns. Very cool book. ootips.org is also pretty good. I meant to say letter-envelope btw :) > think I understand your basic idea. You want modules that provide a simplified > interface to the various widget sets so that the dialog boxes use the user > specified widget set? So in effect, the user only needs to match a window theme > to one gtk/qt/ewl theme rather than needing to match a window theme to a qt/gtk > theme as well as an ewl theme? Yes. Basically we'd only provide a windowmanager theme (i.e. borders, menus), any widgets that we need are provided by the selected toolkit. Now -- I'm aware of the problems. There are challenges, traditionally for X apps, the gui event loop was the driving force behind X applications. We have our event loop already, it's very powerful too. The hard part would be integrating other event loops (for ewl no extra effort would be necessary, that's a big plus). My idea was to leave that up to each module. I'm not too familiar with Qt anymore (last work I did with it was before 2.0), but by putting these widget set event loops in a different process we should be able to work around that. We only need to send them a message "show dialog XYZ", and they'd send back the settings through a file descriptor that's hooked into our event loop. Another thing is that it would be fairly easy for the predefined dialogs. But when epplets want to create custom dialogs, things will get a lot harder. > If I'm understanding you correctly, this doesn't sound like a bad idea to me. > While I would probably use the ewl module (I'm biased ;-), I can understand I would certainly give it a try, you bet :o) My main point was that I think we should spend considerable effort on staying really neutral by supporting the user's widget set of choice, not imposing yet another one. I didn't even really expect people to like the idea :) > So as far as I'm concerned, let's start discussing design issues. (And if you > have links to explanations of those particular design patterns I'd appreciate > it. Design Patterns has been on my "buy ASAP" list for quite a while, > unfortunately books required for classes, and a new car came first.) HAHAHA and I guess the car didn't leave enough money for the book, eh :) Cheers, Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: Nathan I. <ningerso@d.umn.edu> - 2002-03-04 05:57:46
|
On Sun, Mar 03, 2002 at 09:50:55AM +0100, Christian Kreibich is quoted as saying: > Just look at the gang of four book, Design Patterns. Very cool book. > ootips.org is also pretty good. I meant to say letter-envelope btw :) Thanks for the link though, I'll have to check that out later. > Yes. Basically we'd only provide a windowmanager theme (i.e. borders, > menus), any widgets that we need are provided by the selected toolkit. > > Now -- I'm aware of the problems. There are challenges, traditionally > for X apps, the gui event loop was the driving force behind X > applications. We have our event loop already, it's very powerful too. > The hard part would be integrating other event loops (for ewl no extra > effort would be necessary, that's a big plus). I wouldn't say no effort, but very little. Ewl does some setup in the main function before the event loop, but it should be easy enough to modify things so that we can run on any ecore event loop. > My idea was to leave that > up to each module. I'm not too familiar with Qt anymore (last work I did > with it was before 2.0), but by putting these widget set event loops in > a different process we should be able to work around that. We only need > to send them a message "show dialog XYZ", and they'd send back the > settings through a file descriptor that's hooked into our event loop. I agree that a separate process would be necessary to handle the event loops cleanly. That brings up the issue of IPC with E. It seems like we should establish the IPC protocol that e17 will use (if it hasn't already been established) since these dialogs could make use of that, as well as allowing for a new eesh. > Another thing is that it would be fairly easy for the predefined > dialogs. But when epplets want to create custom dialogs, things will get > a lot harder. This definitely makes things quite a bit harder. I wish I was more familiar with the way Qt works in order to know what things are similar to gtk and ewl, and what aren't. But I think it's safe to assume they share many of the same properties (initialization function, main event loop, callbacks/signals, etc). If we want to provide facilities for epplets, it almost seems like a wrapper lib would be the most effective way to do so. Basically, a simplified widget library that accesses modules containing the code for the specific widget toolkit backend. Although it could be quite a lot of work to create, I'm sure people outside of the E community would love to see something like this as well, and I'm rather surprised no one has written something like this yet. Simple applications could be written using this wrapper library, and the author could be assured that their app would work on any machine that had any of the modules installed. The downsides are that module writing would be a big part of the work since mappings would have to be provided for all of the functions, and that applications would have to be quite simple to fit within the supported subset. > I would certainly give it a try, you bet :o) My main point was that I > think we should spend considerable effort on staying really neutral by > supporting the user's widget set of choice, not imposing yet another > one. I didn't even really expect people to like the idea :) I actually really like the idea of wrapping various toolkits. I started using E because it provided so much choice to the user (and that it was the first to be so perty), and while I hope people will enjoy using ewl once it's matured a bit, I have no desire to force it down their throats. > HAHAHA and I guess the car didn't leave enough money for the book, eh :) You got it, money's kinda tight during the school year and we needed a car more than I needed a copy of Design Patterns. :-) So let me make sure I've understood things correctly so far. The options presented at this time are: 1) Wrapper library to various toolkit modules. 2) Predefined dialog modules for the various toolkits. 3) Picking a toolkit and sticking with it. And with all of those, an IPC mechanism for communicating settings changes from a separate process to E. Then the main E process will be responsible for handling updates of the db's on disk. Thoughts, opinions, and/or flames anyone? RbdPngn --------------------------------------------------------------------------- | Nathan Ingersoll | Computer Science/Mathematics | | mailto: ningerso@d.umn.edu | University of Minnesota-Duluth | | http://umn.edu/~ningerso | http://www.d.umn.edu | --------------------------------------------------------------------------- |
From: Christian K. <kre...@in...> - 2002-03-04 11:47:54
|
Nathan Ingersoll wrote: > > > My idea was to leave that > > up to each module. I'm not too familiar with Qt anymore (last work I did > > with it was before 2.0), but by putting these widget set event loops in > > a different process we should be able to work around that. We only need > > to send them a message "show dialog XYZ", and they'd send back the > > settings through a file descriptor that's hooked into our event loop. > > I agree that a separate process would be necessary to handle the event > loops cleanly. That brings up the issue of IPC with E. It seems like we should > establish the IPC protocol that e17 will use (if it hasn't already been > established) since these dialogs could make use of that, as well as allowing > for a new eesh. Yup. The following ipc scheme could work (see below): <piece of art> eesh efsd | / | / | / e17 ------------ dialog server | | | epplets </piece of art> > > Another thing is that it would be fairly easy for the predefined > > dialogs. But when epplets want to create custom dialogs, things will get > > a lot harder. > > This definitely makes things quite a bit harder. I wish I was more familiar > with the way Qt works in order to know what things are similar to gtk and ewl, > and what aren't. But I think it's safe to assume they share many of the same > properties (initialization function, main event loop, callbacks/signals, etc). I roughly remember how it works. They too use a signal/slot mechanism and roughly similar layout features. > If we want to provide facilities for epplets, it almost seems like a wrapper lib > would be the most effective way to do so. Basically, a simplified widget library > that accesses modules containing the code for the specific widget toolkit > backend. Yeah. The modules would contain the mappings to specific toolkits, the wrapper lib would use these mapping hooks for the actual implementations. > Although it could be quite a lot of work to create, I'm sure people > outside of the E community would love to see something like this as well, and > I'm rather surprised no one has written something like this yet. Yeah, me too. It was something that I expected to appear a long time ago. It's probably way to nervewrecking if you want to provide comprehensive features. I think we could try to come up with a minimal version first, for simple dialogs, and see how far we can get. It's an experiment, but hey, nobody can sue us, right :) If we manage to come up with something, it would be quite awesome. I guess we could keep it gtk style so the gtk mapping would be easy, the ewl mapping relatively easy and qt, well, for simple stuff it should be doable. Till's suggestion with the xml dialog descriptions is interesting, I wasn't aware that they're working on that. It would make *so* much sense to have that. I'm just not sure if we can get anything usable out of it at the moment. I guess you just resurrected my motivation for the whole idea :) > > HAHAHA and I guess the car didn't leave enough money for the book, eh :) > > You got it, money's kinda tight during the school year and we needed a car > more than I needed a copy of Design Patterns. :-) <hinthint> go to your nearest library, no need to buy it. If UMN's library doesn't have it, switch to a different Uni :) </hinthint> > So let me make sure I've understood things correctly so far. The options > presented at this time are: 1) Wrapper library to various toolkit modules. > 2) Predefined dialog modules for the various toolkits. 3) Picking a toolkit and > sticking with it. And with all of those, an IPC mechanism for communicating > settings changes from a separate process to E. Then the main E process will be > responsible for handling updates of the db's on disk. Yes. Basically, our wrapper library should allow creation of simple guis. A dialog server would be able to show dialogs for focus settings, window resize modes, view settings, the usual, and simple message dialogs. The settings in these dialogs and the clicked buttons are easy to encode in a string and can be sent back to e17 asynchronously (we don't want to make these dialogs modal anyway) and appear in the event loop. In order to receive messages from e17 ("show view settings dialog"), the gui wrapper lib would need to allow hooking arbitrary fds into the underlying event loop. Epplets on the other hand need a comms channel to e17 for the rendering on the evas, and would use the gui wrapper library for their config dialogs directly. It could actually even work :) Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: Reinaldo F. <fa...@re...> - 2002-03-04 12:56:57
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title></title> </head> <body> Hi all,<br> <br> <br> <br> One sugestion from this topic bellow.<br> <br> Christian Kreibich wrote:<br> <blockquote type="cite" cite="mid:3C8...@in..."> <pre wrap="">Nathan Ingersoll wrote:<br></pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">My idea was to leave that<br>up to each module. I'm not too familiar with Qt anymore (last work I did<br>with it was before 2.0), but by putting these widget set event loops in<br>a different process we should be able to work around that. We only need<br>to send them a message "show dialog XYZ", and they'd send back the<br>settings through a file descriptor that's hooked into our event loop.<br></pre> </blockquote> <pre wrap="">I agree that a separate process would be necessary to handle the event<br>loops cleanly. That brings up the issue of IPC with E. It seems like we should<br>establish the IPC protocol that e17 will use (if it hasn't already been<br>established) since these dialogs could make use of that, as well as allowing<br>for a new eesh.<br></pre> </blockquote> <pre wrap=""><!----><br>Yup. The following ipc scheme could work (see below):<br><br><piece of art><br><br> eesh efsd<br> | /<br> | /<br> | /<br> e17 ------------ dialog server<br> |<br> |<br> |<br> epplets <br><br></piece of art><br></pre> </blockquote> <sugestion><br> <br> What did you think about the dialog server is implemented using a http+xml *like* aproach? Some clients could be write using the widget engine talked before (ewl, gtk, qt etc).<br> <br> The interface could be sended to the clients using tcp-ip connections, and the callbacks of this interface be manipulated with a script language (ferite, javascript, perl, python etc) that be sended to the clients using the same method. Using this method several machines could be remote controlated, some securit issues need to be implemented (sandbox for the script language, authenticantion for the connection etc).<br> <br> Just a hint.<br> <br> </sugestion><br> <blockquote type="cite" cite="mid:3C8...@in..."> <pre wrap=""><br><br></pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">Another thing is that it would be fairly easy for the predefined<br>dialogs. But when epplets want to create custom dialogs, things will get<br>a lot harder.<br></pre> </blockquote> <pre wrap="">This definitely makes things quite a bit harder. I wish I was more familiar<br>with the way Qt works in order to know what things are similar to gtk and ewl,<br>and what aren't. But I think it's safe to assume they share many of the same<br>properties (initialization function, main event loop, callbacks/signals, etc).<br></pre> </blockquote> <pre wrap=""><!----><br>I roughly remember how it works. They too use a signal/slot mechanism<br>and roughly similar layout features.<br> <br></pre> <blockquote type="cite"> <pre wrap="">If we want to provide facilities for epplets, it almost seems like a wrapper lib<br>would be the most effective way to do so. Basically, a simplified widget library<br>that accesses modules containing the code for the specific widget toolkit<br>backend.<br></pre> </blockquote> <pre wrap=""><!----><br>Yeah. The modules would contain the mappings to specific toolkits, the<br>wrapper lib would use these mapping hooks for the actual<br>implementations.<br><br></pre> <blockquote type="cite"> <pre wrap="">Although it could be quite a lot of work to create, I'm sure people<br>outside of the E community would love to see something like this as well, and<br>I'm rather surprised no one has written something like this yet.<br></pre> </blockquote> <pre wrap=""><!----><br>Yeah, me too. It was something that I expected to appear a long time<br>ago. It's probably way to nervewrecking if you want to provide<br>comprehensive features. I think we could try to come up with a minimal<br>version first, for simple dialogs, and see how far we can get. It's an<br>experiment, but hey, nobody can sue us, right :) If we manage to come up<br>with something, it would be quite awesome.<br><br>I guess we could keep it gtk style so the gtk mapping would be easy, the<br>ewl mapping relatively easy and qt, well, for simple stuff it should be<br>doable.<br><br>Till's suggestion with the xml dialog descriptions is interesting, I<br>wasn't aware that they're working on that. It would make *so* much sense<br>to have that. I'm just not sure if we can get anything usable out of it<br>at the moment.<br> <br>I guess you just resurrected my motivation for the whole idea :)<br><br></pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">HAHAHA and I guess the car didn't leave enough money for the book, eh :)<br></pre> </blockquote> <pre wrap="">You got it, money's kinda tight during the school year and we needed a car<br>more than I needed a copy of Design Patterns. :-)<br></pre> </blockquote> <pre wrap=""><!----><br><hinthint> go to your nearest library, no need to buy it. If UMN's<br>library doesn't have it, switch to a different Uni :) </hinthint><br> <br></pre> <blockquote type="cite"> <pre wrap="">So let me make sure I've understood things correctly so far. The options<br>presented at this time are: 1) Wrapper library to various toolkit modules.<br>2) Predefined dialog modules for the various toolkits. 3) Picking a toolkit and<br>sticking with it. And with all of those, an IPC mechanism for communicating<br>settings changes from a separate process to E. Then the main E process will be<br>responsible for handling updates of the db's on disk.<br></pre> </blockquote> <pre wrap=""><!----><br>Yes. Basically, our wrapper library should allow creation of simple<br>guis. A dialog server would be able to show dialogs for focus settings,<br>window resize modes, view settings, the usual, and simple message<br>dialogs. The settings in these dialogs and the clicked buttons are easy<br>to encode in a string and can be sent back to e17 asynchronously (we<br>don't want to make these dialogs modal anyway) and appear in the event<br>loop. In order to receive messages from e17 ("show view settings<br>dialog"), the gui wrapper lib would need to allow hooking arbitrary fds<br>into the underlying event loop.<br><br>Epplets on the other hand need a comms channel to e17 for the rendering<br>on the evas, and would use the gui wrapper library for their config<br>dialogs directly.<br><br>It could actually even work :)<br><br>Christian.<br></pre> </blockquote> []'s<br> <div class="moz-signature">-- <br> <title>Signature</title> <meta http-equiv="content-type" content="text/html; "> <tt><br> .--------------------------------------. <br> | Reinaldo Faccio | <br> | COS Linux - Coordenador de Projetos | <br> `--------------------------------------' <br> </tt></div> <br> </body> </html> |
From: Christian K. <kre...@in...> - 2002-03-04 15:42:05
|
> Reinaldo Faccio wrote: > > What did you think about the dialog server is implemented using a > http+xml *like* aproach? Some clients could be write using the widget > engine talked before (ewl, gtk, qt etc). Could your background, by any chance, be related to soap or anything? :) Seriously though, "server" here doesn't mean network server. It's just a different process on the same machine as e17 that it talks to in order to get a dialog onscreen. There's really no need for what you're suggesting below... > The interface could be sended to the clients using tcp-ip connections, > and the callbacks of this interface be manipulated with a script > language (ferite, javascript, perl, python etc) that be sended to the That should be quite an ego booster for Bowwis -- ferite mentioned next to perl and python! Whoa! > clients using the same method. Using this method several machines > could be remote controlated, some securit issues need to be > implemented (sandbox for the script language, authenticantion for the > connection etc). > > Just a hint. Cheers, Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: kiuma <ki...@us...> - 2002-03-04 18:55:56
|
Christian Kreibich wrote: >>Reinaldo Faccio wrote: >> >>What did you think about the dialog server is implemented using a >>http+xml *like* aproach? Some clients could be write using the widget >>engine talked before (ewl, gtk, qt etc). >> > >Could your background, by any chance, be related to soap or anything? :) > >Seriously though, "server" here doesn't mean network server. It's just a >different process on the same machine as e17 that it talks to in order >to get a dialog onscreen. There's really no need for what you're >suggesting below... > >>The interface could be sended to the clients using tcp-ip connections, >>and the callbacks of this interface be manipulated with a script >>language (ferite, javascript, perl, python etc) that be sended to the >> > >That should be quite an ego booster for Bowwis -- ferite mentioned next >to perl and python! Whoa! > >>clients using the same method. Using this method several machines >>could be remote controlated, some securit issues need to be >>implemented (sandbox for the script language, authenticantion for the >>connection etc). >> >>Just a hint. >> > >Cheers, >Christian. > Ok, but if we decide to have a structure , a written plan , and we decide what we want to have from a widget would be shurely helpfull. We can ask evry time to a widget questions like "Who are you?" "What are you for?" whit a little code of xml, also if i'm using xml in the wrong manner. Infact what is really needed is DOM. Whit this we would be helped for example in integrating an application into another simply asking to it "What are you for?" , "How can I use you?", "Are you good for me?. And all this can be done runtime. Think for example to a menu bar and an db file. After aving loaded it. we could fill our menu and link to names our functions. We could also have a widget, a framebox for example, and we could load in it some module provided by others if 'compatible' then we could make our objects interact each others. |
From: Michael J. <e-...@ka...> - 2002-03-04 19:04:53
|
On Monday, 04 March 2002, at 19:56:00 (+0100), kiuma wrote: > We can ask evry time to a widget questions like "Who are you?" "What > are you for?" whit a little code of xml, also if i'm using xml in > the wrong manner. Those who do not learn from the mistakes of XML-RPC are doomed to repeat them. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <me...@ka...> n+1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "Unix is like a Vorlon: It is incredibly powerful, gives terse, cryptic answers, and has a lot of things going on in the background." -- Jeff Dubrule |
From: Chris b. R. <ch...@da...> - 2002-03-05 09:24:07
|
On Mon, Mar 04, 2002 at 04:36:45PM +0100, Christian Kreibich muttered... : > Reinaldo Faccio wrote: : > : > What did you think about the dialog server is implemented using a : > http+xml *like* aproach? Some clients could be write using the widget : > engine talked before (ewl, gtk, qt etc). : : Could your background, by any chance, be related to soap or anything? :) : : Seriously though, "server" here doesn't mean network server. It's just a : different process on the same machine as e17 that it talks to in order : to get a dialog onscreen. There's really no need for what you're : suggesting below... : : > The interface could be sended to the clients using tcp-ip connections, : > and the callbacks of this interface be manipulated with a script : > language (ferite, javascript, perl, python etc) that be sended to the : : That should be quite an ego booster for Bowwis -- ferite mentioned next : to perl and python! Whoa! Bah, that infers that my ego is small enough to get bigger =P But seriously, everyone knows that there has to be a decent scripting language from limey-land, I'm just hoping someone comes up with something before ferite =P : > clients using the same method. Using this method several machines : > could be remote controlated, some securit issues need to be : > implemented (sandbox for the script language, authenticantion for the : > connection etc). : > : > Just a hint. : : Cheers, : Christian. : -- Regards, Chris -- +------------------------------------------------------------------+ | Chris Ross | ch...@da... | ct...@fe... | | | http://www.darkrock.co.uk | http://www.ferite.org | +------------------------------------------------------------------+ "Don't forget to close your eyes when reading a scary book" |
From: Christian K. <kre...@in...> - 2002-03-05 09:34:50
|
Chris boris Ross wrote: > > Bah, that infers that my ego is small enough to get bigger =P But seriously, HAHAHAHA :) Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: Nathan I. <ningerso@d.umn.edu> - 2002-03-04 15:55:24
|
On Mon, Mar 04, 2002 at 12:38:43PM +0100, Christian Kreibich is quoted as saying: > Yup. The following ipc scheme could work (see below): > > <piece of art> > > eesh efsd > | / > | / > | / > e17 ------------ dialog server > | > | > | > epplets > > </piece of art> This seems like a logical layout to me. Although I had seen some conversation on IRC indicating a possible split of the file manager and window manager into separate processes. That might change the diagram slightly if things go that route. > Yeah, me too. It was something that I expected to appear a long time > ago. It's probably way to nervewrecking if you want to provide > comprehensive features. I think we could try to come up with a minimal > version first, for simple dialogs, and see how far we can get. It's an > experiment, but hey, nobody can sue us, right :) If we manage to come up > with something, it would be quite awesome. I think providing anything beyond a basic UI would be horrific to maintain. Every time you added a feature, each module maintainer would have to add support to their module. Plus each added feature would have to be designed with some idea of how the underlying modules will handle it. > I guess we could keep it gtk style so the gtk mapping would be easy, the > ewl mapping relatively easy and qt, well, for simple stuff it should be > doable. I agree with this, but we may want to dumb things down even more than the gtk style initially. One thing I had in mind was the ability to only bind callbacks to 1 type of event per widget. So you could get info about value changes or button presses, but not be able to do anything really complicated. > Till's suggestion with the xml dialog descriptions is interesting, I > wasn't aware that they're working on that. It would make *so* much sense > to have that. I'm just not sure if we can get anything usable out of it > at the moment. I agree, while an xml description file could be ideal, but we would have to ai at a description format that has not even been decided upon yet. > Yes. Basically, our wrapper library should allow creation of simple > guis. A dialog server would be able to show dialogs for focus settings, > window resize modes, view settings, the usual, and simple message > dialogs. The settings in these dialogs and the clicked buttons are easy > to encode in a string and can be sent back to e17 asynchronously (we > don't want to make these dialogs modal anyway) and appear in the event > loop. In order to receive messages from e17 ("show view settings > dialog"), the gui wrapper lib would need to allow hooking arbitrary fds > into the underlying event loop. Sounds good to me. We could also make these individual epplets rather than one dialog server. Either way seems reasonable to me. > Epplets on the other hand need a comms channel to e17 for the rendering > on the evas, and would use the gui wrapper library for their config > dialogs directly. > > It could actually even work :) Seems like we've got a good outline of what needs to happen. Now the question is, who wants to work on this? Seems like an interesting project, but I know most of the active developers, including myself, are pretty busy already. --------------------------------------------------------------------------- | Nathan Ingersoll | Computer Science/Mathematics | | mailto: ningerso@d.umn.edu | University of Minnesota-Duluth | | http://umn.edu/~ningerso | http://www.d.umn.edu | --------------------------------------------------------------------------- |
From: Yuri H. <yl...@ya...> - 2002-03-04 23:55:20
|
Hi, Most of us have OpenGL videocards and all of us have evas installed, haven't we? :) Some of you have pocket PCs. E-widgets may be quite different than other's. If current congif tool is tab-based it may look like Entice, with tabs on left side and Ok/Apply/Close on above. With thumbnails of the apropriate pages fading-in on MOUSE_IN ;) Or, one panel with 2x2 or 3x3 zoomed out config areas, zooming in on mouse click. Of course, it is very difficult to innovate something to "Are you sure to logout Yes/No". If widget set includes only labels, separator, 3 types of buttons, and editbox, there's nothing to improve too :) Otherwise -- ghosty toolbar, translucent statusbar, spinbutton with additional information, cool-animated menus and comboboxes ;) I want to say that working area may be widen using scalling and animating abilities of Evas&Co. Bye! ------ Sincerely yours' glassy _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: <Val...@vt...> - 2002-03-05 04:04:41
|
On Tue, 05 Mar 2002 04:56:59 +0500, Yuri Hudobin <yl...@ya...> said: > Otherwise -- ghosty toolbar, translucent statusbar, spinbutton with Good user interface design requires *legibility*. This may or may not be the case for 'ghosty/translucent'. Quite often, what "looks cool" will drive you totally batshit after several days of use. ;) -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech |
From: Chris b. R. <ch...@da...> - 2002-03-05 09:21:48
|
On Mon, Mar 04, 2002 at 11:04:36PM -0500, Val...@vt... muttered... : On Tue, 05 Mar 2002 04:56:59 +0500, Yuri Hudobin <yl...@ya...> said: : : > Otherwise -- ghosty toolbar, translucent statusbar, spinbutton with : : Good user interface design requires *legibility*. This may or may not : be the case for 'ghosty/translucent'. Quite often, what "looks cool" : will drive you totally batshit after several days of use. ;) Wow, I haven't heard the term 'batshit' in ages. Thanks for making me chuckle :) Regards, Chris -- +------------------------------------------------------------------+ | Chris Ross | ch...@da... | ct...@fe... | | | http://www.darkrock.co.uk | http://www.ferite.org | +------------------------------------------------------------------+ "Don't forget to close your eyes when reading a scary book" |
From: Till A. <ti...@ad...> - 2002-03-03 09:39:02
|
# Quoting Christian Kreibich (kre...@in...): > You're welcome of course to speak up if you like > it, too :) Chalk one up for Aye. > So, here it comes: can't we use dynamically loaded modules that follow > the handle-envelope or bridge pattern, and that provide entry points > like show_view_settings(), show_focus_settings() etc, and that > themselves use qt, gtk, or ewl? It would save us all the hassle of doing > these things ourselves, the result would be more integrated, and people > don't get the impression of using yet another heterogeneous component on > their system. Hm, glade/gtk has the possibility to provide widget layouts as xml files (*GASP* I've said the acronym from hell ;), which are parsed at runtime and which the dialog is then assembled from. QT has a similar mechanism, I believe, and I am pretty sure to have read about a unified dialog description format the two teams are in the process of agreeing upon. Correct me if I'm wrong here. I've used libglade in the past to build prototypes with the python bindings and I can attest that it works. I dont know about the qt stuff, but I trust the trolls to not produce utter manure. Would that be a road worth investigating? EWL would need to have a similar mechanism, but then we could define all our dialogs once in an xml file and have the three widget sets parse that. If speed is an issue (and in my experience it isnt) they can always be compiled to binaries and shipped as that. Till |
From: Christopher 's. R. <cro...@no...> - 2002-03-03 12:56:54
|
Till Adam wrote on Sun, Mar 03, 2002 at 10:18:33AM +0100 > # Quoting Christian Kreibich (kre...@in...): > > > You're welcome of course to speak up if you like > > it, too :) > > Chalk one up for Aye. > > > So, here it comes: can't we use dynamically loaded modules that follow > > the handle-envelope or bridge pattern, and that provide entry points > > like show_view_settings(), show_focus_settings() etc, and that > > themselves use qt, gtk, or ewl? It would save us all the hassle of doing > > these things ourselves, the result would be more integrated, and people > > don't get the impression of using yet another heterogeneous component on > > their system. > > Hm, glade/gtk has the possibility to provide widget layouts as xml > files (*GASP* I've said the acronym from hell ;), which are parsed at > runtime and which the dialog is then assembled from. QT has a similar > mechanism, I believe, and I am pretty sure to have read about a unified > dialog description format the two teams are in the process of agreeing upon. > Correct me if I'm wrong here. > > I've used libglade in the past to build prototypes with the python > bindings and I can attest that it works. I dont know about the qt stuff, > but I trust the trolls to not produce utter manure. Would that be a road > worth investigating? > > EWL would need to have a similar mechanism, but then we could define all > our dialogs once in an xml file and have the three widget sets parse > that. If speed is an issue (and in my experience it isnt) they can > always be compiled to binaries and shipped as that. Hmm, reading this thread is interesting. This would be very cool to have in EWL but i think it would be easier make the EWL theme engine handle GTK+ themes and QT themes instead. I think that way would save alot of effort. Nathan and i have had some thoughts about writing a glade similiar application for EWL, i think it should save its files using EDB rather then XML, but i wouldn't mind that application being able to read .glade files. I know QT has a similiar application also, a friend of mine showed me it a couple of weeks ago, it wouldn't be a bad idea to be able to generate source code from its project files as well. I think making EWL able to read GTK+ & QT themes instead of rather making it wrap GTK+ & QT methods, would save a lot extra overhead. I might be totally wrong, haven't really done anything like this before, what's your opinions ? |
From: Chris b. R. <ch...@da...> - 2002-03-03 17:23:18
|
On Sun, Mar 03, 2002 at 01:56:01PM +0100, Christopher 'smugg' Rosendahl muttered... [snip] : : Hmm, reading this thread is interesting. This would be very cool to have in EWL : but i think it would be easier make the EWL theme engine handle GTK+ themes : and QT themes instead. I think that way would save alot of effort. : : Nathan and i have had some thoughts about writing a glade similiar application : for EWL, i think it should save its files using EDB rather then XML, but : i wouldn't mind that application being able to read .glade files. : I know QT has a similiar application also, a friend of mine showed me it a : couple of weeks ago, it wouldn't be a bad idea to be able to generate source : code from its project files as well. : : I think making EWL able to read GTK+ & QT themes instead of rather making it : wrap GTK+ & QT methods, would save a lot extra overhead. I believe the idea is not to have it wrap Qt and gtk+ but to have it such that there is a gerneral configutation plugin system where a plugin can be written for ewl, Qt and gtk+ so that the end user of e17 can choose what look they want.... : I might be totally wrong, haven't really done anything like this before, : what's your opinions ? Regards, Chris -- +------------------------------------------------------------------+ | Chris Ross | ch...@da... | ct...@fe... | | | http://www.darkrock.co.uk | http://www.ferite.org | +------------------------------------------------------------------+ "One lawyer can steal more than a hundred men with guns." |
From: Christian K. <kre...@in...> - 2002-03-03 19:07:18
|
trashcan man wrote: > > On Sat, Mar 02, 2002 at 11:33:23PM +0100, Christian Kreibich wrote: > > To be honest, I think staying neutral by doing our own thing is stupid. > > The one thing I want more than anything from my desktop is look > > integrated. I almost exclusively use Gtk/Gnome apps, others are using > > KDE, but everybody would certainly like it best if e17's dialogs and > > tools would show up in the same familiar GUI style they're seeing in all > > their other apps, with all their benefits. Frankly, if we would use ewl > > why not create ewl-backed gtk engine? That doesn't solve my problem -- I'd like to be able to support both gtk and qt and ideally ewl, so that the user can pick his choice. The more I think about the whole thing, the more problems I see, though. The best I can imagine right now is a thin and very restricted abstraction layer over the toolkits we want to support, basically just for putting together simple dialogs. It would need the ability to hook in arbitrary file descriptors into the underlying event loop. Then, epplets could use this abstraction api directly for their own event loop, and e17 could talk to a "dialog server" in a different process through ipc, this dialog server could then use its own event loop and send back and forth the settings in each dialog when they get updated. Although it sounds interesting to me, it'll be a lot of work, and frankly I'm not sure if it should be anywhere near the top of our todo list. Damn, sometimes I'm so tired of the "freedom of choice" in Linux. Cheers, Christian. -- ________________________________________________________________________ http://www.whoop.org |
From: Boris B. <bo...@ic...> - 2002-03-05 10:24:44
|
I'm working on my own desktop, called JEDI, based on evas and ecore. I also had the idea to have some kind of wrapper, which wraps Qt, Gtk and ewl, a bit like SDL, which uses DirectX on Windoze and native Linux code on Linux. So, I like the idea, because I wanted to do something similar in the near future. If you gonna do it, I would certainly help. -- Boris Buegling <bo...@ic...> "Sleep less - live longer." - "Ok good, 1 down... Now all I need is beer, video games and hacking to be linked to living longer and I'm set." |