[E-devel] fix building deb packages
Index: apps/e/debian/enlightenment.install === RCS file: /var/cvs/e/e17/apps/e/debian/enlightenment.install,v retrieving revision 1.11 diff -u -3 -r1.11 enlightenment.install --- apps/e/debian/enlightenment.install 8 Jul 2006 14:59:10 - 1.11 +++ apps/e/debian/enlightenment.install 31 Jul 2006 07:02:21 - @@ -1,6 +1,5 @@ debian/tmp/usr/bin/enlightenment debian/tmp/usr/bin/enlightenment_* -debian/tmp/usr/lib/enlightenment/preload/*.so debian/tmp/usr/lib/enlightenment/modules/battery/*/*.so debian/tmp/usr/lib/enlightenment/modules/battery/*.eap debian/tmp/usr/lib/enlightenment/modules/clock/*/*.so -- Vlad Alyukov RT QA Engineer SWsoft, Inc. - 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 urandom
On Fri, Jul 28, 2006 at 07:22:57PM -0400, Enlightenment CVS wrote: > Enlightenment CVS committal > > Author : urandom > Project : e17 > Module : apps/e > > Dir : e17/apps/e/src/bin > > > Modified Files: > e_menu.c e_menu.h > > > Log Message: > function for adding evas objects as icons in the menus > How about using this in e17's window list (middle click or left click > Windows)? I like the split between 'windows on this desktop' and 'windows on other desktops' that is in the winselector module. Maybe we could make this an optional sort style for the normal window list? (Then winselector would simply be a gadget displaying the current windows' icon, which showed the window menu when clicked). -- rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17 'todo'
On Sun, 30 Jul 2006 22:47:23 -0500 [EMAIL PROTECTED] babbled: > On Mon, Jul 31, 2006 at 10:36:29AM +0900, Carsten Haitzler wrote: > > On Mon, 31 Jul 2006 00:37:42 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > > babbled: > > > > > > > > As part of a recent cvs commit of various e "TODO" stuff, > > > Carsten writes: > > > > > > > * bg needs a gradient dialog that can take a set of pre-drawn > > > > png's and edc recipies and use colored rects and overlayed > > > > png's recolored with color options to create vertical, > > > > horizontal, radial etc. gradients quickly and save to an edc > > > > > > After reading this a couple of times, I had a beer and then > > > read it again a couple of more times... I still have absolutely NO > > > idea what the heck this means! :) :) > > > > so you can define gradients for a bg - but store the saved config in a .edj > > file. use an imag with a pre-rendered alpha->white gradient (horz, vert, > > radial) then use a bg rect for one color and set the color of the gradient > > image object to determine the 2nd color for the gradient - and then just > > properties (scale, tile, which image, where and the 2 colors). a quick way > > for users to get a gradient bg that they can share with friends, other > > computers etc. just like images in .edj files. identical mechanism. > > > > Wouldn't it more sense to add evas gradient support to edje? sure - except 3 things 1. need to dd the code to edje 2. gradients are slower than image manipulation - especially in non-software engines 3. you need a gui to select attributes for your gradient anyway so this need still stands - it simply would implement it using manipulated images recoloured in edje :) were gradients supported in edje then 3. could use it as a saving mechanism - but you still may hit performance issues with 2. remember gradients re one of the least used and least optimised bits of evas - admittedly using them will force them to be optimized but i'd hoped to put that off so we wouldn't need to do it before e17 :) then again we do need to do a major overhaul of evas engine internals - at lest colorspace and engine api... :( > E.g. something like: > > collections { > group { > name: "grad_test"; > parts { > part { > name: "grad"; > type: GRADIENT; > description { > gradient { > angle: 90; > spread: 1; > color: 255 255 255 255 0; // r g b a distance > color: 0 0 0 0 1; > } > } > } > } > } > } > > which would result in something like: > > http://rephorm.com/files/dump/edje_grad.png > > (actual screenshot) > > I still have a bit more to add and test, but looks fairly straightforward. > The only question would be how to transition between states on a GRADIENT > part. Do we actually try to calculate a transition gradient? This would be > straightforward if the control points were at the same distances. For others, > it gets more complex (would need get the union of control point locations for > both sides, and then interpolate from there). Shouldn't be unreasonable > though. well indeed - nice, grad objs. need to do more than linear tho... and then how to specify all the params of other gradient types... anyway. for tweening transitions. this is tough. if start and end gradients dont have the same control points (number, position) what do you do? do you try and merge control points? or do you do a merged overlay of all control points so the intermediat grad is a superset of all control points (exact duplicates removed) and then just linear interp the colors of these control points (and calculate their rgba from their appropriate positions in the start and end grdients). i would say that is what you want... :) -- - 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] E17 'todo'
On Mon, Jul 31, 2006 at 10:36:29AM +0900, Carsten Haitzler wrote: > On Mon, 31 Jul 2006 00:37:42 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > babbled: > > > > > As part of a recent cvs commit of various e "TODO" stuff, > > Carsten writes: > > > > > * bg needs a gradient dialog that can take a set of pre-drawn > > > png's and edc recipies and use colored rects and overlayed > > > png's recolored with color options to create vertical, > > > horizontal, radial etc. gradients quickly and save to an edc > > > > After reading this a couple of times, I had a beer and then > > read it again a couple of more times... I still have absolutely NO > > idea what the heck this means! :) :) > > so you can define gradients for a bg - but store the saved config in a .edj > file. use an imag with a pre-rendered alpha->white gradient (horz, vert, > radial) then use a bg rect for one color and set the color of the gradient > image object to determine the 2nd color for the gradient - and then just > properties (scale, tile, which image, where and the 2 colors). a quick way for > users to get a gradient bg that they can share with friends, other computers > etc. just like images in .edj files. identical mechanism. > Wouldn't it more sense to add evas gradient support to edje? E.g. something like: collections { group { name: "grad_test"; parts { part { name: "grad"; type: GRADIENT; description { gradient { angle: 90; spread: 1; color: 255 255 255 255 0; // r g b a distance color: 0 0 0 0 1; } } } } } } which would result in something like: http://rephorm.com/files/dump/edje_grad.png (actual screenshot) I still have a bit more to add and test, but looks fairly straightforward. The only question would be how to transition between states on a GRADIENT part. Do we actually try to calculate a transition gradient? This would be straightforward if the control points were at the same distances. For others, it gets more complex (would need get the union of control point locations for both sides, and then interpolate from there). Shouldn't be unreasonable though. -- rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17 'todo'
On Mon, 31 Jul 2006 00:37:42 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> babbled: > > As part of a recent cvs commit of various e "TODO" stuff, > Carsten writes: > > > * bg needs a gradient dialog that can take a set of pre-drawn > > png's and edc recipies and use colored rects and overlayed > > png's recolored with color options to create vertical, > > horizontal, radial etc. gradients quickly and save to an edc > > After reading this a couple of times, I had a beer and then > read it again a couple of more times... I still have absolutely NO > idea what the heck this means! :) :) so you can define gradients for a bg - but store the saved config in a .edj file. use an imag with a pre-rendered alpha->white gradient (horz, vert, radial) then use a bg rect for one color and set the color of the gradient image object to determine the 2nd color for the gradient - and then just properties (scale, tile, which image, where and the 2 colors). a quick way for users to get a gradient bg that they can share with friends, other computers etc. just like images in .edj files. identical mechanism. > And hey, where is the todo item about converting e_wm to > use 'engines' for its widgetry stuff.. :) there isn't :) not for e17 anyway. :) > >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 > -- - 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
[E-devel] E17 'todo'
As part of a recent cvs commit of various e "TODO" stuff, Carsten writes: > * bg needs a gradient dialog that can take a set of pre-drawn > png's and edc recipies and use colored rects and overlayed > png's recolored with color options to create vertical, > horizontal, radial etc. gradients quickly and save to an edc After reading this a couple of times, I had a beer and then read it again a couple of more times... I still have absolutely NO idea what the heck this means! :) :) And hey, where is the todo item about converting e_wm to use 'engines' for its widgetry stuff.. :) 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] engage is ready for composite
Ok, new patch minus one dumb mistake. I Should have first look at the the theme data... usage is now: engage -T false -m 0 -t none -B caff -C 1 ? engage-composite-redraw_timer-2.patch ? engage-composite-redraw_timer.patch ? engage-composite.patch Index: config.c === RCS file: /var/cvs/e/misc/engage/src/config.c,v retrieving revision 1.58 diff -u -r1.58 config.c --- config.c 25 Feb 2006 18:29:04 - 1.58 +++ config.c 31 Jul 2006 00:31:56 - @@ -136,7 +136,12 @@ "ignore-running", "Ignore running apps"); ecore_config_boolean_create("engage.options.ignore_iconified", 0, 'I', "ignore-iconified", "Ignore iconified windows"); - + + + ecore_config_boolean_create("engage.options.use_composite", 0, 'C', + "use-composite","Use with composite manager for nice transparency effects"); + + ecore_config_load(); ret = ecore_config_args_parse(); @@ -179,7 +184,8 @@ options.tray = ecore_config_boolean_get("engage.options.tray"); options.ignore_run = ecore_config_boolean_get("engage.options.ignore_running"); options.ignore_min = ecore_config_boolean_get("engage.options.ignore_iconified"); - + + options.use_composite = ecore_config_boolean_get("engage.options.use_composite"); return ret; } Index: dock.c === RCS file: /var/cvs/e/misc/engage/src/dock.c,v retrieving revision 1.20 diff -u -r1.20 dock.c --- dock.c 25 Oct 2005 00:54:54 - 1.20 +++ dock.c 31 Jul 2006 00:31:56 - @@ -118,11 +118,25 @@ need_redraw = true; } +double lasttime = 0; + void od_dock_redraw(Ecore_Evas * ee) { - Evas_List *item = dock.icons; + +double time = ecore_time_get(); + + if(time - lasttime < 0.04) + { + // need_redraw = false; // + return; + } + +lasttime = time; + + + Evas_List *item = dock.icons; while (item) { OD_Icon*icon = (OD_Icon *) item->data; Index: engage.h === RCS file: /var/cvs/e/misc/engage/src/engage.h,v retrieving revision 1.30 diff -u -r1.30 engage.h --- engage.h 25 Oct 2005 00:54:54 - 1.30 +++ engage.h 31 Jul 2006 00:32:00 - @@ -104,6 +104,7 @@ unsignedbg_fore, bg_back; // color - ARGB double icon_appear_duration; int tray, ignore_run, ignore_min; + int use_composite; }; struct _OD_Window { Index: window.c === RCS file: /var/cvs/e/misc/engage/src/window.c,v retrieving revision 1.31 diff -u -r1.31 window.c --- window.c 13 Jun 2005 18:55:14 - 1.31 +++ window.c 31 Jul 2006 00:32:02 - @@ -6,6 +6,8 @@ #include #include #include +#include + #ifdef XINERAMA #include #endif @@ -32,6 +34,22 @@ static void handle_menu_draw(void *data, Evas * e, Evas_Object * obj, void *event); static void od_window_set_hidden(int hidden); +static void window_input_shape_rectangle_set(Ecore_X_Window win, int x, int y, int w, int h); + + +static void +window_input_shape_rectangle_set(Ecore_X_Window win, int x, int y, int w, int h) +{ + XRectangle rect; + + rect.x = x; + rect.y = y; + rect.width = w; + rect.height = h; + XShapeCombineRectangles(ecore_x_display_get(), win, ShapeInput, 0, 0, &rect, 1, ShapeSet, Unsorted); +} + + int od_window_hide_timer_cb(void *data) { @@ -82,6 +100,13 @@ { if (_ee != ee) return; + + if(options.use_composite) + { +Ecore_X_Window win = ecore_evas_software_x11_window_get(_ee); +window_input_shape_rectangle_set(win,0,0,options.width,options.height); + } + if (mouse_focus_timer) ecore_timer_del(mouse_focus_timer); mouse_focus_timer = NULL; @@ -94,6 +119,13 @@ { if (_ee != ee) return; + + if(options.use_composite) // it should be enough to do this at zoom out, but so it looks less cluttered + { +Ecore_X_Window win = ecore_evas_software_x11_window_get(_ee); +window_input_shape_rectangle_set(win,0,options.height-options.size,options.width,options.size); + } + if (mouse_focus_timer) ecore_timer_del(mouse_focus_timer); mouse_focus_timer = ecore_timer_add(0.5, od_window_hide_timer_cb, NULL); @@ -188,7 +220,7 @@ if (!(strcmp(options.engine, "gl"))) ee = ecore_evas_gl_x11_new(NULL, 0, (int) ((res_x - options.width) / 2.0 + x), - (int) (res_y - options.height + y), + (int) (res_y - options.height + y), options.width, options.height); else { if (strcmp(options.engine, "software")) { @@ -198,18 +230,33 @@ } ee = ecore_evas_software_x11_new(NULL, 0,
Re: [E-devel] Ecore_List bugs
Hi, On 7/30/06, Simon TRENY <[EMAIL PROTECTED]> wrote: > Hi there, > > I notice some "bugs" (or strange behaviour) in the calling policy of > the free-callback in Ecore_List: Strange behavior maybe (depending on your perspective), but the listed behavior below is how they are intended to work. > - If you call ecore_list_destroy(), the free-callback will indeed be > called on all the elements. > - If you call ecore_list_clear(), the free_cb won't be called. This API distinction was made so that you could have a list with a free callback, but still have a way to remove all items from the list without freeing them. For a somewhat artificial example, say you have a queue of file descriptors that you copy to an fd set for use with select or poll. The list keeps a reference until all the descriptors are copied successfully, then clears them out until they get re-submitted. You may also want to be able to have a free callback that will close all the fd's when you destroy the list. While the example may not be common place, I have hit a couple of circumstances where I've needed the capability to clear out the list without calling the free callback. > - ecore_list_remove() doesn't call the free_cb neither. Ok, there is > ecore_list_remove_destroy(), but I just find it really confusing. When > you set a free_cb, you usually want it to be called when you remove an > element. All of the ecore_list_remove functions return the value that was removed from the list. This is so you can easily use it as a stack or queue. From an API consistency standpoint, it didn't make sense to have the remove functions perform differently depending on whether there was a free callback assigned, and the pointer would most likely be invalid after the free callback was triggered. > Another thing, why is there a distinction between Ecore_List and > Ecore_DList? It is just to save a pointer per node in the memory? > Because, I don't think it is worth it, and it's just confusing imho. While the space savings are negligible (non-existent due to allocation alignment in most cases), it just distinguishes between a singly and doubly linked list. I don't see a disadvantage of supplying both data structures and the programmer should know which one fits their circumstances. Also, with the abstracted API and the fact that internal node pointers aren't exposed, we could add defragmenting capabilities to the list code to group allocations of nodes and actually gain memory savings from that missing pointer. If the memory fragmentation can be reduced, then 4 to 8 bytes per list entry seems worthwhile to me when dealing with large lists. This may be able to be improved even more by grouping value pointers without a full node. Nathan - 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] engage is ready for composite
Ok, the patch is so damn small. I just post it on the list for everyone interested to try this out. :) The patch is made with cvs diff -u in the engage/src dir. Usage: Start compmgr, compiz or whatever does compositing. then I encourage to use these params: engage -T false -m 0 -t gentoo -b caff -C 1 -P 1 I also included a timer for the redraw function. To me 25 fps are enough and engage sucks with this only half as much cpu cylcles than before. Have Fun. Regards, Hannes ? engage-composite-redraw_timer.patch ? engage-composite.patch Index: config.c === RCS file: /var/cvs/e/misc/engage/src/config.c,v retrieving revision 1.58 diff -u -r1.58 config.c --- config.c 25 Feb 2006 18:29:04 - 1.58 +++ config.c 30 Jul 2006 22:59:24 - @@ -136,7 +136,14 @@ "ignore-running", "Ignore running apps"); ecore_config_boolean_create("engage.options.ignore_iconified", 0, 'I', "ignore-iconified", "Ignore iconified windows"); - + + + ecore_config_boolean_create("engage.options.use_composite", 0, 'C', + "use-composite","Use with composite manager for nice transparency effects"); + + ecore_config_boolean_create("engage.options.position_bug_workaround", 0, 'P', + "position-bug-workaround","If the window seems to be at the bottom, ca. 5 pixels to high, try this"); + ecore_config_load(); ret = ecore_config_args_parse(); @@ -179,7 +186,9 @@ options.tray = ecore_config_boolean_get("engage.options.tray"); options.ignore_run = ecore_config_boolean_get("engage.options.ignore_running"); options.ignore_min = ecore_config_boolean_get("engage.options.ignore_iconified"); - + + options.use_composite = ecore_config_boolean_get("engage.options.use_composite"); + options.position_bug_workaround = ecore_config_boolean_get("engage.options.position_bug_workaround"); return ret; } Index: dock.c === RCS file: /var/cvs/e/misc/engage/src/dock.c,v retrieving revision 1.20 diff -u -r1.20 dock.c --- dock.c 25 Oct 2005 00:54:54 - 1.20 +++ dock.c 30 Jul 2006 22:59:25 - @@ -118,11 +118,25 @@ need_redraw = true; } +double lasttime = 0; + void od_dock_redraw(Ecore_Evas * ee) { - Evas_List *item = dock.icons; + +double time = ecore_time_get(); + + if(time - lasttime < 0.04) + { + // need_redraw = false; // + return; + } + +lasttime = time; + + + Evas_List *item = dock.icons; while (item) { OD_Icon*icon = (OD_Icon *) item->data; Index: engage.h === RCS file: /var/cvs/e/misc/engage/src/engage.h,v retrieving revision 1.30 diff -u -r1.30 engage.h --- engage.h 25 Oct 2005 00:54:54 - 1.30 +++ engage.h 30 Jul 2006 22:59:30 - @@ -104,6 +104,7 @@ unsignedbg_fore, bg_back; // color - ARGB double icon_appear_duration; int tray, ignore_run, ignore_min; + int use_composite, position_bug_workaround; }; struct _OD_Window { Index: window.c === RCS file: /var/cvs/e/misc/engage/src/window.c,v retrieving revision 1.31 diff -u -r1.31 window.c --- window.c 13 Jun 2005 18:55:14 - 1.31 +++ window.c 30 Jul 2006 22:59:31 - @@ -6,6 +6,8 @@ #include #include #include +#include + #ifdef XINERAMA #include #endif @@ -32,6 +34,22 @@ static void handle_menu_draw(void *data, Evas * e, Evas_Object * obj, void *event); static void od_window_set_hidden(int hidden); +static void window_input_shape_rectangle_set(Ecore_X_Window win, int x, int y, int w, int h); + + +static void +window_input_shape_rectangle_set(Ecore_X_Window win, int x, int y, int w, int h) +{ + XRectangle rect; + + rect.x = x; + rect.y = y; + rect.width = w; + rect.height = h; + XShapeCombineRectangles(ecore_x_display_get(), win, ShapeInput, 0, 0, &rect, 1, ShapeSet, Unsorted); +} + + int od_window_hide_timer_cb(void *data) { @@ -82,6 +100,13 @@ { if (_ee != ee) return; + + if(options.use_composite) + { +Ecore_X_Window win = ecore_evas_software_x11_window_get(_ee); +window_input_shape_rectangle_set(win,0,0,options.width,options.height); + } + if (mouse_focus_timer) ecore_timer_del(mouse_focus_timer); mouse_focus_timer = NULL; @@ -94,6 +119,13 @@ { if (_ee != ee) return; + + if(options.use_composite) // it should be enough to do this at zoom out, but so it looks less cluttered + { +Ecore_X_Window win = ecore_evas_software_x11_window_get(_ee); +window_input_shape_rectangle_set(win,0,options.height-options.size,options.width,options.size); + } + if (mouse_focus_timer) eco
Re: [E-devel] Ecore_List bugs
On Sun, Jul 30, 2006 at 08:10:09PM +0200, Simon TRENY wrote: > Hi there, > > I notice some "bugs" (or strange behaviour) in the calling policy of > the free-callback in Ecore_List: > - If you call ecore_list_destroy(), the free-callback will indeed be > called on all the elements. > - If you call ecore_list_clear(), the free_cb won't be called. > - ecore_list_remove() doesn't call the free_cb neither. Ok, there is > ecore_list_remove_destroy(), but I just find it really confusing. When > you set a free_cb, you usually want it to be called when you remove an > element. It makes sense to me to have two sets of list removal calls. Often, you add/remove objects that are used elsewhere to/from lists, so removing them from the list doesn't at all correspond to deleting them. (i.e. no free necessary). But, I haven't used ecore lists much. I guess you just wouldn't set a free callback for lists of such items. So, perhaps a bit confusing. Also, I noticed that _destroy() frees the list itself (in addition to the items). The header file make it look like that's the only difference between _clear() and _destroy(). So you're probably right that _clear() should call the item free callback. -- rephorm - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] engage is ready for composite
Am Sun, 30 Jul 2006 22:55:37 +0900 schrieb Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>: > On Sun, 30 Jul 2006 14:29:29 + Hannes Janetzek > <[EMAIL PROTECTED]> babbled: > > > Am Sat, 29 Jul 2006 20:31:10 +0900 > > schrieb Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>: > > > > > On Sat, 29 Jul 2006 10:38:01 + Hannes Janetzek > > > <[EMAIL PROTECTED]> babbled: > > > > > > > Hi, > > > > > > > > I´m trying to make engage work in a composite environment. > > > > Everything works fine so far. The Problem is when I use > > > > set_alpha and then set_shaped, the whole window still recieves > > > > input events. Does shape_set not work if the window was set up > > > > to use alpha channel? If so, have somebody an idea how to work > > > > around this? > > > > > > correct - shaped and alpha are mutually exclusive. you woudl need > > > to manually generate a shape mask and set the input event mask > > > (new addition to shape extn) to what u want... ie - what u want > > > isnt supported in ecore/evas. > > > > hm, I did it manually but the window still gets focus when the > > pointer is on the not masked area... I think I have to dig deeper > > into this. > > ooh because it's a managed window and the wm (e) will not understand > anythng about event shapes - it only handles traditional shapes. so > you need to set the shape to the largest region in which you will > draw pixels (otherwise they might get chopped off/clipped away). e > doesn't know about event shapes so it wont do it for you :( > ok, for this case it isn´t really needed. Shape changes on every zoom step is in any case to much overhead. Now i just change the InputShape at mouse in / out. With an override window it works well. So I finished my composite option for engage. it is not perfect, but if one of the developers would have a look at it I will send it as patch. Regards, Hannes - 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] Ecore_List bugs
Hi there, I notice some "bugs" (or strange behaviour) in the calling policy of the free-callback in Ecore_List: - If you call ecore_list_destroy(), the free-callback will indeed be called on all the elements. - If you call ecore_list_clear(), the free_cb won't be called. - ecore_list_remove() doesn't call the free_cb neither. Ok, there is ecore_list_remove_destroy(), but I just find it really confusing. When you set a free_cb, you usually want it to be called when you remove an element. Another thing, why is there a distinction between Ecore_List and Ecore_DList? It is just to save a pointer per node in the memory? Because, I don't think it is worth it, and it's just confusing imho. Regards, Simon TRENY - 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] does alpha_set work together with shaped_set?
On Sun, 30 Jul 2006 14:29:29 + Hannes Janetzek <[EMAIL PROTECTED]> babbled: > Am Sat, 29 Jul 2006 20:31:10 +0900 > schrieb Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>: > > > On Sat, 29 Jul 2006 10:38:01 + Hannes Janetzek > > <[EMAIL PROTECTED]> babbled: > > > > > Hi, > > > > > > I´m trying to make engage work in a composite environment. > > > Everything works fine so far. The Problem is when I use set_alpha > > > and then set_shaped, the whole window still recieves input events. > > > Does shape_set not work if the window was set up to use alpha > > > channel? If so, have somebody an idea how to work around this? > > > > correct - shaped and alpha are mutually exclusive. you woudl need to > > manually generate a shape mask and set the input event mask (new > > addition to shape extn) to what u want... ie - what u want isnt > > supported in ecore/evas. > > hm, I did it manually but the window still gets focus when the > pointer is on the not masked area... I think I have to dig deeper > into this. ooh because it's a managed window and the wm (e) will not understand anythng about event shapes - it only handles traditional shapes. so you need to set the shape to the largest region in which you will draw pixels (otherwise they might get chopped off/clipped away). e doesn't know about event shapes so it wont do it for you :( > Have you seen any documentation on the ShapeInput option? no- but this is what lets you set the shape mask/rect list for where in a window events are allowed to happen. it allows you to separately determine drawing region and event region. > As far as I understand it it should work just like ShapeBounding > - XShapeCombineMask for ShapeBounding gives only mouse events to the > window in the masked area AND make the not masked area fully > transparent. XShapeCombineMask for ShapeInput should do only the former, > right? > > Or could it be possible that the wm has to know about ShapeInput to set > focus correctly ? yes - it does. if you bypass the wm then it won't matter if the wm knows or not. > > > btw. Is it wanted that in _ecore_evas_x_render() > ecore_x_window_shape_events_select() gets such a complex second > argument if the only thing that it constantly should say is turn on / > turn off ? Also to me it looks like it says turn on twice. turning on twice is harmless - likely just how the code has evolved. the 2nd argument is either 0 or 1 (off or on). > > > Regards, > Hannes > > > > > > > > I tried to move and resize the window to make it smaller when its > > > not in zoomed state, but the results aren´t pleasing.. > > > > > > > > > Regards, > > > Hannes > > > > > > - > > > 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 > -- - 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] does alpha_set work together with shaped_set?
Am Sat, 29 Jul 2006 20:31:10 +0900 schrieb Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>: > On Sat, 29 Jul 2006 10:38:01 + Hannes Janetzek > <[EMAIL PROTECTED]> babbled: > > > Hi, > > > > I´m trying to make engage work in a composite environment. > > Everything works fine so far. The Problem is when I use set_alpha > > and then set_shaped, the whole window still recieves input events. > > Does shape_set not work if the window was set up to use alpha > > channel? If so, have somebody an idea how to work around this? > > correct - shaped and alpha are mutually exclusive. you woudl need to > manually generate a shape mask and set the input event mask (new > addition to shape extn) to what u want... ie - what u want isnt > supported in ecore/evas. hm, I did it manually but the window still gets focus when the pointer is on the not masked area... I think I have to dig deeper into this. Have you seen any documentation on the ShapeInput option? As far as I understand it it should work just like ShapeBounding - XShapeCombineMask for ShapeBounding gives only mouse events to the window in the masked area AND make the not masked area fully transparent. XShapeCombineMask for ShapeInput should do only the former, right? Or could it be possible that the wm has to know about ShapeInput to set focus correctly ? btw. Is it wanted that in _ecore_evas_x_render() ecore_x_window_shape_events_select() gets such a complex second argument if the only thing that it constantly should say is turn on / turn off ? Also to me it looks like it says turn on twice. Regards, Hannes > > > I tried to move and resize the window to make it smaller when its > > not in zoomed state, but the results aren´t pleasing.. > > > > > > Regards, > > Hannes > > > > - > > 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