Re: [Banshee-List] Remuco 0.8 release announcement

[Oben Sonne <obensonne googlemail com>]

Great :)

Touchscreen support is already on the TODO list. I'm thinking of
something like gestures.

What about adding a screenshot to
http://remuco.sourceforge.net/index.php/Screenshots ? See the link at
the top of that page ..

Oben

Yoann Verminck wrote:
> That's brilliant!
> 
> Just tested it on my Nokia 5800 and it works great (doesn't have touch
> support enabled yet but works with the virtual keyboard though)
> Tested through Wi-Fi and Bluetooth, both were recognized and worked
> flawlessly.
> 
> Thanks!
> 
> Yoann
> 
> 2009/3/26 Oben Sonne <obensonne googlemail com
> <mailto:obensonne googlemail com>>
> 
>     2009/3/26 Chow Loong Jin <hyperair gmail com
>     <mailto:hyperair gmail com>>:
>     > On Thu, 2009-03-26 at 11:15 +0100, Oben Sonne wrote:
>     >> 2009/3/26 Chow Loong Jin <hyperair gmail com
>     <mailto:hyperair gmail com>>:
>     >> > On Thu, 2009-03-26 at 01:31 +0100, Oben Sonne wrote:
>     >> >> Hey folks,
>     >> >>
>     >> >> I'm happy to announce release 0.8 of Remuco, a tool to
>     remotely control
>     >> >> Banshee via Bluetooth or WiFi on J2ME cell phones.
>     >> >>
>     >> >> New features include enhanced playback control, cover art art
>     support
>     >> >> and track progress display on the mobile device.
>     >> >>
>     >> >> See http://remuco.sourceforge.net/ for more information.
>     >> >>
>     >> >> Thanks.
>     >> >>
>     >> >> Oben
>     >> > Hey Oben,
>     >> >
>     >> > This looks like a wonderful application, and I'd like to
>     package it for
>     >> > Debian and Ubuntu. I noticed your code is licensed under GPL-3, and
>     >> > that's all well and good, but you don't seem to have included the
>     >> > sources for the .jar files. As such, as per Debian Free Software
>     >> > Guidelines (DFSG) policy, these binaries have to be removed
>     from the
>     >> > tarball (we generally upload DFSG clean tarballs instead of the
>     pristine
>     >> > upstream tarballs in this case).
>     >> >
>     >> > However, unless I'm mistaken, remuco without the client is pretty
>     >> > useless. Could you perhaps include a tarball with the sources of
>     >> > this .jar file, and perhaps some sort of build system
>     (Makefile?) to
>     >> > generate this .jar?
>     >> >
>     >> > Thanks.
>     >> > --
>     >> > Chow Loong Jin
>     >> >
>     >>
>     >> Hey Chow,
>     >>
>     >> sounds good, thanks for the contribution.
>     >>
>     >> You're right, without the client the whole system is useless. The
>     >> complete source code is available in an SVN repository:
>     >> https://remuco.svn.sourceforge.net/svnroot/remuco/tags/0.8.0/ . The
>     >> client binaries are built using ant - some instructions can be found
>     >> at the top of the file client/build.xml.
>     >>
>     >> Concerning the packaging guide lines, is a release specific SVN URL
>     >> sufficient or do you require an explicit source package?
>     >>
>     >> Oben
>     >
>     > It's possible to use SVN, but it's generally not advised, as the
>     tarball
>     > needs to be generated by the Debian maintainer or uploader of the
>     > package (into Debian). Perhaps you could release a 0.8.0.1
>     tarball? I'm
>     > working on the python bits of this package at the moment.
>     >
>     > Another thing: What versions of python will this work on? Also, is the
>     > remuco module (base/module/remuco) supposed to be a public module or
>     > private module?
>     >
>     > Either way I think it should be okay if you release the sources (and
>     > build system) together with the tarball instead of the .jar file.
>     >
>     > Thanks.
>     > --
>     > Chow Loong Jin
> 
>     Ok, I'll prepare such a package. Just thinking about whether to create
>     an extra source package or whether to include the source in the
>     current package (next to the binaries). In any case there should be a
>     package for end users (which might not use a debian system) which
>     contains the binaries of the client -- creating the binaries initially
>     requires a good piece of work which is not necessary if users just
>     want to deploy the client on their devices.
> 
>     Concerning the Python module:
>     For now I would say it is a private module as it is only used by other
>     components (player adapters) within the remuco package. Further the
>     module's API may still evolve. From a long term perspective it might
>     be made public one day when it sounds reasonable to distribute player
>     adapters outside the remuco package, e.g as part of a media player.
>     What effects does this decision have on packaging?
> 
>     Btw. if you have any recommendations concerning the build structure of
>     the package to make life easier for packagers, let me know it.
> 
>     Maybe we should proceed this discussion private? I guess it is not
>     that interesting for most list members.
> 
>     Oben
>     _______________________________________________
>     banshee-list mailing list
>     banshee-list gnome org <mailto:banshee-list gnome org>
>     http://mail.gnome.org/mailman/listinfo/banshee-list
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> banshee-list mailing list
> banshee-list gnome org
> http://mail.gnome.org/mailman/listinfo/banshee-list