Resending to include joao..
r ---------- Forwarded message ---------- From: Risto H. Kurppa <ri...@kurppa.fi> Date: Mon, Sep 7, 2009 at 10:19 PM Subject: Re: om-showroom half-serious task list To: List for Openmoko community discussion <community@lists.openmoko.org> Hi David! Thanks a lot for your work! Looking forward to see the simple tool up & running! Some comments inline. On Mon, Sep 7, 2009 at 6:26 PM, David Reyes Samblas Martinez<da...@tuxbrain.com> wrote: > -Package filtering:using a config file to block some packages to be > showed the showroom package selector in order to simplify the editors > works. > I consider than devel, docs, fonts, plugins from main packages and > libraries must not appear in a application showroom so using this > principle I have reduced from 8215 to 510 using the filter criteria in > a sql statement[2] on the shrunestable database Looks good to me so far, I also had a look at the SQL statement and looks good. Makes sense to filter away ~everything that is not a 'end user application': filter away all libraries, fonts & stuff, jus like you did. Any changes of posting a list of the 510 accepted packages to a pastebin for example for us to see what gets through. > Doubts on how to face the implementation of this: > -two approaches: > -on the import itself, no include this on the database on import > -pros:small and more quick database > -cons:a package not imported will be not posible to be included in > the showroom > -filter it on the showroom editor , build the sql query online using > this "blacklist" file to retry the allowed packages to be included. > -pros:possible to disable/modify the filter by the editor and being > able to include any package on the repo > -cons:big and slow? database, a bit more dificult to implement edit > management part. > This point is the first I will dedicate some time once the approach is > decided, if no input received I will procced with the second approach I don't know. But anywhere there needs to be the possibility to upgrade the database as new apps are added to repository -> it needs to be very automatic. To me it looks like that the filtering would be easiest to do when importing not to bloat the database with unused information. > -Web application (om-showroom it self) > Due the design is still pending I will start development on an an > ugly plain text and html tables without care about, styles, colours > or nothing image/look related , only focusing in that the info can be > shown and edited I agree - but use <div> -tags to make it easy to create a CSS template. Or what do I know about web pages.. > For the first release > -Welcome page > -App Navigation: > -the categories will be predefined with the freedesktop.org Main > registered ones[1], if the amount of apps of one category began to > rise then a two level navigation will be implemented using the > additional categories of freedesktop.org too. > -App Details: > -main screenshoot: a predef image will be shown if no one is uploaded > -Short description:based on the package description will be showed > in the applications list during navigation, editable through > application editor no mor e than 255 chars > -Description:description without char descriptions and surely not on > this release but in next ones with wiki formating style. > -package name, source and homepage inherited from packages info Look good! > -comments > -voting I'd be ready to drop this from the first version unless it's very easy to implement. Don't spend too much time on this. > -more screenshots?(doubt if it will be included on this release) One is good for the first release. > -additional links?(doubt if it will be included on this release) One is good for the first release. > -Editor page > -Form for edit all the above with > -Package filtering?(see Package filtering item above) > -Only apps with asociated package are allowed > -clear way to know which packages is already included and what > are pending and what are rejected (must be included on the filter?) > -The fist time an app is included this description will be > filled with the package description > -have in mind the future features, (multi-distro, multi-distro > version.. etc) Looks good. > Well that's all for now, :) I hope my next mail will be with something > to show, in spite it will be ugly :) nice, nice! Please have a look at this: http://aseigo.blogspot.com/2009/01/building-community-around-your-foss.html - I think it's vital that there are more people working on this than you (and entil/Markus) alone! I'd possibly drop themes away.. (regarding e-wm-theme- ) r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community