Tray menu (network selection) is only 1 list item tall, plus up and down arrows

tbursztyka / connman-ui

A full-featured GTK based trayicon UI for ConnMan

GNU General Public License v2.0

38 stars 13 forks source link

Tray menu (network selection) is only 1 list item tall, plus up and down arrows #11

Closed djvs closed 9 years ago

tbursztyka commented 9 years ago

Hi,

It's a known issue, and has been identified as a GTK+ bug. Depends on the system-tray you are using also. (xfce, awesome, lxqt ones are known to work). Have a look at issue 6, it's the same bug.

djvs commented 9 years ago

Compare behavior in gtk program "clipit", same principle but works fine.

tbursztyka commented 9 years ago

As far as I can tell (I quickly went through the code), it does not do the same:

clipit generates the menu with the items before showing anything, and once it shows the menu, there is no dynamic modification of this menu.
connman-ui dynamically modifies the menu once showed according to the scan results: if services are added or removed, it will respecticelly add/remove items.

djvs commented 9 years ago

I figured, maybe worth considering doing it that way if it works. On Nov 25, 2014 2:21 AM, "Tomasz Bursztyka" notifications@github.com wrote:

As far as I can tell (I quickly went through the code), it does not do the same:

clipit generates the menu with the items before showing anything, and once it shows the menu, there is no dynamic modification of this menu.

connman-ui dynamically modifies the menu once showed according to the scan results: if services are added or removed, it will respecticelly add/remove items.

— Reply to this email directly or view it on GitHub https://github.com/tbursztyka/connman-ui/issues/11#issuecomment-64319516 .

tbursztyka commented 9 years ago

The problem is, depending on hardware and how many known hidden services you have, a scan might take a while and results will come by bunch with delays in between. With the clipit approach it could then take some time to see the list appearing, and that's not really nice for the user experience.

I am 100% sure the actual bug is in Gtk+. The tray icon widget is quite specific and does not own a window by default. As far as I pushed my investigation it would seem to be the cause that affect the menu size calculation, because the same logic on any window-based app just always works with Gtk+. I saw once some code having the same issue and fixing it by recalculating itself the size of the menu, but that's wrong since the framework owns such logic already.

djvs commented 9 years ago

Is there a tray app this will work with?

tbursztyka commented 9 years ago

The default one in awesome-wm works, the xfce one too, lxde and lxqt as well afaik. Or on the other way: the 2 ones I know which does not work are KDE's and Gnome 3. Haven't tested MATE's one.