gnome apps

Jérôme Guelfucci jerome.guelfucci at
Fri Feb 1 21:19:40 UTC 2008

One point is of course performance, why would we provide such detailed
benchmark ??? I don't remember anybody having done that in the Xubuntu
Team, and I wonder if other teams do so. But if you have some time to
provide all those informations, please do :)

The other point is that those applications are all part of the XFCE
desktop "suite", and it makes more sense to follow upstream. This is
done in every distribution, for example I know that man members of
Ubuntu Desktop Team do not like Seahorse, but they still ship it has
default because it has been decided so upstream (if I understood


It's not just enough that an application has a responsive developer,
if it's not used in other distributions/desktops (and found to be
working well), it will be XFCE users that "discover" these bugs.

This is just why we switched applications at the beginning of the
development cycle, to be able to test them, to file bug and features
requests, most of which have already been adressed. I personnaly filed
features requests for ristretto which were fixed within less than a
month. I think this is more useful than saying "It's buggy, it's
unmaintained... Let's put Gnome stuff.", this one solution, but this
is not a long term solution, if xfce applications had been integrated
earlier, they would have been tested much more, bug reports could have
been filed and they could have been adressed upstream. It's only by
doing this that XFCE will become more user friendly, and stable.
Trying to compensate its actual defaults might be a solution for short
term, but I think this is a mistake, we just postpone everytime large
scale usage of XFCE applications... How do you think that Gnome did
get all those features & stability ?

Of course there are execptions like Xfmedia, and Xfburn, which are
totally crashy and unusable. Xfmedia has been recently improved a bit,
audio works again for me :), but video still crashes every time.
xfburn is totally unusable, no need to speak of it. In this case, it's
really impossible to ship them and alternatives have to be found.
Brasero is already part of gutsy, and will remain in Hardy because
it's almost the only gtk burning application still maintained.

We still have to find the "perfect" multimedia player. Audacious is
great, but it's only for audio files, we need something for videos.
All suggestions are welcome, if nothing is found, I think that we will
stick with Totem.


On Feb 1, 2008 9:54 PM, Eero Tamminen <oak at> wrote:
> Hi,
> On Friday 01 February 2008, Lionel Le Folgoc (mr_pouit) wrote:
> > There are several people subscribed to this mailing list, they can all
> > give their opinion about the choices we made on the seeds. If most of
> > them think we should revert all these changes and put the seeds back to
> > where they were in 7.10, of course we'll revert.
> Are there other changes besides what Jani mentioned?
> > But your opinion counts only for one vote, and so far, two people said
> > that xubuntu gutsy was slower and heavier than the previous releases.
> What things exactly were slower and heavier and what evidence you have that
> these changes help for that (in general)?
> For now these changes seem more like random breakage against existing
> functionality & documentation... :-)
> > So for the moment, the seeds are not going to change.
> >
> > I would be glad if as many people as possible on this list could give
> > their opinion about the seeds[*], this way we could really call this an
> > open development process...
> You need to provide more information.
> Slowness/heaviness could be split to several categories:
> - System/desktop startup speed
>   -> can be measured with a clock
> - Application startup speed
>   -> can be measured with "xresponse"
>   -> can be analyzed with callgrind/kcachegrind
> - Performance/responsiveness (first visible response to user input)
>   -> can be measured with "xresponse"
>   -> can be analyzed with "ltrace"
> - Performance/general (how long things take to finish)
>   -> can be measured with a clock or "xresponse"
>   -> can be analyzed with oprofile/sysprof/callgrind
> - Resource/memory usage (blocker for people with little memory)
>   -> "Writable" and "X server" fields in gnome-system-monitor are
>       the best measures for this
>   -> can be analyzed with massif/valgrind
> - Battery usage (most important for laptop users)
>   -> Can be checked with "strace -p PID" on the given app to see whether
>       it wakes up more often that at few sec interval.  Xresponse or Xephyr
>       can be sometimes also useful
> - Network usage (most important for thin client/remote users)
>   -> screen updates of an application can be checked either with
>       xresponse or running it under xserver-xephyr
>   -> other kind of network activity can be checked with strace
> And these should be weighted against features / their importance and
> robustness / maturity of the software.  It's not just enough that an
> application has a responsive developer, if it's not used in other
> distributions/desktops (and found to be working well), it will be XFCE
> users that "discover" these bugs. Often the bugs are not fixed until
> the next release (in worst case 6 months later which from users' point
> of view means that he says goodbye for that kind of a crappy distro).
> So, what functionality was lost with your changes and what
> non-/improvements there were from them (e.g. in above categories)?
>         - Eero
> --
> xubuntu-devel mailing list
> xubuntu-devel at

More information about the xubuntu-devel mailing list