Disclaimer: 12 hrs into a wine tour/night on the town. Respondant is intoxicated.
I think its more about reducing the basic package to whats 'needed' by the average user. It becomes a grey area because E reaches across a broad spectrum of devices... Whats the target user? If we know what that is, what should then be in the basic package. I know there is a mobile usage camp and a desktop usage camp, which i think is awesome :) but i think the user base would be desktop right now. As such, it should be more desktop orientated, imho. I know theres a mild push to keep the basic tarball on release down to a minimum... (hence my recent png squish.) Toma... On 3/20/10, Carsten Haitzler <[email protected]> wrote: > On Fri, 19 Mar 2010 20:35:33 +0100 Thomas Gstädtner <[email protected]> > said: > >> On Fri, Mar 19, 2010 at 17:25, Gustavo Sverzut Barbieri >> <[email protected]> wrote: >> > On Fri, Mar 19, 2010 at 7:39 AM, Tom Haste <[email protected]> wrote: >> >> I agree on this. There are more useful modules to most users in >> >> E-MODULES-EXTRAs that would be better suited to the main tarball... >> >> like >> >> calendar. >> > >> > Needless to say, I disagree with that. >> > >> > These are in the same class of "Mixer" or "Illume", they are or will >> > be core functionality, even if you do not use them now, you might >> > using it really soon as most systems start shipping with bluetooth (as >> > it is the case) or 3g modems as lots of netbooks to come. And they are >> > being officially included and maintained by me... so blame me at any >> > problems, these modules should work, and work well. >> > >> > What we could do is disable their compilation by default. It would be >> > the case for lots of modules, like all of the illume. This is not so >> > good because bugs and warnings would not show and thus be fixed >> > soon... the way raster likes to manage it :-) >> > >> > Alternatively, you can just disable these modules --disable-MODULENAME >> > to save your build time. >> >> I think it should stay where it is and currently be built by defau alt. >> When the release comes, it should not longer be built by default, so >> packagers can chose if they want the features without explicitly >> deactivating them (only the other way around). Same goes probably for >> most non-trivial and non-shelf modules. > > why does it matter? these modules build only if edbus has the support. they > are > not loaded by default. now if edbus has the support - ofono and bluez are > built by default - support for them in edbus anyway. and they have no > dependencies. same with connman - and hal and notify. they arte there and > provide features. building the modules for e is harmless. the real question > is... should the be enabled by default, and if so, what default config, if > any > should they have etc. > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) [email protected] > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Sent from my mobile device ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
