OP mentioned that i watch lots of "rextube". I liked it up. You should too.
Posts made by Carsten_Haitzler
-
RE: Enlightened
-
RE: Enlightened
Ok, let me address what was written here by @Carsten_Haitzler . But first, I need to say responding to rants with personal attacks is a sure way to get burned. I recognize that you are the author of this stuff and you might be angry, especially when it's finally starting to see some usage after ~20y of development. Using ad hominem says a lot about you as a developer and a person. I'm not going to get dragged into this, that's your sandbox.
it has been used in various products for many years - long before now, and my responses have quoted fact - responded to your content directly and pointed out facts you have wrong - as well as taking a view on your competence as you re not able to actually use details and facts correctly in your original post.
Also, if you read the original post (especially the last sentence) and following comments, you would find that I'm talking about the version on Tizen. It seems the next version I mentioned is the one you're talking about.
I can, when it's there. I can when it's clear. I can when it's not lying. That's why reading EFL docs and examples aren't really much help to me.
oh look at that - it tells you to use a elm_win_util_standard_add() - that adds a background for you.
From what I can see, it creates a window and adds a "bg" object to it - exactly what I said to make window with a background. If one doesn't know about this utility function with such intuitive name, like me and pretty much everyone around me, there's no way to know to use/search for it.
first elementary doc page - click getting started. there - first example. there. elm_win_util_standard_add(). docs not lying. docs are clear. elm_win docs clearly list this function. you make a big complaint about it being hard when the docs made it abundantly easy for you. you either ignored them entirely after reading and chose to do things your way, or didn't even look. your difficulties are entirely self-induced as you chose to not use even the first first getting started guide.
@Carsten_Haitzler said:
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?
First - to what you wish to apply that alpha channel, since the window has no background? To some implicit background which is not really a background, because they're separate?
when there is no background and window has alpha - the empty area where no object is is transparent.
Second - good window managers/frameworks redraw only what is needed. If a background is obscured, no one will draw it. If no one will draw it, it pretty much is non-existent resource-wise, unless you call 4 bytes of color information a resource-intensive data structure. Literally, a pointer to your bg object takes the same amount of resources other frameworks use for bg color information. But you choose to make it a first class citizen actually adding more burden to resources and developer. There is a reason why window systems are designed the way they are, and this is not the way you did it.
in efl the background has more than just 4 bytes for color - it's far more extensive thus costs more. having the background be any object you like means you don't have special cases where you have to figure out how to turn the window background off if you want translucency etc. again - you didn't even read the first starter docs that show to use the api that adds a background for you so you don't need to know or care - but instead you chose to post about it as if that documentation didn't exist.
@Carsten_Haitzler said:
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.
I can't think of any window framework which doesn't support backgrounds in any kind of widget. The only difference is, they don't make it a separate object for no sane reason.
try add a background to a table in gtk - want it green, or a texture, or an image? nope - widget is transparent - what was below shows through. having a bg allows you to place it anywhere in your window - eg split your window into a 2x2 table and have each cell have a different background. works the same way as the window bg so it's consistent.
@Carsten_Haitzler said:
of course there are no error logs because there is no error - what you have is perfectly valid/correct.
It is valid from EFL's point of view, but creating a window and not seeing anything is not intuitive and looks like an error. One of the design rules of interfaces (in a general sense, not only API) is: it should work how a user expects it to work. I expect my window to be visible as in every other framework out there. I don't expect my window not to be visible because the author choose to oppose industry standards.
because you didn't even follow the getting started docs. the window was visible - it just inherited previous framebuffer content due to the way x11 works. as you had no titlebar or transition animation showing it appear you didn't get the hint that there is a window there and it's visible - just with previous fb content. again - if you even followed the very first docs on getting started you'd have been just fine. you didn't.
@Carsten_Haitzler said:
explain why they are a HACK in any way - you do not. not in the slightest.
Because creating a separate object for a background, and then creating a "rectangle" object when the bg doesn't work isn't a hack. Bonus related
again - how is it a hack? the background is a visible object like anything else - it's not some special case. how is that a hack? it's consistent.
hack: how to make something which was not though of as being clickable, respond to clicks? Create an invisible rectangle object and listen to clicks on it (actual implementation in one project).
in x11 have a window with a shape input mask that is empty - watch your events go through it. how do you get events on it (without modifying the internal behavior of that window)? cover it in an input only window to gather events (or stack one below, ... or reparent it to a window that takes events). same thing as that. the object was explicitly designed/intended to not get events. it's sticking to its design. YOU want events there - then yous an object of your own.
@Carsten_Haitzler said:
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.
Users don't care who made it and why. Users want good documentation and documentation like that actually can stop them. Having to dig through the code, instead of reading the docs, is repulsive. Telling them it was a joke, is not an excuse.
first - i said it needed to be changed - but you chose to pretend i didn't say that. i did explain it was a smart-arse comment that shouldn't be there. you have a very short fuse when it comes to "repulsiveness". so a few "heck if i know" lines in one part of the documents makes them all repulsive? people must have to walk on eggshells around you if that is enough to be repulsive.
[/quote]@Carsten_Haitzler said:
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. l
Again - I'm talking about the version on Tizen, where it is void *. Also, changing from void * to some other type which represents everything, doesn't
no - it's not. the line from Evas.h from at least one of my tizen repositories for tizen 2.3. this is the tizen mobile repo from which tizen tv was forked:
typedef struct _Evas_Object Evas_Object;
not void. not at all. it has a type.
change the original argument that this is awful design. Let me reiterate the most important rule in making APIs: make it easy to use properly and difficult to use improperly. By using whatever placeholder you come up with for everything, you violate this principle.
@Carsten_Haitzler said: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.
Being lazy is not an excuse for bad design. By using a semi-inheritance method of C (adding base structs as fields of the derived struct), you actually could incorporate type safety. Not much work involved and much gain in terms of coherence, safety and clarity. You chose C yourself so you have to live with it and try to make most of it. Instead you abuse it's already weak type system, when the solution is so simple.
@Carsten_Haitzler said:
i guess if you knew C you'd know this.
I know C and I gave you a solution which C projects have been using for ages. It really is not a problem with the language itself, but with your design decisions.
without casting (which ends up bypassing type checking anyway) you can't do it. compiler will complain:
#include <stdio.h> #include <stdlib.h> #include <string.h> typedef struct parent Parent; typedef struct child Child; struct parent { int x; }; struct child { Parent parent; int y; }; void func1(Parent *o) { printf("%p\n", o); } void func2(Child *o) { printf("%p\n", o); } int main(int argc, char **argv) { Child *o = malloc(sizeof(Child)); func1(o); func2(o); }
results in:
tt.c: In function ‘main’: tt.c:34:10: warning: passing argument 1 of ‘func1’ from incompatible pointer type func1(o); ^ tt.c:20:1: note: expected ‘struct Parent *’ but argument is of type ‘struct Child *’ func1(Parent *o) ^
so sorry - no - putting a parent struct type inside a child doesn't result in type checking working as you imagine. it does allow for inheritance and simply treating the child type as if it were parent works fine - that is the design intent, but type checking at compile time doesn't work. and if you start casting then you defeat the type checking and also make the code more verbose.
@Carsten_Haitzler said:
yes - our code does say "naughty programmer spank spank" and TELLS you what is wrong
Really? What does:
"*** 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"tell me exactly? What magic check failed? On which object? When? Doing what? Where? What code I need to fix? None of that is in the message. I
export EINA_ERROR_ABORT=1
you get backtraces and crashes now. the complaint above is to alert you to there being a problem - get your attention and encourage you to do this. it would provide a backtrace if backtrace_symbols() was in any way reliable. it isn't. i have spent time before trying to get backtraces in these errors but libc wasn't going to play nice. so use gdb instead.
already gave you the explanation people use: "something did something". That's the exact information you can infer from the message. And that "spank" comments? Are you serious you would show that to a
client/management? It looks like work of someone with sexual issues.
i guess to someone whose tagline on their user is "sex. i like it" you'd probably think about sexual issues first. it's obviously the way your mind thinks. you may not have heard of children and yes - they can be naughty and have and still are spanked when they misbehave. but your mind i guess jumps straight into the "gutter".
@Carsten_Haitzler said:
yes - event types are a string. gtk does this too.
"Someone else did it this way" is not an excuse for bad design. I know
but you use it under the guise of "industry standard" and complaining when something is different, yet when something is the same as elsewhere and you don't like it - you pan it. not very consistent or logical.
making functions that add type-safe callbacks was work and you don't like work, like you said earlier, but the result is a safer and saner software.
nothing with not liking work - it's just not really worth the effort in C. it makes the api worse imho.
@Carsten_Haitzler said:
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.
You really mixed up notions here. You are associating a callback with some data. Neither implies mutability nor immutability of the data itself, so the decision was arbitrary. By taking a const and removing it, you opened the land of undefined behavior to developers. You allow const object, which can reside in read-only memory, to be freely modified. Either allow one form or the other, but never both at the same time.
you don't understand. you can't enforce constness there. you have to allow the data passed into the callback to be non-const because it HAS to allow modification because this is a common use scenario. it uses const void * as the input type when you add the callback because it's saying that the adding of the callback doesnt modify what the data pointer points to. the callback is an artifact called later on as a result of that event. the api doesn't guarantee constness etc. - this isn't something we could do in C unless we add yet more callback adding apis some that take const void * and some that take void * - what would be the value.benefit of that? nothing would change.
@Carsten_Haitzler said:
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,
...except when you register it with a list item and don't get the item in the callback, but the list. Either that, or our corporation list code was wrong all the time.
you mean the specific callbacks set on the list item itself? or genlist? i'llgenlist passes in the item. list passes in the list object - as the callback prototype doesn't have a item type in its parameters. the assumption is you don't need the item itself at all as the callback is meant to do a specific task - eg switch an option to that value. the item is not an evas_object as per the callback prototype. your typeing rules are being followed here - so what's surprising? the type tells you it's not the item.
@Carsten_Haitzler said:
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.
Yeah, because I can totally get XF86AudioPlay on Windows. Not to mention, you said in your later comments that you take them from X11.
it's out job to ensure you do get an XF86AudioPlay on windows - when the same "play" media buttons are pressed. if we don't - it's a bug we have to fix.
@Carsten_Haitzler said:
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.
So what's with the logical key, being seemingly for the same purpose? If they're redundant, eliminate one. If not, fix your docs.
it says it there - evas docs:
char *keyname; /**< the name string of the key pressed */ const char *key; /**< The logical key : (eg shift+1 == exclamation) */ const char *string; /**< A UTF8 string if this keystroke has produced a visible string to be ADDED */
if you press shift+5, when 5 is hit, keyname is "5", key is "percent" amd string is "%". it's documented there with even an exampe - shift+1 is exclamation. keyname would be "1" and string "!". docs are there. with example.
@Carsten_Haitzler said:
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).
Except you can't modify the layout itself. Yes, you can make SWALLOWs. Yes, you can try to script them. But you actually can't modify the layout from C when it's compiled by edje.
you modify a layout by it modifying itself - you emit a signal, send a message and the layout reacts. layouts are intended to be "opaque replaceablae data blobs". they are not bits of code just forcing you to write them in some strange and unknown new language. they are meant for themes. an edje file contains groups and you may have a group for a button - that group represents what a button looks like and how it behaves when clicked etc. - you can set the text of the label, swallow in an icon sub object, emit signals to have to do things (animate, change state) etc. the idea is you can replace that button edje object with any other - it may change its entire design, layout, number of parts etc. but the "api" bit (signals it understands or emits back to you, swallows it provides etc.) remain constant so that the data can just be swapped out for an alternative version - edje keeps the internals opaque to make this easy. so you can change - point it to a new group with the new setup, emit signals so the edje object knows it needs to change state and does so etc. there are endless examples of this.
@Carsten_Haitzler said:
as for swallow. have you every used fvwm?
No, I didn't and most developers on this planet didn't either. We don't really care where you got your name from. We know it's not intuitive and don't give
it's a term used in the past in what has been a majorly popular wm. you may be too young to have experienced it. i guess my language isn't hip and trendy enough for you . of course you would make a personal ad-hominem attack (i simply returned in kind) assuming it's a result of watching porn - and it's not. but you wouldn't be willing to admit this assumption of yours is both insulting and wrong based on simply a lack of facts and experience on your part. but hey - you'll never admit to being wrong, you haven't so far, so why do i bother?
a slightest clue what it's for. Ask a random non-EFL developer what is a SWALLOW and I doubt you get a right response. All this because something in the lines of "WIDGET_CONTAINER" was too hard, eh?
widget_container is far longer and the efl docs happily explain the concept of swallows. http://docs.enlightenment.org/auto/efl/group__Edje__Part__Swallow.html - didn't read it i guess?
@Carsten_Haitzler said:
as for edje_cc - it does NOt return exit code 0 on error.
The one gbs uses on Tizen does. I don't care if it's wrapped in something or broken in some way. I see edje_cc returning 0 and that's it. If you think someone broke it, look it up and fix it, as you are the author.
i checked. edje_cc exits with non-zero codes/ almost the exact same code as currently in upstream. it's not edje_cc existing with 0 on error - it's something else, but you are willing to blame edje_cc as opposed to look into it and maybe accept you are wrong. the code never just decided to return 0 on error - it returned non-zero on error since day one. it was relied on as part of compilaton to break and it has for many years. the code in tizen git repos i am looking at hasn't changed that. you again make accusations entirely unfounded in fact and details. i bother to look in case this is the case - i find that it's not. you could at least bother then to say "i was wrong. i'll check in detail and find out what's going on". i bothered to look - i found nothing wrong. would you bother to back up your statement with fact and details?
@Carsten_Haitzler said:
the docs will tel you if you have to free, or EFL frees - yes. that's live in C.
Again - it was your decision to use C. The onus for nonexistent memory management falls on you.
yes - and we document when you have to free something (other than the obvious case where you create a new object - we don't tell you everywhere you have to delete the object - it's a basic concept - create it then delete it when done (or hand it off to another object to own).
@Carsten_Haitzler said:
as for genlist - yes - it keeps only the active set of items as full objects. it has nothing to do with ram
Turn on logging in Genlist callback for getting item labels and widgets, and your console will be pretty much DoSed with memory allocations. This has actually been done, so stop the propaganda.
no - you're stuffing verbose "printfs" through a serial port straw most likely. yes - it does allocations. the actual allocations don't appear in profiles. at all. it's more init, set up of state and event handling. i've done the profiling. the assumption is that you will immediately retun some data - you won't open and parse a file, do a sql query or anything else - you return the data (eg label string) you have in memory prove to me with an actual profile (perf, oprofile - something) that the allocations are an actual serious issue. i have looked many times - they are not.
@Carsten_Haitzler said:
fl 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.
Except when it's disabled and you get nothing except undefined behavior. Pray for a crash then.
it's not disabled - not in any default build. if someone --disabled the magic checking at compile time of evas - then talk to them. looking at the spec file for the tizen evas build here - it's not disabled. so i doon't know what you are going on about unless you or someone else provided you with a custom evas build to turn this off and you used it - then blame the one who turned it off, not efl.
@Carsten_Haitzler said:
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.
That's because EFL does not enforce any kind of type safety, has shitty docs and mismanages memory. It's not hard to pass a garbage pointer, when all you see is an Evas_Object which may or may not be valid to call with a given function. Again - it's your design, live with it.
wrong. efl does enforce type safety - runtime for sure (unless some idiot turned it off and thus had no idea of the consequences of doing that - which is why its on by default). i have gone over many docs - repeatedly that solve your problems above and you simply didn't read them - so yes, docs you don't even read are going to be shitty.
@Carsten_Haitzler said:
oh and maximum number of objects being 512.... BWHAHAHAHAHAHAH so crap.
Taken from your own "Core Object Model" presentation:
> One in 512 chance of a false positive on valid row
you really don't grasp even basic english there do you? how does that say the number of objects is limited to 512? how? in what way at all does it even HINT at that? it's the generation count that minimizes a false positive IF: 1. the table number exists, 2. the row in the table has a non-NULL entry (an actual object in the slot), then generation count is checked. only objects allocated within the same generation will pass. every object allocation increments the generation count. yes - it wraps around. so that means if you get past the table + row check and there is an obj an extra 1 in 512 generation count check is done - that is the false positive if you get past this (and if the object is of the wrong type then you have another check that will make it not crash (or optionally crash if you set an env var)). so you didn't understand that at all.
To end this, let me give some some advice:
- be cool
- don't attack other personally
when you are attacked - eg being accused of spending time watching port and using terms from that in api names, then yes - i'll respond in kind. you started this.i'm simply dropping to the kind of language you seem to understand and like because you used it against me.
- design your software with users in mind
- don't hack at problems - analyze and solve them
- if making better software requires more work, deal with it and do more work!
perhaps you should read documentation, actually fact-check and maybe gain a better grasp of basic english before you decide to come to conclusions and broadcast them to the world without fact checking them (the 512 object limit for example). maybe you should have the minimal amount of professionalism to actually report bugs if you see them, as opposed to going on a rant laced with personal attacks. perhaps you should, if you have trouble, ask for help from the community and your company support systems - which i would assume you didn't because you had so much trouble.
i'm done with this. at least i learned something. i shall take note of how capable you are of using documentation or help resources in future. i have taken note of your racist generalizations of things like "asian people who know shit about programming". oddly enough these asians could build the open source tizen tv code with a small team over 2 or 3 months and get it up, and working using the documentation for efl. it is what has been publicly demoed. yet you (am i right you are polish?) are struggling with even the basics.
-
RE: Enlightened
to date we've had no real problems with the key strings - if people were to actually do things like report this as a bug, it might be nice, and as for the string compares for keys - they matter not at al speed-wise. if they did we'd not use them. show me a real life performance profile where they matter nd i'll happily reconsider.
-
RE: Enlightened
i guess you have zero sense of humor and are unable to recognize it as a result.
-
RE: Enlightened
that is indeed why we take the "march on as best as possible" approach. developers can enable "crash first" with an environment variable and find the issues.
-
RE: Enlightened
i think i did reply to this - you will get feedback. you'll get a stderr log noisily about the object being invalid (not in the table or the table entry is a NULL pointer to an obj). it's really 2 dimensional with tables and rows. you have any number of tables (tables are allocated on-demand and released when empty). a table has N rows and a row has generation count and pointer to actual object data. if you call a method (function) on the object and the object doesn't inherit from that class, then you'll get a loud complaint that the method (with a string spewed out as to the method) is not valid for that object. so no - there is not "don't give the programmer any feedback" - they definitely get it loudly.
and sorry - limit on 32bit is 22 bits (1 extra flag bit - i forgot about), on 64bit it's 34 bits for object id (so 16 billion or so).
-
RE: Enlightened
and i was very explicit - i took the string he gave "you bitch" - i pasted results of the grep. i looked for exactly what he said - i normally use the most explicit string as it cuts down false positives. i didn't lie - i said that that string does not appear anywhere in efl - if he had said "something like 'you bitch'" i'd maybe have been a bit more circumspect. and as i have said something on the order of a dozen times - yes "bitch" was there in an error printout and it should not have been. i fixed it.
-
RE: Enlightened
i never said "i never saw it" - quote:
"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:"
please don;t put words in my mouth.
-
RE: Enlightened
dude - i said it half a dozen times now - you read not a single one - it should not be there. i removed it. scroll back up and just look.
-
RE: Enlightened
yes - because mostly the errors are harmless. the majority of code marches on fine - thus prefer staying alive over suddenly falling over. the mode can be switched with an env var. you can set it in /etc/profile or ~/.profile or .bashrc or whatever tickles your fancy if you are a developer and are going to hunt down the issues.
-
RE: Enlightened
my response was based on it not being there (anymore) (when i looked). i have been pretty clear about it that it shouldn't be there and i fixed it. i searched the codebase - i didn't do an exhaustive search through all history and using different strings than quoted in the OP.
-
RE: Enlightened
nope - don't regret using C. and as for backtrace:
export EINA_ERROR_ABORT=1 gdb app
you will get a nice bt. sure - it isn't the default because default is to march on and recover with a complaint - the complaint is your signal to enable this next time you run and hunt down the detail. the reason there is no bt is that i've had mixed success with backtrace_symbols() before and mostly it getting ??()'s rather than a real bt where gdb manages the real bt fine.
-
RE: Enlightened
nope - i didn't feel like being calm. i felt like following the tone of the OP - it seemed the kind of way of talking that would maybe be understood by the OP as that is what they used.
-
RE: Enlightened
i never said it was good. i never said i didn't see it. and i never said that - OP did. and the text he claimed was there was not - and i fixed it. see previous reply. what makes you think i denied that this would be offensive? what makes you think i would fail to see the insult?
-
RE: Enlightened
grep -ri = search recursively though all files in this dir tree (the r), case insensitive. (the i). it was there was no "you " in front of the "bitch". and as i have said - it's fixed and yes there was, but it wasn't what was originally quoted as fact (not approximation). i totally admit that the code likely should say this and that has been fixed, but when i replied to the OP i was using what he wrote as he wrote it. yes - bitch was there. but you can't expect me to go find things if i'm told the wrong information? i can keep trying permutations etc. but i was busy going through other things as well at the same time.
-
RE: Enlightened
he did not say he pulled it from memory when he made the claim until corrected. quote:
"Another extremely helpful message: “You bitch!”. And I’m not joking about that one either – it was discovered by a female coworker while trying to hack layouts to work. Perfect timing on EFL side here."
-
RE: Enlightened
slight catch - i didnt disagree - i pointed to actual facts showing it wrong - eg not being able to know the callback signals a widget emits - documented clearly. many of those. it's not opinion there. it's fact. if it were opinion - i'd not bother.
-
RE: Enlightened
not on his team - but i know the comparison that was done and it had nothing to do with unity3d. his comment:
"All I can say about choosing EFL is it involved a comparison of application startup time (with differences measured in milliseconds) and a comparison of memory usage between EFL and Unity3D game engine. And no, don't ask."
that is entirely wrong.
as for ide's - i know of none that will magically auto-cast for you when you type - they may tab-complete the type int he cast.. but not magically do it for you. if this feature exists - it's news to me.
and yes - bitch did. it was "bitch" for complain - and yes - it should be removed. but "you bitch" did not and that is what the OP said and i actualyl looked for it.
as for the spank spank - i'd be just fine that being in public or in a meeting with management etc.
as for key names - no - we didn't document it, but it'll be the same set as you get in x11. we emulate it elsewhere. yes- maybe we should explicitly document that but to date no one has actually complained and said "i have no idea what these keys are - is it documented?". i don't remember a complaint in person nor a bug filed.
as for c land - if you want to do it in c - make a smart object. you casn use code to create/destroy/manipulate all the child elements of this object (and nest as you see fit with more types). that is how all the widgets and objects are created in efl - we use the same mechanism. so yes - possible in c.
it may be that his edje_cc was wrapped or changed - but the upstream edje_cc has always errored on an error with a nonzero error code. we compile edc files with edje_cc during build ourselves and our builds have failed when edje_cc spots an error for as long as edje_cc has existed. check the history of the code if you want to verify
as for the widget docs - if its a const char * of course you don't free - if it's a char * return (example) it'll be documented as to how to free it. if its' objects - objects stay alive until you delete them ... or the canvas they live in is deleted, or an object that has taken ownership is deleted (and objects that take ownership are in charge of deletion). it's the same throughout efl - its similar to gtk in that sense. it hasn't been explicitly documented i guess because it's a convention that is common enough.
oh and for the list boxes. i meant "it has nothing to do with ram" in that it isnt the "ram screaming in agony" - the allocation and de-allocation. that's not the problem. if it were malloc/free internals would appear in our profiles - they don't (way way way down the list).
as for introspecting the table - can you elaborate? we don't provide anything to walk the table - the table is shuffled off into a separate mmaped bit of memory outside the normal malloc pool and we even have code to mprotect the memory to be read only if you may have the unlikely event of table corruptions (eg if some code outside of eo itself is scribbling over the table memory by pure chance)
and yes - 512 has legitimacy - its' the generation count (9 bits - on 32bit,s it's much more on 64bit). he wouldn't run into the upper limit - he just wouldn't. in fact yes - i oopsied in my arithmetic - we have 23 bits for object count - so 8 million objects or so. not 2 million.
and as for trac - we shut it down long ago - we can;t edit it anymore and the links were set up before we had everything set up - why someone goes to trac, i don't know because the enlightenment.org homepage points to phab's wiki - we kept it alive in read-only mode just as a signpost .. years ago. so can't edit and fix it. and yes i'ts there five times because so often people miss a single link and ask questions. the trac pages are dead and i'm surprised people are ending up at them. how?
and as for the structure that is useless - you don't need to care - it will never be returned or used as such. it is the first member of all the engine info structs (thus common data) which is seeded by evas for evas's purposes and the developer should not modify it - they don't need to know what is there.
-
RE: Enlightened
i did not lie. i pasted my greps. "you bitch" as OP said didn't exist. i found the bitch thanks to a correction in the comments when i finally got there. i fixed it. not hiding anything.
-
RE: Enlightened
as i said enough - most of what was pointed out was utterly wrong. but presented as fact. if someone says you are selling drugs and encouraging people to become addicted - do you go "oh - that's my fault" or if it's wrong do you defend yourself? if you built a building and someone goes around saying it's about to collapse and no one should go in it even though that is utterly false and it's solid and stable, do you just say "oh my bad. i will find the problem that doesn't exists" or do you defend?
-
RE: Enlightened
i will calmly note problems sand talk to people if they behave that way. the OP did not.
-
RE: Enlightened
i literally pointed out many times where the OP just didn't read the docs - the docs were a few clicks in under an obvious section - eg widgets -> entry for the entry widget.... the elementary documentation has a "getting started" link on the first page - very first. in that is a sample app to get you started. it isn't hard to find by the OP managed to not find it.
the OP simply raved on about a litany of falsehoods - yes someone is wrong on the internet and it's time to correct them. i know.
most people find our "naught programmer" errors quite amusing and they remember them - that was the point. to make them memorable so people will look and pay attention. you personally may not like it, but the feedback from people vastly says it's good.
as for types - you didn't really pay attention to what i was saying if we used types we'd have to be casing all over the shop to make it work in c - we stick to simple object types and then do checking internally to make this work without casting-hell.
-
RE: Enlightened
nope - elm handles high level widget focus, evas handles detailed object focus as widgets are just collections of sub-objects inside them and evas deals with this layer. not ecore. nope.
-
RE: Enlightened
yes - thats the option to stop sanity checking to save a few miliseconds of startup time. it was named such to make it clear you are accepting to have no sanity checks (like are loaders installed to load basic image types like png, jpg etc.)
-
RE: Enlightened
no - the controllers are done for you - you CAN writer your own and yes - you'd have to do the event handling by hand. but entries are done. buttons, lists, scrollers and much more. use them to save work.
-
RE: Enlightened
yes - the structure is useless - it's not used as only engine specific info is returned... it's telling you to nicely to not bother reading that or caring.
-
RE: Enlightened
yes - indeed objects are ALL hidden by default - show if you want to see them. no - there isn't a show_all - he just missed a show on bg - though he could have avoided that and used the util func that does this for you.
-
RE: Enlightened
evas_engine_info() returns a structure specific to the engine bound/set for the canvas as different engines need different input to define target like window id etc. - no - it's not typesafe. this is what has to be done in C. this is not C++. reality is that almost no one needs to use this api as it's an internal and wrapped by ecore_evas and elementary.
-
RE: Enlightened
or you could rub two braincells together to make fire and understand the docs for it.. but no - that's too much for you.
-
RE: Enlightened
If you're interested in working with, or on, the EFL take a look at the [url=http://trac.enlightenment.org/e/wiki]wiki[/url] for more information.
Um … OK, let’s check that out …<img src="/uploads/default/16101/879f87ba9317a877.png" width="667" height="488">
yes ... it moved. links all there to point you there.
-
RE: Enlightened
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/ragemost 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.
-
RE: Enlightened
you are so full of bullshit it's not funny. it had nothing to do with that, but you'd say anything to make your rant look good.