Enlightened
-
not on his team - but i know the comparison that was done and it had nothing to do with unity3d.
Oooh! Can your omniscience also tell me who's going to win the 2018 World Cup? I need to know for ... reasons.
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.
They'll tell you you need a cast. Some you can just click "Fix it for me!", while others require you to type the parentheses yourself, but will happily fill in the type if the cast is valid.
as for the spank spank - i'd be just fine that being in public or in a meeting with management etc.
Let me get my popcorn. I love to watch people getting fired!
as for key names - no - we didn't document it, but it'll be the same set as you get in x11. ... to date no one has actually complained and said "i have no idea what these keys are - is it documented?".
Well, Windows has a different set, OSX has a different set, the K Desktop Environment has a different set for multimedia keys... Let me see if those are relevant.
Hmm, "X11 and others". Let's see these others.
Linux, FreeBSD, Sliding Glass Doors and Pear! Oh wait, Windows and Mac. It would be helpful to use the actual brand icons so I'd know immediately. Let's click one to dig deeper.
... Okay, it would have been nice to have all three categories on this one page, but I'll accept it for now. I'm gonna click Operating Systems.
Oh. Darn. I'll never know whether the existence of other sets of key names is relevant, because error page. Oh well.Also, you now have two complaints about the lack of documentation. You're welcome!
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)
In Windows, if you use the OS' support for windows and controls, you can get a list of all the window handles a process owns, and then use those to look up information about the actual windows. You can see their parents, children, classes (prototypes really), dimensions, style bits, everything. This is really useful when you have an ACCESS_VIOLATION (SIGSEGV for your OS) while manipulating controls as you can use that information to help figure out why you're trying to access a nonexistent window. Maybe you're trying to access a parent that's already destructed, or you ORed one or two bits into the handle for additional information and forgot to mask them out. But since you have every valid window ID and can examine all the relationships between all the live windows, it's easy to determine the root cause of those sorts of problems.
Can you do anything like that in Enlightenment?
My opinion is that it's better to know about errors sooner, rather than later. Therefore I prefer static typing so that my compiler can catch problems before I run the code. I also use an IDE that catches basic errors so I can fix them before I compile my code. Run-time checks are the last place where you can find an error (before a bug report). How does the situation look like with the new system of "pointers that are IDs"? How can you debug it? Does it print stack traces when an invalid operation is attempted? Is further execution prevented?
QFT
and as for backtrace:
export EINA_ERROR_ABORT=1
gdb appyou will get a nice bt.
And we're supposed to know this... how? Googling it -- and telling Google that no, we're not searching for NS_ERROR_ABORT -- shows nine hits. Two of which are under your control, both of which are patches out of context that use it once each. Also, does that also work under WinDBG? Under LLVM and XCode?
-
as for the spank spank - i'd be just fine that being in public or in a meeting with management etc.
Have you EVER had a day job in your life?
as for key names - no - we didn't document it, but it'll be the same set as you get in x11.
Haha what!?
I wonder if his writing is even a tiny bit representative of EFLs coding and/or documenation style...
It's definitely representative of their documentation style, based on the documentation I read.
he did not say he pulled it from memory when he made the claim until corrected. quote:
Look, be a pedantic dickweed all you want, it's not acceptable to ever have code output "bitch". In any context. Ever. Not acceptable.
but you can't expect me to go find things if i'm told the wrong information?
You don't know me very well.
Sweet, now the counter-counter ranters are signing up!
He totally stole that "I don't believe you." thing from me. Just wanna put that out there.
Most of your reply is about how the problems with EFL exist because it's written in C.
It sounds more like it's written in Wish-It-Weren't-C. Considering it seems to piss all over every protection the C compiler would give you by default.
-
WTF why is there no channel logo on that one! Consistency, man! WTF!
-
Needs more MOAN!, WRITHE!, WEEP!, WAIL!, REND GARMENTS!
RIP BODICE!
Oh wait I guess that's a different insinuation...
-
Oh. Darn. I'll never know whether the existence of other sets of key names is relevant, because error page. Oh well.
How come the wiki doesn't say BITCH! That's disappointing. I mean smirking table-flipping guy is nice a juvenile, but it's no "BITCH!" or "spank spank naughty programmer". I mean, come on here!
-
Have you EVER had a day job in your life?
Principal Engineer for Enlightenment at Samsung Electronics, apparently. Probably some sort of sinecure cause an exec felt sorry for him.
-
Man someone tip off the New York Times or Wired or some shit that Samsung is shipping code that yells "bitch!" at its users. On a slow news day, that might build some traction.
-
WTF why is there no channel logo on that one! Consistency, man! WTF!
That's because it's concept art
-
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.
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.Oh.... where do I begin. I guess in the spirit of the original - you really can't read documentation nor examples, can you?
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.
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?
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.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.
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.
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 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).
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.
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 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.
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.
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.
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 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.
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 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.
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.
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.
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.
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.
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.
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 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?
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.
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.
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.
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.
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.
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
To end this, let me give some some advice:
- be cool
- don't attack other personally
- 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!
-
as for the "you bitch" comment. that does not appear anywhere inside efl at asll.
http://git.enlightenment.org/core/efl.git/commit/?id=1733d29922f8f1e07d63ad6be3264bc9249b3301
evas - change error out from bitch to complain - cosmetic changeHEADmastercommitter Carsten Haitzler (Rasterman) raster@rasterman.com 2015-03-11 12:59:01 (GMT)Fuck off.
Just to throw some more fuel on the fire.Here is the first commit that included bitch! (albeit commented out):
https://git.enlightenment.org/legacy/evas.git/commit/src/lib/canvas/evas_stack.c?id=e928a2e8f6e975787eb3b884c852b0d4ef123e57
And then uncommented here:
https://git.enlightenment.org/legacy/evas.git/commit/src/lib/canvas/evas_stack.c?id=9c3620ce13b372a12100929e76c3bde6b39a8d8c
Discovering the identity of the committer of both is left as an exercise to the reader.Oh, this is awesome. Who needs credibility anyway?
-
Ah, so it's On Error Resume Next 2.0. Nice.
To be fair, I understand what the whole "warn but don't crash" deal is about, and is actually not that bad. He just sucks at explaining it because he keeps throwing EFL terminology around like we all understand it.
He mentioned signals so I'm buttuming it's similar to Qt, at least a bit. The way you handle events there is:
- An object, let's say a button, has a function that is considered a
signal, for exampleclicked. This function is called (signal is emitted) when you click the button. - Let's say you want to respond to that signal. You create a function that is declared as a
slot, for example you call itonButtonClicked. - You then call a
connectfunction that tells the framework "Hey, every timeobjectemitsclickedcallobject::onButtonClicked.
Part of this is checked at compile time: if signals and slots are not compatible or
objectis invalid it will spit out an error at compile time. But signal and slot don't have to be defined on a same object, not even in the same class. So if you remove the target object (the one with theslotfunction) and try emitting that signal again there will be nothing to call because the object is gone. But that doesn't necessarily mean your application has to crash, you just get a warning.Now, if only the warning could say something like
Error emitting signal Button::clicked: no available slotsor such, maybe, just maybe, you'd be able to Google that shit and read something like what I wrote in the docs. But no, it has toSPANKyou.
- An object, let's say a button, has a function that is considered a
-
To be fair, I understand what the whole "warn but don't crash" deal is about, and is actually not that bad.
OpenGL does the same thing (i.e., "on error resume next"), and until very recently it was rather stingy about its error messages too (
GL_INVALID_OPERATION- how I hate thee).
-
Once again, C ruining software projects. Sigh.
-
Some more WTFs found in his presentation.
A sample of their custom language to define classes.
Because C++ was Not Invented Here:
And because Complexity Is Good:
-
Missed some.
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
Every framework I know of keeps a list of key codes, which correspond to physical keys. If making such list is too much of a burden for you, copy-paste from this: http://doc.qt.io/qt-5/qt.html#Key-enum
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.
Same with key codes.
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?
For a framework which tends to pride itself for speed and memory usage, yes - this matters. Comparing a key code is comparing two numbers together. Doing string OS-dependent key comparisons is just insane.
-
Over or dead stinking corpsesI'll take either, really.
-
An object, let's say a button, has a function that is considered a signal, for example clicked. This function is called (signal is emitted) when you click the button.
Let's say you want to respond to that signal. You create a function that is declared as a slot, for example you call it onButtonClicked.
You then call a connect function that tells the framework "Hey, every time object emits clicked call object::onButtonClicked.So it's normal DOM or .net-style events but with weird alien terminology nobody understands? WTF.
[img]http://what.thedailywtf.com/uploads/default/_optimized/7d4/14a/449d0642f9_689x388.png[/img]
I'd like to take "dead stinking corpses", please.
(Seriously, these guys sound like assholes. I mean, I don't like C++ either, but I'd never put something like that in the official materials of a developer conference! Is there anybody involved with this project with maturity level above that of a 8-year-old?)
-
Very professional presentation. Remind me to stay away from anything Tizen-related.
Also, what is up with this
Eina_BoolandEINA_TRUE? I may be too dumb to understand why they're not using the bog-standardboolandTRUEwhich, as I understand it, are included since C99?
-
So it's normal DOM or .net-style events but with weird alien terminology nobody understands?
Pretty much. I wasn't sure about .NET so I didn't want to go and make that comparison on pure speculation though.
I have no idea who came up with the naming either. It makes perfect sense to me now, but I do admit I was a bit confused at first as well.
-
It makes perfect sense to me now,
Because you understand the "slots" and "signals" metaphor (assuming there even is one!), or because you just fucking memorized it?
-
I understand what happens. They can be called frooms and glooms for all I care, as long as they are documented and consistent.
Metaphors help, sure. But once you learn how something actually works the metaphor becomes less relevant. It took me as long to learn how to use signals and slots in Qt as it did to learn events and listeners in JavaScript. In both cases the concept can be explained in about two sentences, regardless of the names.
Also, if we want to poke holes at metaphors, I usually don't listen for events, I listen for the sounds. Maybe the sounds are news about an event, maybe not. It's just abstractions anyway, I'm fine with both as long as they work.
-
So it's normal DOM or .net-style events but with weird alien terminology nobody understands? WTF.
Nah, just terminology from like 20 years ago and not-Windows-land. Qt and a few other languages/frameworks have the same stuff. Though usually by constants, not string comparisons.
-
It's possible his employer has forced a version on him from before that work was done.
2015-03-11 12:59:01 (GMT)
@NeighborhoodButcher is using a version from yesterday, perhaps?
-
yes - because mostly the errors are harmless. the majority of code marches on fine - thus prefer staying alive over suddenly falling over.
Have you considered porting the EFL codebase from C into PHP?
-
So it's normal DOM or .net-style events but with weird alien terminology nobody understands? WTF.
Who the hell understands bullshit .NET terminology?
-
So the four identical lines on the page to all tell visitors about that move are intentional to make sure nobody accidentally misses the notice?
-
Oh, wow. Rasterman appeared. Do we have that Eterm author yet? Michael something IIRC?
This might be an interesting thread if the noise level wasn't so high. And half of the participants weren't dyed-in-the-wool C# programmers who hate open sauce and have never left Windows.
(Personally, I'm just impressed that rasterman & co spent ten years writing and rewriting the libraries for e17 before a real release. Anyone who can do that is dedicated.) (Yes, I'm afraid this is joke-bait. Bad thread for praising someone.)
-
And half of the participants weren't dyed-in-the-wool C# programmers who hate open sauce and have never left Windows.
Hey, relight that C++ fire, but no dice.
Maybe I should use more hyperbole and less facts?
-
To be fair, I understand what the whole "warn but don't crash" deal is about, and is actually not that bad.
Well, that depends. An X-Ray imaging control unit (fun fact: many of which are still running Windows XP and outdated antivirus solutions (a WTF in itself)) should keep running along, whatever it takes, no questions asked. Because then the doctor might finish welding your heart together.
A car ECU should provide at least some propulsion, so people don't get stranded on train crossings.
A shitty "smart" TV should crash as hard and fast and often as possible, so people have a chance to see exactly how big a piece of shit they just built, or sold, or bought.Shit like this helps people build and sell bad software. Stop it.
-
I was talking about it on a framework level. If the whole thing crashed on such an error with a segfault every time it would never be viable as a framework you could even use to write those pieces of software you don't want crashing.
Not that I'm saying you should write X-Ray imaging control software in EFL. But when designing such a framework you want to make it viable for such use. Whether you succeed or not is a whole different matter.
-
A shitty "smart" TV should crash as hard and fast and often as possible, so people have a chance to see exactly how big a piece of shit they just built, or sold, or bought.
-
I was talking about it on a framework level. If the whole thing crashed on such an error with a segfault every time it would never be viable as a framework you could even use to write those pieces of software you don't want crashing.
So people would stop using shitty frameworks. I fail to see the problem.
-
So you're advocating the methodology where I have to wrap every call to
button.click()in anifor atry .. catchand if I dare to miss a single check, and something goes wrong at any point, my application should crash and burn in eternal frames, rather than my framework spitting an error at me and continuing to chug along?Ok.
Filed under: INB4 "X does this internally and fixes it with magics which is better. Because magics!
-
-
I spin on my chair corrected.
grammmatical
You spellared your gramming though.
Filed under: Hi, I'm kettle!
-
You're damn right I did!
-
So you're advocating the methodology where I have to wrap every call to
button.click()in anifor atry .. catchand if I dare to miss a single check, and something goes wrong at any point, my application should crash and burn in eternal frames, rather than my framework spitting an error at me and continuing to chug along?
Umm... yes?
If your framework is so broken it can't even handle button clicks reliably, I certainly would expect at least your application to deal with that.
What is the user supposed to do, click again and hope it works this time?
-
You do realize I'm using the button as an oversimplified example here, right?
It could be a network reply object and something got fudged during the data transfer so it became unavailable. It could be a third-party component that's buggy and out of your control. It could be any number of edge cases that don't get caught in testing, whether automated or by testers.
Do you think Chrome sandboxes tabs for shits and giggles? No, they do it so that when Flash decides to crap itself and pull the rest of the Webkit with it your other tabs don't follow it to Valhalla. Or do you really miss the days when your whole browser shat itself after meeting a particularly "creative" piece of JavaScript?
-
whole browser shat itself after meeting a particularly "creative" piece of JavaScript
Like Discourse?
(Seriously, it did that earlier. Had too many WTDWTF tabs open and Chrome went in to "Not Responding" mode)
-
You do realize I'm using the button as an oversimplified example here, right?
Then it wasn't a particularly useful example to prove your point.It could be a network reply object and something got fudged during the data transfer so it became unavailable.
Okay, so you should send the network request again instead of ignoring this situation.It could be a third-party component that's buggy and out of your control.
All the more reason to wrap it in a try/catch, so you can reload it or whatever.It could be any number of edge cases that don't get caught in testing, whether automated or by testers.
I still prefer my applications to crash instead of pretending to work.Do you think Chrome sandboxes tabs for shits and giggles? No, they do it so that when Flash decides to crap itself and pull the rest of the Webkit with it your *other* tabs don't follow it to Valhalla.
That's not a framework chugging along, that's a desperate attempt to limit the damage you can't prevent from happening for whatever reason (probably because of shitty software).Or do you really miss the days when your whole browser shat itself after meeting a particularly "creative" piece of JavaScript?
I've never had that happen, and I had to work with IE6 extensively. (It did shit itself quite impressively if you used the nice Direct3D CSS effects too much or on the wrong hardware or something, though. But I disgress.) I'd still file that one under "shitty software", not so much "framework design". But yeah, I'm starting to see your point.
-
Makes everything more complex, and we love complexity :)Sweet, just what I'm looking for in a framework!
-
I'd still file that one under "shitty software", not so much "framework design".
The point is that this kind of "don't crash on the slightest sign of trouble" thing gives you time to react.
I can't remember what I did the one time I actually got that error. I do remember that the rest of the code that kept working actually managed to get the application back into working state but I had a dangling signal / slot connection left alive somewhere.
If that code actually got into production before I caught it, it would actually continue to work relatively uninterrupted. While it was a bug in my code (that I since fixed) it kept ticking along with the only real consequence being a log file to remind me of my failure. If it actually crashed... let's just say there would be some angry phone calls going around.
-
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.
-
i guess you have zero sense of humor and are unable to recognize it as a result.
-
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.
-
I guess that's it.
-
-
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.
-
What is the user supposed to do, click again and hope it works this time?
That's always worked for me in Windows.
-
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.
All it takes is one "Screw you" response. That would definitely qualify as a "Screw you" response. If this was a project nobody would feasibly be using in the real world, that kind of stuff in the wiki is probably OK. In a production product, that's ridiculous and should be above any code changes (with the probable exception of security bugs) in priority to fix. Or at least replace with "Documentation is in progress" or similar. At least make people think you care. Hey, maybe do what Wikipedia does and ask your more experienced users to add the docs themselves!
Combine the un-helpful pages in the documentation with error messages that are useless and unprofessional, and could be seen in a production setting (programmers are human, they'll make mistakes!), it just gives a lot of people a bad taste in their mouth. I am not in the market for a product for this particular need, but if I was, the information I've seen on here and your hostile response would definitely rule it out.
If you're looking to build a good development community, you need to treat your users nicely. Error messages that make them look bad don't help. Docs that make you look like you don't care don't help. It makes it look unprofessional. It makes it look like this is a product that you don't care about, which clearly isn't the case, from your responses here.
You need to own up to the fact that there are issues. We're all human, we all have bugs in our code.[citation needed] We all hate documentation.[citation needed] This website exists to point out those issues, then subsequently joke about them, and trying to argue that they don't exist is a waste of bandwidth and makes you look much worse. Perhaps you should try to work with the fustrated customer (That would be @NeighborhoodButcher) rather than argue with him in a place where he clearly has the "high ground". Who knows, maybe you'll actually get him to like your product.
Filed Under: Wall of text, woops
![http://what.thedailywtf.com/uploads/default/_optimized/7d4/14a/449d0642f9_689x388.png[/img]](http://what.thedailywtf.com/uploads/default/_optimized/7d4/14a/449d0642f9_689x388.png%5B/img%5D){kind=link}