elementary-dev-community team mailing list archive

[José Expósito <jose.exposito89@xxxxxxxxx>]

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, <dardevelin@xxxxxxxxxxxxxx> 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 <dardevelin@xxxxxxxxxxxxxx>:
>>
>>  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.exposito89@xxxxxxxxx> 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
>>> <jacobparker1992@xxxxxxxxx>:
>>>
>>> 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.exposito89@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>>  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
>>
>