Oh.... where do I begin. I guess in the spirit of the original - you really can't read documentation nor examples, can you? let me start you with the elementary documentation:
docs.enlightenment.org/stable/elementary/
see that "getting started" ?
docs.enlightenment.org/stable/elementary/group__Start.html
oh look at that - it tells you to use a elm_win_util_standard_add() - that adds a background for you. which the api documentation if you bothered to clikc on that api call tells you. but i guess you couldn't even manage to click on this. i guess that tells me how good a developer you are when you can't even manage to get this far and instead are happy to spend hours screwing around instead. it seems you were unable to understand the consistent behavior that everything is hidden until shown too. why is it you could figure this out for a window but not the background? don't know. odd way your brain works there. why would you have to show a window but not a background. btw - the background is separated from the window because there is a relatively common use case of having a window with an alpha channel and NO background at all - or maybe your content entirely replaces the background itself and there is no point wasting time and resources an a background no one will ever see? oh the bonus - background as they are not directly tied to a window can be placed inside any widget - recycle standard background and their features inside a scroller, as a background of a table or anything else. of course there are no error logs because there is no error - what you have is perfectly valid/correct. but of course you don't read the documentation at all and instead choose to waste your hours then turn up here bitching as if it is someone elses fault. background are not a hack - your view of them as such shows your ignorance. explain why they are a HACK in any way - you do not. not in the slightest. you really just feel like mouthing off with no clue about what you are talking about.
but hey ... let's continue.
as for the "hell if i know" bit of the docs - that was a smart arse who was tasked to document something and chose not to bother. it's something we need to fix, but this shouldn't have stopped you at all. it's not even related to basic functional.
as for types. no - an Evas_Object does NOT translate to a void *. Did you even BOTHER to read the header files before saying this? oh - i guess not. let me quote then:
typedef Eo Evas_Object
oh wow... not a void.... let's check what Eo is typed to...
typedef struct _Eo_Opaque Eo;
WOW! not a void! it's a\ struct whose type is incomplete. this means its internals are only exposed inside of EFL .. not outside. wow... we have types! geeee! funny that!. i guess though you can go on and claim whatever you like to claim. your mind is stuck in C++ and Qt and couldn't possibly imagine anything else... but let us continue to tear apart everything you say at the technical level and prove it to be utter junk.
now as for the typing - it's because you'd otherwise have to cast your way to oblivion. some parent class (evas_object_move()) functions for example work on any evas object. some some derived classes and their methods (ejde_object_file_set(), evas_object_image_file_set() etc.) work only on objects of that type. if we were to use a spefiic typedef per object you'd either forever have to do evas_object_move((Evas_Object *)object, x, y); and that just leads to work work and work. we do all out type checking dynamically at runtime - just like javascript, python, lua etc. ... it's not because of a "fuck you". it's because that's the reality of C. just like it is in js, python, lua etc. - you think these languages dropped types just because "fuck you"? no. it's part of the design. but of course since your brain only thinks in c++ qt land it couldn't possibly imagine anything else and thus must interpret a "this is different" to a "fuck you". sure. i guess if you knew C you'd know this. but i guess you don't. too bad.
as for the "you bitch" comment. that does not appear anywhere inside efl at asll. i can only assume you are full of bullshit here as with a lot of the prior "facts" you have disclosed, as a grep through our codebase for efl and elementary shows no such string:
8:27PM ~/C/efl > grep -ri "you bitch" .
8:27PM ~/C/efl >
8:27PM ~/C/elementary > grep -ri "you bitch" .
8:27PM ~/C/elementary >
yes - our code does say "naughty programmer spank spank" and TELLS you what is wrong - eg object of wrong type or null object pointer right next to it. it is MEANT to get your attention. but it does tell you the problem which you cunningly lef out of your rant implying it doesn't tell you at all. let me paste some of the lines it prints out:
eina_log_print(EINA_LOG_DOMAIN_GLOBAL, EINA_LOG_LEVEL_ERR,
file, fnc, line,
"*** Eina Magic Check Failed !!!\n"
" Input handle pointer is NULL !\n"
"*** NAUGHTY PROGRAMMER!!!\n"
"*** SPANK SPANK SPANK!!!\n"
"*** Now go fix your code. Tut tut tut!\n"
"\n");
eina_log_print(EINA_LOG_DOMAIN_GLOBAL, EINA_LOG_LEVEL_CRITICAL,
file, fnc, line,
"*** Eina Magic Check Failed at %p !!!\n"
" Input handle has already been freed!\n"
"*** NAUGHTY PROGRAMMER!!!\n"
"*** SPANK SPANK SPANK!!!\n"
"*** Now go fix your code. Tut tut tut!\n"
"\n", d);
eina_log_print(EINA_LOG_DOMAIN_GLOBAL, EINA_LOG_LEVEL_CRITICAL,
file, fnc, line,
"*** Eina Magic Check Failed at %p !!!\n"
" Input handle is wrong type\n"
" Expected: %08x - %s\n"
" Supplied: %08x - %s\n"
"*** NAUGHTY PROGRAMMER!!!\n"
"*** SPANK SPANK SPANK!!!\n"
"*** Now go fix your code. Tut tut tut!\n"
"\n",
d, req_m, eina_magic_string_get(req_m),
m, eina_magic_string_get(m));
... i can go on. in fact i shall. onto the next point.
now as for events... yes - event types are a string. gtk does this too. and we document them. maybe you should have read the docs:
docs.enlightenment.org/stable/elementary/group__Button.html
docs.enlightenment.org/stable/elementary/group__Entry.html
i just picked two. there are more - a complete list of widgets et. from the elementary documentation. and what do these docs say:
Emitted signals
This widget emits the following signals, besides the ones sent from Layout:
"aborted": The escape key was pressed on a single line entry. (since 1.7)
"activated": The enter key was pressed on a single line entry.
"anchor,clicked": An anchor has been clicked. The event_info parameter for the callback will be an Elm_Entry_Anchor_Info.
"anchor,down": Mouse button has been pressed on an anchor. The event_info parameter for the callback will be an Elm_Entry_Anchor_Info.
"anchor,hover,opened": The anchor is clicked.
"anchor,in": Mouse cursor has moved into an anchor. The event_info parameter for the callback will be an Elm_Entry_Anchor_Info.
"anchor,out": Mouse cursor has moved out of an anchor. The event_info parameter for the callback will be an Elm_Entry_Anchor_Info.
"anchor,up": Mouse button has been unpressed on an anchor. The event_info parameter for the callback will be an Elm_Entry_Anchor_Info.
"changed": The text within the entry was changed.
"changed,user": The text within the entry was changed because of user interaction.
"clicked": The entry has been clicked (mouse press and release).
"clicked,double": The entry has been double clicked.
"clicked,triple": The entry has been triple clicked.
"cursor,changed": The cursor has changed position.
"cursor,changed,manual": The cursor has changed position manually.
"focused": The entry has received focus.
"unfocused": The entry has lost focus.
"language,changed": Program language changed.
"longpressed": A mouse button has been pressed and held for a couple
"maxlength,reached": Called when a maximum length is reached.
"preedit,changed": The preedit string has changed.
"press": A mouse button has been pressed on the entry. seconds.
"redo,request": Called on redo request.
"selection,changed": The current selection has changed.
"selection,cleared": The current selection has been cleared.
"selection,copy": A copy of the selected text into the clipboard was requested.
"selection,cut": A cut of the selected text into the clipboard was requested.
"selection,paste": A paste of the clipboard contents was requested.
"selection,start": A selection has begun and no previous selection existed.
"text,set,done": Whole text has been set to the entry.
"theme,changed": Called when the theme is changed.
"undo,request": Called on undo request.
"rejected": Called when some of inputs are rejected by the filter. (since 1.9)
This widget emits the following signals, besides the ones sent from Layout:
"clicked": the user clicked the button (press/release).
"repeated": the user pressed the button without releasing it.
"pressed": button was pressed.
"unpressed": button was released after being pressed.
"focused" : When the button has received focus. (since 1.8)
"unfocused" : When the button has lost focus. (since 1.8) In all cases, the event parameter of the callback will be NULL.
WOW ... funny that. right there in the docs for these two widgets... and for more too. you again didn't even BOTHER to read the docs - all online there and browsable. but hey - you're opinion is so well founded in fact and experience. let us continue.
as for your const - this is the nature of c. the void * there can point to anything at all - objects or structs that could be modified .. or not. thus adding the callback takes a const void * because ADDING of the callback doesn't modify what that points to at all. it treats it read-only, but when callbacks are called, they have to be able to modify what this points to - it could be another object, a struct, string - anything. yes - this is how shit works in C. again - you live in a mental Qt only world. you have not the slightest concept of something else and simply take it as incompetence or a direct insult to you. but no - you obviously know C so well. so let us continue with your fun-filled post.
no for what obj is - obj is always the object that called the callback due to the event. - always. no - you don't register callbacks with a list and expect obj to the the item - you registered it with the list, thus obj is the list, not the list item. duh. what would make you think that obj would magically change? the item selected is passed in as the event_info - athe documentation even states this:
"activated" - The user has double-clicked or pressed (enter|return|spacebar) on an item. The event_info parameter is the item that was activated.
straight from the list docs: http://docs.enlightenment.org/stable/elementary/group__List.html
as for types... in c you'd have to write SPECIALIZED callback add functions for EVERY event - this would just be nuts in C. of course you don't get the idea of such a compromise and it's what js, python and lua all do too - to make something more usable and less of a pain. but of course you only live in one world Qt & C++. i forgot. carry on.
now as for key names... we ensure they are consistent across platforms - so your whine about "pray it isn't ported to another platform" is utter bullshit. and yes - we use strings to avoid the insanity of an insanely huge list of #defines or enums... and it allows us to support new keys at any point without having to update our headers to make those keys available. if a new piece of hardware happens to generate some new key strings that were not listed in older headers... then your app can be written to handle it.
as for the string comparisons - they are minimal and fast given key events happen rarely in the scheme of cpu cycles... so does it really matter?
as for ther different strings of the key - you figured it out. you just didn't have enough brain to know to use the string representation - eg the utf8 string, as if you are implementing something like an entry you'd use that. as such an entry is already created and provided for you... so why didn't you use it? i guess maybe you never read the docs? or you just like to make your life hard for yourself. oh well - doesn't matter - you have the info you need - you decide what to do with it. but it seems this isn't something you are happy with doing - deciding what to do as a programmer. i guess this explains your rant.
as for layouts being immutable - bullshit. they are dynamic - they can modify elements, animate, and even be totally dynamic (create and destroy sub objects on the fly if you use the lua script+only objects ... but i guess you didn't). layouts are a defined layout + behavior of a set of elements - you can change the images (switch the state of a part to show a new image) hide it and show another. most of the widgets and animation in enlightenment and efl is all based on these edje files that layouts use. they animate and are dynamic. they were designed originally as an "overengineered PSD" that allows you to have various layers so they can scale/reisze separately when objects resize and scale and to modify the state of the parts - it grew a lot over the years and can do a vast amount, if you bother. but i guess you wouldn't bother. you'd rather just call it "godforsaken" because you don't know it - just like anyone who dislikes Qt might call qml godforsaken because they don't happen to know it. but then again by now i should know it is you. you wouldn't have the breadth of mind to consider anything outside your Qt/C++ world. carry on.
as for swallow. have you every used fvwm? oh no., perhaps you haven't? too young? never seen anything outside your environment? in fvwm you had an fvwm module - an appp that SWALLOWED other windows into its own window and laid them out. it was the buttonbox: fvwm.org/documentation/manpages/stable/FvwmButtons.php and edje just adopted this same terminology - swallowing a foreign object you can''t directly control thus taking owndership of stacking, position, sizing etc ... but no - you'd rather just say some smart arse line instead of even doing some research as to where the term came from...
as for edje_cc - it does NOt return exit code 0 on error. let me disabuse you of this:
9:00PM ~ > edje_cc t.edc; echo $?
edje_cc: Error. t.edc:1 unhandled keyword dwefweqd
edje_cc: Error. PARSE STACK:
dwefweqd
edje_cc: Error. PARAMS:
255
oh look there! non-zero exit code!. not convinced. let me check the code:
9:02PM ~/C/git/efl/src/bin/edje > grep exit edje_cc*.c | grep 'exit(-1)' | wc -l
200
9:02PM ~/C/git/efl/src/bin/edje > grep exit edje_cc*.c | wc -l
205
oh wow! 200 of the 205 exits in edje_cc return a non-zero exit code! WOW!
of that grep one was a false-positive of a comment, another was an atexit - so not exit, another a false positive with an if() and the last 2 exits were 1 exit(0) and another exit(1) .... so there is a SINGLE exit(0) in the entire codebase. sorry - you are full of so much crap it's not funny. what you say is PROVABLY wrong but sure, your opinion is based on facts. carry on.
as for EFL freeing your memory - the docs will tel you if you have to free, or EFL frees - yes. that's live in C. but of course you only know the c++ Qt. but of course - blame EFL for this. sure. a reality of C is our fault. indeed. (and i wonder how it is we can manage to write efl and apps on top and not suffer from things like double-frees and you can't? weird!)
as for genlist - yes - it keeps only the active set of items as full objects. it has nothing to do with ram - it's actually working hard to do object setup, processing signals and events, calculating layout positions and sizes etc in order to keep memory usage down and speed up for when you have like 100,000 items. there is a simple list for smaller number of items that doesn't do this that is simpler to use.
now as for the crap you are spewing about the "complaining about backtraces of bug reports" bit. let me fill in the stuff you leave out. efl checks object validity by looking at the first 4 bytes of the memory of the object. in here is a "magic number" that indicates both type and that the object isn't freed or garbage memory. we got lots of bug reports of "a bug in efl" what it ended up being is our magic number check crashing because ap app calling it used a garbage pointer - thus our dereference was pointing to somewhere invalid thus it crashed. in the wonderful way bugs are handled - this was filed as an efl bug. if you try and explain, you can't close it until you have PROVEN the app is at fault passing in a garbage pointer - this logic was not understood, so efl is now working around this to actually not use pointers for objects at all. but you didn't really understand what is going on. we indirect to a table that is managed in order to get actual object pointers. the "pointer" exposed to apps is now an ID stuffed into a pointer for API/ABI compatibility. so no - you didn't get it. we didn't so anything with typedefs here. but .. again - facts. or lacking. as for feedback - yes - the api gives feedback. you get loud complaints when an object has an invalid ID (or type - ie missing the class). these get logged to stderr by default. so totwlly wrong on the "no feedback" part. missing facts i guess? oh and maximum number of objects being 512.... BWHAHAHAHAHAHAH so crap. you have no idea. we use 9 bits for generation count on 32bit. the rest of the 21 bits is for object id's - that means about 2 million objects. as our objects are generally rather large, you'll hit memory pressure before you hit object id limits. we have all of efl , enlightenment, elementary, and multiple apps running today with 1000's of objects - even 10,000's and it works fine - proof that you have no idea. but indeed - carry on.
oddly enough i wrote a terminal emulator using efl in a week while on holiday - most of the work was actually figuring out all the terminal pty stuff and basic escape codes to make it work enough to use. one person, one week, a terminal emulator, i wrote a video player (also does music) mostly in a weekend:
enlightenment.org/p.php?p=about/terminology
enlightenment.org/p.php?p=about/rage
most of the work was in design and graphics, deciding what it should look like etc. - proof that efl does not take huge teams to make apps.you really more than likely are just a clueless programmer who can't adapt to something other than Qt.