[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: why do we still ship (gtk1) xmms, when we have bmp




Ville Skyttä wrote:
> On Sun, 2006-06-18 at 09:39 +0200, Hans de Goede wrote:
>> Ville Skyttä wrote:
>>
>> bmp has libbmp which is api compatible with libxmms and I beleave
>> (but I am in no way sure) even abi)
> 
> libbmp <-> libxmms needs to be taken into account when linking or
> dlopening in dependent apps, and those apps need to be prepared for
> that.
> 

If we actually drop libxmms then we can easily patch the (few) apps
using libxmms to compile and link against libbmp.

>> the plugin interface
>> is not ABI but is API compatible, so doing a recompile is all that it
>> should take.
> 
> Hardly.  #include <xmms/*.h> is very commonly found in xmms plugins (all
> of them?) and bmp-devel doesn't provide that.  Also the vast majority of
> xmms plugins have direct gtk1 dependencies of their own which needs to
> change or it makes the whole effort kind of pointless.  The plugin
> install dirs are different too, as are xmms-config vs pkg-config bmp
> invocations.  It may be that these issues would be easy to fix/port for
> gtk2/bmp, but a rebuild alone after changing build dependencies doesn't
> magically accomplish that.
> 

True, I forgot about that, but AFAIK (from reading docs only) GUI-less
plugings will work almost out of the box, and the others "only" need a
gtk1->2 port.

>>> gtk1 dependency chain is a lot smaller
>>> than gtk2 which may matter eg. in "pure" KDE setups.
>> They will need this anyway for system-config-xxxx, or openoffice or
>> firefox.
> 
> Note "pure" KDE setups.  system-config-xxx (not necessarily needed),
> openoffice (-> koffice) or firefox (-> konqueror) don't qualify there.
> Anyway, this issue is mostly of academic interest and IMO would not
> qualify as a blocker against dropping xmms if all other issues would be
> resolved.
> 

I'm glad you say that I was thinking about investing (some) time in
getting audacious into Extras (preferably as a replacement for bmp
initially we really don't need xmms + 2 forks) and then working on
getting the other issues resolved. It would also be nice to have a list
of the other issues, so far we have that I'm aware of:
-all the xmms plugins must be ported too / be available for audacious.
-xmmslib using apps should be able to use audaciouslib instead.

>> I was hoping
>> that having a good replacement for xmms could sooner or later lead do
>> really dropping gtk+.
> 
> I share that hope, but I don't think the replacements are ready yet.
> 

Well I'm willing to work on getting them ready and I have some time to
invest this summer (I work as a teacher). For starters I'll contact the
bmp package maintainer and try to work with him to get audacious in to
FE (preferably as a BMP replacement).

Then I'll start porting all the plugins in FE and that other repo, and
the apps using libxmms.

Once thats done we need some people todo a descent amount of testing and
 then we will hopefully be ready to drop xmms.

So unless someone seems some big holes in my plan I would like to this
discussion to stop and to invest my time in actually making this happen.

Regards,

Hans


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]