During the past week, I (along with Alex Băluț) obtained commit access to the main Pitivi branch.
This is a very good thing. Two more community members being able to merge contributions means that:
- We are raising the bus factor
- We will hopefully be able to meet our new goal of “reviewing every patch within three weeks” and move faster.
I have a couple of interesting things in the cooker, but won’t be blogging about them just yet. Instead, let me tell you about a small usability improvement that might provide some inspiration to others.
See, I hate scrolling. Unless it’s absolutely necessary and the dialog is bigger than my screen’s height or you expect to tile windows vertically, as an application developer you should avoid scrolling when possible.
- The “correct” way is to size the dialog automatically depending on the contents and to use a the available screen space (instead of showing a tiny window).
- What I found out through experimentation is that setting the “default size” of a window to be greater than the available space on the screen works 100% fine with most (if not all?) window managers. What this means is that if you expect the user to scroll a long document, you might as well set its default height to 1200 pixels or something: if the screen is only 600 pixels tall, the window manager will size it down.
- In Python with GTK+, that’s the set_default_size method, right before you actually show the window (not to be confused with the set_size_request or resize methods).
See also MPT’s lightning talk on common interface bloopers (in which Pitivi was cited as the prime example of “bad default size” back then).
Most of pitivi’s dialogs are home-made with a reasonable set of expectations regarding size: we know in advance the size of the main rendering dialog’s window, for instance. Ok. That’s easy. No problem here.
The problem is that some of pitivi’s dialogs use dynamic/autogenerated content. The advanced codecs settings dialog is one of them. Since the amount of stuff that is shown in that dialog is highly variable depending on what codec the user wants to configure and yet you can’t be sure that it will all fit on the screen, you end up with failsauce like this:
Yes. This is how it looked like for the Vorbis codec. Until now, that is:
As you can see in this commit, I implemented a naïve approach to detect the “height” of the vbox containing the actual contents (once they have been generated), and then, if the size makes sense (or if we have a lot of available screen height), size up the dialog so that this fits neatly. If there is a much better way to do this, patches are welcome!
Since it fits neatly in most cases, then we can get rid of the scrollbar and border around the contents. We end up with a dialog that feels less like an afterthought.
Do you have dialogs in your application that have a bad default size? Sometimes, remembering their size is not the answer. Save your users some strain and put that 1920×1200 monitor to good use!