Re: [arch-general] Gedit startup issues
Hi, I've been bitten by a very similar issue recently on a RedHat system. When trying to launch from commandline no message is shown and the command returns soon. I did an strace of the execution and found out that gedit creates a socket in a temporary directory (in my case was controlled by $TMPDIR) and sometimes it wouldn't be deleted when closing gedit. On the next execution, it would find the socket, try to connect there and close as the syscalls failed. If it happens again and no error appears on logs or stdout/stderr, try the strace. You won't see it on the last line but a bit before, in my case 10-20 lines before the end. HTH, Miguel El 22 abr. 2016 7:39 a. m., "Ralf Mardorf" escribió: > On Thu, 21 Apr 2016 20:05:10 -0500, Marshall Neill wrote: > >Launch from the command line and see what shows up. > > > >Just a thought. > > That could help, after the issue appears when launching it by a file > manager or a launcher, but not necessarily helps. The output in > ~/.xsession-errors* could provide error messages from the original > event, when gedit first failed by e.g. launching it, when clicking a > file in a file manager. In ~/.xsession-errors* usually is the output, > that you get by running an app in a terminal. >
Re: [arch-general] Gedit startup issues
On Thu, 21 Apr 2016 20:05:10 -0500, Marshall Neill wrote: >Launch from the command line and see what shows up. > >Just a thought. That could help, after the issue appears when launching it by a file manager or a launcher, but not necessarily helps. The output in ~/.xsession-errors* could provide error messages from the original event, when gedit first failed by e.g. launching it, when clicking a file in a file manager. In ~/.xsession-errors* usually is the output, that you get by running an app in a terminal.
Re: [arch-general] Gedit startup issues
Launch from the command line and see what shows up. Just a thought. On 04/21/2016 05:08 PM, L. Rose wrote: Dear fellow Archers, I'm using XFCE4 on an up-to-date Arch Linux installation I've built from the official downloadable image and by following the instructions on the Arch wiki. The system works fine, but there are still some bugs I want to zap out. First thing is: Sometimes gedit won't start when launching it over the GUI. I've installed it from the package repositories by using pacman, and it works most times, but, sometimes (I can't see any pattern in when it works and when not) it just won't start from the GUI. By GUI, I mean * The XFCE-Applications Menu * By double-clicking a text file that is associated with gedit * By clicking the gedit icon I've attached to docky I've never noticed such issues when launching gedit from the GUI. Furthermore, I didn't see any error messages in dmesg or in /var/log/Xorg.0.log. When the problem appears, it often persists until the next reboot. I have no clue on how to fix it, any ideas are greatly appreciated. It's quite annoying that I can't rely on gedit... Thanks in advance, Lukas
Re: [arch-general] Gedit startup issues
On Fri, 22 Apr 2016 00:08:36 +0200, L. Rose wrote: >I've never noticed such issues when launching gedit from the GUI. >Furthermore, I didn't see any error messages in dmesg or in >/var/log/Xorg.0.log. When the problem appears, it often persists until >the next reboot. Those are unrelated log files. Take a look at ~/.xsession-errors*. Gedit seems not to use /run/user/*/dconf/user, if it would, it could be the source of issues, at least after running gedit with root privileges. Did you test pluma? Unfortunately pluma does use /run/user/*/dconf/user, but OTOH it's based on GTK2 and closer to the old gedit, than gedit is nowadays.
[arch-general] Gedit startup issues
Dear fellow Archers, I'm using XFCE4 on an up-to-date Arch Linux installation I've built from the official downloadable image and by following the instructions on the Arch wiki. The system works fine, but there are still some bugs I want to zap out. First thing is: Sometimes gedit won't start when launching it over the GUI. I've installed it from the package repositories by using pacman, and it works most times, but, sometimes (I can't see any pattern in when it works and when not) it just won't start from the GUI. By GUI, I mean * The XFCE-Applications Menu * By double-clicking a text file that is associated with gedit * By clicking the gedit icon I've attached to docky I've never noticed such issues when launching gedit from the GUI. Furthermore, I didn't see any error messages in dmesg or in /var/log/Xorg.0.log. When the problem appears, it often persists until the next reboot. I have no clue on how to fix it, any ideas are greatly appreciated. It's quite annoying that I can't rely on gedit... Thanks in advance, Lukas
Re: [arch-general] Gedit
El 15/04/2014 18:00, "Daniel Micay" escribió: > That's not at all true. KDE is going to be using server-side window > decorations with their Wayland compositor. That's true. I didn't know that. Anyway it is a KDE implementation, it's not part of Wayland Protocol. > The GTK+ header bar is based > on UX design, not anything to do with Wayland. An GTK+ application can > draw client-side decorations with or without a header bar. That's true too, but client side decoration on Wayland was the main reason to change the design guidelines. Andrés Fernandez Software Peronista
Re: [arch-general] Gedit
On 15/04/14 04:56 PM, Andres Fernandez wrote: >> Chromium defaults to drawing the title bar itself as part of the window, >> for the same space-saving reasons. GTK+ applications using the header >> bar still have window buttons too - by default a close button, but >> optionally minimize/maximize. >> >> Anyway, I'm pointing them out as the applications that popularized this >> feature, not as applications *only* providing this choice. > > The main reason for HeaderBar widget on core apps of Gnome is Wayland. This > is a protocol to develop compositors in replacement of the old and beloved > Xorg. In Wayland world there is no Windows Manager, so windows decoration > are in apps. That's the main reason. That's not at all true. KDE is going to be using server-side window decorations with their Wayland compositor. The GTK+ header bar is based on UX design, not anything to do with Wayland. An GTK+ application can draw client-side decorations with or without a header bar. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Gedit
> Chromium defaults to drawing the title bar itself as part of the window, > for the same space-saving reasons. GTK+ applications using the header > bar still have window buttons too - by default a close button, but > optionally minimize/maximize. > > Anyway, I'm pointing them out as the applications that popularized this > feature, not as applications *only* providing this choice. The main reason for HeaderBar widget on core apps of Gnome is Wayland. This is a protocol to develop compositors in replacement of the old and beloved Xorg. In Wayland world there is no Windows Manager, so windows decoration are in apps. That's the main reason.
Re: [arch-general] Gedit
On Tue, 2014-04-15 at 16:33 -0400, Daniel Micay wrote: > > Firefox provides a menu bar and a title bar with window buttons using > > the JWM theme. > > Firefox lacks support for this on Linux because it's not viewed as a > first tier platform. The menu bar will go away on Linux by default when > the new interface is released quite soon. It might not stay around as a > supported feature for much longer. I anyway dislike Firefox, regarding to it's history search options, that don't fit to my needs, so I prefer QupZilla, hopefully QupZilla doesn't follow this new design.
Re: [arch-general] Gedit
Well, you may give up gedit for Sublime Text. You will never go back. ;) -- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu
Re: [arch-general] Gedit
On 15/04/14 04:18 PM, Ralf Mardorf wrote: > On Tue, 2014-04-15 at 15:57 -0400, Daniel Micay wrote: >> You can blame Chromium/Chrome > > They still have a title bar with window buttons, Chromium even takes > care about the JWM theme I'm using. Chromium defaults to drawing the title bar itself as part of the window, for the same space-saving reasons. GTK+ applications using the header bar still have window buttons too - by default a close button, but optionally minimize/maximize. Anyway, I'm pointing them out as the applications that popularized this feature, not as applications *only* providing this choice. > Firefox provides a menu bar and a title bar with window buttons using > the JWM theme. Firefox lacks support for this on Linux because it's not viewed as a first tier platform. The menu bar will go away on Linux by default when the new interface is released quite soon. It might not stay around as a supported feature for much longer. signature.asc Description: OpenPGP digital signature
Re: [arch-general] Gedit
Am 15.04.2014 22:18, schrieb Ralf Mardorf: > > On Tue, 2014-04-15 at 16:59 -0300, Andres Fernandez wrote: >> Anyway, complaining won't change the new design guidelines, wich are >> large accepted. > > :( Well, it's a feature that gedit also lost its menubar. Mousepad, you have a new friend. -- xmpp b...@schafweide.org bjo.nord-west.org | nord-west.org
Re: [arch-general] Gedit
On Tue, 2014-04-15 at 15:57 -0400, Daniel Micay wrote: > You can blame Chromium/Chrome They still have a title bar with window buttons, Chromium even takes care about the JWM theme I'm using. > and Firefox for making this popular. Firefox provides a menu bar and a title bar with window buttons using the JWM theme. [rocketmouse@archlinux ~]$ pacman -Q chromium google-chrome firefox chromium 34.0.1847.116-1 google-chrome 34.0.1847.116-1 firefox 28.0-1 On Tue, 2014-04-15 at 16:59 -0300, Andres Fernandez wrote: > Anyway, complaining won't change the new design guidelines, wich are > large accepted. :(
Re: [arch-general] Gedit
On Tue, 2014-04-15 at 15:57 -0400, Daniel Micay wrote: > There are some window managers not implementing EWMH properly (Xfce's window > manager) and you > will get a redundant title bar on top of the header bar. I'm using JWM.
Re: [arch-general] Gedit
El 15/04/2014 16:52, "Ralf Mardorf" escribió: > > Hi, > > do I miss options for the preferences or doesn't gedit provide a menu > bar and window buttons anymore? A menu bar might be something to argue, > since it's part of the app, but the window buttons are provided by the > window manager I decided to use. Will this happen to other editors, such > as pluma and other apps too? Disgusting! It is the new design guidelines of Gnome 3. I don't think Pluma follow that design. > Doers it make sense to send a veto to upstream or is it wanted by most > users? It's wanted by most of Gnome user. Anyway, complaining won't change the new design guidelines, wich are large accepted. Andrés Fernandez Software Peronista
Re: [arch-general] Gedit
On 15/04/14 03:51 PM, Ralf Mardorf wrote: > Hi, > > do I miss options for the preferences or doesn't gedit provide a menu > bar and window buttons anymore? A menu bar might be something to argue, > since it's part of the app, but the window buttons are provided by the > window manager I decided to use. Will this happen to other editors, such > as pluma and other apps too? Disgusting! > > Doers it make sense to send a veto to upstream or is it wanted by most > users? > > Regards, > Ralf The GTK header bar widget replaces the title bar. It's possible to enable the minimize/maximize buttons for it, and it does respect whatever theme you're using. It's intended to save vertical space by making a separate menu/toolbar unnecessary. There are some window managers not implementing EWMH properly (Xfce's window manager) and you will get a redundant title bar on top of the header bar. You can blame Chromium/Chrome and Firefox for making this popular. I happen to think it's a good idea, although as a user of i3 it has little to no impact on me. signature.asc Description: OpenPGP digital signature
[arch-general] Gedit
Hi, do I miss options for the preferences or doesn't gedit provide a menu bar and window buttons anymore? A menu bar might be something to argue, since it's part of the app, but the window buttons are provided by the window manager I decided to use. Will this happen to other editors, such as pluma and other apps too? Disgusting! Doers it make sense to send a veto to upstream or is it wanted by most users? Regards, Ralf
