From: Brian M. <bri...@gm...> - 2007-01-16 23:15:38
|
After a few weeks of spare-time development, I'd like to announce Efreet, a new implementation of the XDG (freedesktop) specs for Icons, Menus and Desktop Entries. The current implementation, Ecore_Desktop, while a commendable effort for a sole developer under time constraints, leaves a bit to be desired. So, dj2 and I started reading through the xdg specs, and playing around with our own implementation, code named Efreet. After speaking with onefang about some of the issues with ecore_desktop, he said it was due for a rewrite, so we continuted with our replacement implementation. Rbdpngn and Engelbass also pitched in. Currently we have code to build menus, find icons, and load desktop entries complete. There are a few things left to finish (most importatnly executing desktop entries), but it is almost at a point where we'd like to start integrating it in to e17. The code, for those interested, is available from subversion at: http://everburning.com/svn/efreet Before we hook e17 in to efreet, there are a few issues I'd like to bring up. E currently uses a hands off 'read only' approach to the XDG structure, copying the structure in to the format that e previously used (.order files). This made sense given ecore_desktops roots as an addon program that simply connected the two. But, since we're already going to be loading up the xdg menu format, is there any reason to not just use that directly? This would have the added benefit that as apps are added through a package manager, they would just show up in the menu as they do in every other desktop (without having to go to config > application menus > Regenerate / Update "Applications" Menu). The next question is, assuming you guys see it as a viable replacement for ecore_desktop, do we stick this somewhere in libs (as efreet or e_xdg, or whatever name) or do we cram it in to ecore? My vote is that we stop bloating ecore in the name of a 'dependency freeze' and keep proper separation of libraries. (Its all 'new code' that needs to be verified and tested regardless of where we stick it). Let us know what you guys think. rephorm |
From: Jorge L. Z. M. <jor...@gm...> - 2007-01-17 00:14:31
|
On 1/17/07, Brian Mattern <bri...@gm...> wrote: >.... > > The next question is, assuming you guys see it as a viable replacement > for ecore_desktop, do we stick this somewhere in libs (as efreet or > e_xdg, or whatever name) or do we cram it in to ecore? My vote is that > we stop bloating ecore in the name of a 'dependency freeze' and keep > proper separation of libraries. (Its all 'new code' that needs to be > verified and tested regardless of where we stick it). > > Let us know what you guys think. > Indeed, i agree here. Better make it away from ecore, ecore already has too many (unrelated?) things inside. turran > 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.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > |
From: Peter P. <pet...@gm...> - 2007-01-17 14:09:29
|
On Wednesday 17 January 2007 01:14, Jorge Luis Zapata Muga wrote: > On 1/17/07, Brian Mattern <bri...@gm...> wrote: > >.... > > > > The next question is, assuming you guys see it as a viable replacement > > for ecore_desktop, do we stick this somewhere in libs (as efreet or > > e_xdg, or whatever name) or do we cram it in to ecore? My vote is that > > we stop bloating ecore in the name of a 'dependency freeze' and keep > > proper separation of libraries. (Its all 'new code' that needs to be > > verified and tested regardless of where we stick it). > > > > Let us know what you guys think. > > Indeed, i agree here. Better make it away from ecore, ecore already > has too many (unrelated?) things inside. > > turran I'd argue on that topic. I think it should go to either ecore or e17. The reason: I don't think any app but e uses the freedesktop menu, or if they do so, they depend on e itself. It would be just a mess in the now well-structured dependency tree if we had to compile another lib, which only does one thing, and only one app uses it. And ecore? Well ecore is what its name sais: core library for efl(not just e17). And if there are already fdo stuff in it, and this would be a replacement for that, why don't you really replace it, inside ecore? Peter. > > > 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.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > enlightenment-devel mailing list > > enl...@li... > > 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.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel |
From: Peter P. <me...@rh...> - 2007-01-17 14:41:26
|
On Wednesday 17 January 2007 15:15, you wrote: > On Wednesday 17 January 2007 01:14, Jorge Luis Zapata Muga wrote: > > On 1/17/07, Brian Mattern <bri...@gm...> wrote: > > >.... > > > > > > The next question is, assuming you guys see it as a viable replacement > > > for ecore_desktop, do we stick this somewhere in libs (as efreet or > > > e_xdg, or whatever name) or do we cram it in to ecore? My vote is that > > > we stop bloating ecore in the name of a 'dependency freeze' and keep > > > proper separation of libraries. (Its all 'new code' that needs to be > > > verified and tested regardless of where we stick it). > > > > > > Let us know what you guys think. > > > > Indeed, i agree here. Better make it away from ecore, ecore already > > has too many (unrelated?) things inside. > > > > turran I'd argue on that topic. I think it should go to either ecore or e17. The reason: I don't think any app but e uses the freedesktop menu, or if they do so, they depend on e itself. It would be just a mess in the now well-structured dependency tree if we had to compile another lib, which only does one thing, and only one app uses it. And ecore? Well ecore is what its name sais: core library for efl(not just e17). And if there are already fdo stuff in it, and this would be a replacement for that, why don't you really replace it, inside ecore? Peter. > > I'd argue on that topic. I think it should go to either ecore or e17. The > reason: I don't think any app but e uses the freedesktop menu, or if they > do so, they depend on e itself. > > It would be just a mess in the now well-structured dependency tree if we > had to compile another lib, which only does one thing, and only one app > uses it. And ecore? Well ecore is what its name sais: core library for > efl(not just e17). And if there are already fdo stuff in it, and this would > be a replacement for that, why don't you really replace it, inside ecore? > > Peter. > > > > 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.php&p=sourceforge&CID=DEVD > > >EV _______________________________________________ > > > enlightenment-devel mailing list > > > enl...@li... > > > 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.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > enlightenment-devel mailing list > > enl...@li... > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel |
From: dan s. <ze...@pe...> - 2007-01-17 14:50:23
|
Peter Parkanyi wrote: > On Wednesday 17 January 2007 15:15, you wrote: >> On Wednesday 17 January 2007 01:14, Jorge Luis Zapata Muga wrote: >> > On 1/17/07, Brian Mattern <bri...@gm...> wrote: >> > >.... >> > > >> > > The next question is, assuming you guys see it as a viable replacement >> > > for ecore_desktop, do we stick this somewhere in libs (as efreet or >> > > e_xdg, or whatever name) or do we cram it in to ecore? My vote is that >> > > we stop bloating ecore in the name of a 'dependency freeze' and keep >> > > proper separation of libraries. (Its all 'new code' that needs to be >> > > verified and tested regardless of where we stick it). >> > > >> > > Let us know what you guys think. >> > >> > Indeed, i agree here. Better make it away from ecore, ecore already >> > has too many (unrelated?) things inside. >> > >> > turran > > I'd argue on that topic. I think it should go to either ecore or e17. The > reason: I don't think any app but e uses the freedesktop menu, or if they do > so, they depend on e itself. > > It would be just a mess in the now well-structured dependency tree if we had > to compile another lib, which only does one thing, and only one app uses it. > And ecore? Well ecore is what its name sais: core library for efl(not just > e17). And if there are already fdo stuff in it, and this would be a > replacement for that, why don't you really replace it, inside ecore? > Efreet is more then just menus. It also contains the icon theme code which is used in Ewl. Any other app that want's to use the icons from a given icon theme could use Efreet as well. Along with that, this _isn't_ core functionality that every app needs. Why should we stuff it into Ecore when it doesn't really fit? Compiling one more lib isn't that difficult and doesn't confuse anything. Along with that, what if someone wants to write a menu editor? They'll need access to the fdo menu code as well. If it's stuck inside e17 then they have to build it inside e17. Not an optimal solution. dan |
From: Essien I. E. <es...@wa...> - 2007-01-17 15:00:51
|
Peter Parkanyi wrote: > On Wednesday 17 January 2007 15:15, you wrote: > >> On Wednesday 17 January 2007 01:14, Jorge Luis Zapata Muga wrote: >> >>> On 1/17/07, Brian Mattern <bri...@gm...> wrote: >>> >>>> .... >>>> >>>> The next question is, assuming you guys see it as a viable replacement >>>> for ecore_desktop, do we stick this somewhere in libs (as efreet or >>>> e_xdg, or whatever name) or do we cram it in to ecore? My vote is that >>>> we stop bloating ecore in the name of a 'dependency freeze' and keep >>>> proper separation of libraries. (Its all 'new code' that needs to be >>>> verified and tested regardless of where we stick it). >>>> >>>> Let us know what you guys think. >>>> >>> Indeed, i agree here. Better make it away from ecore, ecore already >>> has too many (unrelated?) things inside. >>> >>> turran >>> > > I'd argue on that topic. I think it should go to either ecore or e17. The > reason: I don't think any app but e uses the freedesktop menu, or if they do > so, they depend on e itself. > errr*** Entrance Does. And it doesn't depend on E. > It would be just a mess in the now well-structured dependency tree if we had > to compile another lib, which only does one thing, and only one app uses it. > And ecore? Well ecore is what its name sais: core library for efl(not just > e17). And if there are already fdo stuff in it, and this would be a > replacement for that, why don't you really replace it, inside ecore? > I agree with replacing Ecore_Desktop if it cleanly solves the problems. No need for backward compatibility with Ecore_Desktop, since there's not much apps written for it yet. Efreet could just start life in cvs/proto/Ecore_Desktop2 for now, and (assuming we're all on the same page), become Ecore_Desktop as it matures. The argument for putting libraries into Ecore, is actually a pragmatic IMOHO one. When its *easier* for the developer to know that everything is provided by a *major* provider (like glibc is all you need for *most* *basic* UNIX programs). If you're developing a basic EFL application (the 70% case I'm assuming), you should need only do 3 things. 1. Choose b/w ETK and EWL 2. build against Ecore 3. Build against your application domain specific libraries It will make learning and developign for the EFL a matter of knowing Ecore for the most part and if you wanna do funkier stuff, then EVAS, Engrave, etc. Or maybe I'm actually meta-thinking about a lib that should be called libefl. I do understand the need for small and targetted, resulting in cleaner and better implementations, but a modular approach could work wonders (it seems ecore already does this? where you can build against parts of Ecore instead of the whole of Ecore). The code base itself, could be a main project itself like E17, ETK, EWL, EFL, etc... anyways... i'm ranting now. just my 2 kobo[1] Cheers, Essien [1] Kobo is like Cents in Nigeria :) > Peter. > > >> I'd argue on that topic. I think it should go to either ecore or e17. The >> reason: I don't think any app but e uses the freedesktop menu, or if they >> do so, they depend on e itself. >> >> It would be just a mess in the now well-structured dependency tree if we >> had to compile another lib, which only does one thing, and only one app >> uses it. And ecore? Well ecore is what its name sais: core library for >> efl(not just e17). And if there are already fdo stuff in it, and this would >> be a replacement for that, why don't you really replace it, inside ecore? >> >> Peter. >> >> >>>> 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.php&p=sourceforge&CID=DEVD >>>> EV _______________________________________________ >>>> enlightenment-devel mailing list >>>> enl...@li... >>>> 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.php&p=sourceforge&CID=DEVDEV >>> _______________________________________________ >>> enlightenment-devel mailing list >>> enl...@li... >>> 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.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > |
From: Nathan I. <nin...@gm...> - 2007-01-17 15:11:39
|
On 1/17/07, Peter Parkanyi <me...@rh...> wrote: > > I'd argue on that topic. I think it should go to either ecore or e17. The > reason: I don't think any app but e uses the freedesktop menu, or if they do > so, they depend on e itself. That's an incorrect assumption. EWL currently relies on ecore_desktop for mapping stock icons. Having the window manager as a dependency is not an option for EWL. I would guess that ETK and custom evas/edje based user apps could also benefit from this. |
From: DaveMDS <li...@gu...> - 2007-01-17 15:11:48
|
dan sinclair ha scritto: > Peter Parkanyi wrote: > >> On Wednesday 17 January 2007 15:15, you wrote: >> >>> On Wednesday 17 January 2007 01:14, Jorge Luis Zapata Muga wrote: >>> >>>> On 1/17/07, Brian Mattern <bri...@gm...> wrote: >>>> >>>>> .... >>>>> >>>>> The next question is, assuming you guys see it as a viable replacement >>>>> for ecore_desktop, do we stick this somewhere in libs (as efreet or >>>>> e_xdg, or whatever name) or do we cram it in to ecore? My vote is that >>>>> we stop bloating ecore in the name of a 'dependency freeze' and keep >>>>> proper separation of libraries. (Its all 'new code' that needs to be >>>>> verified and tested regardless of where we stick it). >>>>> >>>>> Let us know what you guys think. >>>>> >>>> Indeed, i agree here. Better make it away from ecore, ecore already >>>> has too many (unrelated?) things inside. >>>> >>>> turran >>>> >> I'd argue on that topic. I think it should go to either ecore or e17. The >> reason: I don't think any app but e uses the freedesktop menu, or if they do >> so, they depend on e itself. >> >> It would be just a mess in the now well-structured dependency tree if we had >> to compile another lib, which only does one thing, and only one app uses it. >> And ecore? Well ecore is what its name sais: core library for efl(not just >> e17). And if there are already fdo stuff in it, and this would be a >> replacement for that, why don't you really replace it, inside ecore? >> >> > > Efreet is more then just menus. It also contains the icon theme code > which is used in Ewl. Any other app that want's to use the icons from a > given icon theme could use Efreet as well. > > Along with that, this _isn't_ core functionality that every app needs. > Why should we stuff it into Ecore when it doesn't really fit? > > Compiling one more lib isn't that difficult and doesn't confuse anything. > > Along with that, what if someone wants to write a menu editor? They'll > need access to the fdo menu code as well. If it's stuck inside e17 then > they have to build it inside e17. Not an optimal solution. > > dan > I complete agree with you dan, make a separate lib so we can use it in many other project (also that not depend to e itself). Dave > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > |
From: D. H. <dha...@dr...> - 2007-01-17 16:40:37
|
On Wed, 17 Jan 2007, DaveMDS wrote: > dan sinclair ha scritto: >> Peter Parkanyi wrote: >> >> Efreet is more then just menus. It also contains the icon theme code >> which is used in Ewl. Any other app that want's to use the icons from a >> given icon theme could use Efreet as well. >> >> Along with that, this _isn't_ core functionality that every app needs. >> Why should we stuff it into Ecore when it doesn't really fit? >> >> Compiling one more lib isn't that difficult and doesn't confuse anything. >> >> Along with that, what if someone wants to write a menu editor? They'll >> need access to the fdo menu code as well. If it's stuck inside e17 then >> they have to build it inside e17. Not an optimal solution. >> >> dan >> > I complete agree with you dan, make a separate lib so we can use it > in many other project (also that not depend to e itself). > I guess the real questions that should be asked: a) How many non-standard libaries does one project need to support their project? At what point are there too many? b) At what point do all the dependencies start being such a headache that a normal user wouldn't waste their time with the software no matter how "cool" it is? c) How many applications are created and used by people that rely on E libraries, but don't use E? I think C is the big question to ask. I have yet to find anyone using an application that uses e17 libaries that doesn't use E already. What does that indicate? Take a step back and think about it ... I am not trying to start a fight, but rather give some perspective on things from an end user point of view. If I were you ... I would just put it in ecore and be done with it. -- //========================================================\\ || D. Hageman <dha...@dr...> || \\========================================================// |
From: dan s. <ze...@pe...> - 2007-01-17 17:03:49
|
D. Hageman wrote: > > I guess the real questions that should be asked: > > a) How many non-standard libaries does one project need to support > their project? At what point are there too many? > Define non-standard. None of the efl libraries are 'standards'. We separate things into libraries because it makes sense. Dumping everything into one bucket just makes it harder to figure out how to use something. You're just bloating a library that is suppost to be a small core library with a lot of extra crap. When does it stop? Should we put an rss parsing engine into ecore because we want to use it on the e17 desktop? > b) At what point do all the dependencies start being such a headache > that a normal user wouldn't waste their time with the software no matter > how "cool" it is? At what point does a 'normal' user install from CVS? They just do apt-get install enlightenment and walk away. Dependencies shouldn't be an issue for 'normal' users. If you're installing from CVS you're, by definition, not a normal user. > > c) How many applications are created and used by people that rely on E > libraries, but don't use E? You could ask that question about any set of libraries. The core developers are obviously E users. E also isn't released. Therefore most of the apps are going to be run by people using E. That doesn't mean we should _force_ people to use E to use any EFL apps. That's just plain stupid. > > I think C is the big question to ask. I have yet to find anyone using > an application that uses e17 libaries that doesn't use E already. What > does that indicate? Take a step back and think about it ... I am not > trying to start a fight, but rather give some perspective on things from > an end user point of view. > > If I were you ... I would just put it in ecore and be done with it. > There are people using the EFL that don't use E. I know of at least one of the devs that doesn't run enlightenment. Just because people don't do it currently doesn't make any sense. Stuffing the kitchen sink into ecore isn't the way to go. The code still has to be stabilized. It still has to be installed. The only difference is your package manager adds another dependency line. We're not adding external dependencies. This is an EFL lib that doesn't link to anything else. dan |
From: Peter P. <me...@rh...> - 2007-01-17 18:05:21
|
On Wednesday 17 January 2007 18:01, dan sinclair wrote: > D. Hageman wrote: > > I guess the real questions that should be asked: > > > > a) How many non-standard libaries does one project need to support > > their project? At what point are there too many? > > Define non-standard. None of the efl libraries are 'standards'. We > separate things into libraries because it makes sense. Dumping > everything into one bucket just makes it harder to figure out how to use > something. You're just bloating a library that is suppost to be a small > core library with a lot of extra crap. When does it stop? Should we put > an rss parsing engine into ecore because we want to use it on the e17 > desktop? I think you still should put it into ecore, replacing Ecore_Desktop. Maybe they should coexist for some time(days, weeks, maybe?). Then remove the former, problem solved. Peter. |
From: D. H. <dha...@dr...> - 2007-01-18 15:12:52
|
On Wed, 17 Jan 2007, dan sinclair wrote: > D. Hageman wrote: >> >> I guess the real questions that should be asked: >> >> a) How many non-standard libaries does one project need to support their >> project? At what point are there too many? >> > > Define non-standard. None of the efl libraries are 'standards'. We separate > things into libraries because it makes sense. Dumping everything into one > bucket just makes it harder to figure out how to use something. You're just > bloating a library that is suppost to be a small core library with a lot of > extra crap. When does it stop? Should we put an rss parsing engine into ecore > because we want to use it on the e17 desktop? I understand the purpose of libraries. My argument is that there is a point of diminishing returns when you put *everything* into its own library. I also argue (package managers or not) that eventually you need to start thinking of end users experience besides of just "how pretty does it look?" Anyone can argue that e17 et al hasn't been released yet so it doesn't matter ... does this mean it will never, ever be released? Anyone can argue a slipperly slope argument of what should go in and not go into something like ecore ... but the truth is that something *similar* is already there. It is logically to just replace it and be done with it instead of contributing more to dependency/library bloat. -- //========================================================\\ || D. Hageman <dha...@dr...> || \\========================================================// |
From: Nathan I. <nin...@gm...> - 2007-01-18 16:42:51
|
On 1/18/07, D. Hageman <dha...@dr...> wrote: > > I understand the purpose of libraries. My argument is that there is a > point of diminishing returns when you put *everything* into its own > library. This isn't a discussion about whether everything should be its own library. It's whether freedesktop support is such a "core" function that it belongs in ecore. If you look at the existing modules in ecore, there is a fairly clear line about which ones are common to other libs and apps, and which are relatively unused or specialized. I would say that efreet falls into the specialized category. It's useful to more than a single application, but not useful for most. > I also argue (package managers or not) that eventually you need > to start thinking of end users experience besides of just "how pretty does > it look?" Anyone can argue that e17 et al hasn't been released yet so it > doesn't matter ... does this mean it will never, ever be released? What does another lib have to do with the "end user experience"? This has nothing to do with how pretty it looks. End user experience is about using the software, not compiling it (at least not for most users). We're not at the number of libraries that linking is overly burdensome on the user experience. If you're a programmer using the API's, it's about being able to easily understand how to use the API provided, and in that case there is little difference if its a separate lib or a module inside of another lib. In either case, the programmer needs a reference to know which lib provides the functionality required. > Anyone can argue a slipperly slope argument of what should go in and not go into > something like ecore ... I believe you were the one that used that logical fallacy earlier in this message by stating that we're arguing to put everything in its own library (though that could fall under a couple other categories too). > but the truth is that something *similar* is > already there. It is logically to just replace it and be done with it > instead of contributing more to dependency/library bloat. It's true that there is already something similar in ecore, but does that mean it necessarily belongs there? If e17 and other users of ecore_desktop switch to efreet, they will have to change their code regardless if it's updating to the new ecore_desktop API or changing it to an exdg API. As far as dependency or bloat, the way ecore_desktop is used now is that it's built and installed as a separate lib, just the source is inside the ecore directory and its namespaced under ecore. So the only difference is directory location and how many times you may have to do ./configure && make && make install. The number of libs linked would be identical. I want to make it clear, I think it makes sense to have an ecore type library to collect common functionality into a central location, but I don't think the desktop functionality necessarily belongs there. |
From: D. H. <dha...@dr...> - 2007-01-18 17:54:30
|
On Thu, 18 Jan 2007, Nathan Ingersoll wrote: > > I want to make it clear, I think it makes sense to have an ecore type > library to collect common functionality into a central location, but I > don't think the desktop functionality necessarily belongs there. The main thing is that this all gets down to philosophy more then anything and we can argue till we are blue in the face. I would still argue to stick it in ecore. I would also go for sticking it in E itself, but another library ... *sigh* ... -- //========================================================\\ || D. Hageman <dha...@dr...> || \\========================================================// |
From: Carsten H. (T. R. <ra...@ra...> - 2007-02-10 11:17:05
|
On Tue, 16 Jan 2007 17:11:33 -0600 Brian Mattern <bri...@gm...> babbled: hidey-ho... here i go - finally responding to this... :) > After a few weeks of spare-time development, I'd like to announce > Efreet, a new implementation of the XDG (freedesktop) specs for Icons, > Menus and Desktop Entries. cool- in good time. i recently daw some fun slowness in e17 when hunting for icons during startup when stat()'s are sloooow on a slow fs (eg nfs with high latency). > The current implementation, Ecore_Desktop, while a commendable effort > for a sole developer under time constraints, leaves a bit to be desired. > So, dj2 and I started reading through the xdg specs, and playing around > with our own implementation, code named Efreet. After speaking with > onefang about some of the issues with ecore_desktop, he said it was due > for a rewrite, so we continuted with our replacement implementation. > Rbdpngn and Engelbass also pitched in. great! :) it can do with improvement. > Currently we have code to build menus, find icons, and load desktop > entries complete. There are a few things left to finish (most > importatnly executing desktop entries), but it is almost at a point > where we'd like to start integrating it in to e17. can it slide in AS ecore_desktop? > The code, for those interested, is available from subversion at: > http://everburning.com/svn/efreet > > Before we hook e17 in to efreet, there are a few issues I'd like to > bring up. > E currently uses a hands off 'read only' approach to the XDG structure, > copying the structure in to the format that e previously used (.order > files). This made sense given ecore_desktops roots as an addon program > that simply connected the two. But, since we're already going to be > loading up the xdg menu format, is there any reason to not just use that > directly? This would have the added benefit that as apps are added > through a package manager, they would just show up in the menu as they > do in every other desktop (without having to go to config > application > menus > Regenerate / Update "Applications" Menu). then we need to support the xdg menu modifications spec (ie user changes to the system menus overlayed on the systems ones) - is that your plan? > The next question is, assuming you guys see it as a viable replacement > for ecore_desktop, do we stick this somewhere in libs (as efreet or > e_xdg, or whatever name) or do we cram it in to ecore? My vote is that > we stop bloating ecore in the name of a 'dependency freeze' and keep > proper separation of libraries. (Its all 'new code' that needs to be > verified and tested regardless of where we stick it). well i'd prefer it in ecore - as the plan post e17 is to split ecore up into multiple actual libs - thus you get what you want anyway :) > Let us know what you guys think. > > 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.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... 裸好多 Tokyo, Japan (東京 日本) |
From: dan s. <ze...@pe...> - 2007-02-10 15:51:50
|
On 9-Feb-07, at 6:14 PM, Carsten Haitzler (The Rasterman) wrote: > On Tue, 16 Jan 2007 17:11:33 -0600 Brian Mattern > <bri...@gm...> > babbled: > >> Currently we have code to build menus, find icons, and load desktop >> entries complete. There are a few things left to finish (most >> importatnly executing desktop entries), but it is almost at a point >> where we'd like to start integrating it in to e17. > > can it slide in AS ecore_desktop? > The APIs are different but the changes to bring in efreet instead of ecore_desktop aren't huge at this point. (There have been a couple of patches to do it so far) >> The code, for those interested, is available from subversion at: >> http://everburning.com/svn/efreet The code is in the e17/libs/efreet directory of CVS at the moment. >> >> Before we hook e17 in to efreet, there are a few issues I'd like to >> bring up. >> E currently uses a hands off 'read only' approach to the XDG >> structure, >> copying the structure in to the format that e previously used (.order >> files). This made sense given ecore_desktops roots as an addon >> program >> that simply connected the two. But, since we're already going to be >> loading up the xdg menu format, is there any reason to not just >> use that >> directly? This would have the added benefit that as apps are added >> through a package manager, they would just show up in the menu as >> they >> do in every other desktop (without having to go to config > >> application >> menus > Regenerate / Update "Applications" Menu). > > then we need to support the xdg menu modifications spec (ie user > changes to the > system menus overlayed on the systems ones) - is that your plan? > If the user has an applications.menu in their .local/menu directory then efreet will load that and use it. The user can then have that do a MergeFile with the system menus and put their changes on the end. Efreet will handle merging them together correctly. At this point Efreet handles the full menu-spec test that fdo provides. (At least last time I tried a week ago it did) >> The next question is, assuming you guys see it as a viable >> replacement >> for ecore_desktop, do we stick this somewhere in libs (as efreet or >> e_xdg, or whatever name) or do we cram it in to ecore? My vote is >> that >> we stop bloating ecore in the name of a 'dependency freeze' and keep >> proper separation of libraries. (Its all 'new code' that needs to be >> verified and tested regardless of where we stick it). > > well i'd prefer it in ecore - as the plan post e17 is to split > ecore up into > multiple actual libs - thus you get what you want anyway :) > Wouldn't it make it easier in the long run to have it in a separate lib as you then don't have to go through the hassle of splitting it out? Before we just start sliding it in as an ecore_desktop replacement, do we want to remove all the extra layer of menu stuff that e17 currently has? ecore_desktop has slid in as a replacement for .eap files. Do we really need too second layer of converting fdo menus to .order files and then e17 working off of the .order files? If we just work off of the fdo menu it will take a lot of the confusion out of the picture. May cleanup/reduce a lot of the code. dan |
From: Carsten H. (T. R. <ra...@ra...> - 2007-03-02 01:43:03
|
On Sat, 10 Feb 2007 10:51:54 -0500 dan sinclair <ze...@pe...> babbled: > > On 9-Feb-07, at 6:14 PM, Carsten Haitzler (The Rasterman) wrote: > > > On Tue, 16 Jan 2007 17:11:33 -0600 Brian Mattern > > <bri...@gm...> > > babbled: > > > >> Currently we have code to build menus, find icons, and load desktop > >> entries complete. There are a few things left to finish (most > >> importatnly executing desktop entries), but it is almost at a point > >> where we'd like to start integrating it in to e17. > > > > can it slide in AS ecore_desktop? > > > > The APIs are different but the changes to bring in efreet instead of > ecore_desktop aren't huge at this point. (There have been a couple of > patches to do it so far) i didn't mean changing the api of efreet - but making it build as part of ecore. this means no packaging or dependency changes for anything, consistent packaging, and it will get split out eventually (with no rename) when all of ecore splits. > >> The code, for those interested, is available from subversion at: > >> http://everburning.com/svn/efreet > > The code is in the e17/libs/efreet directory of CVS at the moment. yup. spotted :) > >> > >> Before we hook e17 in to efreet, there are a few issues I'd like to > >> bring up. > >> E currently uses a hands off 'read only' approach to the XDG > >> structure, > >> copying the structure in to the format that e previously used (.order > >> files). This made sense given ecore_desktops roots as an addon > >> program > >> that simply connected the two. But, since we're already going to be > >> loading up the xdg menu format, is there any reason to not just > >> use that > >> directly? This would have the added benefit that as apps are added > >> through a package manager, they would just show up in the menu as > >> they > >> do in every other desktop (without having to go to config > > >> application > >> menus > Regenerate / Update "Applications" Menu). > > > > then we need to support the xdg menu modifications spec (ie user > > changes to the > > system menus overlayed on the systems ones) - is that your plan? > > > > If the user has an applications.menu in their .local/menu directory > then efreet will load that and use it. The user can then have that do > a MergeFile with the system menus and put their changes on the end. > Efreet will handle merging them together correctly. > > At this point Efreet handles the full menu-spec test that fdo > provides. (At least last time I tried a week ago it did) thats good. as i said - before to rephorm on irc - i dont see any issue with efreet replacing the e_apps stuff behind the menus - i think that would be fine. the issues then come with having a menu editor, and other things like ibar etc. i think ibar can retain its current scheme for now. > > >> The next question is, assuming you guys see it as a viable > >> replacement > >> for ecore_desktop, do we stick this somewhere in libs (as efreet or > >> e_xdg, or whatever name) or do we cram it in to ecore? My vote is > >> that > >> we stop bloating ecore in the name of a 'dependency freeze' and keep > >> proper separation of libraries. (Its all 'new code' that needs to be > >> verified and tested regardless of where we stick it). > > > > well i'd prefer it in ecore - as the plan post e17 is to split > > ecore up into > > multiple actual libs - thus you get what you want anyway :) > > > > Wouldn't it make it easier in the long run to have it in a separate > lib as you then don't have to go through the hassle of splitting it out? well i will need to split all of ecore up anyway - so i will do it all in 1 go in the same consistent manner, so i dont see it as an issue :) > Before we just start sliding it in as an ecore_desktop replacement, > do we want to remove all the extra layer of menu stuff that e17 > currently has? ecore_desktop has slid in as a replacement for .eap > files. Do we really need too second layer of converting fdo menus > to .order files and then e17 working off of the .order files? If we > just work off of the fdo menu it will take a lot of the confusion out > of the picture. we dont need it - except that editing your own menus now needs special editing code too :) > May cleanup/reduce a lot of the code. indeed. i dont see a problem - just need to add the editing. the sticking point is efreet vs ecore_desktop as the place for efreet to live. > dan > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ra...@ra... 裸好多 Tokyo, Japan (東京 日本) |