cc'ed to anjuta-devel for their information.
I dont know if many have noticed but I have spent the last 12 months or
so working on a new UI framework for gtkpod.
The reasons behind this were:
- Re-examination of the codebase, looking to separate the 'business
logic' of the application from the UI driving;
- Move to a more flexible platform that allowed for the development of
new features without requiring huge efforts to integrate them into the
After having had a lot of experience playing with Netbeans and Eclipse,
which are java plugin environments, I began looking into an equivalent
platform for C. Someone on the lists suggested anjuta and this is what I
went with. The process was slow to begin with but the last few months
have seen major refactorings on the application, converting it into a
single core anjuta-based application and ten UI-centric plugins.
For those with little experience of plugin platforms, this architecture
does NOT imply that one launches anjuta and adds gtkpod plugins to it.
That will not work.
The idea of the development is that gtkpod is an anjuta-based
application, ie. it uses the anjuta shell features like the
windowing/docking API and plugin manager. Thus, at its barest, gtkpod
will be a blank gdl shell with no windows at all. By installing and
enabling plugins, the various UI windows will appear in gtkpod and allow
ipod management consistent with the existing stable version.
In order to facilitate the change in architecture, two major changes
have been implemented:
- gtkpod dependency on libanjuta. This library provides all the
anjuta-esque windowing API, plugin management etc...
- introduction of libgtkpod. This represents a single common UI library
that all plugins take advantage of. API calls to add, remove tracks etc.
live in this library and they in turn call the more low-level API in
libgpod. Additional gtk dialogs universal through plugins live in this
The architecture is not finished yet. For example, the tool menu
features are currently not included in any plugins since they will be
separated into their own plugins, eg. playing track plugin, synchronizer
plugin etc... Implementing new plugins is as easy as copying the
standard of existing plugins and modifying to suit. This has led me for
instance to build a coverart browser plugin (based on webkit) in the
last couple of days, its purpose being to search for coverart then drag
n drop it straight onto the coverart display. However, the application
that can be built is useable but I am certain they are omissions, bugs
Therefore, please download, test and break. Its likely that a lot of
assumptions in the build process have been assumed, eg. assigning
commands for use in sudo, so we need to work through those before I
merge the branch back into master.
Anyway ... enough of my rambling. Happy testing ... and please let me
know any ideas and further improvements.
The branch can be accessed in either
- the sourceforge repository under the name plugin-framework
- in my gtkpod gitorous sandbox at
Paul (a.k.a. phantomjinx)