Re: [Gtkpod-devel] gtkpod and extensions

[Javier K. <jk...@gm...>]

On Tue, Aug 11, 2009 at 16:43, P.G. Richardson <
p.g...@ph...> 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
> option.
>
> 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.:

   - adding and removing tracks,
   - browsing and playing music directly from the iPod,
   - photo management,
   - podcast management,
   - synchronization,
   - etc.

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,