Re: [E-devel] Is efreet still coming?

2007-03-20 Thread The Rasterman
On Tue, 20 Mar 2007 09:23:37 -0400 dan sinclair <[EMAIL PROTECTED]> babbled:

> Christopher Michael wrote:
>   > I've been reading through the efreet code and it's not too shabby, so
> > big (insert your favorite type) cookie to the authors there :) but 
> > before I jump head first into this porting nightmare I have a few 
> > remaining questions
> > 
> > 1) Is it really worth the effort to port all this efreet code into 
> > ecore_desktop, just to be pulling it out at a later date when ecore gets 
> > broken apart ??
> 
> I'd prefer keeping it out of ecore, but its been decided that that's 
> where it's to go.
> 
> > 
> > 2) Am I correct in assuming that we still want to keep the 
> > ecore_desktop_some_function calls and just replace the code inside with 
> > efreet code ?? (with #ifdef NEW_CODE blocking of course..ie: we still 
> > would have ecore_desktop_some_func, just that it would run efreet code)
> > 
> 
> I'd prefer if you keep the efreet naming and just 
> s/efreet/ecore_desktop/g. We put some thought into the APIs and think 
> they came out pretty good. (Unless we got the words around backwards for 
> the typical ecore naming, then swap them around.)

i agree - am happy with that. trying a compromise here - keep whatever api u
have - as its what you designed and thought about - just make it an
ecore_desktop replacement in ecore. :)

> dan
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Is efreet still coming?

2007-03-20 Thread The Rasterman
On Tue, 20 Mar 2007 08:13:35 -0400 Christopher Michael <[EMAIL PROTECTED]>
babbled:

> Carsten Haitzler (The Rasterman) wrote:
> > On Mon, 19 Mar 2007 10:02:18 -0400 dan sinclair <[EMAIL PROTECTED]>
> > babbled:
> > 
> >> Christopher Michael wrote:
> >>> Brian Mattern wrote:
>  Loading .desktop files, finding icons and parsing / building menus all
>  works. Executing desktops (and even downloading the files if necessary)
>  has been implemented.
> 
>  There may be a small amount of work left to be done to properly do menu
>  editing. I think we just never decided to what degree we want to
>  integrate things. E.g. converting directly from efreet's menu structures
>  into an E_Menu, or doing an intermediate step and building .order files
>  first.
> 
> >>> IMO, .order files may be the way to go as this would still allow a 
> >>> manual edit if needs be.
> >>>
> >> I don't think .order files are the way to go. The menu spec allows you 
> >> do manual edits. You can override the system menus by adding/editing 
> >> menus in your local directories (~/.config/menus). This gives the same 
> >> thing and saves us having to translate between .order and menu stuff. 
> >> Also keeps us consistent with other window managers for people that 
> >> switch desktops.
> >>
> >>
>  But, I'm busy with work, planning a wedding, and preparing for grad
>  school in the fall. So, its hard to find the motivation to work on this
>  in what little free time I have. :(
> 
>  rephorm
> >>> If you could provide a little more "direction" (as in what exactly we 
> >>> want todo in regards to integration) then I'd be happy to look into this 
> >>> and spend some time with it.
> >>>
> >> I believe the idea is to use fdo menus directly for the main e17 menus. 
> >> The Ibar would remain .order files.
> >>
> >> So, we need to replace the menu generation code with efreet code. We 
> >> need to port the icon editor over to using efreet (and add in a bit of 
> >> editing stuff to efreet I believe).
> >>
> >> We also, I guess, need to move efreet into ecore. Probably into 
> >> ecore_desktop as #if NEW_CODE blocks so we can keep the old stuff. Not 
> >> sure on that one tho. If we integrate into ecore we need to make sure we 
> >> bring the menu test suite code into the bin directory. This is the code 
> >> that let's us run efreet against the menu spec tests. I think we should 
> >> definately keep it around.
> >>
> >> There is a bunch of example code in the efreet test directory that 
> >> should let you know how things work in efreet-land.
> > 
> > agreed to all the above - except i think test code could/should go into the
> > now nice and shiny e17/test/... tree :) (imho).
> > 
> >> dan
> >>
> 
> Hi Guys :)
> 
> I've been reading through the efreet code and it's not too shabby, so 
> big (insert your favorite type) cookie to the authors there :) but 
> before I jump head first into this porting nightmare I have a few 
> remaining questions
> 
> 1) Is it really worth the effort to port all this efreet code into 
> ecore_desktop, just to be pulling it out at a later date when ecore gets 
> broken apart ??

yes. as then we need to remove ecore_desktop from ecore if we keep efreet. we
also now need efreet to be packaged for e17 and add it to the dependencies
checks, e17 build checks etc. when ecore gets broken apart - it will be post
1.0 and it will be broken up consistently - it will not be hard as the same
thing will be done for each ecore component when broken out so its do the 1
thing N times which is tirival - in the scheme of things.

> 2) Am I correct in assuming that we still want to keep the 
> ecore_desktop_some_function calls and just replace the code inside with 
> efreet code ?? (with #ifdef NEW_CODE blocking of course..ie: we still 
> would have ecore_desktop_some_func, just that it would run efreet code)
> 
> 
> Cheers,
> dh
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Is efreet still coming?

2007-03-20 Thread dan sinclair
Christopher Michael wrote:
  > I've been reading through the efreet code and it's not too shabby, so
> big (insert your favorite type) cookie to the authors there :) but 
> before I jump head first into this porting nightmare I have a few 
> remaining questions
> 
> 1) Is it really worth the effort to port all this efreet code into 
> ecore_desktop, just to be pulling it out at a later date when ecore gets 
> broken apart ??

I'd prefer keeping it out of ecore, but its been decided that that's 
where it's to go.

> 
> 2) Am I correct in assuming that we still want to keep the 
> ecore_desktop_some_function calls and just replace the code inside with 
> efreet code ?? (with #ifdef NEW_CODE blocking of course..ie: we still 
> would have ecore_desktop_some_func, just that it would run efreet code)
> 

I'd prefer if you keep the efreet naming and just 
s/efreet/ecore_desktop/g. We put some thought into the APIs and think 
they came out pretty good. (Unless we got the words around backwards for 
the typical ecore naming, then swap them around.)

dan

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Is efreet still coming?

2007-03-20 Thread Christopher Michael
Peter Wehrfritz wrote:
> Christopher Michael schrieb:
>> Hi Guys :)
>>
>> I've been reading through the efreet code and it's not too shabby, so 
>> big (insert your favorite type) cookie to the authors there :) but 
>> before I jump head first into this porting nightmare I have a few 
>> remaining questions
>>
>> 1) Is it really worth the effort to port all this efreet code into 
>> ecore_desktop, just to be pulling it out at a later date when ecore 
>> gets broken apart ??
>>
>> 2) Am I correct in assuming that we still want to keep the 
>> ecore_desktop_some_function calls and just replace the code inside 
>> with efreet code ?? (with #ifdef NEW_CODE blocking of course..ie: we 
>> still would have ecore_desktop_some_func, just that it would run 
>> efreet code)
>>
>>   
> If you want to have efreet to be a part of ecore and raster seems to 
> want this, why don't you move it simply to ecore/src/lib/efreet and keep 
> the efreet name-space. So efreet and ecore_desktop can coexist for 
> sometime and it is much easier to do the transition (not only e17 uses 
> ecore_desktop).
> And when sometime ecore gets split into several package, you can still 
> use the efreet namespace and you don't have to rename all the function 
> in your applications and libraries.
> 
> just my 2 cents
> 
> Peter
> 
This is along the lines of what I was thinkingtho I wanted some 
"peer" input first :) I'd rather just do all this once and not have to 
go back and redo it :)

dh


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Is efreet still coming?

2007-03-20 Thread Peter Wehrfritz
Christopher Michael schrieb:
> Hi Guys :)
>
> I've been reading through the efreet code and it's not too shabby, so 
> big (insert your favorite type) cookie to the authors there :) but 
> before I jump head first into this porting nightmare I have a few 
> remaining questions
>
> 1) Is it really worth the effort to port all this efreet code into 
> ecore_desktop, just to be pulling it out at a later date when ecore gets 
> broken apart ??
>
> 2) Am I correct in assuming that we still want to keep the 
> ecore_desktop_some_function calls and just replace the code inside with 
> efreet code ?? (with #ifdef NEW_CODE blocking of course..ie: we still 
> would have ecore_desktop_some_func, just that it would run efreet code)
>
>   
If you want to have efreet to be a part of ecore and raster seems to 
want this, why don't you move it simply to ecore/src/lib/efreet and keep 
the efreet name-space. So efreet and ecore_desktop can coexist for 
sometime and it is much easier to do the transition (not only e17 uses 
ecore_desktop).
And when sometime ecore gets split into several package, you can still 
use the efreet namespace and you don't have to rename all the function 
in your applications and libraries.

just my 2 cents

Peter

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Is efreet still coming?

2007-03-20 Thread Christopher Michael
Carsten Haitzler (The Rasterman) wrote:
> On Mon, 19 Mar 2007 10:02:18 -0400 dan sinclair <[EMAIL PROTECTED]> babbled:
> 
>> Christopher Michael wrote:
>>> Brian Mattern wrote:
 Loading .desktop files, finding icons and parsing / building menus all
 works. Executing desktops (and even downloading the files if necessary)
 has been implemented.

 There may be a small amount of work left to be done to properly do menu
 editing. I think we just never decided to what degree we want to
 integrate things. E.g. converting directly from efreet's menu structures
 into an E_Menu, or doing an intermediate step and building .order files
 first.

>>> IMO, .order files may be the way to go as this would still allow a 
>>> manual edit if needs be.
>>>
>> I don't think .order files are the way to go. The menu spec allows you 
>> do manual edits. You can override the system menus by adding/editing 
>> menus in your local directories (~/.config/menus). This gives the same 
>> thing and saves us having to translate between .order and menu stuff. 
>> Also keeps us consistent with other window managers for people that 
>> switch desktops.
>>
>>
 But, I'm busy with work, planning a wedding, and preparing for grad
 school in the fall. So, its hard to find the motivation to work on this
 in what little free time I have. :(

 rephorm
>>> If you could provide a little more "direction" (as in what exactly we 
>>> want todo in regards to integration) then I'd be happy to look into this 
>>> and spend some time with it.
>>>
>> I believe the idea is to use fdo menus directly for the main e17 menus. 
>> The Ibar would remain .order files.
>>
>> So, we need to replace the menu generation code with efreet code. We 
>> need to port the icon editor over to using efreet (and add in a bit of 
>> editing stuff to efreet I believe).
>>
>> We also, I guess, need to move efreet into ecore. Probably into 
>> ecore_desktop as #if NEW_CODE blocks so we can keep the old stuff. Not 
>> sure on that one tho. If we integrate into ecore we need to make sure we 
>> bring the menu test suite code into the bin directory. This is the code 
>> that let's us run efreet against the menu spec tests. I think we should 
>> definately keep it around.
>>
>> There is a bunch of example code in the efreet test directory that 
>> should let you know how things work in efreet-land.
> 
> agreed to all the above - except i think test code could/should go into the 
> now
> nice and shiny e17/test/... tree :) (imho).
> 
>> dan
>>

Hi Guys :)

I've been reading through the efreet code and it's not too shabby, so 
big (insert your favorite type) cookie to the authors there :) but 
before I jump head first into this porting nightmare I have a few 
remaining questions

1) Is it really worth the effort to port all this efreet code into 
ecore_desktop, just to be pulling it out at a later date when ecore gets 
broken apart ??

2) Am I correct in assuming that we still want to keep the 
ecore_desktop_some_function calls and just replace the code inside with 
efreet code ?? (with #ifdef NEW_CODE blocking of course..ie: we still 
would have ecore_desktop_some_func, just that it would run efreet code)


Cheers,
dh

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Is efreet still coming?

2007-03-19 Thread The Rasterman
On Mon, 19 Mar 2007 10:39:08 -0500 Brian Mattern <[EMAIL PROTECTED]>
babbled:

> On Tue, Mar 20, 2007 at 12:15:59AM +0900, Carsten Haitzler wrote:
> > agreed to all the above - except i think test code could/should go into the
> > now nice and shiny e17/test/... tree :) (imho).
> 
> As long as we make this tree well known (e.g on whatever new 'accessing
> CVS' page we build). :)
> 
> I've noticed several people who started learning edje after you split
> out the test tree who never knew about the edje test app (which is very
> helpful when initially learning EDC).

yeah - i need to make something better that's separate. as such the edje test
app is only just that - a quickly hacked up test app. :(

> 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
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Is efreet still coming?

2007-03-19 Thread Brian Mattern
On Tue, Mar 20, 2007 at 12:15:59AM +0900, Carsten Haitzler wrote:
> agreed to all the above - except i think test code could/should go into the 
> now
> nice and shiny e17/test/... tree :) (imho).

As long as we make this tree well known (e.g on whatever new 'accessing
CVS' page we build). :)

I've noticed several people who started learning edje after you split
out the test tree who never knew about the edje test app (which is very
helpful when initially learning EDC).

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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Is efreet still coming?

2007-03-19 Thread The Rasterman
On Mon, 19 Mar 2007 10:02:18 -0400 dan sinclair <[EMAIL PROTECTED]> babbled:

> Christopher Michael wrote:
> > Brian Mattern wrote:
> >> Loading .desktop files, finding icons and parsing / building menus all
> >> works. Executing desktops (and even downloading the files if necessary)
> >> has been implemented.
> >> 
> >> There may be a small amount of work left to be done to properly do menu
> >> editing. I think we just never decided to what degree we want to
> >> integrate things. E.g. converting directly from efreet's menu structures
> >> into an E_Menu, or doing an intermediate step and building .order files
> >> first.
> >> 
> > IMO, .order files may be the way to go as this would still allow a 
> > manual edit if needs be.
> > 
> 
> I don't think .order files are the way to go. The menu spec allows you 
> do manual edits. You can override the system menus by adding/editing 
> menus in your local directories (~/.config/menus). This gives the same 
> thing and saves us having to translate between .order and menu stuff. 
> Also keeps us consistent with other window managers for people that 
> switch desktops.
> 
> 
> >> But, I'm busy with work, planning a wedding, and preparing for grad
> >> school in the fall. So, its hard to find the motivation to work on this
> >> in what little free time I have. :(
> >> 
> >> rephorm
> > 
> > If you could provide a little more "direction" (as in what exactly we 
> > want todo in regards to integration) then I'd be happy to look into this 
> > and spend some time with it.
> > 
> 
> I believe the idea is to use fdo menus directly for the main e17 menus. 
> The Ibar would remain .order files.
> 
> So, we need to replace the menu generation code with efreet code. We 
> need to port the icon editor over to using efreet (and add in a bit of 
> editing stuff to efreet I believe).
> 
> We also, I guess, need to move efreet into ecore. Probably into 
> ecore_desktop as #if NEW_CODE blocks so we can keep the old stuff. Not 
> sure on that one tho. If we integrate into ecore we need to make sure we 
> bring the menu test suite code into the bin directory. This is the code 
> that let's us run efreet against the menu spec tests. I think we should 
> definately keep it around.
> 
> There is a bunch of example code in the efreet test directory that 
> should let you know how things work in efreet-land.

agreed to all the above - except i think test code could/should go into the now
nice and shiny e17/test/... tree :) (imho).

> dan
> 
> 
> -
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Is efreet still coming?

2007-03-19 Thread dan sinclair
Brian Mattern wrote:
> 
> Efreet is pretty much complete, other than being itegrated into e17.
> Unfortunately, dan doesn't use e17 on anymore and seb and I have been
> pretty busy lately. 
> 

I still use e17 at work, but don't have time to do development there. I 
just don't use it at home anymore as I turned off my last non-mac 
machine when I gave the monitor to my wife.

dan

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Is efreet still coming?

2007-03-19 Thread dan sinclair
Christopher Michael wrote:
> Brian Mattern wrote:
>> Loading .desktop files, finding icons and parsing / building menus all
>> works. Executing desktops (and even downloading the files if necessary)
>> has been implemented.
>> 
>> There may be a small amount of work left to be done to properly do menu
>> editing. I think we just never decided to what degree we want to
>> integrate things. E.g. converting directly from efreet's menu structures
>> into an E_Menu, or doing an intermediate step and building .order files
>> first.
>> 
> IMO, .order files may be the way to go as this would still allow a 
> manual edit if needs be.
> 

I don't think .order files are the way to go. The menu spec allows you 
do manual edits. You can override the system menus by adding/editing 
menus in your local directories (~/.config/menus). This gives the same 
thing and saves us having to translate between .order and menu stuff. 
Also keeps us consistent with other window managers for people that 
switch desktops.


>> But, I'm busy with work, planning a wedding, and preparing for grad
>> school in the fall. So, its hard to find the motivation to work on this
>> in what little free time I have. :(
>> 
>> rephorm
> 
> If you could provide a little more "direction" (as in what exactly we 
> want todo in regards to integration) then I'd be happy to look into this 
> and spend some time with it.
> 

I believe the idea is to use fdo menus directly for the main e17 menus. 
The Ibar would remain .order files.

So, we need to replace the menu generation code with efreet code. We 
need to port the icon editor over to using efreet (and add in a bit of 
editing stuff to efreet I believe).

We also, I guess, need to move efreet into ecore. Probably into 
ecore_desktop as #if NEW_CODE blocks so we can keep the old stuff. Not 
sure on that one tho. If we integrate into ecore we need to make sure we 
bring the menu test suite code into the bin directory. This is the code 
that let's us run efreet against the menu spec tests. I think we should 
definately keep it around.

There is a bunch of example code in the efreet test directory that 
should let you know how things work in efreet-land.

dan


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Is efreet still coming?

2007-03-19 Thread Christopher Michael
Brian Mattern wrote:
> On Sun, Mar 18, 2007 at 03:29:13PM +1000, David Seikel wrote:
>> Raster made this commit about two weeks ago :
>>
>>> a lot of patches - also my work on moving the IO stuff in e_fm to a
>>> slave process to stop e from ever "locking up". this unfortunately
>>> breaks the other source stuff and thus breaks the app editor config
>>> dialogs and anything using fm2 for .desktop stuff from the e
>>> applications/all repo. i am doing this as i expect this to go away
>>> with efreet anyway so not too much of an issue. not all fm operatiosn
>>> work currently - note. so beware. it can view files though :)
>> So I have been holding off on any attempt to repair these things and
>> just sitting and waiting for efreet to solve all our problems.  The
>> users are now complaining about the broken app editor.  I have not seen
>> any efreet commits for a while, is it going to replace ecore_desktop
>> soon?  Or should I put in some effort to patching up the app editor
>> while we wait?
> 
> Efreet is pretty much complete, other than being itegrated into e17.
> Unfortunately, dan doesn't use e17 on anymore and seb and I have been
> pretty busy lately. 
> 
>> What state of development is efreet in anyway?
> 
> It is mostly complete.
> 
> Loading .desktop files, finding icons and parsing / building menus all
> works. Executing desktops (and even downloading the files if necessary)
> has been implemented.
> 
> There may be a small amount of work left to be done to properly do menu
> editing. I think we just never decided to what degree we want to
> integrate things. E.g. converting directly from efreet's menu structures
> into an E_Menu, or doing an intermediate step and building .order files
> first.
> 
IMO, .order files may be the way to go as this would still allow a 
manual edit if needs be.

> But, I'm busy with work, planning a wedding, and preparing for grad
> school in the fall. So, its hard to find the motivation to work on this
> in what little free time I have. :(
> 
> rephorm

If you could provide a little more "direction" (as in what exactly we 
want todo in regards to integration) then I'd be happy to look into this 
and spend some time with it.

dh

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Is efreet still coming?

2007-03-18 Thread Brian Mattern
On Sun, Mar 18, 2007 at 03:29:13PM +1000, David Seikel wrote:
> Raster made this commit about two weeks ago :
> 
> > a lot of patches - also my work on moving the IO stuff in e_fm to a
> > slave process to stop e from ever "locking up". this unfortunately
> > breaks the other source stuff and thus breaks the app editor config
> > dialogs and anything using fm2 for .desktop stuff from the e
> > applications/all repo. i am doing this as i expect this to go away
> > with efreet anyway so not too much of an issue. not all fm operatiosn
> > work currently - note. so beware. it can view files though :)
> 
> So I have been holding off on any attempt to repair these things and
> just sitting and waiting for efreet to solve all our problems.  The
> users are now complaining about the broken app editor.  I have not seen
> any efreet commits for a while, is it going to replace ecore_desktop
> soon?  Or should I put in some effort to patching up the app editor
> while we wait?

Efreet is pretty much complete, other than being itegrated into e17.
Unfortunately, dan doesn't use e17 on anymore and seb and I have been
pretty busy lately. 

> 
> What state of development is efreet in anyway?

It is mostly complete.

Loading .desktop files, finding icons and parsing / building menus all
works. Executing desktops (and even downloading the files if necessary)
has been implemented.

There may be a small amount of work left to be done to properly do menu
editing. I think we just never decided to what degree we want to
integrate things. E.g. converting directly from efreet's menu structures
into an E_Menu, or doing an intermediate step and building .order files
first.

But, I'm busy with work, planning a wedding, and preparing for grad
school in the fall. So, its hard to find the motivation to work on this
in what little free time I have. :(

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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] Is efreet still coming?

2007-03-17 Thread David Seikel
Raster made this commit about two weeks ago :

> a lot of patches - also my work on moving the IO stuff in e_fm to a
> slave process to stop e from ever "locking up". this unfortunately
> breaks the other source stuff and thus breaks the app editor config
> dialogs and anything using fm2 for .desktop stuff from the e
> applications/all repo. i am doing this as i expect this to go away
> with efreet anyway so not too much of an issue. not all fm operatiosn
> work currently - note. so beware. it can view files though :)

So I have been holding off on any attempt to repair these things and
just sitting and waiting for efreet to solve all our problems.  The
users are now complaining about the broken app editor.  I have not seen
any efreet commits for a while, is it going to replace ecore_desktop
soon?  Or should I put in some effort to patching up the app editor
while we wait?

What state of development is efreet in anyway?


signature.asc
Description: PGP signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel