Enlightened
-
So they're either independent or interdependent, but the documentation writers are not quite sure which?
I dare say the developers don't know either.
-
@blakeyrat said:
complement an OS's existing environment, rather than wrap and abstract it, trying to be their own environment and OS in its entirety
The third clause does not seem to go with either the first or second clauses.
Inner Platform Effect, anyone?
-
The third clause does not seem to go with either the first or second clauses.
The whole thing is written that way. It's a masterpiece of "almost coherent gibberish". Also illustrated with a woman in a dress for some reason.
https://phab.enlightenment.org/w/efl_concept_overview/
The example code is very illustrative: https://phab.enlightenment.org/w/example_code/ (The wiki will let you think you can create a page without logging in, but you can't.)
Oh and look you can use it to build a REST API: https://phab.enlightenment.org/w/example_code/ecore_con_url/
The more "perfect and curious" might be interested in seeing the headers, which are here: http://docs.enlightenment.org/auto/emotion/ecore_con_url_headers_example_8c-example.html#a13
I guess I'm not "perfect and curious" enough to understand code in the auto/emotion section.
-
I guess I'm not "perfect and curious" enough to understand code in the auto/emotion section.
Me, neither, but when I was here:
Oh and look you can use it to build a REST API: https://phab.enlightenment.org/w/example_code/ecore_con_url/
He was totally spot on with this bit:
WHAT YOU WILL FAIL TO NOTICE
There will be no CURL(), socket(), select(), pipe().
No threads, unless you need to do lengthy parsing or processing (use ECore_Threads) in this case.
Everything you need to handle the REST API is in the handle.
The ECore_Con_Url code remains same, no matter how big your app becomes.
The above code is the complete REST module for your application.
-
The example code is very illustrative: https://phab.enlightenment.org/w/example_code/ (The wiki will let you think you can create a page without logging in, but you can't.)
I like the three different kinds of errors you get while clicking on links there.
-
This is why they call it Enlightenment:
The cookie files set by ecore_con_url_cookies_file_add() aren't loaded immediately, just when the request is started. Thus, if you ask to clear the cookies, but has a file already set by that function, the cookies will then be loaded and you will have old cookies set. In order to don't have any old cookie set, you need to don't call ecore_con_url_cookies_file_add() ever on the url_con handler, and call this function to clear any cookie set by a previous request on this handler.
I AM ENLIGHTENED!
-
http://docs.enlightenment.org/auto/emotion/struct__Ecore__WinCE__Event__Window__Damage.html
Detailed Description
Event sent when the window is damaged.
Dafuq?!
-
-
Dafuq?!
I believe the Windows term is "invalidate." Which is to say, it tells you what part of the window is going to need to be repainted because something got in front of it.
-
You might also like http://docs.enlightenment.org/auto/emotion/group__Eina__Magic__Group.html#ga4085afe8dc73c98ae626cc952c69c668
Declaration of a variable of type Eina_Magic.
To put in a structure when one wants to use the magic feature of Eina with the functions of that structure
-
I was quite satisfied with what Enlightenment DR16 could do back when loading KDE took several minutes at best. It's spartan, but at least it was themeable and properly remembered window style settings.
I wonder though, was that already using what would become the EFL or did the madness start when beginning E17?
-
> Declaration of a variable of type Eina_Magic.
To put in a structure when one wants to use the magic feature of Eina with the functions of that structure
Other than slightly ESL-ish grammar, that doesn't seem too bad, assuming "the magic feature of Eina" is described somewhere that can be found with reasonable effort. However, I suspect that assumption is not valid.
-
You can search for it, but reading the docs is not worth the hassle. It's basically a memory hack used to randomly provide "MAGIC FAILED!" logs which can be translated as "something did something - deal with it".
-
They should've just used PHP then. You get that for free.
-
I dare not imagine a combination of EFL and PHP.
-
I dare not imagine a combination of EFL and PHP.
Probably safe. I bet it gets rewritten in Node.js though.
-
-
God fucking damn it!
I have to keep running my mouth, don't I?
-
hmm... i don't like that version. the one from the Device was a better version.
-
Hmm. Sample code. (For your sanity and my own, I've excerpted as much of it as I possibly could...)
static Evas *create_canvas(int width, int height) { Evas *canvas; Evas_Engine_Info_Buffer *einfo; //... canvas = evas_new(); //... einfo = (Evas_Engine_Info_Buffer *)evas_engine_info_get(canvas);
Apparently
evas_engine_info_get()
doesn't return aEvas_Engine_Buffer_Info
. OK... (I wonder what it does return...)//... einfo->info.depth_type = EVAS_ENGINE_BUFFER_DEPTH_ARGB32; einfo->info.dest_buffer = pixels; einfo->info.dest_buffer_row_bytes = width * sizeof(int); einfo->info.use_color_key = 0; einfo->info.alpha_threshold = 0; einfo->info.func.new_update_region = NULL; einfo->info.func.free_update_region = NULL;
But
Evas_Engine_Buffer_Info
has a single member calledinfo
(I wonder what type that could possibly be...)evas_engine_info_set(canvas, (Evas_Engine_Info *)einfo); return canvas; }
...and we can cast a
Evas_Engine_Buffer_Info*
into aEvas_Engine_Info*
. Hmmm. So that's what, three casts between two different types where a sane API could probably get by with just a single type.And that is literally the first piece of code I saw on their site. I don't even want to know if it gets worse than that...
Gah. I'm gonna go wash my hands... a lot...
-
Ooh, they have a data structures page. Maybe there are some algor
iythms on there too!I'll click the first one on the list.
And no, there are no links in that screenshot.
-
I read every word. It was worth the time. +100.
So did I. And now I need cheering up.
https://www.youtube.com/watch?v=10t-FGfPsqo
-
I'd love to see a kernel that has no type safety whatsoever though. Hilarity would be sure to ensue.
-
Particularly the human/dwarf bit, of course.
Oh, I thought it was about the trolls around here
-
INB4
Trolls are large, predatory, dangerous subterranean creatures that often appear under the command of goblins during sieges, noted for their "terrifying features". They are building destroyers, and will path to your buildings simply for the joy of sheer destruction.
-
Aw god! I hope Tizen SmartTV apps are developed in a JS walled garden or I'm totally fucked.
-
Don't even make me start on those...
Let me give you a small hint: Tizen uses a variant of Webkit called EWebkit. Guess where this E comes from.
-
Disclaimer: I've been looking at E17/EFL development from afar for a while; never actually used it.
1. Create a widget of type box with the background as a parent (obviously!), which is not really a widget but a layout, but it’s also not a layout because a layout in EFL is something totally different and it’s not a widget. As usual – it’s a hack for positioning widgets next to each other.
2. Show the box.
3. Create an Evas_Object of type button with the box as its parent.
4. Show the button.
5. Create a next Evas_Object of type button with the box as its parent.
6. Show the button.
7. Marvel at your two buttons which took you 50-100 lines of code to create.Some things in your post remind me of GTK. Are you sure you're not missing a
show_all()
function call? This is how you'd do it in GTK:my $window = Gtk2::Window->new; my $vbox = GTK2::VBox->new(...); $window->add($vbox); my $button1 = Gtk2::Button->new("_Foo"); my $button2 = Gtk2::Button->new("_Bar"); $vbox->pack_start($button1, ...); $vbox->pack_start($button2, ...); $window->show_all();
Not quite sure how you can get fifty lines out of it.
One example of this memory mismanagement is a thing called a Genlist. It in essence is a list widget with some items. It has a special “feature” – it deletes items when they go out of view and allocates memory for them when they get into view. Make a quick swipe on such list on your mobile device and you can actually hear your RAM scream in agony.
For example, a layout is immutable. You make it, you stick with it. That immutability is pretty far reaching.
These things halfway make sense, if you consider that the whole thing is designed for low memory usage and performance. (Kind of like what you'd want an UI library on a cell phone to be.)
-
I did find out that
Evas
is an abbreviation of "Canvas", apparently...
-
@blakeyrat said:
EFL is a collection of libraries that are independent or may build on top of each-other
So they're either independent or interdependent, but the documentation writers are not quite sure which?It's a dependency hierarchy. Some parts of EFL have no dependencies. Others depend on each other. It's a fancy way of saying "Compile+install these first; the rest will fail to compile if their dependencies haven't been installed yet."
-
Some things in your post remind me of GTK. Are you sure you're not missing a show_all() function call?
No, EFL doesn't have such functionality. You have to manually show every child of every widget. At least hiding works as expected - hiding the parent hides all children.
Not quite sure how you can get fifty lines out of it.
It all comes down to the boilerplate code EFL forces you to use. To make a widget look and act like anyone would expect, you need to call a crapton of cryptic setter functions.These things halfway make sense, if you consider that the whole thing is designed for low memory usage and performance. (Kind of like what you'd want an UI library on a cell phone to be.)
Low memory - yes, performance - no. Doing this many allocations can bring the whole system to a halt. Yes - that has happened.If you wish I can write more EFL stories in the comments, so you'll see how well designed it is.
-
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys
/* * break system call. * -- bad planning: "break" is a dirty word in C. */ sbreak() { <..snip..> if(d > 0) goto bigger; <..snip..> bigger: <..snip..> }
-
@hhaamu said:
[something about
show_all()
; discobug: first nested quote doesn't get quoted]
No, EFL doesn't have such functionality. You have to manually show every child of every widget. At least hiding works as expected - hiding the parent hides all children.Can't you at least foreach over the objects?
-
I went grepping for the code. The 'spank spank spank' I don't particularly find amusing, but it's not really as bad as your selective quoting makes it look like.
"*** Eina Magic Check Failed !!!\n" " Input handle has already been freed!\n" "*** NAUGHTY PROGRAMMER!!!\n" "*** SPANK SPANK SPANK!!!\n" "*** Now go fix your code. Tut tut tut!\n"
It appears your 'bitch' string is used in the sense of 'complaint' or 'gripe'; many comments say 'Evas bitches'. Never does it say 'you bitch'.
if (obj->smart.parent) { if (obj->smart.parent != below->smart.parent) { ERR("BITCH! evas_object_stack_below(), %p not inside same smart as %p!", obj, below); return; } evas_object_smart_member_stack_below(obj, below); } else
...they use the GNU brace style. I just came up with a strong aversion for the library.
-
"*** Eina Magic Check Failed !!!\n"
" Input handle has already been freed!\n"
"*** NAUGHTY PROGRAMMER!!!\n"
"*** SPANK SPANK SPANK!!!\n"
"*** Now go fix your code. Tut tut tut!\n"
9ooooooooohNew error messages for @sockbot
-
Yes mistress Sultanatrix of Swypos; @RaceProUK's queen, I shall appear as summoned.
-
-
It appears your 'bitch' string is used in the sense of 'complaint' or 'gripe'; many comments say 'Evas bitches'. Never does it say 'you bitch'.
Maybe it said just "bitch!" instead of "you bitch!", I blame my memory. In all seriousness, I don't see how that makes any kind of difference as the intent is exactly the same, and I really can't image any sane programmer leaving such messages for people (especially coworkers) to discover. It's just a step away from a real harassment suit if someone gets pissed enough, and believe me, you don't want to go that road because someone was stupid.
-
-
well... only two out of tree really. the third time it uses my username rather than my long name.
-
-
tan out of tethera?
-
That works ;)
-
hmm... i don't like that version. the one from the Device was a better version.
True, but this one was both easier to find and easier too copy out. Nobody talking through it.
-
http://docs.enlightenment.org/auto/eet/struct__Evas__Engine__Info.html is sort of apologetic.
-
You know things are bad when the description of a data structure is:
Generic info is useless
-
method = evas_render_method_lookup("buffer");
if (method <= 0)
{
fputs("ERROR: evas was not compiled with 'buffer' engine!\n", stderr);
return NULL;
}Erm, what? Seems they have subscribed to the
TRUE, FALSE, FILE_NOT_FOUND
type of feature availability checking... just without enums.
-
http://docs.enlightenment.org/auto/eet/group__Evil.html
Ah look - the windows portability layer is called Evil.
-
Ah look - the windows portability layer is called Evil.
Yeah! Pfft! Those stupid Windows idiots probably coded their windowing system using TYPES! Morons.
-
There could be quite a few tomes written about the abhorrent malefaction that is EFL, but let me keep this post short. Or at least shorter than planned.
Almost everything you write about is approximately how GUI toolkits really work internally (except for the derp-tastic stuff with the layout compiler). Keyboard event handling really is very nasty at the low level (hint: ignore the key names if at all possible). But nobody in their right mind would expose it all to (programming) users of the toolkit! At the very least, sensible defaults make it possible for someone to get up and going with only a few lines of code.
Do you have to write all the controllers by hand too? Even the basic ones like how to make an entry field respond to keyboard input? If so, that's a massive WTF. (That sort of code is actually tricky to write, as there's a lot of little details that all interact asynchronously with each other.) Low-level controllers are usually toolkit-supplied (as part of the class definition for entry fields, etc.) for damn good reason!