[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: visibility?
From:       Christopher Molnar <molnarc () nebsllc ! com>
Date:       2000-03-09 17:20:46
[Download RAW message or body]

Rik,

Thanks for the breakdown of what needs to be done, but 
I am afraid this goes way past my comfort level with my 
skills (main reason). It also came as a sort of shock 
to me this week that the company I work for may be sold 
and I may be competing with 11,000 others for work in 
my area. So the job search is on.

Because of these reasons I need to pass on this job, I 
just don't think I will have the time to give it the 
attention it deservers, and it would be unfair to 
pretend otherwise. (just remembered, I still need to 
fix the nntp slave as well).

Would you mind if I added it to the "Jobs-open" web 
page? Maybe there are some other takers.

Thanks,
Chris


Quoting Rik Hemsley <rik@kde.org>:

> #if Christopher Molnar
> > OK, if you have some patience give me an overview 
of what needs to happen
> > and I'll ask questions as needed. (A pointer to the 
right area of code
> > would be nice as well).
>
> Here we go...
>
> I'm sending this to kde-devel so that people can see 
that the
> app-starting indicator is on its way and simply needs 
some code
> writing.
>
> Brief explanation:
>
>         When KApplication::setTopWidget() is called, 
various
>         properties are set on the toplevel widget 
(window). One of
>         these is the WM_COMMAND property. This has 
two parts, res_name
>         and res_class. res_name is set from argv[0] 
(so we know the
>         name of the binary) and res_class is simply 
set to "toplevel" -
>         we don't need that.
>
>         (BTW, thanks to whomever cleaned up that 
code :)
>
>         Now, when we launch an app, we want to pass 
the name of
>         the binary to kicker. kicker will notify the 
user that
>         the app is starting by _immediately_ creating 
a taskbar
>         entry for that app.
>
>         When the application sets a toplevel widget 
(window),
>         kwin will pass the name of the app (found in
>         WM_COMMAND -> res_name) to kicker. kicker 
will then
>         replace the 'app starting' indication with a 
real taskbar
>         entry.
>
>         kicker already creates taskbar entries when 
an app is
>         mapped. So all that needs to be done there is 
to remove
>         the 'app starting' indicator.
>
>         The 'app starting' indicator, as I said 
earlier, should
>         be a taskbar entry. This is logical, it's 
what the user
>         expects. The thing that isn't what they 
expect is that
>         there is no accompanying window. For this 
reason the
>         taskbar entry should be marked in some way to 
make this
>         clear. I suggest the 'white gauze' effect as 
seen in Window
>         Maker and over toolbar buttons. Feel free to 
do spinning
>         cogs or something else if you wish, but 
remember that
>         animations eat bandwidth when you're running 
X remotely,
>         so this would not be the best solution.
>
> Step 1: Find out how applications are being launched.
>
>         KDE applications should never launch apps 
themselves with
>         exec() or similar, they should be using the 
support in kdelibs.
>
>         You need to know whether there is more than 
one mechanism
>         that is being used. When I did this before I 
just assumed
>         that all apps used krun (kio/krun.*) to 
launch. This might
>         not be the case, so that simply needs 
checking.
>
>         You may also want to keep track of the pids 
of apps you
>         exec and notice when they die. More on this 
in a bit...
>
> Step 2: Edit kicker's taskbar code.
>
>         You need to receive DCOP signals called:
>           'clientStarted(QString, int)',
>           'clientMapped(QString)' and
>           'clientDied(int)'
>
>         The first (clientStarted()) will be sent by 
KRun when it
>         calls exec().
>
>         You should create an 'app starting' taskbar 
entry here,
>         using the name you are passed in the first 
parameter.
>
>         The second parameter is the pid of the 
process that was
>         started. You must remember this so that when 
the process
>         exits you can remove the taskbar entry.
>
>         You may say, "Well, I can remove the entry 
when the window
>         goes away" - see the discussion on buggy 
clients later
>         for the reasons why.
>
>         The second (clientMapped()) will be sent by 
kwin whenever
>         it sees a new window.
>
> Step 3: Edit krun (and anywhere else you find code 
that launches apps).
>
>         You need to emit a signal via DCOP, that is 
directed to kicker.
>
>         Something like this...
>
>         dcopClient->send(
>           "kicker",
>           "taskbar/something",
>           "clientStarted(QString)",
>           nameOfAppBinary,
>           pid
>         );
>
>         You then need to make sure you are notified 
when the process
>         exits, so don't lose that pid.
>
> Step 4: Edit kwin
>
>         Again you need to emit a signal via DCOP, 
that is directed to
> kicker.
>
>         Something like this...
>
>         dcopClient->send(
>           "kicker",
>           "taskbar/something",
>           "clientMapped(QString)",
>           WM_CLASS -> res_name
>         );
>
>         WM_CLASS is set in kapp.cpp and contains argv
[0] and "toplevel".
>
>         Within WM_CLASS, res_name contains argv[0] 
and res_class
>         contains "toplevel".
>
> Final thoughts...
>
> You may wonder how this will work with 'legacy' apps. 
Well the fact is,
> most X11 apps already set WM_COMMAND. Only very few 
apps do not set
> this property. Examples include Tk apps (though 
that's generally because
> the author didn't do it) and KDE 1 apps.
>
> So if some apps don't set WM_COMMAND, how do we know 
when they have
> mapped ? The answer is, we don't. I can't see a way 
to be sure, and
> if we can't be sure, we shouldn't mess, as we'll just 
get into
> trouble.
>
> How to fix this ? You can't, completely.
>
> You can, however, take notes from Window Maker.
>
> krun can be notified when the binary it has exec()'ed 
has died.
> When this happens, it send a clientDied(pid) DCOP 
signal to kicker.
> If kicker finds a taskbar entry with matching 
associated pid, it
> simply removes it.
>
> The upshot of all of this is that a buggy client will 
create a
> taskbar entry which looks permanently like it is 
starting up.
>
> We can remedy the situation further by using .desktop 
files to our
> advantage. Because we ship KDE with a set of .desktop 
files for legacy
> apps, we can identify some common legacy apps that 
are buggy (do not
> set WM_COMMAND) and mention that fact in 
their .desktop file.
>
> If krun is 'running a .desktop file' (I believe it 
does this ?) then
> it can simply avoid sending the clientStarted() 
signal to kicker.
> I think this might be a good solution. Any other 
suggestions are
> welcome.
>
> It's also possible that we kicker could get the info 
from the related
> .desktop file itself. I think it's ksycoca it would 
need to chat
> with.
>
> Any questions ? We can take this off-list now if 
there are no issues
> that everyone needs to hear about.
>
> Rik
>
> --
> Stop waiting for Godot.
> 



Christopher Molnar
Red Hat Certified Engineer
Aetna, Inc.
New England Business Services, LLC
Hartford, CT USA
860-636-5588/860-956-9408
mailto:molnarc@nebsllc.com
mailto:molnarc@aetna.com

[prev in list] [next in list] [prev in thread] [next in thread]