It’s a bit old now, but Hylke Bons posted a great wrap up on elegance in software user interface design, and some big problems that application designers in the Gnome community need to work on fixing. Things like multiple borders when only one is needed, redundant labelling, lack of whitespace and so on. Gnome does look pretty good (especially when you change the fonts) but there are still a lot of things that could be improved.
Archive for the ‘Linux’ Category
Gnome Global Menu
Posted on Friday, July 31st, 2009
I recently blogged about integrating menus in an X11 window manager’s window borders, and I assumed that this would require quite a lot of changes to both GTK+ and the window manager, with an API to communicate between them, but it seems that it may be far simpler than that. I came across a project called gnome-globalmenu which takes window borders out of applications and places them in the panel, without any changes to the applications. Using a similar method, the window border could grab the menus, and then a transparent theme could used to blend in toolbars, tabs, scrollbars and so on like in my other post on the topic, if the theme so wanted.
The only problems is that it seems to work with GTK applications, so KDE and other toolkit applications, as well as applications like Firefox and Wine which draw their own menus wouldn’t be able to integrate. In this case, and for windows with no menus, a normal sized window border could just be used.
Extending the application/window manager integration
Posted on Monday, July 20th, 2009
After my post suggesting that we should have an API that window managers can provide to integrate menus with the window borders, I thought I’d take it a little further and make a mock-up of what Firefox could look like with a the menus, toolbar and tab bar integrated into a black glass like window border theme:
Here’s what I think Firefox could look like (Click for full size)
Fairly nice, I think. Given the greater flexibility, it could also allow people to create themes that look like Mac OS X, Vista (if you’re into that kind of thing) or anything else. Take the Mac OS unified window look for instance – it would be very difficult to create it with current theming systems:
With the ability for a window manager to manage the menus and toolbars, this would be possible.
On window managers and menus
Posted on Sunday, July 19th, 2009
There’s been a lot of talk on the future of the Gnome project’s default window manager, Metacity, such as using CSS to design window border themes and giving applications the ability to extend the window menu. But I think that we could go one step further than just the little window menu – as suggested by the Tango project, maybe we could move all the menus into the window border. Obviously this would require changes to the window manager, to GTK, and probably even the applications that use it. Still, it would have a lot of advantages:
- The changes to GTK could make integrating GTK apps with systems like Mac OS X much easier – if the menus were not embedded in the layout of the application, they would not require a library like ige_mac_integration – just changes to the Mac OS backend.
- Furthermore, if somebody was interested in making a window manager that had a menu system like Mac OS X, it would be far easier to implement with a system like this.
- The window’s icon could be made bigger, which looks better – you can hardly fit any detail in 16×16 pixel icons.
A mock-up I made of an integrated menu.
I don’t really know much about the internals of X11 window managers, but I expect the process would have to be something like the following: On loading a GTK application, the toolkit would have to query the window manager to see if it supported menus. If it did (and was running a compatible window border theme), GTK would pass it the menus (through the UIManager XML format or something) and it would render them. If the window manager or theme was not supported, they would just be drawn by GTK as they are now.
One difficulty might be sending events back to the application from the window manager. Another could be the difficulties of handling multiple windows with menus on a universal menu bar system such as Mac OS X.
Anyway, it was just an idea that, if possible, could really improve the look and feel of user interfaces, among other benefits.
Move Window
Posted on Monday, August 18th, 2008
I recently bought a new graphics card for my computer. It’s a Nvidia GeForce 9600GT with 512 MB of memory. Here’s what it looks like:
Now, seeing that this card was pretty recent, it wasn’t supported by the graphics driver that shipped with Ubuntu 8.04. Now, I did try to update the driver manually using the driver from the Nvidia website, and it’s times like those when you really appreciate the drivers in the repositories. To put it one way, it didn’t really work. Whereas I had a kind-of-working desktop beforehand, now I was working in a resolution of 800×600, which didn’t look great on my 22 inch screen. So, I did what it seems I always end up doing – upgrading to an untested, unstable early alpha of Ubuntu!
Now, I have to say that it was actually pretty smooth. The update worked first time, and then I was able to just grab the driver for my card from Synaptic. Sure, a whole host of programs crash from time to time, but compared to my other experiences, I had a pretty stable system.
(more…)
Kernel Based modesetting in Linux
Posted on Sunday, April 20th, 2008
This is an interesting new feature coming soon to X.org and the Linux kernel – it’s basically moving a video card’s mode setting code (which makes the card change resolutions and so on) out of the user-mode video driver, and into the kernel. It probably doesn’t sound exciting, but it will lead to a much nicer user experience. For example, it helps to make the boot process more flicker free, and will make suspend and hibernation much more reliable.
It also makes switching from X to a virtual terminal much, much faster. There are some videos in the article demonstrating it, but since this is not planned for release until the end of the year, it is still fairly buggy and unreliable.
Development system dead
Posted on Thursday, March 13th, 2008
Ah, the joys of running a pre-release operating system. I was doing my usual daily update on my Ubuntu Hardy system (the computer I use most of the time), and one of the updates failed to install, saying something about a dependancy not being installed. So, I tried to open Synaptic to sort it out, but it didn’t want to open. I thought that a reboot was in order, but when the computer turned on, it just stopped part way through the boot process. I tried to log into a terminal, but it wouldn’t work. So I then tried the recovery mode, and a few other kernel versions that I had installed.
No luck… It seems that the system is completely hosed, so I’ll have to install it all over again… At least I have my home folder on another partition, so I should keep all my settings. But still, having to install the OS and all the programs that aren’t included by default is very irritating.
I’ll try to pull some projects onto a USB drive – at least it will be a good opportunity to compile them for Windows.
Eclipse… In 3D?
Posted on Tuesday, March 11th, 2008
I’ve been working on Eclipse a lot lately. I’ve changed the build system, and also vastly improved the menu system. So, I was thinking that since I’m spending so much time and effort making the game, I might as well make as cool as I can. So, I thought that instead of just making it 2D, I could do a top down 3D view instead. I’m already using OpenGL, so it shouldn’t take that much work to change the current code to 3D. It would make it easier to use particle effects too, so I could have cool looking explosions, and a better looking flame from the ship’s engine.
First, I would have to see if there are any file formats for storing 3D models that would be easy enough to implement. Then, I’d probably set the projection mode to a perspective view (instead of the orthographic view I use now), and get the coordinate system set up the same way as it is now. Then, all I’d have to do is to make a 3D version of the sprite class, and I could program it the same way I am now.
I have to try that out before I start writing game code. It’s a good thing that I have started storing the code in a GIT repository, because I can just roll back the changes if anything goes wrong. I’ve also ported Eclipse to the Autotools build system, and added internationalisation support. I don’t have any completed translations yet, but anyway…
What ever I decide, one thing that definitely needs to be done is resolution independence. Then I’ll need to make two new widgets. A spin-button kind of thing (or drop-down box) to select the resolution, and a checkbox to select full screen mode.
GIT
Posted on Friday, March 7th, 2008
A few days ago I set up a Subversion repository to put some projects I have been working on (like Eclipse) in. I decided to go with SVN because I have worked with it before, and am pretty familiar with its commands and workflow.
But, recently on Planet Gnome, I have been hearing a lot about GIT (the version control system originally written for managing the Linux kernel) and I decided to try it out. I backed up my Eclipse directory and turned it into a GIT repository (which, unlike SVN can exist without a server). When I committed the sources, I couldn’t believe how blazingly fast GIT is – where SVN used to take three or four seconds, GIT is done before you can release the enter key! It seems a lot more powerful than Subversion, but takes a while longer to get comfortable with it.
I also plan to convert the Eclipse build system to Autotools, which is pretty horrible to set up, but can vastly simplify things like installation and cross-compiling if set up correctly.
Progress on the Engine
Posted on Tuesday, December 18th, 2007
The game engine has been coming along quite well recently. I’ve been doing a lot of work on it, as it’s school holidays.
I moved all the image code over to OpenGL, which was surprisingly easy. All I had to do was change a bit of initialisation code, and then rewrite the code that draws bitmaps. Instead of blitting them onto the screen, now images are rendered as textures. This gives me some very big advantages. Firstly, I have to call one command to rotate an image – something I was having a lot of trouble doing before. Also, I should be able to make it more resolution independent, and allow the user to play the game fullscreen.
I was having some trouble initially with OpenGL – I was just getting a black screen. Eventually I found that I was clearing the screen after drawing everything… At least then I could get white (or coloured) rectangles to render, but I was still having problems mapping the texture to them. After a long, frustrating debug session, I found that I had just accidentally put two arguments around the wrong way on a function call… Suddenly everything worked perfectly!
