[E-devel] Re: E CVS: apps/e rephorm
Hi, Just some comments on dnd in pager. From my point of view, it would be nice to have a config option that allows to turn of the dnd. I request this, because I usually use mouse to switch desktops. Some times desktops switch fine. But, sometimes dnd starts and I drag a window in pager. After, finaly, I go to desktop I want, the position of the window is changed. This looks not very comfortable for me, since I have to reposition wins on that desktop. sn On 3/29/06, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : rephorm Project : e17 Module : apps/e Dir : e17/apps/e/src/modules/pager Modified Files: e_mod_config.c e_mod_main.c e_mod_main.h Log Message: better pager dragging * drag windows around within pager * dnd when going outside of the pager * window placed at location in pager of drop * window centered under mouse when dropped off of pager I'm not sure yet to do with original window when dragging off the pager. Right now it stays at last on pager location, which is a bit ugly. Should it jump back to the original position? Or disappear entirely? --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Re: E CVS: libs/ecore raster
On Thu, Mar 30, 2006 at 08:53:29AM +0900, Carsten Haitzler wrote: On Wed, 29 Mar 2006 07:33:08 -0800 Blake B. [EMAIL PROTECTED] babbled: On Mar 29, 2006, at 1:45 AM, Vlad Alyukov wrote: EC changelog.cin ... errr... not right. EC do the people doing debian packaging... actually test things? There were some half-baked commits just before CVS was taken down. I hope to clean it up this week and get all packages building for the weekend. ok. i think i might have to poke my finger into it all too - i notice some totally outrageous build requirements (ecore REQUIRES libdiretfb? no - it's optional and i don't think we should be shipping it as then the final e install will drag in dfb w2hen actually no apps use it - it's there for special case development). also packages need splitting up into more fine-grained lumps if there're no objections i'll split libecore0 into the following packages (which will hopefully fix the dependency issues as well): libecore0 libecore0-config libecore0-con libecore0-dbus libecore0-directfb libecore0-evas libecore0-fb libecore0-file libecore0-ipc libecore0-job libecore0-txt libecore0-x are there packages which can be merged into one? libecore0-dev will contain all available headers, as it is right now. or should i split that one, too? Falko --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Re: E CVS: apps/e rephorm
Read the email I sent (Pager Dragging) about setting the drag offset. -- rephorm On Thursday 30 March 2006 04:35, Aleksej Struk wrote: Hi, Just some comments on dnd in pager. From my point of view, it would be nice to have a config option that allows to turn of the dnd. I request this, because I usually use mouse to switch desktops. Some times desktops switch fine. But, sometimes dnd starts and I drag a window in pager. After, finaly, I go to desktop I want, the position of the window is changed. This looks not very comfortable for me, since I have to reposition wins on that desktop. sn On 3/29/06, Enlightenment CVS [EMAIL PROTECTED] wrote: Enlightenment CVS committal Author : rephorm Project : e17 Module : apps/e Dir : e17/apps/e/src/modules/pager Modified Files: e_mod_config.c e_mod_main.c e_mod_main.h Log Message: better pager dragging * drag windows around within pager * dnd when going outside of the pager * window placed at location in pager of drop * window centered under mouse when dropped off of pager I'm not sure yet to do with original window when dragging off the pager. Right now it stays at last on pager location, which is a bit ugly. Should it jump back to the original position? Or disappear entirely? --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Re: E CVS: libs/ecore raster
On Thu, 30 Mar 2006 15:09:32 +0200 Falko Schmidt [EMAIL PROTECTED] babbled: On Thu, Mar 30, 2006 at 08:53:29AM +0900, Carsten Haitzler wrote: On Wed, 29 Mar 2006 07:33:08 -0800 Blake B. [EMAIL PROTECTED] babbled: On Mar 29, 2006, at 1:45 AM, Vlad Alyukov wrote: EC changelog.cin ... errr... not right. EC do the people doing debian packaging... actually test things? There were some half-baked commits just before CVS was taken down. I hope to clean it up this week and get all packages building for the weekend. ok. i think i might have to poke my finger into it all too - i notice some totally outrageous build requirements (ecore REQUIRES libdiretfb? no - it's optional and i don't think we should be shipping it as then the final e install will drag in dfb w2hen actually no apps use it - it's there for special case development). also packages need splitting up into more fine-grained lumps if there're no objections i'll split libecore0 into the following packages (which will hopefully fix the dependency issues as well): libecore0 libecore0-config libecore0-con libecore0-dbus libecore0-directfb libecore0-evas libecore0-fb libecore0-file libecore0-ipc libecore0-job libecore0-txt libecore0-x are there packages which can be merged into one? i like the split this way. it gives fine-grained control. auto-dependency resolving will make sure the right subset is installed. libecore0-dev will contain all available headers, as it is right now. or should i split that one, too? it will have to suck in all the above libs then. Falko -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ATTN: Core Developers
On Wednesday 29 March 2006 21:39, Carsten Haitzler wrote: On Thu, 30 Mar 2006 13:27:49 +1000 David Seikel [EMAIL PROTECTED] babbled: On Wed, 29 Mar 2006 18:07:58 -0500 Christopher Michael [EMAIL PROTECTED] wrote: I'm writting you today under counsel from another core dev who shall remain nameless for now, concerning the possiblity of granting (irc) kiwi_ developer access so that he may add his dEvian module, and a few more up-coming modules, to cvs under e_modules. I am a little conflicted on this. First, the module/gadget API isn't very stable yet, and as we've seen, every small API change is followed by the corresponding change to each of the modules. Gadcon introduces a large API change, so when that stabilizes, they'll all need a major overhaul. That said, devilhorns has been pretty consistent at keeping the modules up to date. (I just think its unfortunate that so many people jumped the gun and started writing modules using a nowhere-near-stable api). /rant_on_mondules As far as granting dev access, I'm all for the more the merrier. But, we used to have a send in some (good) patches for a while, and we'll eventually get sick of committing them and grant you access policy. So, does here I wrote this module count? Are we going to grant access to EVERY person that writes a module? Just something to think about. I hadn't heard of dEvian, and haven't had time to try it out / review any of the code. So, I abstain from voting (for now). snip core devs are 1. current - they actually have been active in cvs etc. recently (if you go away for 6 months and come back... you aren't core until u start getting back in the game - at some fuzzy point afterwards u are back 2. you know what u are doing the vast majority of the time. you aren't blindly breaking/etc. 3. you actually ACCEPT responsibility for your work and when it needs fixing - u fix. 4. you have a big hand in code development. devs who do packaging i wouldn't consider core but more helpers i don't like to make a them and us culture though - so i want to keep this all fuzzy and nebulous. I agree. I'm all for a more anarchic system (as in 'no rulers' not 'no rules'). We just need to maintain some sort of criteria for giving people access. (And remember that granting someone access is equivalent to vouching for them and taking responsibility for their actions also). -- rephorm --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Re: E CVS: libs/ecore raster
On Mar 30, 2006, at 6:12 AM, Carsten Haitzler (The Rasterman) wrote: ok. i think i might have to poke my finger into it all too - i notice some totally outrageous build requirements (ecore REQUIRES libdiretfb? no - it's optional and i don't think we should be shipping it as then the final e install will drag in dfb w2hen actually no apps use it - it's there for special case development). also packages need splitting up into more fine-grained lumps Definitely. Evas needs to be done this way too. I didn't notice the directfb requirement in there, I build without it. I think xstasi must have added it because his repository has support for it (and a back-ported directfb package) if there're no objections i'll split libecore0 into the following packages (which will hopefully fix the dependency issues as well): libecore0 libecore0-config libecore0-con libecore0-dbus libecore0-directfb libecore0-evas libecore0-fb libecore0-file libecore0-ipc libecore0-job libecore0-txt libecore0-x are there packages which can be merged into one? i like the split this way. it gives fine-grained control. auto- dependency resolving will make sure the right subset is installed. Cool, will libecore be a virtual package for all of them? Or something like libecore-all? libecore0-dev will contain all available headers, as it is right now. or should i split that one, too? it will have to suck in all the above libs then. I think this is fine, since IMO anyone wouldn't be doing much development with only one specific subsystem of ecore. And not to mention maintaining all those different packages for -dev AND lib will be a pain. -Blake --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ATTN: Core Developers
On Mar 30, 2006, at 6:59 AM, Brian Mattern wrote: As far as granting dev access, I'm all for the more the merrier. But, we used to have a send in some (good) patches for a while, and we'll eventually get sick of committing them and grant you access policy. So, does here I wrote this module count? Are we going to grant access to EVERY person that writes a module? Just something to think about. I think coding standards and fitting in with the development style of the rest of the project should be a pre-requisite to getting access. I say this only from past experience with rogue developers who can't change the way they code to fit into a group, they often introduce more problems than they solve. I hadn't heard of dEvian, and haven't had time to try it out / review any of the code. So, I abstain from voting (for now). So maybe that's all that should happen, sign-off by two or more currently-considered-core developers? Could be noted in the dev's info.txt. So maybe their code and their dev info is checked into CVS, reviewed, agreed on, and then their SSH key is put in place? I know I'm not core or anything but I have had experience on projects of this size at various jobs in the past and I think the loosely-controlled approach works well, but too much anarchy is just as bad as too much order. Another thing I'd love to see is a way to restrict commit access based on the CVS module project dir (like a check against the AUTHORS file), and then only core or project owners can add/update that file. -Blake --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ATTN: Core Developers
Sorry for the self-reply. I just want to clarify that I'm not referring to kiwi specifically at all. -Blake On Mar 30, 2006, at 8:25 AM, Blake B. wrote: On Mar 30, 2006, at 6:59 AM, Brian Mattern wrote: As far as granting dev access, I'm all for the more the merrier. But, we used to have a send in some (good) patches for a while, and we'll eventually get sick of committing them and grant you access policy. So, does here I wrote this module count? Are we going to grant access to EVERY person that writes a module? Just something to think about. I think coding standards and fitting in with the development style of the rest of the project should be a pre-requisite to getting access. I say this only from past experience with rogue developers who can't change the way they code to fit into a group, they often introduce more problems than they solve. I hadn't heard of dEvian, and haven't had time to try it out / review any of the code. So, I abstain from voting (for now). So maybe that's all that should happen, sign-off by two or more currently-considered-core developers? Could be noted in the dev's info.txt. So maybe their code and their dev info is checked into CVS, reviewed, agreed on, and then their SSH key is put in place? I know I'm not core or anything but I have had experience on projects of this size at various jobs in the past and I think the loosely-controlled approach works well, but too much anarchy is just as bad as too much order. Another thing I'd love to see is a way to restrict commit access based on the CVS module project dir (like a check against the AUTHORS file), and then only core or project owners can add/ update that file. -Blake --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel? cmd=lnkkid=110944bid=241720dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] e16 - 0.16.8.1, e16keyedit - 0.3
e16 version 0.16.8.1 and e16keyedit version 0.3 are now available for download. e16-0.16.8.1: - Fix for themes containing menu definitions Any e16 theme should now work with 0.16.8.1. - Various background handling fixes Only use root background overlay window when composite is enabled. Fix external background handling (when using e.g. Esetroot). Show external background in pagers. - Bug fixes, see ChangeLog for details. e16keyedit-0.3: - Now works with e16.8. - Build with gtk2 (by default). /Kim --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Re: E CVS: libs/ecore raster
On Thu, Mar 30, 2006 at 11:12:15PM +0900, Carsten Haitzler wrote: On Thu, 30 Mar 2006 15:09:32 +0200 Falko Schmidt [EMAIL PROTECTED] babbled: On Thu, Mar 30, 2006 at 08:53:29AM +0900, Carsten Haitzler wrote: On Wed, 29 Mar 2006 07:33:08 -0800 Blake B. [EMAIL PROTECTED] babbled: On Mar 29, 2006, at 1:45 AM, Vlad Alyukov wrote: EC changelog.cin ... errr... not right. EC do the people doing debian packaging... actually test things? There were some half-baked commits just before CVS was taken down. I hope to clean it up this week and get all packages building for the weekend. ok. i think i might have to poke my finger into it all too - i notice some totally outrageous build requirements (ecore REQUIRES libdiretfb? no - it's optional and i don't think we should be shipping it as then the final e install will drag in dfb w2hen actually no apps use it - it's there for special case development). also packages need splitting up into more fine-grained lumps if there're no objections i'll split libecore0 into the following packages (which will hopefully fix the dependency issues as well): libecore0 libecore0-config libecore0-con libecore0-dbus libecore0-directfb libecore0-evas libecore0-fb libecore0-file libecore0-ipc libecore0-job libecore0-txt libecore0-x are there packages which can be merged into one? i like the split this way. it gives fine-grained control. auto-dependency resolving will make sure the right subset is installed. fine then. i just commited the new .install and control files. hope everything is alright. if you're not too busy, i'd be glad if you took a quick look at the dependencies somewhen and tell me if you see any missing or unnecessary libraries. i grepped the code for #include's and checked the .so's with ldd and found some missing dependencies in the former debian control file which should now be fixed. one more question though: do we need the fonts in data/fonts? i didn't find any related part which loads fonts. if they're needed indeed, shouldn't i better make libecore0 depend on the appropriate debian font package? libecore0-dev will contain all available headers, as it is right now. or should i split that one, too? it will have to suck in all the above libs then. yep, it does. Falko --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Re: E CVS: libs/ecore raster
On Thu, Mar 30, 2006 at 08:13:09AM -0800, Blake B. wrote: On Mar 30, 2006, at 6:12 AM, Carsten Haitzler (The Rasterman) wrote: ok. i think i might have to poke my finger into it all too - i notice some totally outrageous build requirements (ecore REQUIRES libdiretfb? no - it's optional and i don't think we should be shipping it as then the final e install will drag in dfb w2hen actually no apps use it - it's there for special case development). also packages need splitting up into more fine-grained lumps Definitely. Evas needs to be done this way too. I didn't notice the directfb requirement in there, I build without it. I think xstasi must have added it because his repository has support for it (and a back-ported directfb package) if there're no objections i'll split libecore0 into the following packages (which will hopefully fix the dependency issues as well): libecore0 libecore0-config libecore0-con libecore0-dbus libecore0-directfb libecore0-evas libecore0-fb libecore0-file libecore0-ipc libecore0-job libecore0-txt libecore0-x are there packages which can be merged into one? i like the split this way. it gives fine-grained control. auto- dependency resolving will make sure the right subset is installed. Cool, will libecore be a virtual package for all of them? Or something like libecore-all? good question. as it is now, libecore0 just contains the basic infrastructure for the rest: [...] ./usr/share/ecore ./usr/share/ecore/fonts ./usr/share/ecore/fonts/fonts.alias ./usr/share/ecore/fonts/fonts.dir ./usr/share/ecore/fonts/Vera.ttf ./usr/share/ecore/fonts/VeraBd.ttf ./usr/share/ecore/fonts/VeraBI.ttf ./usr/share/ecore/fonts/VeraIt.ttf ./usr/share/ecore/fonts/VeraMoBd.ttf ./usr/share/ecore/fonts/VeraMoBI.ttf ./usr/share/ecore/fonts/VeraMoIt.ttf ./usr/share/ecore/fonts/VeraMono.ttf ./usr/share/ecore/fonts/VeraSe.ttf ./usr/share/ecore/fonts/VeraSeBd.ttf ./usr/lib ./usr/lib/libecore.so.1.0.0 ./usr/lib/libecore.so.1 the fonts remain another issue (see last mail). i could add a virtual libecore0-all package but that shouldn't hold us back from adjusting proper specific ecore dependencies of apps/e, apps/entrance and so on. ditto for evas when it's ready, of course. if the previous commit in ecore is ok then i'll look into apps and libs which use ecore and fix the deps there. libecore0-dev will contain all available headers, as it is right now. or should i split that one, too? it will have to suck in all the above libs then. I think this is fine, since IMO anyone wouldn't be doing much development with only one specific subsystem of ecore. And not to mention maintaining all those different packages for -dev AND lib will be a pain. i totally agree. Falko --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] dr17 study
Hello guys :)We are a team of french students (at ENSEIRB, an engineering school in Bordeaux), and we are studying the e17 project as an example of open source project. We'd like to find out more about how things work from the inside, from any developer's point of view. So we have compiled here our main questions for those who are willing to help us.. Feel free to answer further than the actual question, we are looking for a real insight! :)Sorry in advance for those who are not interested, you can just skip this mail ;)-First, what is the nick under which u commit ? -What is your role in the E project?-Which country do u code from?-Who are the programmers you consider to be the core of the project?-Who are those you actually ask for help when you need some ( e.g. about compatibility issues)?-Do you use means of communicating with the rest of the devs other than irc and the mailing lists? Do you find it (irc and MLs) entirely suited to your needs?-When there is a decision concerning the whole team you wish to see taken, how do u see to that? -Have you developed links with some devs that go beyond working on the same project?-How much time do you spend doing e17 developing (per week and per day, depending on the day)?-What do you do aside from Enlightenment? -When, why and how did you join the E project?-Do you think major changes have occurred since that time?-Is there any recurrent problem you find to be responsible of unnecessary extra work/loss of time for you or the team? Well, thanks for reading, and greater thanks for answering us if you do.. :)Code be with you! ;)
Re: [E-devel] Re: E CVS: libs/ecore raster
On Thu, 30 Mar 2006 21:20:16 +0200 Falko Schmidt [EMAIL PROTECTED] babbled: On Thu, Mar 30, 2006 at 08:13:09AM -0800, Blake B. wrote: On Mar 30, 2006, at 6:12 AM, Carsten Haitzler (The Rasterman) wrote: ok. i think i might have to poke my finger into it all too - i notice some totally outrageous build requirements (ecore REQUIRES libdiretfb? no - it's optional and i don't think we should be shipping it as then the final e install will drag in dfb w2hen actually no apps use it - it's there for special case development). also packages need splitting up into more fine-grained lumps Definitely. Evas needs to be done this way too. I didn't notice the directfb requirement in there, I build without it. I think xstasi must have added it because his repository has support for it (and a back-ported directfb package) if there're no objections i'll split libecore0 into the following packages (which will hopefully fix the dependency issues as well): libecore0 libecore0-config libecore0-con libecore0-dbus libecore0-directfb libecore0-evas libecore0-fb libecore0-file libecore0-ipc libecore0-job libecore0-txt libecore0-x are there packages which can be merged into one? i like the split this way. it gives fine-grained control. auto- dependency resolving will make sure the right subset is installed. Cool, will libecore be a virtual package for all of them? Or something like libecore-all? good question. as it is now, libecore0 just contains the basic infrastructure for the rest: [...] ./usr/share/ecore ./usr/share/ecore/fonts ./usr/share/ecore/fonts/fonts.alias ./usr/share/ecore/fonts/fonts.dir ./usr/share/ecore/fonts/Vera.ttf ./usr/share/ecore/fonts/VeraBd.ttf ./usr/share/ecore/fonts/VeraBI.ttf ./usr/share/ecore/fonts/VeraIt.ttf ./usr/share/ecore/fonts/VeraMoBd.ttf ./usr/share/ecore/fonts/VeraMoBI.ttf ./usr/share/ecore/fonts/VeraMoIt.ttf ./usr/share/ecore/fonts/VeraMono.ttf ./usr/share/ecore/fonts/VeraSe.ttf ./usr/share/ecore/fonts/VeraSeBd.ttf ./usr/lib ./usr/lib/libecore.so.1.0.0 ./usr/lib/libecore.so.1 the fonts remain another issue (see last mail). this stuff should go away. ecore should get an ecore-debug package (look what i did with eet) which includes ecore_test, ecore_evas_test and the share files above (as ecore_evas_test is the only thing that uses them). ecore_confg should also be put into another package maybe ecore-util-config by itself as a utility tool for fiddling with ecore configs. a buildrequires may suck it in for build time for example. this should be done with evas too and all packages that contain these binaries that are PRIMARILY library packages BUT also may include binaries. edje is another example. u want an edje-debug (which included edje and edje_test and all the font/png/edc/edj etc. files) an edje-cc (which included edje_cc, edje_decc, edje_recc and the edje.inc file). also embryo is similar (embryo in embryo-debug, the default.inc and embryo_cc in embryo-cc package). i could add a virtual libecore0-all package but that shouldn't hold us back from adjusting proper specific ecore dependencies of apps/e, apps/entrance and so on. ditto for evas when it's ready, of course. if the previous commit in ecore is ok then i'll look into apps and libs which use ecore and fix the deps there. libecore0-dev will contain all available headers, as it is right now. or should i split that one, too? it will have to suck in all the above libs then. I think this is fine, since IMO anyone wouldn't be doing much development with only one specific subsystem of ecore. And not to mention maintaining all those different packages for -dev AND lib will be a pain. i totally agree. Falko --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ 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 (東京 日本) --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ enlightenment-devel mailing list
Re: [E-devel] Re: E CVS: libs/ecore raster
On Thu, 30 Mar 2006 08:13:09 -0800 Blake B. [EMAIL PROTECTED] babbled: On Mar 30, 2006, at 6:12 AM, Carsten Haitzler (The Rasterman) wrote: ok. i think i might have to poke my finger into it all too - i notice some totally outrageous build requirements (ecore REQUIRES libdiretfb? no - it's optional and i don't think we should be shipping it as then the final e install will drag in dfb w2hen actually no apps use it - it's there for special case development). also packages need splitting up into more fine-grained lumps Definitely. Evas needs to be done this way too. I didn't notice the directfb requirement in there, I build without it. I think xstasi must have added it because his repository has support for it (and a back-ported directfb package) aaah. i think a dfb enabled ecore is certainly an option - but shouldn't be a general case imho :) if there're no objections i'll split libecore0 into the following packages (which will hopefully fix the dependency issues as well): libecore0 libecore0-config libecore0-con libecore0-dbus libecore0-directfb libecore0-evas libecore0-fb libecore0-file libecore0-ipc libecore0-job libecore0-txt libecore0-x are there packages which can be merged into one? i like the split this way. it gives fine-grained control. auto- dependency resolving will make sure the right subset is installed. Cool, will libecore be a virtual package for all of them? Or something like libecore-all? well there is a libecore as such already... i'd say libecore-all can be that. libecore0-dev will contain all available headers, as it is right now. or should i split that one, too? it will have to suck in all the above libs then. I think this is fine, since IMO anyone wouldn't be doing much development with only one specific subsystem of ecore. And not to mention maintaining all those different packages for -dev AND lib will be a pain. yup. the main thing is that at RUNTIME a user is not forced to suck in dependencies he/she does not need (installing e17 - they dont need/want directfb for example). if someone makes some server monitoring tool that runs on servers using ecore +ecore_ipc - they dont NEED to suck in evas, x, dfb, etc. :) -Blake -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Re: E CVS: libs/ecore raster
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Falko Schmidt [EMAIL PROTECTED] writes: libecore0-dev will contain all available headers, as it is right now. or should i split that one, too? Also, I think the xlibs-dev issue should be dealt with. see it here: http://lists.debian.org/debian-devel-announce/2005/11/msg00022.html and for details: http://lists.debian.org/debian-devel-announce/2006/01/msg3.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFELCAV+MQbLPcULsIRAkmTAKDC+vXvLQOPgPEQEiwU13oc7FZ8igCeLjZE QoZpVTYjh83AqZnJnv4e6e8= =0x6L -END PGP SIGNATURE- --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e16 - 0.16.8.1, e16keyedit - 0.3
On Thursday 30 March 2006 13:33, Kim Woelders wrote: e16 version 0.16.8.1 and e16keyedit version 0.3 are now available for download. the e page still says 0.16.7.1 :) http://enlightenment.org/Enlightenment/Get_Enlightenment/ -mike --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] FC5 X.org X11R7 with entrance
I am not able to use the same tricks of integrating entrance in to FC5 that I had used for FC4. I think it may be that X11R7 its modular approach is what is different. From the FC5 release notes: 21.3. X.org X11R7 Developer Overview The following list includes some of the more visible changes for developers in X11R7: The entire buildsystem has changed from |imake| to the GNU |autotools| collection. Libraries now install |pkgconfig| |*.pc| files, which should now always be used by software that depends on these libraries, instead of hard coding paths to them in |/usr/X11| |R6/lib | or elsewhere. Everything is now installed directly into |/usr| instead of |/usr/X11| |R6|. All software that hard codes paths to anything in |/usr/X11| |R6| must now be changed, preferably to dynamically detect the proper location of the object. Developers are *strongly* advised against hard-coding the new X11R7 default paths. Every library has its own private source RPM package, which creates a runtime binary subpackage and a |-devel| subpackage. == On boot cannot seem to find display. No locked up keyboard, just flashing display with text warnings. Is entrance looking for love in all the wrong places? How about the make-install script? X appears to now be in /usr/bin for FC5. Didier: Curious to know how you got around this with the rpm package. Sym link hack? --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
