Re: [E-devel] Strange warnings & compiling errors
On Fri, 06 Jan 2006 21:44:24 -0700 "Nathan A. Smith" <[EMAIL PROTECTED]> babbled: > On Fri, 2006-01-06 at 22:18 +0900, Carsten Haitzler wrote: > > On Sun, 01 Jan 2006 09:35:03 -0700 "Nathan A. Smith" <[EMAIL PROTECTED]> > > babbled: > > > > > On Sun, 2006-01-01 at 17:34 +0900, David Stevenson wrote: > > > > > > > > > > > > On 1/1/06, Nathan A. Smith <[EMAIL PROTECTED]> wrote: > > > > Hi guys, > > > > > > > > I have recently noticed I am getting a lot of strange (to me) > > > > compiling > > > > errors and warnings. I was hoping I could get one of you > > > > smart people > > > > to point me in the right direction to fix them. > > > > > > > > the warnings (I started getting them when compiling evas -- > > > > and > > > > everthing that followed) > > > > > > > > an example follows: > > > > > > > > ecore_value.c:31: warning: redeclaration of > > > > 'ecore_prime_table' with > > > > different visibility (old visibility preserved) > > > > Ecore_Data.h:41: warning: previous declaration of > > > > 'ecore_prime_table' > > > > was here > > > > > > > > > > > > These warnings would be repeated for different lines more than > > > > a hundred > > > > times -- no kidding. > > > > > > > > I was seeing those too when I rebuilt everything earlier today. > > > > > > > > Further, e17 was seg'ing when the moon module's e_modapi_shutdown > > > > function was called. I think this was a result of the visibility > > > > changes ,.. not sure though. > > > > > > > > Anyway when I rebuilt the moon module, those visibility warnings were > > > > appearing there too, so I > > > > 1) mimicked raster's EAPI changes from 4 days ago into the moon's > > > > e_mod_main.h, and additionally > > > > 2) found that putting "EAPI" in front of all the module api function > > > > declarations in e_mod_main.c got rid of the warnings as well. > > > > > > > > I tried using both these gcc versions: > > > > gcc (GCC) 3.3.6 (Debian 1:3.3.6-10) > > > > gcc (GCC) 4.0.3 20051201 (prerelease) (Debian 4.0.2-5) > > > > ...and there are no more warnings with either after making those > > > > changes... > > > > > > > > I don't understand all this too well, so hopefully someone who does > > > > can confirm that these EAPI changes in e_mod_main.c were the right > > > > thing to do. > > > > Anybody? > > > > (If so I'll make a new version of the moon module with these changes > > > > shortly, for any moon module fans) > > > > > > > for evas: > > > > > > Vincent's suggestion of removing line 17 from > > > evas_common.h (in ../evas/src/lib/include/) does allow evas to compile. > > > I will have to look for similar lines in other libraries -- and talk to > > > Raster to see if this would be a good fix. > > > > remeber - they are just WARNINGS - we need to go over api calls and put > > EAPI's in the .c files in front of the fn calls marked as externally > > accessible api calls (EAPI) and thew warnings go away - it's harmless until > > then. the build problems are other things. related - but not the warnings > > themselves. we need to fix this as efl has been broken all along in many > > places but no one ever tried to turn this feature of gcc4 (and above) on at > > all (it's a good feature too!) > > Actually I was referring to the compiling errors I have been getting > > As an example: > ecore_value.o -L/opt/e17/lib -lm -ldl -Wl,-soname -Wl,libecore.so.1 > -o .libs/libecore.so.1.0.0 > /usr/bin/ld: .libs/ecore_main.o: relocation R_X86_64_PC32 against > `finite@@GLIBC_2.2.5' can not be used when making a shared object; > recompile with -fPIC > /usr/bin/ld: final link failed: Bad value > collect2: ld returned 1 exit status > > This went away with Vincent's suggestion... this has to do with pragma's turning on symbol hiding before system headers were included. that has been fixed. if you find more - let us know and we will fix them as they don't turn up here. something with your system headers makes them break where they don't here. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl on MinGw
On Fri, 06 Jan 2006 23:56:20 +0100 Michel Briand <[EMAIL PROTECTED]> babbled: > Hi, and happy new year ;) > > I would add something on that topic, having tested and worked a long time with > this configuration: Cygwin/X works very well as a good X server on your little > sister's computer ;)... > > I use Cygwin/X for many month without trouble, I rebuild Imlib2 and a lot of > Open Source applications (even OpenGL programs with the last Cygwin/X with GLX > support)... > > So I would say that this combo is good enough for production use. > > E16 is running in Cygwin/X > (http://cuco.pwp.blueyonder.co.uk/desktop/e-cygwin.png). > > Strickly speeking E17 have to be build & tested on Windows before saying that > you could use them but I don't see any major blocking issue. > > Raster: what's the status of Evas's win32 rendering engine ? I see empty files > in the appropriate directory ;)... and until someone fills them in... that's all you'll see :) status: not there. not being worked on. > Since Evas is the heart of all things in E17 that the main focal point to > investigate. even if evas worked - e17 wouldnt as its an X wm - wm's are x specific. u'd need to write a new app for win32 - but for apps it might be possible with an ecore_win32 and ecore_evas wrapper - ewl wrapper too etc. > Regarding MinGw I see it as a buddle offering an X server, a Window Manager > and a widget API. So I would discourage a merge of EFL in it : it could be > boring and not so productive. win32 is defintiely NOT my focus point ... so i can't say. i'll leave this all up to he win32 guys :) > What do you think? > > Best regards, > Michel > > > Carsten Haitzler (The Rasterman) a écrit : > > On Tue, 3 Jan 2006 13:57:37 -0600 Benoit DECHERF <[EMAIL PROTECTED]> > > babbled: > > > > > >>ups... software_qtopia doesn't work on windows ? > > > > > > err .. no? qtopia is the EMBEDDED GUI from trolltech based 99% on qt. there > > is no "windows native" display system for efl - you could install an > > xswerver abnd xlibs and use an xserver under windows though - in theory :) > > > > > >>I still have a lot of problems for compiling the library. I'm not > >>realy intersting on porting efl on windows. I just want to use EFL to > >>develop cross platform aplications. > >> > >>Could you publish ths binary of EFL ? Or describe how to compile it ? > >>(with all library you need to install first :) ). > >> > >>thank you. > >> > >> > >> > >>2006/1/3, Tilman Sauerbeck <[EMAIL PROTECTED]>: > >> > >>>Benoit DECHERF [2006-01-02 17:20]: > >>> > Someone has compile efl on MinGw ? > >>> > >>>Yes. Mind there's no Evas engine for win32, so it's prolly a bit boring > >>>;) > >>> > >>> > I just compile eet, but I had to change fnmatch because i can't find > this include for MinGw. Does it exist ? Where Can I find it ? > >>> > >>>http://claws.sylpheed.org/win32/sylpheed/fnmatch-dev-2003.8.25.0.zip > >>>Power of Google etc. > >>> > >>>Regards, > >>>Tilman > >>> > >>>-- > >>>GnuPG key available at > >>>http://code-monkey.de/files/tsauerbeck-public-key.asc > >>> > >>> > >>> > >> > >> > >>--- > >>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > >>for problems? Stop! Download the new AJAX search engine that makes > >>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > >>http://ads.osdn.com/?ad_idv37&alloc_id865&opÌk > >>___ > >>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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] add menu items through modules
On Sat, 07 Jan 2006 04:24:35 +0100 Morten Nilsen <[EMAIL PROTECTED]> babbled: > David Seikel wrote: > > Even if e_menu_category_callback_set() with the callback set to NULL was > > implemented, there is no unique parameter in the function that would > > identify which callback to remove. There way be multiple callbacks > > registered, that's why they are all added to a list. And that's why we > > usually call them add(). > > yes, when you add that bit of tale, I agree :) _set() lead me to believe > the function only set one unique callback.. that indeed is almsot always the case in EFL. _set() will set 1 and 1 only item (be it a callback, string, integer, boolean etc.) and _add() and _del() imply there is a list of them to add to or delete from. :) so yes. i agree with dave (fangie) :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Strange warnings & compiling errors
On Fri, 2006-01-06 at 22:18 +0900, Carsten Haitzler wrote: > On Sun, 01 Jan 2006 09:35:03 -0700 "Nathan A. Smith" <[EMAIL PROTECTED]> > babbled: > > > On Sun, 2006-01-01 at 17:34 +0900, David Stevenson wrote: > > > > > > > > > On 1/1/06, Nathan A. Smith <[EMAIL PROTECTED]> wrote: > > > Hi guys, > > > > > > I have recently noticed I am getting a lot of strange (to me) > > > compiling > > > errors and warnings. I was hoping I could get one of you > > > smart people > > > to point me in the right direction to fix them. > > > > > > the warnings (I started getting them when compiling evas -- > > > and > > > everthing that followed) > > > > > > an example follows: > > > > > > ecore_value.c:31: warning: redeclaration of > > > 'ecore_prime_table' with > > > different visibility (old visibility preserved) > > > Ecore_Data.h:41: warning: previous declaration of > > > 'ecore_prime_table' > > > was here > > > > > > > > > These warnings would be repeated for different lines more than > > > a hundred > > > times -- no kidding. > > > > > > I was seeing those too when I rebuilt everything earlier today. > > > > > > Further, e17 was seg'ing when the moon module's e_modapi_shutdown > > > function was called. I think this was a result of the visibility > > > changes ,.. not sure though. > > > > > > Anyway when I rebuilt the moon module, those visibility warnings were > > > appearing there too, so I > > > 1) mimicked raster's EAPI changes from 4 days ago into the moon's > > > e_mod_main.h, and additionally > > > 2) found that putting "EAPI" in front of all the module api function > > > declarations in e_mod_main.c got rid of the warnings as well. > > > > > > I tried using both these gcc versions: > > > gcc (GCC) 3.3.6 (Debian 1:3.3.6-10) > > > gcc (GCC) 4.0.3 20051201 (prerelease) (Debian 4.0.2-5) > > > ...and there are no more warnings with either after making those > > > changes... > > > > > > I don't understand all this too well, so hopefully someone who does > > > can confirm that these EAPI changes in e_mod_main.c were the right > > > thing to do. > > > Anybody? > > > (If so I'll make a new version of the moon module with these changes > > > shortly, for any moon module fans) > > > > > for evas: > > > > Vincent's suggestion of removing line 17 from > > evas_common.h (in ../evas/src/lib/include/) does allow evas to compile. > > I will have to look for similar lines in other libraries -- and talk to > > Raster to see if this would be a good fix. > > remeber - they are just WARNINGS - we need to go over api calls and put EAPI's > in the .c files in front of the fn calls marked as externally accessible api > calls (EAPI) and thew warnings go away - it's harmless until then. the build > problems are other things. related - but not the warnings themselves. we need > to fix this as efl has been broken all along in many places but no one ever > tried to turn this feature of gcc4 (and above) on at all (it's a good feature > too!) Actually I was referring to the compiling errors I have been getting As an example: ecore_value.o -L/opt/e17/lib -lm -ldl -Wl,-soname -Wl,libecore.so.1 -o .libs/libecore.so.1.0.0 /usr/bin/ld: .libs/ecore_main.o: relocation R_X86_64_PC32 against `finite@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status This went away with Vincent's suggestion... Nasa > > > Nasa > > > > > > > > > Nothing like a little fun to start the new year :-) > > > > > > > > > which finally lead to this error: > > > > > > /usr/bin/ld: .libs/ecore.o: relocation R_X86_64_PC32 against > > > `setlocale@@GLIBC_2.2.5' can not be used when making a shared > > > object; > > > recompile with -fPIC > > > /usr/bin/ld: final link failed: Bad value > > > > > > This I did not see. > > > > > > Regards! > > > David > > > > > > > > > > > > > > --- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > > for problems? Stop! Download the new AJAX search engine that makes > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > > ___ > > 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 spons
Re: [E-devel] [PATCH] add menu items through modules
David Seikel wrote: Even if e_menu_category_callback_set() with the callback set to NULL was implemented, there is no unique parameter in the function that would identify which callback to remove. There way be multiple callbacks registered, that's why they are all added to a list. And that's why we usually call them add(). yes, when you add that bit of tale, I agree :) _set() lead me to believe the function only set one unique callback.. -- Morten :wq --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] add menu items through modules
On Sat, 07 Jan 2006 04:01:23 +0100 Morten Nilsen <[EMAIL PROTECTED]> wrote: > David Seikel wrote: > > e_menu_category_callback_del(). > > wouldn't that be semantically equal to calling > e_menu_category_callback_set() with the callback set to NULL ? If the e_menu_category_callback_set() code knew what to do with NULL - a) it doesn't, it will just create a new callback item, set the callback pointer in it to NULL, and add it to the list. I haven't figured out what will happen when it comes time to call that callback, but the old callback item is still on the list, and will still get called, and will still crash if it's code has been unloaded from ram. b) consistency is good, most other callback systems in E17 offer an add() and a del() function. Even if e_menu_category_callback_set() with the callback set to NULL was implemented, there is no unique parameter in the function that would identify which callback to remove. There way be multiple callbacks registered, that's why they are all added to a list. And that's why we usually call them add(). pgpSNwKJ4EloV.pgp Description: PGP signature
Re: [E-devel] [PATCH] add menu items through modules
David Seikel wrote: e_menu_category_callback_del(). wouldn't that be semantically equal to calling e_menu_category_callback_set() with the callback set to NULL ? -- Morten :wq --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] add menu items through modules
On Wed, 4 Jan 2006 01:32:05 +0100 Jorge Luis Zapata Muga
<[EMAIL PROTECTED]> wrote:
> on the client (modules, or whatever)
>
> 1. e_menu_category_callback_set("fileman/action", _callback_create,
> _callback_free, local_data);
Big problem here. After a module has set the callback, if the module
gets unloaded, the callback can still get called, which will crash E
since that callbacked code in the module no longer exists. There needs
to be a way to remove the modules callback when the module is disabled.
Maybe change e_menu_category_callback_set() to
e_menu_category_callback_add(), then write
e_menu_category_callback_del().
Other than that, it's working well in the emu module.
pgpzSXs59MPcL.pgp
Description: PGP signature
Re: [E-devel] [PATCH] add menu items through modules
On Wed, 4 Jan 2006 01:32:05 +0100 Jorge Luis Zapata Muga <[EMAIL PROTECTED]> wrote: > hi all, here i attach the patch wich will add the functionality to add > menu items outside the main routines of creating the menu. the idea is > basically this: Cool, this is something that is needed by the emu module. Now that it is committed, I'll start using it straight away. pgpFPGHhAP9HZ.pgp Description: PGP signature
[E-devel] Re: E CVS: apps/e codewarrior
> Enlightenment CVS committal > > Author : codewarrior > Project : e17 > Module : apps/e > > Dir : e17/apps/e/src/bin > > > Modified Files: > e.h e_fileman_file.c e_fileman_file.h e_fileman_icon.c > e_fileman_smart.c e_fileman_smart.h e_int_border_menu.c > e_int_menus.c e_menu.c e_menu.h > > > Log Message: > -Efm: > - cleanups > - patch from Jose for menus. > - patch from Mista for Open With and other misc. > > Ack! sorry about that, patch from Jorge (not Jose)! (= -- Hisham Mardam Bey MSc (Computer Science) http://hisham.cc/ +9613609386 Codito Ergo Sum (I Code Therefore I Am) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] add menu items through modules
Applied.
On 1/4/06, Jorge Luis Zapata Muga <[EMAIL PROTECTED]> wrote:
> hi all, here i attach the patch wich will add the functionality to add
> menu items outside the main routines of creating the menu. the idea is
> basically this:
>
> on the function where the e_menu_new is called
>
> 1. set the category of the menu (i.e "fileman/action")
> 2. set some data to be passed to every callback that registers with
> this category
>
>
> on the client (modules, or whatever)
>
> 1. e_menu_category_callback_set("fileman/action", _callback_create,
> _callback_free, local_data);
>
> callback_create: will be called when the menu is activated will
> receive the menu, the category data and local_data. here you have to
> create the menu item or do whatever you want to do
> callback_delete: will be called when the menu is freed, will receive
> the local data
>
> and thats it. some advice, the logic on the create-free should be the
> same as in other parts of the e code, set some condition before the
> menu item is going to be created or you will end with duplicate items
>
>
> implementation:
> a hash for the menus categories, the data is the E_Menu_Category wich
> have a list of callbacks. when a menu is activated it checks the
> category of the menu, find the category in the hash and call all the
> callbacks on the list. the same procedure to the delete callback but
> when the menu is freed.
>
> notes:
> all the menu items are created as usual, appended to the list of
> items, the problem is that they will always appear at the end of the
> menu. maybe should be done some kind of fixed positoin where to put
> this items, or better be able to mark some items as fixed at the
> end-beginning
>
> ive already tested, and it does work, but any discussion, comments
> would be appreciated.
>
> thanks.
>
>
>
--
Hisham Mardam Bey
MSc (Computer Science)
http://hisham.cc/
+9613609386
Codito Ergo Sum (I Code Therefore I Am)
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efm patch
On 1/6/06, mista <[EMAIL PROTECTED]> wrote: > I started making the open-with menu. Should I make the items with > toggles and the last chosen app is then used for the normal open-item? > I changed the code for key selection with control set. It now gets less > messed up when selecting back and forth, but its not perfect. I thought > about making a direct lookup for icons by coordinates, as it could make > the selection-logic more simple. > Applied. > To me the naming-scheme for icons and files seems a bit inconsistent. > The List of E_Fm_Icon is called sd->files and then it includes a file- > and an icon-object, sometimes its reffered to as selection.current.file > and more often as icon. Is it grown or planned like that? If this is not > planned, I would like to rename it to E_Fm_Item and sd->items and all > function that work on E_Fm_Item and not on E_Fm_File or e_fileman_icon´s > smartdata. I can wait with that, but it would have been much easier for > me to understand the code. > Might be logical, but lets leave it for now. -- Hisham Mardam Bey MSc (Computer Science) http://hisham.cc/ +9613609386 Codito Ergo Sum (I Code Therefore I Am) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl on MinGw
Hi, and happy new year ;) I would add something on that topic, having tested and worked a long time with this configuration: Cygwin/X works very well as a good X server on your little sister's computer ;)... I use Cygwin/X for many month without trouble, I rebuild Imlib2 and a lot of Open Source applications (even OpenGL programs with the last Cygwin/X with GLX support)... So I would say that this combo is good enough for production use. E16 is running in Cygwin/X (http://cuco.pwp.blueyonder.co.uk/desktop/e-cygwin.png). Strickly speeking E17 have to be build & tested on Windows before saying that you could use them but I don't see any major blocking issue. Raster: what's the status of Evas's win32 rendering engine ? I see empty files in the appropriate directory ;)... Since Evas is the heart of all things in E17 that the main focal point to investigate. Regarding MinGw I see it as a buddle offering an X server, a Window Manager and a widget API. So I would discourage a merge of EFL in it : it could be boring and not so productive. What do you think? Best regards, Michel Carsten Haitzler (The Rasterman) a écrit : > On Tue, 3 Jan 2006 13:57:37 -0600 Benoit DECHERF <[EMAIL PROTECTED]> babbled: > > >>ups... software_qtopia doesn't work on windows ? > > > err .. no? qtopia is the EMBEDDED GUI from trolltech based 99% on qt. there is > no "windows native" display system for efl - you could install an xswerver > abnd > xlibs and use an xserver under windows though - in theory :) > > >>I still have a lot of problems for compiling the library. I'm not >>realy intersting on porting efl on windows. I just want to use EFL to >>develop cross platform aplications. >> >>Could you publish ths binary of EFL ? Or describe how to compile it ? >>(with all library you need to install first :) ). >> >>thank you. >> >> >> >>2006/1/3, Tilman Sauerbeck <[EMAIL PROTECTED]>: >> >>>Benoit DECHERF [2006-01-02 17:20]: >>> Someone has compile efl on MinGw ? >>> >>>Yes. Mind there's no Evas engine for win32, so it's prolly a bit boring >>>;) >>> >>> I just compile eet, but I had to change fnmatch because i can't find this include for MinGw. Does it exist ? Where Can I find it ? >>> >>>http://claws.sylpheed.org/win32/sylpheed/fnmatch-dev-2003.8.25.0.zip >>>Power of Google etc. >>> >>>Regards, >>>Tilman >>> >>>-- >>>GnuPG key available at >>>http://code-monkey.de/files/tsauerbeck-public-key.asc >>> >>> >>> >> >> >>--- >>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files >>for problems? Stop! Download the new AJAX search engine that makes >>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >>http://ads.osdn.com/?ad_idv37&alloc_id865&op$([EMAIL PROTECTED](Bk >>___ >>enlightenment-devel mailing list >>enlightenment-devel@lists.sourceforge.net >>https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > > --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Re: E CVS: libs/ecore kwo
On Fri, 06 Jan 2006 13:56:06 -0800 enlightenment-cvs@lists.sourceforge.net wrote: > Enlightenment CVS committal > > Author : kwo > Project : e17 > Module : libs/ecore > > Dir : e17/libs/ecore/src/lib/ecore_x > > > Modified Files: > ecore_x.c ecore_x_dnd.c ecore_x_icccm.c ecore_x_mwm.c > ecore_x_netwm.c > > > Log Message: > Fix warnings. Thanks for that. raster told me to be cautious, and those ones where not covered by his other instructions, so I didn't do them. I think he wanted evas done to. pgpc6r5Ad6g0n.pgp Description: PGP signature
Re: [E-devel] efm patch
I started making the open-with menu. Should I make the items with
toggles and the last chosen app is then used for the normal open-item?
I changed the code for key selection with control set. It now gets less
messed up when selecting back and forth, but its not perfect. I thought
about making a direct lookup for icons by coordinates, as it could make
the selection-logic more simple.
To me the naming-scheme for icons and files seems a bit inconsistent.
The List of E_Fm_Icon is called sd->files and then it includes a file-
and an icon-object, sometimes its reffered to as selection.current.file
and more often as icon. Is it grown or planned like that? If this is not
planned, I would like to rename it to E_Fm_Item and sd->items and all
function that work on E_Fm_Item and not on E_Fm_File or e_fileman_icon´s
smartdata. I can wait with that, but it would have been much easier for
me to understand the code.
regards,
jeff
Index: e_fileman_file.c
===
RCS file: /root/e17/apps/e/src/bin/e_fileman_file.c,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 e_fileman_file.c
12,17c12
< typedef struct _E_Fm_Assoc_App E_Fm_Assoc_App;
< struct _E_Fm_Assoc_App
< {
49a45
> char *ext;
80c76
mode))
---
>if (S_ISDIR(file->mode)){
81a78,79
> file->mime = "directory";
> }
98a97,106
> if(!file->mime)
> {
> ext = strrchr(file->name, '.');
> if (ext)
> {
> file->mime = ext;
> }
> else
> file->mime = "unknown";
> }
330a339,340
>
>
420a431,454
> int e_fm_file_exec_with(E_Fm_File *file, char* exec_with)
> {
> Ecore_Exe *exe;
>char app[PATH_MAX * 2];
>if (!exec_with || !file) return 0;
>
>snprintf(app, PATH_MAX * 2, "%s \"%s\"", exec_with, file->path);
>exe = ecore_exe_run(app, NULL);
>
>if (!exe)
>{
> e_error_dialog_show(_("Run Error"),
> _("3 Enlightenment was unable fork a child process:\n"
> "\n"
> "%s\n"
> "\n"),
> app);
> return 0;
>}
> }
>
>
>
>
428a463
> ///??? if (file->mime) free(file->mime);
431a467
>
Index: e_fileman_file.h
===
RCS file: /root/e17/apps/e/src/bin/e_fileman_file.h,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 e_fileman_file.h
39a40
> char *mime;/* mimetype (just the extension) */
68a70
> EAPI int e_fm_file_exec_with (E_Fm_File *file, char* exec_with);
Index: e_fileman_smart.c
===
RCS file: /root/e17/apps/e/src/bin/e_fileman_smart.c,v
retrieving revision 1.1.1.41
diff -r1.1.1.41 e_fileman_smart.c
90c90
<
---
> typedef enum _E_Fm_State E_Fm_State;
94c94,95
int height;
>Evas_List *apps;
142a144,151
> enum _E_Fm_State
> {
>E_FILEMAN_STATE_IDLE = 0,
>E_FILEMAN_STATE_TYPEBUFFER = 1,
>E_FILEMAN_STATE_RENAME = 2,
> };
>
>
163a173,174
>Evas_Hash *mime_menu_hash;
>
176c187,189
<
---
>
>E_Fm_State state;
> // E_Fm_Icon *active_file;
252a266,267
> static void_e_fm_file_rename_start(E_Fm_Icon *icon);
> static void _e_fm_file_rename_abort(E_Fm_Icon *icon);
314c329
<
---
> static int _e_fm_init_assoc(E_Fm_Smart_Data *sd);
379a395
>
614a631,683
>
>
> int
> _e_fm_init_assoc(E_Fm_Smart_Data *sd)
> {
> E_Fm_Assoc_App *assoc;
>
> assoc = E_NEW(E_Fm_Assoc_App, 1);
> assoc->mime = (char*)E_NEW(char *, 5);
> snprintf(assoc->mime, 5, "%s", ".jpg");
> assoc->app = (char*)E_NEW(char *, 7);
> snprintf(assoc->app, 5, "gimp");
> sd->conf.main->apps = evas_list_append(sd->conf.main->apps, assoc);
>
> assoc = E_NEW(E_Fm_Assoc_App, 1);
> assoc->mime = (char*)E_NEW(char *, 5);
> snprintf(assoc->mime, 5, "%s", ".jpg");
> assoc->app = (char*)E_NEW(char *, 7);
> snprintf(assoc->app, 8, "exhibit");
> sd->conf.main->apps = evas_list_append(sd->conf.main->apps, assoc);
>
> assoc = E_NEW(E_Fm_Assoc_App, 1);
> assoc->mime = (char*)E_NEW(char *, 5);
> snprintf(assoc->mime, 5, "%s", ".png");
> assoc->app = (char*)E_NEW(char *, 7);
> snprintf(assoc->app, 5, "gimp");
> sd->conf.main->apps = evas_list_append(sd->conf.main->apps, assoc);
>
> assoc = E_NEW(E_Fm_Assoc_App, 1);
> assoc->mime = (char*)E_NEW(char *, 5);
> snprintf(assoc->mime, 5, "%s", ".png");
> assoc->app = (char*)E_NEW(char *, 7);
> snprintf(assoc->app, 8, "exhibit");
> sd->conf.main->apps = evas_list_append(sd->conf.main->apps, assoc);
>
> assoc = E_NEW(E_Fm_Assoc_App, 1);
> assoc->mime = (char*)E_NEW(char *, 5);
> snprintf(assoc->mime, 5, "%s", ".pdf");
> assoc->app = (char*)E_NEW(char *, 7);
> snprintf(assoc->app, 7, "evince");
> sd->conf.main->apps = evas_list_append(sd->conf.main->apps, assoc);
>
Re: [E-devel] efl on MinGw
On Tue, 3 Jan 2006 19:54:20 +0100 Tilman Sauerbeck <[EMAIL PROTECTED]> babbled: > Benoit DECHERF [2006-01-02 17:20]: > > Someone has compile efl on MinGw ? > > Yes. Mind there's no Evas engine for win32, so it's prolly a bit boring > ;) > > > I just compile eet, but I had to change fnmatch because i can't find > > this include for MinGw. Does it exist ? Where Can I find it ? > > http://claws.sylpheed.org/win32/sylpheed/fnmatch-dev-2003.8.25.0.zip > Power of Google etc. mm - a power which very few peolpe seem to use! :) > Regards, > Tilman > > -- > GnuPG key available at > http://code-monkey.de/files/tsauerbeck-public-key.asc > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evas_object_image_data_set() crash with directfb engine
On Thu, 29 Dec 2005 00:30:20 +0100 Jorge Luis Zapata Muga <[EMAIL PROTECTED]> babbled: > -- Forwarded message -- > From: Jorge Luis Zapata Muga <[EMAIL PROTECTED]> > Date: Dec 29, 2005 12:23 AM > Subject: Re: [E-devel] evas_object_image_data_set() crash with directfb engine > To: Jason Tackaberry <[EMAIL PROTECTED]> > > > On 12/28/05, Jason Tackaberry <[EMAIL PROTECTED]> wrote: > > I am getting a segfault when calling evas_object_image_data_set() using > > the directfb engine. Looking at the source for the engine, I can see > > what the problem is, but I'm not entirely sure how to fix it. > > > > The problem is that evas_engine_directfb_image_new_from_copied_data() > > frees the image_data buffer passed to it. The expectation, it seems, is > > that the buffer is to be gotten from > > evas_engine_directfb_image_data_get(). But, as in my case, if the > > buffer is created by the application (outside of evas), it's not correct > > for evas to free it. Judging by the FIXME comment just above the call > > to free, I'm willing to bet whoever wrote this code knew that too. > > > > The best solution would be for dfb to be able to support external > > buffers. Judging by the fact that > > evas_engine_directfb_image_new_from_data() simply calls > > evas_engine_directfb_image_new_from_copied_data(), I'm guessing that > > this isn't supported by dfb. > > dfb does support an image provider from an external buffer. > IDirectFBDataBuffer is the interface, there you have the method > CreateImageProvider from it (if i understand correctly what you are > saying) > > > > > > A sensible workaround to this problem would be for the engine to > > remember the pointer created in data_get() for that image. Subsequent > > calls to data_get() will reuse that pointer if the image size is the > > same as the last call. If the image size is different, data_get will > > free the old buffer and allocate a new one. Then, when the engine shuts > > down, evas_engine_directfb_output_free will free any memory that's been > > allocated from data_get(). > > > > Perhaps someone could suggest a better solution? > > > > the current dfb engine is kind of old compared to the other engines > (mainly xrender,software_x11, fb) and it lacks for several features > others have (i.e load eet-edb files to work with edje) ive made a > new one that you can find on > http://arraydev.net/~jl/directfb_engine.tar.gz copy the files on the > directfb engine directory and tell me if it works correctly. > > > > Also, in general, how well maintained are the non-software_x11 engines? > > It seems to me that all the other engines (except for the buffer engine, > > perhaps) are really second class citizens. The GL engine has now > > reached the point where it's being disabled by default. Will it > > eventually be removed? Will the other engines also accumulate bitrot > > and gradually become disabled and eventually removed? I'd appreciate > > knowing, because I don't want to waste my own time building a solution > > on unmaintained code. > > > > as far as i see, these engines arent maintained. i sent the new > implementation to the list but the only who can check for it is > raster, and i think is quite busy to check for it. i think one > solution for this is to be able to build engines outside evas, and > modularize evas so it can load .so engines. i am currently working on > that and is working, just need to talk with raster about the exported > API. > > hope this helps you. speaking of all that... i looked over your dfb engine while on holidays - how about putting that is as part of the enigne modularisation? :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Cursor do not show properly when window is very small - minor bug
On Wed, 21 Dec 2005 22:51:35 +0100 (CET) [EMAIL PROTECTED] babbled: > I have updated E this evening, and got the same problem as last week. > > - open an Eterm with borders > - resize it VERY SMALL, some thing like maximum 3 chars width and height, > better with 2 > - release any button and ALT key > - put mouse in one lower corner, either right or left, does not matter. > - move mouse toward other low corner EXACTLY HORIZONTALLY, taking care to > keep the corsor along the decoration of window > - after a time, the cursor changes shape to the normal arrow, even if the > very opposite corner of the low border this is actually not a bug as such - it's because the resize regiosn are fixed 24x24 regions on the corners and thus one region overlaps the other and takes precedence if they overlap :) > optional: > - left clic > - you can resize and the cursor keeps the orange arrow when it should be > the black angle. > > Happens with Eterm, and any other window that can be reduce, like email > windows of ThunderBird, FireFox PopUps, Xeyes, Xclock ... > > * > > Also note with xclock that if the window is just the same width as the > 'close button' (the small cross), then cliking on the cross does not > actually close the win, but rather opens the Window menu ... > > I think thats unrelated, but seems there are several issues around 'small > windows'. > > > > --- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id865&opÌk > ___ > 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Design idea for the configuation panel (aka my two cents)
On Thu, 29 Dec 2005 16:15:28 +0100 CGA <[EMAIL PROTECTED]> babbled: > Good Day to you all e-devs and thank you for your great job =) > > As you can understand from the subject of this e-mail I'm here to suggest > you a design idea for the configuration panel, take it or leave it, it's up > to you. > Obviously *anyone* can post impressions and improvements of this idea if > they like. > > Now, i was wandering if you plan to make the configuration panel and all > the "sub-options" one monolithic window... it could be nicer to have > something as will follow, rather than to have many windows open like in this > screenie: > http://www0.get-e.org/Screenshots/User_Submitted/_images/dialogs.png -- Of > course it is not compulsory to have all of them open at one time, but this > is not the main point. The point is to have *always* one "piece" and not to > have a second (third, fourth and so on..) window opened for the config > option one choses to open. To let you understand better i'll use an example: > > My idea in example: > > #1- the config panel opens like it does now from the main menu, and opens > the "configuration panel" main window. > #2- when you click on a configuration item (let's say background settings) , > that slides off on the right of the main window (pretty much like the > eclair's cover thing) and presents you the configuration you have chosen. > (let's say background settings) in basic mode. > #2a- advanced mode might have few lines explaining the user what's all > about. > #3- if one leaves the background settings before he applied the change , > there should be a warning "save the changes?" and the likes. > #4- when one leaves the current config dialogue for another, then the first > slides back in and the second slides off afterwards. there might be room for > great eye-candy here, like eg: transparency or fade in fade out. > #5- if one clicks on the advanced settings the whole pc must implode. > #6 -whatever you like, i'm out of ideas. > > best regards and thank you again for the whole E project =) > ps: the txt attached is the log of the #edevelop chat where this started. ok. this is really a big CHANGE in how it works. and a lot fo work to do. right now i think we will opt for the "less work" option (ie - continue where we are going). we edo appreciate the effort to list this - but we're on a path and we need gui config. we can sit and chop and change - but frankly - this is a "neither way is particularly better than the other one". sure. multiple dialogs mean closign them - BUT it does allow you to play with 2 configuration items at once, where a 1 thing at a time only one means you have to keep fliping around. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Alt+Tab bug
On Wed, 4 Jan 2006 21:19:02 -0600 Nathan Ingersoll <[EMAIL PROTECTED]> babbled: > This is a well-known race condition. The last I talked to raster about it, > the fix is non-trivial and will require more work than he's willing to put > into it right now. I made a small change a while back that made the > timeframe for this to occur a little shorter, but you're right its still > very easy to trigger. actually for e17 i THINK i have found a workaround. try cvs again... > On 1/3/06, Sthithaprajna Garapaty <[EMAIL PROTECTED]> wrote: > > > > > > Sometimes, when I alt+tab very quickly(press alt+tab and release both keys > > quickly), > > the alt+tab window gets stuck and the mouse gets stuck with it. > > The mouse can only be freed by pressing alt+tab again, which also returns > > the alt+tab window to normal behavior. > > > > This happens quite often and is easily reproducable. > > > > Please fix this as soon as you can. > > > > Thanks! > > > > > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] evas_stringshare null string
On Mon, 26 Dec 2005 09:38:08 +0200 Chady Kassouf <[EMAIL PROTECTED]> babbled: > Hi, > > I encountered a segfault in e17 while playing around with desktop names: > > $ enlightenment_remote -desktop-name-add 0 0 0 0 "" > > will crash e17 > > This is a patch for evas_stringshare_(add|del) to quickly return on nulls. actually fixed at the real source (e_desk.c) :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl on MinGw
On Tue, 3 Jan 2006 13:57:37 -0600 Benoit DECHERF <[EMAIL PROTECTED]> babbled: > ups... software_qtopia doesn't work on windows ? err .. no? qtopia is the EMBEDDED GUI from trolltech based 99% on qt. there is no "windows native" display system for efl - you could install an xswerver abnd xlibs and use an xserver under windows though - in theory :) > I still have a lot of problems for compiling the library. I'm not > realy intersting on porting efl on windows. I just want to use EFL to > develop cross platform aplications. > > Could you publish ths binary of EFL ? Or describe how to compile it ? > (with all library you need to install first :) ). > > thank you. > > > > 2006/1/3, Tilman Sauerbeck <[EMAIL PROTECTED]>: > > Benoit DECHERF [2006-01-02 17:20]: > > > Someone has compile efl on MinGw ? > > > > Yes. Mind there's no Evas engine for win32, so it's prolly a bit boring > > ;) > > > > > I just compile eet, but I had to change fnmatch because i can't find > > > this include for MinGw. Does it exist ? Where Can I find it ? > > > > http://claws.sylpheed.org/win32/sylpheed/fnmatch-dev-2003.8.25.0.zip > > Power of Google etc. > > > > Regards, > > Tilman > > > > -- > > GnuPG key available at > > http://code-monkey.de/files/tsauerbeck-public-key.asc > > > > > > > > > --- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id865&opÌk > ___ > 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore_exe event type consistancy.
On Sat, 7 Jan 2006 00:35:42 +0900 Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> wrote: > i would argue that ECORE_EVENT_EXE is fine as its a CORE ecore event > (not a sub ecore system like ecore_con)... ? I'm thinking consistency in naming things IPC related. I think that merging fork'n'pipe with ecore_ipc might be good, it's just another IPC method, why should it be different? Most of the ways of dealing with it from the ecore users perspective are mostly similar. Most of the differences are simply due to current inconsistent naming and lack of an exe add event. The user doesn't see any core ecore / sub ecore issues, it's all ecore_*_whatever to them. As I said before, the naming of the exit event is historical, and I'm prepared to wear that. The data event is new though, and should be consistent with other IPC data events. It's semantics are the same, hell most of the code was just cut'n'paste from ecore_con. BTW, ecore_con could probably use a line buffered option. More consistency. With consistency comes the ability to merge almost identical code and APIs into a better whole. Things become easier for developers to use coz it's all the same. pgprDwwJnqzY4.pgp Description: PGP signature
Re: [E-devel] [patch] ecore examples..
On Mon, 02 Jan 2006 06:37:58 +0100 Morten Nilsen <[EMAIL PROTECTED]> babbled: > decided to make another, trivial, patch.. > > this fixes the config_listener and list examples. > it also tweaks the config_basic example a bit... in cvs :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] module configuration BUG
On Thu, 29 Dec 2005 23:16:58 +0100 Aleksej Struk <[EMAIL PROTECTED]> babbled: > Hi all, > > I've found one interesting bug. For example, let say, that first I launch > the configuration dialog of a module. > Second, I unload that module using enlightenment_remote. Finally, if i click > on the apply/ok button > in the configuration dialog of the module, then E crashes. definitely would happen. moduels need to delete their config dialogs on shutdown to fix this :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] patch for the visibility feature
On Fri, 6 Jan 2006 15:08:01 +0100 (CET) Vincent Torri <[EMAIL PROTECTED]> babbled: > > hey, > > it seems that there are some problems with the visibility feature and gcc > 4.*. According to the documentation (http://gcc.gnu.org/wiki/Visibility) > the pragma statement should not be used. And indeed, it seems that there > are some problems with gcc 4.0.2 and that pragma. well actually - the pragma just does the -fvisibiloity option WITHIN the code - ans that's what i did. it's turned on in the code if you have gcc4 and up. EAPI explicitly SPECIFIEs a symbol to be public and otherwise its private. > I propose that solution: > > * checking if gcc accept the vsibility feature in configure.in (i've > written a small m4 macro for that. It add -fvisibility=hidden during > compilation and it defines GCC_HASCLASSVISIBILITY) i tried using this in CFLAGS and it didnt work. thats why i used pragma. > * modifying the definition of EAPI so that it uses GCC_HASCLASSVISIBILITY > (if it's not already the case) it used to be - and didn't work. > * removing all the pragma statements. > > i've already made the changes for eet on my hard disk. Without the > visibility feature, the size of the shared library is 37162 KB. With it, > it's 36626. That is, it compiles fine and it works. well as i said - i tried with gcc 4.0.2 and it didnt work. the library STILL had all the symbols init. if u stripped it they didnt go away (strip -x is what u want) i NEEDEd to use the #pragma to make it work. > is there any objections that I commit that for eet ? > > Vincent > > > --- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > ___ > 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ 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 raster
On Sat, 7 Jan 2006 01:48:25 +1000 David Seikel <[EMAIL PROTECTED]> babbled: > Welcome back raster. Hope you had a good holiday. > > On Fri, 06 Jan 2006 07:32:41 -0800 > enlightenment-cvs@lists.sourceforge.net wrote: > > >+* BUG: IBAR follower speed and autoscroll speed are not > > pixels / sec (they are > > + recursive multiplication values). should invert gui valus and > > display as a > > + factor, not px/sec > > I kept telling him that over and over again. well it is a bit weird. but it needs fixing so it's noted down now :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ 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 raster
On Fri, 06 Jan 2006 16:27:53 +0100 Sebastian Dransfeld <[EMAIL PROTECTED]> babbled: > enlightenment-cvs@lists.sourceforge.net wrote: > > Enlightenment CVS committal > > > > Author : raster > > Project : e17 > > Module : apps/e > > > > Dir : e17/apps/e > > > > > > Modified Files: > > BUGS TODO > > > > > > Log Message: > > > > > > fix several bugs (cursors for example)... found some more... :) > > > > > +* BUG: fullscreen does not respect min/max window size > > It did respect min max size and aspect ratio, but mplayer got confused > since it wanted the wm to (at least) produce a window with the same > aspect ratio as the real screen. well now thats just bloody brilliant! stupid mplayer. grrr. why hve a min/max/aspect hint on your window and then expect fullscreening it NOT to use these? h. > Sebastian > > > --- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > ___ > 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ 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 devilhorns
On Thu, 5 Jan 2006 10:32:42 -0500 Michael Jennings <[EMAIL PROTECTED]> babbled: > On Thursday, 05 January 2006, at 22:37:37 (+0900), > David Stevenson wrote: > > > Feel free to flame me down, but I'm wondering what users think about calling > > "Window List" "Alt-Tab" instead. > > No. That would be just as silly as renaming the exit dialog the > "Ctrl-Alt-Del" dialog and the module Edit Mode the "Ctrl-Alt-G" mode. i would definitely agree :) (dont rename). definitely not in the code. in the GUI config it COULD do with maybe "window task list" or something - but alt-tab - definitely not. > Michael > > -- > Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> > n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) > --- > "To err is human; to really louse things up requires Microsoft > products." -- Alexander Pope, slightly paraphrased > > > --- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > ___ > 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] more tiff alpha weirdness
On Thu, 5 Jan 2006 12:07:12 + Simon Wistow <[EMAIL PROTECTED]> babbled: > Apparently TIFF has not one but two types of Alpha channel Associated > and UnAssociated. The premultiplication of the r,g and b channels by > 255/a on load should only be done with UnAssociated alpha channels > (which seems to be counter-intuitive to me but what the hell). > > The previous patch that Raster did for me didn't take this into account. > > Attached is a patch against CVS loader_tiff.c to fix that. > > This possibly means that line 400 (in save) should be changed to > EXTRASAMPLE_UNASSALPHA. oucdh. both premul and non premul alpha in tiff. pain! patch in cvs. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [patch]: minor e_winlist functional change
On Wed, 4 Jan 2006 00:41:56 +0900 David Stevenson <[EMAIL PROTECTED]> babbled: > Hi, > > When using the winlist functionality, if your windows are more > than half-way off a given edge of the screen (i know i know! but I only have > a 15-inch display :-) it happens) when the mouse pointer warps, it warps so > far as to cause an edge-flip to occur after the window is selected. > > The attached patch ensures the pointer is warped to the center of the part > of the window that remains visible on the desk, preventing the > edge-flipping. good point! well spotted! fixed! :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [patch] ecore_ipc deprecated ecore_list2
On Mon, 02 Jan 2006 05:28:08 +0100 Morten Nilsen <[EMAIL PROTECTED]> babbled: > probably last patch for today... (all list patches). right now i'm not entirely sure its a godo idea to move everything to ecore_list as ecore_list literally works differently, adds malloc overhead etc. it changes things that could impact performance (not very much though) and memory efficiency - so... i'd rather hold off on this. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore_exe event type consistancy.
On Thu, 5 Jan 2006 08:05:43 +1000 David Seikel <[EMAIL PROTECTED]> babbled: > While I was bringing ecore_exe fork'n'pipe into consistency with > ecore_con and ecore_ipc, I noticed a problem with the way the exe event > types are allocated and named. To make them more consistent, > ECORE_EVENT_EXE_EXIT and ECORE_EVENT_EXE_DATA should be renamed to > ECORE_EXE_EVENT_DEL and ECORE_EXE_EVENT_DATA, then be allocated with > ecore_event_type_new(). An ECORE_EXE_EVENT_ADD should be added as > well. > > ECORE_EVENT_EXE_EXIT is historical, before there where plans to add > fork'n'pipe style IPC to ecore_exe. raster was probably not thinking > of consistency when he named all the ecore_exe fork'n'pipe stuff. I > think consistency is a good idea for this though. > > Stuff that will need to be updated if I change ECORE_EVENT_EXE_EXIT - > misc/engage > e_modules/mount > e_modules/screenshot > e17/proto/exhibit > e17/apps/entrance > e17/apps/e > > evidence also uses ECORE_EVENT_EXE_EXIT, and that is a problem as I > don't think anybody that is still active has cvs write permission for > evidence. Has evidence been broken by any API changes since it went > quiet? I don't want to be the first. > > The rest of my fork'n'pipe consistency work is unlikely to bother > anyone, as no one else uses it yet. Although devilhorns tells me he > will use it today. > > So, the question is - Should I change ECORE_EVENT_EXE_EXIT for > consistency, or leave it as is for historical reasons? At the very > least I could set up an alias, and deprecate use of the original. i would argue that ECORE_EVENT_EXE is fine as its a CORE ecore event (not a sub ecore system like ecore_con)... ? -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas text object not showing
On Wed, 28 Dec 2005 13:35:19 +0200 [EMAIL PROTECTED] babbled: > Hello All! > I was really impressed from Enlightenment from screenshots so I decided > to try it. > I downloaded all important libraries from CVS (yesterday-Tuesday) and > installed everything without a problem. > E17 is now my main window manager and so far I have to say > that I am really pleased. > > Next I decided to play with EVAS programming a bit > but I have a problem with the text object. > > I have attached a minimal .c file which shows this. > The rectangle object shows up correctly but the text object does not. > I compile with: > gcc `ecore-config --libs --cflags` ecore-test.c -g -o ecore-test > > I know that it is my fault that it doesn't run. > All library tests (ecore and evas) run correctly and show up text > normally. > > I opened their code and saw how they do it but I don't see anything missing. > I tried to play with layers (in case my text was covered by the background). > This did not work. I even removed the background completely but the text still > does not show. The rectangle is always present though. > > What drives me crazy is that I suspect that the problem is trivial > and I missing something that you guys would laugh at!! > > Please enlighten me!! you need some fonts dude! :) (evas doesnt knwo what font to use or where to get it from - notice a lot of code spends time setting up font search paths and then sets font names which can be loosely used as a file.ttf minus the .ttf extension or using an x-style fonts.dir/fonts.alias directory) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [PATCH] Re: [E-devel] Font rendering regression in Imlib2
On Sat, 31 Dec 2005 02:00:40 +0100 Kim Woelders <[EMAIL PROTECTED]> babbled: > Jason Tackaberry wrote: > > On Fri, 2005-12-30 at 17:31 +0100, Kim Woelders wrote: > > > >>I think you are right that something is wrong somewhere around here. > >>However, this patch breaks stuff for certain fonts (w becomes too small, > >>IIRC). > > > > > > Ok. I have to plead a bit of ignorance when it comes to font metrics. > > But if your problem is with the width, and my original problem is with > > the height, then the naive assumption is that if we take the horizontal > > advance and the height as returned by imlib_font_query_size(), we should > > be ok. > > > > I've coded this up and it looks ok on all of my tests. Some review and > > testing is clearly needed. The patch is attached. > > > > Regards, > > Jason. > > > > > > > > > > --- imlib2-1.2.1.009.orig/src/lib/font_draw.c 2005-12-30 > > 10:49:31.0 -0500 +++ imlib2-1.2.1.009/src/lib/font_draw.c > > 2005-12-30 11:42:11.0 -0500 @@ -78,7 +78,8 @@ > > DATA32 *data, col; > > int nx, ny; > > > > - imlib_font_query_advance(fn, text, &w, &h); > > + imlib_font_query_advance(fn, text, &w, NULL); > > + imlib_font_query_size(fn, text, NULL, &h); > > > > data = malloc(w * h * sizeof(DATA32)); > > if (!data) > > I have committed attached patch. It does the same thing as your patch #2 > but avoids recalculating the width. > It is possibly also equivalent to rasters original fix if "inset" were > subtracted in stead of added. > > I think there are some more or less related bugs in the imlib2 font > metrics department. > > imlib_get_font_descent (imlib_font_descent_get) returns a positive > value, whereas imlib_get_maximum_font_descent > (imlib_font_max_descent_get) returns a negative value. > I doubt this is intentional. > > imlib_get_text_size (imlib_font_query_size) - > What is it supposed to do? > If it should return the ink size of the given text string I think the > height is wrong (currently font max ascent +(-?) font max descent). > If it should return some overall bounding box size I think the width is > wrong (currently ~= ink width?). > > imlib_text_draw_with_return_metrics probably doesn't return the intended > values in width_return and height_return. > > Unfortunately, changing any of this may cause breakage in existing apps. mmm. bugger. this must have screwed up at some point. it was always meant to return only positives for ascent AND descent (unless the font is totally weird) is as pixels above ro below the baseline of the font. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] white square 1st time resizing a window
On Wed, 21 Dec 2005 22:42:11 +0100 (CET) [EMAIL PROTECTED] babbled: > I have updated E this evening, and got the same problem as last week. > > Just after I log into E17, the very first time I want to resize a window > using a low corner, the mouse becomes a white square. > > Happens once per cession for each one of the left, and right corners. > > Sounds like init routines forget to pre-load some pixmaps. > > Seems to happen with other cursors, like maybe move or vertical resize, > but those are harder for me to get 'each time'. it's been fixed :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] follow speed
On Thu, 22 Dec 2005 12:38:26 +0100 Massimo Maiurana <[EMAIL PROTECTED]> babbled: > > looks like speed values for follower in ibar configuration are > inverted, i.e. if I set a higher value follower is slower. noted down in TODO -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Strange warnings & compiling errors
On Sun, 01 Jan 2006 09:35:03 -0700 "Nathan A. Smith" <[EMAIL PROTECTED]> babbled: > On Sun, 2006-01-01 at 17:34 +0900, David Stevenson wrote: > > > > > > On 1/1/06, Nathan A. Smith <[EMAIL PROTECTED]> wrote: > > Hi guys, > > > > I have recently noticed I am getting a lot of strange (to me) > > compiling > > errors and warnings. I was hoping I could get one of you > > smart people > > to point me in the right direction to fix them. > > > > the warnings (I started getting them when compiling evas -- > > and > > everthing that followed) > > > > an example follows: > > > > ecore_value.c:31: warning: redeclaration of > > 'ecore_prime_table' with > > different visibility (old visibility preserved) > > Ecore_Data.h:41: warning: previous declaration of > > 'ecore_prime_table' > > was here > > > > > > These warnings would be repeated for different lines more than > > a hundred > > times -- no kidding. > > > > I was seeing those too when I rebuilt everything earlier today. > > > > Further, e17 was seg'ing when the moon module's e_modapi_shutdown > > function was called. I think this was a result of the visibility > > changes ,.. not sure though. > > > > Anyway when I rebuilt the moon module, those visibility warnings were > > appearing there too, so I > > 1) mimicked raster's EAPI changes from 4 days ago into the moon's > > e_mod_main.h, and additionally > > 2) found that putting "EAPI" in front of all the module api function > > declarations in e_mod_main.c got rid of the warnings as well. > > > > I tried using both these gcc versions: > > gcc (GCC) 3.3.6 (Debian 1:3.3.6-10) > > gcc (GCC) 4.0.3 20051201 (prerelease) (Debian 4.0.2-5) > > ...and there are no more warnings with either after making those > > changes... > > > > I don't understand all this too well, so hopefully someone who does > > can confirm that these EAPI changes in e_mod_main.c were the right > > thing to do. > > Anybody? > > (If so I'll make a new version of the moon module with these changes > > shortly, for any moon module fans) > > > for evas: > > Vincent's suggestion of removing line 17 from > evas_common.h (in ../evas/src/lib/include/) does allow evas to compile. > I will have to look for similar lines in other libraries -- and talk to > Raster to see if this would be a good fix. remeber - they are just WARNINGS - we need to go over api calls and put EAPI's in the .c files in front of the fn calls marked as externally accessible api calls (EAPI) and thew warnings go away - it's harmless until then. the build problems are other things. related - but not the warnings themselves. we need to fix this as efl has been broken all along in many places but no one ever tried to turn this feature of gcc4 (and above) on at all (it's a good feature too!) > Nasa > > > > > Nothing like a little fun to start the new year :-) > > > > > > which finally lead to this error: > > > > /usr/bin/ld: .libs/ecore.o: relocation R_X86_64_PC32 against > > `setlocale@@GLIBC_2.2.5' can not be used when making a shared > > object; > > recompile with -fPIC > > /usr/bin/ld: final link failed: Bad value > > > > This I did not see. > > > > Regards! > > David > > > > > > > > --- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > ___ > 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Strange warnings & compiling errors
On Sat, 31 Dec 2005 17:02:36 -0600 Ibukun Olumuyiwa <[EMAIL PROTECTED]> babbled: > Mike Frysinger wrote: > > On Saturday 31 December 2005 10:08, Nathan A. Smith wrote: > > > >>ecore_value.c:31: warning: redeclaration of 'ecore_prime_table' with > >>different visibility (old visibility preserved) > >>Ecore_Data.h:41: warning: previous declaration of 'ecore_prime_table' > >>was here > > > > > > what version of gcc are you using ? what distro ? > > > > > >>/usr/bin/ld: .libs/ecore.o: relocation R_X86_64_PC32 against > >>`setlocale@@GLIBC_2.2.5' can not be used when making a shared object; > >>recompile with -fPIC > >>/usr/bin/ld: final link failed: Bad value > > > > > > looks like your toolchain is broken > > Not quite. Started seeing those warnings galore here too after Raster's > symbol visibility commits. Obviously GCC 4.0 doesn't like them. well more that it insists you delcare them visible in the prototype in the header AND in the code. we simply need to add an EAPI to every symbol to be made visible in the .c code (like in the .h) and the warnings vanish. since gcc takes the first header declaration as the one to use anyway it's harmless (for now) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [patch] ecore_list2 removal
On Mon, 2 Jan 2006 16:33:51 -0500 Michael Jennings <[EMAIL PROTECTED]> babbled: > On Monday, 02 January 2006, at 12:46:32 (-0600), > Nathan Ingersoll wrote: > > > I don't think there is a very cohesive plan on list use atm. I've > > heard a few rumblings of people saying "ecore lists suck" or "evas > > lists suck" but as usual it's a case of choosing the best tool for > > the job and knowing when each is appropriate. > > And thankfully the data structure names make it very clear to > developers what the basic implementation and usage considerations are > for each list type. Any idiot knows the difference between "List" and > "List2." >:I i think i need to give a small history class. this has nothng to do wi9th taking a lesson from libast. list2 was the ORIGJNAL ecore list for INTERNAL ecore use only - not as an api to be used outside of ecore. it was not called list2 then - just ecore_list - and it was there becasue there was NO DEPENDENCY that provided a linked list. it was built as a simple internal linked list system to hold lists of timers, event handlers etc. it got renamed when ewd (ewl's data struct lib) was moerged into ecore as ecore_data. thus ecore_data now provided an EXTERNAL api for ecore_list and the existing code was just renamed to ecore_oldlist. we made it list2 to save typing. it's simply that the way the list mechanisms worked was DIFFERENT historically. evas has its own list system as it needs a LOT of lists and actually needs 2 KINDS of lists (generic pointign to item lisst (evas_list which is made public for general usefulness as its used internally anywway) AND evas_object_list (internal only - requires object include list header struct at the start of its struct - ie inheritance) which saves allocs and list searches for removes if you already have the object u want, and also assumes the object will lexist in 1 list only (if it is references in other lists evas_list is the way to go). but as i said - these exist because evas doesnt rely on ecore and needs its own lists (and actually is historically older than ecore). since evas and ecore share no common dependency there is no good place tyo put a shared list mechanism - also each is quite engrained in its own and changing it is a lot of work. as nathan said - it's very historical in nature and ecore_list2 and evas_list and evas_object_list are very similar in that they are simple double-linked lsist with minimal accounting. (btw nathan - ecore_list2 does keep a pointer to the last member :) so its overhead per object that uses it is 3 pointers). ecore_list2 is very much identical to evas_object_list - designed for tracking objects in 1 list only with DIRECT access to the list node they are stored in from the object itself without a list search needed at all (ie O(1) remove, O (1) append, O(1), prepend). they are very efficient at what they were intended for and quite minimal, considering (saves an alloc per list node (no allocs in addition to the object), also O(1) on the most common operations etc.) > I've said it before, and I'll say it again. Evas and Ecore really > need to take some lessons from libast on how to provide multiple > implementations of a common data structure type with a single > interface and easy switching between selected implementation in each > case. Or at least on how to name a list implementation so it hints at > the underlying mechanism. :P > > Michael > > -- > Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> > n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) > --- > "Here, let me get my thumb off her breast so you can fully appreciate > her." -- Beth O'Hara > > > --- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > ___ > 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lis
Re: [E-devel] Strange warnings & compiling errors
On Sat, 31 Dec 2005 23:55:07 +0100 (CET) Vincent Torri <[EMAIL PROTECTED]> babbled: > > > On Sat, 31 Dec 2005, Ibukun Olumuyiwa wrote: > > > Mike Frysinger wrote: > > > On Saturday 31 December 2005 10:08, Nathan A. Smith wrote: > > > > > >>ecore_value.c:31: warning: redeclaration of 'ecore_prime_table' with > > >>different visibility (old visibility preserved) > > >>Ecore_Data.h:41: warning: previous declaration of 'ecore_prime_table' > > >>was here > > > > > > > > > what version of gcc are you using ? what distro ? > > > > > > > > >>/usr/bin/ld: .libs/ecore.o: relocation R_X86_64_PC32 against > > >>`setlocale@@GLIBC_2.2.5' can not be used when making a shared object; > > >>recompile with -fPIC > > >>/usr/bin/ld: final link failed: Bad value > > > > > > > > > looks like your toolchain is broken > > > > Not quite. Started seeing those warnings galore here too after Raster's > > symbol visibility commits. Obviously GCC 4.0 doesn't like them. > > remove the pragma and add -fvisibility=hidden during compilation > (otherwise, EAPI is useless) the pargma turns it on without CFLAGS - the CFLAGS actually don't work - i tried (the -fvisibility=hidden). they dont hide symbols at all after a strip. the pragma does. the problem, is that the pragma was turning on symbol hiding BEFORE a locale.h header inlined code and thus broke things. i fixed it now. (this didnt happen on my system - so it seems different glibc's do things differently in this regard or different locale setups) > Vincent > > > --- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > ___ > 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 cvs - e_utils - build error
On Thu, 29 Dec 2005 09:00:55 +0200 Chady Kassouf <[EMAIL PROTECTED]> babbled: > Oops.. > > I dunno why I was using evas_object_free, and now with symbol hiding it's > breaking. definitely should not have been using evas_object_free(). it's an internal call only and never was in Evas.h's exported api calls. :) > Attached is the patch for the powers that be to apply it. > > > On 12/29/05, Laurence Vanek <[EMAIL PROTECTED]> wrote: > > > > not sure if e_utils is even needed for anything anymore but if so got > > this error after attempt to build from latest cvs update: > > > > = > > . > > . > > . > > main.o(.text+0xac9): In function `main': > > /root/e17/apps/e_utils/src/bin/ethemes/main.c:339: undefined ref > > erence to `evas_object_free' > > main.o(.text+0xad5):/root/e17/apps/e_utils/src/bin/ethemes/main. > > c:340: undefined reference to `evas_object_free' > > main.o(.text+0xae1):/root/e17/apps/e_utils/src/bin/ethemes/main. > > c:341: undefined reference to `evas_object_free' > > main.o(.text+0xaed):/root/e17/apps/e_utils/src/bin/ethemes/main. > > c:342: undefined reference to `evas_object_free' > > main.o(.text+0xaf9):/root/e17/apps/e_utils/src/bin/ethemes/main. > > c:343: undefined reference to `evas_object_free' > > main.o(.text+0xb05):/root/e17/apps/e_utils/src/bin/ethemes/main. > > c:344: more undefined references to `evas_object_free' follow > > collect2: ld returned 1 exit status > > make[4]: *** [ethemes] Error 1 > > make[4]: Leaving directory `/root/e17/apps/e_utils/src/bin/ethem > > es' > > make[3]: *** [all-recursive] Error 1 > > make[3]: Leaving directory `/root/e17/apps/e_utils/src/bin' > > make[2]: *** [all-recursive] Error 1 > > make[2]: Leaving directory `/root/e17/apps/e_utils/src' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/root/e17/apps/e_utils' > > make: *** [all] Error 2 > > > > > > > > > > --- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > > files > > for problems? Stop! Download the new AJAX search engine that makes > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > -- > Chady 'Leviathan' Kassouf > http://chady.net/ > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Strange warnings & compiling errors
On Sat, 31 Dec 2005 08:08:10 -0700 "Nathan A. Smith" <[EMAIL PROTECTED]> babbled: > Hi guys, > > I have recently noticed I am getting a lot of strange (to me) compiling > errors and warnings. I was hoping I could get one of you smart people > to point me in the right direction to fix them. > > the warnings (I started getting them when compiling evas -- and > everthing that followed) > > an example follows: > > ecore_value.c:31: warning: redeclaration of 'ecore_prime_table' with > different visibility (old visibility preserved) > Ecore_Data.h:41: warning: previous declaration of 'ecore_prime_table' > was here > > > These warnings would be repeated for different lines more than a hundred > times -- no kidding. these warnings are warnigns and not errors as such - we need to fix all the api instances properly as this actually has been brokewn in efl for a loong time and i recently made it work and found the issues. they are just warnings - but below is a bi-productr of your system headers inlining functions in the header and the headers being included afetr the pragma has enabled symbol hiding for gcc (whcih si a good thing - i decided to make this actually work after recently seeing some code in cvs using INTERNAL library function call symbols (evas_object_free to be exact) and decided it would be good to actually do what was intended with the EAPI define - that is to mark only functions that are in the API for external access and make only those visible to stop "back door access". i didn't see this bug as my system here doesnt have its system headers inline the code > which finally lead to this error: > > /usr/bin/ld: .libs/ecore.o: relocation R_X86_64_PC32 against > `setlocale@@GLIBC_2.2.5' can not be used when making a shared object; > recompile with -fPIC > /usr/bin/ld: final link failed: Bad value > > > Any help would be greatly appreciated. > > Nasa > > > > --- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > ___ > 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: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Re: [e-users] e16.8 pre1
On Mon, 26 Dec 2005 00:27:39 -0500 Michael Jennings <[EMAIL PROTECTED]> babbled: > On Sunday, 25 December 2005, at 21:02:05 (+0100), > Michel Briand wrote: > > > - it's evident but it's better said than not : This Program Is > > Designed With Users In Mind, it's not your little toy, even if > > Raster as it's creator, you and all contributors own the > > intellectual property, Open Sourcing it makes the software the > > property of Users ;). > > Bullshit. Don't think for a second that someone being nice enough to > make their work available to you under an open source license gives > you some kind of entitlement. It's a gift. You get it as is. If you (even though mej and i disagree often...) i'll have tyo agree with mej here 100%. the software is produced and ythen given away - with source, free, out fo the goodness of hearts of developers. *IF* users begin to thgink they are ENTITLED to support, help, ownership of the software and ENTITLED to determine how it is developed - they might soon find their developrs have vanished and started makign real money off their work by writing it for windows or macos - where people.. *GASP* PAY for software and software developers can *GASP* ... make a living from it. so remember. developers donate 100's or even 1000's of hours of their own personal time to work on the software then GIVE IT AWAY for FREE.one day there will come a crunch if enough users push develoeprs - they will close their work up and make you pay for it. i have many times considered it and been tempted - but i haven't and i think it'd be wrong to do that. but as mej said - you should be RELLY happy that every developer, contributor, patch sender, tester, doc writer, etc. etc. etc. all donate their time selflessly. > want something changed, you do it yourself, or you ask nicely and > realize that you may be refused. But it is in no way your property. > > > That's what I mean when I said "many Open Source projects are > > suffering"... That's the Great Concept, IMHO, of Richard > > Stallman. You give the software and no one can say "I own it". The > > main focus becomes : how to do things that benefits to the users. yeah. GREAT ideaq. u spend 1000's of hours workign on it and get nothing in return. GREAAAT idea. REAAALY smart!. dude. in the real world timeis money. time can be billed to customers - thats actually many years salary worth of billable time being given away for free. time is only worth nothing for those with unlimited time. those with jobs and skills find their time worth something. RMS's focs was on giving the CUSTOMER of the software the freedom to inspect, modify then re-distribute their changes, so they are not stuck with unusable machines or programs as they have no source and no ability to keep using it. > Richard Stallman is a nutcase, and we couldn't possibly care less what > his opinion is on software ownership. We don't use the GPL in case > you hadn't noticed. You own your changes and contributions to the > software, and NOTHING MORE. If you haven't helped out, you own jack > shit. > > > - software releases should be made clear and as much as possible, > > straightforward for users to download, build and install. But not > > the least: to migrate without burden. This means, I think, a smart > > way to migrate from e16.7 to e16.8+ config files... > > If you were paying for this software, I'd agree with you. But you're > not. So take what you can get or help out. Either way, the opinion > of someone who does not contribute is worth about as much as the paper > it's written on. And since we don't use paper around here, that > leaves you in quite a pickle. > > > - configuration management should identify that there is a change in > > config file syntax and/or structure. I.e. CVS should help us to > > signal these changes and package management systems should map > > this. I can greatly help you and all the Ecommunity. I've strong > > experience in SCM at work. Mainly in "industry class" managed > > projects... > > Great. So contribute something. Put your money where your mouth is. > So far all we've heard is a lot of talk. > > Oh, and for the record, all these changes WERE developed, signaled, > and coordinated in CVS. I guess you weren't paying attention. > > > Yes, we agree that E is a critical application, that's a way for us > > to better distinguish it from non-critical application. For example > > applications that don't creates user annoyance when they don't work > > or applications that can easyly be updated without notice to user. > > If E is a critical application for you, it's your responsibility to > keep up with changes. If you're not prepared to get help during an or if its so critical - DONT keep up. use what you have - keep using it, NEVER upgrade. then changes will NOT happen - guarantee :) "if it ain't broke - don't fix it". if thats your situation - then stick to it! :) > upgrade, you have two choices: Keep up, or Don't upgra
Re: [E-devel] Modules
On Tue, 20 Dec 2005 21:44:50 -0600 "Hawkwind " <[EMAIL PROTECTED]> babbled: > I've noticed in the recent days after an update that *Modules* is nolonger an > option in the menu. I do realise that it is now part of theConfiguration > Panel which is nice. However, it was so much easier tobe able to left click, > go to modules and find your module and dowhatever you wanted. I have spoken > to several other users and theyall tend to agree. I'm not asking that it be > removed from the ConfigPanel, and put back as was, but why not have it in > both places ? Alot of us would prefer to have it as a menu option as well as > in theConfig Panel. Is there any chance of this option being put back > intoplace, as it was very user friendly and saved a few seconds of timeand > was just easier to use IMO. --With kind regards, ok. it seems there is demand. i was hoping just to remvoe maintenance hassle for this menu since it is ALSO under the configuration panel dialog now. that means we need to fix up the whole conifg callbacks for modules and make this an option to turn on. frankly the main menu needs some level of configrability anyway. i'll put it back in now by default and just fix up the config callbacks to not pop up a menu for config. :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Unified thumbnails (background)
On Wed, 21 Dec 2005 09:21:42 -0600 Nathan Ingersoll <[EMAIL PROTECTED]> babbled: > On 12/20/05, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > > > > > > just one thing - with efm it shouldnt be forking 1 process per image all > > at > > once. it will only be keeping 1 forked child at a time - running along > > generating for images without thumbs if they need one. the parent just > > gets the > > child exit event then forks off another. so it's 1 fork per image - and > > only > > per image that needs a thumb ANd only once per generation. i think you can > > safely asume even on the worst of posi systems 1 fork is nothing compared > > to > > the workload of loading, scaling then writing an image file :) > > Ahh, I should have read the code more closely. I saw the fork() at the top > of the _e_thumb_generate and assumed the worst. Thanks for clarifying that. yeah. that;d just be silly to fork of possibly 100's of children for a directory full of unthumbnailed images :) > anyway. i personalyl still favor the fork model as it requires nop pthreads, > > likely is no overhead compared to threads, has no concurrency and cache > > issues, > > aned is simple. > > > Agreed. excellent :) > what it does ned is an ability to tune how many forked image > > generators to allow at a time (efm allows only 1 so dual cpu systems will > > be > > happy, more cpus wont benefit - ok maybe 3 as x is probably involved, and > > you > > might say 4 if you let the kernel run IO cpu instructions on a 4th cpu). > > I think single CPU systems could even benefit from spawning a few worker > processes. Each process will reach a state where it's waiting on a read from > the image file, so two or three thumbnailing processes could potentially > interleave their resource usage pretty well. One sitting in a blocking read > while the other is processing image data. sure - to an extent it will. though the by far biggest gain will be in "smart thumbnailing" ala epeg - ie for common image formats make special fast paths. frankly jpeg is the biggest offenderthere with digital photos pushing 8 megapisels ande above even now, and even your average camera doing 4-6 megapixels. i think we can improve on epeg, by adding exif thumbnail handling (if a thumbnail is already inlineed in the jpeg as extended exif info and use that if its apropriate). anyway - i digress. :) > anyway > > - you DO have a very valid point for when 2 apps start thumbnailign the > > same > > dir. we should definitely put in a locking mechanism for that so wither > > they > > share the workload, or the first guy in gets "lock ownership" and drives > > the > > thumbnailing until he's done and the other process sits and waits (maybe > > polling the lock file if we sue that mechanism - the owenr coudl update > > the > > timespamp on the lockfile whenever it generates something. or the lock > > file > > could contain info as so the queue of ungenerated images to go... or maybe > > the > > simplest case all processes not owning the thumbnailing for that dir hold > > off > > until the owner releases (hopefulyl not too long from now) and then do a > > full > > update). > > > I'm actually pretty surprised the fd.o spec didn't address locking at all, > at least not that I saw the last time I read it. indeed - i should read it again. it's been a few years since i last read it, but i think they kind of thought the chance of concurrency low and thus simply a performance issue in the end, and well - certain other desktop environments pushing such things havent been renowned for their focus on efficiency in the past :) > anyway - i do agree that there is need to unify. i do also think there are 2 > > levels here. 1. just generate thumbs and let calling process know (either > > via a > > blocking api or a fork/event), 2. be able to ask for the thumb path for > > any > > given file path, and 3. load thumb into a canvas object (another level > > entirely). i do think you want to support blocking and sync - both. really > > async can just be a wrapper on top of the blocking api. > > I think 1 and 2 are what I'm most concerned with atm. Following the > fd.ospec (to a point, since its lack of jpeg support is just dumb) 3 > is not a > large issue since its just loading a png or jpeg. i forgot: thumbnail pruning. ie go through thumbnail cache/stash and find thumbnails that don't apply to any existing file :) need that., > imho it could do with: > > > > 1. add a file path to the thumb gen queue > > 2. delete a file path from the queue > > 3. begin queue processing > > 4. pause/unpause queue processing > > 5. end queue processing > > 6. ask for thumb path from file path > > 7. brute-force blocking-api generate thumb > > 8. get "new thumb available" events > > 9. set paralellism count (how many threads or forked children to allow at > > a > > time) > > > I think we're on the same page here as far as features. So here's the idea I > had in mind for implementation. First off,
Re: [E-devel] [PATCH] edje_cc C-preprocessor invocation
On Wed, 21 Dec 2005 10:01:41 -0600 Nathan Ingersoll <[EMAIL PROTECTED]>
babbled:
> I think you committed the earlier version of the patch that didn't work
> correctly. The later one had a redirected output that solved some issues on
> MacOS 10.3.
fixed... i'll commt as soon as i have net access :)
> On 12/20/05, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, 20 Dec 2005 02:13:14 -0800 Jon Merriman <[EMAIL PROTECTED]>
> > babbled:
> >
> > > Here's a patch that changes how edje_cc invokes the C pre-processor
> > > so that it does not break on systems with the BSD cpp wrapper in the
> > > default path. Before, cpp would return 1 and compile() would continue
> > > to process the empty temporary file.
> >
> > let's see if this breaks for anyone./ i've left the old code there for
> > easy
> > reverting.
> >
> > > Index: edje_cc_parse.c
> > > ===
> > > RCS file: /root/e17/libs/edje/src/bin/edje_cc_parse.c,v
> > > retrieving revision 1.1.1.1
> > > diff -r1.1.1.1 edje_cc_parse.c
> > > 656,666c656,671
> > > < snprintf(buf, sizeof(buf), "cat %s | cpp -I%s %s -E -o %s",
> > > < file_in, inc, def, tmpn);
> > > < ret = system(buf);
> > > < if (ret < 0)
> > > < {
> > > < snprintf(buf, sizeof(buf), "gcc -I%s %s -E -o %s %s",
> > > < inc, def, tmpn, file_in);
> > > < ret = system(buf);
> > > < }
> > > < if (ret >= 0) file_in = tmpn;
> > > < free(def);
> > > ---
> > > >
> > > > /*
> > > > * Run the input through the C pre-processor.
> > > > *
> > > > * On some BSD based systems (MacOS, OpenBSD), the default cpp
> > > > * in the path is a wrapper script that chokes on the -o option.
> > > > * If the preprocessor is invoked via gcc -E, it will treat
> > > > * file_in as a linker file. The safest route seems to be to
> > > > * run cpp with the output as the second non-option argument.
> > > > */
> > > > snprintf(buf, sizeof(buf), "cpp -I%s %s %s %s",
> > > > inc, def, file_in, tmpn);
> > > > ret = system(buf);
> > > > if (ret == EXIT_SUCCESS)
> > > > file_in = tmpn;
> > > > free(def);
> > > 667a673
> > > >
> > >
> > >
> > >
> > > ---
> > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> > files
> > > for problems? Stop! Download the new AJAX search engine that makes
> > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> > > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> > > ___
> > > 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: Splunk Inc. Do you grep through log
> > files
> > for problems? Stop! Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> > ___
> > 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: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Re: E CVS: apps/e raster
Welcome back raster. Hope you had a good holiday. On Fri, 06 Jan 2006 07:32:41 -0800 enlightenment-cvs@lists.sourceforge.net wrote: >+* BUG: IBAR follower speed and autoscroll speed are not > pixels / sec (they are > + recursive multiplication values). should invert gui valus and > display as a > + factor, not px/sec I kept telling him that over and over again. pgppi37d9uf5F.pgp Description: PGP signature
[E-devel] Re: E CVS: apps/e raster
enlightenment-cvs@lists.sourceforge.net wrote: Enlightenment CVS committal Author : raster Project : e17 Module : apps/e Dir : e17/apps/e Modified Files: BUGS TODO Log Message: fix several bugs (cursors for example)... found some more... :) +* BUG: fullscreen does not respect min/max window size It did respect min max size and aspect ratio, but mplayer got confused since it wanted the wm to (at least) produce a window with the same aspect ratio as the real screen. Sebastian --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] patch for the visibility feature
hey, it seems that there are some problems with the visibility feature and gcc 4.*. According to the documentation (http://gcc.gnu.org/wiki/Visibility) the pragma statement should not be used. And indeed, it seems that there are some problems with gcc 4.0.2 and that pragma. I propose that solution: * checking if gcc accept the vsibility feature in configure.in (i've written a small m4 macro for that. It add -fvisibility=hidden during compilation and it defines GCC_HASCLASSVISIBILITY) * modifying the definition of EAPI so that it uses GCC_HASCLASSVISIBILITY (if it's not already the case) * removing all the pragma statements. i've already made the changes for eet on my hard disk. Without the visibility feature, the size of the shared library is 37162 KB. With it, it's 36626. That is, it compiles fine and it works. is there any objections that I commit that for eet ? Vincent --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] allowing shade/resize to fullscreen windows
This is a patch that adds the option to allow these actions. It adds it
to the window manipulation config. Please review it before even
considering updating, since I'm not a C developer.
The option defaults to the current default. I also thougth of making the
window automatically unmaximize itself, but then noticed that that was
never the case with the more forgiving maximizing options.
--
Виктор Кожухаров /Viktor Kojouharov/ <[EMAIL PROTECTED]>
Index: src/bin/e_border.c
===
RCS file: /root/e17/apps/e/src/bin/e_border.c,v
retrieving revision 1.1.1.18
diff -u -r1.1.1.18 e_border.c
--- src/bin/e_border.c 29 Dec 2005 14:35:25 - 1.1.1.18
+++ src/bin/e_border.c 6 Jan 2006 11:25:19 -
@@ -695,7 +695,7 @@
E_OBJECT_TYPE_CHECK(bd, E_BORDER_TYPE);
if ((bd->shaded) || (bd->shading) || (bd->fullscreen) ||
- (bd->maximized == E_MAXIMIZE_FULLSCREEN))
+ ((bd->maximized == E_MAXIMIZE_FULLSCREEN) && (!e_config->allow_shading)))
return;
if (bd->new_client)
{
@@ -752,7 +752,7 @@
E_OBJECT_CHECK(bd);
E_OBJECT_TYPE_CHECK(bd, E_BORDER_TYPE);
- if ((bd->fullscreen) || (bd->maximized == E_MAXIMIZE_FULLSCREEN)) return;
+ if ((bd->fullscreen) || ((bd->maximized == E_MAXIMIZE_FULLSCREEN) && (!e_config->allow_shading))) return;
if (bd->new_client)
{
E_Border_Pending_Move_Resize *pnd;
@@ -1284,7 +1284,8 @@
E_OBJECT_CHECK(bd);
E_OBJECT_TYPE_CHECK(bd, E_BORDER_TYPE);
- if ((bd->fullscreen) || (bd->maximized) || (bd->shading)) return;
+ if ((bd->fullscreen) || ((bd->maximized) && (!e_config->allow_shading))
+ || (bd->shading)) return;
if ((bd->client.border.name) &&
(!strcmp("borderless", bd->client.border.name))) return;
if (!bd->shaded)
@@ -1371,7 +1372,8 @@
E_OBJECT_CHECK(bd);
E_OBJECT_TYPE_CHECK(bd, E_BORDER_TYPE);
- if ((bd->fullscreen) || (bd->maximized) || (bd->shading)) return;
+ if ((bd->fullscreen) || ((bd->maximized) && (!e_config->allow_shading))
+ || (bd->shading)) return;
if (bd->shaded)
{
// printf("UNSHADE!\n");
@@ -3753,8 +3755,10 @@
bd = e_border_find_by_client_window(e->win);
if (!bd) return 1;
- if ((bd->shaded) || (bd->shading) || (bd->maximized == E_MAXIMIZE_FULLSCREEN) ||
- (bd->fullscreen) || (bd->moving) || (bd->resize_mode != RESIZE_NONE))
+ if ((bd->shaded) || (bd->shading)
+ || ((bd->maximized == E_MAXIMIZE_FULLSCREEN) && (!e_config->allow_shading))
+ || (bd->fullscreen) || (bd->moving)
+ || (bd->resize_mode != RESIZE_NONE))
return 1;
if ((e->button >= 1) && (e->button <= 3))
@@ -6250,8 +6254,9 @@
if (!bd->lock_user_stacking)
e_border_raise(bd);
- if ((bd->shaded) || (bd->shading) || (bd->maximized == E_MAXIMIZE_FULLSCREEN) ||
- (bd->fullscreen) || (bd->lock_user_size))
+ if ((bd->shaded) || (bd->shading) ||
+ ((bd->maximized == E_MAXIMIZE_FULLSCREEN) && (!e_config->allow_shading))
+ || (bd->fullscreen) || (bd->lock_user_size))
return 0;
if ((bd->client.icccm.base_w >= 0) &&
@@ -6351,7 +6356,8 @@
{
if (!bd->lock_user_stacking)
e_border_raise(bd);
- if ((bd->maximized == E_MAXIMIZE_FULLSCREEN) || (bd->fullscreen) || (bd->lock_user_location))
+ if ((bd->maximized == E_MAXIMIZE_FULLSCREEN)
+ || (bd->fullscreen) || (bd->lock_user_location))
return 0;
if (grabbed)
Index: src/bin/e_config.c
===
RCS file: /root/e17/apps/e/src/bin/e_config.c,v
retrieving revision 1.1.1.14
diff -u -r1.1.1.14 e_config.c
--- src/bin/e_config.c 27 Dec 2005 17:35:57 - 1.1.1.14
+++ src/bin/e_config.c 6 Jan 2006 11:25:19 -
@@ -332,6 +332,7 @@
E_CONFIG_VAL(D, T, winlist_pos_max_w, INT); /**/
E_CONFIG_VAL(D, T, winlist_pos_max_h, INT); /**/
E_CONFIG_VAL(D, T, maximize_policy, INT); /**/
+ E_CONFIG_VAL(D, T, allow_shading, INT); /**/
E_CONFIG_VAL(D, T, kill_if_close_not_possible, INT); /**/
E_CONFIG_VAL(D, T, kill_process, INT); /**/
E_CONFIG_VAL(D, T, kill_timer_wait, DOUBLE); /**/
@@ -479,6 +480,7 @@
e_config->winlist_pos_max_w = 320;
e_config->winlist_pos_max_h = 320;
e_config->maximize_policy = E_MAXIMIZE_FULLSCREEN;
+ e_config->allow_shading = 0;
e_config->kill_if_close_not_possible = 1;
e_config->kill_process = 1;
e_config->kill_timer_wait = 10.0;
@@ -1494,6 +1496,7 @@
E_CONFIG_LIMIT(e_config->winlist_pos_max_w, 8, 4000);
E_CONFIG_LIMIT(e_config->winlist_pos_max_h, 8, 4000);
E_CONFIG_LIMIT(e_config->maximize_policy, E_MAXIMIZE_FULLSCREEN, E_MAXIMIZE_FILL);
+ E_CONFIG_LIMIT(e_config->allow_shading, 0, 1);
E_CONFIG_LIMIT(e_config->kill_if_close_not_possible, 0, 1);
E_CONFIG_LIMIT(e_config->kill_process, 0, 1);
E_CONFIG_LIMIT(e_config->kill_timer_wait, 0.0, 120.0);
Index: src/bin/e_config.h
===
RCS file: /root/e17/apps/e/src/bin/e_config.h,v
retrievin
