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
sense to write a brand new compositor when we could continue to use

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.

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: [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 <>:

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
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,

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?

I am familiar/interested in Wayland and Qt, I would like to do X to
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.'

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
sense to write a brand new compositor when we could continue to use

But yes, I think right now it makes the most sense for us to be
thinking Wayland instead of Mir.


Daniel Foré [1]

On Fri, Jun 6, 2014 at 11:01 AM, José Expósito
<> wrote:

I was not talking about porting all the apps to Qt, actually this
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
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


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
<> 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
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] [2] [1]

[2] [3] [2]


[1] [2]
[2] [3]

 Mailing list: [5]
 Post to     :
 Unsubscribe : [5]
 More help   : [6]


Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to