Enlightened
-
Yeah, I already learned the lesson to not even put dirty words in class or method names.
One day, you're going to be programming in a language with stack unwinding, and it's going to barf a stacktrace at your customers.
at fuck_bitches:29
-
On the bright side: You just made the first step towards documenting the thing.
But jokes aside, it feels like where I work at...
Small projects like these require teams of 5-10 programmers working up to a year.
... yup.
@NeighborhoodButcher said:And did I mention EFL is the basis of all applications on Tizen?
Man, I might actually know your pain.
-
"They may build on top of "each-other" - but I very much doubt they'd succeed."
-
blakeyrat stumbled onto a page "explaining" the name below.
@blakeyrat said:https://phab.enlightenment.org/w/efl_concept_overview/
Evas is the canvas engine. It handles the entire "state" of a "window" (canvas) by filling that canvas with objects and manipulating their state.
So it's a graphics context? Handles what is being drawn on a canvas? Or a window?
-
EWebkit indeed.
-
So it's a graphics context?
Going by what I've read very swiftly, I think it's a combination of persistent graphics context and drawing surface; it remembers what you drew so that if it has to refresh part of the screen, it can do it without calling back into your code. If you're not animating that part of the application, it's much easier that way.
But it sounds like nothing in EFL is easy. All that effort and so little to show for it.
-
Could we be working at the same bluish hellhole, where the quality of a product is determined how much developers tried to make it work, not how much it actually works?
-
Someone, someday will do a "ps" on Tizen, and see a certain process will a command line option "--i-understand-what-im-doing-and-i-take-full-responsibility". No, that's not a joke.
-
where the quality of a product is determined how much developers tried to make it work
Show your PHB some Wikipedia articles.
Apply a clue bat for reinforcement, if necessary.
-
Unfortunately, my corporation implements feudal management style, and when they say "do things this exact way, because it will make Tizen an even bigger success", there's no working around it. If that results in gems like EFL being forced unto developers, who cares. You made your boss happy and that's what counts. The delusion is strong up there.
-
I'm almost 100% sure the answer is 'yes'. We can skip exchanging condolences I guess ^^
It's a funny coincidence that the WTFs made us both set up an account here within such a short time span.
-
Well you know, Tizen is coming out and people are suddenly starting to see how big piece of shit it really is. I especially like the news coming from TizenTV - imagine spending thousands of dollars on a TV, which can do nothing but display a "Coming Soon" message when you actually try to do something with it, because the core was written by Asian people who know shit about programming, but feel superior to everyone else anyway (if you're Asian, you're automatically higher than others in corp hierarchy and you're always right by definition; you can bypass any kind of code review, for example, even if you're an intern). Assuming it doesn't crash first, of course.
Fun times ahead for Tizen - native applications pretty much no doable thanks to EFL, web applications not doable thanks to buggy and laggy performance by EWebkit, security holes in every package, passwords being logged in plaintext, SMACK killing random processes because of some cryptic bug... Ah, it's going to be a great year.
-
If it's any consolation, after Moblin, Bada, Maemo, Mer, MeeGo and all the other utter failures, nobody really expected Tizen to be much better.
-
I think also nobody expected it to be so bad, but here it is.
-
Now I am 100% sure.
I don't interact with Tizen directly, but based on what you write, the fallout will reach me eventually. And code quality?
- App segfaults if locale is not set to some particular, undocumented value? Check.
- Inheritance by copy-paste? Check.
- Heaps of intermediate data in source control? Check.
- Four copies of a VCS branch, three of them with typos? Check.
- Code not compiling because of: int somevar; soemvar = 0; (variable is not used anywhere, of course)? Check.
I could go on like this, but it's Sunday and time to kick my brother's ass in Starcraft.
-
* App segfaults if locale is not set to some particular, undocumented value? Check.
- Inheritance by copy-paste? Check.
- Heaps of intermediate data in source control? Check.
- Four copies of a VCS branch, three of them with typos? Check.
- Code not compiling because of: int somevar; soemvar = 0; (variable is not used anywhere, of course)? Check.
Ahh, when visual novel authors go on to make general purpose software...
-
If it's any consolation, after Moblin, Bada, Maemo, Mer, MeeGo and all the other utter failures, nobody really expected Tizen to be much better.
My new Jolla phone is running Sailfish, and it works fine* even though it's a successor of MeeGo. They did reinvent the GUI to be based on Qt though, and they were obviously smart enough to partner with a third party for an Android support package so that they wouldn't have to reinvent every app.* It does have a few bugs, some more irritating than others, but the development is still active and they're not critical.
-
-
Bada
I've acutally tried to use a Bada phone for half a year, a few years ago. I'm still traumatized by that experience.
-
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.
A few fact :
- Evas is a scenegraph that predate Qt Scene Graph.
- Edje predate QML and has been its source of design and inspiration (Their first iteration of QML was named QEdje).
- 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.
- 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.
- 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 post
Now I am not a complete fool, I perfectly know where Qt is better than EFL without even the need to ask for justification :
- Documentation, tutorials and examples (Well, Samsung has never though investing in upstream documentation was useful, so it is mostly community based documentation and sure when you come from Qt and go to EFL you get quite a ride !)
- Community is way bigger for Qt than EFL
- Qt has a large set of widget designed for the desktop that do work quite well
- Qt work better on Windows and MacOS X than EFL
Oh and there is one thing that has been great so far with everyone that I know who actually work on Qt itself, they are great people that don't troll around. That how we learn from them and they learn from us. Your behavior here is more the one of a fan boy than of someone who actually does the hard work in those toolkit. If you were actually contributing in any of those toolkit, you would know already that they have weakness and strength that you should take into account.
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. Have fun.
-
EFL is after all an open source project, there is nothing that prevent you from proposing improvement.
@blakeyrat, want to handle this one?
-
Samsung
Samsung use EFL? That explains a lot about just how nasty their custom shovelware is!
-
I thought the whole company name the OP and @eskel were skirting around (blueish hell, Asian company, Tizen) was Samsung.
-
I thought the whole company name the OP and @eskel were skirting around (blueish hell, Asian company, Tizen) was Samsung.
Maybe, but I wasn't paying attention that closely.
-
- Evas is a scenegraph that predate Qt Scene Graph.
Two observations here:
- You didn't invent the concept, so it's not like you were really creative or revolutionary back when you wrote it, and
- Who gives a shit who was first? The important thing is who does it best! A.k.a. if I'm picking a GUI toolkit right now, why would I pick yours?
This is a huge disease among Linux-y people. "Well Linux had file permissions before Windows did!" Well, ok, but I'm not buying my computer in 1993, I'm buying it in 2015 and right now it sucks. Who gives a shit who was first?
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.
This is gibberish.
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.
What would be the point? The bad design is buried so deep now, there's no way you could dig your way out of it. Even if you wanted to refactor it, how could you? You don't even have documentation of how it works now!
I mean, the only suggestion here is: "write a time machine, go back in time, find the guy who wrote this piece of shit and club him in the skull with a 9-iron." I'm guessing you wouldn't find that proposal very useful.
Oh and there is one thing that has been great so far with everyone that I know who actually work on Qt itself, they are great people that don't troll around.
Oh shit, I get it. You're the guy who wrote that wiki! That explains the weird Jupiterian grammar constructs we're seeing here.
If you were actually contributing in any of those toolkit, you would know already that they have weakness and strength that you should take into account.
So what's the strength? It benchmarks slightly better at the cost of probably 3-4x development time? Whoopee.
-
So, skimming over it,
QObjectis a memory hog (comparatively). And given thatQImageand everything else that you would use in a graphical application inherits fromQObjectthey are, by extension memory hogs as well. Whoopdie-do.Yes, the benchmark makes sense from the pure numbers perspective. My question is, does
Evas_Objectcome even close to giving you the featuresQObjectdoes? Meta-object hooks? Dynamic properties? Memory management using an equivalent ofQObject::deleteLater();? I see callbacks are being mentioned, can you create custom ones as easily as you can when using Qt's signals and slots?I honestly don't know, but unless OP is a dirty liar, I kinda doubt it. It's a tradeoff. The article mentions that C is not a RAD solution. Well, with Qt at least, C++ damn near is. Also, why are you using
QImageif you're that concerned with memory? OrQSceneGraph? Oh, right, because those things actually, you know, work. And don't take 50 lines of code to initialize.
-
So, skimming over it,
QObjectis a memory hog (comparatively).
How much of a hog is it? Surely it can't hog too much, given it's the base of all Qt classes (I assume)…
-
Well, I never really benchmarked it that much, but out of experience, we're talking peanuts.
The only non-toy project I did write in Qt so far is a realtime monitoring service that monitors an Asterisk-based phone systems. This involves networking (data is collected through a telnet interface), shitloads of string manipulation on that data, database access, and dozens of custom classes.
Everything but the barest primitives (
ints,floats...) is inherited fromQObject:QStrings,QMaps,QHashes, my own classes... Each call spawns probably hundreds of these during it's lifetime. Now, I didn't manage to get it tested with hundreds of concurrent calls or anything crazy like that, but you know what the highest memory peak I got was? 4MB.Also, notice they are comparing a pure C application to a QtQuick application. Meaning there's a whole additional layer running on top of it that can interpret QML code and uses V8 engine to run JavaScript code. And the peak consumption on the graph?
4.9 MB? Holy crap, someone call the memory police!
-
Well, I never really benchmarked it that much, but out of experience, we're talking peanuts.
Especially since GUIs spend 99.999% of their time waiting for the user.
-
-
4.9 MB? Holy crap, someone call the memory police!
EMACS:
Eight
Megabytes
And
Constantly
Swapping
-
My question is, does Evas_Object come even close to giving you the features QObject does?
Yes, it does. It also provide ABI stability without additional effort. For a longer answer there is kind of a doc there : https://build.enlightenment.org/job/nightly_efl_gcc_x86_64/lastSuccessfulBuild/artifact/doc/html/Eo_Tutorial.html .
-
1) You didn't invent the concept, so it's not like you were really creative or revolutionary back when you wrote it, and
No, we didn't, but we were the first to apply it to a 2D toolkit. Also we are still the only one providing one that doesn't require a GPU. And when you do have a GPU, we are still performing better than the other.
2) Who gives a shit who was first? The important thing is who does it best! A.k.a. if I'm picking a GUI toolkit right now, why would I pick yours?
Being the first to implement it for a 2D toolkit did give us some time to put a lot of optimization in it.
This is a huge disease among Linux-y people. "Well Linux had file permissions before Windows did!" Well, ok, but I'm not buying my computer in 1993, I'm buying it in 2015 and right now it sucks. Who gives a shit who was first?
I don't get your point here at all.
What would be the point? The bad design is buried so deep now, there's no way you could dig your way out of it. Even if you wanted to refactor it, how could you? You don't even have documentation of how it works now!
I like how you put no argument in this sentence. If you at least started to give some valuable technical point, it would be more useful. Right now, you look like a pure troll here.
So what's the strength? It benchmarks slightly better at the cost of probably 3-4x development time?
You are balancing a hardware cost vs a development cost. On mass market, maybe that does have an impact ;-)
-
No, we didn't, but we were the first to apply it to a 2D toolkit.
Someone from Adobe's gonna come in here and kick your ass, buddy.
Also we are still the only one providing one that doesn't require a GPU.
That can not possibly be true.
Being the first to implement it for a 2D toolkit did give us some time to put a lot of optimization in it.
Right; but you're not optimizing for development time, which is the most goddamned important thing.
I like how you put no argument in this sentence. If you at least started to give some valuable technical point, it would be more useful. Right now, you look like a pure troll here.
If you want "valuable" technical points, you can pay me for them. Lemme know, I'll deal.
-
Let's say I believe you because reading this stuff makes me remember idiotic PHP hacks I had to do because the damned thing is... well, it's PHP.
When eo_do() reaches a function of a class, it is the responsibility of the user to extract from the va_list ALL the parameters needed for this function, NO MORE, NO LESS. Otherwise, unknown behavior can occur. eo_do() is called with a list of op id, params, op id, params... A bad extraction of parameters can bring to the parsing of a wrong op id and so in the best case, to an error, in the worst case, to another function not in relation with the actual use case.
Yeah... ummm... I'm gonna... I'm gonna go now. I think I have some Ibuprofen somewhere around the house...
-
I read that quoted bit, and
-
I don't get the surprise.
If you're limited to C varargs and want dynamic calls and junk, that kind of mess is exactly what you're going to get.
-
It's also the sort of mess you shouldn't have to be exposed to.
-
If you're limited to C varargs and want dynamic calls and junk...
...you're unlikely to have much of a good time with it.
(You're probably better off with a
void (*)(void*)though, then at least you can pack your parameters into a singlestructand pass its address into the callback so you can extract them in a semi-sane way. Callback function plus varargs is just asking for trouble.)
-
You are balancing a hardware cost vs a development cost. On mass market, maybe that does have an impact
Newsflash: In the last 30 years, the monetary balance has shifted. Hardware is cheaper than developers, that's why we're not all on mainframes right now.
-
Right now, you look like a pure troll here.
You've never been here before, have you?
Edit: Replied to the wrong post, dammit.
-
Is it really on a consumer device cost level though?
I'm not trying to play the devil's advocate, but I sort of understand what the point of EFL is, though I'm still trying to figure out if there's an actual, real use case. Tizen is supposed target EVERYTHING embedded, which might be TRWTF here.
-
- Documentation, tutorials and examples (Well, Samsung has never though investing in upstream documentation was useful, so it is mostly community based documentation and sure when you come from Qt and go to EFL you get quite a ride !)
One thing I have learned over the years:
If the documentation is shitty, the product usually isn't really worth your while.
-
One thing I have learned over the years:
If the documentation is shitty, the product usually isn't really worth your while.
Discourse REST API Documentation
Discourse API Please view the Discourse API Documentation site for detailed info: https://docs.discourse.org âš Deprecation Warning! On April 6th, 2020 we dropped support for all non-HTTP header based authentication (excluding some rss, mail-receiver, and ics routes). This means that API...
-
High-end workstation for a programmer: Let's call it $2000 every few years.
What's a typical salary?
-
If the documentation is shitty, the product usually isn't really worth your while.
Challenge: Name a single product/API/other with good documentation
-
The linux kernel and glibc, I'd say.
systemd for the ideas and interfaces, not so much for the code.
The Arch Wiki as well.
-
-
I found the C# documentation to be quite nice.
-
http://developer.android.com is pretty good.
Sunk cost - Wikipedia
