On Tue, Aug 11, 2009 at 16:43, P.G. Richardson <p.g.richardson@phantomjinx.co.uk> wrote:
Afternoon all,

Have been musing over this possibility for a while now and wanted to
canvas opinions...

gtkpod has acquired a fair number of features over the years, some
essential and others irrelevant. I am sure other people are completely
different in their choice of features to me. Consequently, I have been
exploring ways to add a plug-in framework to gtkpod so that features could
be broken out into separate plug-ins, making the core app lighter and
custom installations more flexible.

I came across ethos (http://git.dronelabs.com/ethos/about/) as a gtk+
plug-in framework that I am looking into as a first step. My initial idea
would be to break the coverart window out into its own plug-in since I
know that code the best.

My other consideration is redoing the UI of gtkpod as an Eclipse RCP
application using java (and one of the java -> C binding libs). Benefits
being that the Eclipse RCP framework is very sophisticated (and I have
played with it a fair amount). Such an idea may not fly with
everybody/anybody so this may become a subproject for those that are
interested. I dont imagine it would ever replace the native UI but be an
option unless people were so keen on it then it became the preferred

Anwyay, this is to start the ball rolling so any constructive comments,
thoughts ...

This is an exciting topic. You get +1 on both ideas from me as a user and very casual contributor. However, I'm not a core team developer, and I don't think I can dedicate much of my time to help you.

If you don't care about my ideas, you can stop reading here :-)

I've previously worked on some changes to the current GUI code, and it does show signs of ad hoc design. In many places the separation between GUI components and behavior is not very clear, there are lots of blocking points that freeze the GUI, etc. A clear model for separating functionality into plug-ins, plus a richer set of widgets, would surely benefit both the users and the developers/maintainers.

Moreover, if I remember correctly, at some points the separation between gtkpod and libgpod is unclear. I understand gtkpod is doing some things that should be in a library, but aren't, yet. That should be a concern if you are planning a new GUI from scratch.

Last, but IMO not least, I think gtkpod would be more accessible both to users and developers if it tried to do less. No doubt that every single feature was supported by at least the developer who implemented it, but the overall result is overwhelming. My work on optimizing the library management ended up affecting completely unrelated features that, as a user, I didn't even know existed. I think this point of view supports the idea of writing a new GUI, that's optimized for specific typical tasks. E.g.:
Good compartmentalization makes the application more user friendly, but also easier to extend without fear of breaking other parts. Also it allows potentially better optimizations. For instance the current track listing shows everything, which for large collections is very slow (and it used to be almost unusable). It is done this way because it has to support many disconnected features. But if you had a view tailored to each feature, then no doubt it would be easier for a developer to write more efficient code (not to mention more efficient for the end user, too!).

I've personally thought of doing this many times, but two things stopped me. First, I don't have much experience with GUIs or GTK+, so I felt the project would never take off; second, I only care about adding and removing tracks, so it would probably not get much user adoption. Or would it? In any case, I got lazy, so I just fixed the parts of gtkpod that itched me most.

Hope it helps,