Re: [Rhythmbox-devel] Rythmbox GUI Rework

[Sean McNamara <smcnam gmail com>]

On Sat, Jun 5, 2010 at 12:02 PM, Edgar Luna <edgar lunadiaz net> wrote:
> On Sat, Jun 5, 2010 at 4:20 AM, Jim DeVore <jamesanthonydevore gmail com> wrote:
>> Good Day!
>> I asked a few weeks prior about changing the interface for rythmbox.
>> One fellow replied, but we could not figure out how to change the interface.
>> How Do I modify the GUI? Just point me to the file, and I will go from
>> there.
>
> I going to quote the part of the answer that seems relevant to me in
> that threat:
>
> "I doubt some kind of "eye-candy" would be accepted by the devs.
> Rhythmbox is definitely designed to the functional, user-friendly and
> accessible, following the GNOME principles, rather than providing
> useless eye-candy."
>
> There has been many requests for changes in the UI, many mockups, many
> requests for themes and so. But none of these is never done, and I
> think, is because no developer really cares about it. Usability is a
> big part on rhythmbox and usually this requests don't help in that
> sense. For example what you may see as "wasted space" I easily look at
> it as a clean interface.
>
> Now if you want to change the UI, in the sources shell/ grep for "gtk_".

I agree with everything Edgar wrote, but I want to expand on a few things.

Significant parts of the Rhythmbox GUI are not just glade files. For
design reasons, the main UI is constructed in C by inheriting (in the
object-oriented sense) from base GObjects of varying types. Custom
widgets are in widget/ and the shell is in shell/. Parts of the UI
that could fit in glade files are either in the plugins directory
(each plugin often has its own Glade or GtkBuilder file) or in
data/ui.

Maybe, with recent improvements to Glade / GtkBuilder, it may be
possible to re-write the shell in a way that all the widgets are
constructed using Glade and we don't create any custom Gtk widget
classes. Would that be more or less efficient? Would it simplify the
design or make it more complex? I honestly don't know. But it seems
that in the current implementation there are some special Gtk widgets
designed specifically for RB (by inheriting from other widgets) that
either make the design more robust, or make it possible in the first
place, by overriding core widget functionality.

Another really interesting possibility would be to rewrite the
Rhythmbox core in Vala, like some folks did with the Cheese program.
At the very least, this would greatly enhance code readability, and
eliminate a lot of GLib boilerplate (actually, that boilerplate would
still exist; but Vala would generate it for us at compile-time.) Maybe
such a rewrite would make it easier for someone to do UI
customizations. The process of inheriting from a base class in Vala is
insanely easy compared to doing so in C.

I really like the way Rhythmbox has been kept simple for the purpose
of usability. Maybe, once Gnome-Shell and other major Gnome components
show some successful, stable releases using Clutter (backed by
OpenGL), it might be prudent to try the same sort of redesign for the
Rhythmbox GUI. It would be a waste to simply port the existing RB UI
design straight to Clutter without any changes, because there are many
"whizzy effects" we can take advantage of in Clutter, hopefully in a
way that borrows from existing practice in Gnome-Shell and other Gnome
3.0 apps. Or maybe we can be the trendsetters, coming up with the best
practices on our own! That would be fun, too. Composited,
hardware-accelerated scene graph technology opens up a lot of new
possibilities for UI design, but we need to use this new platform in a
way that preserves Rhythmbox's core goals.

Since Rhythmbox is FOSS, you basically have two possibilities when
you're working on a project like this. One, work in tandem with
mainline and convince them to accept your changes. Two, you can ignore
mainline and fork the program, just doing your own thing. If your
version gets very popular or the mainline devs change their minds,
they may merge your changes, as evidenced by past happenings like
egcs.

My opinion is that, if you think you have some promising ideas for
improving Rhythmbox, you should *do it*! Work on your project
regardless of the maintainers -- don't worry about whether mainline is
going to merge your changes or not. Just produce the code, make it
publicly available, let distros and users know about your changes, and
also ping the Rhythmbox maintainers. If the maintainers think your
changes improve Rhythmbox under their own (necessarily) subjective
definition of "improve", they will likely merge them to the mainline.
Otherwise, your project can compete for users with mainline Rhythmbox
by allowing each user to decide which version they want. Regardless of
the outcome, it can only be good for the community, although I think
the better alternative of the two is the case where your changes are
indeed merged to mainline, provided there is consensus that they are
beneficial changes.

HTH,

Sean

>
> Regards,
>
> --
> Edgar Luna
> _______________________________________________
> rhythmbox-devel mailing list
> rhythmbox-devel gnome org
> http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
>