On Tuesday 19 May 2015 00:20:43 Stephen Kelly wrote:
> Kevin Kofler wrote:
> > Koehne Kai wrote:
> >> One thing to worry about though is Linux distributions: We certainly
> >> don't want to let them stick to an old Qt version because there are
> >> applications still depending on qtquick1. However,
Kevin Kofler wrote:
> Koehne Kai wrote:
>> One thing to worry about though is Linux distributions: We certainly
>> don't want to let them stick to an old Qt version because there are
>> applications still depending on qtquick1. However, a quick search with
>> e.g. osc for openSUSE shows that this
Koehne Kai wrote:
> One thing to worry about though is Linux distributions: We certainly don't
> want to let them stick to an old Qt version because there are applications
> still depending on qtquick1. However, a quick search with e.g. osc for
> openSUSE shows that this shouldn't be a big problem
Hi,
On 11.05.2015 12:00, André Somers wrote:
Simon Hausmann schreef op 11-5-2015 om 09:21:
On Saturday, May 09, 2015 09:59:18 PM Andre Somers wrote:
On 8-5-2015 18:47, Hausmann Simon wrote:
If the public API would allow you to implement what the folks at KDAB did
at http://www.kdab.com/creati
Simon Hausmann schreef op 11-5-2015 om 09:21:
> On Saturday, May 09, 2015 09:59:18 PM Andre Somers wrote:
>> On 8-5-2015 18:47, Hausmann Simon wrote:
>>> Hi,
>>>
>>> If the public API would allow you to implement what the folks at KDAB did
>>> at http://www.kdab.com/creating-pdf-qtquick-2-scene-sli
On Saturday, May 09, 2015 09:59:18 PM Andre Somers wrote:
> On 8-5-2015 18:47, Hausmann Simon wrote:
> > Hi,
> >
> > If the public API would allow you to implement what the folks at KDAB did
> > at http://www.kdab.com/creating-pdf-qtquick-2-scene-slideviewer/ , would
> > that help your use case?
project.org
> Subject: [Development] Future of Qt Quick 1 in Qt 5
>
> Hi,
>
> I think the dust has settled quite a bit and the declarative module is
> becoming better by the day. We have seen it evolve and the new Java Script
> engine is running smoothly (and actively worked on, sad
André Somers schreef op 11-5-2015 om 08:26:
> Bo Thorsen schreef op 10-5-2015 om 09:43:
>> You are aware of http://doc.qt.io/qt-5/qquickpainteditem.html, right?
>> This makes it pretty trivial to port painter based items to QtQ2.
>>
> Did you actually read the use case? I am rendering both custom a
Bo Thorsen schreef op 10-5-2015 om 09:43:
>
> You are aware of http://doc.qt.io/qt-5/qquickpainteditem.html, right?
> This makes it pretty trivial to port painter based items to QtQ2.
>
Did you actually read the use case? I am rendering both custom and
standard elements to QPainter based devices
On Sat, May 9, 2015, at 11:41 PM, Alan Alpert wrote:
> > Can we declare the module in Deprecated state and keep bug compatibility
> > with
> > previous versions? If people are using it to transition from Qt 4, it should
> > retain as much of Qt 4's behaviour as possible. That includes buggy
> > b
Thiago A. Corrêa wrote:
> IMHO you should not use Qt Quick 2D Renderer as an argument unless it were
> available in the open source package, but you could argue that there is
> mesa software render support in 5.5. What's the difference between the 2?
>
> export QMLSCENE_DEVICE=softwarecontext
> an
Den 08-05-2015 kl. 14:44 skrev André Somers:
> Frederik Gladhorn schreef op 8-5-2015 om 14:39:
>> Hi,
>>
>> I think the dust has settled quite a bit and the declarative module is
>> becoming better by the day. We have seen it evolve and the new Java Script
>> engine is running smoothly (and activel
On Fri, May 8, 2015 at 12:33 PM, Thiago Macieira
wrote:
> On Friday 08 May 2015 16:10:27 Hausmann Simon wrote:
>> Hi,
>>
>> Compilation wise I agree, it's low effort. But the situation is different in
>> Jira IMO.
>
> Can we declare the module in Deprecated state and keep bug compatibility with
>
On 8-5-2015 18:47, Hausmann Simon wrote:
> Hi,
>
> If the public API would allow you to implement what the folks at KDAB did at
> http://www.kdab.com/creating-pdf-qtquick-2-scene-slideviewer/ , would that
> help your use case?
What they basicaly did was reimplement the Quick elements they were
On Saturday 09 May 2015 16:35:20 Pau Garcia i Quiles wrote:
> On Sat, May 9, 2015 at 3:47 PM, Thiago Macieira
> wrote:Why do people read "remove" as in "you need to stop using it now"?
>
> > When we're saying "remove", we meant only that it's no longer included in
> > the
> > convenience big tarb
On Sat, May 9, 2015 at 3:47 PM, Thiago Macieira
wrote:Why do people read "remove" as in "you need to stop using it now"?
>
> When we're saying "remove", we meant only that it's no longer included in
> the
> convenience big tarball and in the binary releases. If you still need it,
> there's still
On Saturday 09 May 2015 09:31:29 Pau Garcia i Quiles wrote:
> On Sat, May 9, 2015 at 6:34 AM, Turunen Tuukka <
> tuukka.turu...@theqtcompany.com> wrote:
>
> The thing is that since the beginning of Qt 5 we have been constantly
>
> > adding things and not removing the parts that are less used (and
On Saturday 09 May 2015 04:34:45 Turunen Tuukka wrote:
> If we keep the state of making almost no fixes, why would it matter if Qt
> Quick 1 is not included in the Qt 5.6? Those who need it can take it from
> the repository and use with their app, even if we do not include the module
> any more in
On Sat, May 9, 2015 at 6:34 AM, Turunen Tuukka <
tuukka.turu...@theqtcompany.com> wrote:
The thing is that since the beginning of Qt 5 we have been constantly
> adding things and not removing the parts that are less used (and
> deprecated). Even though one might think it takes very little effort t
> Thiago Macieira kirjoitti 8.5.2015 kello 22.33:
>
>> On Friday 08 May 2015 16:10:27 Hausmann Simon wrote:
>> Hi,
>>
>> Compilation wise I agree, it's low effort. But the situation is different in
>> Jira IMO.
>
> Can we declare the module in Deprecated state and keep bug compatibility with
On Friday 08 May 2015 16:10:27 Hausmann Simon wrote:
> Hi,
>
> Compilation wise I agree, it's low effort. But the situation is different in
> Jira IMO.
Can we declare the module in Deprecated state and keep bug compatibility with
previous versions? If people are using it to transition from Qt 4,
15, at 06:10 PM, Hausmann Simon wrote:
> Hi,
>
> Compilation wise I agree, it's low effort. But the situation is different
> in Jira IMO.
>
>
> Simon
>
> Original Message
> From: Thiago Macieira
> Sent: Friday, May 8, 2015 17:37
> To: development@qt-project.
Hi,
On Fri, May 8, 2015, at 02:39 PM, Frederik Gladhorn wrote:
> One question is if there is any reason to maintain Qt Quick 1 in the
> future.
I know of some projects that are still out there using QtQuick1
(unfortunately). I think that moving to remove it now might be a little
too quick, altho
: Re: [Development] Future of Qt Quick 1 in Qt 5
Frederik Gladhorn schreef op 8-5-2015 om 14:39:
> Hi,
>
> I think the dust has settled quite a bit and the declarative module is
> becoming better by the day. We have seen it evolve and the new Java Script
> engine is running smoothl
Hi,
Compilation wise I agree, it's low effort. But the situation is different in
Jira IMO.
Simon
Original Message
From: Thiago Macieira
Sent: Friday, May 8, 2015 17:37
To: development@qt-project.org
Subject: Re: [Development] Future of Qt Quick 1 in Qt 5
On Friday 08 May 2015 14:
On Friday 08 May 2015 14:39:38 Frederik Gladhorn wrote:
> Since KDE moved over the Plasma desktop to Qt Quick 2 (on which I'm writing
> this email), I feel confident that the time has come to move everyone over.
> For the no opengl acceleration use case, we provide the Qt Quick 2D Renderer
> as bac
On Friday, May 08, 2015 04:04:46 PM André Somers wrote:
> Albert Astals Cid schreef op 8-5-2015 om 15:58:
> > On Fri, May 8, 2015 at 3:53 PM, Frederik Gladhorn
> >
> > wrote:
> >> Absolutely. But you can migrate to Qt 5.5 which has Qt Quick 1 support
> >> and
> >> later to 5.6 and onwards.
> >
>
On Fri, May 8, 2015 at 9:39 AM, Frederik Gladhorn <
frederik.gladh...@theqtcompany.com> wrote:
>
> Since KDE moved over the Plasma desktop to Qt Quick 2 (on which I'm writing
> this email), I feel confident that the time has come to move everyone over.
> For the no opengl acceleration use case, we
Albert Astals Cid schreef op 8-5-2015 om 15:58:
> On Fri, May 8, 2015 at 3:53 PM, Frederik Gladhorn
> wrote:
>>
>> Absolutely. But you can migrate to Qt 5.5 which has Qt Quick 1 support and
>> later to 5.6 and onwards.
> Not if you're using the Qt that comes with your Linux distribution
> (not sur
On Fri, May 8, 2015 at 3:53 PM, Frederik Gladhorn
wrote:
> On Friday, May 08, 2015 02:44:53 PM André Somers wrote:
>> Frederik Gladhorn schreef op 8-5-2015 om 14:39:
>> > Hi,
>> >
>> > I think the dust has settled quite a bit and the declarative module is
>> > becoming better by the day. We have s
On Friday, May 08, 2015 02:44:53 PM André Somers wrote:
> Frederik Gladhorn schreef op 8-5-2015 om 14:39:
> > Hi,
> >
> > I think the dust has settled quite a bit and the declarative module is
> > becoming better by the day. We have seen it evolve and the new Java Script
> > engine is running smoo
Frederik Gladhorn schreef op 8-5-2015 om 14:39:
> Hi,
>
> I think the dust has settled quite a bit and the declarative module is
> becoming better by the day. We have seen it evolve and the new Java Script
> engine is running smoothly (and actively worked on, sadly it will have one
> known crasher
Hi,
I think the dust has settled quite a bit and the declarative module is
becoming better by the day. We have seen it evolve and the new Java Script
engine is running smoothly (and actively worked on, sadly it will have one
known crasher in the 5.5 beta release which has been fixed in the mean
33 matches
Mail list logo
