Thu, 28 May 2015
Once upon a time, there was a windowing system called X. There were lots of applications for X written using various widget toolkits. In order to make the window operations unified across the whole desktop, regardless of the widget toolkit used by a particular application, the special application, called "window manager" provided window title bars and borders. Applications could inform the window manager about their particular needs (for example, their minimum required window size, etc.) using an open protocol called ICCCM. Not anymore.
Nowadays, GNOME developers decided that the only way to use their system and their applications is to have the complete desktop including all running apps GNOME-based. Being able to run GNOME apps under other desktop environments and vice versa is sooo last century way of desktop computing. From now on, all GNOME applications inform the window manager using ICCCM, that their windows are not to be touched by the WM. These windows then do not have window borders for resizing, raising/lowering/etc., they have their own title bar and maximize/minimize/close buttons different to the rest of the desktop, etc.
OK, after ditching GNOME desktop environment when GNOME 3.0 came out, it is time to ditch also the GNOME applications, as they are clearly not intended to run under the standard desktop environment. So far I have replaced the following applications:
- This means installing lots of KDE libraries, but on the other hand Okular
does not take
over the screen on startup (unfixed since at least 2008), it can zoom to the
arbitrary size (CLOSED WONTFIX, really?), when I run "
okular somefile.pdf" twice, I get two windows as expected, etc.
- Not that I use the GUI file manager often, but still.
gthumbwith (undecided yet)
- I am still not sure about the replacement - so far I am testing
geeqieand some others.
There is a nice list of recommended applications for XFCE, which are written in GTK, but positively GNOME-free. Which image viewer and PDF viewer do you use, my dear lazyweb?
Fri, 19 Dec 2014
After getting a new mainboard, I have upgraded my home computer to Fedora 20, and made my multiseat setup use the udev/logind/loginctl seat tags. About a month ago I have discovered that the seat numbers are not correctly assigned to sessions by xdm(8), so I started to look for solutions. Of course, that piece of crap called gdm was not even been considered for obvious reasons. Apparently the solution does exist, and suprisingly enough, it is really nice: it is called LightDM.
LightDM is the display manager. It has cleanly separated the display manager part (starting up the X servers, listening on XDMCP, etc.), and the user interface part (chooser). The later can be selected from various options - e.g. a KDE/Qt compatible one, and a GTK+ compatible one. The configuration is pretty straigthforward, and it does not try to hide anything from the user, unlike the above mentioned piece of crap.
The multiseat setup in LightDM is pretty straightforward: in /etc/ligthdm/lightdm.conf I have to add the following:
[Seat:0] xdg-seat=seat0 xserver-command=X -layout Primary -isolateDevice PCI:0:2:0 -seat seat0 vt7 [Seat:1] xdg-seat=seat1 xserver-command=X -layout Secondary -isolateDevice PCI:1:0:0 -seat seat1 -sharevts vt7
In the udev tags, I had to tag the following device as belonging to Seat1 (using loginctl(8)):
- The DRM device of the graphics card (.../drm/card1)
- The FB device of the graphics card (.../graphics/fb1)
- The sound card ports (.../sound/card1/inputXX)
- The USB port for the mouse (.../usb5/5-1)
- The USB port for the keyboard (.../usb5/5-2)
And that's it! The only (minor) nitpick is, that the GTK+ greeter does not remember the last logged-in user per seat, so it preselects the last logged in user on both seats by default. But we usually log in only after the reboot, so it is not a big problem.
Mon, 09 Jun 2014
Politically Correct Media Players
Hello, welcome to today's issue of your favourite "Bashing the Questionable Fedora Desktop Decisions" series. Today, we will have a look at the politically correct media players.
In a civilized world, there is no place for such insane things like software patents. Unfortunately, there are less free parts of the world, which includes the United States of America. So the companies originating in the U.S. are forced to do absurd decisions like shipping audio players which really cannot play most of the audio files out there (which are, unfortunately, stored in the inferior MP3 format), or video players which cannot play almost any video (which can be encoded in wide variety formats, almost all encumbered by software patents).
For Fedora, the clean solution would be to have a package repository outside
the U.S. jurisdiction, and offer it as a part of Fedora by default.
Such a repository already exists at
and it provides everything needed to play audio and video in free parts
of the world. But it is not as promoted as it should be in free parts
of the world. However, Fedora does something different: they ship empty shells
of audio and video players, such as Pragha or Totem, which in fact cannot
play most of the audio and video files. The problem is, that these applications
shamelessly register themselves as the handlers of
video/h264, and similar MIME types. Only after the media file
is handed to them, they start to complain that they don't have an appropriate
Hey, Fedora desktop maintainers, stop pretending that the US-based Fedora desktops can handle MP3 and H.264 files, and admit that your inferior but not U.S. software-patent encumbered players cannot handle these files by default. It would be fair to your users. Fedora users: is there anybody who really uses Totem instead of VLC or Mplayer?
Fri, 24 May 2013
The last file manager I have used was Norton Commander back in the DOS era. Many years after that, during the flame wars between proponents of spatial and single-windowed Nautilus, I have only laughed at them, thinking that the command line was much better. Why would anybody need a GUI file manager? I feel slightly ashamed now, but I have to admit that for the last two weeks, I have also been using a GUI file manager.
I work on various things with respect to cabling, electricity, a new datacenter, and so on in the new building of Faculty of Informatics. The problem with the building specifications, projects, and so on is, that they are stored in the deep structure of directories, with names containing whitespace and even non-ASCII characters (in different character sets), and each directory contains many files or subdirectories with common prefixes shared by a set of files. So the usual tab-completion does not help - it is necessary to actually look at the completion prefix in order to know what character to add next. Here is an example of such a file name, starting from my automount point:
stavba_cerit_dok/01_ZADAVACI_DOK/02_zadavaci_projektova_dokumentace/\ FIMU_GD_SOD_příloha č. 1/!!!_02_FIMU_GD_SoD_Priloha_1_II.A_PD_DVD_PROJEKTOVA_DOK_1.etapa!!!/\ FI_F.3_03_PS 03 SUPERPOCITAC, DATOVE CENTRUM_DVD/\ F.3_03_5 SLABOPROUDE ROZVODY_DVD/F.3_03_5.2.01_PUDORYS 5NP - SLABOPROUD.pdf
In order to be able to quickly navigate inside such directory tree, I have started to use a GUI file manager. So far I use Thunar, the default file manager in XFCE. It can easily switch to any directory along the current path, and it has bookmarks for fast access to frequently-used directories. I use this feature a lot, because of the main drawback of GUI file managers: It is not possible to descend into a directory, which is an automount point (and which, from the VFS point of view, does not exist yet).
Do you use a GUI file manager?
Mon, 12 Nov 2012
Desktop Environment-Specific Apps
I have recently came across this two years old bug report, filled to the bug tracker of Transmission (a Bittorrent client) where a GNOME developer suggests removal of the notification area icon from the application on the basis that GNOME 3 does not support notification area at all.
So if I understand it correctly, we are now living in a world where all the GUI applications have to be dependent on the particular desktop environment, and it should be no longer supported to run - say - Transmission under XFCE, or GIMP under KDE, at least according to GNOME developers. "We GNOMErs do not support notification area icons, so this application should not use it" (even though the application is not used exclusively under GNOME)? Where are the freedesktop.org cross-DE interoperability recommendations?
That said, notification area as such sucks - what I liked most was the original approach of X11: using on-desktop icons for minimized applications (instead of applications and documents shortcuts), and applications displaying their own status in their icon (handled by every window manager using the same ICCCM specification).
Mon, 23 May 2011
Lost GUI features
Contemporary GUI applications have several problems which, if I remember correctly, previous systems did not have. I wonder whether somebody else also considers it being a problem:
- Creating a new file
- Almost every TUI text editor (like
vim) happily accepts a non-existent file
as a command-line argument, and the straightforward interpretation is
"user wants to start working with a new file". On the other hand,
most GUI applications simply complain that the file does not exist,
and some‒like OO.org‒exit after that
message. Other GUI apps,
like Gnumeric, present
a warning, but then open a new work with the default file name
Book1.gnumericin the case of Gnumeric) instead.
- Working directory
- The file open/save dialog of contemporary GUI apps does not offer
by default the working directory from which the application has been started,
and uses some silly default (such as
~/Documentsin case of OpenOffice.org). Even gThumb needs to be explicitly told that the user wants to browse the current directory with the "
gthumb ." command line.
- Iconified applications
- Once upon a time, in a stone age of GUI computing, there was a twm window manager. When the application window was not needed on the screen, twm could be used to iconify the application. All applications, and all instances of them, could be iconified and then restored back the same way. Then Windows 95 happened, and it started to minimize the applications to the bottom panel instead of iconifying them to any place in the desktop. It also reused the desktop icons as application shortcuts instead of representing the minimized running applications. Unfortunately, the panel was too small for so many running minimized applications. Users stopped expecting to be able to restore the application after minimizing it. The applications which required to be minimized and restored back frequently (music players etc), developed their own means of minimizing, the notification icon area. So we have the iconification back, only not usable from all applications, and with each application implementing it in its own crappy way.
So what other important features of the "desktop of the past" do you consider missing from the present GUI systems?
Update - Mon, 23 May 2011: Iconified Apps
I have just discovered that XFCE4 in Fedora 15 allows the desktop icons to be switched between the Application launchers/shortcuts and Minimzed applications modes. Yay!
Fri, 20 May 2011
After installing Fedora 15 in a virtual machine, I have decided to give GNOME 3 a try. Firstly, it is really slow over VNC. While GNOME 2 has been pretty usable for testing various new applications in a virtual machine, under GNOME 3 it is almost impossible. Here is a screenshot on which I will demonstrate my problems with GNOME 3:
Firstly about the file manager. I use mostly command line for managing
my files, but using a file manager is sometimes handy nevertheless. One
of the features I often use is the "Places" list. In GNOME 3, it is presented
differently in the Places menu and in the file manager itself, which
is a clear usability bug. When I wanted to add another directory there
(I often use
~/tmp as my sandbox),
it took me at least 10 minutes to discover
that "Bookmarks" is what I probably want. And even then, the newly added
bookmark is added to a submenu instead of the main Places menu.
Also, I did not found any way how to remove those useless predefined
from the left sidebar. Even when I have deleted them from my home directory,
they still remain in the sidebar.
Another ugliness is that the new window manager does not decorate the windows properly, and instead relies on the applications themselves to provide things like resizing handle in the lower right corner (see the gnome-terminal window). Not only it looks ugly as hell, it also obscures the space the application expects to be visible. I will probably file this as a bug report when F15 is officially released, but I expect in a truly GNOME-ish fasion it to be solved by removing the "scrollbar on the left side" option :-/.
Anyway, it seems that XFCE+Sawfish combo works as expected, so I am definitely leaving GNOME when I install F15 on my workstations.
Wed, 23 Mar 2011
The first alternative to GNOME I have decided to try is XFCE. In the LWN discussion, Jon Masters presented it as a viable replacement to GNOME. Also, it uses GTK+ like GNOME, so many applications can be the same (including, I have hoped, my window manager of choice, Sawfish. XFCE is definitely usable and configurable for power-user. Most (but not all) properties can also be set using their Settings manager, and thus XFCE should also be mostly usable for ordinary users. So far the problems include:
- The keyboard configuration allows the user to set multiple layouts (for
example English and Czech/qwerty), but I did not find how to set layout
options, for example the layout switching hot-key. Adding a
setxkbmapcommand to the startup script is trivial, though (#5487).
- The touchpad settings such as edge scrolling are not remembered
and cannot be set in the Settings manager. The solution is another startup
synclientwith the appropriate parameters (#5300).
- The window manager cannot be chosen in a GUI. I had to remove the
xfwm4from the session and add Sawfish there instead (that said, I have nothing special against the default WM, I am just more used to Sawfish right now).
- The Terminal application does not have
Ctrl -hotkeys for increasing/decreasing the font size (I sometimes use it, for example when more than one person is looking at the window). When the font size is set in the terminal menu, the physical window size remains the same, which means the number of rows and columns changes. Not good. I have solved this by choosing
gnome-terminalin Preferred applications (#5605).
- Moving applets inside a panel is not intuitive, and I have not found out yet how to reorder the launchers on a panel (#7142).
- Changing the orientation of a panel to vertical requires several non-trivial configuration steps. However, I have managed to configure the date/time applet (the only text applet on my panel) to fit a 48 pixels wide vertical panel, and I will probably keep the vertical panel orientation, as for most apps, the screen is more crowded in the horizontal direction (#7434).
XFCE is tightly related to both GTK+ and GNOME, and can incorporate various parts of GNOME (some notification area applets, keyring manager, etc). So I guess I would be able to use it as a replacement, if not for the whole GNOME, then at least for the central parts like GNOME Shell.
Tue, 22 Mar 2011
GNOME in the Shell
Yesterday, after reading The Grumpy Editor's GNOME 3 experience article at LWN, I have decided it is time to at least make an attempt to move away from GNOME, which (much like KDE 4) decided to use revolutionary instead of evolutionary development, and apparently continues in their feature removal crusade in the name of so called usability. Also, this might be a good chance to move away from Galeon after so many years.
I wonder what makes the GNOME developers think the existing users would
welcome a completely new desktop with very limited means of customization.
GNOME 2 has only recently reached a moderate level of usability (except
gdm, which is still not usable for many purposes since the
It would be very sad to move away from GNOME, because I think I am not a typical conservative user, and I welcome occasional new features, provided they do not hurt productivity and power-user usability. However, apparently GNOME Shell provides neither, and the so called fallback mode is not complete enough (virtual desktops in a single row, seriously?). Also I would rather use the same desktop envionment as some non-computer-savvy users to which I occasionally provide technical support.
So I have decided to experiment a bit on my laptop, but keep GNOME and Galeon both on my home and work workstations for now. More on it in a few days.
Note: I am sorry, the above mentioned LWN article is subscribers-only for now. It will become freely available in several days. Alternatively, you can ask me for a link in a private e-mail.
Wed, 18 Nov 2009
The GDM Fiasco
A short trip to the history: for GNOME 2.22 (two years ago, in the Fedora 9 timeframe) someone decided that it would be nice to completely rewrite the GNOME display manager. So far so good, but they have decided to include this partially rewritten piece of crap without many important features (a display manager without XDMCP, WTF?) to the official GNOME and thus Fedora releases.
Fast forward to the present time: basically, for two years, GDM has not been usable for anything beyond a single-user desktop (I use xdm on my home dual-seat desktop, and we have replaced Fedora altogether in some of our computer labs partly because of GDM).
- It did not handle XDMCP (at least this one got fixed).
- There is still no way of setting the X server command line, making GDM unusable in multiseat configurations.
- It cannot be configured as XDMCP-only daemon without starting the local X server.
- The login window cannot be configured, and the way it works it is usable on a personal desktop, but definitely not in a computer lab with ~2200 accounts and users logging in on random hosts.
Apparently, somebody has started to work on solving at least some of the problems after all. But guess what? Instead of backing off quickly (say, before the Fedora 10 has been released), Fedora maintainers has ignored the problem despite many polite and even some profane requests to provide an upgrade to the latest working version (i.e. the Fedora 8 one). And now the answer is "wait for Fedora 13 (another half a year), we are probably going to fix it there". Without any hint of being sorry for forcing an utterly broken package to the users for two years and counting.
Tue, 31 Mar 2009
Is Ekiga Doomed?
I am more-or-less happy user of ekiga. However, with the latest GNOME release (or two), I am not sure about its future. The new GNOME contains a new instant messaging and voice-over-IP application, Empathy.
I have not tested Empathy yet, but the list of supported protocols look impressive. I wonder how complete this support is, however (like GPG in Jabber/XMPP, SIP call redirection, SIP from behind of NAT using STUN or proxy, etc). I am trying hard not to be a skeptic, but maybe ekiga will join the following list of doomed applications:
- GDM 2.1x
- The rewrite of GDM in Fedora 8 (not sure about version numbers now) took away most of the options (such as the X server command line, automatic login for single-user systems, XDMCP(!)), most of the features are not restored even now, year and half later.
- It has been deprecated in favor of Metacity, which still cannot do such a simple thing like sending a window to the different workspace using
Ctrl+Alt+Rightand return back by releasing both
Right, and pressing the
Leftkey while still holding the
Ctrlkey. Metacity still requires the
Ctrlkey to be released first.
- Has been deprecated in favor of Epiphany, which still plays catch up
with Galeon feature set (even with its
epiphany-extensionspackage, and despite of the fact the development of Galeon has been dormant for several years now).
I could probably name several other projects. May be this is a trend in GNOME: replace the existing full-featured apps with half-retarded new ones, just because you do not agree with architectural decisions of previous developers, or because (in the GDM case) you need one more feature (fast user switching) which is hard to do in the present code base. And then promise to implement all other features users are used to, and fail to fulfill the promise in several years. In the meantime, get your code merged to the GNOME code base, kicking the previous full-featured application out of it, making the life of its developers harder, and thus cause the development of it to slowly die off.
Mon, 30 Mar 2009
Firefox File Input
The daily user-interface annoyance award herby goes to the Firefox (or rather XULRunner,
which means this is present also in Galeon). The problem is in forms
<input type="file"> fields. It looks like this:
In Firefox and Galeon, it is impossible to write directly to this field. Which means that even if I already know the file name and can type it really fast, I have to click to the input field, wait for the file input dialog to pop up and get focus, and only then I can type the text in.
Is it possible to disable the pop-up (or make it appear only after clicking
Wed, 28 May 2008
Browsers: Back to Square One
On Oct 15, 2005 i wrote about Galeon development slowing down, and I speculated that I would have needed to choose a new browser. With recent problems of Galeon in Fedora 9, I have decided to look at the current state of browsers again.
Firstly, Firefox: it is not a bad browser, the Firefox 3.0beta in Fedora 9 even feels much faster than Galeon. With some essential extensions it is almost usable: TreeStyleTab allows to have tabs vertically on the right side, and NewTabURL allows something other than a blank page to be displayed in newly opened tabs (I wonder why these two features are not included in the Firefox itself). FireGestures are even better than in Galeon: more configurable (not that I need that), but also the plugin displays the gesture. It also does not have a long-standing Galeon bug, where gestures do not work over an empty tab.
Now the bad part: I need a "middle button pastes the URL in new tab" functionality. It is much faster to have it on one click instead of having to open new tab manually beforehand. Another problem is that newly opened tabs do not inherit parent's history, so you cannot do Back in them. There is no way how to create a "smart bookmarks" toolbar (i.e. bookmarks with a wildcard in their URL, which are then displayed as input boxes). In Galeon, it is very convenient to have things like dictionaries, IS MU people search, Wikipedia, etc., each with separate input box. Moreover, in Galeon you can open the search results in a new tab by pressing Ctrl+Enter instead of Enter. The Firefox search inputbox is really a bad joke: the text entered there remains there, for example. So when you want to look up a new dictionary word, instead of just pasting it there you have to clear the previous search contents. Sometimes the NewTabURL stops working, so after opening a new tab I wait whether my home page gets loaded or not. Unread tabs are not displayed in a different color in the tab list. And finally, there is this bug, which makes saving and restoring session with multiple authenticated tabs next to impossible. Reported almost two years ago, and still unfixed.
As for Epiphany, it is a bit better: smart bookmarks are there, there is an extension for moving tabs to the right side (left side actually, but it can be trivially modified for the right side; I wonder why this is not in the main distribution - having two line Python plugin instead of a configuration option is really ugly). However, the gestures use a middle mouse button, and it clashes with possible future "paste URL in the new tab" functionality. Also the cookie manager is not as flexible as in Galeon and Firefox.
So after much experimenting and testing, actually using both Firefox and Epiphany for several days, I have decided to downgrade Galeon in my Fedora 9 to the one from Fedora 8, and I am back to square one. Galeon is still the best browser available, despite being in pure maintainance mode for two years. Both Firefox and Epiphany are getting better, but they still lack some functionality, not to mention having real bugs.
Fri, 07 Dec 2007
Ekiga, PulseAudio, and D-Bus
It seems that more and more applications start using D-Bus for communication, so it is time to get ones feet wet with the D-Bus programming. Fedora 8 has PulseAudio enabled by default, which conflicts with Ekiga because of this ALSA bug (see also the related PulseAudio issue).
My solution is to suspend the PulseAudio server temporarily when the call is being made. This has an additional effect that you don't need to find where the music player window is hidden in order to mute it (so something similar would be usable even later, after the above two issues are fixed).
Anyway, here is my Ekiga PulseAudio suspender.
Written in Perl, needs
Net::DBus from CPAN,
Run it on background from your session startup script (or even from the
terminal inside your desktop session). It will mute your PulseAudio server when the call is being received (or when an outgoing
call is being made), and enables it back after the call is finished.
Comments are welcome.
Tue, 06 Nov 2007
I have installed Fedora 8 on my
workstation. Everything works as expected, except the multihead support.
I am getting the "
Requested Entity already in use!" error message.
The problem is that my
xorg.conf uses two separate screens,
instead of one screen merged by XRandR extension (which is
the preferred way of doing dual-head now).
While not a bad thing per se, XRandR seems to be unusable for my dual head setup: I want the workspace switcher work separately for each head. With XRandR, there is only one big virtual screen area, so the workspace switcher switches both heads at once.
I think XRandR would be useful for my laptop which has 16:10 screen, so the aspect ratio for the external beamer would be different. Also, it could allow to see the lecture notes together with slides when doing a presentation. Here is a little RandR dualhead howto.
My dear lazyweb, does anybody know how to do a multi-screen setup (as opposed to one virtual screen area) in XRandR? For now, I have downgraded to the Fedora 7 version of the ATI driver, which works the way I want. Bug reported as #368531.