Quick and Dirty Hacks

I’ve been asked to make it clear that this does not in any way reflect the belief of Nokia. I’m just adding mine where others have added theirs… Also some of this will bleed over into parts of the GNOME 3.0 discussion so please don’t shout at me for things going out of the toolkit scope.

Important points about the current plan

• Killing the dead weight – deprecated code needs to get out of there once and for all.
• Removing access to what should be private structures
• Easily bound
• Easier to extend
• Easier to develop with
  

Now down to the nitty gritty of it…

GTK+ for the most part has served us all very, very well over the years, we’ve failed to gain any real improvements in it because of maintaining legacy compatibility. We’ve also stagnated^[1] a little with this toolkit, and this has created the need for things like libsexy to be built in order to fill a gap. I’m not saying supplementary widgets are a bad thing, but when some of them have been implemented so many different times all over the place it pains me to watch.

Now we need to make sure that this time we can continue to not break the API/ABI for a good number of years, however there doesn’t appear to be any statement to the public about how long this will last. I think there needs to be clarity as to how long this toolkit will maintain API/ABI compatibility this is to ensure that developers in the closed source world which use GTK+ can have confidence that they will not be required to put in effort above and beyond because we decide to change it again in a years time because mistakes were made. I think it would be fair to say 8 years without API/ABI breakage, this would be quite appropriate as we’re expecting around 8 years from 2.x. We also need to make sure that if we do make a statement about how long, that we don’t paint ourselves into a corner until that day comes.

The next thing we must be very clear on is how we’re going to ensure that we don’t end up loosing traction to other toolkits. In order to achieve this we must think carefully about some very important things, from my perspective^[2] we need to be clever about some very crucial points.

• User Interface

• Parental/Heirarchical styling - I want widgets which can inherit a certain look from their parent or parents, for instance I want one button, if I put that button in a toolbar it should be a toolbar button. I see no point in having a GtkToolbarButton, and a GtkButton! They behave in the same way in real terms. This is one of the main advantages of using CSS for styling. Styles defined on a per object basis, or inherited from the parent, or inherited from the parent for a specific type of child.
• Custom styling – Sometimes I would like to customise a style, for instance changing the background colour of a widget and have all the child widgets inherit that colouring. Or completely change the look of my application without changing the code that powers it or having to reinvent everything from scratch^[3] just to fit my UI design concept. Doing this by applying local themes/styles which are identical to the code used in the CSS for our overall theme engines.
• Access to the colour palette in a logical way – When working on system monitor I found I could only get the colour of the background for a notebook from the notebook widget. Why isn’t there a global colour palette which can be accessed from anywhere. Integrating cairo can be made much simpler with this functionality.
• Full scalability – Building a toolkit in this age should always consider and be very concerned with scaling, DPI is increasing, and we need the UI to be smooth, also from an accessibility point of view its important that when I have a high DPI screen with a certain physical size it can look the same^[4] as a lower DPI screen of the same physical size. My best example of this was Rob Taylors new laptop which has an awesome DPI but the text can be difficult to read as a result.
• Polymorphism – Widgets should be dynamic in their appearance to stop the user interface being boring. I don’t mean animated, I mean like Seth Nickell was musing about on his blog back in 2005 which he called dynamic themes.
• Putting widgets wherever you like – I’ve had it mentioned to me in the past that putting some widgets in some places is hard. For instance putting a button in a treeview. This is not outside of the realm of possibility but these kinds of things could and should be easier.
• Flowing, not boxed in – I’ve seen some great designs come up for having nautilus select files as if they were a continuous selection, and the same thing happening in various other UI designs. Button bars for instance should be a continuous bar of buttons rather than just tightly packed buttons.
• Borders, alignments and spacing – in the future I don’t even want to care about aligning my widgets, setting borders and spacing so they’re positioned not too close to each other but not too far away. I want the widgets to know how this should be done globally from the theme. I want all my applications to look more or less the same. Specifying good practice rules in the HIG is one thing, but taking the option away from the developer for disobeying the HIG might be drastic, but it is also sensible. There should be some options regarding how it works but for the most part it should be automatic, and with a heirarchy of styles it should also be possible.
• Canvasing – Cairo does some of it, Clutter does some more, WebKit does different things but similar in lots of ways. It is important to consider that we need to be able to treat items on a canvas as objects, and we also need to think in terms of there is no difference between paper and screen on a canvas. I should be able to send a GtkCanvas(?) to a printing API and have it print as it is on screen, cairo already considers this, but clutter doesn’t (AFAIK). There needs to be some middle ground.
• The Bling – We should have alpha which can be applied to windows and widgets etc… but we should make this part of the framework on which we are drawing, it should be exposed to the theme engines and style sheets as well as exposed in the individual widgets via custom styling. In a similar way we need to keep in mind a framework for how animations can be performed, a universal governer of time so animations don’t step out of time with each other desktop wide as it can make me a little sea sick. We need to consider whether or not GDK is the right tool to be doing all of our widgeting on top of, and maybe write something lying under GTK+ which has the power to take us forward for another 10 years.
• Interface Description Language – Microsoft did this with the Windows Presentation Foundation and Extensible Application Markup Language. We do need something like this, however we shouldn’t be designing our logic into the IDL, we need to think about where the IDL is meaningful and what benefits it provides to the developer, it should never be the focus of our developments but yet another tool to assist us into the future.

• User Experience

• Animations which mean something – It sometimes excites and sometimes amuses me looking at some of the things that have made it into compiz, for instance my windows can fold up like a paper aeroplane and zip off to the corner of the screen. This would be cool for sending and email, but a bit dumb for closing an error dialog. If we’re going to animate the toolkit we need to think about how, when, where and why. We can’t just animate things for the sake of being animated. Animated pathbars are a good example of things making sense, as are animated progress bars.^[5]
• Sounds – Sounds are a good indicator of things happening and what’s happening. Subtle sounds on the desktop are important keys to what’s going on now, when I say sounds I don’t mean everywhere for the sake of having them^[6] I mean in appropriate places appropriate times, good quality, very subtle and using them as hints rather than features. Is this a toolkit item? Maybe and maybe not, its definitely a desktop item and maybe there are important places in the toolkit for this to be hooked into.
• The computer as a tool, not a machine – A screwdriver is pretty easy to use, but a train is quite hard to drive. Knowing how to interact with a widget should not be a prerequisite to using a widget, in the same way knowing how to use the desktop should not be a prerequisite to using the desktop. It should always be a natural interaction with widgets, applications and tools.
• Touchy feely – The toolkit needs to be aware of when a touch screen is being used and when a mouse is being used, or when a pen or stylus is being used on a screen or when its being used on a tablet… These different methods of interaction have very subtle differences and these differences need to be considered from the ground up in the toolkit, rather than adapted in as afterthoughts.
• Paying attention to what has been said before – There are some great papers that have been written for a long time, for instance “A comparison of selection time from walking and pull down menus” these existing papers, and concepts like Fitts’ law and Hick-Hyman law need to be taken into account at all times. For instance our child menus still align down from the parent menu item, when it is more logical to have them aligned centrally. Moreover it is important for developers to exploit this and have the items not frequently used above the cursor entry position and the frequently used items below the cursor entry position. In a flash developers can halve the time it takes to access menu items, for the most important features, as long as the toolkit implements this.

The upshot

We need to think about canvas widgets, we need to think about scene graphs, we need to think about interface description languages, we need to think about themes and animations and most of all we need to think about these things long and hard before we begin with GTK+ 3.0, and we can’t simply put it off until 3.2 or 3.4 or 3.6 and definitely not until 4.0. I agree that 3.0 is overdue and in my opinion the approach that has been delivered is an approach that I’m not completely convinced with, especially after talking with a bunch of people about it and hearing their concerns. Building the future is not as simple as deprecating the past, we need to innovate, be stylish and be prepared for how the landscape of competitors will change in the future.

The delayed text…

1. I feel using the word decadance is incorrect, stagnation is more appropriate, both gramatically and descriptively.
2. And lets be very clear this is my perspective and nobody else’s.
3. Banshee I’m looking at you!
4. And should always by default.
5. If it stops there must be something wrong.
6. Why does internet explorer insist on making the same sound as a mouse click when I click a link?