[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] EMI prototype

On Tue, 21 Mar 2006 12:37:46 +0100 "Ribas, Joan" <Joan.Ribas@realtech.com>

> hi,
> Like MTV, I'm going to give you an EMI (Enlightenment Module Installer). This
> program is a quick and dirty prototype for download and install modules in
> E17. 
> It downloads an xml from a web server with the info about the available
> modules (in this case it downloads from www.pon-e.org, but it could be a good
> idea to do it configurable). The xml looks like
> http://www.pon-e.org/downloads/modulos/modules.xml (of course  the info must
> be completed). 
> Once the info is downloaded, it shows an entry per module, clicking on one of
> them shows the info, and the user only need to click on the "install" button
> to get the module installed
> The used libraries are ETK

ok - nice idea... but....
1. you need to note that module api's and install setups are not finished and
set in stone. recently things changed adding a module.eap that is required for
modules for example.
2. freezing is bad. really bad. you should be using ecore_exe() and forking off
jobs in the background and monitoring progress (maybe use ecore_exe stdin/out
pipes to read the stdout from a build or install, parse it, etc. to provide
progress meters or log info etc.
3. i really don't think compiling should be part of any standard installation
process ever - it should not be a desired method. gentoo etc. people might
disagree - but frankly - they are in the vast minority. modules should be
distributed as pre-built binary packages built for 1 or more architectures and
simply "duiimped" in a location. modules should be shipped in a
installation-path neutral fashion (which is perfectly possible as they can
discover their installation directory at runtime via api calls and should be
doing just that). then have a module installer that can install in
~/.e/e/modules/ OR in a given system modules dir
(/usr/local/lib/enlightenment/modules for example). compiling up a binary module
package (lets say its a tarball) SHOULD, IMHO be a separate step done by only
a very few people (packagers) that know how compilers and build systems work
and make sure they have development packages, libs, headers, etc. installed.
end-users really should not even NEED gcc installed nor 1 single development
header/package. we should strive to make things easy simple and minimal for the
end user, and not introduce "fat" requirements to do anything useful.

so really- nice concept - but see above for how to do things nicer/better :)

> Known issues:
> - it freezes when starts (Is because of the module info download)
> - it freezes when install a module (Is because of the download of the source
> and its compilation)
> - Few checks... so is posible it gives you a segfault if you try "somethig
> strange"
> - the code has a lot of printf (I use it for debug :) )
> - the version of the stocks module that is available from the web is old :)
> what do you think about the idea? could it be useful? any comment is welcome
> P.S. sorry for my poor english

------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
Tokyo, Japan (東京 日本)