[Development] New Qt 5.2 snapshot available
Hi all, We have again new snapshot available for you verification testing: http://download.qt-project.org/snapshots/qt/5.2/5.2.0/2013-12-04_194/ Almost all installers are available, only combined iOS Android installer for mac is missing. Mirroring is ongoing so it might be all installers aren't visible for everyone just now (but will be later). Qt5 changes after #186: https://codereview.qt-project.org/#change,73036: * qtbase 7d5448d...9302169 (9): QtConcurrent: Workaround GCC bug 58800 in median calculation Stabilize tst_QGraphicsItem iOS: Use DWARF instead of DWARF with dSYM for debug builds Revert configure: Abort if Xlib isnt present when building for XCB. Use Q_QDOC for Qt namespace declaration in Qt Gui Stabilize tst_QColumnView::dynamicModelChanges(). Cocoa: Mouse enter events on window activation. Add PBXCopyFilesBuildPhases to main target, not preprocessing step Default to 5.2 source repository for Qt 5.2.x * qtdeclarative 17da877...3b7a8d9 (2): Fix style animations to stop when the item is hidden Safely abort when we dont succeed in creating a GL context. * qtquickcontrols 78c8e7d...1d684b3 (1): Fix desktop style animations to stop when the control is hidden * qtserialport 5fabe1c...fdd3876 (1): Deprecate further Unknown* property values similarly to UnknownParity * qttools 9ca1e89...f7f37e7 (1): Revert Qt Designer: Temporarily disable loading of QDeclarativeView plugin. * qtwebkit 840e281...4c86230 (1): Do not force SSE2 instructions on i386 builds * qtwinextras ed4d739...c996740 (1): Add missing include for QQuickDwmFeatures plugin. -- Jani Heikkinen Release Manager Digia Plc Elektroniikkatie 10, FI 90590 Oulu Finland Email: jani.heikki...@digia.commailto:jani.heikki...@digia.com Mobile: +358-504-873-735 Visit us at: www.digia.comhttp://www.digia.com/ | Bloghttp://blog.digia.com/ | Twitterhttps://twitter.com/digiaonline | LinkedInhttp://www.linkedin.com/company/5119 | YouTubehttp://www.youtube.com/digiaonline | Facebookhttp://www.facebook.com/digiaonline | -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Plc does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. -- ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] qt5.2.0: javascriptcore compile fix
hi,
in order to compile qt-5.2.0-rc1 as static library with c++11 on osx, i
need to apply the attached patch.
the issue had been reported in a comment in [1], but i guess the issue
was missed, because the bug was closed before.
iac, attached patch fixes the issue, would be great if it can be included.
thnx,
tim
[1] https://bugreports.qt-project.org/browse/QTBUG-34842
diff --git
a/qtscript/src/3rdparty/javascriptcore/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp
b/qtscript/src/3rdparty/javascriptcore/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp
index d2ad679..87b70a4 100644
---
a/qtscript/src/3rdparty/javascriptcore/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp
+++
b/qtscript/src/3rdparty/javascriptcore/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp
@@ -1835,7 +1835,13 @@ RegisterID*
BytecodeGenerator::emitNextPropertyName(RegisterID* dst, RegisterID*
RegisterID* BytecodeGenerator::emitCatch(RegisterID* targetRegister, Label*
start, Label* end)
{
#if ENABLE(JIT)
-HandlerInfo info = { start-bind(0, 0), end-bind(0, 0),
instructions().size(), m_dynamicScopeDepth + m_baseScopeDepth,
CodeLocationLabel() };
+HandlerInfo info = {
+static_castuint32_t(start-bind(0, 0)),
+static_castuint32_t(end-bind(0, 0)),
+static_castuint32_t(instructions().size()),
+static_castuint32_t(m_dynamicScopeDepth + m_baseScopeDepth),
+CodeLocationLabel()
+};
#else
HandlerInfo info = {
static_castuint32_t(start-bind(0, 0)),
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qt5.2.0: javascriptcore compile fix
On Wednesday 04 December 2013 09:55:55 Tim Blechmann wrote: hi, in order to compile qt-5.2.0-rc1 as static library with c++11 on osx, i need to apply the attached patch. the issue had been reported in a comment in [1], but i guess the issue was missed, because the bug was closed before. iac, attached patch fixes the issue, would be great if it can be included. thnx, tim [1] https://bugreports.qt-project.org/browse/QTBUG-34842 The patch looks good. Please send it to gerrit so it can be merged. (stable branch) http://qt-project.org/wiki/Gerrit-Introduction (You can add me as a reviewer) -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [ANN] C++Now 2014: 5 Days to Submissions Deadline
Hi, Only 5 days left before the submissions deadline for C++Now 2014! C++Now is a general C++ conference for C++ experts and enthusiasts. It is not specific to any library/framework or compiler vendor and has three tracks with presentations ranging from hands-on, practical tutorials to advanced C++ design and development techniques. For more information about C++Now, see the conference's website: http://cppnow.org/about/ Have you learned something interesting about C++ (e.g., a new technique possible in C++11)? Or maybe you have implemented something cool related to C++ (e.g., a C++ library)? If so, consider sharing it with other C++ enthusiasts by giving a talk at C++Now 2014. For more information on possible topics, formats, etc., see the call for submissions: http://cppnow.org/2013/10/21/2014-call-for-submissions/ Boris ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qt5.2.0: javascriptcore compile fix
hi, in order to compile qt-5.2.0-rc1 as static library with c++11 on osx, i need to apply the attached patch. the issue had been reported in a comment in [1], but i guess the issue was missed, because the bug was closed before. iac, attached patch fixes the issue, would be great if it can be included. thnx, tim [1] https://bugreports.qt-project.org/browse/QTBUG-34842 The patch looks good. Please send it to gerrit so it can be merged. (stable branch) http://qt-project.org/wiki/Gerrit-Introduction (You can add me as a reviewer) is there a way to upload a patch without cloning all of qt? my internet connection is pretty unstable atm. this means that cloning repos hangs after some time :( thnx, tim ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Sysadmin
Hi all, Petri Järvenpää is nominated to Qt project sysadmin role. He is the default assignee for all tickets at https://bugreports.qt-project.org/browse/QTSYSADM In case of Petri's vacations or other absences deputies are handling tickets. Olli Hirvonen Senior Manager, Qt Releases - Digia Visit us on: http://qt.digia.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OpenGL drivers
QWidget has the exact opposite problem. Layouts, styles and rendering happens
in pixel units while fonts are sized in point size. This is also a problem when
moving between platfoms as the pixelsize of a point has a different definition
on each platform. When running widgets on a hidpi screen, the fonts are usually
huge compared to spacing, lines and icons. In addition to looking quite ugly it
easily breaks the layout scheme set up by the application because the text
takes up too much space.
As long as one sticks to one unit type through the application everything is
fine. Mixing leads to problems.
Just thinking out loud:
Sticking to pixels makes it possible for the application developer to make the
right decision based on what he/she wants to achieve. Layout out relative to
millimeters can quite easily be done by providing supporting logic in Qt.
If we added conversion functions for inch(), cm(), mm(), points() to
QQuickItem, it could look up its current window/screen object and figure out
the relationship between each unit for the screen the item is on and just set
that. The app can then layout in the unit space it prefers with information
readily available.
Text {
font.pixelSize: cm(0.5);
anchors.left: parent.left
anchors.margins: cm(0.25);
}
Making them functions makes it impossible to listen for screen changes which in
turn trigger dpi changes so they would have to be properties...
Text {
font.pixelSize: 0.5 * cm;
anchors.left: parent.left
anchors.margins: 0.25 * cm;
}
The properties would look up the item's window and then the screen and do the
calculation from there so no extra memory for each item to store the
properties. And since they don't change all that often, the added calculation
is a negligible overhead. When the item is not associated with a window, it
will have to use the OS definition of a point instead, usually 72 or 96.
Just an idea.
-
Gunnar
Fra: development-bounces+gunnar.sletta=digia@qt-project.org
[development-bounces+gunnar.sletta=digia@qt-project.org] p#229; vegne av
Thiago Macieira [thiago.macie...@intel.com]
Sendt: 3. desember 2013 18:09
To: development@qt-project.org
Emne: Re: [Development] OpenGL drivers
On terça-feira, 3 de dezembro de 2013 10:27:24, Thomas Hartmann wrote:
Hi,
we really should think about introducing em or percent for font sizes.
But non pixel size fonts create a lot of problems for complex layouts.
QWidget has worked with that for 15 years, so I don't accept that as an
excuse. We have anchor layouts in Qt Quick, which are a lot more powerful than
the grids and spacers that we used in QWidget.
Desktop support does not require pixel perfection. It does require scaling
over widely different resolutions and DPIs, though -- from 1366x768 to
3200x1800, for example.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OpenGL drivers
Hi,
what is already possible is to read the font.pixelSize property for a
specific point size or just using the implicit size of a text item.
One main problems with layouts following physical units (pt, cm), is
that icons (all pixel based resources) have to be scaled accordingly (or
have a random size). And most icons are still pixel and not vector
based and scale badly.
Eventually on high dpi screens it would make sense of course, to ditch
all pixels and only use vector bases resources. But this is not our
reality, yet.
Kind Regards,
Thomas Hartmann
Am 04/12/2013 11:47, schrieb Sletta Gunnar:
QWidget has the exact opposite problem. Layouts, styles and rendering happens
in pixel units while fonts are sized in point size. This is also a problem
when moving between platfoms as the pixelsize of a point has a different
definition on each platform. When running widgets on a hidpi screen, the
fonts are usually huge compared to spacing, lines and icons. In addition to
looking quite ugly it easily breaks the layout scheme set up by the
application because the text takes up too much space.
As long as one sticks to one unit type through the application everything is
fine. Mixing leads to problems.
Just thinking out loud:
Sticking to pixels makes it possible for the application developer to make
the right decision based on what he/she wants to achieve. Layout out relative
to millimeters can quite easily be done by providing supporting logic in Qt.
If we added conversion functions for inch(), cm(), mm(), points() to
QQuickItem, it could look up its current window/screen object and figure out
the relationship between each unit for the screen the item is on and just set
that. The app can then layout in the unit space it prefers with information
readily available.
Text {
font.pixelSize: cm(0.5);
anchors.left: parent.left
anchors.margins: cm(0.25);
}
Making them functions makes it impossible to listen for screen changes which
in turn trigger dpi changes so they would have to be properties...
Text {
font.pixelSize: 0.5 * cm;
anchors.left: parent.left
anchors.margins: 0.25 * cm;
}
The properties would look up the item's window and then the screen and do the
calculation from there so no extra memory for each item to store the
properties. And since they don't change all that often, the added calculation
is a negligible overhead. When the item is not associated with a window, it
will have to use the OS definition of a point instead, usually 72 or 96.
Just an idea.
-
Gunnar
Fra: development-bounces+gunnar.sletta=digia@qt-project.org
[development-bounces+gunnar.sletta=digia@qt-project.org] p#229; vegne av
Thiago Macieira [thiago.macie...@intel.com]
Sendt: 3. desember 2013 18:09
To: development@qt-project.org
Emne: Re: [Development] OpenGL drivers
On terça-feira, 3 de dezembro de 2013 10:27:24, Thomas Hartmann wrote:
Hi,
we really should think about introducing em or percent for font sizes.
But non pixel size fonts create a lot of problems for complex layouts.
QWidget has worked with that for 15 years, so I don't accept that as an
excuse. We have anchor layouts in Qt Quick, which are a lot more powerful than
the grids and spacers that we used in QWidget.
Desktop support does not require pixel perfection. It does require scaling
over widely different resolutions and DPIs, though -- from 1366x768 to
3200x1800, for example.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
--
Thomas Hartmann
Software Engineer
Nokia, Qt Development Frameworks
Digia Germany GmbH
Rudower Chausse 13, 12489 D-Berlin
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B,
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Email: thomas.hartm...@digia.com
Digia Germany is a group company of Digia Plc,
Valimotie 21, FI-00380 Helsinki Finland
Visit us at: www.digia.com
--
PRIVACY AND CONFIDENTIALITY NOTICE
This message and any attachments are intended only for use by the named
addressee and may contain privileged and/or confidential information. If
you are not the named addressee you should not disseminate, copy or take
any action in reliance on it. If you have received this message in
error, please contact the sender immediately and delete the message and
any attachments accompanying it. Digia Germany GmbH and Digia Plc do not
accept liability for any corruption, interception, amendment, tampering
or viruses occurring to this message.
___
Development mailing list
Re: [Development] OpenGL drivers
On 12/04/2013 11:47 AM, Sletta Gunnar wrote:
QWidget has the exact opposite problem. Layouts, styles and rendering happens
in pixel units while fonts are sized in point size. This is also a problem
when moving between platfoms as the pixelsize of a point has a different
definition on each platform. When running widgets on a hidpi screen, the
fonts are usually huge compared to spacing, lines and icons. In addition to
looking quite ugly it easily breaks the layout scheme set up by the
application because the text takes up too much space.
As long as one sticks to one unit type through the application everything is
fine. Mixing leads to problems.
Just thinking out loud:
Sticking to pixels makes it possible for the application developer to make
the right decision based on what he/she wants to achieve. Layout out relative
to millimeters can quite easily be done by providing supporting logic in Qt.
If we added conversion functions for inch(), cm(), mm(), points() to
QQuickItem, it could look up its current window/screen object and figure out
the relationship between each unit for the screen the item is on and just set
that. The app can then layout in the unit space it prefers with information
readily available.
Text {
font.pixelSize: cm(0.5);
anchors.left: parent.left
anchors.margins: cm(0.25);
}
Making them functions makes it impossible to listen for screen changes which
in turn trigger dpi changes so they would have to be properties...
Text {
font.pixelSize: 0.5 * cm;
anchors.left: parent.left
anchors.margins: 0.25 * cm;
}
The properties would look up the item's window and then the screen and do the
calculation from there so no extra memory for each item to store the
properties. And since they don't change all that often, the added calculation
is a negligible overhead. When the item is not associated with a window, it
will have to use the OS definition of a point instead, usually 72 or 96.
Just an idea.
-
Gunnar
That's a pretty cool idea! It would make it so painless to design stuff
for different screens' DPIs.
Fra: development-bounces+gunnar.sletta=digia@qt-project.org
[development-bounces+gunnar.sletta=digia@qt-project.org] p#229; vegne av
Thiago Macieira [thiago.macie...@intel.com]
Sendt: 3. desember 2013 18:09
To: development@qt-project.org
Emne: Re: [Development] OpenGL drivers
On terça-feira, 3 de dezembro de 2013 10:27:24, Thomas Hartmann wrote:
Hi,
we really should think about introducing em or percent for font sizes.
But non pixel size fonts create a lot of problems for complex layouts.
QWidget has worked with that for 15 years, so I don't accept that as an
excuse. We have anchor layouts in Qt Quick, which are a lot more powerful than
the grids and spacers that we used in QWidget.
Desktop support does not require pixel perfection. It does require scaling
over widely different resolutions and DPIs, though -- from 1366x768 to
3200x1800, for example.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OpenGL drivers
On 04 Dec 2013, at 11:47, Sletta Gunnar gunnar.sle...@digia.com wrote: QWidget has the exact opposite problem. Layouts, styles and rendering happens in pixel units while fonts are sized in point size. This is also a problem when moving between platfoms as the pixelsize of a point has a different definition on each platform. When running widgets on a hidpi screen, the fonts are usually huge compared to spacing, lines and icons. In addition to looking quite ugly it easily breaks the layout scheme set up by the application because the text takes up too much space. As long as one sticks to one unit type through the application everything is fine. Mixing leads to problems. Just thinking out loud: Sticking to pixels makes it possible for the application developer to make the right decision based on what he/she wants to achieve. Layout out relative to millimeters can quite easily be done by providing supporting logic in Qt. If we added conversion functions for inch(), cm(), mm(), points() to QQuickItem, it could look up its current window/screen object and figure out the relationship between each unit for the screen the item is on and just set that. The app can then layout in the unit space it prefers with information readily available. I agree on sticking to one unit. However, we've tested using screen metrics and found that not all screens report those, or worse, some return bogus values. Think about the projector case, what should it report? We also ran into odd behavior when moving windows between screens, where windows would resize themselves (or fail to do so) to accommodate to the new definition of “cm”. I believe CSS anchors its “px” unit to either the device pixel grid (and then some integer multiple is recommended), or to physical size (for example when printing). In Qt this could be decided by the platform. The problem is however that you don’t know if you can trust the screen metrics you get. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OpenGL drivers
On Wed, Dec 4, 2013 at 12:37 PM, Mitch Curtis mitch.cur...@digia.com wrote:
On 12/04/2013 11:47 AM, Sletta Gunnar wrote:
QWidget has the exact opposite problem. Layouts, styles and rendering
happens in pixel units while fonts are sized in point size. This is also a
problem when moving between platfoms as the pixelsize of a point has a
different definition on each platform. When running widgets on a hidpi
screen, the fonts are usually huge compared to spacing, lines and icons. In
addition to looking quite ugly it easily breaks the layout scheme set up by
the application because the text takes up too much space.
As long as one sticks to one unit type through the application everything is
fine. Mixing leads to problems.
Just thinking out loud:
Sticking to pixels makes it possible for the application developer to make
the right decision based on what he/she wants to achieve. Layout out
relative to millimeters can quite easily be done by providing supporting
logic in Qt.
If we added conversion functions for inch(), cm(), mm(), points() to
QQuickItem, it could look up its current window/screen object and figure out
the relationship between each unit for the screen the item is on and just
set that. The app can then layout in the unit space it prefers with
information readily available.
Text {
font.pixelSize: cm(0.5);
anchors.left: parent.left
anchors.margins: cm(0.25);
}
Making them functions makes it impossible to listen for screen changes which
in turn trigger dpi changes so they would have to be properties...
Text {
font.pixelSize: 0.5 * cm;
anchors.left: parent.left
anchors.margins: 0.25 * cm;
}
The properties would look up the item's window and then the screen and do
the calculation from there so no extra memory for each item to store the
properties. And since they don't change all that often, the added
calculation is a negligible overhead. When the item is not associated with a
window, it will have to use the OS definition of a point instead, usually 72
or 96.
Just an idea.
-
Gunnar
That's a pretty cool idea! It would make it so painless to design stuff
for different screens' DPIs.
I'm confused.
I thought we has pointSize for that reason, no?
To me it sounds like two different ways to accomplish the same thing.
Also, if i'm setting a font.pixelSize i'm expexting pixels to be
drawn. adding a * cm makes that moot since the real pixels that will
be drawn are calculated based on whatever cm is.
In other words, don't use pixelSize for it. Just making up a name now,
but how about something like this:
Text {
...
font.realSize: 0.5 cm
...
}
seems more readable to me and gives me the expectation that the font
is going to be 0.5 CM (per char).
Fra: development-bounces+gunnar.sletta=digia@qt-project.org
[development-bounces+gunnar.sletta=digia@qt-project.org] p#229; vegne
av Thiago Macieira [thiago.macie...@intel.com]
Sendt: 3. desember 2013 18:09
To: development@qt-project.org
Emne: Re: [Development] OpenGL drivers
On terça-feira, 3 de dezembro de 2013 10:27:24, Thomas Hartmann wrote:
Hi,
we really should think about introducing em or percent for font sizes.
But non pixel size fonts create a lot of problems for complex layouts.
QWidget has worked with that for 15 years, so I don't accept that as an
excuse. We have anchor layouts in Qt Quick, which are a lot more powerful
than
the grids and spacers that we used in QWidget.
Desktop support does not require pixel perfection. It does require scaling
over widely different resolutions and DPIs, though -- from 1366x768 to
3200x1800, for example.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OpenGL drivers
Because everything else, x, y, width, height, image dimensions, anchor margins,
etc is in pixels. The fact that we have Font.pointSize is in my opinion a flaw.
That being said, I wouldn't mind changing Font.pixelSize to Font.size if there
was an agreement on standardizing on pixels.
Fra: Mark Gaiser [mark...@gmail.com]
Sendt: 4. desember 2013 14:54
To: Curtis Mitch
Cc: Sletta Gunnar; Thiago Macieira; development@qt-project.org
Emne: Re: [Development] OpenGL drivers
On Wed, Dec 4, 2013 at 12:37 PM, Mitch Curtis mitch.cur...@digia.com wrote:
On 12/04/2013 11:47 AM, Sletta Gunnar wrote:
QWidget has the exact opposite problem. Layouts, styles and rendering
happens in pixel units while fonts are sized in point size. This is also a
problem when moving between platfoms as the pixelsize of a point has a
different definition on each platform. When running widgets on a hidpi
screen, the fonts are usually huge compared to spacing, lines and icons. In
addition to looking quite ugly it easily breaks the layout scheme set up by
the application because the text takes up too much space.
As long as one sticks to one unit type through the application everything is
fine. Mixing leads to problems.
Just thinking out loud:
Sticking to pixels makes it possible for the application developer to make
the right decision based on what he/she wants to achieve. Layout out
relative to millimeters can quite easily be done by providing supporting
logic in Qt.
If we added conversion functions for inch(), cm(), mm(), points() to
QQuickItem, it could look up its current window/screen object and figure out
the relationship between each unit for the screen the item is on and just
set that. The app can then layout in the unit space it prefers with
information readily available.
Text {
font.pixelSize: cm(0.5);
anchors.left: parent.left
anchors.margins: cm(0.25);
}
Making them functions makes it impossible to listen for screen changes which
in turn trigger dpi changes so they would have to be properties...
Text {
font.pixelSize: 0.5 * cm;
anchors.left: parent.left
anchors.margins: 0.25 * cm;
}
The properties would look up the item's window and then the screen and do
the calculation from there so no extra memory for each item to store the
properties. And since they don't change all that often, the added
calculation is a negligible overhead. When the item is not associated with a
window, it will have to use the OS definition of a point instead, usually 72
or 96.
Just an idea.
-
Gunnar
That's a pretty cool idea! It would make it so painless to design stuff
for different screens' DPIs.
I'm confused.
I thought we has pointSize for that reason, no?
To me it sounds like two different ways to accomplish the same thing.
Also, if i'm setting a font.pixelSize i'm expexting pixels to be
drawn. adding a * cm makes that moot since the real pixels that will
be drawn are calculated based on whatever cm is.
In other words, don't use pixelSize for it. Just making up a name now,
but how about something like this:
Text {
...
font.realSize: 0.5 cm
...
}
seems more readable to me and gives me the expectation that the font
is going to be 0.5 CM (per char).
Fra: development-bounces+gunnar.sletta=digia@qt-project.org
[development-bounces+gunnar.sletta=digia@qt-project.org] p#229; vegne
av Thiago Macieira [thiago.macie...@intel.com]
Sendt: 3. desember 2013 18:09
To: development@qt-project.org
Emne: Re: [Development] OpenGL drivers
On terça-feira, 3 de dezembro de 2013 10:27:24, Thomas Hartmann wrote:
Hi,
we really should think about introducing em or percent for font sizes.
But non pixel size fonts create a lot of problems for complex layouts.
QWidget has worked with that for 15 years, so I don't accept that as an
excuse. We have anchor layouts in Qt Quick, which are a lot more powerful
than
the grids and spacers that we used in QWidget.
Desktop support does not require pixel perfection. It does require scaling
over widely different resolutions and DPIs, though -- from 1366x768 to
3200x1800, for example.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OpenGL drivers
Hi,
On Wednesday 04 December 2013 11:47:29 Sletta Gunnar wrote:
If we added conversion functions for inch(), cm(), mm(), points() to
QQuickItem, it could look up its current window/screen object and figure
out the relationship between each unit for the screen the item is on and
just set that. The app can then layout in the unit space it prefers with
information readily available.
Text {
font.pixelSize: cm(0.5);
anchors.left: parent.left
anchors.margins: cm(0.25);
}
Making them functions makes it impossible to listen for screen changes
which in turn trigger dpi changes so they would have to be properties...
Text {
font.pixelSize: 0.5 * cm;
anchors.left: parent.left
anchors.margins: 0.25 * cm;
}
Interesting, the cm() function is another example that shows the need for
functions having NOTIFY signals.
The other example is qsTr(), since you want to have updates when the language
changes. Although for qsTr(), there is a patch somewhere that adds support for
just that in the QML engine, a generic mechanism for NOTIFY support in
functions would be nice.
Regards,
Thomas
--
Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer
KDAB (Deutschland) GmbHCo KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] QSGNode::markDirty no longer works?
Hi,
I had a QQuickItem-based 2D linegraph working fine in prior versions of
Qt 5. This code does not seem to work with Qt 5.2 RC 1. Below is the
relevant code of my QQuickItem-based linegraph:
QSGNode* Linegraph::updatePaintNode(QSGNode* oldNode,
UpdatePaintNodeData* updatePaintNodeData)
{
Q_UNUSED(updatePaintNodeData);
QSGGeometryNode* node = nullptr;
QSGGeometry* geometry = nullptr;
QSGFlatColorMaterial* material = nullptr;
if (!oldNode)
{
node = new QSGGeometryNode();
geometry = new
QSGGeometry(QSGGeometry::defaultAttributes_Point2D(), 1000);
geometry-setLineWidth(1);
geometry-setDrawingMode(GL_LINE_STRIP);
geometry-allocate(1000);
node-setGeometry(geometry);
node-setFlag(QSGNode::OwnsGeometry);
material = new QSGFlatColorMaterial();
node-setMaterial(material);
node-setFlag(QSGNode::OwnsMaterial);
}
else
{
node = static_castQSGGeometryNode*(oldNode);
geometry = node-geometry();
material = static_castQSGFlatColorMaterial*(node-material());
}
const QRectF bounds = boundingRect();
const float horizontalPointSpacing = (float)bounds.width() / (1000 -
1.0f);
QSGGeometry::Point2D* vertices = geometry-vertexDataAsPoint2D();
float currentX = 0.0f;
float currentY = 0.0f;
for (quint32 pointIndex = 0; pointIndex m_numOfTracePoints;
++pointIndex)
{
currentX = 1.0f + pointIndex * horizontalPointSpacing;
currentY = qBound(0.0f, (m_data[pointIndex] * (-1)) / 10.0f,
1.0f) * (float)bounds.height();
vertices[pointIndex].set(currentX, currentY);
}
node-markDirty(QSGNode::DirtyForceUpdate);
return node;
}
In prior versions of Qt, the second to last line
(node-markDirty(QSGNode::DirtyForceUpdate)) was needed, otherwise
updates to the vertices point array would not be reflected in what
gets drawn. Now, with Qt 5.2 RC 1, changes made to the points stored in
the vertices point array are never reflected in what is drawn:
whatever the array is initialized with is what is drawn in all
subsequent updates.
Is this a user error on my part? Should I be using something other than
QSGNode::markDirty to force the vertices point array changes to take
effect? Or is this perhaps a bug in Qt 5.2 RC 1?
Any help is greatly appreciated.
Thanks.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSGNode::markDirty no longer works?
It looks like using QSGNode::DirtyGeometry did the trick. I would have
expected QSGNode::DirtyForceUpdate to work though. Is this a bug?
On Wed, Dec 4, 2013, at 02:14 PM, achart...@fastmail.fm wrote:
Hi,
I had a QQuickItem-based 2D linegraph working fine in prior versions of
Qt 5. This code does not seem to work with Qt 5.2 RC 1. Below is the
relevant code of my QQuickItem-based linegraph:
QSGNode* Linegraph::updatePaintNode(QSGNode* oldNode,
UpdatePaintNodeData* updatePaintNodeData)
{
Q_UNUSED(updatePaintNodeData);
QSGGeometryNode* node = nullptr;
QSGGeometry* geometry = nullptr;
QSGFlatColorMaterial* material = nullptr;
if (!oldNode)
{
node = new QSGGeometryNode();
geometry = new
QSGGeometry(QSGGeometry::defaultAttributes_Point2D(), 1000);
geometry-setLineWidth(1);
geometry-setDrawingMode(GL_LINE_STRIP);
geometry-allocate(1000);
node-setGeometry(geometry);
node-setFlag(QSGNode::OwnsGeometry);
material = new QSGFlatColorMaterial();
node-setMaterial(material);
node-setFlag(QSGNode::OwnsMaterial);
}
else
{
node = static_castQSGGeometryNode*(oldNode);
geometry = node-geometry();
material = static_castQSGFlatColorMaterial*(node-material());
}
const QRectF bounds = boundingRect();
const float horizontalPointSpacing = (float)bounds.width() / (1000 -
1.0f);
QSGGeometry::Point2D* vertices = geometry-vertexDataAsPoint2D();
float currentX = 0.0f;
float currentY = 0.0f;
for (quint32 pointIndex = 0; pointIndex m_numOfTracePoints;
++pointIndex)
{
currentX = 1.0f + pointIndex * horizontalPointSpacing;
currentY = qBound(0.0f, (m_data[pointIndex] * (-1)) / 10.0f,
1.0f) * (float)bounds.height();
vertices[pointIndex].set(currentX, currentY);
}
node-markDirty(QSGNode::DirtyForceUpdate);
return node;
}
In prior versions of Qt, the second to last line
(node-markDirty(QSGNode::DirtyForceUpdate)) was needed, otherwise
updates to the vertices point array would not be reflected in what
gets drawn. Now, with Qt 5.2 RC 1, changes made to the points stored in
the vertices point array are never reflected in what is drawn:
whatever the array is initialized with is what is drawn in all
subsequent updates.
Is this a user error on my part? Should I be using something other than
QSGNode::markDirty to force the vertices point array changes to take
effect? Or is this perhaps a bug in Qt 5.2 RC 1?
Any help is greatly appreciated.
Thanks.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] QQuickView memory leaking
Hi, everyone, i'm recently working on a project which is qmlpyqt based, i have to say that it's really much faster doing GUI things in qml, but now i have one problem, every time i called the setSource(url) method of QQuickview, i got plenty of my memory consumed and it never came back event i destroyed the view, what's worse, my program _must_ show and destroy every now and then, so, anyone has some ideas on that , how can i release the memory (or the source) when i want to destroy the view ? thanks :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSGNode::markDirty no longer works?
I'm afraid this is your bug :)
QSGNode::DirtyForceUpdate is an internal undocumented property used for
internal reasons. The right thing to do is to the scene graph exactly what you
changed, which is also cheaper for the scene graph to handle.
QSGNode::DirtyGeometry in this case.
cheers,
Gunnar
Fra: development-bounces+gunnar.sletta=digia@qt-project.org
[development-bounces+gunnar.sletta=digia@qt-project.org] p#229; vegne av
achart...@fastmail.fm [achart...@fastmail.fm]
Sendt: 5. desember 2013 02:04
To: development@qt-project.org
Emne: Re: [Development] QSGNode::markDirty no longer works?
It looks like using QSGNode::DirtyGeometry did the trick. I would have
expected QSGNode::DirtyForceUpdate to work though. Is this a bug?
On Wed, Dec 4, 2013, at 02:14 PM, achart...@fastmail.fm wrote:
Hi,
I had a QQuickItem-based 2D linegraph working fine in prior versions of
Qt 5. This code does not seem to work with Qt 5.2 RC 1. Below is the
relevant code of my QQuickItem-based linegraph:
QSGNode* Linegraph::updatePaintNode(QSGNode* oldNode,
UpdatePaintNodeData* updatePaintNodeData)
{
Q_UNUSED(updatePaintNodeData);
QSGGeometryNode* node = nullptr;
QSGGeometry* geometry = nullptr;
QSGFlatColorMaterial* material = nullptr;
if (!oldNode)
{
node = new QSGGeometryNode();
geometry = new
QSGGeometry(QSGGeometry::defaultAttributes_Point2D(), 1000);
geometry-setLineWidth(1);
geometry-setDrawingMode(GL_LINE_STRIP);
geometry-allocate(1000);
node-setGeometry(geometry);
node-setFlag(QSGNode::OwnsGeometry);
material = new QSGFlatColorMaterial();
node-setMaterial(material);
node-setFlag(QSGNode::OwnsMaterial);
}
else
{
node = static_castQSGGeometryNode*(oldNode);
geometry = node-geometry();
material = static_castQSGFlatColorMaterial*(node-material());
}
const QRectF bounds = boundingRect();
const float horizontalPointSpacing = (float)bounds.width() / (1000 -
1.0f);
QSGGeometry::Point2D* vertices = geometry-vertexDataAsPoint2D();
float currentX = 0.0f;
float currentY = 0.0f;
for (quint32 pointIndex = 0; pointIndex m_numOfTracePoints;
++pointIndex)
{
currentX = 1.0f + pointIndex * horizontalPointSpacing;
currentY = qBound(0.0f, (m_data[pointIndex] * (-1)) / 10.0f,
1.0f) * (float)bounds.height();
vertices[pointIndex].set(currentX, currentY);
}
node-markDirty(QSGNode::DirtyForceUpdate);
return node;
}
In prior versions of Qt, the second to last line
(node-markDirty(QSGNode::DirtyForceUpdate)) was needed, otherwise
updates to the vertices point array would not be reflected in what
gets drawn. Now, with Qt 5.2 RC 1, changes made to the points stored in
the vertices point array are never reflected in what is drawn:
whatever the array is initialized with is what is drawn in all
subsequent updates.
Is this a user error on my part? Should I be using something other than
QSGNode::markDirty to force the vertices point array changes to take
effect? Or is this perhaps a bug in Qt 5.2 RC 1?
Any help is greatly appreciated.
Thanks.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
