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

List:       kde-devel
Subject:    Re: Thoughts on the systray II.
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2005-04-18 14:30:41
Message-ID: 200504181630.41467.l.lunak () suse ! cz
[Download RAW message or body]

On Saturday 16 of April 2005 02:54, LiuCougar wrote:
> On 4/15/05, Aaron Seigo <aseigo@kde.org> wrote:
> > but i have to ask... why do you need the applet in addition to the
> > systray icon in the first place?
>
> The scenoria is this:
> What I am working on is a program called skim ( http://www.scim-im.org
> is the main project homepage ). Basically, it is an input method which
> is required for users from China, Japan, Korea etc to input their
> native languages.
>
> Let's first look at what the input methods under M$ windows can do:
> Before windows XP, there is a dedicated system tray icon to indicate
> current input method activated, and the toolbar of input method is
> floating; while under Windows XP (and Mac OS X), in addition to the
> floating mode, the input method main toolbar can be docked into the
> panel, not in the system tray itself, but in a seperate area. Thus,
> I'd like skim to be configurable to either one of these two mode.

 My mail with the patches was an attempt to actually get rid of the systray 
completely. Systray here meaning "the UI feature that happens to be a random 
mess where everybody puts things they don't know where to put them 
elsewhere". According to this plan the non-XP way with the systray icon would 
be wrong and you should go only with the applet. The question of course is if 
the plan makes it.

>
> The problem with panel applet is: this is the only way I can image to
> make a top-level window (the main toolbar) dockable into the kicker.
> What skim does is: if required, it will communicate with the applet,
> and ask it to dock the main window (main toolbar) to itself.
>
> > and why are you using QXEmbed for the applet in the first place? to avoid
> > using DCOP to communicate with it, or...?
>
> After looking into the code of system tray (in kwin), I noticed that

 Kicker, not KWin, I presume.

> each applet is a shared library which runs in the kicker process, not
> in skim itself, so I have to use QXEmbed. I can not make the
> mainwindow into an applet, because it needs to co-operate with the
> other part of skim tightly.

 Why not simply having everything in the applet? You wouldn't need to do any 
communication then at all.

> In fact, skim makes use of dcop calls to communicate with the kicker
> applet. Could you tell me is there any other alternative approaches
> for this special situation?

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak@suse.cz , l.lunak@kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]