Announcement

Collapse
No announcement yet.

Enlightenment Is Enlightening Wayland

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Answers

    You are very welcome If you have any other questions or concerns, please feel free to contact us:
    http://www.enlightenment.org/p.php?p=contact&l=en

    Comment


    • #17
      Originally posted by 89c51 View Post
      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.

      Comment


      • #18
        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.

        Comment


        • #19
          Originally posted by devilhorns View Post
          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


          • #20
            Originally posted by Nobu View Post
            I don't find that Qt is all that heavy, but some applications/libraries which rely on it (most infamously, in KDE*) are.
            Maybe try compiling gtk, qt, and efl and take the time on each

            Comment


            • #21
              Nobody said we were talking about source code; yes, Qt's source is definitely bigger than the efl's.
              Anyway, let me finish cloning the Qt repository and then I'll get back to you.

              Comment


              • #22
                Originally posted by curaga View Post
                Maybe try compiling gtk, qt, and efl and take the time on each
                Does this statement really have to end with "take the time?"

                Comment


                • #23
                  What would you like it to end with?

                  Comment


                  • #24
                    Originally posted by curaga View Post
                    What would you like it to end with?
                    "and combine them all into one condense perfect super library ,that's the size of SDL, while retaining all the functionality of the aforementioned libraries."

                    I think that would make me much happier than compiling all these libraries one by one.

                    Comment


                    • #25
                      For humor:

                      Qt:
                      Code:
                      # time gmake -j3
                      8671.82s	user
                      1013.20s	system
                      172%		cpu
                      1:33:30.64	total
                      efl: (well...I guess)
                      Code:
                      eina:
                      23.36s	user	3.56s	system		182%  cpu	14.766	total
                      
                      eet:
                      12.27s	user	1.64s	system		131%  cpu	10.617	total
                      
                      evas:
                      150.51s	user	19.20s	system		160%  cpu	1:45.84	total
                      
                      ecore:
                      73.85s	user	14.22s	system		157%  cpu	56.056	total
                      
                      embryo:
                      11.40s	user	1.24s	system		174%  cpu	7.232	total
                      
                      edje:
                      66.15s	user	8.14s	system		 95%  cpu	1:17.65	total
                      
                      efreet:
                      17.92s	user	3.67s	system		167%  cpu	12.888	total
                      
                      e_dbus:
                      28.50s	user	7.21s	system		115%  cpu	30.993	total
                      
                      eeze:
                      2.90s	user	0.94s	system		111%  cpu	3.453	total
                      
                      grand total:
                      386.8s	user	59.8s	system		143%  cpu	5:19.5	total
                      So, Qt takes roughly 17.5x longer to compile than "efl"***.

                      ***Qt 4.8 from git built with these configure flags:
                      "-fast -opensource -system-sqlite -no-qt3support -svg -graphicssystem opengl -nomake tools -nomake demos -nomake docs -nomake examples"
                      I suppose I could have cut a bit more stuff out, but didn't feel like taking the time.

                      Comment


                      • #26
                        EFL with default options and qt skipping several parts? That's cheating

                        Comment


                        • #27
                          Well, at least I stated clearly that I did that.

                          And, to be fair, I didn't compile any of the efl examples, demos, or tools either (since those are separate from the libraries, afaict). I also didn't compile some of the "Extra" libraries (even though they could be considered part of efl) because I didn't know about them.

                          Comment


                          • #28
                            Originally posted by Drago View Post
                            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.
                            If you go to FOSDEM, raster will talk about the EFL and Tizen. Otherwise, you can read this interview:

                            http://fosdem.org/2012/interview/carsten-haitzler

                            Comment


                            • #29
                              Originally posted by devilhorns View Post
                              Actually, development on the Wayland port did not "officially" start until December. The stuff posted in November was just me getting familiar with the Wayland code. I am glad that people are finding interest in this tho

                              Yes, the EFL libraries like evas, ecore, ecore_evas, and elementary all render in Wayland now using Shared Memory or EGL. With regard to the speed at which this was accomplished ... I will just say, it's been a long road The Enlightenment libraries themselves are known for running on various devices pretty easily due to their modular design. That being said, the Wayland port was no easy task tho mainly due to figuring out how Wayland works manually (sadly, documentation is a bit lacking) but the folks at Wayland have been incredibly helpful in this regard...they always took the time to answer my silly questions and have been very helpful in making this all happen. I look forward to working with them some more !!

                              With regard to why we are creating our own compositor...in my opinion, the wayland demo compositor (weston) is nice, but it's just that ... a demo, and thus does not provide all the features that we need or want to port the actually E17 window manager to Wayland.

                              Ohhh, and hi vtorri

                              I think I have it compiling... How do I tell elementary_test to use Wayland though? It's using X, even though I compiled the Wayland options for ecore and evas.

                              Comment


                              • #30
                                Originally posted by nerdopolis View Post
                                I think I have it compiling... How do I tell elementary_test to use Wayland though? It's using X, even though I compiled the Wayland options for ecore and evas.
                                export ELM_ENGINE="wayland_shm"

                                or

                                export ELM_ENGINE="wayland_egl"

                                Comment

                                Working...
                                X