"Carsten Haitzler (The Rasterman)" wrote: > > > 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. :) > >
I've been meaning to post some detail about ecore_ps / etop / whatever we call it :) So here's a quick rundown of what it does so far, and stuff left to do. First, there's a patch tarball at http://kevb.net/files/etop_alpha_01.tgz against head e17 and ebits. It'll do what you see in http://kevb.net/files/2003-05-14-212316_1280x1024_scrot.jpg , which is monitor cpu load for a windowed app and all it's children. The little green/yellow/red indicator in the upper left of a window is tied to load on a 1-2 second interval for the child apps. At the moment, I consider this alpha quality, so use it with caution. Also, it's Linux specific, because it parses /proc in the Linux format. I'm looking for some help with other OS's, so if you have a favorite, and know what the /proc format looks like, or can get me/point me at docs, send me some mail. Note that copying GNU ps/top is frowned upon, since they are GPL and E is not. :) (I've written the current Linux version without looking at those sources, although looking may be ok as some have pointed out...) Warnings: - Something leaks. I thought it would be the process tree code, although I was fairly thorough with it. It may be the window border regen code. I haven't spent any time on the window border side checking it. - There seems to be a timer startup issue sometimes. Once in a while when I start e17 I don't see the load info I expect in the indicators. Switching to console shows timer events firing much quicker than the 1 second interval. I haven't investigated this. Restarting E once or twice resolves this (it's only a startup issue from what I can tell.) - The window border update code in e17 isn't optimal. If you have a lot of apps changing load frequently, you'll bring e17 to it's knees. That's the price we pay for large shaped borders :( - I've had a report that load information doesn't work after some extended period of time. I can't reproduce that here, and have no further info on the problem. This may be an artifact of the mem leak though. I've seen e17 grow from 11M to 40-50M in 24 hours (using 'top' numbers.) This isn't normal behavior, so something is leaking memory. For anyone interested in trying this on a non-Linux platform, the core process accounting code was built as a command line app for initial testing. I can make it available, or modify a version against docs you point me at, for testing. Let me know. :) Good stuff: - It works well. There isn't a lot of load doing 1 second updates, although slower cpu's might see a hit. - The tarball contains patches, a README, and the theme files you see in the screen shot. Everything you need is there. Plus directions on how to mod a theme to work with the newly enabled ebit property "LOAD". - http://kevb.net/files/2003-05-11-173831_1280x1024_scrot.jpg is the default e theme with load support. Ever wonder what the little gray box was for? :) I don't have this up for download, so just yell if anyone wants it. todo: All kinds of stuff. Support non-Linux platforms. Hash the process tree so it does fast lookup rather than linear search. Make an ecore module out of it. Support info other than cpu usage (and decide what kind of differential cpu info to export, for that matter.) Add the ability to report cpu usage for app and children, but stop at the next windowed app (not that hard, just needs a stop list in the search routine.) And more :) -- Kevin ------------------------------------------------------- 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
