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

List:       kde-devel
Subject:    Re: Thoughts on the systray II.
From:       LiuCougar <liucougar () gmail ! com>
Date:       2005-04-16 0:54:47
Message-ID: 9558067805041517543d38d34d () mail ! gmail ! com
[Download RAW message or body]

On 4/15/05, Aaron Seigo <aseigo@kde.org> wrote:
> On April 15, 2005 21:40, LiuCougar wrote:
> > > > I really do not like QXEmbed class: it requires a lot of hack to work
> > > > as expected; but I have to use it in my app to implement the applet I
> > > > mentioned above...
> > >
> > > yep. i too dislike XEmbed for these tasks. which is the whole reason for
> > > the push away from it here ;)
> >
> > Can I use the new mechanism in kicker applet? I'd like to be able to
> > replace QXEmbed class with a more friendly one.
> 
> it should be possible to add a flag to this that says, "make this an applet"
> 
> 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.

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
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.
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?

> (just want to confirm that this is a valid use case before seriously
> considering adding support for it =)
Thanks for consideration.

Regards
Cougar

-- 
"People's characters are strengthened through struggle against
difficulties; they are weakened by comfort."
- Old Chinese adage
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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