Desktop Application Selection for Maverick

Categories so far: Browser, Image Viewer & Editor, Music Player, Messaging Client, Other
See below for a pro/con on each one.

A table listing CD size requirements for each app (and/or dependencies) would be useful here.
– Something like this? Can one make real tables here?
I got the size from »Download« in Synaptic, in case that’s wrong.
Tried out apt-rdepends for dependencies, too many to list effectively. I installed some from a clean install.
And to everyone at UDS: Have fun. :)

Browser
 Firefox; 10.9 MB; depends on ?
 Chromium; 21.1 MB; depends on ?
 Midori; 0.8 MB; depends on javascript-common, libjs-mootools, wwwconfig-common
        Epiphany; 1 MB

Image Viewer & Editor
 Eye of GNOME; 0.4 MB; depends on ?
 F-Spot; 1.4 MB; depends on ?
 gThumb; 3.1 MB; depends on ?
 Shotwell; 1.0 MB; depends on libgee2

Music Player
 Rhythmbox; 1.2 MB; depends on python-mako
 Banshee; 3.6 MB; depends on libboo2.0.9-cil, libgdata1.4-cil, libmono-zeroconf1.0-cil, libnotify0.4-cil, libtaglib2.0-cil, libwebkit1.1-cil, podsleuth

Messaging Client
 Empathy; 1.3 MB; depends on ?
 Pidgin; 1.8 MB; depends on ?
Other
 Thumbnailers; < 0.1 MB; depend on ?

=== Browser ===

[inquata 2010-05-03]
I guess so. Just the amount of bulky chrome in Firefox is almost enough to default to Chromium.
Firefox standard install:
• title bar
• menu bar
• navigation toolbar
• bookmarks toolbar
• tab bar
• status bar

Chromium:
• tab bar + title bar
• navigation toolbar + menu bar
4 bars combined to 2. Additionally, bookmarks toolbar and status bar are on demand by default.

[winniemiel05 2010-05-05]
Mozilla is doing work to change is UI. Maybe it's better to wait and see, it seems they want to do something like in chrome, with less lost space. See :
      http://www.generation-nt.com/firefox-4-theme-interface-utilisateur-actualite-1001101.html
and
      http://blog.stephenhorlander.com/2010/04/20/theme-status-timelines-panels-and-progress/
Maybe asking Mozilla what they will do before anything

[inquata 2010-05-05]
Right, I forgot to take Mozilla’s progression into account.
We may have to wait for the benchmarks there. Speed is what matters most to users: http://chrome.blogspot.com/2010/05/pedal-to-chrome-metal-our-fastest-beta.html

The other important part is usability:
The Chromium preferences for one are much simpler than Firefox’s – though they are beginning to complicate.

An advantage of Firefox is the consistent looks with other Ubuntu applications. Especially that of the scrollbar, which I often have hard times to differentiate from its background in Chromium.

[amano 2010-05-05]
Replacing Firefox with Chromium might be a reasonable idea if it blended well with the rest of the desktop. Chromiums sandboxing features are convincing. Usablility-wise I have to moan about the lack of a proper bookmarks sidebar. With current widescreen monitors the bookmarks/history sidebar of firefox is ideal.

[humphreybc 2010-05-06]
What about Midori? It's as fast as Chrome (in some cases faster), it uses GTK (a very important feature with the new windicators work planned for Maverick, not to mention the buttons on the left), respects the system theme and it has a small profile which makes it ideal for the netbook edition too. Plus, it supports the global menu project. It has a few things that could be improved like bookmark management, but it wouldn't take a lot of work to sort that stuff out.

Also, I would recommend Google Chrome over Chromium. Google Chrome has flash built-in now, thanks to a recent deal Google did with Adobe. This would enable us to ship flash by default legally, offering the greatest web browsing experience. Google Chrome is also a lot more stable that Chromium in my experience.

[dpm 2010-05-06]
Chromium and localization: after a quick search on the Chromium website, it is not clear to me how it can be translated by the community. On Ubuntu there is a chromium-l10n package that reportedly contains translations for 50 languages, but I could not find any information neither on who did those translations nor how new languages can be added by the community.

It also seems that Chromium is using yet another localization technology, which most certainly will not be supported by Launchpad in the near future, so Chromium would not be translatable there, either.

[inquata 2010-05-06]
humphreybc, problem with Google Chrome would be the branding, I suppose. Also, nearly every feature from Chrome bleeds into Chromium and the other way around, so it would be better to go with the unbranded version.

Regarding Midori: It is nice and lightweight, but does not have the vast amount of addons some users are used to. Installing userscripts does not work that easy either (in Chromium it is click and go). And it has an extra search bar in addition to the location bar – nowadays that is just interface cruft. People are typing »facebook login« into their location bar anyway (which is why it should not be called location bar *cough* omnibar).

[humphreybc 2010-05-07]
"And [Midori] has an extra search bar in addition to the location bar – nowadays that is just interface cruft." The toolbar can be customized using the "Customize toolbar" extension. I'm sure we could quite easily fork Midori and customize the toolbar to how we want it to look by default.

As for Chromium/Chrome, I still don't believe it's a viable option simply because it's not GTK - it doesn't support the new window controls on the left, nor will it support any global menu stuff or windicator stuff. It also doesn't have the right click menu for managing windows between workspaces. All of this can be rectified by enabling the GTK window border, but that adds another chunk to the top of Chrome, thereby rendering the entire concept of the tabs _in_ the window border to save space useless.

Midori is GTK, it's faster than Chrome in most areas, and it's stable. It can be easily forked, it has just the right amount of features average users will need in an internet browser without cramming in junk, and with a bit of development work could be totally awesome. I think it has the most potential with the least tradeoffs.

[om26er 2010-05-07]
@humphreybc: Remember this is not a spec for UNE. No one uses Midori but users are quickly moving to chromium thats why it was considered :) for chromium not using the window border of the default theme there is/was a reason which client side window decorations can solve. Even in lucid cycle when the csd patch was uploaded chromium devs were willing to implement this(even if it was not in gtk officially). Chromium is secure,fast and sleek :)

[winniemiel05 2010-05-08]
Another VERY big problem if firefox isn't used by default is banks. Lot of banks accpet only firefox as linux web browser to consult online. Exemple : Banque Populaire in France.
But I agree, today Firefox become to complicated, and with flash it's horrible.
About design:
The use of system windows bar in chromium isn't a problem at all. I use it, with the ambiance theme for chromium, and it feel very good.
If firefox kept here, maybe it should be a good idea to integrate firefox ambiance personna by default, it integrate very very well.

[ddecator 2010-05-08]
For those who are interested in Chromium for the speed, I would just like to point out that Mozilla is working on JaegerMonkey which should make Firefox much more competetive with Chromium in terms of speed:
http://www.bailopan.net/blog/?p=683
https://wiki.mozilla.org/JaegerMonkey
In my opinion, Firefox is showing enough potential to warrant keeping it as the default. It's what people are used to, and people might not like being switched to Chromium for Maverick and then possibly back to Firefox for Maverick+1. If the new UI design and JaegerMonkey don't live up to their claims, then I think Chromium can be considered.

[jjardon 2010-05-11]
What about Epiphany?
It's a modern browser based in webkit that supports lots HTML5 features (like <video> tag through gstreamer).
Also It's the default browser of GNOME desktop an It integrates very well with the whole desktop.

[ddecator 2010-05-11]
Here is a slideshow showing what Mozilla plans for Firefox 4, which will bring huge improvements: http://www.slideshare.net/beltzner/firefox-roadmap-2010-0510?from=ss_embed

[danny.piccirillo 2010-05-15]
If Midori would be considered, i don't see why we shouldn't just go with Epiphany. Personally, i don't think it's ready, as much as i wish it was. Chromium might be good in the meantime though.

[olafra 2010-05-19]
We are competing against Windows and I think we need to take into consideration the path that ie9 is taking. Accelerated graphics through GPU. We pick the one that commits to taking this strategy, simple. In Firefox 4 they talk about using DirectDraw which I think is an awful strategy because it only works on Windows, plus the version hell. And OpenGL is better, plus shader codes. I've tried to find a similar thing in Webkit but I haven't found it yet. We are going to loose big if we don't take this into consideration.

=== Image Viewer & Editor ===

[amano 2010-05-05]
I would consider Solang or Shotwell to replace the bulky F-Spot.

[rickspencer3 2010-05-05]
@amano - can you provide some more analysis of the F-Spot to Shotwell trade off?

[amano 2010-05-05]
Solang is a C++ photo editor that does't use a complicated Database for importing and exporting and should be more intuitive for new users. I might try to create a discspace vs. RAM usage vs. feature vs. usability overview by the weekend. I hate the tendency of F-Spot to duplicate pictures on your harddisk (original location, ~/Photo folder and inside the database as well). If there are thousands of pictures to be imported, you might easily run out of disk space. And database corruptions/confusions are not impossible as well.

For now I can offer this video review of the Vala based Shotwell: http://linuxfilesystem.com/uncategorized/shotwell-photo-manager-for-gnome-linux-mint-8. It is database driven and doesn't recognize if you added new files to one of your photo folders (same for F-Spot). Thus new photos have to imported manually which can be tiresome. The C++ based Solang uses Tracker 0.8 to check the photo folders and SPARQL is used to gain access to the meta information about the photos. This approach looks perfectly sane but with its current version 0.4.1 it lacks the option to crop and resize files (http://git.gnome.org/browse/solang/tree/TODO?id=SOLANG_0_4_1) which is rather a "must have" since the removal of the GIMP (given that the simple-image-management blueprint doesn't bring to life a 'simple scan' for image editing). On the other hand it is developed at a rapid pace and those options might be included by the maverick feature freeze. To get a sensible decision in favor of Solang the authors should be contaced first. Shotwell on the other hand is not too different from F-Spot but is developed faster and performs better than the current default.

[humphreybc 2010-05-07]
Why don't we replace Eye of Gnome with gThumb? It has all the features that EOG has, but with some basic image editing like cropping, red eye removal, brightness chucked in too.

[amano 2010-05-08]
Yes, the new gthumb development branch looks very promising. Version 2.11.3 from mid April even added a flickr importer and exporter and a facebook exporter (the latter is an extension that has to be enabled first). It uses the database of Nautilus to store the thumbnails but doesn't use a database to import the pictures as a whole. And you are right to question the current Ubuntu approach to split the image related tasks into Eye of Gnome and F-Spot ones. Gthumb could replace both of them.

[inquata 2010-05-08]
Regarding merging image viewer and editor, please also see the related blueprint: https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-simple-image-management
(Is it possible to link blueprints?)

[danny.piccirillo 2010-05-15]
I would put a serious vote down for Solang for the same reasons that Telepathy and PitiVi were chosen as deafult: Solang seems to want to integrate and do things properly. Check this out from their FAQ (http://live.gnome.org/Solang/FAQ):

"Why write yet another photo manager? F-Spot, GThumb, J-Brout, Shotwell, etc. rock.

In our opinion none of them integrate well with the desktop. They need you to explicitly import photos from a directory and any meta-data that you add (mainly tags) get inserted into their private database. We do not do that anymore. We use Tracker (http://tracker-project.org/) for these purposes. It allows us to automatically detect all the photos on your computer and any meta-data that is added gets inserted into Tracker. So if you tag your photos in Solang, you can use those tags from any other application on the desktop (eg., Nautilus), and vice versa."

[davidnielsen 2010-10-22]
I would suggest going back to using F-spot, the fears that F-spot would not be able to be maintained by the community have been utterly shamed by it's new maintainer RubenV who revitalized F-spot and managed to grow a community around the new code base. Progress has been astounding and the roadmap includes even greater code sharing with Banshee, more features and UI work. We are still supporting F-Spot on LTS and for these types of uses Ruben has introduced an LTS promise for the 0.8 branch of F-spot. It is the horse to bet on in the photo management race.

=== Music Player ===

[amano 2010-05-05]
I would consider to replace Rhythmbox with Banshee, which finally got support for gapless playing (not for LAME MP3s yet, but rhythmbox cannot handle that either).

[qense 2010-05-07]
The advantage of using Banshee over Rhythmbox would be that -- with a bit of work -- the 'Ubuntu One Music Store' could be turned into a 'Ubuntu One Music and Video Store', something there is probably a lot of need for, but not much choice in.

[vish 2010-05-07]
@qense: Banshee has a few UI problems , but the most frustrating problem is the browser view is stuck with only "All Artists" view , which makes the browser view unusable in certain locales. [which is not a problem in RB]

[qense 2010-05-08]
In that case, how hard would it be to:
1) add a video catalogue to Rhythmbox
OR
2) fix those issues in Banshee?

[jmatthew 2010-05-10]
adding video support to rhythmbox is a fair bit of effort and requires some extensive internal changes. Not having seen much motivation for it besides "banshee does it" it's a pretty low priority at this stage.

[amano 2010-05-12]
The only technical obstacle against Banshee would be its current use of HAL. There is already a branch to get rid of it (Alex Launi works on it): http://gitorious.org/~lamalex/banshee/lamalex-udev/commits/master . I can't guarantee that this branch will get merged on time for the 1.8 release but I think that this de-halsification is on top of their priority list.

[davidnielsen 2010-10-22]
Banshee 1.8.0 no longer depends on HAL, it has excellent integration with Ubuntu specific technologies such as the SoundMenu and Application Indicators. The development pace is nothing short of amazing and the community which has grown around Banshee has proven to be welcoming and swift to fix bugs. Banshee has multiple UIs which suits Ubuntu well for deployment on UNE as well as the desktop.

=== Messaging Client ===

[mmiicc 2010-05-07]
Please consider adding proper IRC client or fixing Empathy.
Currently using Empathy as an IRC client is horrible experience. Take a look at this article, which quite good describe all the troubles: http://rww.dreamwidth.org/6196.html Participating in Ubuntu Open Week, for example, required IRC connection.

[humphreybc 2010-05-07]
As for instant messaging/IRC clients - Pidgin should go back to default, end of story.

[mmiicc 2010-05-10]
What about VOIP application? It use to be Ekiga before. Now there's an option to add your SIP to Empathy. Unfortunately, Empathy doesn't store phone numbers, so it's very unfriendly to use. You have to every time type phone number you want to call. I can recommend an app called SFLphone http://www.sflphone.org It look nice and simple and has option to integrate with Evolution's contact database.

=== Other ===

[inquata 2010-05-06]
They are not really desktop applications, but what about having the thumbnail factories installed by default? They are very convenient to quickly identify the right file and folder. Also that is often requested by users switching from Windows.

Some suggestions:
gnome-exe-thumbnailer, gnome-raw-thumbnailer, gnome-xcf-thumbnailer, ffmpegthumbnailer, imagemagick, libgsf-bin, ooo-thumbnailer, maybe even http://launchpad.net/cover-thumbnailer (as soon as it supports thumbnail folder icons)

[winniemiel05 2010-05-08]
Maybe integrate a wallpaper application like drapes (http://drapes.mindtouchsoftware.com/), wallapapoz (http://wallpapoz.akbarhome.com/), or any other. This is very asked around me, and if it has to be integrated in any release, I think Maverick is the good one: the release in which mark sayed he wanted to integrate lot of new features.

[amano 2010-05-10] The limitation of X to not paste content from an application that gets closed causes a lot of gripe for people used to the behaviour of windows: https://bugs.launchpad.net/ubuntu/+bug/11334?comments=all The inlcusion of Parcellite by default could ease those pains - at least for text content ;) Note that KDE opted to install a clipboard manager by default to overcome this limitation of X. Maybe a stripped down to the absolute basics Parcellite fork (Ubuntu ClipBoard) could be created beacuse from now an Parcellite doesn't seem to maintained anymore.

I think that it would be handy for linux newbies to include Nautilus-Open-Terminal by default as well. To let them have a quick access to certain folders without knowing about the linux syntax to navigate to the /home or root folder of yout filesystem. Them they can copy and paste commands from Firefox.

[danny.piccirillo 2010-05-15]
I don't feel strongly about this but it seems that Pino might be quickly outdoing Gwibber. Would it be worth replacing?
http://pino-app.appspot.com/