new kde project

[Antonio Larrosa Jiménez]

El Friday 06 June 2003 14:28, Gav Wood escribió:
> > Btw, given that I'm going to stop completely the development of
> > finglonger, I hope you can implement a few things that I had in mind.
> > First, it would be nice if you could add a way to configure an icon
> > for each mode, that way, you could make the kicker icon of irkick
> > change showing the current mode (I would do it by drawing a
> > semitransparent version of the "mode icon" over irkick's icon, and
> > possibly reducing it a few pixels and putting it on the right-bottom
> > corner of irkick's icon).
>
> the good news is that in fact i had this in mind too :-) so when i

cool :)

> designed it, i implemented modes in such a way to allow properties to be
> set like an icon without any significant changes to the code.
>
> the bad news is that on later reflection, this idea only works if the
> system has one remote control, since there's only one icon in the system
> tray to change. i, for instance, have two, and i'm unsure how to
> represent each of their modes with the current interface.

Easy, show two (or N) icons in the system tray, one for each remote.

> if this difficulty can be overcome in an elegant way i'll do the
> necessary code asap.

Thanks :)
Btw, it would be nice if you could add a menu entry to the systray icon to 
easily access the kcontrol module to configure it.

>
> > Also, it would be nice if you could had a look at the way you handle
> > the dcop arguments. I'm trying to add an action that calls kicker
> > Mixer0 increaseVolume(0) but it doesn't work (Mixer0 is there when you
> > have kmix's applet in kicker, and the 0 device id is the one for the
> > master volume).
>
> right, this has been on the TODO list for quite some time now, and to be
> quite honest i have _no_idea_ how to fix it. it's either a bug in dcop,
> a bug in kmix or i am doing something highly stupid, since making an rpc
> using one method works, and yet the - supposedly equivalent - rpc using
> another method doesn't. unfortunately, to make matters worse, it only
> seems to happen on a subset of applications kmix being one it doesn't
> work on, and only when arguments are used.

Hey, I had a look at the code and that was easy too :)
You're using this to insert the parameters to your arguments list of 
variants:

void EditAction::slotInputArgument(const QString &value)
{
    arguments[theArguments->currentItem()] = value;
}

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.

As a way to prove that it's really that problem, you can just modify the 
config file of irkick:

Binding1Argument0=0
Binding1ArgumentType0=3
Binding1Arguments=1
Binding1Method=void increaseVolume(int deviceidx)
Binding1Object=Mixer0
Binding1Program=kicker

That is, the type of the first argument is 3 (QVariant::String, which is 
what you assigned the QVariant to). Just changing it to 16 (QVariant::Int) 
makes it work ok.

> the code is in kdenonbeta/kdelirc/irkick/irkick.cpp for those
> interested.

I must say that sentence made me have a look :)

Greetings,

--
Antonio Larrosa Jimenez
KDE developer - larrosa at kde.org
http://developer.kde.org/~larrosa/
It's not logical to think that some things are unmovable -- MrSpock.