On Thu, 15 Oct 2015 15:21:41 +1000 David Seikel <[email protected]> said:
> 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? because this costs code and ADDS more code duplication. we can't use ecore_thread in evas. we can't even use ecore_time_get(). we end up duplicating. i recently ducplicated this time get in eina_debug so i could get timestamps. > 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. then it doesn't affect you. you are on efl 1.7 - so what we do will not affect you as you haven't even moved beyond that. :) > 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 i guarantee you that you violate that. you will have tonnes of code never triggered or run or part of its legal usage because that is how things work. you will have code there for logging and debugging that is never used or part of the system definition. you will have code for objects you never use - do you use line objects? polygon? i can - i gauarantee you - find MOUNTAINS of code that is totally unrelated to the defined function of your device - in efl 1.7 and before even. you want an audit? i guarantee you you'll be caught out. so all we're doing is expanding what is considered core. if YOU don't need it for some obscure legal definition - then it's kind of your problem. no project is going to 100% match your required legal definitions. you AGREED to these with the price you bid. you made the choice. you could have refused and been sane and said "this simply isn't possible unless you put in a clause to make it a best effort based on provided software stacks you depend on". i GUARANTEE you you have code in your libc that is unrelated to the legal definition of your device and it's not used - yet it is there. did you audit and fix all of that? your argument doesn't work to me because you are already violating it many times over and somehow this is acceptable, yet it's not acceptable for an upstream project that you will never update to (still on 1.7) to expand what its guaranteed featureset is? why do i not see you reviewing EVERY SINGLE FUNCTION we add to efl going "make this an ifdef - it isn't legally required my my contract project - you must make it an option". every single function added to eina? did you say anything wen i added eina_evlog? or eina_threadqueue? what about eina_tmpstr... i saw no complaints? what about the evas filters? masking? those are legal requirements in your contract even though they never existed before? you already violate this requirement many times over in many places. if you want to be pedantic about it you absolutely do. of COURSE the INTENT is that you don't put an irc daemon on a device that is meant to handle missile guidance (and let's not get silly with missiles guided by irc - you know what i mean) or whatever. the point is to not EGREGIOUSLY put software on that is totally unrelated. if it is a simple bi-product of the software that things are based on and those are the requirements that it has, and such code doesn't INTERFERE with the purpose of the system - then this is sane and is the probable INTENT of such restrictions. it is YOUR task to ensure that such contractual restrictions match reality so you don't get bitten, OR you accept the fact that the system must be totally coded from scratch (kernel and bootloader and up) to ONLY meet those spec and then charge accordingly. your contract would be much more expensive then and you may indeed then lose out to a competitor who is bending the rules to be cheaper rather than be pedantic. so it is your choice. > 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 they already are. guarantee. > 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. as above. you ALREADY have code that is unrelated. all over the place. and more unrelated code is added daily in upstream efl. even at the lowest layers. > 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. you'd be screwed with all toolkits as they all will have input method suport buried right deep into them. deal with it. :) and as i said - x, wayland etc. are display system specific and already optional. we'd just be putting them into a single .so at compile time. but input method support is a BASIC part of input. what about the code in elm, edje that handles space? ctrl+c? you already violate your legal requirements. are you shouting for us to remove all code that isnt numbers to meet your contract requirements? because that *IS* what you have to do. sorry - input methods are as basic to input as ctrl+c or space. if you disagree and your reason is "legal" then you already violate the (actually you violated a contract) and you already should have MASSIVELY modified efl to the point where you just cant upgrade, or you should have built your own toolkit entirely to meet only those specs. > > > 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. the world has moved on. tiny is bigger these days. i listen, i just think you're claims are without merit because: 1. efl 1.7 violates the crap out of them. vast parts of eina, evas and edje will be unrelated to your system and they will violate it, yet this is fine for you. the point at which someone goes "my god don't bring more beer into the house! beer is illegal!" then sits back and opens up another bottle of cold beer from the fridge... that message is lost on me. PROVE to me you do not. edje_entry - all the stuff handling things other than JUST numbers. go on - did you remove it all? did you? did you profile all code paths used or needed and remove the ones never needed or used from all old 1.7x efl libs and glibc and kernel and... ? no. so ... let's get over this bit. 2. the day you are actively fighting every single api we add because "it's not needed by my contract" is the day i might take this reason seriously. (though you can bet you that none of this will ever be listened to because it would just fundamentally freeze development and mean we can never add a feature ever again just because of you). > For the record though, this embedded project of mine currently uses > these separate EFL libraries from EFL 1.7.4 (pre EFL merge) - and you can never update - ever because we added masking and filters to evas - not needed so you are already screwed. you never said squat on any of the 100's of features added to efl since 1.7. > eina, eet, evas (frame buffer only), ecore, embryo, and edje. With a what about map {} states in the edje part descriptions? do you rotate/3d map parts? of not you have unused features and code there in your system - violate. do you begin to get why i don't take this seriously? :) > 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. a stub is code. minimal, but code. and it's not part of the system usage definition. violation! you should have removed all gettext code f2rom efl instead (along with lots of other code). do you use bitmap fonts? or outline? or both? freetype contains code for bitmap font handling (eg embedded bitmaps in ttf's or pcf fonts etc.) did you remember to audit this and remove it if not used? :) i can go on endlessly... > Then there's the actual application itself, though it's totally > proprietary, and you have probably never heard of it. so looking above - you'd get ecore_audio, elocation, ecore_imf, efreet, eldbus, emotion added. ephysics is already optional. ecore_con and ecore_ipc are already reqs of ecore_evas. emotion wouldnt need a backend module which means it'd be non-functional so you dont pull in all of gstreamer for example. elocation relies on a dbus service that won't be there - so non-functional. ecore_imf is really a core part of input and it being a separate lib is an accident of history and it should always have been core. so it's really ecore_audio, eldbus and efreet added for you. just like the piles of existing code you have that is not needed for your system - it just will be part of the footprint i guess. it's not huge and nothing you don't already have to deal with. :) > 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. so we're expanding your "unused code" by a fairly small amount. ecore_audio, eldbus, efreet, emotion (core api only). the rest is optional anyway and will stay so. emotion i don't see as much code and burden until you start sucking in the actual modules. reality is you will have to deal with unused code. it's already all over the place in your project and this isn't going to end. sure - it's being expanded, but the expansion is making useful functionality a core thing. emotion should really be a core thing given efl's entire purpose. the modules are plugins - sure. ecore_audio also should be a core thing if emotion is there - ecore_audio for pure audio only is simply logical. > ------------------- > > 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. if you wish to abide by your "law" you HAVE to. if you do not want to or will not, then accept that you will never move forward and accept that you already violate heavily, and that's that. if you do want to move forward know that you will be FIGHTING to REMOVE massive amounts of features (evas filters, entire api sets in eina, etc.), or simply accept that this is the "cost of doing business". > 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! i added a splash screen form like almost the first days of e17. so i don't buy that. it had nothing to do with efreet. but indeed dealing with fdo standards is a pain. i much preferred the simple .eap stuff as it was so much simpler to deal with and faster, but instead efreet has a complex directory watcher and mmaped cache files to try bring it to some sane semblance of speed. i also dislike the whole fdo thing here. it is far from anything you could call efficient. but it is something we have to deal with one way or another. e16 just had scripts to import apps not e's menus. perhaps somehting similar should exist for efl - we have an efficient native "db" of icons and apps, mimetypes etc. and we have tools that run separately that monitor and "import/update". it sounds a lot like efreetd + efreet now - but i'm thinking more decoupled. either way efreet is necessary and it's required by elm and e. that pretty much means almost all efl apps. MOST efl apps use elm. > 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 hahahah. :) but seriously i know your complaint. the problem is that i don't buy it given copious reasons. w'rre not going from "zero code yo don't need to mountains" it's more code you don't need - but you already have that. it's a matter of degree. X more code for Y more features. worth is yes/no? and as i said - things like ephysics being optional, ecore_x/wl/win32 etc. being compiled conditionally isnt changing. but things like networking being a core thing as well as ipc is a good thing imho. it raises the bar for minimum and make minimum far more useful. imf being a core part of ui imho is almost not a negotiation point. we've had fields in events reserved FOR input methods and composition since before imf appeared. it was intended to go down low but ended up a lib on its own. emotion imho should be as core as edje. ecore_audio too for the same reasons etc. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
