Question about _DirMap
Catalin Patulea
I am reading through the remuco code and there is one thing I don't
quite understand. In files.py, _DirMap takes on a default value of:
__DEFAULT = {
"XDG_DESKTOP_DIR": "$HOME/Desktop",
"XDG_DOWNLOAD_DIR": "$HOME/Download",
[...]
This is updated by reading the user's user-dirs.dirs, then the DirMap
contents are passed through __MIME_TO_ALIAS_MAP:
for mime_type in _DirMap.__MIME_TO_ALIAS_MAP:
alias = _DirMap.__MIME_TO_ALIAS_MAP[mime_type]
self[mime_type] = self[alias]
So the _DirMap now additionally contains "audio" -> "$HOME/Music",
"video" -> "$HOME/Video", etc.
This seems to me like it mixes the two uses of the dict. Then the only
user of _DirMap (FileSystemLibrary.__get_mime_dirs) indexes it by MIME
type. But I don't have much experience with remuco or xdg so perhaps
I'm missing something... Can anyone shed some light on this?
Thanks,
Catalin
Oben
directories but internally it also maps XDG directory identifiers
(XDG_...) to directories. It's some time ago I wrote this and I cannot
say for sure if there was a good reason to do it that way. There is
probably a more clear way to implement this. Do you just ask for
understanding or do you have a specific issue?
Regards,
Oben
Catalin Patulea
> probably a more clear way to implement this. Do you just ask for
> understanding or do you have a specific issue?
server to Windows. files.py is one of the focus areas for this because
it uses (platform-specific) xdg.
I have a hacked up Remuco server running with BluetoothServer and the
fooplay adapter. I'm using a J2ME phone as a client. The biggest
hurdle was getting Bluetooth working and it still has a few bugs. I
also had to stub out references to dbus.
As far as _DirMap goes, I think the best approach is to define a
separate class. Windows has the concept of Desktop, Documents, Music,
etc directory, it's just a matter of importing and using the right
APIs to fill the dict.
Oben
The DBus stuff is not a fundamental requirement, so it shouldn't be a
problem to disable related functionality in Windows. Concerning the
DirMap, I can think of a separate class or adjustments (maybe
including simplifications) to the current class. Do whatever seems to
work best.
Concerning Bluetooth, it should work as long the BT API on Windows
provides a regular socket object. Is there a Python Bluetooth module
for Windows?
By the way, which player you intend to use Remuco for on Windows?
Cheers,
Oben
On Jan 3, 8:17 pm, Catalin Patulea <cronos...@gmail.com> wrote:
Catalin Patulea
message from it -- did it get through?
> --
> You received this message because you are subscribed to the Google Groups "remuco" group.
> To post to this group, send email to rem...@googlegroups.com.
> To unsubscribe from this group, send email to remuco+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/remuco?hl=en.
>
>
>
>
Catalin Patulea
On Wed, Jan 6, 2010 at 7:57 AM, Oben <oben...@googlemail.com> wrote:
> The DBus stuff is not a fundamental requirement, so it shouldn't be a
> problem to disable related functionality in Windows. Concerning the
> DirMap, I can think of a separate class or adjustments (maybe
> including simplifications) to the current class. Do whatever seems to
> work best.
Ok. I am tempted to start a branch where I simply delete the code not
relevant to Windows. This would help me develop and debug the Windows
port without worrying about cross-platform checks. Do you have any
major objections to this?
Once the code is ready to merge into the main codebase, I will
introduce platform checks where necessary. Do you know what the best
practices are in Python for this type of code? I will need to
conditionally import certain things as well. One way to detect the
platform is using the "platform" module, but I would like to avoid
duplicating the checks at the top of each file with multi-platform
imports. At the other end of the spectrum would be to create "wrapper
modules" that include the correct module for the platform and provide
a uniform interface. That seems a bit overkill.. can you think of any
reasonable compromise between the two?
> Concerning Bluetooth, it should work as long the BT API on Windows
> provides a regular socket object. Is there a Python Bluetooth module
> for Windows?
It's more complicated than that.. "In the wild", Windows supports two
parallel Bluetooth stacks. One which has an interface much like the
Linux one (based on AF_BTH sockets) and this is referred to as the
"Microsoft stack". PyBlueZ has support for this stack. The other
possibility is a "Widcomm stack", which has a different (proprietary)
way of communicating with the underlying driver and which interfaces
with clients though a set of C++ classes with callbacks. PyBlueZ also
has support for this stack, but it is (IMHO) very poorly written and
differs subtly from the MS stack backend. At any given time, a Windows
system has one stack or the other, not both. PyBlueZ can detect which
one is present out of the box.
One particular area where the differences actually break remuco's use
of bluetooth is nonblocking mode. First, the PyBlueZ Widcomm stack
return the same socket in accept() as the server socket, so this
breaks io_watch notifications added for that fd. Additionally, the
sockets' recv() wrap the underlying socket recv, *plus* some packet
decapsulation which is internal to the widcomm.py<->_widcomm.pyd
interface. This leads to confusion when the received packet actually
indicates a connection close rather than actual data.
All in all, PyBlueZ Bluetooth support on Windows is a hack, and I
think to get something reliable one would have to rewrite at least
some part of widcomm.py/_widcomm.pyd. I do not mind doing this, as
reliable Python Bluetooth support on Windows would benefit me in the
long run, but it is not very high on my todo list. Besides, I am more
interested in the Wifi server part of remuco, so I am tempted to get
remuco running with that first before taking care of Bluetooth.
On that topic, there is a major compatibility issue with gobject on
Windows. Because of the implementation of glib IOChannels on Windows,
multiple io_watches on the same fd are not supported and produce
incorrect results and, in some cases, spinning main loops. I have seen
this behaviour on my system. There is a bug report in the glib
bugzilla about this, which includes a very alpha patch, and I was
considering building my own glib with that patch, but I realized that
remuco doesn't actually use much else out of gobject. From what I can
see, gobject was used mostly because DBus needed the Glib mainloop.
With DBus out of the picture on Windows, I think it is better to write
a pure Python (well, which uses pywin32) gobject with only the
features remuco needs. As a positive side-effect, this will
dramatically reduce remuco's dependency footprint (at least on
Windows). What do you think about this?
> By the way, which player you intend to use Remuco for on Windows?
I would like to write an adapter for Winamp. I'm planning on using
this interface library:
http://code.google.com/p/pywinamp/
Locally, I have cleaned it up a bit and tested it with Winamp 5.
Windows Media Player is also on the horizon, but pretty far out for now.
Sorry for the giant e-mail, hope everything is clear :)
Catalin
Oben
> [switched e-mail account, old: cronos...@gmail.com new: c...@vv.carleton.ca]
>
> On Wed, Jan 6, 2010 at 7:57 AM, Oben <obenso...@googlemail.com> wrote:
> > The DBus stuff is not a fundamental requirement, so it shouldn't be a
> > problem to disable related functionality in Windows. Concerning the
> > DirMap, I can think of a separate class or adjustments (maybe
> > including simplifications) to the current class. Do whatever seems to
> > work best.
>
> Ok. I am tempted to start a branch where I simply delete the code not
> relevant to Windows. This would help me develop and debug the Windows
> port without worrying about cross-platform checks. Do you have any
> major objections to this?
No. Sounds reasonable.
> Once the code is ready to merge into the main codebase, I will
> introduce platform checks where necessary. Do you know what the best
> practices are in Python for this type of code? I will need to
> conditionally import certain things as well. One way to detect the
> platform is using the "platform" module, but I would like to avoid
> duplicating the checks at the top of each file with multi-platform
> imports. At the other end of the spectrum would be to create "wrapper
> modules" that include the correct module for the platform and provide
> a uniform interface. That seems a bit overkill.. can you think of any
> reasonable compromise between the two?
Hm, I've never ported Python code to Windows so I'm not very
experienced to know what's the best approach here. It mainly depends
on which approach (wrapper modules or platform checks in import
sections) blows up the code less. Initially I would go for platform
checks when importing stuff. If this gets to complicated or produces
high redundancy we could switch to wrapper modules. Just an idea. How
much of the py files in the Remuco base actually require x-platform
adjustments?
Yep, that Bluetooth stuff sounds ugly. I think for now it's best to
concentrate on WiFi and disable Bluetooth in Windows. We could work on
this once the other portability issues are done. If we are lucky, the
Bluetooth stack implementation issues you mentioned are fixed by that
time :)
> On that topic, there is a major compatibility issue with gobject on
> Windows. Because of the implementation of glib IOChannels on Windows,
> multiple io_watches on the same fd are not supported and produce
> incorrect results and, in some cases, spinning main loops. I have seen
> this behaviour on my system. There is a bug report in the glib
> bugzilla about this, which includes a very alpha patch, and I was
> considering building my own glib with that patch, but I realized that
> remuco doesn't actually use much else out of gobject. From what I can
> see, gobject was used mostly because DBus needed the Glib mainloop.
> With DBus out of the picture on Windows, I think it is better to write
> a pure Python (well, which uses pywin32) gobject with only the
> features remuco needs. As a positive side-effect, this will
> dramatically reduce remuco's dependency footprint (at least on
> Windows). What do you think about this?
Removing the gobject dependency would makes things easier but be aware
that gobject is used quite often for idle and timeout callbacks and
for reading and writing data in a non-blocking mode. Remuco is
completely single threaded and uses gobject's (i.e. glib's) main loop
a lot to manage tasks in that context. In Linux I would definitely
stay with gobject as it is also integrated in the player API's which
are used by the player adapters .. using gobject simply integrates
well here. A rewritten pure Python gobject to be used on Windows
should provide io-watches, idle and timeout callbacks. I cannot really
estimate how much work this would be. Maybe there's already some
existing work. While I would stay with gobject for the Linux version,
one could still add a generic MainLoop module to Remuco which
internally maps to a platform appropriate implementation (so here we
would end up with a wrapper).
The multiple watches on a single fd issue actually should not happen.
As far as I remember the is only one watch per server and one watch
per client socket. Did you experience something different?
> > By the way, which player you intend to use Remuco for on Windows?
>
> I would like to write an adapter for Winamp. I'm planning on using
> this interface library:http://code.google.com/p/pywinamp/
>
> Locally, I have cleaned it up a bit and tested it with Winamp 5.
Pretty cool!
> Windows Media Player is also on the horizon, but pretty far out for now.
Sure ..
> Sorry for the giant e-mail, hope everything is clear :)
:) Man, thanks for working on this!
Oben
Catalin Patulea
> checks when importing stuff. If this gets to complicated or produces
> high redundancy we could switch to wrapper modules. Just an idea. How
> much of the py files in the Remuco base actually require x-platform
> adjustments?
- __all__.py imports MPRISAdapter, which requires DBus
- references to xdg (config.py, files.py)
- dbus imports and _DBusObserver in manager.py
- dbus imports and __user_notification in report.py
By the way, what does a user_notification like this actually look like?
> Yep, that Bluetooth stuff sounds ugly. I think for now it's best to
> concentrate on WiFi and disable Bluetooth in Windows. We could work on
> this once the other portability issues are done. If we are lucky, the
> Bluetooth stack implementation issues you mentioned are fixed by that
> time :)
One would hope.. the PyBlueZ widcomm backend was mostly last changed
in Nov 2007, with very topical changes more recently in Nov 2009.
(http://code.google.com/p/pybluez/source/browse/#svn/trunk/widcomm) I
get the feeling that simply not many people use PyBlueZ on Windows.
> A rewritten pure Python gobject to be used on Windows
> should provide io-watches, idle and timeout callbacks.
Well, I hacked away at it yesterday and got something working:
http://github.com/cpatulea/purepython-gobject
I did "grep -r 'gobject\.'" to make sure I supported all of remuco's
base requirements (I did not include support for functions used by
Linux-only player adapters). Note that this library is NOT tested with
remuco yet, but it does have a unittest (gobject_test.py) and example
code (main block at the bottom of gobject.py) which seem to work.
There is still one subtle race condition (noted in the code), but I
think I've come up with a nice solution, just haven't written and
tested it yet.
> The multiple watches on a single fd issue actually should not happen.
> As far as I remember the is only one watch per server and one watch
> per client socket. Did you experience something different?
Hmm, I definitely see multiple watches per socket in net.py:
http://code.google.com/p/remuco/source/browse/base/module/remuco/net.py#109
remuco should not have to change that. purepython-gobject was written
with support for multiple watches per fd in mind.
Also, I agree that there is no reason to introduce purepython-gobject
on Linux. It's just a shim to support Windows.
Oben
On 7 Jan., 23:53, Catalin Patulea <c...@vv.carleton.ca> wrote:
> On Thu, Jan 7, 2010 at 5:27 PM, Oben <obenso...@googlemail.com> wrote:
> > checks when importing stuff. If this gets to complicated or produces
> > high redundancy we could switch to wrapper modules. Just an idea. How
> > much of the py files in the Remuco base actually require x-platform
> > adjustments?
>
> Areas which will need work (summarized from "git diff origin"):
> - __all__.py imports MPRISAdapter, which requires DBus
As MPRIS is a DBus-based and I guess Linux-only player interface, it
won't be needed on Windows. I would vote for a platform-dependent
definition of __all__.
> - references to xdg (config.py, files.py)
Here I think it's best to have one generic user-data module which
provides paths for user cache and config file location as well as
paths like "Music", "Video", etc. On Linux those values would be
retrieved by the xdg-module, on Windows, well, you know it best, I
guess. config.py and files.py would then refer to that generic module.
By the way, I'm sure config.py and files.py could be generally
simplified from an implementation perspective. I wrote them in my
early Python days and today I would say I've utilized classes and
properties a bit excessively.
> - dbus imports and _DBusObserver in manager.py
Both are used by player adapters communicating to players by DBus. I
think its best for now to simply import/define platform-dependent.
> - dbus imports and __user_notification in report.py
For now the report module could simply be disabled on Windows. It's
not a core functionality but simply reports client device information
to remuco.sf.net when a user runs 'remuco-report'. __user_notification
() uses the Linux standard notification interface (DBus-based) to pop
up a notification when a new client device has connected and to kindly
ask the user to run 'remuco-report'. Dropping the notification only
would be another way to make this Windows-working.
> By the way, what does a user_notification like this actually look like?
Well, you've read above :)
> > Yep, that Bluetooth stuff sounds ugly. I think for now it's best to
> > concentrate on WiFi and disable Bluetooth in Windows. We could work on
> > this once the other portability issues are done. If we are lucky, the
> > Bluetooth stack implementation issues you mentioned are fixed by that
> > time :)
>
> One would hope.. the PyBlueZ widcomm backend was mostly last changed
> in Nov 2007, with very topical changes more recently in Nov 2009.
> (http://code.google.com/p/pybluez/source/browse/#svn/trunk/widcomm) I
> get the feeling that simply not many people use PyBlueZ on Windows.
>
> > A rewritten pure Python gobject to be used on Windows
> > should provide io-watches, idle and timeout callbacks.
>
> Well, I hacked away at it yesterday and got something working:http://github.com/cpatulea/purepython-gobject
>
> I did "grep -r 'gobject\.'" to make sure I supported all of remuco's
> base requirements (I did not include support for functions used by
> Linux-only player adapters). Note that this library is NOT tested with
> remuco yet, but it does have a unittest (gobject_test.py) and example
> code (main block at the bottom of gobject.py) which seem to work.
> There is still one subtle race condition (noted in the code), but I
> think I've come up with a nice solution, just haven't written and
> tested it yet.
Awesome, this is really useful.
> > The multiple watches on a single fd issue actually should not happen.
> > As far as I remember the is only one watch per server and one watch
> > per client socket. Did you experience something different?
>
> Hmm, I definitely see multiple watches per socket in net.py:http://code.google.com/p/remuco/source/browse/base/module/remuco/net....
> remuco should not have to change that. purepython-gobject was written
> with support for multiple watches per fd in mind.
Ah, I see. Yes, multiple watches, but different events. Anyway, you
module makes it right :)
> Also, I agree that there is no reason to introduce purepython-gobject
> on Linux. It's just a shim to support Windows.
Al this sounds very good :) I'm a bit busy these days with other
stuff, right now I cannot really contribute here on a coding level. I
hope to have some more time for that in february.
Regards,
Oben
Catalin Patulea
mailing list..]
Hi Oben,
The port is going well. I can play/pause/next/previous/seek, and
change volume, most things get updated in poll(), etc. However, I
haven't started implementing actions at all yet, so you can see the
current playlist but not change it. By the way, I am using the Sun
J2ME emulator, is that what you use for testing new adapters too?
I was confused about one thing.. in a ctrl_*() method, should I call
poll() myself at the end? It seems that if I don't do that, the client
only updates after the next poll interval. But this might also be a
bug in purepython-gobject..
Catalin
Catalin Patulea
The port is going well. I can play/pause/next/previous/seek, and
change volume, most things get updated in poll(), etc. However, I
haven't started implementing actions at all yet, so you can see the
current playlist but not change it. By the way, I am using the Sun
J2ME emulator, is that what you use for testing new adapters too?
I was confused about one thing.. in a ctrl_*() method, should I call
poll() myself at the end? It seems that if I don't do that, the client
only updates after the next poll interval. But this might also be a
bug in purepython-gobject..
Catalin
On Thu, Jan 7, 2010 at 5:53 PM, Catalin Patulea <c...@vv.carleton.ca> wrote:
Oben
> The port is going well. I can play/pause/next/previous/seek, and
> change volume, most things get updated in poll(), etc. However, I
> haven't started implementing actions at all yet, so you can see the
> current playlist but not change it. By the way, I am using the Sun
> J2ME emulator, is that what you use for testing new adapters too?
Yes, mainly its Sun's WTK (version 2.5.2, unfortunately 3.0 is not
ported to Linux yet). Additionally I use the MicroEmu emulator for
cross-checks. This emulator gets downloaded and configured
automaticaly by the setup.sh script in the JME client directory.
> I was confused about one thing.. in a ctrl_*() method, should I call
> poll() myself at the end? It seems that if I don't do that, the client
> only updates after the next poll interval. But this might also be a
> bug in purepython-gobject..
Depends. If a player's API does not provide a concept of signals when
certain values change (e.g. volume or playback state), then a ctrl
method should call poll (or a subset of what happens in poll) to
ensure the new value is synced to the client as soon as possible. E.g.
ctrl_volume() might call poll() (or a helper method poll_volume()) at
its end to make sure the volume bar on the client de-/increases as the
user adjusts the volume (and not after the next regular poll
interval). Generalized it depends on what effects a ctrl method may
have, whether the effects need to be polled and whether the effects
should get synced to the client as fast as possible. A friendly player
API just issues changes signals whenever something interesting changes
- here one don't need to care about polling at all.
>
> Catalin
>
>
>
> On Thu, Jan 7, 2010 at 5:53 PM, Catalin Patulea <c...@vv.carleton.ca> wrote:
> >http://code.google.com/p/remuco/source/browse/base/module/remuco/net....
Catalin Patulea
I have created a repository for my fork at github, please take a look.
http://github.com/cpatulea/remuco
I just noticed that remuco is licensed under GPLv3. Do you know if
GPLv3 is compatible with GPLv2? pywinamp, for instance, is licensed
v2. I was also planning on licensing purepython-gobject as v2.
Catalin
On Fri, Jan 15, 2010 at 10:56 PM, Catalin Patulea <c...@vv.carleton.ca> wrote:
> On Mon, Jan 11, 2010 at 5:38 PM, Oben <oben...@googlemail.com> wrote:
>> Yes, mainly its Sun's WTK (version 2.5.2, unfortunately 3.0 is not
>> ported to Linux yet). Additionally I use the MicroEmu emulator for
>> cross-checks. This emulator gets downloaded and configured
>> automaticaly by the setup.sh script in the JME client directory.
> I got it working with WTK 2.5.2.. there's still a strange quirk, not
> sure if you've noticed it, perhaps it's only on Windows, but if Remuco
> asks me to "reconnect" as a result of a failed connection, and I
> accept, the emulator crashes citing something about keeping networking
> on a separate thread. Everything else works well and it has enabled me
> to develop the Winamp adapter.
>
> Speaking of MicroEmu, did you notice it has a mode of targeting
> Android? Check out this article:
> http://microemu.blogspot.com/2008/11/running-java-me-applications-on-android.html
>
> I tried it and it works only up to trying to connect.. The server
> thinks the client is connected, but the client app hangs.
>
> Any progress on the Android port of remuco? It seems like a stub in
> hg, but perhaps there's a more up to date branch elsewhere.
>
>> interval). Generalized it depends on what effects a ctrl method may
>> have, whether the effects need to be polled and whether the effects
>> should get synced to the client as fast as possible. A friendly player
>> API just issues changes signals whenever something interesting changes
>> - here one don't need to care about polling at all.
> It is more difficult to achieve this -- asynchronous notifications --
> for Winamp on Windows, it basically requires a Winamp plugin (shared
> library) which runs in-process to Winamp and can intercept certain
> window messages. For now, I will stick to polling but I am adding a
> TODO in the Winamp adapter.
>
> One more general question regarding Remuco startup: when an adapter
> which uses polling starts (in its .start()), should it call
> self.poll()? Otherwise, it seems to take until the first polling
> interval for remuco to get the player state, so clients connecting in
> that (admittedly very short) time get a blank screen.
>
Catalin Patulea
> ported to Linux yet). Additionally I use the MicroEmu emulator for
> cross-checks. This emulator gets downloaded and configured
> automaticaly by the setup.sh script in the JME client directory.
sure if you've noticed it, perhaps it's only on Windows, but if Remuco
asks me to "reconnect" as a result of a failed connection, and I
accept, the emulator crashes citing something about keeping networking
on a separate thread. Everything else works well and it has enabled me
to develop the Winamp adapter.
Speaking of MicroEmu, did you notice it has a mode of targeting
Android? Check out this article:
http://microemu.blogspot.com/2008/11/running-java-me-applications-on-android.html
I tried it and it works only up to trying to connect.. The server
thinks the client is connected, but the client app hangs.
Any progress on the Android port of remuco? It seems like a stub in
hg, but perhaps there's a more up to date branch elsewhere.
> interval). Generalized it depends on what effects a ctrl method may
> have, whether the effects need to be polled and whether the effects
> should get synced to the client as fast as possible. A friendly player
> API just issues changes signals whenever something interesting changes
> - here one don't need to care about polling at all.
Oben
>
> I have created a repository for my fork at github, please take a look.http://github.com/cpatulea/remuco
Just had a look. Nothing to complain about so far ;) However, for a
more thorough look and merging your changes into the mainline I'll
probably won't have time until February, sorry. I like your commit
message style of naming the component in the message headline. I think
we should introduce this as a general project style guide line.
> I just noticed that remuco is licensed under GPLv3. Do you know if
> GPLv3 is compatible with GPLv2? pywinamp, for instance, is licensed
> v2. I was also planning on licensing purepython-gobject as v2.
I'm not an expert on this but I don't think that a GPL v3 project is
not allowed to use GPL v2 components. For new projects I would vote
for v3, as it looks more and more projects are switching to it and so
one is prepared for the future. On the other side I don't think this
is a critical issue. If some of your components are GPL v2, the source
file license headers should get adjusted accordingly and we could drop
a note in the project's README that some (named) components are differ
from the project wide license.
> Catalin
>
> On Fri, Jan 15, 2010 at 10:56 PM, Catalin Patulea <c...@vv.carleton.ca> wrote:
> > On Mon, Jan 11, 2010 at 5:38 PM, Oben <obenso...@googlemail.com> wrote:
> >> Yes, mainly its Sun's WTK (version 2.5.2, unfortunately 3.0 is not
> >> ported to Linux yet). Additionally I use the MicroEmu emulator for
> >> cross-checks. This emulator gets downloaded and configured
> >> automaticaly by the setup.sh script in the JME client directory.
> > I got it working with WTK 2.5.2.. there's still a strange quirk, not
> > sure if you've noticed it, perhaps it's only on Windows, but if Remuco
> > asks me to "reconnect" as a result of a failed connection, and I
> > accept, the emulator crashes citing something about keeping networking
> > on a separate thread. Everything else works well and it has enabled me
> > to develop the Winamp adapter.
>
> > Speaking of MicroEmu, did you notice it has a mode of targeting
> > Android? Check out this article:
> >http://microemu.blogspot.com/2008/11/running-java-me-applications-on-...
Oben
> On Mon, Jan 11, 2010 at 5:38 PM, Oben <obenso...@googlemail.com> wrote:
> > Yes, mainly its Sun's WTK (version 2.5.2, unfortunately 3.0 is not
> > ported to Linux yet). Additionally I use the MicroEmu emulator for
> > cross-checks. This emulator gets downloaded and configured
> > automaticaly by the setup.sh script in the JME client directory.
>
> I got it working with WTK 2.5.2.. there's still a strange quirk, not
> sure if you've noticed it, perhaps it's only on Windows, but if Remuco
> asks me to "reconnect" as a result of a failed connection, and I
> accept, the emulator crashes citing something about keeping networking
> on a separate thread.
I guess this is an issue of the Windows implementation of the WTK - I
cannot reproduce this on my Linux box.
> Everything else works well and it has enabled me to develop the Winamp adapter.
Awesome :)
> Speaking of MicroEmu, did you notice it has a mode of targeting
> Android? Check out this article:http://microemu.blogspot.com/2008/11/running-java-me-applications-on-...
>
> I tried it and it works only up to trying to connect.. The server
> thinks the client is connected, but the client app hangs.
I heard of this approach but I never tried it. Mainly because I don't
have an Android device :) But also because I guessed it will cause
trouble when it comes to network and storage related code.
> Any progress on the Android port of remuco? It seems like a stub in
> hg, but perhaps there's a more up to date branch elsewhere.
Yes, the current Android version is just a stub I've created some
weeks ago. Igor V. (http://github.com/ivashyst/remuco) planned to work
on this but I don't what's the current progress on this. While it
might be possible to automatically create an Android app from the JME
client, I would definitely favor a native Android client. Mainly
because Android devices are more powerful .. and so could be the
Remuco Android client. The Android client development is discussed in
issue 34 (http://code.google.com/p/remuco/issues/detail?id=34).
>
> > interval). Generalized it depends on what effects a ctrl method may
> > have, whether the effects need to be polled and whether the effects
> > should get synced to the client as fast as possible. A friendly player
> > API just issues changes signals whenever something interesting changes
> > - here one don't need to care about polling at all.
>
> It is more difficult to achieve this -- asynchronous notifications --
> for Winamp on Windows, it basically requires a Winamp plugin (shared
> library) which runs in-process to Winamp and can intercept certain
> window messages. For now, I will stick to polling but I am adding a
> TODO in the Winamp adapter.
While notifications a smarter, most users won't really recognize the
difference to polling if it's implemented well. I don't think it's
worthwhile to write an extra Winamp plugin just to have notifications.
> One more general question regarding Remuco startup: when an adapter
> which uses polling starts (in its .start()), should it call
> self.poll()? Otherwise, it seems to take until the first polling
> interval for remuco to get the player state, so clients connecting in
> that (admittedly very short) time get a blank screen.
Yes, if you need an instant synchronization, the first poll needs to
called explicitly. I could change this to happen automatically. OTH
one has to be really fast to recognize this synchronization delay, so
I don't think this is urgent.
Cheers,
Oben
Catalin Patulea
> because Android devices are more powerful .. and so could be the
> Remuco Android client. The Android client development is discussed in
> issue 34 (http://code.google.com/p/remuco/issues/detail?id=34).
> Yes, if you need an instant synchronization, the first poll needs to
> called explicitly. I could change this to happen automatically. OTH
> one has to be really fast to recognize this synchronization delay, so
> I don't think this is urgent.
Ok, no problem, just wanted to confirm this is by design.
Regarding ItemActions, what are the guidelines for setting
multiple=True? I can provide an implementation for multiple=True for
all ItemActions, with the exception of playlist Jump to, and I feel it
would make sense in those cases. However, some adapters, for example,
mplayer, use multiple=False, even where it would make sense
(FA_APPEND).
There's also a UI issue with this. I see that while multiple=False
generates "<action> (focussed)" menu items, multiple=True *replaces*
them with "<action> (marked)". Would it make sense to also provide
(focussed) actions for multiple=True, as a shortcut for "mark one
item; action"?
Oben
> On Sun, Jan 17, 2010 at 4:20 PM, Oben <obenso...@googlemail.com> wrote:
> > because Android devices are more powerful .. and so could be the
> > Remuco Android client. The Android client development is discussed in
> > issue 34 (http://code.google.com/p/remuco/issues/detail?id=34).
>
> Ah, excellent, thanks for the link.
>
> > Yes, if you need an instant synchronization, the first poll needs to
> > called explicitly. I could change this to happen automatically. OTH
> > one has to be really fast to recognize this synchronization delay, so
> > I don't think this is urgent.
>
> Ok, no problem, just wanted to confirm this is by design.
>
> Regarding ItemActions, what are the guidelines for setting
> multiple=True? I can provide an implementation for multiple=True for
> all ItemActions, with the exception of playlist Jump to, and I feel it
> would make sense in those cases. However, some adapters, for example,
> mplayer, use multiple=False, even where it would make sense
> (FA_APPEND).
I guess it just has been forgotten. The "Play" action is a single item
action, but "Append" definitely is a multiple one.
As most actions are multiple ones, it may be a good idea to change the
default to multiple=True.
> There's also a UI issue with this. I see that while multiple=False
> generates "<action> (focussed)" menu items, multiple=True *replaces*
> them with "<action> (marked)". Would it make sense to also provide
> (focussed) actions for multiple=True, as a shortcut for "mark one
> item; action"?
Definitely. The problem here is how command menus are handled in J2ME.
Ideally they would be context depended, i.e. as long no items are
marked, all actions are displayed and when some items get marked, only
the multiple actions are shown. It is possible to change the commands
of a screen while it is visible - it works on my Sony Ericsson devices
and in the emulator - but it causes problems on some other phones.
However, one could simply drop the *focussed* and *marked* annotations
and show an alert message when a user tries to apply a single item
action to multiple marked items. When no items are marked and a
multiple item action is chosen, it could get applied to the focused
one - as you suggested. What do you think?
Catalin Patulea
> I guess it just has been forgotten. The "Play" action is a single item
> action, but "Append" definitely is a multiple one.
marking multiple objects and selecting Play creates a playlist with
the marked items. Do you feel this would confuse users?
> As most actions are multiple ones, it may be a good idea to change the
> default to multiple=True.
Hmm.. a very far-reaching change. I think I will leave the defaults
as-is, especially since it is difficult for me to test the behaviour
afterwards.
> However, one could simply drop the *focussed* and *marked* annotations
> and show an alert message when a user tries to apply a single item
> action to multiple marked items. When no items are marked and a
> multiple item action is chosen, it could get applied to the focused
> one - as you suggested. What do you think?
Yes, that sounds good. I will take a look at the client code and try
to come up with a patch; I will commit to my fork and you can take a
look when you have a chance.
Oben
On Jan 24, 2:53 am, Catalin Patulea <c...@vv.carleton.ca> wrote:
> On Mon, Jan 18, 2010 at 11:45 AM, Oben <obenso...@googlemail.com> wrote:
> > I guess it just has been forgotten. The "Play" action is a single item
> > action, but "Append" definitely is a multiple one.
>
> I have implemented the Play action for the Winamp adapter such that
> marking multiple objects and selecting Play creates a playlist with
> the marked items. Do you feel this would confuse users?
What I think:
- current playlist:
- one focused or marked: 'play' jumps to this item
- multiple marked: don't know what 'play' could mean here
- other lists (from the media library or file system):
- creating a new playlist as you said seems plausible
Finally, I think player adapters should try to mimic the behavior of
their players, i.e. the semantics of actions should be as similar as
possible to similar named actions in the regular player UI. As you use
Winamp, you'll probably know best how to implement actions here :)
>
> > As most actions are multiple ones, it may be a good idea to change the
> > default to multiple=True.
>
> Hmm.. a very far-reaching change. I think I will leave the defaults
> as-is, especially since it is difficult for me to test the behaviour
> afterwards.
It's not that complicated. ItemActions get initialized almost similar
and at the same place in every adapter - just stupid work.
It's not critical so I'll may do it one day if no other things are on
the road.
> > However, one could simply drop the *focussed* and *marked* annotations
> > and show an alert message when a user tries to apply a single item
> > action to multiple marked items. When no items are marked and a
> > multiple item action is chosen, it could get applied to the focused
> > one - as you suggested. What do you think?
>
> Yes, that sounds good. I will take a look at the client code and try
> to come up with a patch; I will commit to my fork and you can take a
> look when you have a chance.
I think I'll do this (if not done by you already ;) ). I've to do some
clean up in the client code anyway.
In the week starting with Feb. 15, I'll have some more time to work on
Remuco again. Then we should try to get your Win port changes
integrated into the mainline. Sounds challenging .. yeah :)
Oben
Oben
Concerning your fabulous pure-python gobject, what about integrating a
copy into remuco? Users would benefit from one thing less to download
and setup.
Oben
Oben
windows port changes.
I've created a new module remos.py which abstracts certain OS specific
code, e.g. locations and user notifications. This module already
replaces most Linux-related code in other modules. Concerning the
MPRISAdapter (mpris.py) and the DBusObserver (manager.py), I just try-
catch'ed the DBus import statements. I did not move the code using
DBus, as it shouldn't get called anyway in Windows - if it get's
called, then it's a bug elsewhere to fix. If it does _not_ get called,
it shouldn't do any harm.
Well, I think I've integrated all your adjustments - real world will
say something different probably: could you please test the latest
changes? I did not integrated your Winamp adapter yet. I'll merge it
directly once the base porting is finished.
I think now we have a common code base to continue the porting and
merge changes directly on SCM level.
Cheers,
Oben
Catalin Patulea
> Well, I think I've integrated all your adjustments - real world will
> say something different probably: could you please test the latest
> changes? I did not integrated your Winamp adapter yet. I'll merge it
> directly once the base porting is finished.
tree since that's how I do my testing.
> I think now we have a common code base to continue the porting and
> merge changes directly on SCM level.
I'm a little confused at this point (a bit new to git, hopefully you
can shed some light). I locally branched from remuco/master again for
some small touchups, but now I can't push to cpatulea/remuco/master
because of the divergent histories. Ideally I would also would like to
somehow keep that history (of the port development), any idea how to
do that?
Regarding purepython-gobject, how about I add a conditional "import
gobject" in remos and change all the "import gobject" elsewhere across
the project to "from remos import gobject"?
Oben Sonne
> On Wed, Feb 10, 2010 at 5:54 PM, Oben <oben...@googlemail.com> wrote:
>> Well, I think I've integrated all your adjustments - real world will
>> say something different probably: could you please test the latest
>> changes? I did not integrated your Winamp adapter yet. I'll merge it
>> directly once the base porting is finished.
> It looks good! I actually had to bring the Winamp adapter into the
> tree since that's how I do my testing.
Great!
>> I think now we have a common code base to continue the porting and
>> merge changes directly on SCM level.
> I'm a little confused at this point (a bit new to git, hopefully you
> can shed some light). I locally branched from remuco/master again for
> some small touchups, but now I can't push to cpatulea/remuco/master
> because of the divergent histories. Ideally I would also would like to
> somehow keep that history (of the port development), any idea how to
> do that?
As I'm not a Git user, I cannot help much. Personally I use Mercurial
- the Remuco repo at GitHub is a mirror of the Mercurial repo at
Google/BitBucket. Anyway, in principle you have to get the main line
(obensonne/remuco) into you fork. You then have two branches/heads, 1)
the mainline, i.e. my changes pushed yesterday and 2) your
experimental windows port changes. You should now make the mainline
branch to the new master of your repo and use your previous master as
kind of a personal dev branch. Your future changes should go on top of
the mainline, so I can merge them.
Sorry, I can't help with explicit git instructions, maybe Igor
(Almeida) can help here?
In case everything fails, you could still re-fork at GitHub and and
rebase your changes onto the new fork.
> Regarding purepython-gobject, how about I add a conditional "import
> gobject" in remos and change all the "import gobject" elsewhere across
> the project to "from remos import gobject"?
Yes, sounds good.
Igor Almeida
I'd just need to know how far you managed to go with the merging.
> --
> You received this message because you are subscribed to the Google Groups "remuco" group.
> To post to this group, send email to rem...@googlegroups.com.
> To unsubscribe from this group, send email to remuco+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/remuco?hl=en.
>
>
--
Igor Almeida
Oben
I'm planning to release Remuco 0.9.3 this month. Would be great if we
already have Windows support in this release.
On Feb 11, 7:13 pm, Igor Almeida <igor.cont...@gmail.com> wrote:
> Sure I can try to help.
> I'd just need to know how far you managed to go with the merging.
>
>
>
> On Thu, Feb 11, 2010 at 3:09 PM, Oben Sonne <obenso...@googlemail.com> wrote:
> > On Thu, Feb 11, 2010 at 3:59 AM, Catalin Patulea <c...@vv.carleton.ca> wrote: