Judging from Rhythmbox internal's, messing with the UI should be a difficult task, as most aspects of Rhythmbox are directly tied to their visual representation (a lot of objects are subclasses of widgets). So, whatever happens to this fork, I suppose it would be difficult to reintegrate their code into Rhythmbox, unless they are refactoring all the UI code in Rhythmbox. And to be honest, even if we don't agree with their changes, it still a valid point they make if they want to change the UI to something else. So, I think maybe Rhythmbox should try to have some separation of logic and UI, so that changes like that could be handled more easily and forks are not necessary just for moving stuff out of place.
And some of their changes might even be good to put some fresh air into Rhythmbox. *Alexandre Rosenfeld* On Wed, Sep 22, 2010 at 18:14, Jonathan Matthew <[email protected]> wrote: > On Thu, Sep 23, 2010 at 7:56 AM, John Stowers > <[email protected]> wrote: > > Hi All, > > > > I expect some of you might have seen this by now, but the elementary > > folks have started their own Rhythmbox fork [1]. It might be useful for > > some inspiration. > > Judging by the first few screenshots, it's pretty unlikely. Their > approach seems to be to throw away any UI elements that might give the > user a clue how to use the application and squash everything that > provides useful information until you can't read any of it. I'd be > happy to discuss their ideas with them and see how they fit in with my > (nebulous, unresourced) plans, but if they're more interested in > forking the code, renaming things, and hurfing up a bunch of > screenshots on recreational outrage sites like omgubuntu, that's OK > too. > _______________________________________________ > rhythmbox-devel mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/rhythmbox-devel >
_______________________________________________ rhythmbox-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
