Technical Blog of Richard Hughes

First, don’t panic, it’s not some big secret agenda, or any kind of Swedish conspiracy. The Fedora AppStream generator ignores your application if:

• There is no Name or Comment in the desktop file. You need both.
• There is no application icon, or if the application icon is missing or less than 32×32 in size
• Your desktop file has NoDisplay=true
• Your desktop file does not have Type=Application
• Your application ID or package file name has been blacklisted.
• Your application is really just a settings panel
• Your application isn’t available in fedora or fedora-updates for F20

If you see anything in GNOME Software that you think should not be there, let me know and we can review it. Note, for Fedora 21, i.e. not the Fedora release about to happen they’ll be one extra point where we will disqualify applications:

• Your application does not contain a .appdata.xml file with at least one screenshot.

So that’s 6 months to get your AppData files upstream before we get all strict. Go!

Thanks to the always-awesome Giovanni Campagna, GNOME Software now speaks your language.

 

Do you use or maintain or use any of these application:

Evince, GNOME Calculator, gucharmap, GNOME Clocks, GNOME Dictionary, GNOME Documents, Empathy, Evolution, Nautilus, GNOME Font Viewer, Glade, DevHelp, Eye of GNOME, GNOME Screenshot, Sound Converter, GNOME System Monitor, GNOME Terminal, GNOME Tweak Tool, Totem, Epiphany, XChat, LibreOffice Calc, LibreOffice Draw, LibreOffice Base, LibreOffice Impress, or LibreOffice Writer.

If you can spare 10 minutes to write a three paragraph long description, and fill in the homepage URL I would be very grateful. GNOME Software will look all the more awesome for your contribution.

Just go to the shared document and fill in any details you know. Thanks!

Do you maintain or have commit access or one of these applications:

• echomixer
• envy24control
• hdspconf
• hdspmixer
• hwmixvolume
• alsamixergui
• brasero
• camorama
• cheese
• clementine
• cutecw
• easytag
• flumotion-admin
• fmtools
• gimmix
• gmpc
• gnaural
• gnomad2
• gnome-chord
• gnome-scale
• gnomebaker
• gqradio
• grip
• gtk-recordmydesktop
• gtkpod
• gtkwhiteboard
• guitarix
• gxine
• idjc
• isomaster
• gnome-istanbul
• jack-rack
• kover
• ladi-system-tray
• lash-panel
• lingot
• nxtvepg
• oxine
• pencil
• pianobooster
• picard
• pitivi
• qt-recordmydesktop
• qv4l2
• rhythmbox (bug filed)
• seq24
• sonata
• soundconverter
• sweep
• themonospot-gtk
• themonospot-qt
• v4l2ucp
• vkeybd

If your application is listed here, it will not be in the GNOME Software center as the .desktop file has AudioVideo but not Audio or Video. If you’ve got an app that plays music, you want to have at least “AudioVideo;Audio;” or if you’ve got an app that deals with audio and video you want at least “AudioVideo;Video;Audio;”. The freedesktop menu specification is a little odd in this regard.

If you fix this before 3.10.0 then it’ll magically work in the new software center.

I NEED SOME AWESOME PEOPLE TO HELP ME GET GNOME-SOFTWARE FINISHED:

If you can visit this page and help fill in details for our first set of featured applications, you’d be awesome.

Do you maintain an application that people use? Do you want people to be able to install it easily in the GNOME Software Center?

If both of those are true, please read the newly finalised AppData specification and ship one tiny extra file in your tarball. People will love you for doing it, and I’ll really appreciate it. Maybe post 3.10 we can do a GNOME Goal for all the core GNOME modules, but of course this applies to GNOME, KDE, XFCE and random standalone apps.

This week we will hit a milestone we thought we might not ever reach – selling ColorHug device number 2000. We started making ColorHugs just 18 months ago and have come a long way from the first batch that was hand-built on a desk in our back bedroom. I started the project as a hobby to make some embedded hardware as it was something I enjoyed doing at University and hadn’t done for a while. I assured my wife we wouldn’t need to make more then 50. So imagine how we felt when we got over 800 responses to a single blog post. I only wrote it to check it was worth making that initial batch! So this hobby turned into a second job almost overnight that came with all the fun dealing with customer emails, legal issues and setting up a business that pays tax. Ania was not best pleased when our lovely guest room turned into our manufacturing department and my “hobby” had her screwing devices together on weekends, evenings and even on Boxing Day.

A lot has changed since that first batch.  From outsourcing the PCB fabrication and to occasionally recruiting my mum, dad and of course Ania in the manufacture, assembly, dispatch and administrative aspects of ColorHug. We finally have a new outside office – so after nearly two years we have our house back! And most importantly we have had a little girl, who keeps us very busy and thus has slowed the development of the ColorHug Spectro.

Building an OpenHardware device has definitely been a worthwhile pursuit and something I believe in. We will have built and shipped 2000 devices all around the world, including issuing two lots of free gifts to update early adopters with the latest accessories and design improvements. We’ve also built a large community who are using ColorHugs all over the world for calibrating external screens and panels in domestic and commercial settings.

We still don’t make much profit on each unit and definitely wouldn’t recommend making calibration hardware as a get rich quick scheme, but we have enjoyed growing ColorHug and fostering the community that has built up around it. We’d like to take this opportunity to thank everyone who has helped make ColorHug a success – from those who’ve helped make the device through to those who contribute in the community by testing and reporting bugs.

Some interesting statistics from the last 18 months:

• Total Sold: 1998
• Number of Batches: 8
• Typical number of jiffy bags ready to go at any time: 60
• Number of returns: 8
• Number of automated emails from PayPal: 2520
• Number of emails Ania and I have sent (most semi-automated): 5087
• Number of LiveCD updates: 9
• Number of different countries sent to: 21
• Amount of money spent on postage: £9,354

So, basically, we’re very humbled and grateful! Richard, Ania and baby Hughes.

 

This morning I wrote up this proposal. If you maintain an application that you think should be in the GNOME Software Center, I would appreciate your views. Thanks!

p.s. Don’t actually commit anything to your modules just yet, I want to finish the polishing and wording before asking people to write anything. For example, the format of the long description should probably be much more prescriptive.

Progress on gnome-software is progressing nicely. Most of the major functionality is semi-working, although there are an awful lot of rough (and unimplemented) edges. Now the UI is coming together somewhat, it’s probably time to talk about what data it is going to consume. I’ve talked a lot before about extracting application icon and translations from .desktop files, but now I wanted to talk about long, formatted descriptions. Something like:

So where do we get this long description from? There seems to be many possible places to put this data:

1. On the distribution web service
2. In the ${app}.desktop files of the upstream application
3. In the DOAP file of the upstream tarball
4. In the package file description
5. Some new ${app}.xml file shipped by application with all this extra data
6. Some simple ${app}.md file containing markdown

Each has positives and negatives:

1. All distros have to do basically the same work, and have to retranslate these over and over. -ENORESOURCE.
2. It’s not much fun to do multiline descriptions trying to work on one line in a .desktop file, and trying to do rich text like hyperlinks and bullet points is impossible.
3. DOAP files are not translated, and we only get one file per project, not per app. You probably want a different description for LibreOffice Calc than LibreOffice Presenter.
4. Same problem as 3, and it also pushes the work to the distros, like 1. And it’s not typically translated.
5. YAFF. Yet Another Format. Okay, it lets us define rich text (SGML/DocBook/whatever) but it’s another file format to be added to intltool and I’m not sure how easy it would be to get random projects to ship this.
6. Easy to write, although much harder to extend in the future with things like screenshots and the like. Also, very hard to translate.

Also, anything except option 1 requires the use to have a big cache of all the possible applications they want to search for. So far I’m leaning on some kind of composite approach:

• Add a X-SoftwareCenterLongDescURI key to the desktop file
• Have a web URL with an .xml file on any remote server.
• Download and load the .xml file when the application detail view is opened
• Optionally translate the .xml.in using intltool and update the description at release time
• Applications not shipping .desktop files with X-SoftwareCenterLongDescURI just get a shitty app-detail view in the software center.

Comments, suggestions, flames, all very welcome. If/when we come to a consensus, I’ll write up a proper proposal with some guidelines for application authors. Thanks.

 

The last week I’ve been continuing to work on the hawkey backend for PackageKit. It’s basically a small package manager backend that uses librepo to do the metadata checking and downloading and hawkey to do the depsolving. To glue all of this together and do kinda critical things like assembling and running a librpm transaction I’ve re-used globs of Zif, another little test project of mine.

Today marks a milestone. With librepo from rawhide, hawkey and PackageKit from git you can actually use the gnome-packagekit tools to install, remove and update packages. The latter was quite a bit of work, and I’ve been contributing patches like crazy to the hawkey project making sure all the pieces are in place.

Of course, we’re not doing this for gnome-packagekit, we’re looking forward to the future. If everything goes to plan, in Fedora 20 we’ll have a shiny new software center called gnome-software that will use the hawkey backend on Fedora to perform like a modern software store. No “waiting for locks“. No “downloading metadata” at inopportune times. With the new backend we can make the user experience of the new UI an order of magnitude better than the old tools.

And now, I’m going to eat ice-cream. Have a good weekend everyone.