Re: detection if applet is running
On Saturday, October 29, 2011 12:18:00 Ruurd Pels wrote: On Friday 28 October 2011 12:46:38 Andriy Rysin wrote: Yes, but I can get the keyboard layouts from x11 directly (that's what applets and systray is doing), that'll be more efficient and would not require dbus or even kded daemon running I think it would be preferred to use KDE functionality in this case. Why pass by KDE and Qt and go directly to X11 to do that? That would also mean that you would have to take into account that KDE and Qt run on different platforms that handle keyboard layouts differently. agreed; we're already on our way to Wayland (excuse the pun? :) so this is a key concern. it's much nicer to port centralized code that then extends these changes automatically out to all applications (a prime design idea embodied in so many of our libraries) than to have to hunt down code all over the place and port them. You must abide by separation of concern. In your application your concern is to determine wether a particular applet is running. in this case it probably only needs to use the kded daemon. the applet or tray icon is likely irrelevant. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: detection if applet is running
On 10/29/2011 06:38 AM, Aaron J. Seigo wrote: On Saturday, October 29, 2011 12:18:00 Ruurd Pels wrote: On Friday 28 October 2011 12:46:38 Andriy Rysin wrote: Yes, but I can get the keyboard layouts from x11 directly (that's what applets and systray is doing), that'll be more efficient and would not require dbus or even kded daemon running I think it would be preferred to use KDE functionality in this case. Why pass by KDE and Qt and go directly to X11 to do that? That would also mean that you would have to take into account that KDE and Qt run on different platforms that handle keyboard layouts differently. agreed; we're already on our way to Wayland (excuse the pun? :) so this is a key concern. it's much nicer to port centralized code that then extends these changes automatically out to all applications (a prime design idea embodied in so many of our libraries) than to have to hunt down code all over the place and port them. ideally yes, but if you look at CMakeLists.txt: if(X11_Xkb_FOUND) add_subdirectory( keyboard ) endif(X11_Xkb_FOUND) you could see it would not even compile without xkb. When I was rewriting keyboard layout indicator from scratch for KDE4.5 I initially was thinking to make it abstract from xkb and even from kde (trying to use qt classes only) so that other DEs and window systems could reuse it. Then reality came in :) If you get into details you could see that probably 70% of the keyboard module code is dealing with xkb configuration, quirks and problems. So there's not much of common code you could separate, and even if you do then you'll need to change kcm UI based on which backend features are available as good part of UI is also xkb-related. Of course if somebody wants to try it - you're welcome, but being kxkb maintainer for almost 10 years I haven't seen anybody willing to step up and take over this job (despite several invitations from me in the past) :) I am actually looking forward to Wayland so I can get rid of all this xkb uglyness, but in my opinion (as the author of the code) it's going to be way easier to keep a separate branch of the code, potentially even doing ifdef on the whole keyboard module. Andriy
Re: detection if applet is running
On Thursday, October 27, 2011 23:35:52 Andriy Rysin wrote:
I did a quick research and I see two ways to solve this in
keyboard_layout_widget (embedded component used in lockdlg):
1) link plasma libs and do something like (in pseudo-code)
foreach(containment, new Corona()-containments()) {
foreach(applet, containment-applets()) {
if( applet-pluginName() == ... ) {
// show indicator
}
}
}
that won't work out of the plasma-desktop process, so this isn't an option for
you.
2) make keyboard layout applet exposes some dbus to make it detectable
when running (feels a bit too heavy)
that would be a preferred way ... note, however, that one can have multiple
instances of the same applet. this is why we really recommend and encourage a
separation between visualization and business logic, where the various
visualizations (e.g. applets, tray icons, etc) all share the same business
logic code (e.g. a DataEngine) which can then take care of things like
registering a unique dbus interface.
It felt like there must be a way currently to use dbus on plasma to
query running applets (which would the easiest way to implement what I
need)
nobody has written such a thing, nor do i think it would be as easy as one may
think to use as a widget may be running not in plasma-desktop but in plasma-
netbook, plasma-active, plasma-windowed, etc. and it may be in any number of
running containments.
it is much easier and safer to simply expose a dbus service from your
DataEngine, or whatever the DataEngine uses to get keyboard information from,
than any other approach. it guarantees it works with multiple widgets and
doesn't care which shell the user is running.
in this particular case, why don't you just check the keyboard layout settings
to see if more than one keyboard layout is active? does it matter that there
is or isn't a keyboard layout switcher applet or icon? note that in plasma
active, it is very likely that this functionality will end up integrated into
the virtual keyboard and not reside as a separate applet in the containments
running in plasma-active ...
--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Qt Development Frameworks
signature.asc
Description: This is a digitally signed message part.
Re: detection if applet is running
On 10/28/2011 09:20 AM, Ruurd Pels wrote: On Thursday 27 October 2011 23:35:52 Andriy Rysin wrote: 2) make keyboard layout applet exposes some dbus to make it detectable when running (feels a bit too heavy) Yes. Better. Why does it feel heavy? I'd venture the thought that doing so could expose the keybaord layout applet in such a way that it also could do something usefull (like changing layouts for example :-) ) We already have that dbus API in keyboard kded daemon Adding dbus API to applet just to tell if it is running seems wrong to me it feels like this belongs to parent or container Imagine if to check that app is running in Linux you have to add some code to each app :)
Re: detection if applet is running
On 10/28/2011 02:38 AM, Aaron J. Seigo wrote: On Thursday, October 27, 2011 23:35:52 Andriy Rysin wrote: 2) make keyboard layout applet exposes some dbus to make it detectable when running (feels a bit too heavy) that would be a preferred way ... note, however, that one can have multiple instances of the same applet. this is why we really recommend and encourage a separation between visualization and business logic, where the various visualizations (e.g. applets, tray icons, etc) all share the same business logic code (e.g. a DataEngine) which can then take care of things like registering a unique dbus interface. there's no business logic in the applet, its data engine is x.org it feels to me that adding a data engine just to be able to tell if applet is running is an overkill it is much easier and safer to simply expose a dbus service from your DataEngine, or whatever the DataEngine uses to get keyboard information from, than any other approach. it guarantees it works with multiple widgets and doesn't care which shell the user is running. in this particular case, why don't you just check the keyboard layout settings to see if more than one keyboard layout is active? does it matter that there is or isn't a keyboard layout switcher applet or icon? note that in plasma active, it is very likely that this functionality will end up integrated into the virtual keyboard and not reside as a separate applet in the containments running in plasma-active ... At first I thought it might be a bit inconsistent if user didn't set and indicator to see in the desktop but will see it in the lock dialog, but that's probably an edge case and most of the time user wants some indication of current layout in the lock dialog. That's what I'll do - always show indicator if layout count 1. Thanks for the suggestion, Andriy
Re: detection if applet is running
On Friday, October 28, 2011 11:26:05 Andriy Rysin wrote: We already have that dbus API in keyboard kded daemon could the kded daemon be checked to see if keyboard layouts are available, and if so, show that button in the unlock dialog? does it really need to rely on whether or not there is a system tray icon or plasmoid? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
detection if applet is running
I need to detect if keyboard layout indicator applet is running and show
the keyboard layout button in the screen lock dialog (bug 276692
https://bugs.kde.org/show_bug.cgi?id=276692). Currently it only checks
if indicator option is on which turns on systray icon but user can
bypass that option by just dragging applet on the screen.
I did a quick research and I see two ways to solve this in
keyboard_layout_widget (embedded component used in lockdlg):
1) link plasma libs and do something like (in pseudo-code)
foreach(containment, new Corona()-containments()) {
foreach(applet, containment-applets()) {
if( applet-pluginName() == ... ) {
// show indicator
}
}
}
2) make keyboard layout applet exposes some dbus to make it detectable
when running (feels a bit too heavy)
It felt like there must be a way currently to use dbus on plasma to
query running applets (which would the easiest way to implement what I
need) but could not find anything like that in org.kde.plasma-desktop
I would appreciate any help on this
Thanks
Andriy
