Author: Pavel

After my last post about Blender and how Open Source projects lack communication when it comes to UI Toolkits, I wanted to write another post about OpenOffice.

The UI of OpenOffice is inherently broken, because of (similarly to Blender) the age of the project. OpenOffice also was first a closed source project, developed primary for Windows and having an own Toolkit. And therefore it looked quite out of place when it was first ported to linux – hence one of the main features of OpenOffice2 in comparison to OpenOffice1 was the covering layer over the UI which made it look a bit more native.

But the problem still persists, since it was not fixed but just covered by the layer – you can still see the true ugly face of OpenOffice by removing the “openoffice.org-gtk” in Ubuntu. But even with the cover installed you will see a lot of wrongly drawen things and odd behaviour.

But it seems like the OpenOffice developers are finally aware of that and have also started fixing the problem, by abadonning their custom written toolkit and using and abstract XML description of the UI which maps on Linux directly to GTK calls. This is a quite nice approach similary to where Mozilla ended on Linux(using XUL) and where Blender should head if they really want to fix their UI Problems.

I just started my Intrepid desktop without having xorg-input-kbd and xorg-input-mouse installed, which means that X.org in Intrepid now uses evdev for all input handling. This is nice, since it moves all input drivers out of X and uses the kernel input event interface instead – less code duplication yay!

By the way; evdev was one of the many things which made the EEE PC at linux plumbers boot in 5 seconds.

I just ran across this proposal for imporving the UI of Blender. First of all it is nice that they are trying to improving one of the most confusing an not intuitive interface I have come across. It is especially also nice since they also recognized some design flaws, like having to set object properties before creating the actual object, which prevents adjusting the properties afterwards.

Another interesting point is to see how it could come that far; Blender was initially intended to be used by the same people who wrote it, which is a small audience that does not care about usability and interface standards, so you can define the UI the way you like it best. But as Blender became opensource the audience dramatically increased and Blender now is used in the context of a desktop, where standards matter.

But what I do not like is the way out of their “self written toolkit” trap; first of all the proposal says, that it is a good idea, that Blender looks the same across the platforms. But that is clearly a false assumption since meanwhile we know that “same everywhere” translates to “integrated nowhere” – this is even something that Mozilla after a lot of struggling acclaimed when they left out their key-lock concept out of firefox3 on Linux. This is also a principle all modern cross platform toolkits try to follow, but Blender wants to keep to its own look, which they want to improve instead.

This shows another problem of the “self written toolkit”; currently they have many problems with usability, because the toolkit is broken at a basic level, like there is no visual difference between buttons and a one out of many selection. Things that were available in GTK for years and which are documented in the HIG, so you can use them correctly.

So basically what we are seeing here is another lack of interaction between Open Source projects – instead of use (for instance) GTK and get platform integration and the experience of years with user interaction for free, Blender tries to fix their inherently broken toolkit and so to say reinvent the Wheel.

this is kind of a followup to this post, which explains what I mean with “the rest”.

So now we are going to look at Gallium 3D and put in in the context of the rest. First of all you need to know that there is the DRI protocol, an API provided by the kernel and there is a DRI driver which controls the graphics hardware by using this protocol.

Gallium 3D is now a modularization of the DRI driver, where the parts which the intel and radeon drivers(and others) have in common are put in a seperate package which is then used by both. Furthermore Gallium 3D itself provides a simple graphics API on which you can implement more complex APIs like OpenGL, OpenVG or Direct3D.

Currently every driver reinvents the wheel, when it comes to common parts and if you want to implement some other graphics API, you have to map it to the OpenGL like interface which current DRI drivers provide, which in many cases slows things down.

Now how does this relate to DRI2? There are people asking whether Gallium 3D or DRI2 is better. Well you will need both. Like already said above DRI2 just a protocol, which Gallium 3D will have to use in order to talk to the kernel – just like any DRI1 driver which will be updated to DRI2.

And DRI2 is what you want for proper memory management on the graphics card, one that allows redirected direct rendering etc.

while I possibly can not tell how the actual GTK Theme for Gnome3 will look like, I suppose that It will use the GTK-CSS Engine which just made a first release.

One might ask why the next Gnome should use an engine which just looks as crappy as that, but that becomes pretty obvious when you think about what CSS is.

CSS is the language used to layout XML document such as XHTML websites and thus it is flexible enough to support every possible design one might think of. Furthermore it is pretty widespread – probably not in the desktop world, but everyone only barely related with web design should have a pretty good knowledge of it.

And now lets look at CSS Zen Garden a Website created to showcase the possibilities of CSS – look at the themes on the right and how they can change the face of the website. Remember it is always the same physical structure! Now think all of these would be possible with gtk and just using one engine – pretty cool, right?

In case you were wondering what I was doing all the time; I was porting youamp from maemo/hildon to gtk/gnome only. And as you can see I even experimentet with going gtk only 😀

when it comes to folder sharing in a local network and Linux, you have basically the choice between samba and NFS. While samba is the better choice when you have also windows machines on the network, NFS should be the choice when the network is homogeneously Linux, since it is much easier to configure and directly maps user-ids and permissions on the remote machine.

One might think, that that native Linux filesystem should have good GUI tool coverage, but amazingly there are absolutely no tools for setting up NFS in Gnome, while accessing a Samba share is just a few clicks away. In order to set up NFS one still has to manually edit the fstab and manually mount the directory in the console. Neither Nautilus nor gnome-volume-manager give you a hand here.

Even though the tools you need are already there; you can already advertise NFS through Avahi/ Zeroconf and make it automatically show up on OSX – all it takes is to make Nautilus recognise this and automount the share in the /media/ folder.

So lets vote here and hope that the situation improves.

AMD just realeased a new version of their proprietary graphics driver fglrx. While usually they only introduce new bugs every months while the really interesting stuff is happening within the open source radeon driver, this month there are also some interesting things in fglrx.

Not that it would excite any of the existing radeon users, since they have got that stuff for months, but now fglrx also supports Xrandr 1.2 and accelerated 2D rendering through Xrender.

in order to enable this, add the following to the Video Device Section of your xorg.conf:

    Option      "Textured2D"
    Option      "EnableRandR12"
    Option      "TexturedXrender"

Textured2D is AMDs acceleration architecture for primitive drawing, similar to EXA in the open source world and is required for the Xrender Acceleration.

Although 2D is just as good as with the OSS drivers now, the texture_from_pixmap extension is still slow and so is scrolling in compiz,  therefore I would still recommend the OSS drivers for compiz.