If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Since I am begginig project with Qt, any one can explain why Enlightenment was chosen for Tizen, instead of Qt?
Does Qt has a problem with embedded devices? Thank you.
Since I am begginig project with Qt, any one can explain why Enlightenment was chosen for Tizen, instead of Qt?
Does Qt has a problem with embedded devices? Thank you.
i will make a wild guestimate and say that the reason behind favoring EFL on Tizen is that Samsung is one of the main backers. They have invested in E and pay devs.
Has there been any discussion between the desktop environment (KDE, E17, Gnome etc) and wayland people in order to create an official compositor?? I don't know if writing compositors is an easy task but the potential fragmentation might cause trouble. Not in interoperability since all will speak the wayland protocol but in terms of resources etc.
Has there been any discussion between the desktop environment (KDE, E17, Gnome etc) and wayland people in order to create an official compositor?? I don't know if writing compositors is an easy task but the potential fragmentation might cause trouble. Not in interoperability since all will speak the wayland protocol but in terms of resources etc.
There were always lots of compositors for X11, like KWin, Compiz, Metacity, Mutter etc, and this will continue with Wayland. There is nothing wrong with it.
There were always lots of compositors for X11, like KWin, Compiz, Metacity, Mutter etc, and this will continue with Wayland. There is nothing wrong with it.
i will make a wild guestimate and say that the reason behind favoring EFL on Tizen is that Samsung is one of the main backers. They have invested in E and pay devs.
Enlightenment was chosen due to it's speed, low resource requirements, and ability to run on just about anything I am sure Samsung did their research on all the toolkits before choosing one.
Not to put anyone's choices down or to knock other peoples work (no flame wars please), but I have always found QT to be heavy and a bit slugish...but again, that is just my personal opinion.
I've never really thought about it before, but eventually qt wayland clients should be able to speak to the gtk (etc.) compositor (assuming api compatibility...), and vice versa, right? So if qt clients appear when a gtk compositor already exists, could they use gtk's compositor instead of their own, is it required (i.e., are two compositors not able to run side-by-side)?
Being able to use a pre-existing compositor would keep resource duplication and redundancy down. And although it wouldn't make qt and gtk apps' decorations the same, a wayland extension could possibly be made which would allow decoration resources to be shared between toolkits.
Enlightenment was chosen due to it's speed, low resource requirements, and ability to run on just about anything I am sure Samsung did their research on all the toolkits before choosing one.
Not to put anyone's choices down or to knock other peoples work (no flame wars please), but I have always found QT to be heavy and a bit slugish...but again, that is just my personal opinion.
...and because they had pre-existing code and experience with Enlightenment (I read almost all of the thread on the ml, and this point was made several times).
I don't find that Qt is all that heavy, but some applications/libraries which rely on it (most infamously, in KDE*) are.
*no offense intended, I'm sure they're working on that
Comment