[E-devel] (e16) iconbox/systray enable/disable options ?
Hello,
is there a legal way to disable e16 iconbox(es) ? Since I haven't found it,
I've implemented my own :-). I didn't test it too much, and I'm not sure
this is the Right Thing which needs to be included in e16. This is just
a simple solution which works for me.
Dmitry
diff -ur e16-0.16.8.4/src/container.c e16-0.16.8.4.devel/src/container.c
--- e16-0.16.8.4/src/container.c2006-10-15 21:51:10.0 +0400
+++ e16-0.16.8.4.devel/src/container.c 2006-11-15 21:30:53.0 +0300
@@ -32,6 +32,12 @@
#include iclass.h
#include menus.h
+static struct
+{
+char iconbox_enable;
+char systray_enable;
+} Conf_containers;
+
extern const ContainerOps IconboxOps;
extern const ContainerOps SystrayOps;
@@ -65,8 +71,16 @@
static Container *
ContainerCreate(const char *name)
{
+ char type;
Container *ct;
+ type = (name !strcmp(name, _ST_)) ?
+ IB_TYPE_SYSTRAY : IB_TYPE_ICONBOX;
+ if ((type == IB_TYPE_SYSTRAY) !Conf_containers.systray_enable)
+ return NULL;
+ if ((type == IB_TYPE_ICONBOX) !Conf_containers.iconbox_enable)
+ return NULL;
+
if (ContainerFind(name))
return NULL;
@@ -79,8 +93,7 @@
ecore_list_append(container_list, ct);
ct-name = Estrdup(name);
- ct-type = (name !strcmp(name, _ST_)) ?
- IB_TYPE_SYSTRAY : IB_TYPE_ICONBOX;
+ ct-type = type;
ct-orientation = 0;
ct-scrollbar_side = 1;
ct-arrow_side = 1;
@@ -2007,22 +2020,21 @@
};
#define N_IPC_FUNCS (sizeof(ContainersIpcArray)/sizeof(IpcItem))
-#if 0
/*
* Configuration items
*/
static const CfgItem ContainersCfgItems[] = {
- CFG_ITEM_BOOL(Conf.iconboxes, enable, 1),
+ CFG_ITEM_BOOL(Conf_containers, iconbox_enable, 1),
+ CFG_ITEM_BOOL(Conf_containers, systray_enable, 0),
};
#define N_CFG_ITEMS (sizeof(ContainersCfgItems)/sizeof(CfgItem))
-#endif
/*
* Module descriptor
*/
-const EModule ModIconboxes = {
- iconboxes, ibox,
+const EModule ModContainers = {
+ containers, containers,
ContainersSighan,
{N_IPC_FUNCS, ContainersIpcArray},
- {0, NULL}
+ {N_CFG_ITEMS, ContainersCfgItems}
};
diff -ur e16-0.16.8.4/src/mod-misc.c e16-0.16.8.4.devel/src/mod-misc.c
--- e16-0.16.8.4/src/mod-misc.c 2006-10-15 21:51:10.0 +0400
+++ e16-0.16.8.4.devel/src/mod-misc.c 2006-11-15 21:31:15.0 +0300
@@ -45,7 +45,7 @@
extern const EModule ModFocus;
extern const EModule ModGroups;
extern const EModule ModImageclass;
-extern const EModule ModIconboxes;
+extern const EModule ModContainers;
extern const EModule ModLocale;
extern const EModule ModMenus;
extern const EModule ModMisc;
@@ -75,7 +75,7 @@
ModEffects,
ModFocus,
ModGroups,
- ModIconboxes,
+ ModContainers,
ModImageclass,
ModLocale,
ModMenus,
-
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.phpp=sourceforgeCID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] xmms causes e17 to freeze
Starting xmms on current CVS build causes e17 to completely freeze. Onefang thinks it may be due to the new evas threading code (this is a multi proc / dual core box). BT follows: [Switching to Thread -1216890192 (LWP 17018)] 0xbfffe410 in __kernel_vsyscall () #0 0xbfffe410 in __kernel_vsyscall () #1 0xb7c42ece in __lll_mutex_lock_wait () from /lib/i686/libpthread.so.0 #2 0xb7c411d0 in pthread_barrier_wait () from /lib/i686/libpthread.so.0 #3 0xb7ce6807 in evas_common_pipe_begin (im=0x8d19080) at evas_pipe.c:183 #4 0xb7418030 in eng_output_redraws_next_update_push (data=0x89b6e48, surface=0x8d19080, x=0, y=0, w=168, h=32) at evas_engine.c:359 #5 0xb7c9fd16 in evas_render_updates_internal (e=0x8aa7ab8, make_updates=1 '\001') at evas_render.c:358 #6 0xb7c9ffe7 in evas_render_updates (e=0x8aa7ab8) at evas_render.c:439 #7 0xb7f8bda1 in _ecore_evas_x_render () from /usr/lib/libecore_evas.so.1 #8 0xb7f8e28a in _ecore_evas_x_idle_enter () from /usr/lib/libecore_evas.so.1 #9 0xb7f149c1 in _ecore_idle_enterer_call () from /usr/lib/libecore.so.1 #10 0xb7f17aaf in _ecore_main_loop_iterate_internal () from /usr/lib/libecore.so.1 #11 0xb7f16f9b in ecore_main_loop_begin () from /usr/lib/libecore.so.1 #12 0x080674b3 in main (argc=1, argv=0xbfe7f4a4) at e_main.c:823 - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] xmms causes e17 to freeze
On Fri, 17 Nov 2006 18:18:09 -0500 Ryan Little [EMAIL PROTECTED] babbled: Starting xmms on current CVS build causes e17 to completely freeze. Onefang thinks it may be due to the new evas threading code (this is a multi proc / dual core box). can someone put a second set of eyes on the threading code - i am staring at it and it seems entirely solid. evas_pipe.c is the only core thread code and evas_font_draw.c has 1 mutex lock (LKL() and LKU() macros on the font) and evas_font_load.c (the only place such objects are created) inits and destroys these. interestingly the font mutexes are not the issue. the issue i myself just saw this morning too - the main process thread and the 2 slave threads are ALL blocking on pthread_barrier_wait () all waiting on eachother. this doesn't make any sense if you look at the pthread code (i have 1 barriers - barrier 0 and 1. barrier 0 is used for starting up the slave threads and 1 is used to sync up the end of the slave threads and the main process thread. here is how it works (it's hellishly simple!) 1. in main process thread before any slave threads do anything build pipeline. no locking. no concurrency - should be no issues. this pipelne is read-only so it needs no locks later. 2. once pipeline is complete and evas needs the results of the rendering it calls evas_common_pipe_begin() which if no slave threads exist, will create them, then have them sitting in an initially blocked state waiting on barrier 0. if the threads have been created already they will be in this blocking on barrier 0 state anyway so this create it not done. 3. for each slave thread (thread_num) the main thread quickly creates a small thread-specific context (allocates it) and fills it with the region the thread has to render, then sets the thread info pointer (which the thread was handed on start so it knows about its own specific context). 4. the main thread now sets up the sync thread end barrier (barrier 1) and then waits on barrier 0 - this wait will trigger the slaves to begin working (barriers are really convenient sync mechanisms that basically block until N threads are waiting on the barrier - then they unblock). this means every thread waiting unblocks and so the slaves go on and run and the main process thread runs. 5. the way the code is currently the main process instantly then calls the evas_common_pipe_flush() call which basically means any pending rendering - finish it now and wait. this means it first re-inits barrier 0, then waits on barrier 1 - once all slave threads are done they also wait on barrier 1. when all slaves and parent are waiting (both slaves done and parent has been waiting) then the barrier unblocks - main thread now continues running and slaves start blocking on barrier 0 again (which is set up and ready) basically waiting for evas's parent main thread to set up a new pipeline and unblock the workers to do their stuff. now here is the problem - this is INCREDIBLY simple. there is no complex locking (the only locking is for fonts and that is also incredibly simple). the problem is there is a deadlock on the barrier sync points and i am looking at them and cannot for the life of me see the problem. either it is incredibly subtle and hiding - or it's so obvious and glaring i somehow have skipped it and am just assuming too much. anyone else have ideas? (evas/src/lib/engines/common is where these files are. macros in evas/src/lib/include/evas_common.h) BT follows: [Switching to Thread -1216890192 (LWP 17018)] 0xbfffe410 in __kernel_vsyscall () #0 0xbfffe410 in __kernel_vsyscall () #1 0xb7c42ece in __lll_mutex_lock_wait () from /lib/i686/libpthread.so.0 #2 0xb7c411d0 in pthread_barrier_wait () from /lib/i686/libpthread.so.0 #3 0xb7ce6807 in evas_common_pipe_begin (im=0x8d19080) at evas_pipe.c:183 #4 0xb7418030 in eng_output_redraws_next_update_push (data=0x89b6e48, surface=0x8d19080, x=0, y=0, w=168, h=32) at evas_engine.c:359 #5 0xb7c9fd16 in evas_render_updates_internal (e=0x8aa7ab8, make_updates=1 '\001') at evas_render.c:358 #6 0xb7c9ffe7 in evas_render_updates (e=0x8aa7ab8) at evas_render.c:439 #7 0xb7f8bda1 in _ecore_evas_x_render () from /usr/lib/libecore_evas.so.1 #8 0xb7f8e28a in _ecore_evas_x_idle_enter () from /usr/lib/libecore_evas.so.1 #9 0xb7f149c1 in _ecore_idle_enterer_call () from /usr/lib/libecore.so.1 #10 0xb7f17aaf in _ecore_main_loop_iterate_internal () from /usr/lib/libecore.so.1 #11 0xb7f16f9b in ecore_main_loop_begin () from /usr/lib/libecore.so.1 #12 0x080674b3 in main (argc=1, argv=0xbfe7f4a4) at e_main.c:823 - 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.phpp=sourceforgeCID=DEVDEV
Re: [E-devel] (e16) iconbox/systray enable/disable options ?
Dmitry Antipov wrote: Hello, is there a legal way to disable e16 iconbox(es) ? Since I haven't found it, I've implemented my own :-). I didn't test it too much, and I'm not sure this is the Right Thing which needs to be included in e16. This is just a simple solution which works for me. If you close an iconbox/systray (right mouse or winops menu) it should not reappear in a later session, and new iconboxes/systray can be created via the middle mouse-Desktop menu. Doesn't that cover your needs ? /Kim - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
