Anyway, I would once again want to ask people to contribute to this effort. There is a proven team behind this fundraiser, so this is not like a kickstarter where people are starting from scratch and you have no idea where they will end up going or what they might achieve. This is an existing project that just needs some polish to get it to critical mass. So visit the fundraising page and make your pledge.
So the PiTiVi announced the PiTiVi fundraising campaign on Friday. I sincerely hope they are successful, because I think we really need a good non-linear video editor that runs on the Linux desktop, especially one that is built on top of GStreamer and thus sharing the core multimedia infrastructure of the rest of your desktop. The current PiTiVi team got the right skills and enthusiams in my view to truly pull this off, and their project is scoped in a manner that makes me believe they can pull it off. PiTiVi is already functional and this fundraiser is more about accelerating ongoing development as opposed to creating something from scratch. And their funding requirements for reaching the base milestone is rather modest, for example if just the employees of the 3 main linux distribution companies pitched in 3-4 Euro it would be enough to cover the base funding goal.
But I think this fundraiser is important also beyond the PiTiVi project, because it can serve as a precedent that it is possible to do significant crowdfunding around open source development and thus open the gate for more projects accelerating their development using it. There are a lot of great open source projects out there created on a volunteer basis, which is great and like PiTiVi they will flourish even without crowdfunding, but crowdfunding can be a great way for developers of the most interesting projects to be able to focus solely on their project for some time and thus accelerate its development significantly. So in the case of PiTiVi, I am sure the team will be able to achieve all the goals they have outlined in the funding campaign even if the fundraiser raises no money, but the difference here is if they do it in 1 year or 5 years.
So personally I donated 60 Euro to the PiTiVi fundraiser and I hope everyone reading this blog entry will do the same. Lets give the people developing this and other great open source tools our support and help them make their great software even better. This fundraiser is done by people passionate about open source and their project, because to be fair, no matter if the efforts ends up raising closer to 30 000€ or closer to 100 000 € it is in no way what anyone can call a get rich quick scheme, but rather modest amounts that will let two talented open source developers spend time working fulltime on a project we all want.
And remember whenever a major project using GStreamer gets a boost, it gives all GStreamer projects a boost. For instance in my own pet project, Transmageddon, I am gotten a lot of help over the years from general improvements in GStreamer done due to the involvement from PiTiVi developers, and I have even ended up copying code from PiTiVi itself a few times to quickly and easily solve some challenges in had in Transmageddon.
So thanks to the new GStreamer 1.x VAAPI package for Fedora I was able to do a hardware encode with Transmageddon for the first time today. This has been working in theory for a while, but due to me migrating Transmageddon from GStreamer 0.10.x to GStreamer 1.x at the wrong time compared to the gstreamer-vaapi development timeline I wasn’t able to test it before.
Bellow is the GStreamer pipeline that Transmageddon use now if you have the Intel hardware encoder packages installed. Click on the image for the full image.
I am also close to being able to release the new version of Transmageddon now. Most recent bugs found have turned out to be in various GStreamer elements, so I am starting to feel confident about the current pipeline building code in Transmageddon. I think that during the GStreamer Hackfest in Munich next Month I will make the new release with the nice new features such as general support for multiple audio streams, DVD ripping support and language tag setting support.
So we had the DevConf conference here in Brno this weekend. One of the projects I am really excited about is Cockpit. Cockpit is a new server administration tool developed by Red Hat engineers which aims at providing a modern looking and userfriendly interface for your servers. There has been many such efforts over the years, but what I feel makes this one special is that it got graphical designers and interface designers involved, to ensure that the user experience is kept in focus instead of being taken hostage by underlaying APIs or systems. Too many such interfaces, be they web based or not tend to both feel and look clunky, for instance sometimes exposing features not because anyone realistically ever would want them, but because the underlying library happen to have a call for it.
Cockpit should also hopefully put the final nail in the coffin for the so called ‘server desktop’. The idea that you need to be able to run a graphical shell using X on your server adds a lot of pain with little gain in my opinion. The Fedora Server product should hopefully become a great showpiece for how nice a Linux server can be to use and configure when you have something like Cockpit available.
There was some nice videos showing what is already in Cockpit shown at the conference so hopefully they will be available online soon. In the meantime I recommend taking a look at the Cockpit web page.
I noticed an article on Phoronix today about libinput which made me think I should post a little Wayland update again. So Libinput is developed by Peter Hutterer who is part of the Graphics team here at Red Hat, and our resident input expert. He is developing libinput as part of our work to get Fedora Wayland ready.
That said input is a complex area and if we do end up not having a Wayland option with feature parity with the X.org option in Fedora 21, then not having gotten input sorted in time is the most likely scenario. That said we are still charging ahead with the goal of getting things ready for Fedora 21, but in our last status meeting we did flag input as our biggest risk. Luckily Peter is not alone in his efforts on libinput, there are a healthy amount of community contributions and at Red Hat we have recently had Hans de Goede join Peter on input. So we are doing our utmost to make sure the pieces fall into place.
Our minimum todo list for input that will enable Wayland to be on parity with X for at least 90% of our users is as follows:
keyboard works as-is
mouse supports left/right-handed button mapping
mouse/touchpad middle mouse button emulation
touchpad scrolling and tapping
touchpad software-emulated buttons work on clickpads
But there are of course other items on here too, like Wacom tablet support, which is of interest to a much smaller segment of our users, but still important to get done. We might have to push some of these more niche items onto the F22 timescale.
Also if anyone is wondering about game pads and such, we don’t have any concrete plans around them currently in the context of Wayland, as when we spoke to Valve and the SDL team they currently access game controllers directly through the kernel interfaces, and preferred to keep doing that. So we decided not to try to second guess them on this considering they been doing game development for years and we haven’t
With the growing popularity of ChromeOS and Chrome applications we have been doing a little research project inside Red Hat to make such applications a bit more integrated into your Fedora desktop. As you might know if you go into the ‘Tools’ menu in Chrome/Chromium there is an option called ‘Create Applications Shortcut’. If you choose that you can turn any web page or chrome application into something easily reached directly from the desktop, and especially with a lot of ChromeApps now working offline this is a quite nice feature. But there are some issues with this setup. First of all it uses the appicon as the application icon, which looks really ugly compared to the other icons on your desktop, secondly it is a little cumbersome to have to go into that menu to set up your application and lastly there is no way of uninstalling it again save from manually deleting the generated .desktop file.
Well our resident Webkit developer, Tomas Popela, has created a Chrome/Chromium extension which you can download from using this link.
To install it you need to go to the extensions page (chrome://extensions/) and enable ‘developer mode’. Once you have done that you can for instance drag and drop the created extension onto the Chrome extension page to install it. Once it is installed it will automatically create a desktop entry for any application you install from the Chrome store, using a nice looking icon. It will also remove the entry again once you uninstall the application.
Some screenshots of this feature in in action.
Unfortunately the shelf life of this extension is limited as its relying on Chrome supporting npapi, which it will stop doing in April according to current plans. But we are trying to work with Google to see if we can make this standard functionality going forward.
We sometimes grumble a bit about Google in the community when they do things we feel are not generally helpful to the overall community. But I think we should be equally good at saying thanks when Google do great things. So thanks to our LibreOffice superstar Caolán McNamara I was made aware that Google has released two new open fonts along with Chrome. So what is so exciting about a new font you say?
Well one of them, called Carlito, is metrically compatible with the current MS default font called Calibri. You can get the font here. It is licensed under the OFL 1.1.
So for those wondering what metrically compatible means, I for sure did when I first heard the term, it basically mean that while the individual glyphs in the font doesn’t look like the Calibri font (that would not be legal), each individual letter has the same height and width as their Calibri counterpart. This means that if you import a document using Calibri into LibreOffice and you don’t have Calibri or a metrically compatible font installed, your document layout would change as the font LibreOffice would need to use instead have letters that might in general be slightly wider for instance. So with Carlito installed this will no longer be a problem, the glyphs might look a bit different, but you can be sure that the overall layout stays the same.
And for certain professions that can be crucial, for instance try speaking to the legal team of your company about them using LibreOffice and they are likely to tell you that they will only do that if they can feel certain that when another lawyer sends them a contract, the layout will not change when they view it, as such changes could at least potentially be the cause of a dispute over the meaning of a paragraph. (That worry was probably the main reason the legal profession stayed with Word Perfect for such a long time, when the rest of the world had moved on.)
So we are now going to get this new font packaged for Fedora and Red Hat Enterprise Linux so soon as possible, to make your productivity experience even better
The GStreamer Conference 2013 Schedule is now live and as you can see there are a lot of great talks this year too, ranging from OpenGL integration, embedded hardware, new codecs and more. As always the GStreamer Conference is the best place to be to discuss the challenges of multimedia.
The conference will be held on the 22nd and 23rd of October so I strongly recommend you get yourself registered. If you want to attend ELCE or the Autotmotive summit make sure to register for those too and extend your stay in Edinburgh to also cover the 24th and 25th of October.
Looking forward to seeing you all there.
And last but not least, a big thank you to this years sponsors of the GStreamer Conference, especially Platinum sponsor Collabora. Also a big thank you to sponsors Fluendo, Google and for the first time this year Cisco.
Thought I post another update with some more news on what we are doing here at Red Hat in preparation for our continued push forward for Wayland on Fedora. Peter Hutterer posted his first draft of the Wayland protocol extension to handle Wacom tablets, you can find more details in his Google Plus post. This effort is also a good illustration of our approach to the Wayland switchover, it is not just about working on some high level bits to port them over to existing APIS or protocols provided by Kristian Høgsberg and the other core Wayland devs, but actively contributing to the whole stack where needed.
Our biggest challenge currently is with XWayland, due to some internal projects that had to get priority we have not had the amount of time we hoped to worked on it yet, but we hope to rally a bit in order to get it to a state in F20 where we can at least have our GDM Wayland session working.
I would also like to point out that I seen some headlines around the web where people are excited about the Wayland work happening in Fedora and around GNOME 3.10. And it is exciting as things are falling into place very fast these days for Wayland, but still I ask people to keep their cool a bit as we are branding it a tech preview in F20 for a reason. So for developers we hope that this tech preview will provide an easy to use harness for running Wayland and testing your applications against Wayland, but in no way is this tech preview going to be something that an end user would even want to run. So when I see Slashdot headlines like “GNOME 3.10 Is Now Properly Supported On Wayland” I get a little worried because to me such a headline implies that things are in a much more mature state than they actually are. Our expectation and hope is to have something that can be considered fully working and ready for end users in the Fedora 21 and GNOME 3.12 timeframe, and that is the releases in which I feel such headlines are likely to be warranted.
So yes, the Wayland stuff we are working is cool and I think we have some killer features planned to be deployed on top of it, but lets do this right and not jump the gun here.
So our team here at Red Hat have been working intensively with our counterparts at Intel to merge and stabilize the patches to enable Wayland support in GNOME and at the same time looking into what further improvements are needed in the stack. Enabling Wayland support means essentially turning the GNOME Shell into a Wayland compositor as we are not going to be using the sample compositor Weston. Porting to Wayland isn’t just about replacing X calls with Wayland calls, in many cases there is also functionality that was in X that will be done as a separate library for use with Wayland or settings that used to be handled by X that now needs to be stored elsewhere. The development work is starting to come together now and tarballs are being released with initial Wayland support or core modules such as Mutter.
The goal we are still pursuing is to have a tech preview ready for Fedora 20. So what do we mean with a tech preview? Well there will be a quite a few things missing or maybe not working as expected. What we hope to have ready is a system where you can have the option of a Wayland session available in GDM, so that instead of logging into your normal X based session you log into one running Wayland instead. Once in that session you should be able to launch and run some applications, but stability is likely to not be great and we don’t know how well XWayland will work by then, so you will also likely having limited mileage with applications that still rely on X. The goal for the tech preview is not to create something an end user is likely to find very useful, rather it is about lowering the barrier for developers and contributors to get involved and start preparing for the Wayland future.
But we do think that it will at least be in a state where developers can easily start playing with it and where the community can help us find issues and bugs, so that we can reach our goal of having a full featured and stable GNOME running on Wayland ready for Fedora 21.
As a sidenote, our top priority is to make sure that the transition from X to Wayland becomes something an end users doesn’t really need to care about. So the final switch to Wayland over X will only happen once we are as sure as we can be that our users will not be negatively affected by the change. So if we default to Wayland or X for Fedora 21 is still an open question, we hope to default to Wayland of course, but staying with X as the default for one more release is not considered unreasonable if it will help us ensure a smooth transition experience for us users. We have of course also not forgotten that many of our users use the binary graphics drivers so we are working on making sure we have an answer ready for that going forward.
You can find details on the status of the tech preview if you go to this website.
Fedora, Red Hat, GStreamer and more
Bad Behavior has blocked 703 access attempts in the last 7 days.