[Development] Behavioral change with font metrics

[Eskil Abrahamsen Blomfeldt via Development]

ll see that text layouts get smaller and it might mess up their 
UIs, especially if they were designed with hardcoded sizes. These users can 
easily get back previous behavior by setting the opt-out flags though, so at 
least there is a very fast solution. And hopefully most users will be happy 
that Qt is working according to the spec.

Any comments or thoughts?


--

Eskil Abrahamsen Blomfeldt

Senior Manager, Graphics Engines



The Qt Company

Sandakerveien 116

0484, Oslo, Norway

eskil.abrahamsen-blomfe...@qt.io

+47 938 85 836

http://qt.io



The Future is Written with Qt

--


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

Re: [Development] Nominating Jøger Hansegård for approver rights

[Eskil Abrahamsen Blomfeldt via Development]

+1 

Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

From: Development  on behalf of Tor Arne 
Vestbø via Development 
Sent: Thursday, March 14, 2024 10:06 AM
To: development 
Subject: [Development] Nominating Jøger Hansegård for approver rights

Hi,

I would like to nominate Jøger Hansegård for approver rights in the Qt project.

Jøger joined The Qt Company 10 months ago and has since then been getting his 
hands dirty in Qt Multimedia, and lately focusing on color management.

Jøger is a thorough and responsible engineer and I trust that he will make a 
good approver for the Qt project.

Authored changes: 
https://codereview.qt-project.org/q/owner:joger.hansegard%2540qt.io
Reviews: https://codereview.qt-project.org/q/reviewer:joger.hansegard%2540qt.io

Cheers,
Tor Arne
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Nominating Hatem ElKharashy for maintainership of Qt Svg

[Eskil Abrahamsen Blomfeldt via Development]

Hi,

I would like to nominate Hatem ElKharashy for maintainership of the Qt Svg 
module. This module currently does not have any active maintainer, but it has 
been part of my team's responsibility and backlog within The Qt Company.

Hatem has recently been working on adding support for new SVG features in Qt 
Svg, as well as fixing bugs and greatly improving the test coverage in the 
module. I think he is a great candidate to take on the maintainership of this 
module.

Authored changes:
https://codereview.qt-project.org/q/owner:hatem.elkharashy%2540qt.io

Reviewed hanges:
https://codereview.qt-project.org/q/reviewer:hatem.elkharashy%2540qt.io


--

Eskil Abrahamsen Blomfeldt

Senior Manager, Graphics Engines



The Qt Company

Sandakerveien 116

0484, Oslo, Norway

eskil.abrahamsen-blomfe...@qt.io

+47 938 85 836

http://qt.io



The Future is Written with Qt

--


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

Re: [Development] Nominating Piotr Wierciński for approval status

[Eskil Abrahamsen Blomfeldt via Development]

+1 

Although I think 2013 should be 2023.

Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

From: Development  on behalf of Morten 
Sørvig via Development 
Sent: Thursday, February 8, 2024 9:39 AM
To: development@qt-project.org 
Subject: [Development] Nominating Piotr Wierciński for approval status

I would like to nominate Piotr Wierciński for approver rights in the Qt project.

Piotr joined the Qt company early 2013 and has since then contributed to Qt for 
WebAssembly. This includes many bugfixes and also larger efforts such as 
getting tests running in the CI system.

Piotr is a pleasure to work with and I trust that he will make a good approver 
for the Qt project.

Changes:  https://codereview.qt-project.org/q/owner:piotr.wiercinski
Reviews:  https://codereview.qt-project.org/q/commentby:piotr.wiercinski 
<https://codereview.qt-project.org/q/commentby:piotr.wiercinski:>

Best regards,
Morten
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Hatem ElKhrarashy for approval status

[Eskil Abrahamsen Blomfeldt via Development]

+1 

Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

From: Development  on behalf of Janne 
Koskinen via Development 
Sent: Tuesday, February 6, 2024 10:18 AM
To: 'Qt development mailing list' 
Cc: Hatem ElKharashy 
Subject: [Development] Nominating Hatem ElKhrarashy for approval status

I would like to nominate Hatem Elkharashy for approver rights in the Qt project.

Hatem has been working on Qt Graphics for 2,5 years contributing to QtQuick3D, 
QtCharts, QtDeclarative, QtBase and most recently on QtSvg.

Changes where he is the author:
https://codereview.qt-project.org/q/owner:hatem.elkharashy%2540qt.io

Changes where he is reviewer:
https://codereview.qt-project.org/q/reviewer:hatem.elkharashy%2540qt.io

-Janne Koskinen
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Vlad Zahorodnii for approval status

[Eskil Abrahamsen Blomfeldt via Development]

+1!

Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

From: Development  on behalf of David 
Edmundson 
Sent: Thursday, February 1, 2024 3:11 PM
To: development 
Subject: [Development] Nominating Vlad Zahorodnii for approval status

I would like to nominate Vlad Zahorodnii for approver rights in the Qt project.

Vlad has also been working on the QtWayland backend, providing insight
based on his other role as one of the kwin maintainers.
Vlad and I have been working together at Blue Systems for 5 years. He
is extremely technically competent and very thorough in reviews. I
trust that he would exercise approver rights responsibly.

Changes where he is the author:
https://codereview.qt-project.org/q/author:vlad.zahorodnii%2540kde.org
Changes where he commented/voted
https://codereview.qt-project.org/q/reviewer:vlad.zahorodnii%2540kde.org
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating David Redondo for approval status

[Eskil Abrahamsen Blomfeldt via Development]

+1!

Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

From: Development  on behalf of David 
Edmundson 
Sent: Thursday, February 1, 2024 3:10 PM
To: development 
Subject: [Development] Nominating David Redondo for approval status

I would like to nominate David Redondo for approver rights in the Qt project.

David's first contributions to Qt started in November 2020, but has
ramped up this last year working on the Qt Wayland platform. Not only
has he fixed a lot of issues within Qt Wayland, but he has also
managed to push changes into upstream wayland and un-break a lot of
important Qt functionality.
David and I work together at Blue Systems for the last 4 years. I have
full confidence in his ability to review code correctly and also to
use any new privileges appropriately.

Changes where he is the author:
https://codereview.qt-project.org/q/author:qt%2540david-redondo.de
Changes where he commented/voted on:
https://codereview.qt-project.org/q/reviewer:qt%2540david-redondo.de

David
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Matthias Rauter for approval status

[Eskil Abrahamsen Blomfeldt via Development]

+1!

Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

From: Development  on behalf of Paul Tvete 
via Development 
Sent: Tuesday, January 30, 2024 1:11 PM
To: Qt development mailing list 
Subject: [Development] Nominating Matthias Rauter for approval status

Hi,

I would like to nominate Matthias Rauter as an approver for the Qt Project.

Matthias has been working on Qt for more than a year now. In this time, he has 
done great work on Qt Location and Qt SVG, among other. I have had the pleasure 
to work with him on the Curve Rendering project in Qt Quick Shapes where he has 
made impressive contributions. He has been consistently professional in 
development and review, and I am certain that he will exercise his approver 
powers responsibly.

List of changes made by Matthias: 
https://codereview.qt-project.org/q/owner:matthias.rauter%2540qt.io
Matthias's review activity: 
https://codereview.qt-project.org/q/commentby:matthias.rauter%2540qt.io

Cheers,
 - Paul
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Replacement for QFont::ForceIntegerMetrics in Qt 6?

[Eskil Abrahamsen Blomfeldt via Development]

Hi!

ForceIntegerMetrics was originally added to get CoreText to look at little bit 
better with WebKit, since WebKit did not support subpixel positioning at the 
time and CoreText did not support font hinting. I removed it in Qt 6 because 
it's honestly not a typographically sensible thing to do, and the original use 
case had become irrelevant 

For your case, where you want to make sure your font aligns to the pixel grid, 
you could try enabling hinting  on it with 
font.setHintingPreference(QFont::PreferFullHinting). Font hinting will slightly 
alter the glyphs so that they actually align to the pixel grid instead of 
introducing kerning errors (which is what ForceIntegerMetrics did). I'm not 
sure if this is what you mean by "disabling design metrics"? If so, what 
exactly was the issue with it? I principle, I think this is the most correct 
solution to the problem, so maybe there's some way of getting it to work.

If that does not work, then another option is to manually get the QGlyphRuns 
from the QTextLayout and align the glyphs yourself before drawing them. That 
should get you the same layout as with ForceIntegerMetrics, both good and bad, 
without much extra work.

(Of course, ideally the rendering code should not assume integer advances for 
the characters, since this is not really a reasonable expectation for unhinted, 
scalable fonts, but I can see how it's not tempting to rewrite it just for this 
port.)

Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

From: Development  on behalf of Kai Uwe 
Broulik 
Sent: Saturday, November 4, 2023 10:50 AM
To: development@qt-project.org 
Subject: [Development] Replacement for QFont::ForceIntegerMetrics in Qt 6?

Hi everyone,

in Qt 5.15 the QFont::ForceIntegerMetrics was deprecated and
subsequently removed in Qt 6.

The rendering engine in Konsole, KDE’s terminal emulator, relies on the
fact that every glyph in the monospace font is rendered at the same
width, since sections of different style (e.g. search highlight, text
selection, various escape sequence formattings, etc) are painted in
different pases, basically positioned at charWidth * letterXPos.

With Qt 6, without this flag, the individual letters might be placed at
fractional positions, so a long text run can end up short of what the
renderer expects, leading to gaps in the rendering, see the attached
screenshot where I selected some text which now makes a gap.

I have read into QFontEngine a bit and found that the general
replacement is disabling use of “design metrics”. I changed the
rendering to use QPainter::paint with a QTextOption disabling design
metrics [1], which fixed the issue on my machine but apparently causes
issues with other fonts again.

Many of us have tried to find a solution for this but haven’t, really,
and it is a major showstopper for the Qt 6 adoption here. Any idea how
to address this properly, short of rewriting the renderer that I assume
has been like this for decades or perhaps some insights on what prompted
the removal?

Cheers
Kai Uwe

[1] 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Finvent.kde.org%2Futilities%2Fkonsole%2F-%2Fmerge_requests%2F911=05%7C01%7Ceskil.abrahamsen-blomfeldt%40qt.io%7C402caffbb31d49df5cef08dbdd1bc085%7C20d0b167794d448a9d01aaeccc1124ac%7C0%7C0%7C638346883796105023%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=c5whMadCyHEavgFDTdDha8dTpO%2FRUBAnK%2Bp453ynvmk%3D=0<https://invent.kde.org/utilities/konsole/-/merge_requests/911>
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QSGText: Why round glyph position like this?

[Eskil Abrahamsen Blomfeldt via Development]

Hi!

Just removing the pixel snapping from the vertex shader should definitely cause 
regressions, yes.

I'm not totally clear on what the problem is on your end, so maybe it is more 
efficient if you file a bug report for this with some screenshots and 
descriptions of what you mean?


Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io


From: Kai Uwe Broulik 
Sent: Tuesday, September 5, 2023 8:51 AM
To: Eskil Abrahamsen Blomfeldt ; 
development@qt-project.org 
Subject: Re: [Development] QSGText: Why round glyph position like this?

Hi,

thanks for your insights, Eskil!

I am running a self-compiled Qt dev, so it’s all up-to-date. I did some
further investigation and found that the glyph cache is actually
rendered alright, so nothing to do with FreeType etc.

It seems that the textmask.vert [1] shader is still not entirely
perfect, even after the fixes you mentioned: If I remove the
flooring/dpr stuff from it, text is rendered correctly here but could
probably regress elsewhere?

For example, the word “Erscheinungsbild” has two “i”, both use the same
glyph in my case, but the second one is rendered incorrectly by the shader:

Glyph #7 (i):
In cache at 66,1 @ 5x17, gets rendered to 40.5714,4 @ 2.85714x9.71429
Scale the coordinate back up x1.75 gives us 70.5,7 @ 4.95x17.075

Glyph #14 (i):
In cache at 66,1 @ 5x17, gets rendered to 90.2857,4 @ 2.85714x9.71429
Scale the coordinate back up x1.75 gives us 157.75,7 @
4.95x17.075

I haven’t managed to get Renderdoc up and running, though, to see what
values the shader actually processes and why one gets misplaced by it.
Any idea?

The issue can be reproduced under Wayland *and X*, with NativeRendering.

Cheers
Kai Uwe

[1]
https://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/quick/scenegraph/shaders_ng/textmask.vert#n22

Am 29.08.23 um 13:07 schrieb Eskil Abrahamsen Blomfeldt:
> [...] I did fix some bugs related to this,
> e.g. https://codereview.qt-project.org/c/qt/qtdeclarative/+/417675
> <https://codereview.qt-project.org/c/qt/qtdeclarative/+/417675> and
> https://codereview.qt-project.org/c/qt/qtdeclarative/+/376361
> <https://codereview.qt-project.org/c/qt/qtdeclarative/+/376361>
>
> Most of my testing was on Windows, though, so it sounds like there could
> still be issues on Wayland
> [...]

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

Re: [Development] QSGText: Why round glyph position like this?

[Eskil Abrahamsen Blomfeldt via Development]

Hi!

The reason for rounding is that the subpixel position of the glyphs is baked 
into the cached rendering of the glyph itself (so horizontal position x.5 would 
be a different cached object than x.0, but they should both be rendered at 
pixel x). It's a bit complex because the projected positions of the glyphs are 
calculated later, in the vertex shader, so you need to do some precalculation 
to produce something which aligns with the pixel edge when the final scale is 
applied. I believe the reason retina is mentioned there specifically is just 
because it's the first place we supported DPI-scaling, but it's not exclusive 
to Apple anymore.

Which Qt version is in use here? I did fix some bugs related to this, e.g. 
https://codereview.qt-project.org/c/qt/qtdeclarative/+/417675 and 
https://codereview.qt-project.org/c/qt/qtdeclarative/+/376361

Most of my testing was on Windows, though, so it sounds like there could still 
be issues on Wayland.


Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io


From: Development  on behalf of Kai Uwe 
Broulik 
Sent: Monday, August 28, 2023 6:22 PM
To: development@qt-project.org 
Subject: [Development] QSGText: Why round glyph position like this?

Hi everyone,

while investigating blurry font with native renderer in QML apps in
Plasma 6 under Wayland with fractional scaling (devicePixelRatio 1.75 in
my case), I stumbled upon QSGTextMaskMaterial::populate which rounds the
glyph position [1] citing Mac OS behavior.

When I remove the rounding, font appears rendered correctly on my system
(sorry for attachment ;), but this code hasn’t changed since 2014 and I
am not very knowledgeable in this part of Qt. It’s also flooring the X
and rounding the Y coordinate.

What’s the deal with that? Tor Arne, can you perhaps shed some light on
this?

Cheers
Kai Uwe

[1]
https://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/quick/scenegraph/qsgdefaultglyphnode_p.cpp#n455
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QtWayland compositor can't to render a wl_surface to multi outputs, Is this a restrict of QtQuick graphics scene?

[Eskil Abrahamsen Blomfeldt via Development]

Hi,

Each window has an isolated scene graph and RHI instance, which is the reason 
for this limitation if I understand correctly. Decoupling them is actually 
quite complicated, because different screens have different surface formats 
requirements and it might not be possible to render to both screen within the 
same context or to share graphics resources between them. These difficulties 
are also why Wayland Compositor bases outputs on windows with isolated 
graphics. I know there have been talks of decoupling the Qt Quick graph from 
the window, so that the same Qt Quick code can control items in multiple 
windows. There would still be separate graphics for the two windows and then 
need for duplicate items, but synchronizing animations in that case should be 
easier. Nothing concrete has come of this yet, though, but to me it sounds like 
a more feasible way forwards than redesigning the Qt Quick scene graph.

In the current state, duplicating the items is the correct way to go, at least. 
In order to make sure the animations are in sync, you could for instance have 
some centralized property in a singleton which is read from both scenes and 
just animate that. I think that's probably the easiest way.


Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io


From: Development  on behalf of JiDe Zhang 

Sent: Tuesday, July 4, 2023 9:06 AM
To: Qt邮件列表 
Subject: [Development] QtWayland compositor can't to render a wl_surface to 
multi outputs, Is this a restrict of QtQuick graphics scene?

The following is a part of an QtWayland example:

WaylandOutput {
sizeFollowsWindow: true
window: Window {
width: 1024
height: 768
visible: true

Repeater {
model: shellSurfaces

ShellSurfaceItem {
shellSurface: modelData
onSurfaceDestroyed: shellSurfaces.remove(index)
}
}
}
}


If I have two displays, and a part of a ShellSurfaceItem is in the first 
display, and the other part of the ShellSurfaceItem in the second display. In 
this case, I need to ensure the user can see this ShellSurfaceItem
on both first and second displays, on QtWayland, I can using two WaylandOutput 
with two Window for this case, and create ShellSurfaceItem for which 
WaylandOutput.

But, If I using two ShellSurfaceItem for one wl_surface, I can't sync the 
window animation in different WaylandOutput, this is a hard job, because the 
QQuickItem must bind to single Window, it's can't render to multi Windows.

The better way is redesign QtQuick scene graphics, like as:


  1.  Add QQuickScene class to instead of a part of functions of QQuickWindow. 
a QQuickItem must be added to a QQuickScene, a QQuickScene is a coordinate 
system.
  2.  Add QQuickViewport class, and allow attach multi QQuickViewport to one 
QQuickScene. the QQuickViewport be responsible for render QQuickItem to target 
output. And allow the QQuickViewport can render in a new thread(be different 
than the other QQuickViewport in same QQuickScene).
  3.  Add QQuickRenderTarget::fromSurface(EGLSurface/VkSurface) functions, and 
using QQuickRenderTarget to QQuickViewport::render(QQuickRenderTarget target).
  4.  The QQuickWindow don't depends on QSG* class, it can wapper 
QQuickViewport and QQuickRenderTarget to render QQuickItem.
  5.  Add QQuickSceneHelper abstract class, The QQuickWindow event dispense to 
QQuickSceneHelper, and QQuickSceneHelper dispense event to QuickItem. Provide 
like as "virtual QQuickSceneHelper::setCursor" functions to instead of 
QQuickWindow::setCursor in QQuickItem::setCursor.
  6.  The QQuickItem without QQuickWindow, using QQuickItem::pixelRatio to 
instead of QQuickWindow::effectiveDevicePixelRatio(), the 
QQuickItem::pixelRatio is only using for load resources(like as 
QQuickImage::load), for the render matrix, using the 
QQuickViewport::devicePixelRatio when rendeing.

The above changes may not change the abi.

If I misunderstand QtWayalnd and QtQuick Scene Graphics, please tell me, thanks.


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

Re: [Development] Does QSGPlainTexture needs call setHasAlphaChannel on Vulkan renderer?

[Eskil Abrahamsen Blomfeldt via Development]

Hi,

If the texture does not have alpha, that means we can do disable blending, do 
front-to-back sorting to minimize overdraw, and use depth-buffer checks to 
preserve stacking. So in the case where you know there is no alpha, this is an 
optimization. If you do not know whether or not there is an alpha, the safe 
choice is to assume that there is an alpha channel. Even if all the alpha 
values are at 100% opacity, the alpha-blending will still give the right 
results, whereas unblended opaque rendering will only be correct if the texture 
is completely opaque.


Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io


Fra: Development  på vegne av JiDe Zhang 

Sendt: onsdag 26. oktober 2022 10:13
Til: Qt邮件列表 
Emne: [Development] Does QSGPlainTexture needs call setHasAlphaChannel on 
Vulkan renderer?

Hi, I am working for wlroots with Qt. In this 
https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3538#note_1604273
  patch, I am exporting some interfaces in wlroots for vulkan, and using it 
with QtQuick, I want to get the has_alpha value of texture, but Simon Ser 
thinks we shouldn't need know has_alpha value of vulkan texture.

If I don't call setHasAlphaChannel for QSGPlainTexture, and if the texture is 
having alpha, then I will see the wrong display effective.

So, Is it a Qt bug? Although I don't think it's a Qt bug, but I can't get has 
alpha of texture from wlroots in vulkan.

How should I do?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Jonas Karlsson as maintainer for Qt Quick 3D Physics (and consequently for approver status)

[Eskil Abrahamsen Blomfeldt]

+1 

Jonas is on my team and has been doing excellent work for the past two years, 
on Qt Quick 3D and more recently on the new physics integration.


Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io


Fra: Development  på vegne av Paul Tvete 

Sendt: torsdag 12. mai 2022 10:12
Til: development@qt-project.org 
Emne: [Development] Nominating Jonas Karlsson as maintainer for Qt Quick 3D 
Physics (and consequently for approver status)

Jonas has been working for the Qt Company since April 2020, and we somehow 
forgot to nominate him for approver status before now. He has been working on 
the Qt Quick 3D module, as part of the Oslo graphics team.

His current project has been to turn Andy Nichols's proof-of-concept physics 
module (based on the Bullet engine) into a proper Qt module (based on Nvidia 
PhysX): Qt Quick 3D Physics 
(https://codereview.qt-project.org/c/qt/qtquick3dphysics/+/410063). This module 
is planned to be released as a tech preview in Qt 6.4. The previous commit 
history can be found on https://git.qt.io/jokarlss/qtquick3dphysics
[https://git.qt.io/assets/gitlab_logo-7ae504fe4f68fdebb3c2034e36621930cd36ea87924c11ff65dbcb8ed50dca58.png]<https://git.qt.io/jokarlss/qtquick3dphysics>
Jonas Karlsson / QtQuick3DPhysics<https://git.qt.io/jokarlss/qtquick3dphysics>
GitLab Community Edition
git.qt.io



I therefore nominate Jonas as maintainer for Qt Quick 3D Physics. According to 
my interpretation of QUIP 2, this implies approver status, but to be on the 
safe side, I also explicitly nominate him as approver.

- Paul

(Not currently maintaining any modules, but since I still have maintainer 
status, I think I am able to nominate a maintainer)
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Requesting repository for Qt Quick 3D Physics

[Eskil Abrahamsen Blomfeldt]

Hi,

We are working on an integration of - and API for using - the PhysX physics 
engine with Qt Quick 3D. We would like to request a qt/ repository for 
including this as a supported Qt module in the future.

Name: Qt Quick 3D Physics
Description: Physics engine integration for Qt Quick 3D
Responsible person: Jonas Karlsson
Content: https://git.qt.io/jokarlss/qtquick3dphysics


Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Kaj Grönholm as approver

[Eskil Abrahamsen Blomfeldt]

+1 from me! Kaj is doing a lot of really excellent work and has been for some 
time :)


Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io


Fra: Development  på vegne av Volker 
Hilsheimer 
Sendt: mandag 12. juli 2021 10:38
Til: development@qt-project.org 
Emne: [Development] Nominating Kaj Grönholm as approver

Hi,


I’d like to nominate Kaj Grönholm as an approver for the Qt Project.

Kaj has been working primarily on Qt 3D Studio and Qt Quick 3D, most recently 
on the particle effects support in Qt 6.

He has authored the following patches:

https://codereview.qt-project.org/q/owner:kaj.gronholm%2540qt.io

and reviewed these:

https://codereview.qt-project.org/q/reviewer:kaj.gronholm%2540qt.io


Cheers,
Volker

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

[Development] Nominating Aleix Pol Gonzalez for approver status

[Eskil Abrahamsen Blomfeldt]

Hi all!



I would like to nominate Aleix Pol Gonzalez as an approver for the Qt Project.



Aleix has been a contributor to KDE and Qt for many years, touching on many 
different areas of Qt, and has lately been actively involved in Qt Wayland to 
help improve its position on the Linux desktop: 
https://codereview.qt-project.org/q/owner:aleixpol%2540kde.org


Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Documenting Qt 6 API breakages

[Eskil Abrahamsen Blomfeldt]

Hi,

FWIW, the page I made just replaced the Qt 4 to Qt 5 porting guide, so I didn't 
put any thought into whether we should change the existing structure. As long 
as they are accessible from a general "porting" document, I think it is a good 
idea to move specifics into their respective modules. That would make it 
possible to do the documentation as part of the change as well, instead of as 
an afterthought.


Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io


Fra: Development  på vegne av Kai Köhne 

Sendt: onsdag 27. mai 2020 16:48
Til: development@qt-project.org 
Emne: [Development] Documenting Qt 6 API breakages

Hi,

We should start documenting the API changes that Qt 6.0 brings soon. This will 
allow getting people getting an overview, help early adopters, and will give us 
time to improve the documentation before the release.

Now I see that there are different paths taken:
- Eskil and others have started listing changes in a page in the qtdoc 
repository, https://doc-snapshots.qt.io/qt6-dev/sourcebreaks.html
- I created a skeleton for Qt Core changes in the qtbase repository: 
https://codereview.qt-project.org/c/qt/qtbase/+/299664 .

I wasn't aware of the existing page in qtdoc; Anyhow, from past experience I 
prefer having the documentation nearby the actual code. I therefore would like 
move the existing sections about Qt Quick, Qt OpenGL to the respective module 
documentation and let https://doc-snapshots.qt.io/qt6-dev/sourcebreaks.html 
just link to the module documentation pages.

Thoughts?

Kai

--
Kai Köhne, Director R | The Qt Company

The Qt Company GmbH, Erich-Thilo-Straße 10, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

[Development] The future of Qt Purchasing in Qt 6

[Eskil Abrahamsen Blomfeldt]

Hi!


Qt Purchasing is a convenience API for handling in-app purchases on different 
platforms. Qt 6 will go through lots of changes that affect many modules. It is 
therefore a good time to reconsider the future of Qt Purchasing API.


One potential pitfall of the API is that apps developed with it could suffer 
from weakened copy protection due to Qt open source nature. For example, 
platforms like Android recommend doing code obfuscation for the app's source 
code [1]. It might be possible to replace the app's package with a custom-built 
Qt Purchasing library and use instead, thus breaking copy protection.


Another challenge we have been facing is with the community contributions. By 
nature, contributions should be cross platform, and if not then at least not 
break the functionality of another target platform. Following this has proven 
to be very difficult thus leading to rejection of many submissions to improve 
Qt Purchasing API. This in turn makes for unhappy contributors, and Qt missing 
the needed feature.


I propose to exclude Qt Purchasing from Qt 6, and instead move the underlying 
use cases forward as examples, which has the following advantages:

· The examples would be easily copy-pasted, improved, obfuscated, and more 
secure.

· They can demonstrate how to use purchasing capabilities for different 
platforms with their native purchasing APIs (e.g. Android, iOS, WinRT).

· They can act as good examples of how Qt users can interact with more advanced 
platform-specific and native APIs that the core Qt doesn't cover.

· Modifications and contributions would be much easier added to an example than 
to a module which has more restriction such as feature-freezes.

· OS-specific features could be added and demonstrated if one feature is 
available in one OS and not the others. Updates related to this are tracked 
under the ticket QTBUG-82847.


References:

[1] 
https://developer.android.com/google/play/billing/billing_library_overview#Verify-purchase-device


Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

[Eskil Abrahamsen Blomfeldt]

On 05.02.2020 13:04, Jani Heikkinen wrote:
>
>> -Original Message-
>> From: Eskil Abrahamsen Blomfeldt 
>> Sent: keskiviikko 5. helmikuuta 2020 13.06
>> To: Edward Welbourne ; Jani Heikkinen
>> ; Lars Knoll ; Volker Hilsheimer
>> 
>> Cc: Qt development mailing list ;
>> releas...@qt-project.org
>> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is
>> in effect now
>>
>>
>> On 05.02.2020 11:50, Edward Welbourne wrote:
>>> Jani Heikkinen (5 February 2020 06:42)
>>>> Why this is so important that we should get the exception & go in after
>> FF?
>>> Do we allow changes approved before feature freeze to get past the
>>> Coin hurdle, even if that happens after FF ?  How much fixing of the
>>> change (if it turns out to have problems integrating) is acceptable,
>>> before we declare that it's no longer the change that was approved in time
>> ?
>>
>>
>> If the change is ready and approved by the time of feature freeze and only
>> delayed by CI problems, failures from other changes in a batch, or the
>> awkwardness of our dependency structure, I think it has to be acceptable to
>> merge after the freeze. Otherwise feature freeze becomes a lottery where
>> the features in a given release is based mostly on chance.
> By default we shouldn't put any new features in after FF, not even those 
> which were approved early enough. Not respecting the freeze date was one of 
> biggest reasons why we failed to keep the release schedule with earlier 
> releases. And after we started to be much tighter with the freeze we have 
> been much better to keep the schedules as well...

Hi,

You are looking at this from a very different perspective than me, which 
is totally understandable.

As a developer of the product, I want a deadline for when I should have 
my feature finished. If the deadline is "maybe one month before the 
feature freeze, maybe one week, who knows it kind of depends on whether 
the CI system is acting up and what other changes your fix happens to be 
bundled with", then that makes it impossible to plan anything.

If we estimate, based on statistics, that it will take one month to get 
features in, then we should set the feature freeze one month earlier. If 
we think it will take one week, then we should set it one week earlier. 
At least we should give people a specific date and guarantee that if 
they make it in time for this, their change will be in the next release. 
If this is one month before the actual feature freeze, then so be it. If 
it takes that long to get a change in, then definitely should be very 
visible to everyone, including the stake-holders who depend on features 
being released when we say.

If it turns out that we miscalculated the estimate, then this should 
just cause a delay to the release. It shouldn't cause us to make a 
release containing a random set of features based on whoever won the 
lottery this time.

I understand that your responsibility is making the release on time, and 
late submissions make this difficult, but the way to solve this is to 
add the extra slack between the feature freeze and the point where we 
can start stabilizing to the release schedule. If we see that changes 
that are staged at the freeze date consistently take between 1 day and 1 
week to merge because we have broken systems or because so many people 
stage their changes at the same time, then that means we have to extend 
the period between freeze and release by one week.


> We are doing time based releases so if new feature misses the deadline 
> there will be next one coming after few months. It might be quite long 
> time for unique feature but on the other hand it isn't really that 
> long... Our goal is to cut the schedule between FF and final release, 
> not reserving more time there. Ok, currently there is of course some 
> buffer in; Release plans are based on previous releases and realized 
> schedules there. But we should be able to develop our ways of working 
> & our release systems so that we can make that time much shorter. That 
> way we could get more time to develop new features. 

The next one will be coming after six months in most cases (Qt 5.15 is 
special of course). This is a pretty long time. But more importantly, 
expecting every single developer in the Qt community to internalize the 
flakiness of the CI system or the risk that your change may be rejected 
because it happened to be bundled with a broken change is the wrong 
angle in my opinion. We would just be distributing the responsibility of 
analyzing our release systems to hundreds of people instead of doing it 
once, as part of the release planning.

So if you know how long it will typically take for a change to get in, 
then why 

Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

[Eskil Abrahamsen Blomfeldt]

On 05.02.2020 11:50, Edward Welbourne wrote:
> Jani Heikkinen (5 February 2020 06:42)
>> Why this is so important that we should get the exception & go in after FF?
> Do we allow changes approved before feature freeze to get past the Coin
> hurdle, even if that happens after FF ?  How much fixing of the change
> (if it turns out to have problems integrating) is acceptable, before we
> declare that it's no longer the change that was approved in time ?


If the change is ready and approved by the time of feature freeze and 
only delayed by CI problems, failures from other changes in a batch, or 
the awkwardness of our dependency structure, I think it has to be 
acceptable to merge after the freeze. Otherwise feature freeze becomes a 
lottery where the features in a given release is based mostly on chance. 
The slack to accommodate these intrinsic delays need to be in the 
release plan in my opinion, and not in each developer's individual plan 
for merging their changes.

If it turns out the change cannot be merged as-is and needs additional 
fixing, I think it should be addressed as any other change that doesn't 
match the conditions above: on a case-by-case basis, considering value 
vs. risk in each case.

In the particular case you mention, I think we should fix the issues 
with the feature in 5.15 rather than revert it. The reason we have 
several months between freeze and release is so that we have time for 
stabilization work such as this.

-- 
Eskil Abrahamsen Blomfeldt
Senior Manager, Graphics

The Qt Company
Sandakerveien 116
0484, Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
+47 938 85 836
http://qt.io
https://twitter.com/eskilblomfeldt

The Future is Written with Qt

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

[Development] Nominating Rebecca Worledge for maintainer of Qt Lottie

[Eskil Abrahamsen Blomfeldt]

Hi!

In Qt 5.13 we have added a Qt.labs module called "Qt Lottie", with Qt 
Quick APIs for showing scenes and animations that were exported using 
the Bodymovin plugin in After Effects.

     https://codereview.qt-project.org/qt/qtlottie

Rebecca Worledge has graciously offered to adopt the maintainership of 
this module. She has worked for Qt for eight years in our Professional 
Services organization, providing invaluable work for our customers as 
well as researching and developing internal prototypes, but this would 
be her first maintainership in the Qt Project.

Thanks, Rebecca!

-- 
Eskil Abrahamsen Blomfeldt
Senior Manager, R

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

The Future is Written with Qt
www.qtworldsummit.com

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

Re: [Development] Qt Multimedia maintainer change

[Eskil Abrahamsen Blomfeldt]

Den 07.02.2019 14:23, skrev Yoann Lopes:
Hi,

As most people have probably noticed, I haven’t been active on Qt Multimedia 
for quite some time now.

Valentyn Doroshchuk should be the new maintainer, as he’s been the one putting 
most effort into the module for the past couple of years.


+1 from me :)

Val has been doing a lot of great work on Qt Multimedia.

--

Eskil Abrahamsen Blomfeldt
Senior Manager, R

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io<mailto:eskil.abrahamsen-blomfe...@qt.io>
http://qt.io

The Future is Written with Qt
www.qtworldsummit.com<http://www.qtworldsummit.com>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Deploy Qt unit testing in Android

[Eskil Abrahamsen Blomfeldt]

Den 15.09.2018 19:06, skrev Francesc Martinez:

Hi all,

During the last two weeks I've been trying to run a Qt unit testing 
project in Android. I've tried to create an apk file via Qt Creator 
and by hand but as it didn't give me any result I also tried to build 
it manually using Android Studio and the build.gradle. No results so far.


Hi!

I have frequently run the Qt unit tests on Android by just hitting the 
run button in Qt Creator. You could look at those for inspiration perhaps?


--
Eskil Abrahamsen Blomfeldt
Senior Manager, R

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

The Future is Written with Qt
www.qtworldsummit.com

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

Re: [Development] Stepping down as maintainer

[Eskil Abrahamsen Blomfeldt]

Den 19.03.2018 13:39, skrev Gunnar Sletta:

Hi,

After quite some time of not being active in Qt, I am now formally stepping 
down as maintainer. It has been a great ride, but I simply don't have time to 
follow up Gui and Scene Graph and it makes sense that the people who are active 
in these areas also become the go-to guys.

I've already spoken with Eskil and Lars, and propose the following list of 
people to formally take over my areas:

Tor Arne Vestby - QPA and window system integration
Laszlo Agocs - OpenGL/Vulkan
Eirik Aavitsland - Image Formats and QPainter
Andy Nichols - Scene Graph

(Other specific maintainers in QtGui stay unchanged)


As Gunnar mentioned, all the nominations have a +1 from me :)

Note that Paul Olav Tvete is actually the current maintainer of QPA, but 
when reorganizing we though it made sense to put it together with the 
"windowing system bits".


--
Eskil Abrahamsen Blomfeldt
Senior Manager, R

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

The Future is Written with Qt
www.qtworldsummit.com

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

Re: [Development] Nominating Valentyn Doroshchuk for Approver status

[Eskil Abrahamsen Blomfeldt]

Den 20.03.2018 13:55, skrev Christian Strømme:

Hi,

I'd like to nominate Valentyn Doroshchuk for Approver status. Val has been 
working full time for The Qt Company since mid 2017, and has and has actively 
been fixing and improving QtMultimedia since (which includes upstream fixes to 
GStreamer).

This is his dashboard:
https://codereview.qt-project.org/#/q/owner:%22VaL+Doroshchuk%22+status:merged,n,z


Hi,

+1 from me!

Val is doing great work on Qt Multimedia and is currently one of the 
main contributor to this module. :)


--
Eskil Abrahamsen Blomfeldt
Senior Manager, R

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

The Future is Written with Qt
www.qtworldsummit.com

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

Re: [Development] Stepping down as maintainer

[Eskil Abrahamsen Blomfeldt]

Den 20.03.2018 10:32, skrev Alex Blasche:

-Original Message-
From: Development [mailto:development-
bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Gunnar Sletta
Sent: Monday, 19 March 2018 13:40

...


I've already spoken with Eskil and Lars, and propose the following list of 
people
to formally take over my areas:

Tor Arne Vestby - QPA and window system integration
Laszlo Agocs - OpenGL/Vulkan
Eirik Aavitsland - Image Formats and QPainter
Andy Nichols - Scene Graph

We have a couple of QTBUG components for which Gunnar is default assignee. 
Would the following reallocation reflect the above agreements?

GUI: Basic Input System (keyboard, mouse, touch) -> Tor Arne
GUI: Graphics Performance -> Laszlo
GUI: OpenGL -> Laszlo
GUI: Painting -> Erik
QtQuick: Graphical Effects -> Laszlo
QtQuick: Scenegraph -> Andy Nicols


Hi,

QtQuick: Graphical Effects can be assigned to Graphics Team in Qt if no 
other candidate steps up. It currently has no maintainer in the official 
list, so we didn't actually discuss it yet, but in practice, there has 
been very little activity in that repository and I have usually been 
handling meta-stuff like the changelog.


It would be great to have a dedicated maintainer for it, in my opinion, 
but if no one volunteers, I can take it for now.


--
Eskil Abrahamsen Blomfeldt
Senior Manager, R

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

The Future is Written with Qt
www.qtworldsummit.com

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

[Development] Branch request: wip/webassembly in Qt Declarative

[Eskil Abrahamsen Blomfeldt]

Hi,

We currently have a WIP branch in Qt Base for the WebAssembly work, but 
it turns out that we will also need changes in Qt Declarative that 
significant enough that it would be good to keep them in a WIP branch 
until we merge the feature back.


No CI needed.

--
Eskil Abrahamsen Blomfeldt
Senior Manager, R

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

The Future is Written with Qt
www.qtworldsummit.com

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

[Development] Branch request: wip/webassembly in Qt Base

[Eskil Abrahamsen Blomfeldt]

Hi,

I would like to request a WIP branch in Qt Base: wip/webassembly

Purpose is for the development of Qt for WebAssembly 
(http://webassembly.org)


No CI is needed for this.

--
Eskil Abrahamsen Blomfeldt
Senior Manager, R

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

The Future is Written with Qt
www.qtworldsummit.com

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

Re: [Development] New repository for WebGL Streaming QPA plugin

[Eskil Abrahamsen Blomfeldt]

Den 05.04.2017 17:18, skrev Laszlo Agocs:


Hi,

To clarify, would a qt-labs repo work? As I understand the code still 
needs maturization. It can eventually be graduated to a proper Qt 
module later on. (this also means the repo would not be CI controlled 
for now, but I suspect that’s fine)


It is a bit unfortunate that the platform plugin cannot be part of 
qtbase, but it involves a WebSockets dependency and some additional 
tooling so there’s not much choice left.




Hi,

As you say, this would have just been put in Qt Base if it weren't for 
some meta-issues that are unrelated to the size of the feature or 
quality of it, so it makes no sense going via a qt-labs repository in my 
opinion. It is just a QPA plugin and mature enough that the code is 
currently in production in large-scale commercial projects, so I vote to 
put it in qt/.


If it turns out that stabilization is needed, there is still time to do 
that, but I think the plugin is as ready for review in Qt as any other 
feature we regularly commit.


--
Eskil Abrahamsen Blomfeldt
Senior Manager, R

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

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

Re: [Development] A new approach for Qt main()

[Eskil Abrahamsen Blomfeldt]

Den 09.12.2016 12:40, skrev Tor Arne Vestbø:

On 09/12/2016 11:44, Lars Knoll wrote:

Well, the problem is that the main() entry point is causing huge amounts
of issues on at least Android and iOS.


I don't know about Android, but on iOS this is patently false. While 
the workaround is complex, it has worked very well in the 3 years 
since its inception. Please don't use iOS as a straw-man in this 
discussion.


Speaking for Android, there are and have been thread synchronization 
issues due to Qt running a synchronous event loop in the main function. 
It is also impossible to make applications with multiple entry points 
and complex life cycles, which you would expect in an Android 
application consisting of several activities and services that can be 
triggered independently and simultaenously. Our work-around for this is 
to limit support to applications with one activity or one service per 
process in the application.


So while we have been able to find solutions for most our problems, both 
on Android and iOS, I guess Lars' point is that we are encountering more 
and more cases where we have to invent hacks and work-arounds and 
document limitations in order to be functional on modern platforms. It 
might be a sign that we should adapt.


--
Eskil Abrahamsen Blomfeldt
Senior Manager, R

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

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

Re: [Development] Nominating Paolo Angelelli for Approver status

[Eskil Abrahamsen Blomfeldt]

Den 26.08.2016 10:17, skrev Alexander Blasche:

Hi,

I'd like to nominate Paolo Angelelli for Approver status. He joined The Qt 
Company at the end of 2015, and has been working full time on Qt since. Paolo 
has been actively involved fixing and improving QtPositioning and QtLocation.


+1

Paolo has been and is doing great work on Qt Location :)

--
Eskil Abrahamsen Blomfeldt
Senior Manager, R

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

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

Re: [Development] Nominating Johan Helsing for Approver status

[Eskil Abrahamsen Blomfeldt]

Den 04.08.2016 12:22, skrev 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.


+1

--
Eskil Abrahamsen Blomfeldt
Senior Manager, R

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

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

Re: [Development] commas in ctor-init-lists

[Eskil Abrahamsen-Blomfeldt]

+1 from me as well.

The argument about natural language makes no sense to me;
Nothing in C++ resembles natural grammar, nor should it;
It might take some getting used to,
like any change in style,
but after a while you won't think it is ugly anymore,
and then we can reap the benefits of it being objectively superior
because it minimizes diffs in initializer lists. :)

--
Eskil Abrahamsen Blomfeldt
Senior Manager, Qt Graphics/Multimedia
The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io<mailto:eskil.abrahamsen-blomfe...@qt.io>
http://qt.io<http://qt.io/>

From: Development 
<development-bounces+eskil.abrahamsen-blomfeldt=qt...@qt-project.org<mailto:development-bounces+eskil.abrahamsen-blomfeldt=qt...@qt-project.org>>
 on behalf of Simon Hausmann <simon.hausm...@qt.io<mailto:simon.hausm...@qt.io>>
Date: Wednesday 1 June 2016 at 14:56
To: Marc Mutz <marc.m...@kdab.com<mailto:marc.m...@kdab.com>>, 
"development@qt-project.org<mailto:development@qt-project.org>" 
<development@qt-project.org<mailto:development@qt-project.org>>
Subject: Re: [Development] commas in ctor-init-lists

Hi,

I'm in favorof changing our coding style to adopt the model you call "butt 
ugly" because I find it more appealing and I find that it makes diffs easier to 
read.

Simon



From: Marc Mutz <marc.m...@kdab.com<mailto:marc.m...@kdab.com>>
Sent: Jun 1, 2016 14:41
To: development@qt-project.org<mailto:development@qt-project.org>
Subject: [Development] commas in ctor-init-lists

Hi,

There seems to have been a silent underground move to uglify the Qt sources
, by using commas to introduce lines
. I have no idea where this came from
, but it looks butt
-ugly and it is in violation of http
://wiki
.qt
.io
/Qt_Coding_Style

QFoo::QFoo()
  : QBase(),
m_f1(),
m_f2()
{

}

-not-

QFoo::QFoo()
  : QBase()
  , m_f1()
  , m_f2()
{

}

(http://wiki.qt.io/Qt_Coding_Style#Line_breaks 2nd item: "Commas go at the
_end_ of wrapped lines")

Thanks,
Marc

--
Marc Mutz <marc.m...@kdab.com<mailto:marc.m...@kdab.com>> | Senior Software 
Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org<mailto: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

Re: [Development] Is Qt able to render emoji font using the SVGinOT ?

[Eskil Abrahamsen Blomfeldt]

Den 12.05.2016 23:08, skrev Gianluca:


Hello,
I’m wondering if Qt is able to render the coloured emoji font that use the 
SVGinOT (https://www.w3.org/2013/10/SVG_in_OpenType/) extension.


Hi,

No, none of the font backends we use support them. The only support for 
it that I have heard of is in Firefox, though some Adobe applications 
probably support it as well.


Qt 5.7.0 does support the Google format (CBDT/CBLC) on Android and 
Linux, the Apple format (SBIX) on iOS and OSX, and the Microsoft format 
(COLR/CPAL) on Windows.


--
Eskil Abrahamsen Blomfeldt
Senior Manager, Qt Graphics/Multimedia

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

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

Re: [Development] CI failures

[Eskil Abrahamsen Blomfeldt]

Den 23.04.2016 13:11, skrev Simon Hausmann:

Hi,

Usually the CI system won't rebuild depending modules, but in this case no 
builds exist of qtbase. That is because MinGW 5.3 was added to the CI system - 
replacing MinGW 4.9 - maybe yesterday (I'm not sure exactly when) and qtbase 
doesn't compile with it.

I'll try to get access to a laptop and see if I can revert the changes.


Hi,

MinGW 5.3 apparently includes some of the Directwrite 2 APIs, but not 
all, so my configure test would pass, but then the actual code would 
fail to compile. Friedemann has a patch here which fixes it:


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

--
Eskil Abrahamsen Blomfeldt
Senior Manager, Qt Graphics/Multimedia

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

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

Re: [Development] QtQuick Call for Maintainer

[Eskil Abrahamsen Blomfeldt]

Den 09.03.2016 10:56, skrev Frederik Gladhorn:

We are in the luxury position of having two great candidates.
I briefly talked to both Robin and Shawn yesterday and one option would be to
have a shared maintainership. This seems to have worked nicely for Qt
Networking and dividing the responsibilty will lessen the burden.


+1 for shared maintainership.

-- Eskil

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

Re: [Development] 5.7 feature freeze

[Eskil Abrahamsen Blomfeldt]

Den 26.02.2016 20:07, skrev Nurmi J-P:

Hi Lars,


On 27. jan. 2016, at 09.30, Knoll Lars  wrote:

If anybody else has a feature he believes absolutely has to make it to 5.7, get 
it done until Monday or talk to me :)

I would like to ask for an exception for text selection handles. It's a crucial 
feature to make the new editor controls usable on mobile and embedded. There's 
a task for qtquickcontrols2 (https://bugreports.qt.io/browse/QTBUG-51010), but 
the groundwork needs to be done in qtbase and qtdeclarative.

I'm aware of the following WIP patches:
- qtbase: Add support for ImhAnchorRectangle: 
https://codereview.qt-project.org/#/c/142132/
- qtbase: Android selection handles: 
https://codereview.qt-project.org/#/c/142466/
- qtdeclarative: WIP: Add support for input method selection handles: 
https://codereview.qt-project.org/#/c/142133/

I would imagine that we may need some new API in such areas as QInputMethod, 
Qt::InputMethodHint, and QStyleHints. Would it be acceptable to finish off this 
work in the 5.7 branch?


+1 from me.

-- Eskil

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

Re: [Development] Playground request: qtmirserver

[Eskil Abrahamsen Blomfeldt]

On 08/10/2015 11:01 AM, Paul Olav Tvete wrote:
 Hi,

 I would like to propose a new playground repository for upstreaming the QtMir
 project from Canonical:

 https://code.launchpad.net/~mir-team/qtmir/trunk

 I propose the name qtmirserver, since it is more descriptive than qtmir.
 The name qtmirextras should be reserved for platform specific functionality
 needed by client applications running on  Mir.

+1

-- Eskil

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

Re: [Development] Qt Purchasing in Qt 5.6

[Eskil Abrahamsen Blomfeldt]

On 08/04/2015 04:12 PM, Thiago Macieira wrote:
 On Tuesday 04 August 2015 10:43:35 Eskil Abrahamsen Blomfeldt wrote:
 Hi,

 Qt Purchasing is a commercial add-on module developed by The Qt Company
 which implements a cross-platform API for in-app purchases on iOS and
 Android. In order to make it easier for third parties to contribute new
 backends for the API, we want to release it in the Qt Project under
 LGPLv3/GPLv2/Commercial. I propose to include it as part of Qt 5.6.0.
 Do we have the time to add it a new module and review it in one week?

It's not huge and all changes have been through peer reviews already (by 
approvers in the Qt Project). The module has also been in active use for 
a while. My plan was to upload the whole history including the peer 
reviews (mostly done by Andy Nichols and me).

How do we handle reviews beyond that? Should I make a patch to qt5.git 
and collect comments there, or would it be better if I make a mock 
change that includes the entire code base so that we can get inline 
comments? I'm not sure how this has usually been done before.

I'll try getting it up somewhere today at least, and we can at least try 
to get it in time for Qt 5.6.

-- Eskil


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

Re: [Development] Qt Purchasing in Qt 5.6

[Eskil Abrahamsen Blomfeldt]

On 08/05/2015 09:31 AM, Knoll Lars wrote:

 Well, let’s create the repository today and import the codebase so
 everybody can have a look.

Done!

The code is now in 
https://codereview.qt-project.org/#/admin/projects/qt/qtpurchasing

I'll make a patch for qt5.git as well and collect comments on that.

-- Eskil

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

Re: [Development] Qt Purchasing in Qt 5.6

[Eskil Abrahamsen Blomfeldt]

On 08/05/2015 01:08 PM, Marc Mutz wrote:
 On Wednesday 05 August 2015 09:59:52 Oswald Buddenhagen wrote:
 How do we handle reviews beyond that? Should I make a patch to qt5.git
 and collect comments there, or would it be better if I make a mock
 change that includes the entire code base so that we can get inline
 comments? I'm not sure how this has usually been done before.


 don't make it too meta.
 what exactly you want people to review at which granularity level?
 If you already have exsiting customers, what guarantees have you given them re
 BC and SC? IoW: are we supposed to review API as well as implementation?

I really hope we can keep source compatibility and use deprecation, etc. 
if there is a need for changes to the API. Otherwise it will likely mean 
increasing the version number of the public version and 
maintaining/supporting two separate ones for us, which of course will 
eat into the time we have for other stuff.

Binary compatibility should not really be an issue on Android or iOS, 
since the libraries are always bundled in the former case and statically 
linked in the latter. Someone correct me if I'm wrong :)

-- Eskil

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

[Development] Qt Purchasing in Qt 5.6

[Eskil Abrahamsen Blomfeldt]

Hi,

Qt Purchasing is a commercial add-on module developed by The Qt Company 
which implements a cross-platform API for in-app purchases on iOS and 
Android. In order to make it easier for third parties to contribute new 
backends for the API, we want to release it in the Qt Project under 
LGPLv3/GPLv2/Commercial. I propose to include it as part of Qt 5.6.0.

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

Re: [Development] New Qt5.2 snapshot available

[Eskil Abrahamsen Blomfeldt]

On 11/12/2013 12:13 PM, Paul Olav Tvete wrote:
 On Monday 11 November 2013 17:19:43 Guido Seifert wrote:
 It's a feature. :) To reduce the size of the package, we only deploy the
 libraries that we know are necessary. Adding QT += svg to the .pro file
 of your application should enable support for svg files.
 It does not. But it is a known bug. Already reported. QT += svg is NOT
 sufficient. Currently it must be QT += svg xml.
 Which version of Qt is this? It works for me with QT += svg only, with the
 latest dev branch.

Fixed by this: https://codereview.qt-project.org/#change,70698

So it's been working for several days already ;)

-- Eskil

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

Re: [Development] Weird offseting in QDataStream

[Eskil Abrahamsen Blomfeldt]

On 11/08/2013 11:03 AM, André Somers wrote:
 Olivier Goffart schreef op 8-11-2013 10:57:
 On Friday 08 November 2013 10:42:16 Yves Bailly wrote:

 I can understand this for high-level Qt objects, but what about lower-level
 data? Does this mean I can't use QDataStream to read a file written by
 some other program, and/or can't use it to *write* a file which could be
 read back by some other program? Again, only using low-level data, ints,
 floats, and so on.

 If that is true, then it's a huge step backward in the ease of use provided
 by Qt in the realm of reading/writing binary files.

 Just to give a context, the goal here is to read and write binary
 STL (stereolithography) or PLY files. I have old Qt3 code which works like a
 charm, reading and writing files usable to and from other soft (e.g.
 Blender). Now moving that old code to Qt5 it seems to not work as expected,
 despite using only basic, low-level data types.
 You can use

 stream.setVersion(QDataStream::Qt_3_3);

 To get back to the Qt3 behaviour.

 Else, yes, you will have to change the floating point precision before every
 call.  It was changed in Qt 4.6 for compatibility with  qreal  that can be
 float or double depending on the platform.
 Perhaps one could add a QDataStream::FloatingPointPrecision::AutoPrecision,
 that would not be a bad idea.

 What would that mode do, exactly? Isn't the whole point that qreal may
 be defined as float or double, and thus you don't know how it will be
 stored in QDataStream? You cannot detect which meaning of qreal was used
 when the file was written... Or do you mean that it should be something
 like MixedPrecision or TypePrecision that would always use 4 bytes for
 float and 8 for double again (and wreck havoc if you try to use qReal
 for reading or writing)? That indeed would be good, I think. I think
 it's a bit weird that in order to support streaming qreal, you basicaly
 stop supporting reading and writing floats or doubles.

QDataStream supports reading and writing floats and doubles, but it 
might use more bytes than necessary to represent them in the stream.

The main use case of QDataStream is to serialize Qt data in a portable, 
binary form with the convenience that the code used to write and read 
the file are inverses of each other. One objective is that you get 
predictable results when moving your existing code and data to new 
platforms, and this was not at all the case before we standardized on a 
floating point precision for all floating point values in QDataStream 
for Qt 4.6. (For the same reason, QDataStream also assumes a particular 
endianness of the input data, and this also might have to be overridden 
manually if you want to read data that is not written by QDataStream.)

It's pretty easy to read four bytes from a QIODevice if you do not worry 
about portability.

Personally, having MixedPrecision/AutoPrecision seems unnecessary, since 
you would still have to be aware of the issue before you can make the 
decision to set this mode, and once you are aware of the issue, you can 
use setFloatingPointPrecision() to achieve the results you want and your 
code will still be cross-platform.

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

Re: [Development] androiddeployqt - how it works or should work?

[Eskil Abrahamsen Blomfeldt]

On 11/04/2013 02:34 PM, Felipe Crochik wrote:

Eskil,
Thank you. You literally answered all my questions... but I have more ;)

I included the QT += network sql to my project file and on further 
inspection of the compile output it seems that the way it works is 
that it will include any plugins that has all the dependencies match. 
Is that how it works now?


Yep.

I saw Appending dependency from xml:. What is this xml in this 
case? Is the libs.xml android\res\values the input or output of 
this process? If it is the output, what is the input?


This is just an implementation detail.

There are some libraries which are only dependencies of the plugin and 
not the module, e.g. the libQtQuickParticles.so library. Since it's not 
possible to make this a direct dependency of your application by editing 
the QT variable, it's added to an XML file which lists it as an extra 
dependency of QtQuick, so that if you do QT += quick in your .pro file, 
then that library will be bundled on Android as a dependency as well, 
and the particles plugin will be resolved as supported by androiddeployqt.




I am sure that it is already in the plans (or if not for some good 
reason) but just in case: it would be very helpful if we could have 
the androiddeployqt or qtcreator detect the required dependencies 
based on the import statements on the qml and automatically include 
them or at least spit a building error. I know it can't be 100% 
effective since it probably won't be able to detect exactly what qml 
files are being used and you can also have some embedded code stored 
as strings used to create components on the fly that probably would be 
very hard to find/parse but it would cover the most common cases.


As I mentioned, this is the plan, yes :) We have the qmlimportscanner 
now, which can be used to find which imports are actually used by your 
application. The plan is to use that to find out which imports are 
required. The dependencies of these can then be included automatically. 
There are bigger fish to fry at the moment, though, so I don't know 
exactly when we'll have time to implement this optimization.


For regular plugins (like image formats etc.) however, we cannot do 
this, since it's impossible to detect which plugins will be used. So for 
plugins, we'll keep the current mechanism of detecting them based on 
their dependencies.


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

Re: [Development] Qt 5.2 Beta - is it really much slower to parse qml/javascript on android?

[Eskil Abrahamsen Blomfeldt]

On 10/30/2013 09:09 AM, BogDan wrote:
 Hi,

 Android's assets are indeed slower (~2X) than Qt's resource system,
 but not that slow ! :)

 From our experience the Android assets system is *extremely* slow for 
listing large file sets. It's bad to the degree that I suspect it has 
exponential complexity. We're talking actual *minutes* to list a large 
file set (I don't remember the actual count, but it was an actual 
application, not a constructed benchmark.) Note that Qt was not included 
in this test, so the slowness was entirely in the Android APIs.

This is a known issue in the Android community, and the work-around is 
to always bundle a file list for the assets and use that instead of the 
Android APIs. We can easily generate this list in our deployment tool, 
so I'm hoping I have time to fix it for Qt 5.2. Otherwise it should be 
done for Qt 5.2.1.


 If I recall correctly in the beginning of this thread Kai said that using
 Necessitas SDK it was ok, and I don't think he is using another technique
   to store the qml files than he is using for Necessitas. Also the assets
 implementation should be pretty much the same ... unless me (or someone else)
 screw the implementation in Qt 5.2 :).

This could be due to changes in QML. If QtQuick 2 is doing more lookups 
in the file system it would be very visible in assets loading.

The easiest way to find out is to move the assets into qrc. We've done 
this for other cases and it usually fixes the problem. If it doesn't, 
then we need to look elsewhere.

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

Re: [Development] WebView for Android on track for Qt 5.2?

[Eskil Abrahamsen Blomfeldt]

On 09/05/2013 06:18 PM, Cornelius Hald wrote:
 Hi guys,

 what is the state of WebView (QQ2) for Android? Is it still planed for
 Qt 5.2? Is there a branch to track somewhere? The bug report suggests
 that instead of using QtWebKit a wrapper around the Android-WebView is
 now planned.

 https://bugreports.qt-project.org/browse/QTBUG-32093

 Anything I could help you with?

Hi,

I've talked to the team working on the web engine in Qt in Digia, and 
right now there are no resources to do work on this in Digia 
unfortunately. It might be possible to do something specifically for 
Android, but it would be a lot nicer to have a cross-platform solution 
like the web engine guys initially planned, and I think this is needed 
for iOS as well. I'll talk to the iOS team here, but I don't think it 
sounds feasible that this will be done in the one and a half weeks we 
have left before the Qt 5.2 feature freeze. Sorry :(

-- Eskil

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

Re: [Development] [IMPORTANT] your commits in stable branch perhaps lost after dev branch merged

[Eskil Abrahamsen Blomfeldt]

On 03/21/2013 05:12 PM, Qi Liang wrote:
 Let's be more clear: no commits were lost. They are all still present.

 However, due to conflicts, some changes may have been improperly resolved. 
 This
 is no different than any other merge, in any direction.
 Yes, it's lost because of conflict resolve. And we recorded the conflicts 
 information in merge commit, that's better than before, the merge commits in 
 Qt 4.

This is also a good reason to make an effort to add unit tests that 
verify your fix, however banal they might be, because there's a much 
smaller chance that the unit test will disappear in the merge than the 
bug fix.

-- Eskil

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

Re: [Development] Android: Merge or no merge?

[Eskil Abrahamsen Blomfeldt]

On 02/21/2013 02:16 PM, Oswald Buddenhagen wrote:
 and I fear it will jeopardize our chances of meeting the Qt 5.1
 deadline.

 ah, yeah, there it is: we have a deadline to meet. let's ignore good
 practice!

Yes, of course it is a trade-off. In this case, the negative effects of 
having a code drop with some amendments is outweighed by the positive 
effects of having usable SHA1s in Jira and of being able to focus the 
time of developers on more important issues.

This does not mean that we would accept any compromise thinkable, but in 
this case either solution is a compromise. One favours time and history 
over cleanliness, while the other favours cleanliness.

As far as I can gather from the attention this discussion is getting, 
having the code drop with amendments in the Android-specific parts of 
the code is not unacceptable to anyone but you, while having the history 
intact and work load focused is viewed as valuable by the people who are 
working on this.

The history provides documentation of what has happened to the code, 
also of the mistakes that are made. The history in this case also 
documents why the code differs from the Necessitas project, which might 
also be useful to some people.

As we've said earlier, we're hoping to do the merge this week, which 
means tomorrow. With the comments in this thread so far, I don't see any 
justification to delay it.

-- Eskil


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

Re: [Development] Android: Merge or no merge?

[Eskil Abrahamsen Blomfeldt]

On 02/21/2013 04:54 PM, Oswald Buddenhagen wrote:
 i'll simply block the merge, and i don't even need to resort to my pet 
 process reasons for that. 

Ok, we will delay the merge/rebase until Lars is back and can resolve 
this conflict.

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

[Development] Android: Merge or no merge?

[Eskil Abrahamsen Blomfeldt]

Hi,

We have a disagreement on how to integrate the Android port into Qt 
which we need to get resolved.

Here's the discussion:

 https://codereview.qt-project.org/#change,47480

tl;dr: Should we merge or rebase the Android branch when integrating it 
into Qt mainline?

The main issue originates from the fact that Necessitas was integrated 
as one large, atomic commit.

Our plan to minimize the effect of this was to

1. Create separate patches for the non-Android-specific parts of that 
change, and commit these separately to dev ahead of time. (In progress)
2. Collect feedback on the total diff of the branch using Paul's large 
squashed commit and fix the issues as they are brought up. (In progress)
3. Do a merge which retains the blame-history of the changes that were 
already committed to dev, so that the only parts which will show up as 
the large initial commit in a git blame are the lines which are 
Android-specific and which have not been disputed and therefore altered.

This way we keep the SHA1s which are already linked to tasks in Jira and 
we have the full history of the Android port at least back to the point 
where Necessitas was integrated in Qt 5 (kind of like the initial Qt 5 
commit, but for the Android port.)

However, there was some disagreement about whether this was acceptable 
or whether the branch should be rebased on top of dev instead.

The problems:

1. The initial commit does not have a review-stamp. The only way to get 
around this would be to rebase and rewrite the commit to include my 
review, or to post the commit itself to dev ahead of time and then merge 
on top of that, which would break the rule of only committing finished 
features.
2. There is clutter in the commit log, i.e. changes that change code 
style and whitespace errors.

In my opinion, the amount of history we submit seems like a luxury 
problem. I would very much like to be able to track the development of 
the Android branch after merging it, so in my opinion having the history 
intact is nice, even if they are not interesting to everyone. One of the 
major history-based problems in the Qt 4 days was that we would squash 
together commits from topic branches and lose the history in those branches.

Squashing the clutter commits and rewriting the entire history is a 
lot of work, and I fear it will jeopardize our chances of meeting the Qt 
5.1 deadline. Since it only serves to remove information and history and 
would take up too much valuable time, it does not seem justifiable to 
me. Since we did get reviews for all changes except the initial one, the 
idea was that we would not have to do this kind of history rewrite later.

A compromise would be to rebase on top of dev, review the initial 
commit, and then rebase the rest of the branch on top of this. This 
would break the references in Jira tasks, though, so personally I'd 
prefer not to do this. I also wonder how it's achieved technically, 
since most of the changes have been reviewed already and therefore do 
not need additional reviews, but I'm sure this is not a huge problem.

So what do you think?

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

Re: [Development] Reviews needed before android integration in two weeks

[Eskil Abrahamsen Blomfeldt]

Thanks for the comments. I'll convert them all into tasks or add them as 
comments in Gerrit if the patches in question are already in there.


On 02/06/2013 03:04 AM, Thiago Macieira wrote:

 -2 on the -openssl-source option. It's not used anywhere. 


Yes, that's a left-over. I'll remove it.

 A   lib/rules.xml
 I'd rather you found a better place for this file.

I was planning on putting it into src/android and having it deployed 
into lib/rules.xml when you build for Android.

Would that be acceptable? I'd like to deploy it in lib/ because then the 
Qt Creator plugin doesn't need to look in two different places for the 
file for Qt 4 and Qt 5 builds.


 .
 A   mkspecs/features/java.prf
 Ossi to judge if the mkpath should be there.

Ossi wrote the code ;)


 javac.depends looks like a horrible hack. In fact, while this is a nice
 feature, the whole file looks like a hack. qmake should be modified to learn 
 how
 to compile Java instead.

I disagree. The fewer hardcoded things we have in qmake, the better in 
my opinion. I do agree that the LINK override is hacky, but at least 
it's a working solution with the current system and the cleanest we 
could think of. If qmake is changed later to add a less hacky way to 
override the different compile steps, I'll be glad to adapt to it, but 
for now, I'd like to keep this build system and focus on more pressing 
things before the feature freeze :)

 . Also, doesn't qpa/android.prf conflict with android.prf? 

I don't know. I haven't seen any issues. But I don't know if 
qpa/android.prf is actually used for anything.

 A   src/android/...
 I suggest the dir be renamed to src/androidmain, to match winmain and the old
 (and thankfully removed) s60main.

Ok, sounds good to me.


 M   src/corelib/kernel/qeventdispatcher_unix.cpp
 M   src/corelib/kernel/qeventdispatcher_unix_p.h
 This one needs a very good explanation.

Would you mind discussing this with Bogdan on

 https://codereview.qt-project.org/#change,46798

Apparently it was needed to fix a deadlock in the event loop on Android. 
It was suggested that we move the hacky implementation into the android 
plugin instead. Would that be an acceptable solution, at least for a 
first go?


 M   src/network/ssl/ssl.pri
 -1: this unconditionally builds OpenSSL support in, even if the sources aren't
 present. The configure script changes required for this aren't correct.

I've already reverted the changes in SSL.pri. I'll remove the enablers 
from configure as well.

 .

 A   src/widgets/styles/json/json.cpp
 A   src/widgets/styles/json/json.g
 A   src/widgets/styles/json/json.h
 A   src/widgets/styles/json/json.pri
 A   src/widgets/styles/json/jsonparser.cpp
 -1. Do not add.

 You need to show that this is at least 5x faster than the one in QtCore before
 this begins to be acceptable.

 I'm not the QtWidgets maintainer. If I were, I'd be giving a -2.

Yes, I'll remove these and rewrite to use Qt's json parser.

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

Re: [Development] Reviews needed before android integration in two weeks

[Eskil Abrahamsen Blomfeldt]

On 02/05/2013 12:49 PM, Friedemann Kleint wrote:
 - Nokia is also mentioned along with names of former employees in the 
 json style parser under widgets/styles.  Btw, I am generally wondering 
 about it, it seems to add a new Json parser. Could it be replaced by 
 the Json classes of QtCore?

We have a task about that. I think it either needs to be replaced by 
Qt's json classes or put into 3rdparty.


 -  Compilation of the branch under Windows fails with the attached 
 log. Something is probably wrong with #ifdefing/profiles?

Great, thanks!

Simon Hausmann wrote:
 Let's put it this way: linux-g++* is just as fuzzy as android-g++* in what it
 means. But we're not in the business of creating mathematical formulas, we're
 in the business of making life easier for software developers. If we can make
 it easier for people to port their app to Android, why don't we do it?

I don't have any very strong opinion either way, so whatever the 
majority decides is fine by me, but since there's a disagreement: Could 
you please elaborate on what makes linux-android-g++ (or 
linux-g++-android for symmetry with maemo) simpler for the developer 
compared to android-g++?

Technically I don't think Android is considered a Linux-distribution. 
Wouldn't this be similar to renaming the OSX mkspec to macx-g++-darwin?

-- Eskil

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

Re: [Development] Reviews needed before android integration in two weeks

[Eskil Abrahamsen Blomfeldt]

On 02/05/2013 01:21 PM, BogDan wrote:
   last time when I tried Json classes of QtCore were much slower 
 than the new json parser. Because every application that uses native 
 look and feel must parse a json file every time when it starts, the 
 parsing speed is a very important factor. Cheers, BogDan. 

In that case, the json parser in Qt should probably be fixed instead at 
some point. It doesn't make sense to have two parsers that do the same 
in Qt. I think we have to replace it with the one in Qt, and if Girish 
wants, he can submit a faster parser (or someone can put it into 
3rdparty and map our APIs on top of it).

This is also for QtWidgets which I don't think will be a key ingredient 
in the offering, since it's not really touch-friendly and not working 
optimal on single top level windows.

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

Re: [Development] Reviews needed before android integration in two weeks

[Eskil Abrahamsen Blomfeldt]

On 02/05/2013 02:15 PM, David Faure wrote:
 .
 Looking at the patch with git diff origin/dev...origin/wip/android
 [not very convenient for commenting on code changes...]

 I see changes that are unrelated to android:

I've tried to separate the non-android-specific changes we inherited 
from Necessitas out into separate commits that I will submit to dev 
ahead of time and get proper reviews as soon as possible, as I think we 
will might have to go a few rounds with some of them before they can be 
approved.

Currently I have them as WIPs in Gerrit, because I'm waiting for help to 
understand what each of them are doing. Once I do, I will update the 
commit messages and add relevant people as reviewers for them.

Here's a list of the changes in question (you could also filter on my 
name and look for anything starting with WIP:). The commit messages are 
place holders at the moment, but if maintainers want to look at them 
already, then I would glad to have feedback as soon as possible:

https://codereview.qt-project.org/#change,46789

https://codereview.qt-project.org/#change,46790

https://codereview.qt-project.org/#change,46791

https://codereview.qt-project.org/#change,46792

https://codereview.qt-project.org/#change,46793

https://codereview.qt-project.org/#change,46794 (this is also missing 
documentation)

https://codereview.qt-project.org/#change,46795

https://codereview.qt-project.org/#change,46796

https://codereview.qt-project.org/#change,46797

https://codereview.qt-project.org/#change,46798

https://codereview.qt-project.org/#change,46800

https://codereview.qt-project.org/#change,46801

https://codereview.qt-project.org/#change,46802

https://codereview.qt-project.org/#change,46803

https://codereview.qt-project.org/#change,46804

https://codereview.qt-project.org/#change,46805

https://codereview.qt-project.org/#change,46806


 --- a/src/gui/kernel/qplatforminputcontext.cpp
 +++ b/src/gui/kernel/qplatforminputcontext.cpp
 @@ -114,7 +114,7 @@ void QPlatformInputContext::commit()
   /*!
   Notification on editor updates. Called by QInputMethod::update().
*/
 -void QPlatformInputContext::update(Qt::InputMethodQueries)
 +void QPlatformInputContext::update(Qt::InputMethodQueries queries)
   {
   }
   
 Well, this is just bogus, it creates a compiler warning.

I'll remove stuff like this from the initial commit before submitting it 
to dev.

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

Re: [Development] Proposing Bogdan Vatra as approver

[Eskil Abrahamsen Blomfeldt]

On 01/03/2013 01:29 PM, Eskil Abrahamsen Blomfeldt wrote:
 Hi,

 I'd like to propose BogDan Vatra for approver status.

 BogDan is the main author of the Android-port of Qt 4.8, called
 Necessitas. He is now porting his work to Qt 5 and he has graciously
 agreed to contribute the code to the Qt Project to serve as the basis of
 the official Android-port of Qt 5.

It's been 15 working days, so Bogdan has been upgraded to approver status.

Thanks :)

-- Eskil

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

[Development] Status update on Digia's Qt for Android project

[Eskil Abrahamsen Blomfeldt]

Hi,

As I promised earlier, I will give a short update on the Qt for Android 
project at Digia on a semi-regular basis.

First off, let me introduce the people in Digia who are working on the 
project:

Sinan Tanilkan, acting as product manager
Eskil Blomfeldt (me), acting as project lead

Developers in Oslo:
Paul Olav Tvete,
Christian Strømme,
Yoann Lopes,

In Berlin:
Daniel Teske,
André Pönitz

We have the android-developm...@qt-project.org mailing list up for 
day-to-day discussions that we would like to archive and are using the 
#necessitas IRC channel on Freenode for more direct communication.

The project wiki is here:

 http://qt-project.org/wiki/Qt5ForAndroid

This week we have been focusing on QtMultimedia and virtual keyboard 
support, and preparing for a trip to Berlin next week where we'll 
discuss the tooling and the build system.

The high-level discussions currently on-going are:

1. What should we do about OpenSSL and our binary distributions? There 
are legal issues related to deploying applications that contain 
cryptographic software in some countries, so we need to find out how to 
handle this and based on research done, we believe the APIs provided in 
Android do not cover our needs. My idea is to have the binary 
distribution provide both a non-SSL-enabled and an SSL-enabled build 
(with OpenSSL built in), and the app developer will choose which to 
download. This would be an extra burden on the app developer, though, so 
it would be ideal if we could make the SSL-enabled library the default, 
and just provide an option to select the other one for the use cases 
where the legal issues come into play. Any takes? I know this issue also 
exist for the iOS port. Does anyone know what we do with the binary SDK 
on Windows?

2. There are currently a few names in the Android source code (in 
particular in the Java code) which makes it hard for new developers to 
find their way around. I've proposed the following renaming of the 
following Java packages:

  Quadruplor becomes org.qtproject.qt5.android.tests
  Industrius becomes org.qtproject.qt5.android
  Origo becomes org.qtproject.qt5.android.bindings


That's about it! Please join us on IRC or on the project mailing list if you 
want to participate :)

-- Eskil




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

Re: [Development] ChangeLogs

[Eskil Abrahamsen Blomfeldt]

On 01/17/2013 04:05 PM, Oswald Buddenhagen wrote:
 we introduce a new footer (ChangeLog:) to commit messages. this would
 shift the burden to the contributor, and it could be properly reviewed.
 the generation the logs could be fully automated, and only minimal
 redactional work would be necessary.
 a (somewhat minor) downside would be some redundancy in the commit
 messages.
 don't suggest to change the style of the commit summaries to be
 ready-made changelog entries - this would be neither without
 disadvantages (different target audience), nor would it fully solve the
 problem (selection of commits for the changelog).

 an alternative would be auto-generating the changelog from jira tasks.
 consequently, if you consider something important enough for a changelog
 entry, you need to create a task for it if there is none yet. i guess
 some metrics guys would love that idea, too. for developers, it's of
 course additional work.

I'd prefer adding it to the commit message. There are times when we want 
to link a commit to a task number without having it appear in a commit 
log, e.g. when fixing a regression which was never released or adding 
some internal enablers which would only clutter the changelog and not 
provide any extra value to users. Thus we would either have to add a lot 
of logic to interpret the Jira tasks and try to determine whether it 
should be included in the log or not, or we would have to add the 
possibility of manually overriding it. It just seems like a lot of extra 
potential for committers to break the system.

Having it as part of the commit message seems a lot less complex to me, 
and I don't think it would do any harm to an extra line of 
meta-information in the bottom section with the change-id and 
task-number where there's already lots of clutter.

-- Eskil

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

[Development] Proposal: Adding a repository in Qt Project for the Ministro tool, needed by Qt for Android

[Eskil Abrahamsen Blomfeldt]

Hi,

As part of the Android-port of Qt 5 being contributed to the Qt Project 
by BogDan, he also contributed the code for a general-purpose Android 
app which is used for getting libraries and plugins on demand when a Qt 
app is deployed to an Android device. This tool is called Ministro.

We need a repository to put it in, and the existing repositories do not 
seem to fit, so I'm proposing making a new repository for this: 
ministro/ministro

Thanks!

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

Re: [Development] Android port - Why do we need Ministro?

[Eskil Abrahamsen Blomfeldt]

On 01/11/2013 03:36 PM, Felipe Crochik wrote:
Are there plans to change this flow? I have to assume there were good 
reasons to do like this but without actually looking into the code it 
seems that would make more sense to combine the ministro code with the 
java wrapper generated for each application, no?


I understand ministro plays an important part and donwloads the right 
version of the libraries for each device and that we would have to 
duplicate its code with every application but it seems like a very 
reasonable price to pay if that would actually make the first 
install experience better. Are there any other technical reasons why 
this approach would not work?


Hi,

We need alternative deployment mechanisms for the use cases that are not 
covered by Ministro, but there are issues with this for deploying 
imports and plugins and Ministro also makes it easier to deploy to 
different devices, as it downloads the correct version of the platform 
plugin for you. I think this is all solvable somehow, but I don't think 
the solution is integrating Ministro in each app, because each app would 
still have to download their own libraries if there's no central 
repository on the device. I think it would be better to make a secondary 
deployment method which allows you to put everything you need into the 
apk so that the app works out of the box and you have full control over 
the Qt libraries it uses and when these are updated. I'm not 100% sure 
what that would require at the moment, though. It could mean building 
statically, or it could mean something else.


So the bottom line: I do think we need support for this, but I think we 
should spend the time to find the right solution, so it's not likely to 
happen for the experimental version of the port we're planning to 
release with Qt 5.1. Since Ministro is well-tested and provides both a 
simple and working way of deploying and updating the libraries, imports 
and plugins we need, and it allows several apps to share the same 
binaries, so you avoid bloating the size of your app (which might a 
problem depending on how large your app is to begin with), I think it's 
a good solution for the first version of the port.


-- Eskil





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

Re: [Development] Android port - Why do we need Ministro?

[Eskil Abrahamsen Blomfeldt]

On 01/11/2013 04:23 PM, Felipe Crochik wrote:
With my very limited experience on the subject I have to say that the 
current flow is probably good enough for controlled distribution 
but pretty bad for mass market apps.


Having the application download the libraries after being downloaded 
is bad enough for the average user but figuring out the installing 
ministro step requires a level of commitment that I think very few 
average/casual users will show for a random application they found 
in the store.


Why do you think incorporating ministro code into each application is 
bad? Unless there is some technical limitation to install shared 
libraries this way the only drawback I can imagine is that we will 
need to update applications that depend on it with any improvement on 
it is made because of new devices - what is a pretty reasonable 
problem to work around.


Note that I am only talking about the Qt shared libraries - not any 
other third party libraries.


This suggestion is definitely something we'll investigate. I haven't 
looked into the Ministro code yet, so I don't know if it's technically 
possible, but as far as I've understood from previous discussions, there 
are limits to where apps can write on the device and there are limits to 
where they can load libraries, which makes the app serving as a central 
repository of libraries necessary. But it's something we need to 
investigate further, and for the moment we don't have the resources to 
take this on for Qt 5.1, where our main priority will be to get the Qt 5 
port on par with the Qt 4 version of Necessitas. When get that far, we 
can start looking into alternative solutions for deploying Qt apps which 
does not require the extra install ministro step when a user launches 
a Qt app for the first time on a device.


If integrating Ministro in the app is an option, then I agree it might 
better than depending on an external app, but I still think we would 
need a second solution which allows you to bundle the libraries with 
your app.


-- Eskil


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

Re: [Development] Qt 5 for Android developer mailing list

[Eskil Abrahamsen Blomfeldt]

On 01/09/2013 09:12 PM, Laszlo Papp wrote:
On Tue, Jan 8, 2013 at 5:37 PM, Paul Olav Tvete paul.tv...@digia.com 
mailto:paul.tv...@digia.com wrote:


I'll try once more: We have identified the need for a dedicated
channel of
communication for a new project with a rather tight deadline. We
would like
that channel to be publicly visible so that that others can follow
what we do.


To be honest I am reluctant to this mentality of not caring about 
others like me who do not wish to subscribe to many mailing lists.


Hi, Laszlo.

I understand that a single mailing list is most convenient for the 
people who want to casually follow all Qt development or all mobile Qt 
development, but for those of us who will be working on this for eight 
hours every day, we need a clear channel of communication with more 
persistence than IRC. If I were to treat all mails in 
development@qt-project.org as potentially mission-critical, this would 
cause too many disruptions to my work. This is about finding a way for 
us to manage our project so that we can work efficiently, respond 
quickly, protect ourselves from distractions, etc. etc. In my 
experience, having a dedicated mailing list and a dedicated IRC channel 
is a big convenience and will reduce the risk of failure. That is the 
main priority.


But communicating in the open to involve everyone who's interested in 
the project is also of a very high priority. To me, using qt-project.org 
as an umbrella seemed like the logical choice for this, as it would be 
easy to find for the target audience. If this is not acceptable to the 
Qt Project community, however, I would rather look for an alternative 
public mailing list option rather than using one internal to Digia. The 
comment about having private mails with huge CC-lists was a reference to 
the ad hoc-solution which often occurs naturally in projects with tight 
schedules where this problem of having a clear channel of communication 
has not been solved in some other way initially.


Note that I would consider this mailing list as temporary and it will 
exist to facilitate this project. We could make the naming reflect this, 
perhaps? When the Qt 5 Android port is mature and development is no 
longer as focused, I don't believe there will be any need for a 
dedicated list. At this point, the list can be closed (or just phased 
out), and any Android-related issues can be addressed to the main 
development mailing list, same as for any other topics.



Do I care about mobile platforms? Yes.
Do I wish to maintain many bubbles separately? No.


There's really nothing preventing you from filtering these mailing list 
messages into the same IMAP folder. Adding a second mailing list is a 
compromise which considers both your wishes as well as the wishes of the 
project team and the wishes of the people who do not want to read mails 
about Android. Having everything in the same list is less flexible and 
accounts for the requirements of fewer people, so if your concern is 
caring about others, then I think having a dedicated list is more 
appropriate.


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

Re: [Development] Qt 5 for Android developer mailing list

[Eskil Abrahamsen Blomfeldt]

On 01/10/2013 09:39 AM, Tomasz Siekierda wrote:
 Having a separate list is caring about others like me who are not
 interested in the Android port development. ;-)
 A list for Necessitas already exists (for a long time), along with a
 Google Group.
 https://mail.kde.org/mailman/listinfo/necessitas-devel
 https://groups.google.com/forum/#!forum/android-qt

 Can't they be used, especially if the aim is to make it only a
 temporary thing? Or is the plan to keep Necessitas separate from Qt
 Project port?

Hi, Tomasz.

It could be an option to use the Necessitas list if it turns out that 
hosting it on Qt Project is unacceptable. The downsides of this is that 
users of Necessitas who read this group to get help with writing Qt apps 
for Android will have to read about the day-to-day organization of the 
details in our project, and it will be harder to find for members of the 
Qt Project who are no necessarily familiar with Necessitas.

-- Eskil

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

Re: [Development] Qt 5 for Android developer mailing list

[Eskil Abrahamsen Blomfeldt]

On 01/10/2013 10:14 AM, Chao Caroline wrote:
 I have a suggestion. What about having:

 1 -A dedicated mailing list as suggested by Eskil for day to day discussions:
 Suggested name: android-developm...@qt-project.org

 2 - Once a week a status email sent to the development mailing list giving 
 the status on the current progress and remaining problems.

 So people outside the project can stay tuned and give inputs if needed 
 without too much noise in the generic mailing list.

I can do this, if everyone thinks it sounds like a good compromise. :)

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

[Development] Qt 5 for Android developer mailing list

[Eskil Abrahamsen Blomfeldt]

Hi,

I'd like to propose making a mailing list in Qt Project for the Qt 5 for 
Android port. I think it makes sense to have a separate list for this, 
since it will probably be fairly high in traffic as this project is 
ramping up, and I want to avoid having a lot of ad hoc mailing lists 
based on CC-lists.

Suggested name: android-developm...@qt-project.org

Thanks!

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

Re: [Development] wip/android branch contains binaries without license

[Eskil Abrahamsen Blomfeldt]

On 01/08/2013 01:43 PM, Thiago Macieira wrote:
 On quinta-feira, 3 de janeiro de 2013 14.48.51, Thiago Macieira wrote:
 Please delete the branch and recreate (with another name) without these
 files  in src/3rdparty/android/precompiled/android-8/arch-arm/lib/:
 Again, please *delete* the branch.

There's no binaries in that branch any more, and we did a force push to 
overwrite the history.

-- Eskil


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

[Development] Proposing Bogdan Vatra as approver

[Eskil Abrahamsen Blomfeldt]

Hi,

I'd like to propose BogDan Vatra for approver status.

BogDan is the main author of the Android-port of Qt 4.8, called 
Necessitas. He is now porting his work to Qt 5 and he has graciously 
agreed to contribute the code to the Qt Project to serve as the basis of 
the official Android-port of Qt 5.

best regards,
Eskil
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New branch in qtdoc for Qt 5.0 documentation brush-up

[Eskil Abrahamsen Blomfeldt]

On 10/04/2012 05:21 PM, Stephen Kelly wrote:
 On Thursday, October 04, 2012 17:06:08 Eskil Abrahamsen Blomfeldt wrote:
 If
 you are working on changes to the qtdoc repository, could you please
 move it over to newdocs branch so we can minimize conflicts?
 Excuse my circular logic, but if everyone should commit to newdocs and no one
 should commit to master, let's delete the master branch entirely, rename
 newdocs to master and work there instead. That way, we we're done with this
 complicated branch issue before the newdocs branch was even created.

 In other words: Why create a branch at all?

This is most likely just poor communication on my part.

The newdocs branch is a topic branch where we can break the current 
documentation without delaying the next beta. If you have changes that 
need to go into the beta, they can be put in the master branch and we 
will deal with any potential conflicts when they appear, but if they do 
not, and especially if you are participating in the Qt 5 documentation 
clean-up, it would be great if you could commit to newdocs so we 
working against the same version of the code.

The main conflicts we're worried about now is work on pages that are 
deleted in the new structure for instance or duplicate work, which would 
become much more visible if everyone working to make the Qt 5 
documentation great are on the same branch.

The branch will go away and be merged into master once its contents are 
considered usable, so this is in no way meant to be a permanent 
solution. Hopefully that will not take too long.

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

Re: [Development] Text rendering in Qt5

[Eskil Abrahamsen Blomfeldt]

On 09/25/2012 07:09 AM, ext song.7@nokia.com wrote:
Is there some wikis or blogs about how does the text rendering work in 
Qt5 ?


Hi,

Here's a couple:

http://blog.qt.digia.com/2011/07/15/text-rendering-in-the-qml-scene-graph/

http://blog.qt.digia.com/2012/08/08/native-looking-text-in-qml-2/

The images in the last one have unfortunately not migrated correctly, it 
seems, but the text is there at least.


-- Eskil

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

Re: [Development] HELP NEEDED: Cleaning up the class documentation for Qt 5

[Eskil Abrahamsen Blomfeldt]

On 08/30/2012 03:44 PM, Gladhorn Frederik (Nokia-MP/Oslo) wrote:
 Great stuff :)

 Jedrzej and I just started running our qdoc bot, similar to the sanity bot. It
 will post on commits where we suspect new documentation errors to be
 introduces. Let us know when it doesn't work.
 Currently it runs make docs in qtbase with patches that have been pushed and
 their parent commit to compare the difference in output.

Just to clarify: While there's also a real need to go through all the 
qdoc warnings and fix them up (I know several people are working 
steadily on that at the moment), the clean-up-list is specifically for 
actually reading the documentation to look for phrasing or references 
that are Qt 4-specific.

This could be anything from actual mentions of stuff like the awesome 
Qt 4 main window framework to references to QWidget subclasses in other 
modules than QtWidget where we would want to try to also add references 
to QML (in the cases where this makes sense) or at least make the 
documentation as frontend-agnostic as possible.

One example was in QSyntaxHighlighter where the description of the class 
referred to a constructor which had been removed in Qt 5. This reference 
was simply removed.

Another example was QTextDocument, which has now been rephrased a little 
to identify the class as a general rich text layout engine, and not only 
the back end for QTextEdit, which is just one isolated use case in Qt 5.

Note that for the great majority of the classes this will not be a 
problem, but we won't know for sure until someone has read the 
documentation and verified this.

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