I've always felt that we should be able to have multiple shells.  Rhythm is
a nicely broken up into modules so you should be able to replace any one
part.  Trying to find the one gui that works for everything is somewhat
silly.  I rather have have a family of shells that work with people's
musical taste.  Certainly better than hacking your own media player just
because you don't like the way screen real estate is used.

sri

On Sun, Jun 6, 2010 at 7:23 AM, Edgar Luna <edgar.l...@gmail.com> wrote:

> On Sun, Jun 6, 2010 at 1:25 AM, Michael Gratton <m...@vee.net> wrote:
> > On 06/06/10 04:47, Sean McNamara wrote:
> >> Another really interesting possibility would be to rewrite the
> >> Rhythmbox core in Vala, like some folks did with the Cheese program.
> >
> > Yeah, I've wondered about doing this too, although I was thinking of
> > using Python. Having a native librhythmbox backend with language
> > bindings that are used by a high-level language for the UI would make UI
> > hacking much easier, while keeping people happy about performance and
> > efficiency of the backend.
> >
> I'm not an expert in Vala, but I understands it gives you syntactical
> sugar for gtk stuff, so is a clear advantage over C. In the case of
> python or any other language is more like: its easier than C and I
> know how to program on it; but I need to handle funny bindings.
>
> Overall I like Sean's idea, now who's going to try do it?
>
> Regards,
>
> --
> Edgar Luna
> _______________________________________________
> rhythmbox-devel mailing list
> rhythmbox-devel@gnome.org
> http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
>
_______________________________________________
rhythmbox-devel mailing list
rhythmbox-devel@gnome.org
http://mail.gnome.org/mailman/listinfo/rhythmbox-devel

Reply via email to