"Carsten Haitzler (The Rasterman)" wrote:
> On Tue, 27 May 2003 18:00:16 -0500 Stephen Dranger <stdrange@...>
> > 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...)
- 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
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
shows timer events firing much quicker than the 1 second interval. I
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
pay for large shaped borders :(
- I've had a report that load information doesn't work after some
of time. I can't reproduce that here, and have no further info on
This may be an artifact of the mem leak though. I've seen e17 grow
to 40-50M in 24 hours (using 'top' numbers.) This isn't normal
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. :)
- It works well. There isn't a lot of load doing 1 second updates,
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
work with the newly enabled ebit property "LOAD".
- http://kevb.net/files/2003-05-11-173831_1280x1024_scrot.jpg is the
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.
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