On Thu, 15 Oct 2015 12:08:37 +0900 Carsten Haitzler (The Rasterman) <[email protected]> wrote:
> On Thu, 15 Oct 2015 12:30:11 +1000 David Seikel <[email protected]> > said: > > > On Thu, 15 Oct 2015 09:44:00 +0900 Carsten Haitzler (The Rasterman) > > <[email protected]> wrote: > > > > > so to that effect in future we MUST merge libs. MUST merge > > > modules. this does not mean we have to rename functions, but we > > > need to build differently. my take for NOW is that we need to do > > > this: > > > > > > lib... > > > > > > efl, eina, eo, emile, eet, ecore, eio > > > -> efl > > > > > > ecore_input, ecore_input, ecore_audio, elocation, ecore_con, > > > ecore_ipc, ecore_imf, efreet, efreet_trash, efreet_mime, eldbus, > > > ecore_file -> efl_sys > > > > > > ecore_drm, ecore_x, ecore_fb, ecore_wayland, ecore_input_evas, > > > ecore_imf_evas, ecore_evas, evas, edje, emotion, ector, ephysics > > > -> efl_gfx > > > > > > ethumb_client > > > -> stay for now (be replaced in future with a non-dbus file > > > "preview" infra that doesn't require a central daemon - things > > > like SMACK make ethumb pretty pointless, so move it more to a > > > fork+execced child slave process to do the heavy lifting so > > > permissions are inherited from the parent). > > > > > > eeze > > > -> stay for now (be replaced with a high level device > > > abstraction that doesn't look like or depend on linux sysfs at > > > all) > > > > > > elementary > > > -> stay > > > > As you know, I'm always harping on about squeezing EFL into tiny > > embedded devices, and you specifically mention 32 MB systems. Your > > response in the past to my concerns was along the lines of "compile > > everything, leave out the .so files that are not needed". While it > > was a barely acceptable solution to me, now you are planning on > > taking that solution away. > > correct. the benefits are not worth the cost. reality is that 32mb > systems work FINE with an efl with "everything there". the utility of > the features and ability to DEPEND on the features being there in efl > code without if ()'s or #ifdefs and fallbacks and "oh that only now > half works because the feature was disabled" is worth the cost. I think it is worth the cost, otherwise I wouldn't be bringing it up again. Hell, EFL USED to cater to this, I don't think it was worth the cost of no longer catering for it. > > My previous embedded project used pre merged EFL, though that's > > mostly coz the majority of my work was done before the EFL merge > > was started. I'll be considering a new project soon, one that was > > planned when I wrote the original, and based on the original. At > > the moment I can't see that progressing to modern EFL, even though > > there's some new API that might be useful, not to mention copious > > bug fixes. This proposed change of yours would move EFL too far > > away from being useful for these projects. > > actually that is a decision on your part to not accept "more". you > would have to accept "more" if you built your project on chromium > like some do, or qt, or a wide range of other toolkits. I picked EFL, coz at the time, there was the option of not having to deal with "more" (well, among other reasons). So that substantiates my claim that for this sort of project, EFL will become just as bad as the rest. Why would anyone pick EFL? The ability to not accept "more" is part of the attraction to EFL, that helps differentiates it from those other projects. Why get rid of that and be like every one else? Chromium would not be suitable. QT could be, and I even know some of the QT developers (the QT presenters at linux.conf.au, where you and I met, where in the same computer club I was in at the time). Too late to change horses though for this project. I'll probably just end up sticking with pre merged EFL for the next one. The decision ISN'T mine. I have pointed out before that it's the LEGISLATION that requires nothing on the device that isn't part of it's LEGALLY defined function. Hiding this excess crap deep inside of a library doesn't count. So support for X, icons, intl support, virtual keyboards, or touch screens would actually be illegal for this class of device. And there's a chance that government audit labs will want to audit the device, so they'll find it, and my client will be in deep shit. Not to mention the extra cost to my client of the audit lab having to audit all this extra code that doesn't do anything for the device. It's the L.A.W. law, my client has to follow it, so do I. EFL doesn't have to follow this particular law, but don't claim this is MY decision that I have to. Sure, I'm not personally happy with this plan of yours as is, the legal aspect just makes things worse. It's the legal aspect that is forcing my hand. > the way i see it, is it's better to be able to "guarantee that you > can find an icon for X" than maybe have an api there or not (efreet). > it is beetter to guarantee full intl input method support (ecore_imf) > than maybe have it work, maybe not. we HAVE to have this for decent > virtual keyboard input for touch screens. we have to have this for > pretty much any language in east asia and having that all optional is > not worth the cost. None of that stuff is of any use in this embedded project. There is no X, icons, intl support, virtual keyboards, or touch screens. English only in this project, and barely any of that for the main users. Most of it is numbers, in Australian format. > > So please, let's consider those 32 MB systems when we make these > > plans to reduce options for reducing the footprint. Coz in the > > end, it wont be reducing the footprint if all this extra unneeded > > crap has to come along for the ride. Just makes things harder for > > tiny system developers, which might just make us choose something > > else. I'm too heavily invested in EFL across a few projects, I > > really really really don't want to be forced to choose something > > else. > > 32M RAM is what i am speaking of. if something isn't used it > shouldn't get paged in (as long as the code for that is localized and > not scattered about). There's no guarantee that the code isn't scattered about. Still have to mess about with useless dependencies. It's not just RAM either, this new plan introduces extra complexities across the board. And see my note above about legal requirements. > give me a list of dependencies you don't want. Would be quicker to give the list of dependencies that are actually used by this embedded project, but what's the point? You never listen to me when I raise these concerns, you are not listening now. All the stuff you mentioned above about fallbacks doesn't matter for these sorts of embedded projects. EFL makes grand claims to be able to support tiny devices and embedded projects. How about a bit of actual support then? I see no point in creating all this extra work for people that just need a minimal embedded system. For the record though, this embedded project of mine currently uses these separate EFL libraries from EFL 1.7.4 (pre EFL merge) - eina, eet, evas (frame buffer only), ecore, embryo, and edje. With a large number of --disable-* options for them. The edje mostly uses Lua for the scripted bits, but there's some minimal embryo. It was my main test bed while I developed Lua for edje. It also uses these other packages (not all of them are dependencies) - Linux kernel, uClibc, toybox and busybox (busybox is needed coz not everything is in toybox yet), zlib, e2fsprogs (only the ext3 version of fsck, coz the busybox / toybox versions don't support ext3), libjpeg, libpng, freetype, lua, iana-etc, and grub-legacy. Also a gettext stub is included, not coz it's needed, but coz gettext is a dependency, but it was better to just provide a small stub instead of full blown gettext, and such a stub was already available. Fontconfig used to be a part of it in earlier builds, but I managed to get rid of the need for that dependency. Then there's the actual application itself, though it's totally proprietary, and you have probably never heard of it. For the next project that is based on this, some form of networking might be added, but that's not likely to require any more packages. I might replace uClibc with musl, busybox might manage to go away if toybox replaces enough, and e2fsprogs will go away when the toybox fsck properly supports ext3. The need for fsck might go away if I get my way with the new hardware design (so far the client has rejected this particular hardware change twice for the old project). Grub might also get replaced, but that's just coz we might move to ARM for the next device, which grub doesn't support. Not planning on adding any more packages, but shit happens. I am legally required to keep extra packages to a minimum, as pointed out before. ------------------- Don't get me wrong, I still love EFL. I'm just a bit concerned with current directions turning it into yet another ordinary toolkit, most of which are crap. We don't need yet another ordinary toolkit. Sure the tradition in EFL is to rewrite bits, but these days I want to concentrate on writing applications instead of libraries. Otherwise I would just rewrite some of the crap that has crept into EFL. Don't even get me started on efreet. Crap code written to replace crap code I had half written, coz someone thought mine was too crap (based purely on style??!?!??!!), and they wouldn't give me a chance to finish it. Mine was destined to be less crap, but the FDO protocol itself is crap, my initial code reflected that. There are still bugs in efreet being solved today that my original didn't have. I had a half hearted plan to rewrite efreet, but I got busy writing applications. After that, all the work I did to get Enlightenment start up time down to much less than a second has been wasted as well, now it takes so long that we need to provide a splash screen. Not happy Jan! Think I'll stick to writing applications. Though my big virtual world project includes rewriting some UI library stuff I wrote in Java, to now be in C/Lua, but based on EFL. (More of a reboot than a rewrite.) I'll likely include the widget set I had planned for that old Java project, then replace Elementary with it. With any luck, the EFL project will accept it as a traditional rewrite of Elementary, in the same way that Elementary replaced the EFL widget sets that came before it, and is replacing Enlightenment widgets now. That will make me happy again. So yeah, happy that your plan includes keeping Elementary as a separate library. B-) Yes, I know, it's not about making me happy, but I'm trying to not just cater for me here, others will have similar problems. Hell, I'm not the only one creating devices that have to follow this particular legislation, though my client will probably have my guts for garters if I try to sell EFL to the competition. lol -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
