On Tue, 27 May 2003 18:00:16 -0500 Stephen Dranger <[EMAIL PROTECTED]> babbled:
> Hello, > I've noticed the lengthy conversation regarding adding OS X like > performance to the existing iconbar. Myself and Ziba Scott are currently > working on the ecore_x framework that you need to keep track of things > like this. Basically these calls set up framework that keeps track of > all currently running tasks on the display. The taskbar program, i.e. > the code you want to write for the iconbar, will then ask the framework > to run a callback for it when say, a CreateNotify or DestroyNotify is > called. By setting things up like this, people can use whichever task > management method that they want - and it makes it much easier (as I'm > sure you know) to write a task manager. > > The code is not yet completed, but we are working on it. So far we have > window creates and destroys changing a list of tasks visible on the root > window. The program also searches for all tasks when it starts up. > Currently we are working on the problem of callbacks. Our library will > accept callbacks as arguments and then call them whenever an important > event happens: create, destroy, minimize, etc. This allows the taskbar > to do cool stuff or update its list of tasks when these events happen. > The problem lies in the creates and destroys. Currently the taskbar > writer will listen (using one of our convenience functions) to the root > window property to find out when a window has been created or destroyed. > This forces the taskbar creator to maintain a list of windows and then > write a function that checks if the root window has changed because of a > create or destroy, then checks to see which window it is. Is this too > much to ask a taskbar designer to do? We are aiming for the ability for > a programmer to very simply make their own taskbar. > > It will probably be finished soon, but only for the old ecore libraries, > as the new ecore_x libraries are rapidly changing (not completed, being > ported to XCB, etc). When both our code and the new ecore are finished, > we will port our code to the new ecore and it will be complete. Cool - BTW - you want to talk to Cobra - He's working on "ecore_ps" - basically the ability to tracka process Id, map it to a window id (or more than one) and monitor cpu etc. usage of those processes. basically very much linked with what you are doing. you're challenge is to 1. map PID you get back from fork() to a window on the screen - you'll NEED to do this (name +class or title isn't enough). ehack does this (see the e17 src tree :) ) it's an ld_preload and e17 has code there to exec things with the ld_preload. this lets you map a pid to a window - a VERY important thing. from there its just a matter of monitoring window maps, unmaps, destroys, creates, property changes etc. :) > --Stephen Dranger > Ziba Scott > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your application fit in a > relational database is painful, don't do it! Check out ObjectStore. > Now part of Progress Software. http://www.objectstore.net/sourceforge > _______________________________________________ > enlightenment-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] [EMAIL PROTECTED] Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9698 8615 ------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
