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.
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.".
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
