Enlightened
-
Windows calls it "List"
Ah, ok. Well, they've removed that, but I never liked that view anyway, so I don't care.
If you ask me, that "OMFG!!!! THEY'RE KILLING NAUTILUS!!!" flamewar was a huge fuss about nothing.
-
If you ask me, that "OMFG!!!! THEY'RE KILLING NAUTILUS!!!" flamewar was a huge fuss about nothing.
Wouldn't know. Wasn't there. I just know that I tried it at one point, shit didn't work, tried Cinnamon, Nemo did the job, I was happy.
-
Have you tried https://wiki.ubuntu.com/Elbuntu
NUKE IT FROM ORBIT!!!!!11111111elevenhundredeleven
-
I thought the main E-buntu was Bodhi Linux:
-
Maybe I should try LxQt again. It is relevant to my
fanboyisminterests.
-
WHO THE HELL IS COMING UP WITH THEIR DEFINITION OF EMBEDDED?!?!?!
Tizen (/ˈtaɪzɛn/) is an operating system based on the Linux kernel and the GNU C Library implementing the Linux API. It targets a very wide range of devices including smartphones, tablets, in-vehicle infotainment (IVI) devices, smart TVs, PCs, smart cameras, wearable computing (such as smartwatches), Blu-ray players, printers and smart home appliances[3] (such as refrigerators, lighting, washing machines, air conditioners, ovens/microwaves and a robotic vacuum cleaner[4]).
Thanks Samsung.
-
-
Also illustrated with a woman in a dress for some reason.
That must be Evas :)
-
Last time I used Ubuntu and dared to type a search into the Unity launcher thing it immediately started connecting to Amazon, Ubuntu store, some music store thing and hell knows whatever else.
Hmm. I have one vanilla Ubuntu laptop which I think started off on 10.4. I'm pretty sure I turned that all off in 12.04, and it didn't reenable itself in 14.04.
I also have an Ubuntu Server 14.04 box, but that one is using KDE as a desktop instead of Unity/GNOME.
In the interests of full disclosure it's only fair to warn you that I wore an onion in my belt because that was the fashion at the time...
-
Why not Debian?
I actually have a VPS running Debian. It's close enough to Ubuntu that I've yet to find any discernable differences...
-
Ok, time to get back on topic.
Disclaimer I am a developer of EFL and I write C daily. This troll is massively around a C vs C++ so I will try to stay out of that part as it is a completely useless discussion.
Actually it's not about C vs C++. I detest C, but for reasons other than EFL. In fact, you did not address any of my arguments against EFL, so why the pointless attack on C++? What does C++ have to do with it all anyway? You made a shitty product and you have to deal with the consequences.
BTW. I know from the famously bad "Core Object Model" presentation that you EFL guys would rather "die than use C++", but leave language flame out of itEvas is a scenegraph that predate Qt Scene Graph.
So? It still doesn't negate the fact it's shit.
- As for the choice of EFL vs Qt, which is what you are implying here. It has been put on the table a few time, but one time it was made in the open by someone like you (I mean someone who was forced to work with a toolkit he is not used to in a language he is also not used to). So he did a benchmark to prove his point with real number. Here was the result https://phab.enlightenment.org/phame/live/1//post/simple_efl_vs_qml_comparison_again/ . You are welcome to write another benchmark.
No, that is not a discussion of what should be used on Tizen. It's a description why EFL is crappy software which violates any design principle you can think off. It's also buggy, slow (yes, benchmarks were made and where Qt holds steady 60FPS, EFL struggles to remain even remotely fluid; if it wasn't for NDA, I could record a real-life video of how EFL works in practice), error-prone, poorly documented and extremely hard to work with. Who cares if EFL starts 10ms faster, when the development requires literal orders of magnitude more resources. Which year is it for Tizen browser to be in development? Third? There's a working, multi-platform browser in Qt as a fucking example project!
You seem to live in a typical reality-distortion field as you are one of the authors, and you don't see how the developers struggle with your software. Literally everyone hates it. People actually quit because of EFL. To prove my point - nobody was sane enough to actually use it in commercial software in 20 years before our employer came along. Now we have an OS with no chances of any developer engagement in terms of native apps. But no one will actually change it - after all, enormous resources were spent on EFL, so it has to be a success. Thank God there are rumors of Qt on future Tizen.- As for writing a video player, I am quite certain it is not the job of a 15 peoples for a year. You can check https://git.enlightenment.org/apps/rage.git/ for an example of how to do one. I do like the name quite a lot considering your pos
I see such projects every day, so your certainty is baseless. I can actually tell you that's the cost of using EFL - months and months spent on creating simple stuff like calendars or calculators (not giving away actual projects here, only examples, of course). I went on a 3 day training to learn how to make a damn list widget which doesn't crash all the time.
- Also you seems to over estimate the type checking capability of the C language. Maybe you should write a proposal on how to improve it if you have some idea. EFL is after all an open source project, there is nothing that prevent you from proposing improvement.
My proposal is simple - make it type safe, just like others do it. Saying that C has poor type checking is just an excuse. C has the exact type checking, you allow it to. If you transfer everything by void * and do a crapton of seemingly random casts, no type checking can save you from eventual undefined behavior (also, ever heard of strict aliasing?). Make every type of object you support an actual C type. Throw away the void * garbage and you'll have at least half of bug reports less. The idea of making a 3d hash map to lookup an actual object to work on is just an absurd hack to work around the problem. And that's the core issue of EFL (maybe C in general) - instead of designing software which can be easy to use right and hard to use wrong, and following good practices, you choose to work around problems with design by adding new layers of hacks. And all of Tizen is actually built that way, if you think about it (famous "do it our way" micromanagement).
Also remember - don't mistake users of your product with contributors. As a user I expect the software to work flawlessly and I don't expect the authors to basically say "create a patch yourself or fuck off" at bug reports.Your behavior here is more the one of a fan boy than of someone who actually does the hard work in those toolkit.
Not really. I'm not a Qt or any other technology fanboy. I'm just someone with enough experience to recognize a pile of software manure. I gave the example of Qt, because it illustrates how easy should it be to do such things. I have my problems with Qt too and I also express them openly. EFL is something unworkable with. People should be warned, that's all. I suffer so others don't have to, sort to speak.
Oh and hint, for you crash. Just run your application under valgrind, you will enjoy seeing the application (and not the toolkit), doing all those bad memory access
Wrong again. In fact, in modern C++ there actually is no way to have a bad memory access, because no one sane uses raw pointers anymore or does risky casts. All memory problems always come down to some C library. There is only so much "magic checks" can help you.
-
Holy crap, it's a whole defence brigade!
Might actually be a Corporate Defense Brigade.The authors of shitty software are always so protective of their work.
I write C daily.
Maybe you should stop doing that - it seems to make a lot of people upset.
-
@Cedric said:
I write C daily.
Maybe you should stop doing that - it seems to make a lot of people upset.
Exactly: there are 25 other letters to use!
-
Actually, there are a lot more then 25 more letters to use.
Even if you ignore the idea of lowercase letters (which in your worldview would add another 26 characters), there are still letters from different langauges left. Like ÄÖÜÉÈ, etc.Filed Under: And don't get me started on japanese or chinese characters
Edit: made the example letters uppercase for ease of use
-
Actually, there are a lot more then 25 more letters to use.Even if you ignore the idea of lowercase letters (which in your worldview would add another 26 characters), there are still letters from different langauges left. Like ÄÖÜÉÈ, etc.
"And here doth lie the joke, it's life tragically cut short by dickweedery of the pendantic variety; we commit its ashes to the earth. May it rest in piece."
@Kuro said:And don't get me started on japanese or chinese characters
Which aren't letters, but ideographs
-
Try អក្សរ ខ្មែរ, then. Not ideographs but still weird as shit.
Edit: is there a reason for discourse to convert zero-width whitespace to regular whitespace?
-
is there a reason for discourse to convert zero-width whitespace to regular whitespace?
Shits and giggles.
And unicorns farting rainbows.
Look, there are times when it just makes no sense at all. It's just easier if you don't think about it too much. And remember, it's not quite as badly broken as it used to be! Yay!
-
EFL guys would rather "die than use C++",
Because
this_.base->vtable_->virtualFunction(&this_.base, args);is just so much more expressive than
virtualFunction(args);Can you imagine, just having a multiple inheritance model just handed to you, and not being able to handcraft one which is optimized for just your application? It's madness...
EDIT: lol, and I even fucked up my imaginary C call, it should be:
&this_->base!
-
In fact, in modern C++ there actually is no way to have a bad memory access, because no one sane uses raw pointers anymore or does risky casts.
QFFT
-
Try អក្សរ ខ្មែរ, then.
Is that... Thai? Georgian?
Filed under: what do you mean, they have their own alphabet in Atlanta?
-
EDIT: lol, and I even fucked up my imaginary C call, it should be: <ins>
&</ins>this_->base!Well, if you're really going to nitpick,
this(remember, it's C so it's not a keyword!) will be a pointer to something anyway.((Base *) this)->vtable->virtualFunction((Base *) this, args);or maybe (depending on how you do the
structcomposition):this->base.vtable->virtualFunction((Base *) this, args);(Hmm, for the evil ideas thread: make a C API where key calls in it are called
thisandtemplate, and then criticise the people trying to link it to C++ when this inevitably blows up in their faces…)
-
Khmer. Thai is closely related (As are most writing systems used in SE Asia).
-
-
(Hmm, for the evil ideas thread: make a C API where key calls in it are called this and template, and then criticise the people trying to link it to C++ when this inevitably blows up in their faces…)
Tried that once for shits and giggles. Quickly found out that some key struct members and local variables are called
try.
-
Tried that once for shits and giggles. Quickly found out that some key struct members and local variables are called
try.I've had people rail at me bitterly for calling a field
class… :D
-
And this is why C# has a feature that allows you to use a reserved keyword as a variable/property name if you prepend
@;)Comes in fucking handy when working with ASP.NET MVC with Razor syntax
-
(On mobile, so not even going to attempt a quote....)
If we're both assuming that
this_is pointing to a struct whose first member isBase base;then I think what I posted is functionally the same as the two variations you posted, except mine is bending over backwards to avoid any casting whatsoever. (I'm somewhat militant about trying to avoid casts in any circumstance, as they tend to hide problems caused when the code changes later.) If there are functional differences, feel free to refresh my memory—it's been 8-9 years since I got paid to write any C...
-
And this is why C# has a feature that allows you to use a reserved keyword as a variable/property name if you prepend @
C has the same feature, except you append
_e.g.this_,class_,try_...
-
That is stupid you know?
this.do(@this);Ugh!
It's the same shit with JS self pattern:
this.callback(function(){ self.do(this); });Arg!!!
-
That is stupid you know?
this.do(@this); ```</blockquote> That is, yes. But like I said, it's super fucking handy when using Razor ;)
-
-
The main point of "@keyword" is interoperability between different .NET languages that have different keywords.
Interoperability aside, whether using @class is better or worse than theClass or clazz or cls is up to the gods to decide.
-
If there are functional differences, feel free to refresh my memory—it's been 8-9 years since I got paid to write any C...
A pointer to a structure is guaranteed to be the same bit pattern as a pointer to the first element of that structure. And yes, I should have written:
this->base.vtable->virtualFunction(&this->base, args);JSRF - Like This Like That – 02:50
— TechnoHeroine
-
To add another layer of hilarity, let me give you an example of focus handling. Focus is handled by not one, but two efl libraries - ecore and elm. Some times (because it seems to be non deterministic for even greater fun) those focuses fall out of sync. So when you're manipulating one set of widgets, you are also manipulating some other set in the background. It's entertaining to watch switching focus between buttons in a modal dialog box and in the same time seeing focus jumping in the covered application. When you press ok on a TV remote, for example, you actually click BOTH the button in the dialog and whatever else got focus in the app. You can imagine all the effects this can cause.
-
Focus is handled by not one, but two efl libraries - ecore and elm. Some times (because it seems to be non deterministic for even greater fun) those focuses fall out of sync.
WAT?
You can imagine all the effects this can cause.
Unfortunately, I can indeed.
-
Writing apps when you can't trust your window system is much fun.
-
Some people don't think of programming as a tool to create software, but rather as a way to have fun controlling the computer, or a sacred mathematical concept that n00bs should not defile, so they are extremely opposed to high level programming languages. Where's the fun in just writing what you want if you can't tell the system exactly what pointers to follow and what memory to free and allocate?
-
(Hmm, for the evil ideas thread: make a C API where key calls in it are called this and template, and then criticise the people trying to link it to C++ when this inevitably blows up in their faces…)
Crap - are you the one designing our Thrift interfaces?
(almost every time they add stuff, they use a reserved word)
-
Where's the fun in just writing what you want if you can't tell the system exactly what pointers to follow and what memory to free and allocate?
Let me guess, we're speaking of Real Programmers...
[...]
Mel's job was to re-write
the blackjack program for the RPC-4000.
(Port? What does that mean?)
The new computer had a one-plus-one
addressing scheme,
in which each machine instruction,
in addition to the operation code
and the address of the needed operand,
had a second address that indicated where, on the revolving drum,
the next instruction was located.
In modern parlance,
every single instruction was followed by a GO TO!
Put that in Pascal's pipe and smoke it.
Mel loved the RPC-4000
because he could optimize his code:
that is, locate instructions on the drum
so that just as one finished its job,
the next would be just arriving at the "read head"
and available for immediate execution.
There was a program to do that job,
an "optimizing assembler",
but Mel refused to use it.
"You never know where it's going to put things",
he explained, "so you'd have to use separate constants".
It was a long time before I understood that remark.
[...]
I compared Mel's hand-optimized programs
with the same code massaged by the optimizing assembler program,
and Mel's always ran faster.
That was because the "top-down" method of program design
hadn't been invented yet,
and Mel wouldn't have used it anyway.
He wrote the innermost parts of his program loops first,
so they would get first choice
of the optimum address locations on the drum.
The optimizing assembler wasn't smart enough to do it that way.
[...]
I have often felt that programming is an art form,
whose real value can only be appreciated
by another versed in the same arcane art;
there are lovely gems and brilliant coups
hidden from human view and admiration, sometimes forever,
by the very nature of the process.
You can learn a lot about an individual
just by reading through his code,
even in hexadecimal.
Mel was, I think, an unsung genius.
[..]
—excepted from The Story of Mel, a Real Programmer
-
Let that sink in.
What does it want now?
What? I see that as it's main selling point.
Yep, Xubuntu user here... I got a taskbar, a notification bar, and I'm pretty much happy. I know it isn't going to change anytime soon. If something better comes along, sure, I'll try it out. Maybe switch the next time I reinstall. Better touchscreen support would be nice. (And NO, "3 finger tap to move the window, 4 finger tap to open the Dash" is WORSE than nothing, Unity.)
Might actually be a Corporate Defense Brigade.
I hear that's called "astroturfing".Interoperability aside, whether using @class is better or worse than theClass or clazz or cls is up to the gods to decide.
Class clazz = Class.class; Method methods[] = clazz.getMethods();Fun with Java Reflection: Let's play spot the identifiers
-
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.
-
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_Objectoh 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: 255oh 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 205oh 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.
-
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.
-
Oh, the leader himself appeared.
You should feel honoured, @NeighborhoodButcher.
-
or you could rub two braincells together to make fire and understand the docs for it.. but no - that's too much for you.
-
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.
-
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.
A lot of the complaint here is that the documentation is poorly-written gibberish, where it exists. Much like the above-quoted text.
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's not about creating good software! It's about making things difficult so developers can measure the size of their dicks based on how far they got!
Open source in a nutshell.
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.
I think someone's getting a little personally involved and angry!
Open source is also about getting angry over a piece of code, because it doesn't matter that there's technical and usability problems to be solved, it only matters that someone is insulting your precious baby! THE CODE IS MY BABY!
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.
Oh, well that's ok then! It's perfectly acceptable to have bad documentation if it was a smart arse writing it! Definitely no problems here to be fixed.
and that just leads to work work and work. we do all out type checking dynamically at runtime - just like javascript, python, lua etc.
JavaScript, Python and Lua are all interpreted or JIT-compiled. C isn't. If you're working in C, you should be catching type errors at compile-time. Otherwise, you're just pissing all over the "C way of doing things". So yeah, I see why any C or C++ programmer would have issues with that.
as for the "you bitch" comment. that does not appear anywhere inside efl at asll.
Oh, well that's good.
yes - our code does say "naughty programmer spank spank"
Oh that's... STILL FUCKING TERRIBLE! How the hell is that acceptable!?
Ok the rest of that rant is far too long.
-
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.
-
or you could rub two braincells together to make fire and understand the docs for it.. but no - that's too much for you.
Remember! Open source is about proving how smart you are to other people!
Creating quality software? That's like priority number 5,436.
Dude: it's a fucking piece of code. It's an inanimate object, it doesn't have emotions, and you shouldn't have emotions about it, ok? It does not love you. It is not your baby.
Demonstrably it has problems, otherwise it would not be featured on TheDailyWTF forums. You can approach this situation in two ways:
- You can calmly note these problems and put them in your code's backlog to be addressed in the future
- You can write a super-long rant about how stupid everybody is
You picked a bad approach here. You don't look like a person who's interested in advancing the state of the art in software development, you look like an pissed-off jerk.
-
*goes to get popcorn*
This should be good…
@accalia, I sense a flamewar brewing here…
Bodhi Linux - Wikipedia
