I vote for something different:
src/* -> <prefix>/lib/python<version>/site-packages/freevo
skins/main1 -> <prefix>/share/freevo/skins/main1
skins/icons -> <prefix>/share/icons/freevo
skins/images -> <prefix>/share/pixmaps/freevo (or in icons)
skins/xml/type1 -> <prefix>/share/freevo/skins/main1/xml (since those
xml should be specific to that skin code)
skin/fonts -> <prefix>/share/fonts/freevo (or just share/fonts)
helpers/ -> <prefix>/share/freevo/helpers
Those I'm not sure, maybe we should get ride of them, put them
contrib/ -> <prefix>/share/freevo/contrib
boot/ -> <prefix>/share/freevo/boot
WIP/ -> <prefix>share/freevo/WIP
HOWEVER, since freevo is intended to be in a standalone box, I like
very much it to run from a single dir, so for micro distros you wont
have to create the whole dir tree, just get the package and unpack.
Also, it's easy to maintain.
I think we should get ride, by now, of nonsense things, like:
skins/xml/type1 (what that means?! There was never a type2) and put it
--- Dirk Meyer <dmeyer@...> escreveu:
> I'm thinking of a directory cleanup in the freevo root directory. The
> basic idea is, that you should be able to install Freevo in your
> system based on the LSB, not in one dir like /opt/freevo.
> First of all, we have three locations for Python files: src, helpers
> and inside skins in some directories. So we should
> o move skins/main1 to src/skins/main1. Python files should be under
> src, possible other skins should be all in src/skins
> o rename skins to share. Everything left after moving main1 is
> share stuff (images, fonts, etc.). Also rename xml to skins,
> that are the real skins
> o move helpers to src/helpers or src/scripts. Most of them need the
> Freevo environment (e.g. import config). The best would be, to
> them with the freevo script, e.g. 'freevo imdb' will start
> src/helpers/imdb.py. The freevo script can take care, that the
> environment is correct by adding something to the Python path.
> That would be much cleaner. Next on my list are the binaries. We have
> three: runapp, freevo_xwin and fbxon/matroxset. Let's start with the
> o remove matroxset. It's in the fbcon directory to avoid havinf too
> much external deps. Very funny. We have that much deps, we should
> include matroxset in the runtime and remove it from the source
> o remove freevo_xwin. What was the idea behind this? Make it possible
> to have mplayer controlled with Freevo keybindings? Most people
> report problems with that and for people using the keyboard, we
> the same problem with xine.
> o replace runapp with python wrapper. That may be the hardest
> part. What does runapp? First, set the priority. It should be
> possible with Python, too. And it sets some preloads for the
> runtime. This also should be possible in Python. Maybe we should
> write our own popen, based on popen2 and the stuff we need from
> runapp. Or am I missing something here?
> Next on my list are other directories:
> o replace the stuff in fbcon with python functions. Or make _one_
> script from all and move it into src/helpers (but it should be
> Python, there should be no other stuff in helpers). Suggestion for
> good solution? There is also vtrelease I missed when I wrote about
> binaries. It should be possible to do that in Python, too.
> o move boot into contrib/boot
> More ideas, comments?
> Error 13: Illegal brain function. Process terminated.
> This SF.Net email sponsored by: Free pre-built ASP.NET sites
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> Freevo-devel mailing list
Conheça o novo Cadê? - Mais rápido, mais fácil e mais preciso.
Toda a web, 42 milhões de páginas brasileiras e nova busca por imagens!