On Saturday 16 of April 2005 02:54, LiuCougar wrote: > On 4/15/05, Aaron Seigo 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 <<