Still no OSS R600 & R700 support in Jaunty

Although AMD released the example code for several hours already, there are still no attempts to update the according packages in Jaunty in order to finally enable the R600 and R700 to use open source acceleration techniques like EXA or or tear free Textured Video.

There is also no attemts to make Kernel Mode Setting and GEM to work on this chips, which finally leads me to the question if AMD is really that serious with Linux support. Like I see things there is no chance that things will be ready by – lets say – tomorrow. I am really considering getting a NVidia Card now. 🙁

Gnome Online Desktop

There was a lot of talk recently about how Gnome should embrace the online services in order to keep up with the Web 2.0 development. But sadly most of the ideas were like “lets integrate better with web service <foo>” – the problem is that I do not want to start using Google Calendar from now on; I like the way Lightning handles my dates and I like that I have them available offline. What I would like would be able automatically synchronise them, when an online connection is available.

But we are already too focused on the data layer right now, so lets take a step back and see where we are.

We are here

What we currently have are web pages or better web services with interfaces described with XHTML and styled with CSS and we have local applications with interfaces described with XML and (eventually) styled with CSS. So the UI done pretty similarly already – although it still looks quite different, since there are standard web-page widgets and since most of the web-pages are drawn inside the browser, while local applications are drawn as separate windows on the desktop.

The difference

One might think that the difference might be the place where computation happens, but actually the computation happens in both cases on your local machine – it is just that Java Script is the only language you can use for web services and it is pretty limited right now, but things like Tracemonkey and Google Gears are creating a platform for computation intensive application delivered over HTTP.

And that is also the main difference; the way applications are deployed. Because web-services can be updated every time you reload the page, you can easily keep you customer up to date, while for local applications you often have to deal with out of date applications and updates. This is especially a problem on non Linux platforms, where you do not have a central package(application) manager. But on Linux we have that advanced systems for update delivery so this is not really a problem.

The real difference

What everyone is doing right now is rewriting existing and working code in Java Script in order to solve that one delivery problem, which is really not that big on Linux while the rewriting task is quite huge. And everyone starts using that new and shiny web services – but the question is why. The real benefit which web services offer over current local applications is centralized and therefore synchronised memory; you can log into Google Calendar from every PC you have access to and always see your up to date dates.

So we need

So basically what is missing from Gnome is that centralized memory, but the problem is that an open source community can not easily offer that because someone has to pay a lot of money for a lot of servers. So we still have to integrate with the existing web services. Nothing new here. But that is not a problem either, since there are already web services for everything one might imagine.

What we have to consider here, is that we have to be able to switch easily between different services like lets say Picasa Web Albums and Flickr. We could even define an open API for web service interaction which the services could implement then.

The master plan

to me it makes no sense re-implementing everything in JavaScript just for the sake of being able to run it inside the browser. We have already a variety of better languages available, when running on the local machine and there is also much of the infrastructure ready.

So instead we should make the existing applications more web-aware. Luckily there is already a framework made exactly for this: Telepathy. Currently Telepathy only manages your web-presence status and allows local applications to work with it. But it should also be able to manage your web-pictures and web-calendar and make it accessible to local applications similarly.

Then F-Spot could easily show you which of your pictures are currently published and which are only available locally without making a difference between Picasa Web Albums and Flickr – you should only care whether your pictures are synchronised or not.

The next step would be to actually take advantage of such a framework. If you currently want to write a text you have to care whether you write it for offline or online usage. If you write it for offline work, then things are pretty easy; since Word is not available on Ubuntu you use OpenOffice. But if you write it for online use you have to deal with a bunch of different interfaces – depending on what your web software is you have to deal with the WordPress text editor, the Joomla text editor and so on. And they all have in common that you cant save your text to your local computer easily.

The initial task was just to write a text – why have do I care of such things at all? Would it not be great if I just could open a local running text editor, write my stuff and then decide whether I want to save it to a file or publish it to a web service of my choice.

A locally running web-aware application could do that while offering a consistent interface for text editing and doing a lot of things which you can not inside a browser like launching Gimp in order to edit that picture you need in your article and then automatically upload it.

So basically we have to move things offline in order to get an online desktop and then we can also use browser for what they were meant for; reading text.

OpenOffice is on the right track

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 “” 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.

Well done Ubuntu

I just started my Intrepid desktop without having xorg-input-kbd and xorg-input-mouse installed, which means that 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.

Blender UI – reinventing the Wheel

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.

Gallium 3D and the rest

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.

News on YouAmp

There has been a while since I have last written about the progress of YouAmp – my pet music player. Menwhile I realeased the 0.5.x series, which mainly feature the cover view.

the full changelog is:

  • do not require restart to accept credentials
  • view the cover if saved along with the music files in the same directory
  • details view of the song
  • right click menu allowing filtering by album/ artist
  • allow to jumping in the playlist with “play this next”

YouAmp on Ubuntu

and there is also the first release for Ubuntu; you can find it in my PPA.

As for the next task I am engaging is getting rid of my self written indexer and use Tracker, which will fix some problems with the current design and also is intresting for Frementale.

Gnome3 Theme

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?

Gnome and NFS

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.