OK, some mine recommendations / wishes :

1. simplifying of keyboard and IR control of freevo. Now it uses too many keys, some of them I don't feel as necessary and it's impossible to map it to some simpler IR controllers. I would recommend similar system as in my cell phone - two direction keys (UP/DOWN), two activity keys (ENTER and cancel) are sufficient for anything you want to do. It would also require changes in selection control as it must be mapped only to the UP/DOWN direction keys only.

I know that the feeling differs from user to user, so could this be made as user configurable thing? Any ideas?

2. Split i18 translation file to separate parts, named by calling module name. After change of a module it would require to change appropriate translation file only, adding of modules would be easier and independent of the Freevo core.

3. Selectable character sets for MP3 tags. I have a large collection of MP3, but some of them have tags encoded in CP1250, other in IS8859-2. I'm not able to display them correctly without changing the tags. I'd suggest user configurable option per directory.

4. IMDB seaarches only for current file name. As it is often very different of the movie name, the search either fails or fetches unusable results. It would be nice to search for an user-defined text. But this is dependent on

5. text input plugin. If we want to give users the ability to change config directly from freevo, we need to make a text input plugin. It is no problem with keyboard, but it may be problem with IR controllers. Is it possible to implement similar control as with cell phones, i.e. several presses of button changes the entered value. Is lirc able to support detection of several presses of the same button and pass them to the caller?


For now it's all,

thanks.

Jirka

Dirk Meyer wrote:
Hi,

[ notice: this mail is stored in WIP/Dischi/future_ideas in CVS ]

This mail covers some ideas what I want to change in Freevo after 1.5
is out. There have been different discussions on the mailing lists
about new features and cleanups and I also did some thinking on my
own.

Since this list is long, it would be cool if someone picks a task to
do. Some things require deeper knowledge have some Freevo code, I
guess it's better I do it (and document the stuff). This list is
unsorted, if you want to do something, just do it. Or maybe you have
some additional ideas, just send a mail.


MAKE EXTRA FREEVO INDEPENDED PACKAGES OF SOME MODULES -----------------------------------------------------

The idea is similar to mmpython, only that I don't think of an extra
project. We have some files belonging together and they don't need
Freevo. Making extra packages will make it easier for other projects
to use, to update after a bugfix and for us to maintain since they
have no dependencies.

I'm thinking of a directory 'lib' or 'site-packages' inside 'src' or
at the same level. Right now I would prefer 'lib' on the same level
as 'src'.

To make a small list of files I'm thinking about:

lib/pyepg:
----------

pyepg shouldn't have a very simple interface: update database and
get epg. The update function is similar to the tv_grab helper we
have now. The get gives Python objects. Using xmltv should be hidden
inside this module to make it possible to use other grabbers like
parsing the epg from vdr. The module should store the data somewhere
(e.g. /tmp/TV.xml) and transform it into the Python objects, but
caching it using (un)pickle should be done by Freevo (similar to
mmpython).

Included in this package are epg_types.py epg_xmltv.py xmltv.py and
tv_grab.py


lib/webinfo: ------------

The name sucks, but the idea is to make a module for all files getting
additional informations from the net. Right now we have amazon.py for
audio and an imdb grabber for video. There is also an external plugin
for some French site. The idea is a clean interface with auto loading
so that placing a grabber inside the dir would activate it without any
more changes. The lib won't write fxd files, this is part of Freevo.

Interface:

search(name): returns a list of identifer and a name for
              each identifer where to get the information. For imdb
              this is the search returning name and imdb id.

getinfo(id):  returns a defined struct with informations. For imdb
              this are the informations we have right now, cover is
              a list of images (not files). Amazon will return the
              same type of struct. Maybe we also use additional
              informations in the future, not only the cover amazon
              has.

The format of the id depends on the backend (imdb, amazon, etc)



Notice: these packages are not 100% independed from Freevo. They need
some variables in config.py and also String() and Unicode() for better
Unicode handling. I tested building pyepg and ended up with a
compat.py to make pyepg working inside and outside Freevo.




CREATE NEW GUI TOOLKIT
----------------------

Right now we have osd.py, the animation and gui dir, skin.py and the
skin area definitions in skins/main and skins/plugin. But when is
something in osd.py and when in skin? Some parts using osd.py also use
the skin to get some images. The animation bypasses the skin, the gui
is a bad mix. Some parts of Freevo even import pygame for some stuff.


On the other hand we want to support other drawing modules like pydfb
and bmovl(2). The discussion on the mailing list gave me a good idea
what we need. The skin code is very similar to the idea I have.


I started changing the skin code to see what can be done and here is
the new design proposal:

o We have everything gui related into the gui subdir. The current code
  in that dir is more gui/widgets.

o As abstraction we have gui objects like Image, Rectangle and
  Text. The skin code only knows this three and works fine. It should
  be ok for all parts of Freevo.

o This gui objects where drawn onto layers. The skin code knows three
  layers: background, alpha layer and content. I guess for the first
  version it's ok to only have three layers.

o The layers are bound to a screen object. This is the only part we
need special classes for pygame, pydfb and bmovl.


I started hacking and Image, Rectangle, Text, Layer and Screen are
already implemented. Basicly, it's only some small changes in the skin
code which already has layer and screen support. It works as fast as
the old skin code but much cleaner and easier to understand.


To test the code, copy main.py, screen.py and area.py in the
skins/main subdir of freevo.

Before integrating it into all parts of Freevo I would like to play
around with the new interface:

o Create a screen object using bmovl or bmovl2. It would look bad
  since the skin is drawn to mplayer and the rest to pygame, but it
  should give me a feeling if the design is ok.

There is already bmovl support right now. If you set BMOVL_OSD_VIDEO
in your local_conf.py to a video file, Freevo will start mplayer and
show the menu there. But you can't do anything except browing the
menu right now.


o Make it possible that object can change inside (keyword:
  animation). I will test it with some animated text for the current
  selected item.

After that, the next steps are

o Create new directory structure in gui moving the code from skin
  there and the skin areas should get a subdir:

  gui            objects, layer, different drawing backends screen
    --> widgets  the stuff that is in gui now
    --> skins    code from skins/main
    --> plugins  code from skins/plugins

  The animation code would either in an extra subdir or maybe better
  in the gui main dir.



TV CHANGES
----------

The tv part of Freevo needs different small updates. Most of them are
discussed in the mailing list or on irc.

o Split tv into tv and recording. Maybe recording inside tv, maybe on
the same level. This would result in two plugin directories, one for
watching, one for recording. Most of the recordserver code should
also move into the recording dir.


o Support for live pause. There are different ideas: create a
  ringbuffer inside mplayer, or fix mplayer to support this without
  external help. Maybe move the timeshift code from the xine pvr
  plugin to a global one so it works with dvb, too.

  I have most test code from the mailing list on my computer, if
  someone has the time to develop something like this, let me know.

o Better DVB support. I want to watch and record at the same time if
  it's the same frequence. Also live pause support is needed,
  commercial detection, VPS support, etc. Some of this is not DVB
  specific and may work with analog tv, too.



Dischi




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
Freevo-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-devel

Reply via email to