Monthly Archives: December 2006

GNOME plans for the future

Posted on by

Noticed some tiny disturbance in the force before Christmas as
Thom Holwerda of osnews posted an article about what he felt was the sorry state of free desktops. Seems most people in the GNOME camp simply ignored the article as irrelevant, but Aaron Segio of Trolltech and KDE let it somewhat get to him.

Personally I felt Thom kinda pointed out some troublesome points, but that his context and conclusion was wrong.

First of all he critized GNOME for not having a clear vision for GNOME 3. Well this is true, but that is mostly due to not having any clear ideas for something that would require a GNOME 3. GNOME 2 came about as a result of shortcomings in GTK+ at the time, causing the GTK+ maintainers having to break API compatability in order to improve for instance the handling various writing languages and fonts.

As part of having to port to the new GTK+ some policy changes where made for GNOME in terms of focus and goals. Goals and policies which people are still very happy with and don’t see a big need to change.

At the moment GNOME is doing quite well with incremental improvements with a lot of the major effort by GNOME contributors and companies going into projects such as HAL, X.org, Cairo, NetworkManager, GStreamer, Telepathy, OpenOffice, Firefox and Bluetooth support to mention a few. The thinking being that having a full featured office suite for instance is more important to potential users than having a panel that can be themed to have the shape of a sextant. At the same time the core parts of GNOME are continously moving forward with incremental improvements or replacements.

Why GNOME’s incremental approach is considered less by Thom than Apple’s is not clear to me, but for some reason he feels that unless you put a major version number behind something in the linux world you by definition stand still.

And to be honest incremental improvements is what everyone is doing these days. Windows Vista, MacOSX and KDE4 don’t really contain anything earth shattering, they are basically increamental improvements over the predecessors. Thom mentiones KDE’s Plasma, Appeal and Solid in his article as KDE4 efforts. Aasegio mentioned Phonon and Decibel as other examples. Well if you look at each of them, none of them are actually doing anything ‘new’, they are all just attempts at trying to do what is already being done, but in what each project maintainer feel is a better way. Which is just the same as how GNOME currently increments forward, although since GTK+ is not breaking API the need/motivation to call it GNOME3 is not very big. The excitement around Compiz recently showed how more glitz can be brought to the desktop as an incremental improvement.

The thing is that until we find a new way to interact with our desktops, nobody will be doing anything truly significantly new anytime soon, apart from maybe in the application space.

And to give an example of what I am talking of I want to point to the Nintendo Wii as a device which actually is doing something ‘new’. While parts of the technology has been around for quite a while the way the Wii controler works do truly change the way you interact with the system (making it much for physical for one) as compared to previous and competing consoles.

On the desktop space I think doing something I feel deserve the title ‘new’ will be harder, but I think the Lowfat experiement of Mirco has the potential. And if it pans out it might become the foundation and focus of a GNOME 3 cycle. But with all such experimental efforts we can’t commit to it before the proof of concept has reached a bit further so we know we can accomodate all the major usecases. And maybe in the end it will end up being more like what we at Fluendo try to do with Elisa, making it a add-on to the current desktop/system for a specific usecase rather than a full desktop replacement. Yet using many of the same building blocks as the desktop.

So while both GNOME and KDE could do with more developers I don’t see any truly dark clouds on the horizon. And if Thom or anyone else have any clear ideas on something that would require GNOME to change so many of its internals to justify switching the major version number to 3, then please come with them. In the meantime lets just continue incrementing our way towards perfection within the constraints of the current paradigm :)

The Failure to Enjoy Terry Pratchett

Posted on by

For many years I have heard people I know, and whom I think tend to have similar taste to myself, say how funny the Discworld novells by Terry Pratchett are. Due to this I have multiple times tried picking up ‘The Color of Magic’ hoping to find it very funny. Instead each time I find the book extremely dull and boring. Neither creating ‘funny’ setence-words from the phonetics of the words like insurance or economics or a world whose concepts tries to be funny by outdoing absurdity itself really ever get me to laugh, hardly even smile.

So I guess Terry Prachett will continue to be an undiscovered ‘gem’ for me.

Jokosher on Solaris

Posted on by

Thanks to our friends at Sun we have a SPARC box running Solaris in the office which we use for various development. Yesterday Jan was trying to figure out why gst-python had problems under Solaris. This patch and the problem was solved so Jan moved on to trying to run Jokosher on Solaris. The application started, but Jan was not able to to get it to do much. What hindering Jokosher on Solaris seems to have two major components, one was our Solaris install lacking HAL which Jokosher needs and which newer versions of Solaris has, the other was some hardcodings of the GStreamer ALSA plugin in Jokosher. Jokosher switching to autoaudiosink should solve part of that and if we put together an autoaudiosrc plugin Jokosher should in theory be able to run well under Solaris also. Anyway if we manage to have Jokosher work without any changes on both Solaris and Linux there should be nothing stopping us from getting it running under Windows and MacOS X as well without further changes (apart from audio source plugins for GStreamer for those architectures). An audiosrc plugin is incoming from Sebastian Moutte soon so maybe Jokosher 0.3 will be available for both Linux, Solaris and Windows.

The Magic Lamp of Standardization

Posted on by

Just saw an article on whats up next in Linux desktop standardization where there is blurb talking about the discussion at the latest ODSL Desktop Architects Meeting about the issues around Linux Audio (or multimedia in general if you want).

The final outcome was this: It was decided to start addressing these issues by creating a focus group and mailing a list of what’s needed from audio APIs, and how to deal with bringing consistency to Linux audio.

Which is exactly the kind of outcome a conference like this can ever hope to achieve and which also shows why it is a complete waste of time trying to address the issue in such a forum.

The DAM meetings are set up as a ‘lets get everyone together to see if we can find common ground’ type of meeting. Which isn’t bad, but it only lends itself to a certain type of problems.

The problem with Linux audio is not that people out there do not ‘know’ what the problem is, the problem is that people disagree, often quite strongly on how to solve it, and that there is limited resources available for solving it using any solution. So instead of actually moving towards solving it we get a lot of cute discussions on related topics such as when to push and when to pull as one example.

To solve the problems mentioned in the article you will need to step on some toes, sink a lot of man hours into the chosen solution and in the end win out on excellence. Which surprisingly is a bit harder than one would think :)

I think the ODSL-DAM context fails horribly already on the first hurdle, in the sense that the DAM conference is not set up to do any kind of toe stepping, rather to the contrary. Not that I am saying that the DAM type meetings are useless, not at all, but a format made for trying to increase cooperation between two quite mature and well established solutions like GNOME and KDE doesn’t necessarily lend itself well to a problem requiring some painful trailblazing.

That said I do think the problems are being addressed, but they are not and will not be addressed by things like ODSL DAM, instead they are being addressed by individual developers, contributing companies and distributions who are already all moving in mostly the same direction. The thing is however that for the contexts these people and groups are moving something like DAM is more of a distraction than a valuable contribution towards the end goal at this point in time.

To let on where I see things moving based on what the distro’s are doing I will say that on the audio side the solution that is gaining traction is PulseAudio which will be run on top of ALSA and providing legacy support for ESD and OSS. For the codec problem there are solutions being worked on around GStreamer.

Within the context of these technologies and some other technologies that comes as a consequence around them also longer term plans are made for addressing the issues faced. For instance making sure that Pulse Audio is an acceptable solution for both people doing so called pro-audio and for the normal desktop, like it is on MacOSX.

New Elisa out with Trick modes support

Posted on by

The Elisa media center team did a new development release yesterday. One of the exciting features of this release is the support for trick modes. This means you can do things like fast forward or half speed forward playback. Also for Ogg files with Ogg Theora video you can do reverse playback of the files. So if you have ripped any movies using Thoggen or KungFu you can now play them with Elisa and ‘rewind’ when needed if you want to take a closer look at a scene. The nice thing is that reverse playback like forward playback can happen at a multitude of speeds.

Its nice to have a software package out there enabling trick modes making it available as a visible feature to end-users :)

Comment on Diva

Posted on by

Michael Dominic posted a blog entry on the state of Diva. One of the major announcements he did was that he was looking into moving from GStreamer to MLT.

I usually try avoiding commenting on such decisions and instead let time decide wether they are wise or not, as making a comment on such things easily just cause bad feelings. Of course sometimes the need to make a comment overrides such concerns :)

One thing that Michael forgot to mention in his blog entry was that almost from the begining most of the GStreamer developers disagreed with the design choices he made in terms of Diva’s usage of GStreamer. Multiple times we tried to say that the Gnonlin approach was what we recommended and would be working towards enabling for these kind of applications. Michael disagreed and instead tried various alternative routes, which is why I feel somewhat unhappy about his claims about GStreamer in his blog. The rapid progress of Jokosher I feel validates our claims about Gnonlin to a large degree and I hope with our renewed effort into Pitivi we will have a 100% comparable application to Diva to prove our point with.

Edward added a reply to Michael’s blog pointing out some of the issues involved here, but one thing I want to expand upon and that is the issue of framework readiness. It is impossible to develop a framework such as GStreamer in isolation as there are always usecases and trouble areas that get lost or design decisions who seem clever from the framework point of view but which is a complete fuck up from the application developers point of view. This is a big part of the reason why GStreamer have taken so long to get to where it is today. Every time a new application type started using the framework we discovered that there where basic assumptions made in the core which simply didn’t hold true. This do make life for application developers a bit frustrating as they can get sucked into long periods of having to work on the framework and fixing bugs there instead of moving their application forward. I think people such as Stefan Kost with his Buzztard project and Edward Hervey with his Pitivi project can testify to that. The same is probably even true for the Totem and Rhythmbox projects who where among the early adopters of GStreamer. But thanks to the dedication and continous feedback of our application development community we have managed to ramp up the framework and also managed to keep the design pretty sane through it all.

I think this process is true for any major software project and I think no matter what multimedia framework Diva ends up using it will run into problems and deficiencies in the framework. The only framework which is sure to provide an application with all the features you could want working perfectly ‘today’ is one which already have applications using them sporting all the features you want. Which is why most music player developers for instance are pretty happy with GStreamer today, as there already are fully working high featured music players using the framework.

So on the GStreamer side applications such as Pitivi, Jokosher and Buzztard and Flumotion will continue to push the framework forward and resolve bugs and missing features as we find them. And while all the work going into for instance enabling DVD’s under GStreamer might feel like a unwanted distraction for a video editor developer I am pretty sure the long term effect of being able to easily import video from DVD’s directly into the editor will be a highly welcomed feature by the users.

I wish Michael good luck with Diva and trying out MLT, but I am pretty sure he will find that life there is just as painful, just with different set of bugs and missing features.

One year of GStreamer 0.10

Posted on by

Andy Wingo reminded me that the 5th of December last year we did the first release of GStreamer 0.10. So Tuesday was actually our 1 year aniversary of GStreamer 0.10. We felt it was a major milestone for GStreamer, turning a corner in stability and usefullness. That said the move wasn’t completely without its detractors as the 0.10 branch did have some regressions compared to the 0.8 one. Now one year later I think its safe to say that GStreamer 0.10 has been a gigantic success. The number of developers contributing or using GStreamer have mushroomed and the status of the GStreamer project is much improved. There are still a few feature regressions left in GStreamer 0.10 compared to 0.8, DVD playback being the most noted example, but I think that is overshadowed by the improved capabilities of the framework and the much improved stability provided by the new framework.

The fact that we don’t try to ‘jury-rig’ new feature in place, but instead take the time to do them properly seems to win us more friends than having ‘all’ features available in a flaky manner.

Not everything is perfect though, we know for instance that some of our demuxers are still not perfect and applications like Pitivi and Jokosher breaking new ground are hitting new bugs. But the good thing is that unlike the 0.8 experience, with 0.10 we feel that when we fix bugs they stay fixed, instead of playing bugzilla whack-a-mole like we did with 0.8. For every day we see bugs getting fixed or new plugins getting made, all bringing us closer to give the community the media experience they deserve.

So congratulations to the rest of the GStreamer community with 1 year of GStreamer 0.10 rocking hard!

The return of a GStreamer Legend

Posted on by

Edward got his first major patch for Pitivi yesterday. Cool thing was that it was from an old GStreamer hero who we hadn’t heard from in a long while, namely Richard Boulton. Richard is one of the few people who I think pre-dates my own involvement in regards to GStreamer apart from Wim and Erik. Welcome back Richard :)

What Richard provided for Pitivi was the save/load Project feature which is critical going forward where Pitivi is reaching a level of usability that makes saving and tweaking projects become a real priority. Cool stuff.

Novell bashing at Groklaw

Have to say I agree with Jono on the latest Novell bashing story on Groklaw. It feels more like an attempt at smearing than anything else. As anyone who have followed OpenOffice for the last years would have known, Ximian and later Novell always maintained a large set of changes for OpenOffice due to the process of getting them approved and merged upstream being long and painful. A lot of nice stuff like the GTK+ support and a much improved icon set created by TigerT and Jimmac is the heritage of this effort. Michael Meeks has probably pulled in more people to help out with OpenOffice than anyone else in addition to the incredible work he personally have done on OpenOffice. This is just a few of the contributions done by first Ximian and later Novell to OpenOffice.org. Starting to accuse them now of forking is just childish.

PJ, it is fair to critisize the Novell & MS deal, but please try to keep things at a intelligent level, more postings like that one and you lose all the cred you built up over the last few years.

Gluetastic Pitivi

Posted on by

Anyone following GNOME CVS activity over the last days would have noticed the heavy Pitivi hacking activity. As of yesterday evening Pitivi properly supports ‘gluing’ together multiple videoclips and outputing them as one file. This includes re-scaling the videoclips into one shared size if they are of multiple sizes. The current battle plan is to enable new features in Pitivi even when we know they trigger bugs in various GStreamer elements. Then later on when the GStreamer bugs gets fixed we will hopefully have an active user community which will scream murder (file bugs) when plugins break Pitivi functionality. Next step in enabling the new GUI ideas is to enable basic transitions and some simple cutting (not necesarily in that order). After that we should have a basic but useful tool for people to start using. What the exact priorities will be after this is not set in stone, but will depend on user feedback and of course the priorities of new contributors coming onboard. A big thanks to Edward for his relentless effort in getting Pitivi ready for mass consumption!