From: PCMan <pcm...@gm...> - 2013-08-09 17:35:03
|
On Sat, Aug 10, 2013 at 1:11 AM, .. ink .. <mho...@gm...> wrote: > >> The panel API does not provide a high-level functions like "change icon", >> "show pop-up message". Our API is more low-level. The plugin creates a >> widget (in your case, I suggest QToolButton) and returns a pointer to it >> through the function >> QWidget* IRazorPanelPlugin::widget. >> > Is this by design to let plugins have full control over their UI or the high > level API are simply not implemented yet? > >> >> In plugin you can work with this widget as in a regular Qt application, >> change icon, connect to slots and etc. >> Imho TeaTime example will help you - >> https://github.com/Razor-qt/razor-qt/blob/master/razorqt-panel/plugin-teatime/teatimeplugin.cpp >> > > Thanks for the link,its very informative. > >>> 4. Any plans to support KDE's kstatusnotifyitem API[2]? >> >> Long time ago I suggested to implement appindicator, bu it was >> Ubuntu-specific and we decided don't to do that. If the situation has >> changed now, I think we can implement it. The XEmbed is terrible. >> >> Who knows what with systray in Wayland/Mir? >> >> > As far as i know KDE's kstatusnotifyitem and unity's appindicator > implements the same underlying d-bus based API. Supporting unity appindicator is possible. We did it in lxde in the past. Unity provides a lib for it, so technically we can create a panel plugin for appindicator. But I don't think its priority is lower than other more important tasks ATM. > razor-qt/lxde could come up with its own API that supports the protocol and > KDE's or unity's tray applications would just work in razor-qt's panel.Its a > shame gnome-shell went their own way.Implementing the protocol will give the > plug in architecture a say on how applet's are presented to the user and > this will give a pleasant applet consistency.I believe is one of the core > reasons of moving away from XEmbed. > > Also,any plans to have kwallet/gnome-keyring type of functionality? Yes, it's in my long long TODO list. Actually before the merge of razor and lxde happens, I studies this a bit. > I googled a bit and nobody else seem to be providing the feature. Yes, that's true. > It would have been nice to have a DE independent,self contained,pure C based > small library that offer the functionality project could easily use.In other > words,a sqlite.c type source file that gives the functionality. Historically, KWallet and gnome-keyring developers discussed on xdg mailing list to see if they can use a common dbus interface so they can be compatible. The effort was in vain and the proposal failed. No further improvement in this area since then. Regarding to the C lib, libgcr provided by gnome actually has the potential to be that kind of lib. It separated gtk+ and non-GUI parts deliberately in their source tree. So technically it's possible to port it to Qt as well. The problem is, the UI part is very gtk+ centric and that part is large. Porting is possible, but this will take some time so cannot be done now. Are you interested in helping this area? |
From: PCMan <pcm...@gm...> - 2013-08-10 03:56:59
|
On Sat, Aug 10, 2013 at 4:41 AM, .. ink .. <mho...@gm...> wrote: > On Fri, Aug 9, 2013 at 3:04 PM, .. ink .. <mho...@gm...> wrote: >>> Are you interested in helping this area? >>> >> >> i will look into into >> > Me and my naive self thing we can crack this one. > I have though about it and i will attempt to do the following. > > 1. Use gcrypt as a back end to do encryption/decryption,openssl can be used > instead if it is preferred. > 2. Use CBC mode of AES as i am more familiar with it > 3. Create an independent simple C library to manage the wallet. > 4. Create a Qt/C++ interface to the library. > 5. Create a Qt/C++ GUI front end to the library at 4 to manage keys. > > Will come back when i have something to show. > > Anybody has an opinion on what to call the project? Name: lxqt-keyring Implementation detail: I studied the source code of gnome-keyring and libgcr today. Actaully, it's only gcr-ui and gcr that requires gtk+. The gnome developers carefully separated UI and non-UI parts. The non-UI parts gcr-base and gck are not linked to gtk+. Gcr-ui is a lib used to develop other keyring associated programs. Gnome-keyring itself does not rely on it that much. So, I think porting gnome-keyring to Qt is a faster approach. Besides, gnome-keyring is well-tested and is a proven solution. Since its developers separated UI and non-UI parts already, we can use it. I'm interested in doing this, too. |
From: .. i. .. <mho...@gm...> - 2013-08-10 04:19:06
|
> Name: lxqt-keyring > > Implementation detail: > I studied the source code of gnome-keyring and libgcr today. > Actaully, it's only gcr-ui and gcr that requires gtk+. > The gnome developers carefully separated UI and non-UI parts. > The non-UI parts gcr-base and gck are not linked to gtk+. > Gcr-ui is a lib used to develop other keyring associated programs. > Gnome-keyring itself does not rely on it that much. > So, I think porting gnome-keyring to Qt is a faster approach. > Besides, gnome-keyring is well-tested and is a proven solution. > Since its developers separated UI and non-UI parts already, we can use it. > I'm interested in doing this, too. > > can you point to the repository with gcr sources? i looked but couldnt find them. I already set up a repository[1]. creation of a wallet and testing if a wallet key is correct works.I will just continue for my own amusement if you guys go with gnome-keyring. isnt gnome-keyring deprecated?[2],i dont think its wise basing future work on it. [1] https://github.com/mhogomchungu/lxqt_wallet [2] https://wiki.gnome.org/GnomeGoals/LibsecretMigration |
From: PCMan <pcm...@gm...> - 2013-08-10 04:48:35
|
On Sat, Aug 10, 2013 at 12:18 PM, .. ink .. <mho...@gm...> wrote: > >> Name: lxqt-keyring >> >> Implementation detail: >> I studied the source code of gnome-keyring and libgcr today. >> Actaully, it's only gcr-ui and gcr that requires gtk+. >> The gnome developers carefully separated UI and non-UI parts. >> The non-UI parts gcr-base and gck are not linked to gtk+. >> Gcr-ui is a lib used to develop other keyring associated programs. >> Gnome-keyring itself does not rely on it that much. >> So, I think porting gnome-keyring to Qt is a faster approach. >> Besides, gnome-keyring is well-tested and is a proven solution. >> Since its developers separated UI and non-UI parts already, we can use it. >> I'm interested in doing this, too. >> > > can you point to the repository with gcr sources? i looked but couldnt find > them. https://git.gnome.org/browse/gcr Please see if you can take some useful code from them. > I already set up a repository[1]. creation of a wallet and testing if a > wallet key is correct works.I will just continue for my own amusement if you > guys go with gnome-keyring. It's me that want to try gnome-keyring. I'm not sure about others. The advantage of this approach is, gnome-keyring only uses minimal gtk+ and libgcr-base is UI independent. But the problem is in management UI. The UI used to manage the keyring is seashore, which is full of gtk+. The same problem exists for kwallet. The kwallet daemon and backends seem to be mostly pure Qt. The configuration UI, however, is totally full of KDE APIs and is tight to KDE libs. They're part of KDE runtime and it's not very easy to make it a standalone component. > isnt gnome-keyring deprecated?[2],i dont think its wise basing future work > on it. Thank you for the info! I still see active development from their git. (mainly the gcr repo) It's hard to imagine that an actively developed project is deprecated. Then I probably need to see what they're doing with libsecret and not touch gnome-keyring for now. For keeping the password, I'd suggest that you try KeepPassX, yet aother Qt-based wallet program. It stores and encrypt all your passwords and it's a pure Qt program. What I like from gnome-keyring is, it has integration with PAM, so after login your desktop session, the keyring is decrypted automatically. It has ssh agent and others, so we don't have to type the password sometimes. KeepPassX does not do this and only provides password storage and a complete configuration UI. It, however, provides a good password generator with a nice UI. Maybe you can take some code from KeepPassX. BTW, since gnome-keyring and KWallet both expose their functions via dbus, it will be better if you can implement the dbus iface so other programs can access your wallet. Unfortunately, their dbus API are different. :-( Good luck with your wallet thing. I'll follow up your progress. :) > [1] https://github.com/mhogomchungu/lxqt_wallet > [2] https://wiki.gnome.org/GnomeGoals/LibsecretMigration |
From: PCMan <pcm...@gm...> - 2013-08-10 04:52:37
|
On Sat, Aug 10, 2013 at 12:48 PM, PCMan <pcm...@gm...> wrote: > On Sat, Aug 10, 2013 at 12:18 PM, .. ink .. <mho...@gm...> wrote: >> >>> Name: lxqt-keyring >>> >>> Implementation detail: >>> I studied the source code of gnome-keyring and libgcr today. >>> Actaully, it's only gcr-ui and gcr that requires gtk+. >>> The gnome developers carefully separated UI and non-UI parts. >>> The non-UI parts gcr-base and gck are not linked to gtk+. >>> Gcr-ui is a lib used to develop other keyring associated programs. >>> Gnome-keyring itself does not rely on it that much. >>> So, I think porting gnome-keyring to Qt is a faster approach. >>> Besides, gnome-keyring is well-tested and is a proven solution. >>> Since its developers separated UI and non-UI parts already, we can use it. >>> I'm interested in doing this, too. >>> >> >> can you point to the repository with gcr sources? i looked but couldnt find >> them. > > https://git.gnome.org/browse/gcr > Please see if you can take some useful code from them. > >> I already set up a repository[1]. creation of a wallet and testing if a >> wallet key is correct works.I will just continue for my own amusement if you >> guys go with gnome-keyring. > > It's me that want to try gnome-keyring. I'm not sure about others. > The advantage of this approach is, gnome-keyring only uses minimal > gtk+ and libgcr-base is UI independent. > But the problem is in management UI. > The UI used to manage the keyring is seashore, which is full of gtk+. > > The same problem exists for kwallet. > The kwallet daemon and backends seem to be mostly pure Qt. > The configuration UI, however, is totally full of KDE APIs and is > tight to KDE libs. > They're part of KDE runtime and it's not very easy to make it a > standalone component. > >> isnt gnome-keyring deprecated?[2],i dont think its wise basing future work >> on it. > > Thank you for the info! > I still see active development from their git. (mainly the gcr repo) > It's hard to imagine that an actively developed project is deprecated. > Then I probably need to see what they're doing with libsecret and not > touch gnome-keyring for now. > > For keeping the password, I'd suggest that you try KeepPassX, yet > aother Qt-based wallet program. > It stores and encrypt all your passwords and it's a pure Qt program. > What I like from gnome-keyring is, it has integration with PAM, so > after login your desktop session, the keyring is decrypted > automatically. It has ssh agent and others, so we don't have to type > the password sometimes. > KeepPassX does not do this and only provides password storage and a > complete configuration UI. > It, however, provides a good password generator with a nice UI. Maybe > you can take some code from KeepPassX. > > BTW, since gnome-keyring and KWallet both expose their functions via > dbus, it will be better if > you can implement the dbus iface so other programs can access your wallet. > Unfortunately, their dbus API are different. :-( > > Good luck with your wallet thing. I'll follow up your progress. :) > >> [1] https://github.com/mhogomchungu/lxqt_wallet >> [2] https://wiki.gnome.org/GnomeGoals/LibsecretMigration Well, we were wrong. Gnome-keyring is not deprecated. It's libgnome-keyring that's deprecated, not the daemon. They replace libgnome-keyring with libsecret, and libsecret still talks to gnome-keyring. Gnome-keyring is composed of several parts, gnome-keyring-daemon, gnome-keyring command line tool, and libgnome-keyring, which is a wrapper lib around its dbus interface. The real work is done by libgcr, which is required by gnome-keyring-daemon. So, gnome-keyring is still actively developed. |
From: Kevin K. <and...@gm...> - 2013-08-10 10:15:03
Attachments:
signature.asc
|
On Friday, 2013-08-09, PCMan wrote: > On Sat, Aug 10, 2013 at 1:11 AM, .. ink .. <mho...@gm...> wrote: > >>> 4. Any plans to support KDE's kstatusnotifyitem API[2]? > >> > >> Long time ago I suggested to implement appindicator, bu it was > >> Ubuntu-specific and we decided don't to do that. If the situation has > >> changed now, I think we can implement it. The XEmbed is terrible. > >> > >> Who knows what with systray in Wayland/Mir? > >> > > As far as i know KDE's kstatusnotifyitem and unity's appindicator > > > > implements the same underlying d-bus based API. > > Supporting unity appindicator is possible. We did it in lxde in the past. > Unity provides a lib for it, so technically we can create a panel > plugin for appindicator. And, since it is a D-Bus API, it can also be implemented directly. > > Also,any plans to have kwallet/gnome-keyring type of functionality? > > Yes, it's in my long long TODO list. > Actually before the merge of razor and lxde happens, I studies this a bit. > > > I googled a bit and nobody else seem to be providing the feature. > > Yes, that's true. > > > It would have been nice to have a DE independent,self contained,pure C > > based small library that offer the functionality project could easily > > use.In other words,a sqlite.c type source file that gives the > > functionality. > > Historically, KWallet and gnome-keyring developers discussed on xdg mailing > list to see if they can use a common dbus interface so they can be > compatible. The effort was in vain and the proposal failed. No further > improvement in this area since then. Actually I think GNOME keyring implements the Secret Service API already. The KDE implementation is also finished but hasn't been merged yet. My understanding is that is postponed for KDE Frameworks 5. Maybe Valentin can help us out with more up to date info here :) Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring |
From: Stephan S. <gma...@sp...> - 2013-08-10 15:22:28
|
On 13-08-10 06:14 AM, Kevin Krammer wrote: > On Friday, 2013-08-09, PCMan wrote: >> On Sat, Aug 10, 2013 at 1:11 AM, .. ink .. <mho...@gm...> wrote: > >>>>> 4. Any plans to support KDE's kstatusnotifyitem API[2]? >>>> >>>> Long time ago I suggested to implement appindicator, bu it was >>>> Ubuntu-specific and we decided don't to do that. If the situation has >>>> changed now, I think we can implement it. The XEmbed is terrible. >>>> >>>> Who knows what with systray in Wayland/Mir? >>>> >>> As far as i know KDE's kstatusnotifyitem and unity's appindicator >>> >>> implements the same underlying d-bus based API. >> >> Supporting unity appindicator is possible. We did it in lxde in the past. >> Unity provides a lib for it, so technically we can create a panel >> plugin for appindicator. > > And, since it is a D-Bus API, it can also be implemented directly. > Does the KDE version extend the API to be capable of supporting a "left-click toggles main window visibility, right-click displays the context menu" paradigm? I love the idea of having the tray process handle the tray icons and provide consistent display and behaviour rather than using XEmbed, but I've gone as far as completely avoiding applications which offer only AppIndicator-based tray icons because I refuse to double the number of clicks and throw in some precision mouse movement in order to show/hide an application's main window. (Especially if I just want to peek at its status without having said status visible during times when I'm vulnerable to distraction.) |
From: Andrej N. G. <an...@re...> - 2013-08-10 16:45:56
|
Hello! Stephan Sokolow has written on Saturday, 10 August, at 11:22: >I've gone as far as completely avoiding applications which offer only >AppIndicator-based tray icons because I refuse to double the number of >clicks and throw in some precision mouse movement in order to show/hide >an application's main window. (Especially if I just want to peek at its >status without having said status visible during times when I'm >vulnerable to distraction.) Another annoying thing of AppIndicator-based tray icons is that they never show tooltips and to see status I should click it and then click again to hide status, and for "usual left-click or right-click" actions I should select option in menu below the status and click it. That is weird at the very least but GNOME tell everyone their desktop should be used on tablets and tablets don't support neither tooltips nor right-click, it's their reason for removing both right-click and tooltips from gnome-shell APIs. Andriy. |
From: Kevin K. <kr...@kd...> - 2013-08-10 17:08:14
Attachments:
signature.asc
|
On Saturday, 2013-08-10, Stephan Sokolow wrote: > On 13-08-10 06:14 AM, Kevin Krammer wrote: > > On Friday, 2013-08-09, PCMan wrote: > >> On Sat, Aug 10, 2013 at 1:11 AM, .. ink .. <mho...@gm...> wrote: > >>>>> 4. Any plans to support KDE's kstatusnotifyitem API[2]? > >>>> > >>>> Long time ago I suggested to implement appindicator, bu it was > >>>> Ubuntu-specific and we decided don't to do that. If the situation has > >>>> changed now, I think we can implement it. The XEmbed is terrible. > >>>> > >>>> Who knows what with systray in Wayland/Mir? > >>>> > >>> As far as i know KDE's kstatusnotifyitem and unity's appindicator > >>> > >>> implements the same underlying d-bus based API. > >> > >> Supporting unity appindicator is possible. We did it in lxde in the > >> past. Unity provides a lib for it, so technically we can create a panel > >> plugin for appindicator. > > > > And, since it is a D-Bus API, it can also be implemented directly. > > Does the KDE version extend the API to be capable of supporting a > "left-click toggles main window visibility, right-click displays the > context menu" paradigm? I am not sure how it does it exactly but it definitely does it. E.g. left clicking the Amarok icon toggles main window visiblity and Amarok is using KSystemNotifierItem for its tray integration. I did a quick code search and it seems this is communicated via a property on the D-Bus object. If the property "ItemIsMenu" is true, left click will call the ContextMenu D-Bus method, otherwise (propery is false or missing) it will call the Activate D-Bus method. If you need that more detailed I guess it would be best to ask on the plasma- de...@kd... mailinglist or on the #plasma channel on Freenode IRC. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring |
From: Kevin K. <and...@gm...> - 2013-08-10 17:17:15
Attachments:
signature.asc
|
On Saturday, 2013-08-10, Andrej N. Gritsenko wrote: > Hello! > > Stephan Sokolow has written on Saturday, 10 August, at 11:22: > >I've gone as far as completely avoiding applications which offer only > >AppIndicator-based tray icons because I refuse to double the number of > >clicks and throw in some precision mouse movement in order to show/hide > >an application's main window. (Especially if I just want to peek at its > >status without having said status visible during times when I'm > >vulnerable to distraction.) > > Another annoying thing of AppIndicator-based tray icons is that they > never show tooltips and to see status I should click it and then click > again to hide status, and for "usual left-click or right-click" actions I > should select option in menu below the status and click it. Wouldn't a visualization like that be up to the host? I.e. the LXDE-Qt panel or tray implementation? The KDE Plasma tray applet definitely does show hover popups, however I don't have any libappindicator using application running here (only one using either KStatusNotifierItem or QSystemTrayIcon), Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring |
From: Andrej N. G. <an...@re...> - 2013-08-10 17:28:04
|
Hello! Kevin Krammer has written on Saturday, 10 August, at 19:16: >On Saturday, 2013-08-10, Andrej N. Gritsenko wrote: >> Stephan Sokolow has written on Saturday, 10 August, at 11:22: >> >I've gone as far as completely avoiding applications which offer only >> >AppIndicator-based tray icons because I refuse to double the number of >> >clicks and throw in some precision mouse movement in order to show/hide >> >an application's main window. (Especially if I just want to peek at its >> >status without having said status visible during times when I'm >> >vulnerable to distraction.) >> Another annoying thing of AppIndicator-based tray icons is that they >> never show tooltips and to see status I should click it and then click >> again to hide status, and for "usual left-click or right-click" actions I >> should select option in menu below the status and click it. >Wouldn't a visualization like that be up to the host? >I.e. the LXDE-Qt panel or tray implementation? Exactly, it is tray implementation which gives API for plugins. And since gnome-shell tray doesn't offer such API, plugin has no possibility to implement it. Therefore even if those plugins started in another tray they still don't support it. >The KDE Plasma tray applet definitely does show hover popups, however I don't >have any libappindicator using application running here (only one using either >KStatusNotifierItem or QSystemTrayIcon), >Cheers, >Kevin Cheers! Andriy. |
From: .. i. .. <mho...@gm...> - 2013-08-10 17:39:25
|
> Exactly, it is tray implementation which gives API for plugins. And > since gnome-shell tray doesn't offer such API, plugin has no possibility > to implement it. Therefore even if those plugins started in another tray > they still don't support it. > > gnome-shell has extensions,is it not possible to create an extension that supports the specification in a way that gives UI people prefer?.Same thing for appindicator,cant a different one be used if people dont link its current behavior. this is why i like KDE,there are multiple launchers to choose from,multiple panels,multiple taskbars,multiple notification systems.If somebody doesnt like something,the infrastructure is there for them to do what they please. |
From: Kevin K. <and...@gm...> - 2013-08-10 18:04:45
Attachments:
signature.asc
|
On Saturday, 2013-08-10, Andrej N. Gritsenko wrote: > Hello! > > Kevin Krammer has written on Saturday, 10 August, at 19:16: > >On Saturday, 2013-08-10, Andrej N. Gritsenko wrote: > >> Stephan Sokolow has written on Saturday, 10 August, at 11:22: > >> >I've gone as far as completely avoiding applications which offer only > >> >AppIndicator-based tray icons because I refuse to double the number of > >> >clicks and throw in some precision mouse movement in order to show/hide > >> >an application's main window. (Especially if I just want to peek at its > >> >status without having said status visible during times when I'm > >> >vulnerable to distraction.) > >> > > >> Another annoying thing of AppIndicator-based tray icons is that they > >> > >> never show tooltips and to see status I should click it and then click > >> again to hide status, and for "usual left-click or right-click" actions > >> I should select option in menu below the status and click it. > > > >Wouldn't a visualization like that be up to the host? > >I.e. the LXDE-Qt panel or tray implementation? > > Exactly, it is tray implementation which gives API for plugins. And > since gnome-shell tray doesn't offer such API, plugin has no possibility > to implement it. Therefore even if those plugins started in another tray > they still don't support it. Right, but in the context of LXDE/Razor this is of no consequence, because those are the hosts. The applications offer functionality and visualization data and the hosts decide how to present that data and trigger functionality so that it fits into the host's overall design concepts. So even if the application does not explicitly set any tooltip information a host implementation could still show other things like icon, application name and status in a tooltip. Or maybe I am misunderstanding your concern. Are the LXDE or Razor systrays currently not showing any tooltips? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring |
From: Andrej N. G. <an...@re...> - 2013-08-10 18:43:18
|
Hello! Kevin Krammer has written on Saturday, 10 August, at 20:04: >On Saturday, 2013-08-10, Andrej N. Gritsenko wrote: >> Kevin Krammer has written on Saturday, 10 August, at 19:16: >> >On Saturday, 2013-08-10, Andrej N. Gritsenko wrote: >> >> Stephan Sokolow has written on Saturday, 10 August, at 11:22: >> >> >I've gone as far as completely avoiding applications which offer only >> >> >AppIndicator-based tray icons because I refuse to double the number of >> >> >clicks and throw in some precision mouse movement in order to show/hide >> >> >an application's main window. (Especially if I just want to peek at its >> >> >status without having said status visible during times when I'm >> >> >vulnerable to distraction.) >> >> Another annoying thing of AppIndicator-based tray icons is that they >> >> never show tooltips and to see status I should click it and then click >> >> again to hide status, and for "usual left-click or right-click" actions >> >> I should select option in menu below the status and click it. >> >Wouldn't a visualization like that be up to the host? >> >I.e. the LXDE-Qt panel or tray implementation? >> Exactly, it is tray implementation which gives API for plugins. And >> since gnome-shell tray doesn't offer such API, plugin has no possibility >> to implement it. Therefore even if those plugins started in another tray >> they still don't support it. >Right, but in the context of LXDE/Razor this is of no consequence, because >those are the hosts. >The applications offer functionality and visualization data and the hosts >decide how to present that data and trigger functionality so that it fits into >the host's overall design concepts. >So even if the application does not explicitly set any tooltip information a >host implementation could still show other things like icon, application name >and status in a tooltip. >Or maybe I am misunderstanding your concern. Are the LXDE or Razor systrays >currently not showing any tooltips? I believe their panels show them just fine. I've just added my $.02 about AppIndicator applets - they are uneasy to use because they require a lot of extra clicks, as Stephan Sokolow noticed. And I'm not sure if it possible to extract status from AppIndicator applet until you click on it, so only thing which our tray may show in tooltip is application name which is not very useful unfortunately. It's why I'm rather avoiding any AppIndicator applets. And I still believe desktop and tablet environments should be different in usability. Gnome/Unity/Win8 don't agree with me, you know. Cheers! Andriy. |
From: Kevin K. <and...@gm...> - 2013-08-12 11:38:59
Attachments:
signature.asc
|
Hi! On Saturday, 2013-08-10, Andrej N. Gritsenko wrote: > Hello! > Kevin Krammer has written on Saturday, 10 August, at 20:04: [...] > >Right, but in the context of LXDE/Razor this is of no consequence, because > >those are the hosts. > > > >The applications offer functionality and visualization data and the hosts > >decide how to present that data and trigger functionality so that it fits > >into the host's overall design concepts. > > > >So even if the application does not explicitly set any tooltip information > >a host implementation could still show other things like icon, > >application name and status in a tooltip. > > > >Or maybe I am misunderstanding your concern. Are the LXDE or Razor > >systrays currently not showing any tooltips? > > I believe their panels show them just fine. I've just added my $.02 > about AppIndicator applets - they are uneasy to use because they require > a lot of extra clicks, as Stephan Sokolow noticed. But that it part of what the host does. The LXDE panel could simply display the tooltip on mouse hover. The KDE panel does that. > And I'm not sure if it > possible to extract status from AppIndicator applet until you click on > it, so only thing which our tray may show in tooltip is application name > which is not very useful unfortunately. Of course an application might not have tooltips. But if you compare the two situations, XEmbed vs. StatusNotifier, then in the first case you as the host can do nothing, while in the second case you can at least create a tooltip using the icon and the title. Not as useful as an application setting an explicit tooltip but already allowing users to better identify which application an icon belongs to. > It's why I'm rather avoiding any > AppIndicator applets. And I still believe desktop and tablet environments > should be different in usability. Gnome/Unity/Win8 don't agree with me, > you know. I agree as well, so do the Plasma workspace people. Which is the reason the came up with the spec, because it allows different workspaces to display and interact with the application status data in a way that fits their environment (e.g. mouse vs. touch). E.g. a desktop shell could display the tooltip on hover, activate on left click and menu on right click, while a tablet shell could display tooltip on touch, activate the window on long press and activate the menu on a swipe gesture. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring |
From: .. i. .. <mho...@gm...> - 2013-08-11 22:35:35
|
a preliminary report on my effort to create a wallet support for razor-qt. I am already familiar with KDE kwallet and hence the API will be based on it. 1. The wallet will have backends,internal,kwallet and gnome-keyring.This should make it possible to target one API and use different backends. For example,in my project qCheckGMail,i will use this API but will be storing credentials in kwallet through it. 2. The front end API is still at a conceptual level but an idea of where i am header can be seen here[1] 3. The internal storage support is to me most part,done.Its in C and can be used independently in other projects since it has a dependency only with gcrypt.The source code of the back end is at[2] 4. An overview of the internal storage file format is at[3][4] [1] https://github.com/mhogomchungu/lxqt_wallet/blob/master/lxqt_wallet_interface.h [2] https://github.com/mhogomchungu/lxqt_wallet/blob/master/lxqtwallet.c [3] https://github.com/mhogomchungu/lxqt_wallet/blob/master/doc/lxqt_wallet_header_structure.jpg [4] https://github.com/mhogomchungu/lxqt_wallet/blob/master/doc/wallets_encryption_decryption_process.jpg |
From: Stephan S. <gma...@sp...> - 2013-08-11 00:45:39
|
As far as I can tell, libappindicator (which most appindicator-supporting applications use since it gives them a tray icon fallback for free if the panel doesn't support appindicators) doesn't provide an API to allow applications to register separate actions for left-click and right-click. (Just a menu which most hosts bind to both left and right click and that's it) That's the problem. Most applications use a client library which implements an API without the ability to specify the behaviour I want... which means that we'd have a chicken-and-egg problem with anything we did on the server side. The reason I asked about the KDE one is that KDE is a big enough target that, if they offer an alternative with a richer API, then there's hope that it could gain enough inertia to catch on as the de facto standard apps support if available. (Plus, I really think it's stupid to use touchscreens as an excuse to only have one action. Whatever happened to the tap-and-hold gesture?) On 13-08-10 02:43 PM, Andrej N. Gritsenko wrote: > Hello! > > Kevin Krammer has written on Saturday, 10 August, at 20:04: >> On Saturday, 2013-08-10, Andrej N. Gritsenko wrote: >>> Kevin Krammer has written on Saturday, 10 August, at 19:16: >>>> On Saturday, 2013-08-10, Andrej N. Gritsenko wrote: >>>>> Stephan Sokolow has written on Saturday, 10 August, at 11:22: >>>>>> I've gone as far as completely avoiding applications which offer only >>>>>> AppIndicator-based tray icons because I refuse to double the number of >>>>>> clicks and throw in some precision mouse movement in order to show/hide >>>>>> an application's main window. (Especially if I just want to peek at its >>>>>> status without having said status visible during times when I'm >>>>>> vulnerable to distraction.) > >>>>> Another annoying thing of AppIndicator-based tray icons is that they >>>>> never show tooltips and to see status I should click it and then click >>>>> again to hide status, and for "usual left-click or right-click" actions >>>>> I should select option in menu below the status and click it. > >>>> Wouldn't a visualization like that be up to the host? >>>> I.e. the LXDE-Qt panel or tray implementation? > >>> Exactly, it is tray implementation which gives API for plugins. And >>> since gnome-shell tray doesn't offer such API, plugin has no possibility >>> to implement it. Therefore even if those plugins started in another tray >>> they still don't support it. > >> Right, but in the context of LXDE/Razor this is of no consequence, because >> those are the hosts. > >> The applications offer functionality and visualization data and the hosts >> decide how to present that data and trigger functionality so that it fits into >> the host's overall design concepts. > >> So even if the application does not explicitly set any tooltip information a >> host implementation could still show other things like icon, application name >> and status in a tooltip. > >> Or maybe I am misunderstanding your concern. Are the LXDE or Razor systrays >> currently not showing any tooltips? > > I believe their panels show them just fine. I've just added my $.02 > about AppIndicator applets - they are uneasy to use because they require > a lot of extra clicks, as Stephan Sokolow noticed. And I'm not sure if it > possible to extract status from AppIndicator applet until you click on > it, so only thing which our tray may show in tooltip is application name > which is not very useful unfortunately. It's why I'm rather avoiding any > AppIndicator applets. And I still believe desktop and tablet environments > should be different in usability. Gnome/Unity/Win8 don't agree with me, > you know. > > Cheers! > Andriy. > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > |
From: Stephan S. <gma...@sp...> - 2013-08-11 01:17:30
|
On 13-08-10 01:07 PM, Kevin Krammer wrote: > > I am not sure how it does it exactly but it definitely does it. > E.g. left clicking the Amarok icon toggles main window visiblity and Amarok is > using KSystemNotifierItem for its tray integration. > > I did a quick code search and it seems this is communicated via a property on > the D-Bus object. If the property "ItemIsMenu" is true, left click will call > the ContextMenu D-Bus method, otherwise (propery is false or missing) it will > call the Activate D-Bus method. > Ok, that's a relief. I checked all of my tray icons and it looks like the developers could implement something comfortably sane with that kind of "one action, but you choose which one" limitation, should they choose to drop the XEmbed implementation. Most of them already either have fairly useless context menus or, like Parcellite, have no main window and already display a context menu on left-click. The ones that might be an issue without separate left- and right-click behaviours, should their developers ever abandon XEmbed are: 1. Pidgin (I don't mind only having "toggle visibility" and the context menu does have a lot of stuff that is used infrequently enough to be only accessed via the main window (eg. shortcuts to the accounts and preferences dialogs), but I can see people complaining about needing an extra click to do things like changing their status to/from Away/Busy/etc.) 2. Audacious Media Player (Not everyone uses the global keybindings plugin to toggle main window visibility like I do, I wouldn't want to HAVE to take my hand off the mouse to toggle visibility, and the context menu has useful options like Play/Pause and "quit the damn application so I can re-launch it to get the playlist responding to keystrokes again") |
From: Andrej N. G. <an...@re...> - 2013-08-11 01:48:54
|
Hello! Stephan Sokolow has written on Saturday, 10 August, at 21:17: >On 13-08-10 01:07 PM, Kevin Krammer wrote: >> I am not sure how it does it exactly but it definitely does it. >> E.g. left clicking the Amarok icon toggles main window visiblity and Amarok is >> using KSystemNotifierItem for its tray integration. >> I did a quick code search and it seems this is communicated via a property on >> the D-Bus object. If the property "ItemIsMenu" is true, left click will call >> the ContextMenu D-Bus method, otherwise (propery is false or missing) it will >> call the Activate D-Bus method. >Ok, that's a relief. I checked all of my tray icons and it looks like >the developers could implement something comfortably sane with that kind >of "one action, but you choose which one" limitation, should they choose >to drop the XEmbed implementation. I don't like the "one action" idea at all, I never want configuration of clipboard manager to be mixed with history so I should search one or another. Options should be right-clicked and history drop-down should be left-clicked. The same for keyboard layout switcher. Well, I use shortcut but many people use left-click on tray icon and where to find config if there is only single action? So that "one action" is a very stupid idea, I'm sorry if I'm rude. >Most of them already either have fairly useless context menus or, like >Parcellite, have no main window and already display a context menu on >left-click. >The ones that might be an issue without separate left- and right-click >behaviours, should their developers ever abandon XEmbed are: >1. Pidgin (I don't mind only having "toggle visibility" and the context >menu does have a lot of stuff that is used infrequently enough to be >only accessed via the main window (eg. shortcuts to the accounts and >preferences dialogs), but I can see people complaining about needing an >extra click to do things like changing their status to/from Away/Busy/etc.) It's true for all other IM applications around - Licq, Psi, Skype, etc. I use their context menu not too rarely and I hate to miss it or to click twice to open window. And don't tell me to use shortcuts - I don't have keyboard with 500 keys to bind them all to all applications I ever use and even if I had I don't have a big table to put such monster. ;) >2. Audacious Media Player (Not everyone uses the global keybindings >plugin to toggle main window visibility like I do, I wouldn't want to >HAVE to take my hand off the mouse to toggle visibility, and the context >menu has useful options like Play/Pause and "quit the damn application >so I can re-launch it to get the playlist responding to keystrokes again") Also audio mixer - I used to scroll it to change volume, middle-click to mute, left-click to open a mixer, and that all is what I use often and pack it all into single action menu is damn bad. I rather will use some outdated application which does it than use some new which cannot. Andriy. |
From: Stephan S. <gma...@sp...> - 2013-08-11 02:28:26
|
On 13-08-10 09:48 PM, Andrej N. Gritsenko wrote: > > I don't like the "one action" idea at all, I never want configuration > of clipboard manager to be mixed with history so I should search one or > another. Options should be right-clicked and history drop-down should be > left-clicked. The same for keyboard layout switcher. Well, I use shortcut > but many people use left-click on tray icon and where to find config if > there is only single action? So that "one action" is a very stupid idea, > I'm sorry if I'm rude. > Don't worry. I agree. I'm just saying that, if an application does buy into that appindicator-style nonsense, at least it should be possible to get something tolerable without having to maintain a patched version. > It's true for all other IM applications around - Licq, Psi, Skype, > etc. I use their context menu not too rarely and I hate to miss it or to > click twice to open window. And don't tell me to use shortcuts - I don't > have keyboard with 500 keys to bind them all to all applications I ever > use and even if I had I don't have a big table to put such monster. ;) Trust me. If there's anyone who understands the concept of "well-chosen defaults don't justify forcing them on everyone", it's me. I'm the Vim junkie whose introduction to Vim was delayed by five years because I had the mistaken impression that someone was being pushy about trying it and my instinctive response to dig in my heels kicked in without conscious notice. (Something I've spent my entire life learning to suppress.) ...though, for the record, all my keybinds are using a Rosewill RK-9000I which is one of the most compact, basic 104-key keyboards you can find with mechanical keyswitches. (The limited edition 9000I was on sale for less than the normal 9000) I just set up a few custom global keybinds for the stuff I use a LOT... all either mnemonic or otherwise easy to remember. For example: F12 (Toggle urxvt with kuake plugin and GNU screen) Super+Space (gmrun or other history+tab-complete run dialog) Super+Pause (Play/Pause) Super+Left/Right (Previous/Next Track) Super+Up/Down (Jump to First/Last Track in Playlist) Super+J (Show Jump to Song dialog) Super+KP_Plus/KP_Minus (Increase/Decrease master mixer volume) Ctrl+Alt+NumpadNumbers (Tile active window to matching monitor regions) Ctrl+Alt+NumpadEntry (Cycle active window to next monitor) (F12 and the Ctrl+Alt+... binds were things already in muscle memory from Yakuake and WinSplit Revolution. Hence why they were the easiest to remember.) > >> 2. Audacious Media Player (Not everyone uses the global keybindings >> plugin to toggle main window visibility like I do, I wouldn't want to >> HAVE to take my hand off the mouse to toggle visibility, and the context >> menu has useful options like Play/Pause and "quit the damn application >> so I can re-launch it to get the playlist responding to keystrokes again") > > Also audio mixer - I used to scroll it to change volume, middle-click > to mute, left-click to open a mixer, and that all is what I use often and > pack it all into single action menu is damn bad. I rather will use some > outdated application which does it than use some new which cannot. Oh, yeah. I completely forgot about that. I use the scroll wheel on the Audacious icon as my volume control when my hand is already on the mouse. Another problem with the idea of using the AppIndicator design universally. (I used Audacious global hotkeys to bind Super+KP_Plus and Super+KP_Minus as my keyboard-based volume control options.) > > Andriy. > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > |
From: Kevin K. <kr...@kd...> - 2013-08-11 10:37:00
Attachments:
signature.asc
|
On Sunday, 2013-08-11, Stephan Sokolow wrote: > On 13-08-10 09:48 PM, Andrej N. Gritsenko wrote: > >> 2. Audacious Media Player (Not everyone uses the global keybindings > >> plugin to toggle main window visibility like I do, I wouldn't want to > >> HAVE to take my hand off the mouse to toggle visibility, and the context > >> menu has useful options like Play/Pause and "quit the damn application > >> so I can re-launch it to get the playlist responding to keystrokes > >> again") > >> > > Also audio mixer - I used to scroll it to change volume, > > middle-click > > > > to mute, left-click to open a mixer, and that all is what I use often and > > pack it all into single action menu is damn bad. I rather will use some > > outdated application which does it than use some new which cannot. > > Oh, yeah. I completely forgot about that. I use the scroll wheel on the > Audacious icon as my volume control when my hand is already on the > mouse. Another problem with the idea of using the AppIndicator design > universally. KMix uses the interface's Scroll method for that. Well, indirectly the KDE library side handles the call to Scroll() by emitting a scrollRequested() signal, which KMix then connects to a volume change slot. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring |
From: Kevin K. <kr...@kd...> - 2013-08-11 10:26:12
Attachments:
signature.asc
|
On Sunday, 2013-08-11, Stephan Sokolow wrote: > As far as I can tell, libappindicator (which most > appindicator-supporting applications use since it gives them a tray icon > fallback for free if the panel doesn't support appindicators) doesn't > provide an API to allow applications to register separate actions for > left-click and right-click. I see. I guess there is very little point in using a wrapper library written for a different tool stack, basically using an abstraction that can easily be achieved directly using the tools at hand (qdbusxml2cpp). libappindicator seems to have been created to only address the usecase of Unity app indicator and should probably not be seen as a full client implementation of the specification. > That's the problem. Most applications use a client library which > implements an API without the ability to specify the behaviour I want... > which means that we'd have a chicken-and-egg problem with anything we > did on the server side. Sure, but it is always the responsibility of an application developer to chose libraries based on their capabilities. If a library only implements a subset of a given spec and the application developer wants to have all options available the developer will simply not use that particular implementation. I don't see a chicken-and-egg problem there. Applications that want to offer full capabilties for hosts that make use of all capabilities will just do that. A host implementor who wants to provide all capabilities will to just that independent of whether some applications only use a subset. > The reason I asked about the KDE one is that KDE is a big enough target > that, if they offer an alternative with a richer API, then there's hope > that it could gain enough inertia to catch on as the de facto standard > apps support if available. Right. I don't know if it is an extension or already part of the specification. It looked like part of the normal interface to me. > (Plus, I really think it's stupid to use touchscreens as an excuse to > only have one action. Whatever happened to the tap-and-hold gesture?) Also the whole point is to allow the host to decide if and how to trigger certain actions. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring |
From: Kevin K. <kr...@kd...> - 2013-08-11 10:34:58
Attachments:
signature.asc
|
On Sunday, 2013-08-11, Stephan Sokolow wrote: > On 13-08-10 01:07 PM, Kevin Krammer wrote: > > I am not sure how it does it exactly but it definitely does it. > > E.g. left clicking the Amarok icon toggles main window visiblity and > > Amarok is using KSystemNotifierItem for its tray integration. > > > > I did a quick code search and it seems this is communicated via a > > property on the D-Bus object. If the property "ItemIsMenu" is true, > > left click will call the ContextMenu D-Bus method, otherwise (propery is > > false or missing) it will call the Activate D-Bus method. > > Ok, that's a relief. I checked all of my tray icons and it looks like > the developers could implement something comfortably sane with that kind > of "one action, but you choose which one" limitation, should they choose > to drop the XEmbed implementation. There are separate calls for "Activate" and "ContextMenu". An application can provide both. The host can call Activate on left-click and ContextMenu on right-click. > 1. Pidgin (I don't mind only having "toggle visibility" and the context > menu does have a lot of stuff that is used infrequently enough to be > only accessed via the main window (eg. shortcuts to the accounts and > preferences dialogs), but I can see people complaining about needing an > extra click to do things like changing their status to/from Away/Busy/etc.) Kopete uses both. > 2. Audacious Media Player (Not everyone uses the global keybindings > plugin to toggle main window visibility like I do, I wouldn't want to > HAVE to take my hand off the mouse to toggle visibility, and the context > menu has useful options like Play/Pause and "quit the damn application > so I can re-launch it to get the playlist responding to keystrokes again") Amarok does both as well. Just examples of programs I use that offer different functions for different mouse button clicks. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring |
From: Stephan S. <gma...@sp...> - 2013-08-11 14:17:12
|
My main concern is that there are a lot of GTK+ apps out there and, if that's not a KDE-specific extension, then it may require convincing each developer to buy into using something other than libindicate since it doesn't seem to provide a way to access it in the manner you described. The AppIndicator class does provide a scroll-event signal but, as far as I can tell from the API docs, it imposes these rules on toggling main window visibility: 1. The indicator won't be visible unless you register a menu for things like Unity to display on left-click and right-click using set_menu() 2. set_menu() ONLY accepts a GtkMenu object. 3. You can register a "secondary acctivate target" which things like Unity will bind to middle-click using set_secondary_activate_target() 4. The secondary activate target will only be called if it's a visible and active child of the GtkMenu you passed via set_menu(). 5. I can see no way to swap the actions so the menu is the secondary action and the visibility toggle is the primary one. My best guess is that ItemIsMenu is a KDE-specific extension. bind a non-menu to left-click using libindicate, so I'm guessing that's a KDE-specific extension. (However, if anyone can demonstrate that Amarok's indicator works as expected in Unity, then that would indicate that the restriction is being enforced in libindicator rather than the panel host) Source: http://developer.ubuntu.com/api/ubuntu-12.04/c/appindicator/libappindicator-app-indicator.html The KStatusNotifierItem API docs seem to bear this out, since, unlike AppIndicator, it provides a rich API with methods like setAssociatedWidget and ordinary signals like activateRequested and secondaryActivateRequested alongside the more ordinary setContextMenu method and scrollRequested signal. In fact, given the documentation for setContextMenu and setStandardActionsEnabled, it looks like KStatusNotifierItem is designed around the idea that most applications will want to bind a window to left-click and just let KDE itself auto-generate a context menu with actions like "Quit" for the right-click. Source: http://api.kde.org/4.5-api/kdelibs-apidocs/kdeui/html/classKStatusNotifierItem.html On 13-08-11 06:33 AM, Kevin Krammer wrote: > On Sunday, 2013-08-11, Stephan Sokolow wrote: >> On 13-08-10 01:07 PM, Kevin Krammer wrote: >>> I am not sure how it does it exactly but it definitely does it. >>> E.g. left clicking the Amarok icon toggles main window visiblity and >>> Amarok is using KSystemNotifierItem for its tray integration. >>> >>> I did a quick code search and it seems this is communicated via a >>> property on the D-Bus object. If the property "ItemIsMenu" is true, >>> left click will call the ContextMenu D-Bus method, otherwise (propery is >>> false or missing) it will call the Activate D-Bus method. >> >> Ok, that's a relief. I checked all of my tray icons and it looks like >> the developers could implement something comfortably sane with that kind >> of "one action, but you choose which one" limitation, should they choose >> to drop the XEmbed implementation. > > There are separate calls for "Activate" and "ContextMenu". An application can > provide both. The host can call Activate on left-click and ContextMenu on > right-click. > >> 1. Pidgin (I don't mind only having "toggle visibility" and the context >> menu does have a lot of stuff that is used infrequently enough to be >> only accessed via the main window (eg. shortcuts to the accounts and >> preferences dialogs), but I can see people complaining about needing an >> extra click to do things like changing their status to/from Away/Busy/etc.) > > Kopete uses both. > >> 2. Audacious Media Player (Not everyone uses the global keybindings >> plugin to toggle main window visibility like I do, I wouldn't want to >> HAVE to take my hand off the mouse to toggle visibility, and the context >> menu has useful options like Play/Pause and "quit the damn application >> so I can re-launch it to get the playlist responding to keystrokes again") > > Amarok does both as well. > > Just examples of programs I use that offer different functions for different > mouse button clicks. > > Cheers, > Kevin > > > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > > > |
From: Kevin K. <kr...@kd...> - 2013-08-11 16:42:16
Attachments:
signature.asc
|
On Sunday, 2013-08-11, Stephan Sokolow wrote: > My main concern is that there are a lot of GTK+ apps out there and, if > that's not a KDE-specific extension, then it may require convincing each > developer to buy into using something other than libindicate since it > doesn't seem to provide a way to access it in the manner you described. I don't know how GTK application developers pick the libraries they want to use but they will probably look at other applications, so leading by example might work. Also, when the switch to Wayland moves away from XEmbed, they might be looking explicitly for an alternative. Whether that is libappindicator or a different library might depend on what features each provides, no? > The AppIndicator class does provide a scroll-event signal but, as far as > I can tell from the API docs, it imposes these rules on toggling main > window visibility: > > 1. The indicator won't be visible unless you register a menu for things > like Unity to display on left-click and right-click using set_menu() I guess that makes sense, i.e. every "icon" should probably have a menu, even if it just contains "show/hide" and "quit". But maybe that could be made configurable. > 2. set_menu() ONLY accepts a GtkMenu object. Sounds reasonable to me. > 3. You can register a "secondary acctivate target" which things like > Unity will bind to middle-click using set_secondary_activate_target() > > 4. The secondary activate target will only be called if it's a visible > and active child of the GtkMenu you passed via set_menu(). > > 5. I can see no way to swap the actions so the menu is the secondary > action and the visibility toggle is the primary one. My best guess is > that ItemIsMenu is a KDE-specific extension. It was my guess as well but to be sure I asked Marco (CCed, thanks a lot for your insights) since he is the original author of the spec. He says "yes, [it] was an extension done together with ubuntu because iirc they wanted the possibility to only open a menu, always (instead of activating the application with left click, menu with right click) and is supported by kde." He further says "the complete api that we expose on dbus (for the StatusNotifier object part) is on the file /kdelibs/kdeui/notifications/kstatusnotifieritemdbus_p.h (with some apidoc as well) thinking about it, [LXDE] could even take those classes and replace K* with Q* since the kde dependencies are not many (in frameworks is already standalone, as tier2, perhaps may be even more stripped to become tier1, don't remember exactly what other tier1 stuff it needs right now)" > bind a non-menu to left-click using libindicate, so I'm guessing that's > a KDE-specific extension. (However, if anyone can demonstrate that > Amarok's indicator works as expected in Unity, then that would indicate > that the restriction is being enforced in libindicator rather than the > panel host) I guess it could be done on either side but that sounds like a good test indeed. Maybe KMix would be an even better test target, it has a left-button popup, a menu and uses scroll handling. > Source: > http://developer.ubuntu.com/api/ubuntu-12.04/c/appindicator/libappindicator > -app-indicator.html > > The KStatusNotifierItem API docs seem to bear this out, since, unlike > AppIndicator, it provides a rich API with methods like > setAssociatedWidget and ordinary signals like activateRequested and > secondaryActivateRequested alongside the more ordinary setContextMenu > method and scrollRequested signal. Being the origin of the idea it is probably the most complete implementation. > In fact, given the documentation for setContextMenu and > setStandardActionsEnabled, it looks like KStatusNotifierItem is designed > around the idea that most applications will want to bind a window to > left-click and just let KDE itself auto-generate a context menu with > actions like "Quit" for the right-click. Yeah, that's the behavior KDE workspace users would expect and from what I've read here seems also what LXDE users do expect. But it still seems to be flexible enough to get a behavior Unity users expect when applications run in Unity. Cheers, Kevin > Source: > http://api.kde.org/4.5-api/kdelibs-apidocs/kdeui/html/classKStatusNotifierI > tem.html > > On 13-08-11 06:33 AM, Kevin Krammer wrote: > > On Sunday, 2013-08-11, Stephan Sokolow wrote: > >> On 13-08-10 01:07 PM, Kevin Krammer wrote: > >>> I am not sure how it does it exactly but it definitely does it. > >>> E.g. left clicking the Amarok icon toggles main window visiblity and > >>> Amarok is using KSystemNotifierItem for its tray integration. > >>> > >>> I did a quick code search and it seems this is communicated via a > >>> property on the D-Bus object. If the property "ItemIsMenu" is true, > >>> left click will call the ContextMenu D-Bus method, otherwise (propery > >>> is false or missing) it will call the Activate D-Bus method. > >> > >> Ok, that's a relief. I checked all of my tray icons and it looks like > >> the developers could implement something comfortably sane with that kind > >> of "one action, but you choose which one" limitation, should they choose > >> to drop the XEmbed implementation. > > > > There are separate calls for "Activate" and "ContextMenu". An application > > can provide both. The host can call Activate on left-click and > > ContextMenu on right-click. > > > >> 1. Pidgin (I don't mind only having "toggle visibility" and the context > >> menu does have a lot of stuff that is used infrequently enough to be > >> only accessed via the main window (eg. shortcuts to the accounts and > >> preferences dialogs), but I can see people complaining about needing an > >> extra click to do things like changing their status to/from > >> Away/Busy/etc.) > > > > Kopete uses both. > > > >> 2. Audacious Media Player (Not everyone uses the global keybindings > >> plugin to toggle main window visibility like I do, I wouldn't want to > >> HAVE to take my hand off the mouse to toggle visibility, and the context > >> menu has useful options like Play/Pause and "quit the damn application > >> so I can re-launch it to get the playlist responding to keystrokes > >> again") > > > > Amarok does both as well. > > > > Just examples of programs I use that offer different functions for > > different mouse button clicks. > > > > Cheers, > > Kevin > > > > > > > > ------------------------------------------------------------------------- > > ----- Get 100% visibility into Java/.NET code with AppDynamics Lite! > > It's a free troubleshooting tool designed for production. > > Get down to code-level detail for bottlenecks, with <2% overhead. > > Download for free and get started troubleshooting in minutes. > > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clkt > > rk > > --------------------------------------------------------------------------- > --- Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring |