Sublime Forum

SOLVED: Menu bar present but no drop-downs visible

#1

So, I’ve seen a fair number of reports about menus that are disappeared, and this isn’t one of them. I’m using a fresh install of Debian Jessie with KDE, but I’ve had this happen on other Debian installations, and wanted to convince myself it wasn’t a problem I’d induced.
The problem is that clicking on the menu bar results in the selected menu item turning blue-background, and then, nothing. I cannot seem to do anything to coerce the rest of the menu items to appear. If I use the left/right arrow keys, the selected item changes accordingly, but that’s it. No way to do anything, including enter my registration code, which I legitimately possess. Alt+\key\ lets me select the top menu items as well as mouse clicking. I’ve seen this on multiple Debian Linux desktop and laptop computers (never use any other OS), so it seems surprising to me that no one else seems to be reporting this problem. I originally installed on this fresh installation, version 3126, I think, using the instructions to edit the repositories list, followed by using apt-get to do the installation. On other installations, I downloaded the .deb file and used dpkg to install sublime text. Just now, my package manager reported an available upgrade, which I did, but it doesn’t fix the problem. Really would like this to get fixed. I’m probably capable of executing any sort of diagnostic that anyone can suggest.

0 Likes

#2

does the context menu display if you right click in the main ST window?

0 Likes

#3

I’ll have to try later today when I’m at home. Is there a theory behind your question?

What I can report is that the problem does not exist when I log into the exact same Debian 8.3 installation from a remote Debian 6 workstation (running Gnome desktop) and run the exact same ST on the Debian 8.3 computer (X tunnel via SSH). It’s far too slow to be useful, but with patience, everything seems to work, including the right-click to bring up the context menu.

From another thread, it was suggested to try running ST under strace, and filter for all of the open() system calls, and looking for the ones that failed. I’ll try that later, too. The other user had solved the problem by upgrading/installing some Gnome related components, so I’m going to try ST running under Gnome, as well.

0 Likes

#4

ofc :slight_smile:

the context menu is technically the same OS component as the dropdown part of an application menu, so it’d make sense if it also doesn’t work :wink: but if it does work, it could show that there is some problem specifically with dropdown menus.

0 Likes

#5

Okay, so no go on the context menus. Also, tried the remote access through an SSH X tunnel on a KDE desktop Debian 8.3 host (and where ST works fine locally), and everything works fine with that combo. So, that suggests to me that the installation of ST is fine, but it is sensitive to some mystery configuration of the desktop or something else related to the X server. I don’t have a good sense of what factors to look at. Didn’t get a chance to explore the strace diagnostic yet. I don’t have Gnome installed on the problem host, so any testing on that front will take some further effort.

0 Likes

#6

Hope this isn’t noise, but it seems peculiar to me. I ran ST under strace, and saw that it was complaining about some missing libraries that seemed to be Gnome related, and since another user reported success by doing some Gnome related updates, I installed Gnome. Tested under KDE, still, but a lot of 'ENOENT’s went away, so that seemed good, but the menu problem persisted. But this is what I think might be germane:

theNbomr@delldeb8:~$ grep -C1 libgio /tmp/sublime_text.strace_with_gnome_plus_libgio
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, “\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P<\3\0\0\0\0\0”…, 832) = 832

access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libgio-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libgio-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/libgio-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/libgio-2.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
munmap(0x7fdeb8b07000, 131639) = 0

Notice that libgio-2.0 is found in

/usr/lib/x86_64-linux-gnu/"

but later, it gets searched again, and goes unfound. I’m not sure how that happens. Is it an artifact of some plug-in architecture? I’m spitballing for sure here. Also, I get a huge number of

access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)

entries, which some other research seems to indicate is a Debian peculiarity and seems to be benign.

0 Likes

#7

SOLVED

Yay! It all works now. I logged out of my KDE session, and tried it under Gnome and it worked perfectly there. Logged back into KDE, and it now works perfectly there, too. In summary, I installed Gnome and a library called libgio, and that was all it took.

0 Likes