Re: [E-devel] bug in evas
Brian wrote: > > > > //long, dazed and confused rambling by me (jose). > > > All of this is exactly what I had in mind, with an additional > call that took points in absolute canvas coords and then converted > them to object coords (at the current location/rotation/scaling). > The use case I had in mind for such a function would be to add > points based on mouse input. It would basically just do > > px,py = canvas_coords_to_polygon_coords(cx, cy) > polygon_point_add(px,py) > > So, maybe we would just need the functions that map between the two > coordinate spaces :) > Yes, either absolute rel to canvas coords or absolute rel to an (untransformed) obj coord system would be fine, and one could convert between the two.. you could also have api funcs for both. Note though that "rel to the obj's coord system" won't always be the same as "rel to the obj's current canvas position" if one allows for the points to determine the object's pos (as they get added), unless the min of the vertex coords are exactly (0,0). I don't think "rel to the obj's current canvas pos" is good though.. filled with confusion if we're letting the vertex posns determine the obj's as they get added. From prior snafus, I still think it would be a *really* good idea to try adding this (and/or lines) to edje, just as far as the edc description, and see what problems might seem to arise. jose. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] bug in evas
On Thu, Apr 05, 2007 at 04:09:59AM +, [EMAIL PROTECTED] wrote: > > > > all in all this isnt a simple solution. the only way i see to > > > handle both methods is to have 2 calls. 1 to add a point relative > > > to origin and one to specify it absolutely. > > > > Two calls makes sense, but I think internally the point list > > should be relative to the object origin, and then convert to > > absolute coords at render time. This would allow us to do some > > sore of scaling based on object size (although some error would > > be introduced if the points were specified in abs coords). > > In order to eliminate cummulative errors, the vertex coords > must be stored as input (possibly modulo integer translations). > In order to minimize confusion from multiple coord systems > (and every time you have any kind of transformation, you basically > create a new coord system), or things like eg. mixing calls to add > points with calls to move/resize/rotate the obj (something which > I think ought to be avoided in usage), the inputs must have an > 'absolute' interpretation - either absolute rel to the canvas, > or absolute rel to an (untransformed) 'obj coord system'. > > I'd have to say that I think it would be best if the inputs > were taken rel to the (untransformed) obj, and nothing else. The > object size would grow with points added, or with resizing (scaling > the poly), and the bounding rect would change with rotations, etc.. > But the input vertex coords would have an absolute interpretation > as being rel to the (untransformed) obj. All of this is exactly what I had in mind, with an additional call that took points in absolute canvas coords and then converted them to object coords (at the current location/rotation/scaling). The use case I had in mind for such a function would be to add points based on mouse input. It would basically just do px,py = canvas_coords_to_polygon_coords(cx, cy) polygon_point_add(px,py) So, maybe we would just need the functions that map between the two coordinate spaces :) Brian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Theme for new forums
Surprise surprise I actually did something I said I was going to do. I have created a theme for the forums on the new enlightenment.org. I haven't seen raster or Dan in a couple of days so I figured I'd just send it here if one of you or someone else wants to apply it. To apply just untar the archive to the themes directory of the forum and then in the theme settings for the forum, make it the default theme. Hope you like it. If there is anything you'd like modified, let me know. You can see a screenshot at http://www.satus.net/files/misc/eforum_theme.png if you'd like to preview it. Enjoy.- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] bug in evas
> > all in all this isnt a simple solution. the only way i see to > > handle both methods is to have 2 calls. 1 to add a point relative > > to origin and one to specify it absolutely. > > Two calls makes sense, but I think internally the point list > should be relative to the object origin, and then convert to > absolute coords at render time. This would allow us to do some > sore of scaling based on object size (although some error would > be introduced if the points were specified in abs coords). In order to eliminate cummulative errors, the vertex coords must be stored as input (possibly modulo integer translations). In order to minimize confusion from multiple coord systems (and every time you have any kind of transformation, you basically create a new coord system), or things like eg. mixing calls to add points with calls to move/resize/rotate the obj (something which I think ought to be avoided in usage), the inputs must have an 'absolute' interpretation - either absolute rel to the canvas, or absolute rel to an (untransformed) 'obj coord system'. I'd have to say that I think it would be best if the inputs were taken rel to the (untransformed) obj, and nothing else. The object size would grow with points added, or with resizing (scaling the poly), and the bounding rect would change with rotations, etc.. But the input vertex coords would have an absolute interpretation as being rel to the (untransformed) obj. The obj's coord system would always be at (0,0), regardless of the obj's canvas position, whereas the latter can change not only from moving, but also from adding vertices (whose coords are then always rel to (0,0)), since one wants the obj's cur pos to be a function of the min coords of the vertices. This may seem a bit complex if you think about it, but it would actually be fairly straightforward to use in pratice -- *IF* one avoids adding points after a move/resize/rotate, whenever points had already been added before. BTW: I should add that the same should be done with line objs. Using coords rel to an obj's (untransformed) position is not without precedent in evas - image and gradient objects have a fill position which is interpreted exactly this way. Note that we'll need to add internal 'obj funcs' that deal with move/resize/rotate/... which the generic canvas versions would call before actually resetting the state - just as we have now for smart objs. There's really no way around that. Also, let the engines do any transformation of inputs.. not the canvas. The poly would be passed as is, along with the scaling/rotation data and the obj's cur pos to render at. Lastly, note that edje (bleeding or not), has a general means for specifying an object's pos/size which should probably be used for these vector-based objs. But to avoid any possible 'issues' with things, I'd say that any semantic decision should be heavily influenced by an attempt to actully try adding these to edje - if only as a first try. It's thru edje/edc or similar such (eg. Freevo's kaa.evas xml description, or tilman's "redact") that most interfacing with evas is done, and while I don't think evas should be bound to such, it should make it feasible to use from such (pseudo-) scalable descriptive formats. jose. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e_int_config_mouse.c cleanup....
Ravenlock wrote: > Hello, > > Attached is a small patch which cleans up some dead code in the mouse > config panel. > Committed :) dh - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e raster
On Wed, 04 Apr 2007 13:30:55 -0500 Ravenlock <[EMAIL PROTECTED]> babbled:
bumped :)
> On 04/04/2007 10:56, Carsten Haitzler (The Rasterman) wrote:
> > On Wed, 04 Apr 2007 10:27:33 -0500 Ravenlock <[EMAIL PROTECTED]>
> > babbled:
> >
> > good point - it may have been in another commit. i just did a string of
> > them.
>
> Did you happen to notice the patch attached to this thread that changes
> E_CONFIG_FILE_GENERATION? I think it needs to be bumped. :)
>
> >
> >> On 04/04/2007 08:26, Enlightenment CVS wrote:
> >>> Enlightenment CVS committal
> >>>
> >>> Author : raster
> >>> Project : e17
> >>> Module : apps/e
> >>>
> >>> Dir : e17/apps/e/src/bin
> >>>
> >>>
> >>> Modified Files:
> >>> e_config.c e_config.h e_int_config_clientlist.c
> >>> e_int_config_clientlist.h e_int_menus.c
> >>>
> >>>
> >>> Log Message:
> >>>
> >>>
> >>> cedric's patches.
> >> I don't know if this is important or not, but
> >>
> >> The patch below was something I sent in. However when it was committed
> >> it was noted as Cedric's. Worst case, if something goes wrong poeple
> >> may complain to the wrong person. So... dunno if anything needs to be
> >> done here. But I'd hate for Cedric to loose a cookie on my behalf. :P
> >>
> >> Also, fwiw...
> >> Attached is a patch for the patch. :P
> >> The E_CONFIG_FILE_GENERATION needs to be bumped as the original patch
> >> was against current cvs a month ago.
> >>
> >>> ===
> >>> RCS file: /cvs/e/e17/apps/e/src/bin/e_config.c,v
> >>> retrieving revision 1.233
> >>> retrieving revision 1.234
> >>> diff -u -3 -r1.233 -r1.234
> >>> --- e_config.c25 Mar 2007 22:44:59 - 1.233
> >>> +++ e_config.c4 Apr 2007 13:25:54 - 1.234
> >>> @@ -511,6 +511,7 @@
> >>> E_CONFIG_VAL(D, T, clientlist_sort_by, INT);
> >>> E_CONFIG_VAL(D, T, clientlist_separate_iconified_apps, INT);
> >>> E_CONFIG_VAL(D, T, clientlist_warp_to_iconified_desktop, INT);
> >>> + E_CONFIG_VAL(D, T, clientlist_max_caption_len, INT);
> >>>
> >>> E_CONFIG_VAL(D, T, mouse_accel_numerator, INT);
> >>> E_CONFIG_VAL(D, T, mouse_accel_denominator, INT);
> >>> @@ -1357,6 +1358,10 @@
> >>>
> >>> if (!e_config->icon_theme) e_config->icon_theme = evas_stringshare_add
> >>> ("hicolor");
> >>> + IFCFG(0x111)
> >>> + e_config->clientlist_max_caption_len = 0;
> >>> + IFCFGEND;
> >>> +
> >>> e_config->config_version = E_CONFIG_FILE_VERSION;
> >>>
> >>> #if 0 /* example of new config */
> >>> @@ -1475,6 +1480,7 @@
> >>> E_CONFIG_LIMIT(e_config->clientlist_sort_by, 0, 3);
> >>> E_CONFIG_LIMIT(e_config->clientlist_separate_iconified_apps, 0, 2);
> >>> E_CONFIG_LIMIT(e_config->clientlist_warp_to_iconified_desktop, 0, 1);
> >>> + E_CONFIG_LIMIT(e_config->clientlist_max_caption_len, 0,
> >>> E_CLIENTLIST_MAX_CAPTION_LEN);
> >>> E_CONFIG_LIMIT(e_config->mouse_accel_numerator, 1, 10);
> >>> E_CONFIG_LIMIT(e_config->mouse_accel_denominator, 1, 10);
> >>> ===
> >>> RCS file: /cvs/e/e17/apps/e/src/bin/e_config.h,v
> >>> retrieving revision 1.147
> >>> retrieving revision 1.148
> >>> diff -u -3 -r1.147 -r1.148
> >>> --- e_config.h25 Mar 2007 22:44:59 - 1.147
> >>> +++ e_config.h4 Apr 2007 13:25:54 - 1.148
> >>> @@ -253,6 +253,7 @@
> >>> int clientlist_sort_by; // GUI
> >>> int clientlist_separate_iconified_apps; // GUI
> >>> int clientlist_warp_to_iconified_desktop; // GUI
> >>> + int clientlist_max_caption_len;
> >>>
> >>> int mouse_accel_numerator; // GUI
> >>> int mouse_accel_denominator; // GUI
> >>> ===
> >>> RCS file: /cvs/e/e17/apps/e/src/bin/e_int_config_clientlist.c,v
> >>> retrieving revision 1.5
> >>> retrieving revision 1.6
> >>> diff -u -3 -r1.5 -r1.6
> >>> --- e_int_config_clientlist.c 26 Mar 2007 17:13:57 - 1.5
> >>> +++ e_int_config_clientlist.c 4 Apr 2007 13:25:54 - 1.6
> >>> @@ -17,6 +17,7 @@
> >>> int sort_by;
> >>> int separate_iconified_apps;
> >>> int warp_to_iconified_desktop;
> >>> + int max_caption_len;
> >>> };
> >>>
> >>> EAPI E_Config_Dialog *
> >>> @@ -50,6 +51,7 @@
> >>> cfdata->sort_by = e_config->clientlist_sort_by;
> >>> cfdata->separate_iconified_apps =
> >>> e_config->clientlist_separate_iconified_apps;
> >>> cfdata->warp_to_iconified_desktop =
> >>> e_config->clientlist_warp_to_iconified_desktop;
> >>> + cfdata->max_caption_len = e_config->clientlist_max_caption_len;
> >>> }
> >>>
> >>> static void *
> >>> @@ -77,6 +79,7 @@
> >>> e_config->clientlist_sort_by = cfdata->sort_by;
> >>> e_config->clientlist_separate_iconified_apps =
> >>> cfdata->separate_iconified_apps;
> >>> e_config->clientlist_warp_to_iconified_desktop =
> >>> cfdata->warp_to
Re: [E-devel] Efreet Favorite Menu Editor
Of course :) Just waiting on the related efreet functions to be added :) dh Carsten Haitzler (The Rasterman) wrote: > On Wed, 04 Apr 2007 01:10:00 -0400 Christopher Michael <[EMAIL PROTECTED]> > babbled: > > you want to add del to it too? :) > >> Just something I whipped up, look it over, use it...dont... whichever >> >> Simple Favorites menu editor...only can add right now, missing efreet >> menu desktop del function...see code comments. >> >> Thoughts welcome... >> >> >> dh >> > > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] ecore tslib configure.in fix
On 4/4/07, Lars Munch <[EMAIL PROTECTED]> wrote: > Hi > > If I build ecore with fb engine enabled on a system with tslib installed > I get a linker error because it tries to link against "tslib" instead of > "ts". The attached patch fixes this. > > I thought about removing tslib from configure.in since it is currently > not used, but I have a feeling that support for tslib will appear > sometime in the near future. Indeed, i already have some code to push up on the server which also handles the issue you are saying. as im without a pc this days and can't test my code, i wont be able to commit anything, hope you dont mind to wait a little longer for the fb changes. :) > > Please apply. > > -- Lars Munch > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/efreet englebass
On Wed, Apr 04, 2007 at 01:54:14PM -0500, Ravenlock wrote: > > -ext = strrchr(name, '.'); > ^ > I'm wondering if you accidentally removed the line above?? Yeah, that looks like a mistake. Committed. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/efreet englebass
englebass,
On 04/04/2007 06:54, Enlightenment CVS wrote:
> Enlightenment CVS committal
>
> Author : englebass
> Project : e17
> Module : libs/efreet
>
> Dir : e17/libs/efreet/src/lib
>
>
> Modified Files:
> efreet_icon.c
>
>
> Log Message:
> Drop icons without extenstion
>
> ===
> RCS file: /cvs/e/e17/libs/efreet/src/lib/efreet_icon.c,v
> retrieving revision 1.11
> retrieving revision 1.12
> diff -u -3 -r1.11 -r1.12
> --- efreet_icon.c 4 Apr 2007 11:52:46 - 1.11
> +++ efreet_icon.c 4 Apr 2007 11:54:23 - 1.12
> @@ -671,8 +671,12 @@
> name_strs[0] = name;
>
> /* Drop the extension to cache icon name */
> -ext = strrchr(name, '.');
^
I'm wondering if you accidentally removed the line above??
> -if (ext)
> +if (!ext)
> +{
> +FREE(name);
> +continue;
> +}
> +else
> {
> /* we need to skip .icon files as their used for
> * informational purposes only */
>
>
>
> -
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ___
> enlightenment-cvs mailing list
> enlightenment-cvs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-cvs
>
>
--
Regards,
Ravenlock
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e raster
On 04/04/2007 10:56, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 04 Apr 2007 10:27:33 -0500 Ravenlock <[EMAIL PROTECTED]> babbled:
>
> good point - it may have been in another commit. i just did a string of them.
Did you happen to notice the patch attached to this thread that changes
E_CONFIG_FILE_GENERATION? I think it needs to be bumped. :)
>
>> On 04/04/2007 08:26, Enlightenment CVS wrote:
>>> Enlightenment CVS committal
>>>
>>> Author : raster
>>> Project : e17
>>> Module : apps/e
>>>
>>> Dir : e17/apps/e/src/bin
>>>
>>>
>>> Modified Files:
>>> e_config.c e_config.h e_int_config_clientlist.c
>>> e_int_config_clientlist.h e_int_menus.c
>>>
>>>
>>> Log Message:
>>>
>>>
>>> cedric's patches.
>> I don't know if this is important or not, but
>>
>> The patch below was something I sent in. However when it was committed
>> it was noted as Cedric's. Worst case, if something goes wrong poeple
>> may complain to the wrong person. So... dunno if anything needs to be
>> done here. But I'd hate for Cedric to loose a cookie on my behalf. :P
>>
>> Also, fwiw...
>> Attached is a patch for the patch. :P
>> The E_CONFIG_FILE_GENERATION needs to be bumped as the original patch
>> was against current cvs a month ago.
>>
>>> ===
>>> RCS file: /cvs/e/e17/apps/e/src/bin/e_config.c,v
>>> retrieving revision 1.233
>>> retrieving revision 1.234
>>> diff -u -3 -r1.233 -r1.234
>>> --- e_config.c 25 Mar 2007 22:44:59 - 1.233
>>> +++ e_config.c 4 Apr 2007 13:25:54 - 1.234
>>> @@ -511,6 +511,7 @@
>>> E_CONFIG_VAL(D, T, clientlist_sort_by, INT);
>>> E_CONFIG_VAL(D, T, clientlist_separate_iconified_apps, INT);
>>> E_CONFIG_VAL(D, T, clientlist_warp_to_iconified_desktop, INT);
>>> + E_CONFIG_VAL(D, T, clientlist_max_caption_len, INT);
>>>
>>> E_CONFIG_VAL(D, T, mouse_accel_numerator, INT);
>>> E_CONFIG_VAL(D, T, mouse_accel_denominator, INT);
>>> @@ -1357,6 +1358,10 @@
>>>
>>> if (!e_config->icon_theme) e_config->icon_theme = evas_stringshare_add
>>> ("hicolor");
>>> + IFCFG(0x111)
>>> + e_config->clientlist_max_caption_len = 0;
>>> + IFCFGEND;
>>> +
>>> e_config->config_version = E_CONFIG_FILE_VERSION;
>>>
>>> #if 0 /* example of new config */
>>> @@ -1475,6 +1480,7 @@
>>> E_CONFIG_LIMIT(e_config->clientlist_sort_by, 0, 3);
>>> E_CONFIG_LIMIT(e_config->clientlist_separate_iconified_apps, 0, 2);
>>> E_CONFIG_LIMIT(e_config->clientlist_warp_to_iconified_desktop, 0, 1);
>>> + E_CONFIG_LIMIT(e_config->clientlist_max_caption_len, 0,
>>> E_CLIENTLIST_MAX_CAPTION_LEN);
>>> E_CONFIG_LIMIT(e_config->mouse_accel_numerator, 1, 10);
>>> E_CONFIG_LIMIT(e_config->mouse_accel_denominator, 1, 10);
>>> ===
>>> RCS file: /cvs/e/e17/apps/e/src/bin/e_config.h,v
>>> retrieving revision 1.147
>>> retrieving revision 1.148
>>> diff -u -3 -r1.147 -r1.148
>>> --- e_config.h 25 Mar 2007 22:44:59 - 1.147
>>> +++ e_config.h 4 Apr 2007 13:25:54 - 1.148
>>> @@ -253,6 +253,7 @@
>>> int clientlist_sort_by; // GUI
>>> int clientlist_separate_iconified_apps; // GUI
>>> int clientlist_warp_to_iconified_desktop; // GUI
>>> + int clientlist_max_caption_len;
>>>
>>> int mouse_accel_numerator; // GUI
>>> int mouse_accel_denominator; // GUI
>>> ===
>>> RCS file: /cvs/e/e17/apps/e/src/bin/e_int_config_clientlist.c,v
>>> retrieving revision 1.5
>>> retrieving revision 1.6
>>> diff -u -3 -r1.5 -r1.6
>>> --- e_int_config_clientlist.c 26 Mar 2007 17:13:57 - 1.5
>>> +++ e_int_config_clientlist.c 4 Apr 2007 13:25:54 - 1.6
>>> @@ -17,6 +17,7 @@
>>> int sort_by;
>>> int separate_iconified_apps;
>>> int warp_to_iconified_desktop;
>>> + int max_caption_len;
>>> };
>>>
>>> EAPI E_Config_Dialog *
>>> @@ -50,6 +51,7 @@
>>> cfdata->sort_by = e_config->clientlist_sort_by;
>>> cfdata->separate_iconified_apps =
>>> e_config->clientlist_separate_iconified_apps;
>>> cfdata->warp_to_iconified_desktop =
>>> e_config->clientlist_warp_to_iconified_desktop;
>>> + cfdata->max_caption_len = e_config->clientlist_max_caption_len;
>>> }
>>>
>>> static void *
>>> @@ -77,6 +79,7 @@
>>> e_config->clientlist_sort_by = cfdata->sort_by;
>>> e_config->clientlist_separate_iconified_apps =
>>> cfdata->separate_iconified_apps;
>>> e_config->clientlist_warp_to_iconified_desktop =
>>> cfdata->warp_to_iconified_desktop;
>>> + e_config->clientlist_max_caption_len = cfdata->max_caption_len;
>>> e_config_save_queue();
>>> return 1;
>>> }
>>> @@ -136,6 +139,11 @@
>>> ob = e_widget_check_add(evas, _("Warp to owning desktop"), &
>>> (cfdata->warp_to_iconified_desktop)); e_widget_framelist_object_append(o
Re: [E-devel] [PATCH] edje_extern_object_*() sets swallow_params and trigger recalc
On Wed, 4 Apr 2007 10:48:53 -0500, Brian Mattern <[EMAIL PROTECTED]> wrote : > On Wed, Apr 04, 2007 at 06:36:41PM +0200, Simon TRENY wrote: > > Does this mean, we don't have to unswallow/reswallow a swallowed > > object anymore when we change its size with edje_extern_object_*() ? > > > Yes, that's the idea. Great :) > Just curious, if you knew about the issue, why did you work around it > instead of reporting it / fixing it? :) I didn't report it because it was raster who told me about this issue and how to work around it, so I knew it was an already known issue (or at least... I knew raster knew it :)) And I didn't fix it because at the time I had to use edje_extern_object_*(), I had no time to fix it. And then, I totally forgot about it. Simon > > Brian > > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your opinions on IT & business topics through brief surveys-and > earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ enlightenment-devel > mailing list enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Abstract sockets in ecore
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Mattern schreef:
> On Wed, Apr 04, 2007 at 02:39:12PM +0200, Massimiliano Calamelli wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On Wed, 04 Apr 2007 14:29:06 +0200
>> Sebastian Dransfeld <[EMAIL PROTECTED]> wrote:
>>
>>> It is possible to disable abstract sockets now. It is only used in
>>> ecore_dbus, and I think ecore_dbus will die soon.
>>>
>>> Sebastian
>> Already disabled with --disable-ecore-dbus, but configure check it
>> again.
>>
>
> I added the abstract socket code and the macro to check for it. I have
> no experience with cross-compiling, so didn't know that it would be an
> issue.
>
> Disabling ecore_dbus won't help because the feature is in ecore_con.
> Someone just needs to add a configure option to explicitly disable (thus
> avoiding the check) or determine another means of checking that also
> works when cross compiling.
Just put
ac_cv_have_abstract_sockets=${ac_cv_have_abstract_sockets=no}
in your autoconf cache files and it won't run the checks
regards,
Koen
PS: more stuff in
http://www.openembedded.org/repo/org.openembedded.dev/site/arm-linux
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFGE9p5MkyGM64RGpERAvgsAJ9aiq3w2sSdfYBycSfuqMjzCBDY7QCfZf7n
xA1BNriDjHxoSF9kk1x9GZc=
=26M/
-END PGP SIGNATURE-
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] ecore tslib configure.in fix
Hi If I build ecore with fb engine enabled on a system with tslib installed I get a linker error because it tries to link against "tslib" instead of "ts". The attached patch fixes this. I thought about removing tslib from configure.in since it is currently not used, but I have a feeling that support for tslib will appear sometime in the near future. Please apply. -- Lars Munch Index: ecore/configure.in === RCS file: /var/cvs/e/e17/libs/ecore/configure.in,v retrieving revision 1.191 diff -u -r1.191 configure.in --- ecore/configure.in 4 Apr 2007 12:28:16 - 1.191 +++ ecore/configure.in 4 Apr 2007 13:44:30 - @@ -238,7 +238,7 @@ if test "x$have_ecore_fb" = "xyes" ; then AC_CHECK_HEADER(tslib.h, [ - tslib_libs="-ltslib" + tslib_libs="-lts" AC_DEFINE(HAVE_TSLIB, 1, [Build Ecore_FB Touchscreen Code]) ] ) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Maximize Patch
Carsten Haitzler (The Rasterman) wrote: > On Fri, 16 Mar 2007 13:42:27 -0500 "Sthithaprajna Garapaty" > <[EMAIL PROTECTED]> babbled: > > >> Arr! E! looky like you needs a eye patch fer yer dreadful voyages. >> Here's a small one that'll make ya look real scary while yer >> swashbuckin! >> >> The maximize code needs fixing. Or there needs to be a new maximize mode. >> That maximizes without making my windows go under the shelf ever. >> But that's too much work. >> >> So here's a patch that'll let the user set the size and position the >> window should get to when maximizing. >> This can also be useful if the user has other apps that he'd rather >> not overlap while maximizing. >> (instant messangers and such) >> Bad news, the user has to figure out the dimensions themselves and >> input 'em into this. >> > > you know... you could have made this simpler. instead of entering the x,y w > and > h with sliders - just have a menu item "snapshot current geometry as maximized > size" or something - then store whatever the window is at. less gui to deal > with, easier for users. if you can change it to that - i'll accept :) > > Yup. If you saw my follow up to this, that's exactly what I said should be done. And, I can do it, but it maybe a month before I get to it. --Sthitha - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Pending patch
On Wednesday 04 April 2007 15:25:44 Carsten Haitzler wrote: > On Wed, 21 Mar 2007 17:22:17 +0100 Cedric BAIL <[EMAIL PROTECTED]> > babbled: > ok 2 patches in - edje font hash and tiler speedup - Great. > but the list sort in place is not - the reason i removed it last time is > that i found lists being sorted were losing items. i spotted this in e17's > efm code which did a lot of list and mini-list and partial list sorting > stuff (from memory). you might want to go over that code again. Hum, I didn't notice that, I will check. > as for sdl engine and rfc for events and other things - i will get to them. > this blast of mails from you is the last major lump i need to deal with on > the e-devel list :) Sorry for the spam :) Cedric - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Abstract sockets in ecore
On Wed, Apr 04, 2007 at 10:46:41AM -0500, Brian Mattern wrote: > On Wed, Apr 04, 2007 at 02:39:12PM +0200, Massimiliano Calamelli wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On Wed, 04 Apr 2007 14:29:06 +0200 > > Sebastian Dransfeld <[EMAIL PROTECTED]> wrote: > > > > > It is possible to disable abstract sockets now. It is only used in > > > ecore_dbus, and I think ecore_dbus will die soon. > > > > > > Sebastian > > > > Already disabled with --disable-ecore-dbus, but configure check it > > again. > > > > I added the abstract socket code and the macro to check for it. I have > no experience with cross-compiling, so didn't know that it would be an > issue. > > Disabling ecore_dbus won't help because the feature is in ecore_con. > Someone just needs to add a configure option to explicitly disable (thus > avoiding the check) or determine another means of checking that also > works when cross compiling. > > If no one else gets to it, I'll try to look in the next few days. Sebastian already added an --disable-abstract-sockets option that does the trick. Thanks Sebastian. -- Lars Munch - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e raster
On Wed, 04 Apr 2007 10:27:33 -0500 Ravenlock <[EMAIL PROTECTED]> babbled:
good point - it may have been in another commit. i just did a string of them.
> On 04/04/2007 08:26, Enlightenment CVS wrote:
> > Enlightenment CVS committal
> >
> > Author : raster
> > Project : e17
> > Module : apps/e
> >
> > Dir : e17/apps/e/src/bin
> >
> >
> > Modified Files:
> > e_config.c e_config.h e_int_config_clientlist.c
> > e_int_config_clientlist.h e_int_menus.c
> >
> >
> > Log Message:
> >
> >
> > cedric's patches.
>
> I don't know if this is important or not, but
>
> The patch below was something I sent in. However when it was committed
> it was noted as Cedric's. Worst case, if something goes wrong poeple
> may complain to the wrong person. So... dunno if anything needs to be
> done here. But I'd hate for Cedric to loose a cookie on my behalf. :P
>
> Also, fwiw...
> Attached is a patch for the patch. :P
> The E_CONFIG_FILE_GENERATION needs to be bumped as the original patch
> was against current cvs a month ago.
>
> >
> > ===
> > RCS file: /cvs/e/e17/apps/e/src/bin/e_config.c,v
> > retrieving revision 1.233
> > retrieving revision 1.234
> > diff -u -3 -r1.233 -r1.234
> > --- e_config.c 25 Mar 2007 22:44:59 - 1.233
> > +++ e_config.c 4 Apr 2007 13:25:54 - 1.234
> > @@ -511,6 +511,7 @@
> > E_CONFIG_VAL(D, T, clientlist_sort_by, INT);
> > E_CONFIG_VAL(D, T, clientlist_separate_iconified_apps, INT);
> > E_CONFIG_VAL(D, T, clientlist_warp_to_iconified_desktop, INT);
> > + E_CONFIG_VAL(D, T, clientlist_max_caption_len, INT);
> >
> > E_CONFIG_VAL(D, T, mouse_accel_numerator, INT);
> > E_CONFIG_VAL(D, T, mouse_accel_denominator, INT);
> > @@ -1357,6 +1358,10 @@
> >
> > if (!e_config->icon_theme) e_config->icon_theme = evas_stringshare_add
> > ("hicolor");
> > + IFCFG(0x111)
> > + e_config->clientlist_max_caption_len = 0;
> > + IFCFGEND;
> > +
> > e_config->config_version = E_CONFIG_FILE_VERSION;
> >
> > #if 0 /* example of new config */
> > @@ -1475,6 +1480,7 @@
> > E_CONFIG_LIMIT(e_config->clientlist_sort_by, 0, 3);
> > E_CONFIG_LIMIT(e_config->clientlist_separate_iconified_apps, 0, 2);
> > E_CONFIG_LIMIT(e_config->clientlist_warp_to_iconified_desktop, 0, 1);
> > + E_CONFIG_LIMIT(e_config->clientlist_max_caption_len, 0,
> > E_CLIENTLIST_MAX_CAPTION_LEN);
> > E_CONFIG_LIMIT(e_config->mouse_accel_numerator, 1, 10);
> > E_CONFIG_LIMIT(e_config->mouse_accel_denominator, 1, 10);
> > ===
> > RCS file: /cvs/e/e17/apps/e/src/bin/e_config.h,v
> > retrieving revision 1.147
> > retrieving revision 1.148
> > diff -u -3 -r1.147 -r1.148
> > --- e_config.h 25 Mar 2007 22:44:59 - 1.147
> > +++ e_config.h 4 Apr 2007 13:25:54 - 1.148
> > @@ -253,6 +253,7 @@
> > int clientlist_sort_by; // GUI
> > int clientlist_separate_iconified_apps; // GUI
> > int clientlist_warp_to_iconified_desktop; // GUI
> > + int clientlist_max_caption_len;
> >
> > int mouse_accel_numerator; // GUI
> > int mouse_accel_denominator; // GUI
> > ===
> > RCS file: /cvs/e/e17/apps/e/src/bin/e_int_config_clientlist.c,v
> > retrieving revision 1.5
> > retrieving revision 1.6
> > diff -u -3 -r1.5 -r1.6
> > --- e_int_config_clientlist.c 26 Mar 2007 17:13:57 - 1.5
> > +++ e_int_config_clientlist.c 4 Apr 2007 13:25:54 - 1.6
> > @@ -17,6 +17,7 @@
> > int sort_by;
> > int separate_iconified_apps;
> > int warp_to_iconified_desktop;
> > + int max_caption_len;
> > };
> >
> > EAPI E_Config_Dialog *
> > @@ -50,6 +51,7 @@
> > cfdata->sort_by = e_config->clientlist_sort_by;
> > cfdata->separate_iconified_apps =
> > e_config->clientlist_separate_iconified_apps;
> > cfdata->warp_to_iconified_desktop =
> > e_config->clientlist_warp_to_iconified_desktop;
> > + cfdata->max_caption_len = e_config->clientlist_max_caption_len;
> > }
> >
> > static void *
> > @@ -77,6 +79,7 @@
> > e_config->clientlist_sort_by = cfdata->sort_by;
> > e_config->clientlist_separate_iconified_apps =
> > cfdata->separate_iconified_apps;
> > e_config->clientlist_warp_to_iconified_desktop =
> > cfdata->warp_to_iconified_desktop;
> > + e_config->clientlist_max_caption_len = cfdata->max_caption_len;
> > e_config_save_queue();
> > return 1;
> > }
> > @@ -136,6 +139,11 @@
> > ob = e_widget_check_add(evas, _("Warp to owning desktop"), &
> > (cfdata->warp_to_iconified_desktop)); e_widget_framelist_object_append(of,
> > ob); e_widget_table_object_append(ot, of, 1, 1, 1, 1, 1, 1, 1, 1);
> > +
> > + of = e_widget_framelist_add(evas, _("Maximum Caption Length"), 0);
> > + ob = e_widget_slider_add(evas, 1, 0,
Re: [E-devel] [PATCH] edje_extern_object_*() sets swallow_params and trigger recalc
On Wed, Apr 04, 2007 at 06:36:41PM +0200, Simon TRENY wrote: > Does this mean, we don't have to unswallow/reswallow a swallowed object > anymore when we change its size with edje_extern_object_*() ? > Yes, that's the idea. Just curious, if you knew about the issue, why did you work around it instead of reporting it / fixing it? :) Brian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Abstract sockets in ecore
On Wed, Apr 04, 2007 at 02:39:12PM +0200, Massimiliano Calamelli wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Wed, 04 Apr 2007 14:29:06 +0200 > Sebastian Dransfeld <[EMAIL PROTECTED]> wrote: > > > It is possible to disable abstract sockets now. It is only used in > > ecore_dbus, and I think ecore_dbus will die soon. > > > > Sebastian > > Already disabled with --disable-ecore-dbus, but configure check it > again. > I added the abstract socket code and the macro to check for it. I have no experience with cross-compiling, so didn't know that it would be an issue. Disabling ecore_dbus won't help because the feature is in ecore_con. Someone just needs to add a configure option to explicitly disable (thus avoiding the check) or determine another means of checking that also works when cross compiling. If no one else gets to it, I'll try to look in the next few days. Brian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] bug in evas
On Wed, Apr 04, 2007 at 01:39:51PM +0900, Carsten Haitzler wrote: > all in all this isnt a simple solution. the only way i see to handle both > methods is to have 2 calls. 1 to add a point relative to origin and one to > specify it absolutely. Two calls makes sense, but I think internally the point list should be relative to the object origin, and then convert to absolute coords at render time. This would allow us to do some sore of scaling based on object size (although some error would be introduced if the points were specified in abs coords). Brian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] edje_extern_object_*() sets swallow_params and trigger recalc
Does this mean, we don't have to unswallow/reswallow a swallowed object anymore when we change its size with edje_extern_object_*() ? Simon On Wed, 4 Apr 2007 21:43:24 +0900, Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> wrote : > On Wed, 28 Mar 2007 19:01:17 -0300 "Gustavo Sverzut Barbieri" > <[EMAIL PROTECTED]> babbled: > > this seems fine looking at it - patch in cvs. :) > > > This patch marks swallowed objects and when edje_extern_object_*() > > functions are called on these objects, swallow_params are set and > > _edje_recalc() is called. > > > > This patch was originally written by rephorm, but had small bugs, > > which I've fixed. His original patch is > > http://rephorm.com/files/patches/edje_extern.diff > > > > edje_util.c | 47 +++ > > 1 file changed, 47 insertions(+) > > > > -- > > Gustavo Sverzut Barbieri > > -- > > Jabber: [EMAIL PROTECTED] > >MSN: [EMAIL PROTECTED] > > ICQ#: 17249123 > > Skype: gsbarbieri > > Mobile: +55 (81) 9927 0010 > > > > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] e_int_config_mouse.c cleanup....
Hello,
Attached is a small patch which cleans up some dead code in the mouse
config panel.
--
Regards,
Ravenlock
Index: e17/apps/e/src/bin/e_int_config_mouse.c
===
RCS file: /var/cvs/e/e17/apps/e/src/bin/e_int_config_mouse.c,v
retrieving revision 1.3
diff -u -r1.3 e_int_config_mouse.c
--- e17/apps/e/src/bin/e_int_config_mouse.c 25 Mar 2007 22:44:59 -
1.3
+++ e17/apps/e/src/bin/e_int_config_mouse.c 4 Apr 2007 15:27:59 -
@@ -96,12 +96,6 @@
&(cfdata->numerator), NULL, 200);
e_widget_framelist_object_append(of, ob);
- /*ob = e_widget_label_add(evas, _("Denominator"));
- e_widget_framelist_object_append(of, ob);
- ob = e_widget_slider_add(evas, 1, 0, _("%1.0f"), 1.0, 10.0, 1.0, 0,
- &(cfdata->denominator), NULL, 200);
- e_widget_framelist_object_append(of, ob);*/
-
ob = e_widget_label_add(evas, _("Threshold"));
e_widget_framelist_object_append(of, ob);
ob = e_widget_slider_add(evas, 1, 0, _("%1.0f"), 1.0, 10.0, 1.0, 0,
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: apps/e raster
On 04/04/2007 08:26, Enlightenment CVS wrote:
Enlightenment CVS committal
Author : raster
Project : e17
Module : apps/e
Dir : e17/apps/e/src/bin
Modified Files:
e_config.c e_config.h e_int_config_clientlist.c
e_int_config_clientlist.h e_int_menus.c
Log Message:
cedric's patches.
I don't know if this is important or not, but
The patch below was something I sent in. However when it was committed
it was noted as Cedric's. Worst case, if something goes wrong poeple
may complain to the wrong person. So... dunno if anything needs to be
done here. But I'd hate for Cedric to loose a cookie on my behalf. :P
Also, fwiw...
Attached is a patch for the patch. :P
The E_CONFIG_FILE_GENERATION needs to be bumped as the original patch
was against current cvs a month ago.
===
RCS file: /cvs/e/e17/apps/e/src/bin/e_config.c,v
retrieving revision 1.233
retrieving revision 1.234
diff -u -3 -r1.233 -r1.234
--- e_config.c 25 Mar 2007 22:44:59 - 1.233
+++ e_config.c 4 Apr 2007 13:25:54 - 1.234
@@ -511,6 +511,7 @@
E_CONFIG_VAL(D, T, clientlist_sort_by, INT);
E_CONFIG_VAL(D, T, clientlist_separate_iconified_apps, INT);
E_CONFIG_VAL(D, T, clientlist_warp_to_iconified_desktop, INT);
+ E_CONFIG_VAL(D, T, clientlist_max_caption_len, INT);
E_CONFIG_VAL(D, T, mouse_accel_numerator, INT);
E_CONFIG_VAL(D, T, mouse_accel_denominator, INT);
@@ -1357,6 +1358,10 @@
if (!e_config->icon_theme) e_config->icon_theme = evas_stringshare_add("hicolor");
+ IFCFG(0x111)
+ e_config->clientlist_max_caption_len = 0;
+ IFCFGEND;
+
e_config->config_version = E_CONFIG_FILE_VERSION;
#if 0 /* example of new config */
@@ -1475,6 +1480,7 @@
E_CONFIG_LIMIT(e_config->clientlist_sort_by, 0, 3);
E_CONFIG_LIMIT(e_config->clientlist_separate_iconified_apps, 0, 2);
E_CONFIG_LIMIT(e_config->clientlist_warp_to_iconified_desktop, 0, 1);
+ E_CONFIG_LIMIT(e_config->clientlist_max_caption_len, 0,
E_CLIENTLIST_MAX_CAPTION_LEN);
E_CONFIG_LIMIT(e_config->mouse_accel_numerator, 1, 10);
E_CONFIG_LIMIT(e_config->mouse_accel_denominator, 1, 10);
===
RCS file: /cvs/e/e17/apps/e/src/bin/e_config.h,v
retrieving revision 1.147
retrieving revision 1.148
diff -u -3 -r1.147 -r1.148
--- e_config.h 25 Mar 2007 22:44:59 - 1.147
+++ e_config.h 4 Apr 2007 13:25:54 - 1.148
@@ -253,6 +253,7 @@
int clientlist_sort_by; // GUI
int clientlist_separate_iconified_apps; // GUI
int clientlist_warp_to_iconified_desktop; // GUI
+ int clientlist_max_caption_len;
int mouse_accel_numerator; // GUI
int mouse_accel_denominator; // GUI
===
RCS file: /cvs/e/e17/apps/e/src/bin/e_int_config_clientlist.c,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -3 -r1.5 -r1.6
--- e_int_config_clientlist.c 26 Mar 2007 17:13:57 - 1.5
+++ e_int_config_clientlist.c 4 Apr 2007 13:25:54 - 1.6
@@ -17,6 +17,7 @@
int sort_by;
int separate_iconified_apps;
int warp_to_iconified_desktop;
+ int max_caption_len;
};
EAPI E_Config_Dialog *
@@ -50,6 +51,7 @@
cfdata->sort_by = e_config->clientlist_sort_by;
cfdata->separate_iconified_apps =
e_config->clientlist_separate_iconified_apps;
cfdata->warp_to_iconified_desktop =
e_config->clientlist_warp_to_iconified_desktop;
+ cfdata->max_caption_len = e_config->clientlist_max_caption_len;
}
static void *
@@ -77,6 +79,7 @@
e_config->clientlist_sort_by = cfdata->sort_by;
e_config->clientlist_separate_iconified_apps =
cfdata->separate_iconified_apps;
e_config->clientlist_warp_to_iconified_desktop =
cfdata->warp_to_iconified_desktop;
+ e_config->clientlist_max_caption_len = cfdata->max_caption_len;
e_config_save_queue();
return 1;
}
@@ -136,6 +139,11 @@
ob = e_widget_check_add(evas, _("Warp to owning desktop"),
&(cfdata->warp_to_iconified_desktop));
e_widget_framelist_object_append(of, ob);
e_widget_table_object_append(ot, of, 1, 1, 1, 1, 1, 1, 1, 1);
+
+ of = e_widget_framelist_add(evas, _("Maximum Caption Length"), 0);
+ ob = e_widget_slider_add(evas, 1, 0, _("%1.0f Chars"), 0.0,
E_CLIENTLIST_MAX_CAPTION_LEN, 2.0, 0, NULL, &(cfdata->max_caption_len), 200);
+ e_widget_framelist_object_append(of, ob);
+ e_widget_table_object_append(ot, of, 0, 2, 2, 1, 1, 1, 1, 0);
e_widget_list_object_append(o, ot, 1, 1, 0.5);
===
RCS file: /cvs/e/e17/apps/e/src/bin/e_int_config_clientlist.h,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -3 -r1.1 -r1.2
--- e_int_config_clientlist.h 21 Feb 2007 00:05:27 - 1.1
+++ e_int_config_clientlist.h 4 Apr 2007 13:25:54 - 1.2
@@
Re: [E-devel] [PATCH] Pending patch
On Wed, 21 Mar 2007 17:22:17 +0100 Cedric BAIL <[EMAIL PROTECTED]> babbled:
ok 2 patches in - edje font hash and tiler speedup - but the list sort in place
is not - the reason i removed it last time is that i found lists being sorted
were losing items. i spotted this in e17's efm code which did a lot of list
and mini-list and partial list sorting stuff (from memory). you might want to
go over that code again.
as for sdl engine and rfc for events and other things - i will get to them.
this blast of mails from you is the last major lump i need to deal with on the
e-devel list :)
> I have also some patch that are still waiting their way to the CVS.
>
> - edje_font_hash.diff: Use Evas_Hash for font lookup.
> After upgrading my ubuntu, I experienced the same bug raster
> experienced on his machine (all dialog box where empty). I was able to find
> it in _edje_font_is_embedded from edje_textblock_styles.c.
>
> static int
> _edje_font_is_embedded(Edje_File *edf, char *font)
> {
>Evas_List *l;
>
>if (!edf->font_dir) return 0;
>for (l = edf->font_dir->entries; l; l = l->next)
> {
> Edje_Font_Directory_Entry *fnt = l->data;
>
> if ((fnt->entry) && (!strcmp(fnt->entry, font)))
> return 1;
> }
>return 1;
> }
>
>I read this function too quickly, and didn't see that it really only
> check edf->font_dir. The rest was only here to slow every thing :) So now the
> patch must work correctly.
>
> - evas_list_sort_inplace.diff: Replace the merge sort algorithm with an in
> place merge sort.
> I don't remember why it didn't get inside but I am using it in my own
> code without problem and it's fast. If I have time, I should port this to
> ecore_list_sort.
>
> - evas_tiler_speedup.diff: Walk progressively over the Tilebuf_Tile.
> In some of my test I did notice that this function could take some
> time (It was with moving evas rectangle if I remember correctly). I basically
> took the costly operation out of the loop.
>
> Cedric
>
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Abstract sockets in ecore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 4 Apr 2007 20:20:43 +0900 Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> wrote: > try using scratchbox with qemu cross-exec support enabled... much easier. I know, but i can't, or, better, this way isn't the better way to do this, at this moment. I'm using a toolchain released from Cirrus that works without a chroot env (used by scratchbox, it seems to me), and i've to make EFL buildable (?) in the same way of other libraries already included. Other two points: 0) scratchbox is a very powerful system! 1) when i tried to build ecore on sb, i've got the same prob. Massimiliano - -- Massimiliano Calamelli http://mcalamelli.netsons.org [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (MingW32) iD8DBQFGE6dUleGEL56NNP4RAlnyAJ43l9H4bInb9kMoR3vxQ7ktmd0UuQCgjkQM MHUGSh57mD64dccI06abr2c= =WW8q -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] About my evas module problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 4 Apr 2007 19:53:31 +0900 Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> wrote: > so in the end.. it's a uclibc based issue... bugger :( Yes, but now is solved using uCLibc 0.9.28.3! Massimiliano - -- Massimiliano Calamelli http://mcalamelli.netsons.org [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (MingW32) iD8DBQFGE6RkleGEL56NNP4RAlgGAJ9XbwwsaidlDWBGhea6zGywEYUi6wCglPOb JWY/T0rGFJdiRwebrKW20jQ= =6S1c -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Theme selection for user applications and themes
On Thu, 29 Mar 2007 12:49:45 +0200 Andreas Volz <[EMAIL PROTECTED]> babbled: well it is possible if everyone handles xdnd and can manage to specify a specific .edj file and detect if that file is for it. also it needs to know if u are chaning theme or wanting to move the .edj file (eg a filemanager)... :) but - a lot of other fish to fry atm. > Hello, > > there're many applications and themes which provide their own edj file > as theming. If I like to install a new theme I need to read the README > where to put the user edj file and how to name it. I think a theme > selector build in every single application is also not very smart. So > why not changing themes of applications (e.g. Eclair) or modules (e.g. > tclock) with a drag and drop operation? Simply drop a edj file over > this app or module and it should change to the new theme. > > 1) Do you like/dislike this idea? Why? > > 2) Could this been done in the EFL framework? So all applications and > modules support this drag&drop theme changing with none or minimal > changes. > > I've not yet thought about global themes for EWL/ETK/E17. This toolkit > themes should be handled in another way. > > regards > Andreas > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Efreet Favorite Menu Editor
On Wed, 04 Apr 2007 01:10:00 -0400 Christopher Michael <[EMAIL PROTECTED]> babbled: you want to add del to it too? :) > Just something I whipped up, look it over, use it...dont... whichever > > Simple Favorites menu editor...only can add right now, missing efreet > menu desktop del function...see code comments. > > Thoughts welcome... > > > dh > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Resend] Abbreviating border names in clientlist menu...
On Wed, 04 Apr 2007 07:31:48 -0500 Ravenlock <[EMAIL PROTECTED]> babbled: ok- in! > Resend per Raster's request. > > Original Message > Subject: Abbreviating border names in clientlist menu > Date: Sun, 04 Mar 2007 01:31:45 -0600 > From: Ravenlock <[EMAIL PROTECTED]> > To: Enlightenment-Devel > > Hello, > > Someone had complained in irc that their client list menu was sooo wide > that it did not fit on their screen. > > The attached patch will allow a user to configure the maximum length a > menu caption can have in the client list menu. > > -- > Regards, > Ravenlock > > > -- > Regards, > Ravenlock > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] swallowed objects events
On Wed, 28 Mar 2007 19:27:41 -0300 "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> babbled: this does make sense that the parent edje can control children in this way. > Current edje just ignore events connected to a swallowed part from > inside edje and also doesn't set evas_object_pass_events_set() if > "mouse_events: 0". > > I think it's not the correct behavior since you cannot do edje > programs to act on swallowed part and also swallowed part will catch > events due missing evas_object_pass_events_set() and not pass it, even > if edje says it should not act on events. As I think edje as a theme > engine and I think this behavior should be set by theme, I've written > this patch. > > This patch also does a minor refactory to avoid code duplication: > callbacks should be added on edje_object_file_set() and > edje_object_part_swallow(), removed on edje_object_part_unswallow() > (and _swallow(), if there was an already swallowed object) and > _edje_file_del(). > > PS: There are two patches attached edje_patch_swallow_events.patch is > against cvs HEAD, edje_patch_swallow_events.relative.patch is relative > to my previous patch on edje_extern_object_*() > (edje_patch_extern.patch) > > edje_callbacks.c | 54 + > + edje_load.c | 47 --- > edje_private.h |2 ++ > edje_util.c | 17 + > 4 files changed, 77 insertions(+), 43 deletions(-) > > -- > Gustavo Sverzut Barbieri > -- > Jabber: [EMAIL PROTECTED] >MSN: [EMAIL PROTECTED] > ICQ#: 17249123 > Skype: gsbarbieri > Mobile: +55 (81) 9927 0010 > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] edje_extern_object_*() sets swallow_params and trigger recalc
On Wed, 28 Mar 2007 19:01:17 -0300 "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> babbled: this seems fine looking at it - patch in cvs. :) > This patch marks swallowed objects and when edje_extern_object_*() > functions are called on these objects, swallow_params are set and > _edje_recalc() is called. > > This patch was originally written by rephorm, but had small bugs, > which I've fixed. His original patch is > http://rephorm.com/files/patches/edje_extern.diff > > edje_util.c | 47 +++ > 1 file changed, 47 insertions(+) > > -- > Gustavo Sverzut Barbieri > -- > Jabber: [EMAIL PROTECTED] >MSN: [EMAIL PROTECTED] > ICQ#: 17249123 > Skype: gsbarbieri > Mobile: +55 (81) 9927 0010 > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] More changes to Ecore_Fb
On Tue, 27 Mar 2007 14:39:12 +0200 "Jorge Luis Zapata Muga" <[EMAIL PROTECTED]> babbled: > Hi all, i have coded several things to ecore_fb, but before doing a > commit i prefer your opinion or whishlist =) > > 1. Modules for input devices. Instead of having the input devices > exclusive (linux_input or ps2/keyboard/tslib combo), ive made an > abstraction to support input "modules" (for now they are just > statically linked - its a similar approach to what evas had on the > beginning with engines). For now we don't need real modules because > the input modules is the only module type we have. this sounds all good in principle :) > 2. More Input Devices: A while ago i coded the linux_input (event > devices) support and replace the input devices that were on ecore_fb > (tslib, keyboard, ps2) to support multiple devices (i.e two mice, > three keyboards, whatever). I've re-enabled the replaced ones, > following the module approach. sounds good again. > 3. Support for keyboard layouts, in ecore_fb the keyboard layout was > hard coded to english layout (ascii values only), with this code we > can use different layouts (spanish, french, or your own), it was coded > following the keymaps(5) idea. Ive also made a parser for keymaps (the > files you have under /usr/share/keymaps/) which will export a c source > file for now, i want to also export an eet file, but it wont be done > until my eet patch gets in. btw, where's a good place to put this > application? under /src/bin of ecore? on tests dir in cvs? well you can do an eet file - but you could just keep the keymaps parser and put it into ecore... as you already have the code :) > 4. Support for not allocating a virtual terminal (in case there's no > console attached to the fb) and code to specify which fb device to > use. that makes sense. > I still have one doubt with all of this, ecore_fb will have a lot of > flexibility (input devices, fb to use, vt to allocate, etc) so it will > fit very well for embedded/specific platforms. But we need a way to > set up the configuration for libs/apps working with ecore_fb like > ecore_evas or etk, does it makes sense to also create some kind of > configuration file with a fallback in case none exists? if so, eet, > plain text? i agree with others - some simple plain text files might be best here as it will be limited, small and used very rarely during the running of a process (i.e startup). > turran. > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Abstract sockets in ecore
On Wed, 4 Apr 2007 13:03:56 +0200 Massimiliano Calamelli <[EMAIL PROTECTED]> babbled: try using scratchbox with qemu cross-exec support enabled... much easier. > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all, i'm try to crosscompile ecore for my arm device, but configure > stops with this error: > checking abstract sockets... > configure: error: cannot run test program while cross compiling > > I looked into config.log, but i can't find any useful info. What's the > requirement for abstract sockets? I need ecore only for evas, > evas-framebuffer and events capabilities (at this moment), there's a > way to disable this check? > > Thanks > Massimiliano > - -- > Massimiliano Calamelli > http://mcalamelli.netsons.org > [EMAIL PROTECTED] > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.4 (MingW32) > > iD8DBQFGE4YcleGEL56NNP4RAkHDAJoCbcUBJMF36KFnPDuwC+pCHBblMwCfck5A > YrR/GX7GopAXY0KrwH4VdPE= > =Z7Ci > -END PGP SIGNATURE- > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Dependency graph?
On Mon, 26 Mar 2007 22:08:49 +0200 Andreas Volz <[EMAIL PROTECTED]> babbled: other than making managerial types happy who can't comprehend anything abstract - and love to see graphs and block diagrams, no matter how inaccurate they may be (and a dependency graph of efl is not simple - it is VERY complex even with just some of the base stuff. some deps are optional, some are required, some are modular at runtime etc.). how ill it help? do you have a specific question in mind? > Hello, > > is there a current dependency graph of all EFL libs and apps? There's > something on get-e.org, but that's not really recent. > > regards > Andreas > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] About my evas module problem
On Mon, 26 Mar 2007 17:28:59 +0200 Massimiliano Calamelli <[EMAIL PROTECTED]> babbled: so in the end.. it's a uclibc based issue... bugger :( > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all, googling i've found a thread that can explain better my prob, > with the loading of evas module under uclibc/arm. > I hope that it can be useful to someone. > > http://uclibc.org/lists/uclibc/2006-April/thread.html > > Follow the thread "dlopen / dlsym issue?" > > I've not solved my prob at this time (the boss has sold my devel board, > i've to wait 4/5 days for the new production), but thanks to all for > the help (especially to caro, turran and raster). > > Massi > - -- > Massimiliano Calamelli > http://mcalamelli.netsons.org > [EMAIL PROTECTED] > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.4 (MingW32) > > iD8DBQFGB+a7leGEL56NNP4RArMfAJ4taMDtF8cjTd4D+PJsQV4wTHAXZwCeJaBA > z3N+TM36XOVYalnHB7bW/EM= > =hBx6 > -END PGP SIGNATURE- > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Abstract sockets in ecore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 04 Apr 2007 14:29:06 +0200 Sebastian Dransfeld <[EMAIL PROTECTED]> wrote: > Lars Munch wrote: > > Hi Massi > > > > On Wed, Apr 04, 2007 at 01:03:56PM +0200, Massimiliano Calamelli wrote: > >> Hi all, i'm try to crosscompile ecore for my arm device, but configure > >> stops with this error: > >> checking abstract sockets... > >> configure: error: cannot run test program while cross compiling > >> > >> I looked into config.log, but i can't find any useful info. What's the > >> requirement for abstract sockets? I need ecore only for evas, > >> evas-framebuffer and events capabilities (at this moment), there's a > >> way to disable this check? > > > > I have the same problem and I simply removed the abstract sockets stuff > > from configure.in because I dont need it (yet). > > > > But what we really need is a --with-abstract-sockets or similar option. > > See previous discussion about this: > > > > http://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg11743.html > > > > Perhaps we could bribe some skilled autoconf person to add this > > configure option for us? > > It is possible to disable abstract sockets now. It is only used in > ecore_dbus, and I think ecore_dbus will die soon. > > Sebastian Already disabled with --disable-ecore-dbus, but configure check it again. Massimiliano - -- Massimiliano Calamelli http://mcalamelli.netsons.org [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (MingW32) iD8DBQFGE5xwleGEL56NNP4RAmfIAKDqNxtM+GMKxOdZnOlkRjwxBqqUPwCZASkp ZaI+dDfWUzX8FDplmfzoT6g= =QSdQ -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [Resend] Abbreviating border names in clientlist menu...
Resend per Raster's request.
Original Message
Subject: Abbreviating border names in clientlist menu
Date: Sun, 04 Mar 2007 01:31:45 -0600
From: Ravenlock <[EMAIL PROTECTED]>
To: Enlightenment-Devel
Hello,
Someone had complained in irc that their client list menu was sooo wide
that it did not fit on their screen.
The attached patch will allow a user to configure the maximum length a
menu caption can have in the client list menu.
--
Regards,
Ravenlock
--
Regards,
Ravenlock
Index: e17/apps/e/src/bin/e_config.c
===
RCS file: /var/cvs/e/e17/apps/e/src/bin/e_config.c,v
retrieving revision 1.227
diff -u -r1.227 e_config.c
--- e17/apps/e/src/bin/e_config.c 21 Feb 2007 00:05:27 - 1.227
+++ e17/apps/e/src/bin/e_config.c 4 Mar 2007 08:47:28 -
@@ -509,6 +509,7 @@
E_CONFIG_VAL(D, T, clientlist_sort_by, INT);
E_CONFIG_VAL(D, T, clientlist_separate_iconified_apps, INT);
E_CONFIG_VAL(D, T, clientlist_warp_to_iconified_desktop, INT);
+ E_CONFIG_VAL(D, T, clientlist_max_caption_len, INT);
E_CONFIG_VAL(D, T, border_raise_on_mouse_action, INT);
E_CONFIG_VAL(D, T, border_raise_on_focus, INT);
@@ -1335,6 +1336,10 @@
e_config->clientlist_warp_to_iconified_desktop = 0;
IFCFGEND;
+ IFCFG(0x111)
+ e_config->clientlist_max_caption_len = 0;
+ IFCFGEND;
+
e_config->config_version = E_CONFIG_FILE_VERSION;
#if 0 /* example of new config */
@@ -1452,6 +1457,7 @@
E_CONFIG_LIMIT(e_config->clientlist_sort_by, 0, 3);
E_CONFIG_LIMIT(e_config->clientlist_separate_iconified_apps, 0, 2);
E_CONFIG_LIMIT(e_config->clientlist_warp_to_iconified_desktop, 0, 1);
+ E_CONFIG_LIMIT(e_config->clientlist_max_caption_len, 0,
E_CLIENTLIST_MAX_CAPTION_LEN);
/* FIXME: disabled auto apply because it causes problems */
e_config->cfgdlg_auto_apply = 0;
Index: e17/apps/e/src/bin/e_config.h
===
RCS file: /var/cvs/e/e17/apps/e/src/bin/e_config.h,v
retrieving revision 1.142
diff -u -r1.142 e_config.h
--- e17/apps/e/src/bin/e_config.h 21 Feb 2007 00:05:27 - 1.142
+++ e17/apps/e/src/bin/e_config.h 4 Mar 2007 08:47:29 -
@@ -52,7 +52,7 @@
/* increment this whenever a new set of config values are added but the users
* config doesn't need to be wiped - simply new values need to be put in
*/
-#define E_CONFIG_FILE_GENERATION 0x0110
+#define E_CONFIG_FILE_GENERATION 0x0111
#define E_CONFIG_FILE_VERSION((E_CONFIG_FILE_EPOCH << 16) |
E_CONFIG_FILE_GENERATION)
#define E_EVAS_ENGINE_DEFAULT 0
@@ -252,6 +252,7 @@
int clientlist_sort_by;
int clientlist_separate_iconified_apps;
int clientlist_warp_to_iconified_desktop;
+ int clientlist_max_caption_len;
int display_res_restore; // GUI
int display_res_width; // GUI
Index: e17/apps/e/src/bin/e_int_config_clientlist.c
===
RCS file: /var/cvs/e/e17/apps/e/src/bin/e_int_config_clientlist.c,v
retrieving revision 1.2
diff -u -r1.2 e_int_config_clientlist.c
--- e17/apps/e/src/bin/e_int_config_clientlist.c1 Mar 2007 21:39:06
- 1.2
+++ e17/apps/e/src/bin/e_int_config_clientlist.c4 Mar 2007 08:47:29
-
@@ -16,6 +16,7 @@
int sort_by;
int separate_iconified_apps;
int warp_to_iconified_desktop;
+ int max_caption_len;
};
EAPI E_Config_Dialog *
@@ -48,6 +49,7 @@
cfdata->sort_by = e_config->clientlist_sort_by;
cfdata->separate_iconified_apps =
e_config->clientlist_separate_iconified_apps;
cfdata->warp_to_iconified_desktop =
e_config->clientlist_warp_to_iconified_desktop;
+ cfdata->max_caption_len = e_config->clientlist_max_caption_len;
}
static void *
@@ -74,6 +76,7 @@
e_config->clientlist_sort_by = cfdata->sort_by;
e_config->clientlist_separate_iconified_apps =
cfdata->separate_iconified_apps;
e_config->clientlist_warp_to_iconified_desktop =
cfdata->warp_to_iconified_desktop;
+ e_config->clientlist_max_caption_len = cfdata->max_caption_len;
return 1;
}
@@ -135,6 +138,11 @@
//e_widget_list_object_append(o, of, 1, 1, 0.5);
e_widget_table_object_append(ot, of, 1, 1, 1, 1, 1, 1, 1, 1);
+ of = e_widget_framelist_add(evas, _("Maximum Caption Length"), 0);
+ ob = e_widget_slider_add(evas, 1, 0, _("%1.0f Chars"), 0.0,
E_CLIENTLIST_MAX_CAPTION_LEN, 2.0, 0, NULL, &(cfdata->max_caption_len), 200);
+ e_widget_framelist_object_append(of, ob);
+ e_widget_table_object_append(ot, of, 0, 2, 2, 1, 1, 1, 1, 0);
+
e_widget_list_object_append(o, ot, 1, 1, 0.5);
return o;
Index: e17/apps/e/src/bin/e_int_config_clientlist.h
===
RCS file: /var/cvs/e/e17/apps/e/src/bin/e_int_config_clientlist.h,v
retrieving revision 1.1
diff -u -r1.1 e_int_config_cli
Re: [E-devel] Abstract sockets in ecore
Lars Munch wrote: > Hi Massi > > On Wed, Apr 04, 2007 at 01:03:56PM +0200, Massimiliano Calamelli wrote: >> Hi all, i'm try to crosscompile ecore for my arm device, but configure >> stops with this error: >> checking abstract sockets... >> configure: error: cannot run test program while cross compiling >> >> I looked into config.log, but i can't find any useful info. What's the >> requirement for abstract sockets? I need ecore only for evas, >> evas-framebuffer and events capabilities (at this moment), there's a >> way to disable this check? > > I have the same problem and I simply removed the abstract sockets stuff > from configure.in because I dont need it (yet). > > But what we really need is a --with-abstract-sockets or similar option. > See previous discussion about this: > > http://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg11743.html > > Perhaps we could bribe some skilled autoconf person to add this > configure option for us? It is possible to disable abstract sockets now. It is only used in ecore_dbus, and I think ecore_dbus will die soon. Sebastian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Abstract sockets in ecore
Hi Massi On Wed, Apr 04, 2007 at 01:03:56PM +0200, Massimiliano Calamelli wrote: > Hi all, i'm try to crosscompile ecore for my arm device, but configure > stops with this error: > checking abstract sockets... > configure: error: cannot run test program while cross compiling > > I looked into config.log, but i can't find any useful info. What's the > requirement for abstract sockets? I need ecore only for evas, > evas-framebuffer and events capabilities (at this moment), there's a > way to disable this check? I have the same problem and I simply removed the abstract sockets stuff from configure.in because I dont need it (yet). But what we really need is a --with-abstract-sockets or similar option. See previous discussion about this: http://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg11743.html Perhaps we could bribe some skilled autoconf person to add this configure option for us? -- Lars Munch - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Abstract sockets in ecore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, i'm try to crosscompile ecore for my arm device, but configure stops with this error: checking abstract sockets... configure: error: cannot run test program while cross compiling I looked into config.log, but i can't find any useful info. What's the requirement for abstract sockets? I need ecore only for evas, evas-framebuffer and events capabilities (at this moment), there's a way to disable this check? Thanks Massimiliano - -- Massimiliano Calamelli http://mcalamelli.netsons.org [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (MingW32) iD8DBQFGE4YcleGEL56NNP4RAkHDAJoCbcUBJMF36KFnPDuwC+pCHBblMwCfck5A YrR/GX7GopAXY0KrwH4VdPE= =Z7Ci -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17 installation report in new distro (fai debian etch)
On Sun, 25 Mar 2007 14:18:18 +0200 Michel BRIAND <[EMAIL PROTECTED]> babbled: > Hello > > in my new company, with a friend of mine, we have started a > "Linux Master Server" project: ie with FAI we install all new computers > automaticaly. We have chosen Debian Etch as a starting point but with a > few improvements. E17 is one of the most important ones. > > We ran into a few troubles with Entrance: > > 1/ > The PIDFILE defined in /etc/init.d/entrance does not match the real one > created by entranced. In the source tree I can see that it has been > fixed. Is it the case in the trunk ? Is your .deb up to date ? > > 2/ > Entrance does not run the Debian Xsession scheme. I've tried to change > the /etc/entrance/Xsession file but to no avail. Does anyone have a > solution or even a clue ? > > 3/ > Enlightenment has its main menu broken. > 3.1/ > The "Applications" dialog is obviously broken (graphicaly): > the left part of it is stucker in a rectangle in the left top > corner, unusable this is being broken and fixed up right now. it's now working again - but results may vary from distribution to distribution. i suspect its broken on debian due to the way debian splits up the applicatiosn menu config and has no "system default" one. (but has one for kde and one for gnome etc...) > 3.2/ > In this dialog the "regenerate menus" button, which did not > worked in the 12/03 .deb update, is no more visible. I can't say > if it works now ;) 'cause I can't click on it. > Is there a command line utility to create menus ? now it's not relevant. the applications config dialog is broken atm. > 3.3/ > I can drag a application from the "applications" dialog to the > Ibar : it works. But I would make a comment: the widget that is > under the mouse is a big rectangle taken from the app dialog > list, and it is not easy to drop it in the Ibar at the point > one's want to... since the mouse pointer is no more visible... > same as above. > Enlightenment has still a problem with svg: going through the icon theme > dialog, one would just dig into an svg directory and press the apply > button... > Bug reproducable since six months or so. this is a librsvg bug. you'd be amazed how buggy it is. > 5/ > The mixer applet (or module) is not usable: it simply does not work. It > starts and show a nice ruler but: > 5.1/ > Each time the applet receive a mouse button it opens and > activate the mute check box: that way you have always the mute > checked... > The ruler does not make the sound volume to change !?? > > 6/ > We would like to discuss about the media mounting/unmounting... It > would be nice to have a media menu in E to help new users to use > linux... And E17 deserve a better design than kde for this... Is there > anyone that wants to start a design discussion about this ? e17 has this already. it's filemanager handles dbus hal events, if you plug in removable media and hal finds it - e17 puts an icon in favorites - opening the folder in e's fm2 will auto-mount it and unmount when all windows are closed that use it. it's not perfect - but proof of concept works. the infrastructure is there - but needs work - fm2 needs a lot of work and i will get to it - if i can tame my email monster :) > ** But the picture is not so bad, I would say that E17 is in a good > shape and that it can be used by non-geek users (corporate users). > 80% of functions are working well, and the window manager does > its job perfectly. ** no - not there yet. it needs work - the problem is basically having the people who know the code well have the time to spend. the base libs are very solid now - it's the wm itself that needs work - filemanager needs completion so people can have their "icons on the desktop". i recently did a retake of the fm backend to remove "slow fs" problems. this broke a few things and needs work in fm2 to bring it even back up to where it was before. BUT it will also be able to simplify some things. this means file selectors, wallpaper browsers and more can be much more solid - and people can find and open their files, manage them simply without another extra fm (they can always use one anyway - e needs the fm for its own dialogs, etc. anyway). > I would like to thanks everyone that has worked hard in the last year > to make this real :) > > Best regards, > Michel > > > > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/
Re: [E-devel] Desklock's idle timer....
On Wed, 21 Mar 2007 06:00:46 -0500 Ravenlock <[EMAIL PROTECTED]> babbled: > On 03/21/2007 04:47, Carsten Haitzler (The Rasterman) wrote: > > On Mon, 19 Mar 2007 00:50:26 -0500 Ravenlock <[EMAIL PROTECTED]> > > babbled: > > > >> Hello, > >> > >> The desklock's idle timer was apparently broken from the start. > >> Keyboard activity was not considered when determining if the user was > >> active or not. > >> > >> Here are some patches which fix this. With these patches a persons > >> keyboard and mouse activity are both taken into consideration when > >> determining if the user is active. > >> > >> This implementation requires that the XScreensaver extension be present. > >> This is the "easy" fix. If the powers that be prefer that this > >> functionality *not* depend on the XScreensaver extension, well... then > >> its a bigger problem. > >> > >> Questions/comments/complaints welcome. :) > > > > actually desklocks idle thing has always been broken. the e_manage though > > uses the xscreensaver events in _e_manager_cb_screensaver_notify() to turn > > on desklock if the screensaver kicks in :) > > > > *That* timer still exists. However, I created a new timer that was > separate from that which will allow a user to "lock" the screen either > before or after the X screesaver, or at the same time as some other > third party saver. That timer was not functioning properly. I am > hoping this patch fixes the problem I introduced. a patch read seems to show that desklock still runs a timer and polls idle time - e_manager already uses the screensaver event (blank timeout kicked in) to signal desklock to "go". i should remove the idle timer stuff from desklock anyway as not depending on screensaver really isn't sane as you can't really necessarily intercept key stroked everywhere on the screen and same for mouse. > > >> -- > >> Regards, > >> Ravenlock > >> > > > > > > > -- > Regards, > Ravenlock > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] patch for the pager module, about window urgent state support
On Fri, 23 Mar 2007 16:24:55 +0100 Laurent Ghigonis <[EMAIL PROTECTED]> babbled: doesn't look too bad - in cvs :) > > Here is a little patch for the pager module, > > that basically able the user to show the pager popup on window urgent > > state change. > > I did some changes on my patch, the new one is attached. > > > Details of the patch : > > new from last patch : > * if the urgent window gets focused, close the > popup > * new from last patch : show popup if the urgent window is on the > current desk too, but is not focused > > old patch things : > * fix: show the urgent state of a window even if the urgent state was > set before the pager start > * show the urgent state of windows in the pager popup > * the pager pops its popup on window urgent state change (configurable) > * a desktop can be selected in the pager popup, but all other actions > actions are still forbidden inside the popup > > > It adds 3 options in the pager configuration panel : > 1. "show popup on urgent window" > 2. "urgent popup sticks on the screen" > 3. "urgent popup timer" > > > laurent 'kiwi_' -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Maximize Patch
On Fri, 16 Mar 2007 13:42:27 -0500 "Sthithaprajna Garapaty" <[EMAIL PROTECTED]> babbled: > Arr! E! looky like you needs a eye patch fer yer dreadful voyages. > Here's a small one that'll make ya look real scary while yer > swashbuckin! > > The maximize code needs fixing. Or there needs to be a new maximize mode. > That maximizes without making my windows go under the shelf ever. > But that's too much work. > > So here's a patch that'll let the user set the size and position the > window should get to when maximizing. > This can also be useful if the user has other apps that he'd rather > not overlap while maximizing. > (instant messangers and such) > Bad news, the user has to figure out the dimensions themselves and > input 'em into this. you know... you could have made this simpler. instead of entering the x,y w and h with sliders - just have a menu item "snapshot current geometry as maximized size" or something - then store whatever the window is at. less gui to deal with, easier for users. if you can change it to that - i'll accept :) > --Sthitha > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Cutout
On Thu, 29 Mar 2007 20:38:43 +0200 Tilman Sauerbeck <[EMAIL PROTECTED]> babbled: actually tilmans cleanup might be nicer to take for now - this is good. it actually does get a noticable seedup - maybe i should audit evas for pointless malloc and other mem calls during rendering to minimise overhead. in cvs. > Cedric BAIL [2007-03-29 17:58]: > > Another little patch that potentially break every thing and need > > review. To make the story short, when you have a lot of image on the screen > > with many cliping, you are creating and destroying many time Cutout_Rect > > object. So I changed the code to do less allocation/destruction. It also > > break the API used by the engine, so a patch for them is needed. > > Looks good in general. > > I attached a modified version of your patch where I removed some > oddities: > > In evas_common_draw_context_cutouts_del(), I renamed "delta" to "index". > "delta" implies (for me) that it's the difference between two values, > but it really is an index ;) > > I also removed some unrelated changes that crept into the patch, like > that "error_data" enum that wasn't referenced anywhere, and a few > whitespace-only changes. > > Not sure whether I'm brave enough to commit this :) > > Regards, > Tilman > > -- > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail? > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] bug in evas
On Wed, 28 Mar 2007 20:36:17 -0500 "Nathan Ingersoll" <[EMAIL PROTECTED]> babbled: > On 3/28/07, Brian Mattern <[EMAIL PROTECTED]> wrote: > > > > I) Absolute canvas coordinates > > _point_add() takes a coordinate in canvas coords, and draws that point > > at that coordinate, completely ignoring the object's position > > This way sucks as it requires the user to track all of the polygons > points and update them on a move. sure - but the other side (relative to object top-left) means that either you need oversized poly object that cover thw whole canvas and only use a sub-set of their space for the poly if you want to be able to place/define a poly in abs co-ords. this is common as you may calculate points based on a higher level layout nd thus have abs coords as the output - otherwise you need to figure out min/max, move the obj then define poly coords - so you make 1 case easier, and the other harder. > > II) Relative object coordinates > > _point_add() takes a coord relative to the object, so if the poly is > > moved to (10,10) the point (5,5) will be drawn at (15,15). > > Somewhat more sane as it at least allows for easily moving a polygon > from the users perspective, but size handling would probably be > non-intuitive clipping of the image. > > > III) Polygon coordinates > > _point add() takes points in an abstract space. This space is located > > such that the origin of the object corresponds to top left of the > > bounding box of the polygon's points. > > I think this one makes the most sense from an API perspective. Moving > the polygon object would obviously update the relative coordinates > like (II), but the size change could be used to scale the polygon. > > > I'm impartial as to whether (II) or (III) is better. (II) is a bit more > > predictable, though. > > I think it depends what you expect from resizing as to which is more > predictable. If you want scaling then (III) is more predictable, but > if you want clipping then (II) is. The problem with (II) is that you > can easily emulate the clipping behavior with a clip rect, but scaling > would require the user to iterate over the points themselves and scale > their locations manually. > > > As for the size clipping the poly's extents, that makes some sense, but > > I think the default expected behavior would be for it to be large enough > > to show all of its points. So, maybe it would be better to ignore the > > size? > > This should probably behave like images for initial sizing. If images > have an initial size equal to their image size, then the polygon > should assume a 1:1 scale and have an initial size large enough to > contain all of their points. > > Sound reasonable? actually image objects dont have initial size of the image size. they have an initial size of 32x32 as to all evas objects that don't specify their own geometry explicitly (poly, line and text objects have their size/position altered by contents. a problem when scaling is cumulative error. u scale down to 1/100th then back up to normal size and you will lose a lot of precision on your points. so this means points need to be stored in the original object size space and scaled on the fly at render to avoid cumulative error. on point add or reset, you basically get a new geometry space that is the size of the obj... all in all this isnt a simple solution. the only way i see to handle both methods is to have 2 calls. 1 to add a point relative to origin and one to specify it absolutely. > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
