GUI_Comparisons 

Sony wiki

Login

GUI Comparisons

Here is information about Qt and EFL and others.

Comparison points [edit section]

It's useful to define the points of comparison. The following attributes of the different UI systems should be evaluated:
  • language
  • features/functionality
  • performance
  • license
  • GPU driver support
  • cross-platform support
  • ease of development
    • UI design tools
    • IDEs
    • deployment ease
    • debugging tools
  • resource requirements
    • disk space for system
    • memory for running app
    • disk space for individual app

Other site's comparisons [edit section]

See UI Comparison Table

Thomas Petazzoni compared embedded Linux UI systems in 2008. See his presetation from ELC Europe 2008 here: http://elinux.org/images/6/64/Choosing-embedded-graphical-libraries.pdf

Info about EFL [edit section]

One developer complains about EFL pretty heavily here:

Info about Qt [edit section]

Comparisons [edit section]

Is this good or bad - I can't tell.

Here is a comparison between Qt/QML and EFL: http://tolszak-dev.blogspot.com/2013/02/simple-qml-vs-efl-comparison.html The developer wrote an application in Qt (QML) and EFL, and decided he liked Qt better.

The developer favored Qt in this test, but other developers said the test was not really fair. they thought it would be good to run the tests on a low-end machine like a raspberry pi, to see if the scripting overhead or respective optimizations of each system altered the results.

Some remarks excerpts from: https://www.phoronix.com/forums/forum/software/desktop-linux/35040-comparing-qt-s-qml-vs-enlightenment-s-efl

  • "...since this comes from a KDE dev, it has to count as biased."
  • what zanny says below:

While I'm big on qt, I don't really get the point here:
  • QML is designed for rapid development, and JS is a script language, of course a shim style language + script language will be easier to write than C.
  • Minesweeper is barely computationally intensive, and most of the logic of QML is in the QtQuick runtime that interprets it. Of course performance will be similar in something that has no math intensive logic.
  • GUI apps barely ever have any performance overhead (properly implemented) anyway, because they are just user event handlers.

I mean, it is reasonable to say "X wants to use EFL, here is a comparison of qml to efl in terms of performance and brevity of code" but it doesn't mean EFL is useless, if you like using it it is a perfectly reasonable platform to use. I personally prefer the benefits of qt + qml (cross platform, code brevity, ability to drop into C++ at a whim for performance) but to each their own.

But comparing a native toolkit to a script toolkit seems a bit silly. The only takeaway is that, gasp, the QML runtime is well implemented that the overhead of parsing the files into Qt widgets isn't high and thus the apps perform similarly in a task that isn't very processor intensive and easy to render.

TBWiki engine 1.8.0 by Tim Bird