http://what.thedailywtf.com is now being blocked on the corporate firewall at Samsung.
Thank you @Carsten_Haitzler!
http://what.thedailywtf.com is now being blocked on the corporate firewall at Samsung.
Thank you @Carsten_Haitzler!
Most of your reply is about how the problems with EFL exist because it's written in C. This, unfortunately, does not mean these problems do not exist. It is clear you wanted an OOP design for EFL. Do you regret choosing C over a language with built-in support for OOP?
You mention EFL checks types in run-time, like JavaScript and Python. Do you consider dynamic typing a better alternative to static typing? Guido certainly thinks so and he wrote an entire language for it. If you make a wrong call in Python you get a nice stack trace of what and where things went wrong. The "SPANK SPANK" error doesn't really compare. Similarly, the "BITCH!" (now "COMPLAIN!") error does not really tell you anything worth while until you see the conditions under which it is printed.
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?
From the [documentation][1]:
DO NOT use this function unless you are the person God comes to ask for advice when He has trouble managing the Universe.
Maybe you can integrate the EFL event loop into your own with [ecore_main_loop_select_func_set][2]? Maybe, but:
Warning: you don't know how to use, don't even try to use it.
[1]: http://docs.enlightenment.org/auto/eio/group__Ecore__Main__Loop__Group.html#ga7f5463c1d4f3f020968ed06d6e5816cb
[2]: http://docs.enlightenment.org/auto/eio/group__Ecore__Main__Loop__Group.html#ga91aecfe1c2ef6bd942e942750657e27c
You should read http://download.tizen.org/misc/media/conference2014/slides/tdc2014-core-object-model-eo-efl.pdf .
COMPLAIN! and SPANK! Don't really inspire confidence in the quality of your product.
Now I know why Enlightenment is such trash.
I installed it on Ubuntu 12.04 and it crashed when I tried opening the menu for the first time. Fortunately it had a "Press KEY to continue" kind of error popup and I could try opening the menu again without restarting the whole thing. That is a great feature considering how often this DE crashed. I got to see the menu on my 2nd (or was it 4th?) try.
All in all I spent about an hour using Enlightenment but I only managed to start the settings and terminal app in that time so I didn't really get to know it that well. I noticed lots of bugs like redraw/resize inconsistencies, context menus locing the mouse to the screen. I didn't trust the terminal to not crash long enough to complete any task so I didn't see any point in keeping this thing.
If anything I learned that not having any DE is preferrable.
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.
I searched around for docs and I found: http://docs.enlightenment.org/auto/efl/group__Evas__Keys.html but I also found https://developer.tizen.org/dev-guide/2.3.0/org.tizen.mobile.native.appprogramming/html/guide/ui/events_guide_ecore.htm for Tizen. How do these two relate? Does EFL on Tizen do key handling differently than the EFL you can get from enlightenment.org?
The 3 fields from your post seem to be in the Ecore_Event_Key struct, but I only found a function that gives you modifier keys on the evas page. The function that seems to give you modifier keys is actually right at the top of the page and an example usage is in the "details" (sorry, there is a link limit so I couldn't link directly) part of the page (and not near the actual function). The function does not do anything with "ev" (which I assume is the actual key event) so I'm not sure it does what the example strongly suggest it does. Is "ev" Ecore_Event_Key and I just can't find it on enlightenment.org?
Your code crashes because you're not catching the exception you're throwing.
@C++ Standard §15.3p15 said:
The currently handled exception is rethrown if control reaches the end of a handler of the function-try-block of a constructor or destructor.
But on further thought, there's still the problem of destructor handling constructor's exception.
Your code crashes because you're not catching the exception you're throwing.
@C++ Standard §15.3p15 said:
The currently handled exception is rethrown if control reaches the end of a handler of the function-try-block of a constructor or destructor.
From the [documentation][1]:
DO NOT use this function unless you are the person God comes to ask for advice when He has trouble managing the Universe.
Maybe you can integrate the EFL event loop into your own with [ecore_main_loop_select_func_set][2]? Maybe, but:
Warning: you don't know how to use, don't even try to use it.
[1]: http://docs.enlightenment.org/auto/eio/group__Ecore__Main__Loop__Group.html#ga7f5463c1d4f3f020968ed06d6e5816cb
[2]: http://docs.enlightenment.org/auto/eio/group__Ecore__Main__Loop__Group.html#ga91aecfe1c2ef6bd942e942750657e27c
http://what.thedailywtf.com is now being blocked on the corporate firewall at Samsung.
Thank you @Carsten_Haitzler!
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.
I searched around for docs and I found: http://docs.enlightenment.org/auto/efl/group__Evas__Keys.html but I also found https://developer.tizen.org/dev-guide/2.3.0/org.tizen.mobile.native.appprogramming/html/guide/ui/events_guide_ecore.htm for Tizen. How do these two relate? Does EFL on Tizen do key handling differently than the EFL you can get from enlightenment.org?
The 3 fields from your post seem to be in the Ecore_Event_Key struct, but I only found a function that gives you modifier keys on the evas page. The function that seems to give you modifier keys is actually right at the top of the page and an example usage is in the "details" (sorry, there is a link limit so I couldn't link directly) part of the page (and not near the actual function). The function does not do anything with "ev" (which I assume is the actual key event) so I'm not sure it does what the example strongly suggest it does. Is "ev" Ecore_Event_Key and I just can't find it on enlightenment.org?
You should read http://download.tizen.org/misc/media/conference2014/slides/tdc2014-core-object-model-eo-efl.pdf .
COMPLAIN! and SPANK! Don't really inspire confidence in the quality of your product.
Most of your reply is about how the problems with EFL exist because it's written in C. This, unfortunately, does not mean these problems do not exist. It is clear you wanted an OOP design for EFL. Do you regret choosing C over a language with built-in support for OOP?
You mention EFL checks types in run-time, like JavaScript and Python. Do you consider dynamic typing a better alternative to static typing? Guido certainly thinks so and he wrote an entire language for it. If you make a wrong call in Python you get a nice stack trace of what and where things went wrong. The "SPANK SPANK" error doesn't really compare. Similarly, the "BITCH!" (now "COMPLAIN!") error does not really tell you anything worth while until you see the conditions under which it is printed.
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?
Now I know why Enlightenment is such trash.
I installed it on Ubuntu 12.04 and it crashed when I tried opening the menu for the first time. Fortunately it had a "Press KEY to continue" kind of error popup and I could try opening the menu again without restarting the whole thing. That is a great feature considering how often this DE crashed. I got to see the menu on my 2nd (or was it 4th?) try.
All in all I spent about an hour using Enlightenment but I only managed to start the settings and terminal app in that time so I didn't really get to know it that well. I noticed lots of bugs like redraw/resize inconsistencies, context menus locing the mouse to the screen. I didn't trust the terminal to not crash long enough to complete any task so I didn't see any point in keeping this thing.
If anything I learned that not having any DE is preferrable.