-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 01 May 2004 07:29, Kim Woelders wrote: > Gen Zhang wrote: > > On Friday 30 Apr 2004 19:40, Kim Woelders wrote: > >> Gen Zhang wrote: > >>> Hi all. To relax, I've decided that coding up engage would be a > >>> refreshing change from exam revision. Looking at the (much) > >>> changed code since I last saw it, there's a couple of things that > >>> I would like to implement. One is better handling of windows > >>> opening and closing, the other is better icon management. In > >>> particular, I would like it to be freedesktop.org compliant, so > >>> that engage on its own can be used in any environment, GNOME, KDE > >>> or other compliant desktops. As xcomputerman says on the > >>> homepage, engage has potential to really bring gui writer over to > >>> DR17. So that's my dollars at two cents worth. > >>> > >>> My first goal is to code a replacement for the repeated > >>> od_sync_clients calls. The current form is neither efficient nor > >>> extremely pleasing to the eye -- we've got an average delay of > >>> half a second, an unacceptable latency. Since the last time I > >>> worked on the code, I've gotten to know X and ecore a lot better, > >>> especially the extensible nature of both. I'd like to have the > >>> window management (wm.c) side moved to an event driven way, in > >>> which we monitor top-level window creation/mapping and > >>> destruction/unmapping update the icons as things happen. Also, > >>> and this is probably the harder bit, I'd like to comply with fd.o > >>> with respect to startup notification messages. However, in the > >>> current state, there are a few things that need to be completed > >>> in ecore. Specifically, the boilerplate relating to > >>> ECORE_X_EVENT_CLIENT_MESSAGE. I think I could probably modify > >>> things myself, but I'm a little wary of touching the specifics > >>> inside ecore... (As a side note, ecore_x currently just drops all > >>> x events that does not map cleanly onto one of the handlers; > >>> maybe there should be a default x event that is raised.) > >> > >> Ho! Watch out! Maybe you know exactly what you are doing, then > >> please forgive me. Otherwise, this all sounds to me like you may be > >> heading down a wrong direction. The freedesktop.org hint stuff is > >> designed particularly for client applications like this. You > >> should not have to monitor window state changes but only hints and > >> their changes. > > > > I'm not entirely sure I understand what you mean... but the plan I > > have is to watch for MapNotify/UnmapNotify and Create/Destroy events, > > and filter out thoses which are relevant. > > In my opinion this is *not* the way to do it. It's messy, and this is > one of the WM's core jobs anyway. The WM does this dirty work, and > presents a nice list of the managed clients in the root window property > _NET_CLIENT_LIST. All you have to do is monitor this property, and > selected properties (e.g. _NET_WM_STATE) of the windows in this list, > i.e. process PropertyNotify events on the root window, and on the > windows in the list. This is all really simple. Ah! *Knocks himself on the head* I didn't know that it was possible to monitor specific properties for changes... though logically that makes sense :D Great, that is exactly what is needed. > > > At the same time, implement startup notification as according to > > fd.o. > > I'll have to find out what this startup notification thing is about :) > So far my opinion on this has been something like "Hmm... I don't seem > to be missing anything so why not keep things simple and forget about > it for now.". It's on the fd.o specifications section somewhere. They also provide a reference implementation, but wrapping that to work seems to be more work than simply rewriting it. > > > Perhaps there's a part of the fd.o recommandations that I have missed > > somewhere? Most likely the EWMH stuff... that is just too much > > reading... :p > > The EWMH stuff is particularly relevant for this type of application. > It is more or less what it was designed for! It would be a big mistake > to ignore it. > > >> Also, could you explain what the ECORE_X_EVENT_CLIENT_MESSAGE.is > >> for? > > > > The startup notification, at least, uses these to communicate state > > changes. SN messages are broadcasted to the root window, and it is > > specifically designed so that taskbars, etc can have some sort of > > "application is starting up" indication. > > /Kim > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > enlightenment-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAk1T71N42u6LLBTERAgMaAJ9wIdTYtzWcp0WVYXxG6ulRfvGBZwCfT2dr u2VDu6ZUXU7pN2oXRn1L39I= =TdYa -----END PGP SIGNATURE----- ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id�66&op=click _______________________________________________ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
