I didn't say that, I only proposed a new project to add new features to eOS, the eOS developers say no... So end of the conversation, their project their rules ;)
Feel free to answer this email (I'd suggest you to read some documentation about the status of the implementation in both toolkits and the difference between implementing a client and a compositor) but I'm not going to answer you, this is a developer mailing list, not a Qt vs GTK+ mailing list, plus you are acting like if I was saying that GTK+ is evil and you were Spencer Kimball or Peter Mattis... At the end of the day all are eOS and GTK+ users, aren't we? Take it easy. El 06/06/2014 21:50, <dardeve...@cidadecool.com> escribió: > You should know better, X11, Mir, Wayland ALL are abstracted by the > toolkits. > So I am sorry my useless words caught up your Qt Agenda. So far > I have only seen you say > 'We should use Qt + Wayland not Gtk + Mir because I know it better' > even though it doesn't matter because they are abstracted. > > On 2014-06-06 21:35, José Expósito wrote: > >> As far as I know, Mutter does run on Wayland. So I'm not sure it >>> >> makes >> >>> sense to write a brand new compositor when we could continue to use >>> Gala. >>> >> >> Great, I didn't know that libmutter already implements the Wayland >> protocol, those are good news and, in this situation a new compositor >> doesn't make sense if the team is not thinking on convergence, I'd >> really love to see eOS on my tablet and I'd love to collaborate. >> As eOS user is good to know that the project is going to Wayland >> instead of Mir. >> >> @dardevelin >> >>> So I am sorry but mentioning 'Qt Wayland compositor' to make a case >>> >> for Qt usage >> >>> makes it stink. >>> >> >> Reading this link is highly recommended: >> http://qt-project.org/wiki/QtWayland [4] >> Qt Wayland is a separate Qt module composed by two different parts: >> the client API and the compositor API, so the only thing that stink >> here is your attitude. I'm a C++ & Qt developer, not a Vala & GTK >> developer, that is why I offer my help using this technologies, >> pointing, in my opinion, good reason of why a new QML compositor could >> be a good option to integrate new features in the project >> (movile/tablet/PC shells, possibility of deploy apps on iOS, Android, >> BlackBerry, Windows, OS X, Ubuntu Touch, etc, hardware acceleration >> out of the box...) and I come here with source code, not with useless >> words ;) >> >> However, It looks like eOS is going to use libmutter-wayland, so, >> unfortunately, I can not help with that simply because I'm not a Vala >> developer, not because I was trying to force the inclusion of Qt or >> something similar. >> >> 2014-06-06 20:56 GMT+01:00 <dardeve...@cidadecool.com>: >> >> Jose, wayland is just a protocol. Toolkits abstract the display >>> server and they >>> may or may not implement wayland. In fact wayland has a design that >>> decouples >>> multiple things that were all in on solution under X11 >>> including the compositor, where Weston is the reference compositor. >>> So I am sorry but mentioning 'Qt Wayland compositor' to make a case >>> for Qt usage >>> makes it stink. >>> >>> I AM NOT A CORE DEVELOPER of eOS, but am a interested party and >>> have been following this >>> project for quite a while, and now that the disclaimer is provided, >>> I would say >>> that this most likely applies to most projects you may want to >>> contribute, approach >>> projects showing your case and intentions clearly, >>> >>> example: >>> I want to develop an application >>> Z, I am intending to use Qt, I know the selected toolkit is Gtk+ >>> and vala, are there >>> any strong reasons for me not to use it Qt? >>> >>> example2: >>> I am familiar/interested in Wayland and Qt, I would like to do X to >>> help >>> the project on this technologies, how could I be more useful. >>> >>> the above approaches are just examples but at least they don't give >>> the idea >>> that you are just trying to come to a project and say 'do my terms >>> if you want >>> my help.' >>> >>> Cheers >>> The Elementary Project `Watch Dog - dardevelin` >>> >>> On 2014-06-06 19:21, Daniel Foré wrote: >>> >>> Hey José, >>> >>> As far as I know, Mutter does run on Wayland. So I'm not sure it >>> makes >>> sense to write a brand new compositor when we could continue to use >>> Gala. >>> >>> But yes, I think right now it makes the most sense for us to be >>> thinking Wayland instead of Mir. >>> >>> Cheers, >>> >>> Daniel Foré >>> elementaryos.org [1] >>> >>> On Fri, Jun 6, 2014 at 11:01 AM, José Expósito >>> <jose.exposit...@gmail.com> wrote: >>> >>> I was not talking about porting all the apps to Qt, actually this >>> is >>> not necessary you can run GTK+ apps over a Qt Wayland compositor >>> without any problems, I was talking about write *one* app using Qt. >>> >>> But if for some good reason you don't want to include Qt in the >>> default CD image (to save a couple of MB?) then that is OK >>> otherwise >>> let me know, I'd be more than happy to collaborate with the eOS >>> project :) >>> >>> 2014-06-06 18:50 GMT+01:00 Jacob Parker >>> <jacobparker1...@gmail.com>: >>> >>> José, >>> >>> There is no possibility of porting to Qt, as all the apps are done >>> with Vala (dependency on Gtk). Gtk+ also supports Wayland. >>> >>> Hope this helps! >>> >>> On Fri, Jun 06, 2014 at 6:41 pm, José Expósito >>> <jose.exposit...@gmail.com> wrote: >>> >>> Hi all, >>> >>> I was wondering what are the plans of the eOS team about Wayland. >>> Are you choosing Wayland or Mir? >>> >>> Personally speaking, I think that Wayland is the correct option >>> here >>> for a lots of reasons, so I made a proof of concept C++/QML >>> compositor that looks like [1]. >>> >>> I know that elementary OS relies on GTK+ but in my opinion, talking >>> about Wayland and interface design, Qt is a step ahead GTK+, >>> allowing you to make 100% customizable GUIs without many effort. >>> To quote some example, as you can see in the screenshot, the window >>> shadow is implemented in 7 QML lines: >>> >>> RectangularGlow { >>> >>> anchors.fill: parent >>> >>> glowRadius: shadowRadius >>> >>> spread: 0.2 >>> >>> color: Qt.rgba(0,0,0,0.5) >>> >>> cornerRadius: shadowRadius >>> >>> } >>> >>> And the fade in/out effect for opening/closing windows is >>> implemented in 3 lines: >>> >>> Behavior on opacity { >>> >>> NumberAnimation { easing.type: Easing.InCubic; duration: 400; } >>> >>> } >>> >>> Plus you can build 100% custom responsive UIs (phone, tablet and >>> desktop in the same app without many changes) with cool animations >>> as you can see in this other project [2] And yes... that means that >>> it is possible to adapt the compositor to run it in different kind >>> of devices like phones or tablets. >>> >>> And all of this is hardware accelerated :) So, after pointing why I >>> used Qt instead of GTK+ to build this proof of concept compositor, >>> I'd like to ask you... Are you guys interested on porting the eOS >>> shell to Wayland? Would you be interested in the use of Qt, or do >>> you prefer to maintain a GTK+ only system for some reason? If the >>> answer is yes, would you be interested on my collaboration? >>> >>> I'm waiting for your reply, >>> Thank you! >>> >>> [1] http://oi60.tinypic.com/ekrjaw.jpg [2] [1] >>> >>> [2] https://github.com/JoseExposito/ubuntuone-qt-files [3] [2] >>> >>> Links: >>> ------ >>> >>> [1] http://oi60.tinypic.com/ekrjaw.jpg [2] >>> [2] https://github.com/JoseExposito/ubuntuone-qt-files [3] >>> >> >> -- >> Mailing list: https://launchpad.net/~elementary-dev-community [5] >> Post to : elementary-dev-community@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~elementary-dev-community [5] >> More help : https://help.launchpad.net/ListHelp [6] >> >> >> >> Links: >> ------ >> [1] http://elementaryos.org >> [2] http://oi60.tinypic.com/ekrjaw.jpg >> [3] https://github.com/JoseExposito/ubuntuone-qt-files >> [4] http://qt-project.org/wiki/QtWayland >> [5] https://launchpad.net/~elementary-dev-community >> [6] https://help.launchpad.net/ListHelp >> >
-- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
