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

List:       kde-core-devel
Subject:    Re: new kde project
From:       Antonio Larrosa =?utf-8?q?Jim=C3=A9nez?= <larrosa () kde ! org>
Date:       2003-06-06 20:06:09
[Download RAW message or body]

El Friday 06 June 2003 17:57, Gav Wood escribió:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > Easy, show two (or N) icons in the system tray, one for each remote.
>
> it might get messy with N=4 remote controls, conversely when there are

whoever uses 4 remote controls is only looking for a mess :-)

> no remote controls configured but irkick is still running, an icon

you could handle N==0 as a special case.

> visible would still be useful. a user may have only one remote control
> with modes (me!) and thus may wish for only one status icon for an
> arbitrary remote control,

I see. That's a problem yes.

> so the solution is perhaps not as immediately 
> obvious as it sounds. however, i'll look into doing some sort of a
> usable solution....

Just as an idea, maybe you could add a checkbox to each remote saying 
something like "Show Mode State in System Tray", which will use the first 
irkick icon for the first remote and add additional irkick icons if the 
checkbox is marked for more than one remote.

> > That way, they're added as "Strings" type, so they only work if the
> > dcop call just accepts string parameters.
> > I'm afraid you'll have to parse the list of arguments from the method
> > name and convert that "value" QString to something else first.
>
> the addaction dialog has recently been changed to use different input
> widgets for different argument types, which should fix this problem. i
> haven't yet gotten round to changing the editaction dialog, but
> hopefully that'll fix this particular problem.

Ah, yes. I used the new version when adding the action, but after that I 
edited it, which was the reason it was broken.

> but from what i remember the problem was demonstrable just with a dcop
> call of three QString arguments, who were never anything but QStrings
> and who never touched the config file, were changed into QVariants or
> anything. see line 104 and 113 of the same file for the two chucks of
> code that *should* afaik do the same thing but that don't.

Sorry, I tried to understand that code before, but it seems to me it's only 
used when npApp != QString::null, that is, after calling stealNextPress . 
What's stealNextPress exactly used for? I would say I'm not using that 
"feature", am I? At least I couldn't find any code calling that method.

Greetings,

--
Antonio Larrosa Jimenez
KDE developer - larrosa@kde.org
http://developer.kde.org/~larrosa/
C programs should be indented six feet downward and covered with 
dirt--BP.Hought

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