9

Given: I'm using export $(dbus-launch) in my /etc/bash.bashrc file as I'm normally running under a non-admin user and need to su - admin to do anything dangerous.

Normal behaviour: Go to dash, open gedit. The top menu is visible.

Abnormal behaviour Go to terminal, type: gedit. Then the top menu is invisible. (Problem persists even when sending to bg)

Additional info: I noticed when I do a gksudo gedit, that the menu appears below the menu bar of the window instead of the top menu…

More additional info: I just found the culprit: X11-forwarding. The "abnormal" behaviour stops when I remove export $(dbus-launch) from my bash.bashrc file.

Does anyone have a clue how to bring abnormal back to normal? (keeping x11-forwarding?) I've looked everywhere, but except for a bug on the preferences not showing, I found no solutions to this problem…

  • Seems abnormal, here gedit's menu is always accessible whether started from the .desktop (Dash) or the binary (a terminal). You can always use this from a terminal - gtk-launch gedit or gtk-launch gedit /path/to/a/file. This uses the .desktop to launch – doug Nov 19 '14 at 15:04
  • Thanks for the tip, but alas: using gtk-launch produces the same result. :( – Fabby Nov 20 '14 at 11:22
  • @muru: I only noticed now you removed the gnome-terminal tag 4 minutes after I put the question up for a bounty... Why??? As this only happens when starting from a terminal, I would say it's quite important. (Asking before adding the tag back in) – Fabby Dec 7 '14 at 14:23
  • 1
    Because it is not apparently specific to gnome-terminal (do you experience different behaviour if you use, say, xfce4-terminal instead?). I'd say x11-forwarding covers the fact that you're using a terminal. If you feel it doesn't, consider command-line. – muru Dec 7 '14 at 14:26
  • gtk-launch worked for me on 1604 over X11. Also surprised that the alias to itself worked. alias gedit='gtk-launch gedit' – rickfoosusa Jul 9 '16 at 15:43
4

I found the answer after all:

If you're using X11 forwarding, don't forget to look at the ~/.config/ for the user actually running gedit! Not the ~/.config/ of the user that the application is displayed in!

In this particular case, deleting the ~/.config/gedit solved this particular problem as gedit just recreates it afterwards. (dumb me: I should have renamed it and looked what the differences were, so I could have posted the perfect answer, but at the time, I was trying to solve another problem)


Original answer:

Too bad no one found any answer, so I'll post my own work-arounds as a "solution"

(I know though they're not really "solutions"; they're just "work-arounds")

  1. Use the toolbar for the most-often used commands.
  2. Use the Keyboard short-cuts: As the only menu-item I'm really missing from the toolbar is "File - Save As", I just press Alt+F and the menu seems to be coming out of the system menu when using this workaround. Then just press A for "As" and you get to the "Save As" dialog...

The same system can be used for Edit, View, Search, Tools, Documents and Help

  • +1 because this is close to a problem I'm having... running "sudo gedit" you cannot access any menus even with "<Alt>+E", "<Alt>+F", etc. Something with /home/user/.config/dconf vs /home/root/.config/dconf or as you say $~/.config/gedit vs #~/.config/gedit. Additionally people get messages like "** (gedit:12601): WARNING **: Set document metadata failed: Setting attribute metadata::gedit-spell-enabled not supported". Effects 100k+ people? – WinEunuuchs2Unix Mar 26 '17 at 20:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.