Thanks to Carlos Garnacho’s recent work with the evdev driver and Gtk+ along with Peter Hutterer’s work on getting  the multitouch situation sorted out inside of X, not to mention everybody else who has contributed to the effort, I was able to get Multitouch working on my Fedora 13 powered Lenovo T410s.

All the following instructions relate to those who have N-Trig multitouch devices. Mileage may vary with other devices. To start playing around with multitouch in Fedora today you will need

• my evdev multitouch RPM packages built from Carlos’ branch
  • Warning: this package obsolete xorg-x11-drv-evdev so you will no longer get updates from the Fedora repo
  • Note: I’ll provide a yum repo for my packages once Koji is up and running again, for now if you don’t have an X86_64 machine you will need to rebuild the source rpm.
• If you have a N-Trig device you will also need to get the kernel Kyle built which has a fixed N-Trig driver (hopefully this will show up in an update soon).
• You will also need Carlos’ xorg.conf snippet. This is again for the
  N-Trig driver but should be easily modifiable for other devices
• To play with multitouch you will need the latest Gtk+ from the xi2-playground branch

I recommend building Gtk in a jhbuild environment or at least don’t install it since it is the unstable 3.0 branch. Once the multitouch stuff has been backported to 2-20 branch I will start providing packages. I take no responsibility for the breakage of anyone’s machine due to replacing such a major system package. Thankfully, if you run inside of jhbuild you can play around all you want without fear of breaking your system. Another option might be to run inside an virtual machine but I am not sure if multitouch events will propagate correctly yet.

If you want to play with some demos you will find them inside the tests/multitouch directory of Gtk. Have fun and ping me with any issues you have. It might be nice if we got this working for Fedora 14. The pieces are certainly falling into place.

The project I have been working on for a long time now has seen it’s first (beta) release. Meet Fedora Community, a consolidation of the various Fedora Infrastructure bits into one UI with a focus on usability. The unique thing about this site is that it doesn’t replace the other Fedora Infrastructure bits. It uses them as backends and mashes together the data into one view. For instance you no longer have to go to the bodhi update tool after checking on a build in koji. Instead you simply look at the build tool and if the package is able to be updated you will be presented with the option to do so. It will also point you to the correct log if an error happens in the build.

Right now it is geared towards Fedora packagers but in the future we hope to be adding a lot more functionality. Since the concept revolves around small applications running in a dashboard the possibilities are endless. Think live server status for sysadmins or up to date Fedora news for users. As always, because Fedora stands for Freedom and Community we will be emphasizing upstream collaboration which we owe a great debt for making all of Fedora possible, and Fedora Community’s code will always be licensed under AGPLv3 and compatible licenses.

To learn more you can grab the podcasts (in ogg vorbis format of course) or go to our project page.

Fedora Community, codename MyFedora, integrates the Fedora infrastructure into one interface focused on usability and streamlining user workflows.  This is a beta release with a production version to be released alongside Fedora 10.  While the first revisions are focused on Fedora Developers, the underlying Moksha framework, based on top of the Python WSGI TurboGears 2 platform, provides a base for writing self contained applications which can integrate to create one large application.  The applications seen on Fedora Community interact with the Fedora infrastructure to produce a single, unified view.  In the future applications can be written to interact with Transifex for translations, listen to upstream for project releases and even federate between infrastructures such as OLPC being able to have a view into their services along side the services they use in Fedora.

We are calling on Fedora members to test out the site and file bugs.  We plan to roll this out alongside Fedora 10 so pitch in and help us make a great release.

Your site regarding %TITLE% looks very interesting to me. I found it doing a search for %KEYWORD%….

If you can’t even get the template right … try harder not smarter, because I know you are as dumb as a rock.

In other news look for some Fedora announcements from me pretty soon.  I’ve been pretty under the radar recently in terms of what I have been working on.  It has all been public, just not publicised.  Revolutionary, probably not.  Those who know me know I like calculated improvements.  A step forward…let’s just say I am proud of what I am doing and have to praise Red Hat for having faith in me and my plans to let me work on things I felt were important.  There is a reason they are not just a pay check to me, and part of that is their belief in the power of free and open source softaware and the confidence in developers who work on the betterment of not just the company but the community and the ecosystem as a whole.

It seems that a “feature” that Microsoft implemented in the Windows 9.x days has appeared in Plymouth. Yes that’s right, that “feature” the I.T. world grew to hate, holding down the Ctrl or F8 keys to get into Windows Safe Mode (http://support.microsoft.com/kb/180902/en-us) has invaded Fedora. Ouch!

Now, if I take a step back, I can completely claim the following:

• Plymouth takes away my freedom of choice (a freedom that has become a basic Human Right
• Fedora has taken three steps back to gain one step in the name of ‘usability’

The funny thing is Mac has this feature also (hold c to boot from cdrom etc). Let’s repeat after me, “having to hold down one key after boot does not take away my freedom of choice”. And while we are at it, why do people fling around phrases like “freedom of choice” so cavalierly? It gets to the point where those once powerful words become watered down and an instantly marks ones argument as suspect. I know, let’s give more freedom of choice by bringing up the bios every time they boot. There is a lot of choices in there.

If there is an argument to be had here it is about continuity and discoverability. On the continuity side, if someone is used to seeing grub every time they boot it might be nice to keep that feature or something equivalent on upgrade but not on a fresh install. On discoverability of the feature, I would agree this is where the fustration comes from. However for the small number of (potential) users who actually like grub it would be wrong to add another option to the install. It would be much better as part of system-config-boot and if possible as an option in grub itself so that people who need to switch often can set it the first time and never have to hold down a key again. Hell, if I dual booted a lot I would like to have a key assigned to each OS I boot into but then again with virtualization being pretty good, there are better ways to run a separate OS.

Put it this way. Users may have kicked and screamed when Windows integrated DOS but Windows usage still grew. When MS decided not to show the text boot menu, again usage still grew. The way I see it is polish opened up the world of computing to more and more people.  By not polishing Linux and staying in a mindset that change is bad we will be stuck in the past while the rest of the world moves on. That is not to say every change is good but good reasoning went into this particular change and so far I haven’t seen any legitimate argument for not having it. Let’s repeat again, “having to hold down one key after boot does not take away my freedom of choice”.

• Federico’s screencast of rpm2git tool – we should be using this or something similar

The second reason given, which has to do with building a community is pretty broad but more believable.  Fedora has made huge strides while also sticking to its guns in the freedom department and being valuable upstream contributors. It may be that we sacrificed short term gains which can be gotten via a bit more differentiation, or out of the box “just works” on closed hardware but as companies are being convinced to open up their specs and open drivers are being written, a large portion of which is being done by Fedora developers working upstream, little of the short term gains matter much.

I suspect the real reason is somewhere in the community vein, staring with the Kernel and X team developers who work tirelessly making sure their work is fit for upstream consumption and can be supported in the long term. Following their lead the rest falls naturally out of that single notion of moving Linux forward as a whole. Kudo’s to all my Fedora friends – keep moving forward.

If you knew what I needed to do already why didn’t you just do it?  Just popping up the dialog that I now have to go searching for would have been somewhat passable.  Besides Jython is not even usable right now so just assume I want my system python.  That is just plain laziness and the reason why I keep trying eclipse and then thinking better of it a couple of minutes later.

To be fair I hear it is a great app but I can’t get past the UI.  It gets in my way.  The run dialog alone has forever traumatized me.  Let’s see if the bugzilla plugin will allow me to file this bug or I will be back with another ranty update. I’m going to try to give eclipse a longer benefit of the doubt but if I run into much more of this it’s going to take a lot of people telling me it has since gotten better, before I try again.