Re: [Development] QtWayland Compositor and marketplace

[Pier Luigi Fiorini]

Il giorno gio 16 lug 2020 alle ore 10:11 Shawn Rutledge <
shawn.rutle...@qt.io> ha scritto:

>
> > On 2020 Jul 6, at 18:57, Pier Luigi Fiorini 
> wrote:
> >
> > Hi,
> >
> > I noticed that some modules are going into the marketplace, for example
> Qt Multimedia.
> > Would you consider doing so for QtWayland Compositor?
> >
> > The compositor API would surely benefit from a faster release cycle.
> >
> > Getting new protocols and updates sooner instead of every 6 months would
> be great.
> >
> > Thoughts?
>
> I’m dubious about whether the release cycle would really be faster that
> way.  Continuing to include it in the release every 6 months probably adds
> more motivation to keep fixing things regularly, rather than slowing it
> down.
>
> Otherwise, do you have examples of ongoing changes that really shouldn’t
> wait until the next release?
>
> It’s currently possible to build from git.  (And I hope it remains that
> way.)  “Releases” are artificial flag days, from one side; in practice,
> Linux distros tend to wait for them, but it doesn’t have to be that way.
>
> Maybe you want to add an extra level of release numbering, and put those
> intermediate releases into Marketplace, just to have the psychological
> effect of the existence of more “releases”, and update distro packages more
> often from there?  I.e. after 5.15.1 comes 5.15.1.1, 5.15.1.2, etc.  But
> then I’d predict that it will not be so many after all, as long as
> generating releases takes human time.
>

The main problem is that sometimes you wait even 12 months (or more) before
a release hit the end users.
6 months of release cycle + the time needed by distros to pick up a new Qt
version.

Since updating Qt is not an easy task and affects so many users, some
distros do not update right away and you can't expect to use a new protocol
implementation 12/14 months after you made that change.

-- 
https://liri.io
An OS and apps built with modern design and features
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QtWayland Compositor and marketplace

[Pier Luigi Fiorini]

Il giorno ven 10 lug 2020 alle ore 14:56 David Edmundson <
davidedmund...@kde.org> ha scritto:

>
>
> On Mon, Jul 6, 2020 at 5:58 PM Pier Luigi Fiorini <
> pierluigi.fior...@gmail.com> wrote:
>
>> Hi,
>>
>> I noticed that some modules are going into the marketplace, for example
>> Qt Multimedia.
>> Would you consider doing so for QtWayland Compositor?
>>
>
> We would need to have a client + compositor split first.
> Having the QPA (which uses unstable platform headers) on a separate cycle
> would be very problematic.
>
> David
>

Yes for sure, client side stuff should be split and keep being on the same
cycle as Qt.

-- 
https://liri.io
An OS and apps built with modern design and features
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] QtWayland Compositor and marketplace

[Pier Luigi Fiorini]

Hi,

I noticed that some modules are going into the marketplace, for example Qt
Multimedia.
Would you consider doing so for QtWayland Compositor?

The compositor API would surely benefit from a faster release cycle.

Getting new protocols and updates sooner instead of every 6 months would be
great.

Thoughts?

-- 
https://liri.io
An OS and apps built with modern design and features
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QtWayland future

[Pier Luigi Fiorini]

Il giorno gio 27 feb 2020 alle ore 15:49 Tor Arne Vestbø <
tor.arne.ves...@qt.io> ha scritto:

> Hi Pier!
>
> First of all I’d like to strongly echo your thanks to Johan for his
> amazing work on QtWayland!
>
> The module is important to us as well, and we’d like to see it continued.
> As of now we do not have a dedicated person to take over Johan's work, but
> this is something we’re looking to address.
>
> In the interim, Eskil will be our point of contact, as discussed here:
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/20#note_419952,
> and our graphics team, who has many people with Wayland experience, will
> follow up anything that comes up.
>
> What are the things you see on the horizon for Qt 6?
>

There are different topics, there are already a couple of epics:

https://bugreports.qt.io/browse/QTBUG-64598
https://bugreports.qt.io/browse/QTBUG-68847

plus off the top of my head:

- implement missing protocols like pointer constraints/relative motion
(started working on it: qtwayland code should be in good shape, needs to
clarify how does qtgui changes work on other platforms)
- possibly a better API for WaylandOutput modes from QML
- allow to set frame margins for client-side decorations (this is related
to QWindow and xdg-shell, probably other platforms too)

There are also some notes from QtCS '19:
https://wiki.qt.io/Qt_Contributors_Summit_2019_-_Qt_Wayland_Client_and_extensions

-- 
https://liri.io
An OS and apps built with modern design and features
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] QtWayland future

[Pier Luigi Fiorini]

Hi,

The QtWayland module contains the Wayland platform abstraction and a nice
library to make compositors using Qt and QtQuick.

QtWayland Compositor is being used by LG, Jolla, embedded projects and Liri.

The client part is an integral part of those projects and of course it's
fundamental for using Qt applications on Linux/Wayland.

Unfortunately Johan Helsing is leaving The Qt Company.

He has done an amazing work and I want to thank him.

Johan was basically acting as the maintainer, for quite some time I haven't
heard from Giulio.

I'm afraid that without him the project will quickly become stale, as it
was for quite some time in the post-Nokia era.

There are several things to address for Qt 6.

What are the plans for this module?

-- 
https://liri.io
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[Pier Luigi Fiorini]

Il giorno lun 27 gen 2020 alle ore 22:01 Alexander Akulich <
akulichalexan...@gmail.com> ha scritto:

>
> You already made life harder by licensing Qt under GPL v3. Of course,
> it has pros and cons, but let's jump to the consequence: we have
> Sailfish OS out of the boat. The OS could have a modern Qt and we
> actually could have people working on the upstream QtDeclarative, Qt
> Quick Controls 2 and other modules in the paid time, but. The OS
> developers have complex agreements with a number of important business
> partners and for some of them, it is unacceptable to follow some of
> the tivoization-related GPL v3 clauses. It is hard to explain to
> managers the profit from a new version or collaboration with the Qt
> community. (From a business PoV) it makes very little sense to pay for
> some abstract "technical prettiness" as long as Qt 5.6 gives you the
> money.
>

Jolla should just buy a proprietary license since the user facing bits are
proprietary as well.

-- 
https://liri.io
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Any history on why "qtmultimedia5-private-dev" was removed.

[Pier Luigi Fiorini]

Il giorno ven 29 nov 2019 alle ore 08:44 Paul Knopf 
ha scritto:

> I'm working on getting Debian 10 working for my Linux appliance/device and
> our GUI uses Qt.
>
> Specifically, it uses "CONFIG+=multimedia-private".
>
> There seems to be a bunch of private Qt headers in the official repos, but
> non for qtmultimedia5.
>
> There looks to be history of "qtmultimedia5-private-dev", but it doesn't
> exist anywhere anymore.
>
> I found this:
> https://metadata.ftp-master.debian.org/changelogs/main/q/qtmultimedia-opensource-src/unstable_changelog
>
> ---
>   * Remove package qtmultimedia5-private-dev. Nothing in the Qt stack
> seems to
> be using it. Can be reintroduced later if needed.
> - Remove associated install file.
> - Remove the files from debian/tmp before installing the packages.
> ---
>
> Can anyone provide me with some context?
>

Debian doesn't ship private headers, unless they are needed by the Qt stack.
Using private headers in third party applications is not recommended.

-- 
https://liri.io
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating David Edmundson as approver

[Pier Luigi Fiorini]

+1

Il giorno ven 23 ago 2019 alle ore 14:17 Johan Helsing 
ha scritto:

> Hi all,
>
> I'd like to nominate David Edmundson as approver for the Qt Project. David
> started contributing to Qt in 2013 and has been active contributing and
> reviewing patches in QtWayland for the past two years. His patches and
> reviews have a very high quality and I trust he will use his rights
> responsibly.
>
> Here is his list of contributions:
> https://codereview.qt-project.org/q/owner:davidedmundson%2540kde.org
>
> And reviews:
> https://codereview.qt-project.org/q/reviewer:davidedmundson%2540kde.org
>
> Best regards,
> Johan Helsing
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>


-- 
https://liri.io
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 Planning: Consideration of dropping support for UWP applications

[Pier Luigi Fiorini]

Does this affect shipping Qt apps in the store?
I'm not a Windows expert but as far as I remember only UWP apps are
supposed to go there, but I can be wrong.

Il giorno gio 18 apr 2019 alle ore 14:50 Oliver Wolff 
ha scritto:

> Hi,
>
> as you might have heard, we are currently in Qt 6's planning phase and
> thus checking things that have to be done to make Qt even better.
> Of course we also want to use this opportuniy to drop support for
> platforms that are no longer relevant in Qt's new environment.
>
> One of these platforms is Microsoft's Universal Windows Platform which
> is used on desktop PCs (for "Tiled" UWP applications, no classic desktop
> applications), Windows Phone, Xbox one, Microsoft Hololens, and
> Microsoft IoT devices. With Windows Phone no longer being relevant and
> Microsoft's IoT strategy being unclear we now consider dropping support
> for these platforms. Additional benefits and reasons can be found in
> https://bugreports.qt.io/browse/QTBUG-74755
>
> To be able to make the right decision, we now want your input as well.
> If you can give some input on why support should be kept or have
> additional reasons for dropping support, please reply to this mail or
> add your input to https://bugreports.qt.io/browse/QTBUG-74755 where we
> want to gather all the needed information before making a decision.
>
> As said before, nothing is set in stone. At the moment we are gathering
> information so that we can make a well informed decision.
> Olli
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>


-- 
https://liri.io
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt Quick Templates 2 from C++

[Pier Luigi Fiorini]

Mitch, do you have plans?

Il giorno gio 14 feb 2019 alle ore 20:12 drwho  ha
scritto:

> On 2019-02-14 5:45 a.m., Pier Luigi Fiorini wrote:
> > Hi,
> >
> > I'd like to know if you have plans of making Qt Quick Templates 2 a
> > public API and allow people to write new controls with C++ without
> > using a private library.
>
> +1 for this and also for a public api for c++ Qt Quick Controls 2
> widgets.  Our management killed our Qt desktop app in favor of HTML 5
> electron garbage.
>
> Jon
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>


-- 
https://liri.io
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Qt Quick Templates 2 from C++

[Pier Luigi Fiorini]

Hi,

I'd like to know if you have plans of making Qt Quick Templates 2 a public
API and allow people to write new controls with C++ without using a private
library.

-- 
https://liri.io
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

[Pier Luigi Fiorini]

Il giorno mar 30 ott 2018 alle ore 17:52 Oswald Buddenhagen <
oswald.buddenha...@qt.io> ha scritto:

> On Tue, Oct 30, 2018 at 09:10:27AM -0700, Thiago Macieira wrote:
> > Is it packaged in a Linux distribution? My requirements also included
> > continuously packaged for 2 years in at least 3 Linux distributions,
> > at the time of the Qt switch to the particular buildsystem.
> >
> it's been packaged for much longer and by more distros already, because
> it's part of qt creator for quite a while. i don't know whether all of
> them ship it as separate packages already, but the official messaging
> from us was that they *should*.
>
>
Distros started packaging it separately for some time now.
Before that, as you point out, it was packaged inside QtCreator.

Debian: https://packages.debian.org/sid/qbs
Fedora: https://apps.fedoraproject.org/packages/qbs
Arch Linux: https://www.archlinux.org/packages/extra/x86_64/qbs/
OpenSuSE: https://software.opensuse.org/package/qbs?search_term=qbs

-- 
https://liri.io
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Pier Luigi Fiorini]

Il giorno mar 30 ott 2018 alle ore 09:59 Olivier Goffart 
ha scritto:

> On 10/30/18 6:29 AM, resurrect...@centrum.cz wrote:
> > Honestly I feel very disappointed as well with this decision. I feel
> similarly
> > to others, Qbs is now being phased out so fast (half a year of
> development,
> > another half a year of maintanance after that it seems). So better get
> to
> > porting stuff to CMake right away. Having experience with CMake this is
> gonna
> > be very ugly...
> >
> > What I do not understand is why the decision was qmake + cmake in the
> first
> > place. Why not Qbs + CMake? Was not the qmake deemed unmaintainable? It
> is
> > perfectly understandable to tap into wide CMake user base but why
> ditching Qbs
> > and not qmake? I wouldn't expect people would mourn qmake...
>
> This is not about "qmake + cmake" vs. anything.
>
> Qbs did not disappear from one day to the other.
> What Lars said, if I read the email properly, is that the Qt Company does
> not
> see a business value in developing it further.
> But the project is open source and the code is there and anyone is free to
> take
> over if they are interested in it.
>

We all know that without company support, the project will stagnate.


> And Qbs does not have to build Qt for you to use it.
>

No but it would have been a great indicator of confidence on the project
and help its adoption because it would have been much more noticeable than
QtCreator (not all Qt users and developers build QtCreator but a lot of
them do build Qt).
The main problem here is not that Qt will use CMake, the problem is that
Qbs will no longer be maintained.
Given that qmake is not suitable for large projects, Qbs will not be
developed anymore we can expect only CMake support on QtCreator to improve,
therefore a lot of us will need to migrate to CMake.

-- 
https://liri.io
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Pier Luigi Fiorini]

Il giorno mar 30 ott 2018 alle ore 04:34 Thiago Macieira <
thiago.macie...@intel.com> ha scritto:

>
> > You've said it yourself that qbs did give good results. Maybe give it a
> > chance?
>
> It's been given a chance. The wip/qbs branch has existed for years in
> qtbase.
> The tool has existed for years.
>

No Qbs hasn't got visibility outside the Qt project and even inside there
are people, like me, who really learned about it a couple years ago and
then it was planned to be the Qt 6 build system.
With more visibility, documentation and examples in all those years, things
might different now.

Some people say Qt is not in the business of creating a build tool but it
was not in the business of creating an IDE but we have QtCreator, which is
an excellent IDE tailored to the needs of Qt developers.

In less than two years we went from the build system planned for Qt 6 to a
deprecated tool.
Spending those years improving CMake (documentation, IDE integration, ...)
would have been far better then.


>
> Can you name any project of moderate complexity using it?
>
>
https://github.com/lirios

-- 
https://liri.io
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Pier Luigi Fiorini]

I too feel like thanks are in order to the Qbs team.
Hopefully CMake integration with QtCreator will quickly improve and include
mobile platforms as well as embedded and desktop.

Il giorno lun 29 ott 2018 alle ore 17:24 Corentin 
ha scritto:

>
> Having had the pleasure to use QBS quite extensively (and successfully) in
> the past, I would like to thank the QBS team and contributors for showing
> us what a sane, modern build system could look like.
> So long!
>
> On Mon, 29 Oct 2018 at 13:17 Lars Knoll  wrote:
>
>> Hi all,
>>
>> As you will probably remember, there have been lively discussions around
>> what kind of build tool to use for Qt 6 both during Qt Contributor Summits
>> as well as on this mailing list.
>>
>> There has been a strong consent that we should move away from qmake as
>> our build tool for Qt due to many shortcomings and the burden we have
>> maintaining the system.
>>
>> Thiago wrote a set of relatively strict requirements for such a build
>> tool in his mail in July. While some of the requirements had a bit of a
>> Linux specific background, they have been a good basis.
>>
>> There have been rather lively discussions around alternatives, but most
>> focused around two possible choices for us: Qbs and cmake.
>>
>> Qbs is something that has been developed almost exclusively by The Qt
>> Company. As such, TQtC had to also look at it from a business perspective
>> and how it fits into the larger picture of making Qt successful. To make a
>> long story short, while Qbs is pretty cool and interesting technology, it
>> doesn’t really help us expand the Qt ecosystem and usage.
>>
>> To make Qbs really successful would require a rather large effort and
>> investment in promoting it towards the larger C++ ecosystem as a new build
>> tool. At the same time it has to be an open source product to stand any
>> chance in the market. Together this makes it challenging for TQtC to see
>> how to recover that investment. Thus this investment would be at the
>> expense of other things we’d like to do, like improving our IDE, working on
>> rearchitecting and cleaning up our core frameworks for Qt 6 or the design
>> tooling we are currently investing into. The Qt Company believes that those
>> other investments are more important for the future of Qt than our choice
>> of build tool.
>>
>> As such, we were left with the question on whether we need Qbs as the
>> build system for Qt 6 or whether cmake (as the other alternative) would be
>> up to the task.
>>
>> Given that background, we’ve done some more research on using both Qbs
>> and cmake to build Qt. Both projects did give us good results but we were
>> actually surprised on how far we got with cmake in a rather limited period
>> of time.
>>
>> In addition, cmake has the advantage of being very widely used in the C++
>> ecosystem (amongst many others by KDE), has a very wide support in many
>> IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of
>> knowledge about the build system available in the ecosystem. Using it with
>> Qt 6 would also mean that we can focus our support on two build systems for
>> our users (qmake and cmake) and we would not have to add a third one to the
>> mix.
>>
>> Given that we are confident we can build Qt 6 with cmake, I believe that
>> it makes most sense to follow down that route. In case you’re interested,
>> you can have a look at the cmake prototype code for qtbase on Gerrit in the
>> wip/cmake branch. Please also let us know if you’re interested in helping
>> with the effort of porting Qt’s build system over to cmake.
>>
>> We have been developing Qbs over the last years, and as such are
>> committed to it for some more time. We are planning on another feature
>> release in the first quarter of next year and will support it in Qt Creator
>> for at least another year. Qbs is open source and if someone wants to take
>> over and develop it further let us know as well. I’d also like to use this
>> place to thank Christian and Jörg for all their great work on Qbs  (and of
>> course also anybody else who contributed to it).
>>
>> Cheers,
>> Lars
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>


-- 
https://liri.io
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Johan Helsing for Approver status

[Pier Luigi Fiorini]

2016-08-04 12:22 GMT+02:00 Paul Tvete :

> Hi all,
>
>
> I'd like to nominate Johan Helsing for Approver status. He joined The Qt
> Company half a year ago, and has been working full time on Qt since. Johan
> has been actively involved in making the QtWaylandCompositor module ready
> for Qt 5.8, as well as doing a major part of the bug fixes for Qt Wayland
> in 5.6 and 5.7.
>
> Here is his gerrit dashboard:
>
> https://codereview.qt-project.org/#/q/owner:%22Johan+Helsing%22,n,z
>
> Johan's list of reviews can be found at:
>
> https://codereview.qt-project.org/#/q/reviewer:%22Johan+
> Helsing+%253Cjohan.helsing%2540theqtcompany.com%253E%22,p,003e6e7d0002807d
>
> Cheers,
>
> - Paul
>


+1

Cheers
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Update QtWayland CI to Wayland 1.6+

[Pier Luigi Fiorini]

2016-01-14 10:15 GMT+01:00 Jędrzej Nowacki <jedrzej.nowa...@theqtcompany.com
>:

> On Monday 11 of January 2016 00:27:08 Pier Luigi Fiorini wrote:
> > Hi,
> >
> > We are starting to have QtWayland patches that require at least Wayland
> 1.6
> > available, such as:
> >
> > - https://codereview.qt-project.org/#/c/104222/
> > - https://codereview.qt-project.org/#/c/112141/
> > - https://codereview.qt-project.org/#/c/144891/
> >
> > We need to update CI to at least Wayland 1.6 as soon as possible.
> >
> > If I recall CI is running Ubuntu 14.04 LTS now, but LTS is released every
> > two years.
> >
> > The next LTS should be 16.04 which means that until April we cannot merge
> > those patches making the first one more than 1 year old.
> >
> > Would it be possible to switch to a distro that potentially has more
> > frequent updates to avoid repeating the same problem again in the future?
>
> Hi,
>
>  I guess the whole point of having Ubuntu 14.04 LTS in CI is to support
> that
> platform as long as it is important. As you said it will be important until
> 16.04 release. I think we could potentially remove 14.04 from CI on dev
> branch
> after Qt 5.7 release. Can't you "ifdef" you code, so it "works" with the
> older
> Wayland too?



Nope, unfortunately in order to use the newer protocol we need to link to
libwayland >= 1.6

Recent versions of Wayland (>= 1.8) should let us target a new protocol
version while linking to an older version mitigating the problem in the
future, but still Ubuntu is probably not the best option for Wayland.

-- 
Out of the box experience
http://hawaiios.org/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Update QtWayland CI to Wayland 1.6+

[Pier Luigi Fiorini]

2016-01-14 15:39 GMT+01:00 Thiago Macieira :

> On Thursday 14 January 2016 10:15:40 Jędrzej Nowacki wrote:
> >  I guess the whole point of having Ubuntu 14.04 LTS in CI is to support
> that
> > platform as long as it is important. As you said it will be important
> until
> > 16.04 release. I think we could potentially remove 14.04 from CI on dev
> > branch after Qt 5.7 release. Can't you "ifdef" you code, so it "works"
> with
> > the older Wayland too?
>
> I don't think it makes sense to support Wayland that old, especially not
> on a
> distro that decided to not support Wayland. It's probably better to just
> skip
> building Wayland altogether if the found libraries are too old.
>
> We just need a newer distro that does support Wayland to be present.


That looks like a future proof solution, perhaps OpenSuSE - the new 42
release has Wayland 1.8 as far as I can tell [*]

[*]
http://download.opensuse.org/repositories/openSUSE:/42/images/repo/openSUSE-42.1-x86_64-Build0008-Media1/suse/x86_64/libwayland-server0-1.8.0-1.4.x86_64.rpm


-- 
Out of the box experience
http://hawaiios.org/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Update QtWayland CI to Wayland 1.6+

[Pier Luigi Fiorini]

Hi,

We are starting to have QtWayland patches that require at least Wayland 1.6
available, such as:

- https://codereview.qt-project.org/#/c/104222/
- https://codereview.qt-project.org/#/c/112141/
- https://codereview.qt-project.org/#/c/144891/

We need to update CI to at least Wayland 1.6 as soon as possible.

If I recall CI is running Ubuntu 14.04 LTS now, but LTS is released every
two years.

The next LTS should be 16.04 which means that until April we cannot merge
those patches making the first one more than 1 year old.

Would it be possible to switch to a distro that potentially has more
frequent updates to avoid repeating the same problem again in the future?

-- 
Out of the box experience
http://hawaiios.org/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Bit of help for QtWayland on a Raspberry Pi

[Pier Luigi Fiorini]

2015-11-05 10:46 GMT+01:00 Massimo Callegari :

> >>> Indeed they aren't on GL windows. The goal with decorations is to move
> >>> them to subsurfaces and just draw them with SHM, so we don't need to
> >>> do hacks for GL windows like we do in the wayland-egl
> >>> hardwareintegration.
> >>
> >> So what's the whole point of having a compositor if you cannot do
> anything on windows ?
> >
> > What do you mean? You don't need decorations to interact with windows,
> > though they are surely useful.
>
> I mean from the user interaction perspective.
> Let's leave the compositing of multiple applications aside for a moment.
> Normally, a QtWidget application makes use of modal/non-modal windows to
> represent sub-areas of the software (e.g. configurations, preview, status,
> etc)
> If a window doesn't have the OK/Cancel buttons, then you need a window
> decoration to close it.
> Also, it might be necessary to move a sub-window around the screen to see
> what happened in the main window. There you need a title bar to get a grip
> to the window.
> Eventually QML has the same needs when using the Window item.
>
> In general, the point is that with QPA plugins like eglfs, linuxfb and
> wayland it is impossible to use Qt application in some cases.
> That was not the case with QWS, which provided a simple windowing system
> out of the box.
>
> I think it should be somehow considered to reintroduce QWS on top of QPA.
> So QPA plugins would be in charge of purely handling the
> hardware/protocols abstraction and QWS would be an optional layer adding
> the missing pieces to make an application usable on certain QPA (basically
> when the OS doesn't provide a window manager)
>


Window management is available with QtWayland, the client side decoration
is missing only with the brcm hw integration as explained earlier by Giulio.


>
>
> >> Can windows+decorations be treated like GL textures as part of the same
> GL window ?
> >
> > Yes, that's what the wayland-egl plugin does, but as i said it's an
> > hack that nobody bothered to port to brcm, because it fiddles with the
> > GL context state, and that's a thing applications don't usually like.
> > The subsurface approach will fix this problem, i may have something
> > working in a few days.
>
> That would be great news for my use case !
> If you want, I have a user on Gerrit, and in case I can make some tests on
> brcm-eglfs. Just add me to reviewers when the changeset is somehow usable.
>
> Thanks !
> Massimo
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>



-- 
Out of the box experience
http://hawaiios.org/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qtbase 5.5 CI broken again ?

[Pier Luigi Fiorini]

Looks like it's broken for qtwayland too.

https://codereview.qt-project.org/#/c/120705/

Though I don't get what ci-osx109-x64-09 has to do with qtwayland
which is Linux only.

2015-07-21 13:56 GMT+02:00 BogDan bog_dan...@yahoo.com:
 Hey,

 It's juts me or CI is broken again? I'm trying to push a two patches[0] for a 
 few days with no luck ...

 Cheers,
 BogDan.


 [0] https://codereview.qt-project.org/#/c/120757/
 https://codereview.qt-project.org/#/c/120756/
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development



-- 
Out of the box experience
http://hawaiios.org/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development