Re: [Freevo-devel] input architecture
Petri Damstén wrote: On Thursday 23 September 2004 19:07, Rob Shortt wrote: - Define and refine an input architecture for Freevo. I really like your idea of a clean input architecure! This would simplify the installation because one more dependency is out of the way. This might be good place to re-think about mouse support in freevo. I think that most of the input devices can be put either of these groups: 1. Arrow keys + buttons - Keyboards, Joysticks, Remotes, Mobile phones, ... 2. Pointer + buttons - Mouse, Touchscreen, Trackball, Touchpad, ... Group one works nicely with freevo now, but group two would need some work. Maybe something like that detached player for extra buttons and ability to select items with cursor would be enough. Well atleast it might be good idea to think about this if the input architecture is rewritten. First thought: Are there really users which want to use a mouse when they are sitting in their livingroom?? Second thought: Still, it might be a good idea to have generic mouse support in the architecture. Imagine a web browser plugin (gecko engine in a custom frame or just a skinned firefox), it would be certainly annoing to use up/down buttons to reach the links, for example. Third thought: You are right, we should think of it :-) Greetings, -- Thomas --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
Re: [Freevo-devel] input architecture
On Thu, 23 Sep 2004, Rob Shortt wrote: > > - Remove the dependency on pygame for user input. > - Define and refine an input architecture for Freevo. > - Keep the input configuration easy for users. > > > Concerns: > > - If we remove pygame import from config.py and keymap from event.py > it will restrict the user's ability to define a keymap based on > the pygame keys inside local_conf.py (as it stands now). We would > have to rework how we allow users to specify their own mapping. > > Hi Rob, Are you aware that in kernel 2.6, there's an input layer which pretty much maps to the keyboard events provided to X11? I don't know all the details, but basically my new TV capture card with IR remote (saa7134-based) doesn't need to use lirc to capture and decode the button presses. I'm not sure about the status of the other IR remote devices, whether they're being ported to the input layer. In fact, lirc in cvs (0.7pre7, last I checked) now has input layer support. I havne't figured out how to map them to freevo events yet Worth a look I believe. T.C. Wan Tat Chee (Lecturer) School of Computer Sciences, Univ. of Science Malaysia, 11800 USM, Penang, Malaysia. Rm.625 Ofc Ph: +604 653-3888 x 3617 NRG Lab Admin: +604 659-4757 Rm.601-F Ofc Ph: +604 653-4396 Internet: [EMAIL PROTECTED]Web: http://nrg.cs.usm.my/~tcwan GPG Key : http://nrg.cs.usm.my/~tcwan/tcwan-nrg-20040805.asc F'print : 4B2E F0BF AAD7 2F51 CB41 4386 F72B 7859 8278 BDC4 --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
Re: [Freevo-devel] input architecture
On Thursday 23 September 2004 19:07, Rob Shortt wrote: > - Define and refine an input architecture for Freevo. This might be good place to re-think about mouse support in freevo. I think that most of the input devices can be put either of these groups: 1. Arrow keys + buttons - Keyboards, Joysticks, Remotes, Mobile phones, ... 2. Pointer + buttons - Mouse, Touchscreen, Trackball, Touchpad, ... Group one works nicely with freevo now, but group two would need some work. Maybe something like that detached player for extra buttons and ability to select items with cursor would be enough. Well atleast it might be good idea to think about this if the input architecture is rewritten. -Petri- pgp6JtwwiXJ2y.pgp Description: PGP signature
[Freevo-devel] Re: PATCH: nvram-wakeup integration
Hans Meine wrote: > On Tuesday 21 September 2004 16:33, Mick wrote: >> > I really like this feature also but sadly it didn't make it into >> > CVS. Although >> >> I too would like this to be worked on a little deeper... > > The last patch I sent to the list works perfectly well for me. > What's missing is mostly (as I wrote at that time) that Freevo shuts down the > machine after the recording (of course only if it has not been touched by a > human user since it started automatically; basically a plugin which listens > to all user events and sets a flag "i_have_been_touched" would be > sufficient). > > Another thing I could improve (but not before next friday / October) is the > message that appears if you press shutdown during a recording: "The next > recording will start in -47 minutes. Are you sure..." ;-) Please send the patch again. Sometimes a patch / bug reports gets lost. Dischi -- A man generally has two reasons for doing a thing. One that sounds good, and a real one. pgpIqrCD6zOg9.pgp Description: PGP signature
[Freevo-devel] Re: MMpython question
[EMAIL PROTECTED] wrote: > Hi all. > I am adding some features to the matroska parser of mmpython, notably the > chapters list. I am now able to get chapter name and position, but how to > set it into the MEDIAINFO interface ? > I try to look in the DVD files, but chapter usage thru mmpython is not > clear for me. Chapter for normal video files are more a hack than working. They are no real streams in mmpython. I guess we have to fix that for future use. A subtitle should a real stream with it's own info object, not a sible list of text strings like it is now. Possible attributes: id, lang, description (like en, director commentary), forces yes/no, type (vobsub, lst, ..) and if not inside the container filename. Something missing? This will be used in Freevo > 1.5.x Dischi -- Just remember, if the world didn't suck, we'd all fall off. pgpxN2xsRI9rA.pgp Description: PGP signature
[Freevo-devel] Re: Interaction between LCD plugin and imageviewer
Gustavo Barbieri wrote: > On my side (lcd plugin) I don't know... since my last change was a > long time ago, I don't think it was messed. I guess we need more debug information. I don't know the lcd code, when is it triggered. Even if you didn't change the lcd code, I changed the image viewer and maybe now your plugins is triggered on every loop. One problem: does the lcd plugin has a poll function which is called every 0.01 seconds? But IIRC the animation code in 1.5.x doesn't call the plugin in that case. Dischi -- Bad spellers of the world Untie! pgpP75oB7IVyh.pgp Description: PGP signature
[Freevo-devel] input architecture
Hi all, I'd like to follow up on the previous thread "further removing pygame dependency" with more thoughts on the matter and a plan of action. Below is a bit of an outline of the situation and what I would like to do to change things. Goals: - Remove the dependency on pygame for user input. - Define and refine an input architecture for Freevo. - Keep the input configuration easy for users. Concerns: - If we remove pygame import from config.py and keymap from event.py it will restrict the user's ability to define a keymap based on the pygame keys inside local_conf.py (as it stands now). We would have to rework how we allow users to specify their own mapping. New code locations: src/input/ - All input related code and plugins. - Keyboard, Lirc, NetRemote classes moved into here. - Support code for input plugins that is really generic. - Perhaps some keymap support code. src/input/plugins/ - Input plugins for pygame kb, dfb, input_event, joystick, net, etc. How input plugins would work: - Each plugin defines a default keymap for their input keys to Freevo keys. - Allow users to define their own keymap for each plugin. - The default keymap in Freevo right now is more like what the pygame input plugin would have. - The lircrc file for Freevo is really just a lirc keymap. The lirc plugin may be home to the LIRCRC config variable and not define another keymap. - Some plugins like the network remote may not need its own keymap because the commands they receive translate directly into Freevo keys (ENTER, SELECT, etc). - Each plugin appends its own input callback to the rc object. Other notes: - This would remove input code from src/gui/displays/ modules. - Could remove the dependency on pygame but still make it the default. Ideas on dealing with user defined keymaps: - Could be possible to have totally separate keymaps for each input plugin, sort of like it is now, lircrc is different from the pygame keymap. - Could extend the DEFAULT_KEYMAP with more keys to its dictionary, for each input plugin's keymap. Here we'd still have the problem of needing (for example) pygame key references in config. - Could define a new keymap for Freevo's internals. Each input plugin's keymap would have to make a reference to a Freevo key. I guess this one is very similar to the first point but with something to tie all the keymaps together. I would like to work on this very soon (this week, next few days). I have a Freevo and Mevas directfb output working now and am using a plugin for receiving events with the linux event input interface. Yes, this means I don't even need LIRC. I am not using pygame either, in fact I've removed it from my PYTHONPATH and moved the pygame code out of the way in my running copy. As of now I have a hardcoded keymap in my event device plugin but I would like to implement it properly before checking it into CVS. I also want my setup working properly before I continue on to other important items on my TODO. -Rob --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
