From: Christian K. <kre...@in...> - 2001-11-07 11:08:35
|
Hi, this one is going out to the ewl developers. I've loosely followed the commits so far, and there's one thing I don't understand -- it seems you're making a lot of effort to do things the same way as gtk. However, you rewrite everything as a new lib. Why don't you try to make things gtk compatible, i.e. for now provide subsets of the gtk api that would be enough to make simple gtk apps compile when using ewl? I admire the energy you put into this, I just don't think the world needs yet another widget set api. Regards, -- Christian. ________________________________________________________________________ http://www.whoop.org |
From: Christian K. <kre...@in...> - 2001-11-08 10:51:51
|
xworm wrote: > > I agree with you on this one, but i remember them saying sth like that > it would be easier and a lot cleaner if they made a new api from scratch. Really? Cleaner? Why? > Still it would be a lot more interesting the way you say. :) It would make a lot more sense, too :) -- Christian. ________________________________________________________________________ http://www.whoop.org |
From: Lyle K. <te...@ke...> - 2001-11-08 16:10:14
|
* Christian Kreibich (kre...@in...) wrote: > > I agree with you on this one, but i remember them saying sth like that > > it would be easier and a lot cleaner if they made a new api from scratch. > Really? Cleaner? Why? I could understand why the design would be cleaner.. you're not trying to mimic the functionality of another API, bug-for-bug etc. Trying to map one way of handling stuff to another is rarely simple internally.. Not that I disagree with what you've said (which I've already told you :).. I think it'd be tremendously useful as an alternative to using gtk itself, but not as a stand-alone toolkit. It doesn't appear to offer any new functionality at the application level.. term |
From: Christian K. <kre...@in...> - 2001-11-08 16:43:15
|
Lyle Kempler wrote: > > * Christian Kreibich (kre...@in...) wrote: > > > I agree with you on this one, but i remember them saying sth like that > > > it would be easier and a lot cleaner if they made a new api from scratch. > > Really? Cleaner? Why? > > I could understand why the design would be cleaner.. you're not trying > to mimic the functionality of another API, bug-for-bug etc. Trying to > map one way of handling stuff to another is rarely simple internally.. Oh, right. I read that in the sense of using the new api would be a lot easier and cleaner. Internally, no doubt, it might be hard to map things to the way Evas handles things. Not necessarily, though. Cheers, -- Christian. ________________________________________________________________________ http://www.whoop.org |
From: Nathan I. <ningerso@d.umn.edu> - 2001-11-08 17:31:38
|
On Wed Nov 07, 2001 at 12:08:45PM +0100, Christian Kreibich is quoted as saying: > > Hi, > > this one is going out to the ewl developers. I've loosely followed the > commits so far, and there's one thing I don't understand -- it seems > you're making a lot of effort to do things the same way as gtk. However, > you rewrite everything as a new lib. Why don't you try to make things > gtk compatible, i.e. for now provide subsets of the gtk api that would > be enough to make simple gtk apps compile when using ewl? Actually, we haven't made that much effort to do things like gtk, in fact that's only half intentional. We wanted to make an API that was similar enough to an existing one that people could pick it up easily, but we wanted freedom to change the API in ways we thought would be easier to use/understand. The main similarities to gtk have developed because it was a common widget library that smugg and I were both familiar with before starting ewl. > I admire the energy you put into this, I just don't think the world > needs yet another widget set api. > > Regards, > -- Christian. > ________________________________________________________________________ > http://www.whoop.org Well, I personally don't see the harm in another widget set api, especially one that is well documented (which we're not yet, but it's coming along). If the api uses similar concepts to existing api's it shouldn't be difficult to pick up. I guess that I prefer having a level of freedom in developing the api for ewl, but smugg and I have discussed adding some compatibility wrappers to a subset of the gtk api. There are some details/issues that need to be worked out first. There is a pretty close correlation between gtk calls and ewl calls so porting apps should be fairly simple, but the wrapper would ease the process. --------------------------------------------------------------------------- | Nathan Ingersoll | Computer Science/Mathematics | | mailto: ningerso@d.umn.edu | University of Minnesota-Duluth | | http://umn.edu/~ningerso | http://www.d.umn.edu | --------------------------------------------------------------------------- |
From: <be...@cu...> - 2001-11-08 20:01:55
|
Just to throw another log on the fire.... I personally really enjoy using EWL. It is missing acouple things (namely a file selection widget) but its really easy to use, jives with much of the other libs ('cept IMLIB2, but...) and is something we can call our own. On top of that, being able to make changes to our own toolkit is very convient... GTK doesn't allow us that flexablility without a fork. But this is just my unimportant and humble opinion. I haven't really cared to do any coding for months, and EWL is alot of fun to me, so I'm enjoying it, if for no other reason, for the enjoyment of it. dats my 2 penz. benr. > On Wed Nov 07, 2001 at 12:08:45PM +0100, Christian Kreibich is quoted > as saying: >> >> Hi, >> >> this one is going out to the ewl developers. I've loosely followed the >> commits so far, and there's one thing I don't understand -- it seems >> you're making a lot of effort to do things the same way as gtk. >> However, you rewrite everything as a new lib. Why don't you try to >> make things gtk compatible, i.e. for now provide subsets of the gtk >> api that would be enough to make simple gtk apps compile when using >> ewl? > > Actually, we haven't made that much effort to do things like gtk, in > fact that's only half intentional. We wanted to make an API that was > similar enough to an existing one that people could pick it up easily, > but we wanted freedom to change the API in ways we thought would be > easier to use/understand. The main similarities to gtk have developed > because it was a common widget library that smugg and I were both > familiar with before starting ewl. > >> I admire the energy you put into this, I just don't think the world >> needs yet another widget set api. >> >> Regards, >> -- Christian. >> ________________________________________________________________________ >> http://www.whoop.org > > Well, I personally don't see the harm in another widget set api, > especially one that is well documented (which we're not yet, but it's > coming along). If the api uses similar concepts to existing api's it > shouldn't be difficult to pick up. > > I guess that I prefer having a level of freedom in developing the api > for ewl, but smugg and I have discussed adding some compatibility > wrappers to a subset of the gtk api. There are some details/issues that > need to be worked out first. There is a pretty close correlation > between gtk calls and ewl calls so porting apps should be fairly > simple, but the wrapper would ease the process. > > ---------------------------------------------------------------------------> | 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 |
From: Derick J.F. <de...@xe...> - 2001-11-08 21:05:58
|
i eat EWL for breakfast, tastes great :). and the fact that the calls are similar to GTK makes it easy to digest. peace, derick ----- Original Message ----- From: <be...@cu...> To: <ningerso@d.umn.edu> Cc: <enl...@li...> Sent: Thursday, November 08, 2001 11:40 AM Subject: Re: [E-devel] About ewl. > Just to throw another log on the fire.... I personally really enjoy using > EWL. It is missing acouple things (namely a file selection widget) but its > really easy to use, jives with much of the other libs ('cept IMLIB2, but...) > and is something we can call our own. On top of that, being able to make > changes to our own toolkit is very convient... GTK doesn't allow us that > flexablility without a fork. > > But this is just my unimportant and humble opinion. I haven't really cared > to do any coding for months, and EWL is alot of fun to me, so I'm enjoying > it, if for no other reason, for the enjoyment of it. > > dats my 2 penz. > > benr. > > > > On Wed Nov 07, 2001 at 12:08:45PM +0100, Christian Kreibich is quoted > > as saying: > >> > >> Hi, > >> > >> this one is going out to the ewl developers. I've loosely followed the > >> commits so far, and there's one thing I don't understand -- it seems > >> you're making a lot of effort to do things the same way as gtk. > >> However, you rewrite everything as a new lib. Why don't you try to > >> make things gtk compatible, i.e. for now provide subsets of the gtk > >> api that would be enough to make simple gtk apps compile when using > >> ewl? > > > > Actually, we haven't made that much effort to do things like gtk, in > > fact that's only half intentional. We wanted to make an API that was > > similar enough to an existing one that people could pick it up easily, > > but we wanted freedom to change the API in ways we thought would be > > easier to use/understand. The main similarities to gtk have developed > > because it was a common widget library that smugg and I were both > > familiar with before starting ewl. > > > >> I admire the energy you put into this, I just don't think the world > >> needs yet another widget set api. > >> > >> Regards, > >> -- Christian. > >> ________________________________________________________________________ > >> http://www.whoop.org > > > > Well, I personally don't see the harm in another widget set api, > > especially one that is well documented (which we're not yet, but it's > > coming along). If the api uses similar concepts to existing api's it > > shouldn't be difficult to pick up. > > > > I guess that I prefer having a level of freedom in developing the api > > for ewl, but smugg and I have discussed adding some compatibility > > wrappers to a subset of the gtk api. There are some details/issues that > > need to be worked out first. There is a pretty close correlation > > between gtk calls and ewl calls so porting apps should be fairly > > simple, but the wrapper would ease the process. > > > > -------------------------------------------------------------------------- -> | 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 > > > > > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > |
From: Christopher 's. R. <cro...@no...> - 2001-11-09 18:46:09
|
Christian Kreibich wrote on Wed, Nov 07, 2001 at 12:08:45PM +0100 > > Hi, > > this one is going out to the ewl developers. I've loosely followed the > commits so far, and there's one thing I don't understand -- it seems > you're making a lot of effort to do things the same way as gtk. However, > you rewrite everything as a new lib. Why don't you try to make things > gtk compatible, i.e. for now provide subsets of the gtk api that would > be enough to make simple gtk apps compile when using ewl? > > I admire the energy you put into this, I just don't think the world > needs yet another widget set api. > > Regards, > -- Christian. I think it's good that you brought this up, it's not really something we have clarified quite yet, and it's about time it gets done =) The main reason we started working on EWL was because we want a unique look to E that no other WM has so far. With evas this is done really easily, and then with evas we can have these kick-ass effects no other widget sets offers. Sure there are alot of widget sets out there, but actually there's none that offer what EWL does. Some of the features in the pipeline right now are pluggable fx, floating widgets (that allow arbitary positioning and transparency), as well as improvements to the current theme engine. Creating a subset api of gtk compatible calls would take a lot of effort to be of much use to more than the most simple apps. Apps that simple could easily be ported. And even if we got this done we woudln't get the result of what we really want. |
From: Christian K. <kre...@in...> - 2001-11-09 20:11:18
|
Christopher 'smugg' Rosendahl wrote: > > The main reason we started working on EWL was because we want a unique > look to E that no other WM has so far. With evas this is done really > easily, and then with evas we can have these kick-ass effects no other > widget sets offers. > > Sure there are alot of widget sets out there, but actually there's none > that offer what EWL does. Some of the features in the pipeline right now are > pluggable fx, floating widgets (that allow arbitary positioning and > transparency), as well as improvements to the current theme engine. That's all cool, really. Notice I said "another widget set api", I'm just worried about the api. You can definitely do fun stuff on top of Evas. > Creating a subset api of gtk compatible calls would take a lot of effort to > be of much use to more than the most simple apps. Apps that simple could > easily be ported. And even if we got this done we woudln't get the > result of what we really want. Mhmmm well you probably know this better than I because I haven't tried writing a widget set. But by saying that its easy to port gtk apps you multiply the amount of work necessary by orders of magnitude -- instead of you investing a lot of effort, you ask every single developer who wants an app to work with ewl to do the porting. I guess a wrapper library sounds like the way to go here... Cheers, -- Christian. ________________________________________________________________________ http://www.whoop.org |
From: Christopher 's. R. <cro...@no...> - 2001-11-09 23:36:08
|
Christian Kreibich wrote on Fri, Nov 09, 2001 at 09:10:49PM +0100 > Christopher 'smugg' Rosendahl wrote: > > > > The main reason we started working on EWL was because we want a unique > > look to E that no other WM has so far. With evas this is done really > > easily, and then with evas we can have these kick-ass effects no other > > widget sets offers. > > > > Sure there are alot of widget sets out there, but actually there's none > > that offer what EWL does. Some of the features in the pipeline right now are > > pluggable fx, floating widgets (that allow arbitary positioning and > > transparency), as well as improvements to the current theme engine. > > That's all cool, really. Notice I said "another widget set api", I'm > just worried about the api. You can definitely do fun stuff on top of > Evas. yeah =) > > Creating a subset api of gtk compatible calls would take a lot of effort to > > be of much use to more than the most simple apps. Apps that simple could > > easily be ported. And even if we got this done we woudln't get the > > result of what we really want. > > Mhmmm well you probably know this better than I because I haven't tried > writing a widget set. But by saying that its easy to port gtk apps you > multiply the amount of work necessary by orders of magnitude -- instead > of you investing a lot of effort, you ask every single developer who > wants an app to work with ewl to do the porting. I'm not saying it's easy too port every single application out there but for the less complex applications i'm saying it's not hard. Porting applications like mozilla or gimp would demand a whole lot of work. Prehaps i shouldnt have said it would be easy to port applications like that because when i think about it some more it requires a whole lot of work. > I guess a wrapper library sounds like the way to go here... Yeah that would probably be the best solution, but still it would requires a whole lot of work. But sometime in the future when the EWL API becomes a bit more consistent i could spend some time on doing that. |