gtkpod and extensions

[P.G. Richardson]

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 ...

Regards

PGR (a.k.a. phantomjinx)



--
Laws are partly formed for the sake of good men, in order to instruct them
how they may live on friendly terms with one another, and partly for the
sake of those who refuse to be instructed, whose spirit cannot be subdued,
or softened, or hindered from plunging into evil. [The Laws, Plato]

You fiend! Never have I encountered such corrupt and foul-minded
perversity… Have you ever considered a career in the church?
Bishop of Bath and Wells (Blackadder II)

A clear conscience? When did you acquire such luxuries, Bernard? (Sir
Humphrey, Yes Prime Minister)


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gtkpod-devel mailing list
Gtkpod-devel@...
https://lists.sourceforge.net/lists/listinfo/gtkpod-devel

[Javier Kohen-2]

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gtkpod-devel mailing list
Gtkpod-devel@...
https://lists.sourceforge.net/lists/listinfo/gtkpod-devel

[P.G. Richardson]

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

Hi Javier,

Thanks for the input.

Started looking at the problem tonight in the light of Eclipse RCP talking
through JNI (SWIG) to gtkpod as a library. Yes, there is definitely some
work to be done to achieve this so should keep be happily busy for a
while.

Functions responsible for loading the itdbs for example, also set data in
the UI. Such things would have to be separated out if this is in any way
going to succeed.

Thus, in my mind at this point I am envisaging the following:

libgpod
libgtkpod (functions necessary to interface with itdbs, get mp3 tag info
... etc.)
libjnigtkpod (interface library for java native calls to libgtkpod)
gtkpod (Application redone to use libgtkpod / libgpod)
jecpod (Eclipse RCP created with the libs above)

We shall see. All very tentative and subject to change. Certainly, this
will remain a separate subproject.

Cheers

PGR

--
Laws are partly formed for the sake of good men, in order to instruct them
how they may live on friendly terms with one another, and partly for the
sake of those who refuse to be instructed, whose spirit cannot be subdued,
or softened, or hindered from plunging into evil. [The Laws, Plato]

You fiend! Never have I encountered such corrupt and foul-minded
perversity… Have you ever considered a career in the church?
Bishop of Bath and Wells (Blackadder II)

A clear conscience? When did you acquire such luxuries, Bernard? (Sir
Humphrey, Yes Prime Minister)


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gtkpod-devel mailing list
Gtkpod-devel@...
https://lists.sourceforge.net/lists/listinfo/gtkpod-devel

[P.G. Richardson]

Morning all,

This topic has not currently generated much interest so if anyone has any
opinions on the issue at all then please feel free to interject. I would
really like to know whether this seems like a good thing to do (Javier is
in favour for one) or whether others generally have no real reason to get
interested in such a move.

After several failed attempts to start builing plugins and a core gtkpod
over the weekend, I am left with several options.

The framework for ethos does not afford the complexity and maturity of the
Eclipse RCP environment. The most significant aspect is windowing
components cannot be easily added to flexible positions. Indeed, I found
that rhythmbox has a plugin architecture (not using ethos) but only allows
plugins to add components at designated areas of the UI. For this reason
and the fact my strengths rest in java over C, my preference is for trying
to build a gtkpod as an Eclipse RCP (nicknamed jecpod at the moment).

However, creating a Java plugin architecture against the existing gtkpod
codebase has proved an unenviable task. Indeed, it seems that for each
java UI plugin created, a partner native/C plugin will be required in
order to interface with existing gtkpod src. Thus, gtkpod's codebase could
break up into many smaller units rather than being a cohesive whole.

The alternative is a complete port of all gtkpod code to java with only
one core plugin, interfacing with libgpod. This is my fallback position
and I would rather not rewrite gtkpod code just for the sake of it.

My motivation is not to change gtkpod to java just for the sake of it but
I am really struggling to find anything plugin architectural environment
comparable to the Eclipse RCP at the moment. So if anyone has any better
experience or better suggestions then please speak up.

Hope that is faily clear.

Cheers

PGR (a.k.a. phantomjinx)








------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gtkpod-devel mailing list
Gtkpod-devel@...
https://lists.sourceforge.net/lists/listinfo/gtkpod-devel

[James Liggett]

On Mon, 2009-08-24 at 09:59 +0100, P.G. Richardson wrote:

> Morning all,
>
> This topic has not currently generated much interest so if anyone has any
> opinions on the issue at all then please feel free to interject. I would
> really like to know whether this seems like a good thing to do (Javier is
> in favour for one) or whether others generally have no real reason to get
> interested in such a move.
>
> After several failed attempts to start builing plugins and a core gtkpod
> over the weekend, I am left with several options.
>
> The framework for ethos does not afford the complexity and maturity of the
> Eclipse RCP environment. The most significant aspect is windowing
> components cannot be easily added to flexible positions. Indeed, I found
> that rhythmbox has a plugin architecture (not using ethos) but only allows
> plugins to add components at designated areas of the UI. For this reason
> and the fact my strengths rest in java over C, my preference is for trying
> to build a gtkpod as an Eclipse RCP (nicknamed jecpod at the moment).
>
> However, creating a Java plugin architecture against the existing gtkpod
> codebase has proved an unenviable task. Indeed, it seems that for each
> java UI plugin created, a partner native/C plugin will be required in
> order to interface with existing gtkpod src. Thus, gtkpod's codebase could
> break up into many smaller units rather than being a cohesive whole.
>
> The alternative is a complete port of all gtkpod code to java with only
> one core plugin, interfacing with libgpod. This is my fallback position
> and I would rather not rewrite gtkpod code just for the sake of it.
>
> My motivation is not to change gtkpod to java just for the sake of it but
> I am really struggling to find anything plugin architectural environment
> comparable to the Eclipse RCP at the moment. So if anyone has any better
> experience or better suggestions then please speak up.

I'm not sure how well this would fit in with you overall plans, but
Anjuta (GNOME's IDE) has a very extensive plugin system, written in C.
They also use GDL (GNOME Docking Layer) for dynamic UI creation. An
implementation similar to it might just be the kind of thing you're
looking for

See http://www.anjuta.org

HTH,
James Liggettt


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gtkpod-devel mailing list
Gtkpod-devel@...
https://lists.sourceforge.net/lists/listinfo/gtkpod-devel

[Jorg Schuler-2]

Hi,

I'm sorry I have been so silent -- I just have too many other things to
take care of at the moment.

First let me point out that gtkpod's code has been growing historically
-- we've been adding new features as they appeared in iTunes, or as
developers were available and interested. There are consequently many
areas where the programming could have been done more efficiently and
with fewer bugs and unwanted side-effects. This is particulary true with
the display code. This area will probably profit a lot from a complete
re-write.

I'm a big fan of having a plug-in interface to gtkpod, as this could
alleviate some of the historically grown problems. I wonder, however,
how extensive such a plug-in system has to be. Is it necessary to be
able to configure just about everything, or would an approach similar to
rhythmbox be sufficient. I'm also concerned about maintainability if
everything in gtkpod has to be front-ended with an interface library.
And I also wonder whether it may be a better idea to rewrite the entire
display subsystem with plugin functionality in mind.

Unfortunately I have no real suggestion as to what environment will be
most suitable to create a plugin system. I do feel, however, that
interfacing java with gtkpod may not be the best way. If java is the
only way, it's probably better to start with libgpod only, rather than
to try to re-use gtkpod. Personally, however, I would hope that we can
continue using gtkpod.

JCS.



P.G. Richardson wrote:

> Morning all,
>
> This topic has not currently generated much interest so if anyone has any
> opinions on the issue at all then please feel free to interject. I would
> really like to know whether this seems like a good thing to do (Javier is
> in favour for one) or whether others generally have no real reason to get
> interested in such a move.
>
> After several failed attempts to start builing plugins and a core gtkpod
> over the weekend, I am left with several options.
>
> The framework for ethos does not afford the complexity and maturity of the
> Eclipse RCP environment. The most significant aspect is windowing
> components cannot be easily added to flexible positions. Indeed, I found
> that rhythmbox has a plugin architecture (not using ethos) but only allows
> plugins to add components at designated areas of the UI. For this reason
> and the fact my strengths rest in java over C, my preference is for trying
> to build a gtkpod as an Eclipse RCP (nicknamed jecpod at the moment).
>
> However, creating a Java plugin architecture against the existing gtkpod
> codebase has proved an unenviable task. Indeed, it seems that for each
> java UI plugin created, a partner native/C plugin will be required in
> order to interface with existing gtkpod src. Thus, gtkpod's codebase could
> break up into many smaller units rather than being a cohesive whole.
>
> The alternative is a complete port of all gtkpod code to java with only
> one core plugin, interfacing with libgpod. This is my fallback position
> and I would rather not rewrite gtkpod code just for the sake of it.
>
> My motivation is not to change gtkpod to java just for the sake of it but
> I am really struggling to find anything plugin architectural environment
> comparable to the Eclipse RCP at the moment. So if anyone has any better
> experience or better suggestions then please speak up.
>
> Hope that is faily clear.
>
> Cheers
>
> PGR (a.k.a. phantomjinx)
>
>
>
>
>
>  

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gtkpod-devel mailing list
Gtkpod-devel@...
https://lists.sourceforge.net/lists/listinfo/gtkpod-devel

[P.G. Richardson]

> I'm sorry I have been so silent -- I just have too many other things to
> take care of at the moment.

No worries. Can fully appreciate juggling demands on one's time ;)

> First let me point out that gtkpod's code has been growing historically
> -- we've been adding new features as they appeared in iTunes, or as
> developers were available and interested. There are consequently many
> areas where the programming could have been done more efficiently and
> with fewer bugs and unwanted side-effects. This is particulary true with
> the display code. This area will probably profit a lot from a complete
> re-write.

Sounds like this is a good time to give the codebase a review then.

> I'm a big fan of having a plug-in interface to gtkpod, as this could
> alleviate some of the historically grown problems. I wonder, however,
> how extensive such a plug-in system has to be. Is it necessary to be
> able to configure just about everything, or would an approach similar to
> rhythmbox be sufficient. I'm also concerned about maintainability if
> everything in gtkpod has to be front-ended with an interface library.
> And I also wonder whether it may be a better idea to rewrite the entire
> display subsystem with plugin functionality in mind.

Giving every function a UI library is not a nice solution hence my real
hesitancy in kicking off this java-C project.

A core plug-in surrounded by "normal" installed plugin-ins with extra
optional plug-ins available is what I am imagining.

> Unfortunately I have no real suggestion as to what environment will be
> most suitable to create a plugin system. I do feel, however, that
> interfacing java with gtkpod may not be the best way. If java is the
> only way, it's probably better to start with libgpod only, rather than
> to try to re-use gtkpod. Personally, however, I would hope that we can
> continue using gtkpod.

I have come to this conclusion and porting the entirity of gtkpod over to
java seems a long job for little benefit. My current investigation is
looking at anjuta (suggested in this thread) plug-ins. Anyone have any
experience wtih anjuta then feel free to chip in.

Anyway, still considering ... cheers for the feedback.

PGR (a.k.a. phantomjinx)


--
Laws are partly formed for the sake of good men, in order to instruct them
how they may live on friendly terms with one another, and partly for the
sake of those who refuse to be instructed, whose spirit cannot be subdued,
or softened, or hindered from plunging into evil. [The Laws, Plato]

You fiend! Never have I encountered such corrupt and foul-minded
perversity… Have you ever considered a career in the church?
Bishop of Bath and Wells (Blackadder II)

A clear conscience? When did you acquire such luxuries, Bernard? (Sir
Humphrey, Yes Prime Minister)


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Gtkpod-devel mailing list
Gtkpod-devel@...
https://lists.sourceforge.net/lists/listinfo/gtkpod-devel