[Development] Request qtquickdesigner-components as Qt 6 addon
Hi, I would like to request the inclusion of a new module to Qt 6 as an add-on: Name of the repository: qt-labs/qtquickdesigner-components Description: Module for Qt Design Studio specific QML items Responsible person: Thomas Hartmann Gerrit user/email: thomas.hartm...@qt.io<mailto:thomas.hartm...@qt.io> The module is already on gerrit and is in a mature state by now. The qtquickdesigner-components are part of Qt Design Studio and are typically used by projects created in Qt Design Studio. I request adding the module to Qt 6 releases as an addon. The module provides components that make it easier to create QML using tooling. This includes easy-to-use geometrical shapes like Arc, Triangle, and Hexagon and a more powerful rectangle. The module also contains the FlowView which makes it easy to define screen transitions and it contains building blocks to define logic in declarative QML and compatibilities items for Qt for MCU and Qt for Automotive. Currently, developers have to build the module manually, if they want to build a Qt Design Studio project against Qt. Having the qtquickdesigner-components as an add-on as part of Qt 6 would make their life easier. Best Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Repository request: qtdesignviewer
Hi, I'd like to request a new repository on codereview.qt-project.org. Name of the repository: qt/qtdesignviewer.git Description: Viewer application for .qmlproject based QML applications Responsible person: Thomas Hartmann Gerrit user/email: thomas.hartm...@qt.io<mailto:thomas.hartm...@qt.io> The design viewer for https://qt-webassembly.io/designviewer can already be found here https://git.qt.io/aportale/designviewer. The goal is to extend the functionality and for example, also have a version for Android. Best Regards, Thomas Hartmann -- Thomas Hartmann Senior R Manager The Qt Company GmbH Erich-Thilo-Straße 10 D-12489 Berlin thomas.hartm...@qt.io<mailto:thomas.hartm...@qt.io> http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen 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] Nominating Henning Gründl as approver
Hi all, I'd like to nominate Henning Gründl as an approver for the Qt Project. Henning has been working on Qt Studio Design Studio and has regularly contributed to Qt Design Studio and Qt Creator. He helped to integrate the advanced dock widget framework and did a lot of work on the property editor. Qt Commits: https://codereview.qt-project.org/q/owner:henning.gruendl%2540qt.io Currently, Henning is further improving the property editor. Mandatory disclaimer: We work in the same team. I trust him to be a good reviewer. Best regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Nominating Aleksei German as aproover
Hi all, I'd like to nominate Aleksei German as an approver for the Qt Project. Aleksei has been working on Qt Studio Design Studio and has regularly contributed to Qt Design Studio and Qt Creator. He implemented annotation support and improved the property editor and form editor. Aleksei is also taking care of the MCU support. Qt Commits: https://codereview.qt-project.org/q/owner:aleksei.german%2540qt.io Currently, Aleksei is working on a few last features for annotations and will continue with MCU support. Mandatory disclaimer: We work in the same team. I trust him to be a good reviewer. Best regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Nominating Knud Dollereder as approver
Hi all, I'd like to nominate Knud Dollereder as an approver for the Qt Project. Mahmoud has been working on Qt 3D Studio Design Studi and has regularly contributed to Qt Design Studio and Qt Creator. He helped with implementing the timeline and implemented the curve editor. Qt Commits: https://codereview.qt-project.org/q/owner:knud.dollereder%2540qt.io Currently, Knud is working on Qt 6 support and helps with macOS issues. Mandatory disclaimer: We work in the same team. I trust him to be a good reviewer. Best regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Qt Design Studio 1.6 released
Hi all, We released Qt Design Studio 1.6 today, see https://www.qt.io/blog/qt-design-studio-1.6-released Big thanks to everyone involved! Best Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] We released Qt Design Studio Beta 1.6
Hi all, We released Qt Design Studio Beta 1.6 today, see https://www.qt.io/blog/qt-design-studio-1.6-beta-released Big thanks to everyone involved! Best Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Qt Design Studio 1.5 is released
Hi all, We released Qt Design Studio 1.5 today, see https://www.qt.io/blog/qt-design-studio-1.5-released Big thanks to everyone involved! Best Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Qt Design Studio 1.5 Beta is released
Hi, Qt Design Studio 1.5 Beta is released today, see https://www.qt.io/blog/qt-design-studio-1.5-beta-released Big thanks to everyone involved! Best Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Qt Design Studio 1.4.0 released
Hi all, We released Qt Design Studio 1.4.0 today, see https://www.qt.io/blog/qt-design-studio-1.4-released. Big thanks to everyone involved! Best Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Nominating Mahmoud Badri as approver
Hi all, I'd like to nominate Mahmoud Badri as an approver for the Qt Project. Mahmoud has been working on Qt 3D Studio and now is contributing to Qt Design Studio and Qt Creator. He is leading the designer experience team for the Qt Company in Oulu. Qt Commits: https://codereview.qt-project.org/q/owner:+mahmoud.badri%2540qt.io Currently, Mahmoud is working on the 3D edit view for Qt Design Studio. Mandatory disclaimer: We work in the same team. I trust him to be a good reviewer. Best regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Qt Design Studio 1.3.1 is released
Hi all, We released Qt Design Studio 1.3.1 today, see https://www.qt.io/blog/qt-design-studio-1.3.1-released Big thanks to everyone involved! Best Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Qt Design Studio 1.3.0 is released
Hi, Qt Design Studio 1.3.0 is released today, see https://www.qt.io/blog/qt-design-studio-1.3-released Big thanks to everyone involved! Best Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Qt Design Studio 1.3 Beta is released
Hi, Qt Design Studio 1.3 Beta is released today, see https://blog.qt.io/blog/2019/08/15/qt-design-studio-1-3-beta-released/ Big thanks to everyone involved! Best Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Qt Design Studio 1.2 final is released
Hi, Qt Design Studio 1.2 final is released today, see https://blog.qt.io/blog/2019/06/03/qt-design-studio-1-2-released/ Big thanks to everyone involved! Best Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Qt Design Studio 1.2 is released
Hi, Qt Design Studio 1.2 is released today, see https://blog.qt.io/blog/2019/05/17/qt-design-studio-1-2-beta-released/ Big thanks to everyone involved! Best Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a module for Qt Quick Timeline Implementation
Hi Frederik, Yes, the module was already created. So the patch in qt/qt5 is 5.14 should be the only thing missing. Yes, I think it is an addon. Best Regards, Thomas Hartmann From: Frederik Gladhorn Sent: Monday, May 13, 2019 1:03:53 PM To: development@qt-project.org Cc: Thomas Hartmann Subject: Re: [Development] Requesting a module for Qt Quick Timeline Implementation Hi Thomas, Since the module exists, it's a bit unclear to me what you request (creating the module would what I'd expect). The next step would be to ask for inclusion in the releases and making a patch to qt/qt5 to enable us shipping the module by default. Then there's the question which state the module would be in, I guess it's "addon" or so. Cheers, Frederik On torsdag 9. mai 2019 10:21:55 CEST Thomas Hartmann wrote: > Hi, > > I would like to request for a new module: > > Name of the repository: qt/qtquicktimeline.git > Description: Module for keyframe-based timeline construction. > Responsible person: Thomas Hartmann > Gerrit user/email: thomas.hartm...@qt.io > > The module is already on gerrit and is in a mature state by now. > The timeline module is used by Qt Design Studio and Qt Quick Designer > but there are use cases independent from tooling. > > One use case is defining 'animations' not in time, but depending on an > expression. This way it is very easy to create complex progress bars or > gauges. > > Best Regards, > Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a module for Qt Quick Timeline Implementation
Hi, > What you're proposing is the inclusion of the existing Qt Quick Timeline > module in Qt 5 as add-on? Yes, the repository itself already exists for quite a while, but I think it is now time to make it part of Qt 5. > I'd suggest to place it into qtdeclarative itself. But I guess that's not an > option because of the license mix (GPL while declarative is LGPL)? Yes, It is a very small module and I agree that it would be a natural fit for qtdeclarative. Mixing LGPL and GPL in a single module is most likely a no go, though. Another reason for a sperate module is the fact that the timeline builds against Qt 5.9 upwards (That is what we tested.) and we want to keep it easy to build against older Qt versions. Best Regards, Thomas Hartmann From: Simon Hausmann Sent: Thursday, May 9, 2019 10:45:12 AM To: Thomas Hartmann; development@qt-project.org Subject: Re: [Development] Requesting a module for Qt Quick Timeline Implementation Ah, just to clarify: What you're request is not a new module, right? What you're proposing is the inclusion of the existing Qt Quick Timeline module in Qt 5 as add-on? I'd suggest to place it into qtdeclarative itself. But I guess that's not an option because of the license mix (GPL while declarative is LGPL)? In terms of maturity etc. I agree and vote in favor of an inclusion. Keyframe based animations are great to use :) Simon From: Development on behalf of Thomas Hartmann Sent: Thursday, May 9, 2019 10:21 To: development@qt-project.org Subject: [Development] Requesting a module for Qt Quick Timeline Implementation Hi, I would like to request for a new module: Name of the repository: qt/qtquicktimeline.git Description: Module for keyframe-based timeline construction. Responsible person: Thomas Hartmann Gerrit user/email: thomas.hartm...@qt.io The module is already on gerrit and is in a mature state by now. The timeline module is used by Qt Design Studio and Qt Quick Designer but there are use cases independent from tooling. One use case is defining 'animations' not in time, but depending on an expression. This way it is very easy to create complex progress bars or gauges. Best Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Requesting a module for Qt Quick Timeline Implementation
Hi, I would like to request for a new module: Name of the repository: qt/qtquicktimeline.git Description: Module for keyframe-based timeline construction. Responsible person: Thomas Hartmann Gerrit user/email: thomas.hartm...@qt.io The module is already on gerrit and is in a mature state by now. The timeline module is used by Qt Design Studio and Qt Quick Designer but there are use cases independent from tooling. One use case is defining 'animations' not in time, but depending on an expression. This way it is very easy to create complex progress bars or gauges. Best Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Requesting a repository for shared components between Qt Creator and Qt 3D Studio.
Hi, There is no standalone release planned. This will be a submodule of Qt Creator and Qt 3D Studio and part of their releases. Best Regards, Thomas Hartmann From: Development on behalf of Thiago Macieira Sent: Tuesday, January 8, 2019 3:21:34 PM To: development@qt-project.org Subject: Re: [Development] Requesting a repository for shared components between Qt Creator and Qt 3D Studio. On Monday, 7 January 2019 06:23:47 PST Thomas Hartmann wrote: > The name of the repository should be 'qtdesigntools' and license of these > components will be GPLV3. I will be responsible. What will the release model be for the content there? Will you use submodules and thus integrate that content as part of the other two's tarballs? Or will there be full releases? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ 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] Requesting a repository for shared components between Qt Creator and Qt 3D Studio.
Hi, I am requesting a repository for shared components between Qt Creator and Qt3DStudio. The Qt Company is developing shared components for Qt Quick Designer/Qt Design Studio and Qt3D Studio. The first component we develope is a curve editor for animations, but there are more shared components planned. The name of the repository should be 'qtdesigntools' and license of these components will be GPLV3. I will be responsible. Best Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Requesting a repository for shared components between Qt Creator and Qt 3D Studio.
Hi, I am requesting a repository for shared components between Qt Creator and Qt3DStudio. The Qt Company is developing shared components for Qt Quick Designer/Qt Design Studio and Qt3D Studio. The first component we develope is a curve editor for animations, but there are more shared components planned. The name of the repository should be 'qtdesigntools' and license of these components will be GPLV3. I will be responsible. Best Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Requesting a repository for shared components between Qt Creator and Qt 3D Studio.
Hi, I am requesting a repository for shared components between Qt Creator and Qt3DStudio. The Qt Company is developing shared components for Qt Quick Designer/Qt Design Studio and Qt3D Studio. The first component we develope is a curve editor for animations, but there are more shared components planned. The name of the repository should be 'qtdesigntools' and license of these components will be GPLV3. I will be responsible. Best Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/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
Development@qt
Re: [Development] OpenGL drivers
Hi, the design was done by a professional designer. I am not a professional designer and so far I trusted external expertise. I did some sanity checks of course and other software products use even smaller fonts. Using pixel size is problematic, but using point sizes is not perfect either. Speaking from experience, any discussion about design, ends in heavy bike shedding. This is why I prefer objective criticism instead of opinions. There will be no design/welcome page everybody likes. What we can provide is a welcome page that works for everybody and does not get into the way. If on your retina display the font is to small (to small to read, smaller then the text of e.g. tool tips etc.), I consider this a bug. Please create a bug report. If the kerning is broken this is most likely a bug in the font rendering. Kind Regards, Thomas Hartmann Am 02/12/2013 19:05, schrieb Robert Knight: yes, this was a conscious decision. Does it create usability issues for you? Digia is trying to sell a UI toolkit for native app development. Surely you want one of Qt's flagship apps to create a good first impression! On 2 December 2013 16:32, Giuseppe D'Angelo dange...@gmail.com wrote: On 2 December 2013 16:44, Thiago Macieira thiago.macie...@intel.com wrote: The project names and paths have blurry fonts because they're way too small. Not to mention the totally broken kernings on the bigger texts (the buttons and the New to Qt area)... :( -- Giuseppe D'Angelo ___ 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, 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. This is a general problem mostly of the web world, but also relevant to webish QML like the welcome page. There is no general solution. You use px size and you annoy people with non standard DPI or other special needs. You use em or percent and you have a really hard time to maintain a consistent layout. Kind Regards, Thomas Hartmann Am 02/12/2013 19:19, schrieb Thiago Macieira: On segunda-feira, 2 de dezembro de 2013 16:28:06, Ziller Eike wrote: On Dec 2, 2013, at 4:44 PM, Thiago Macieira thiago.macie...@intel.com wrote: On segunda-feira, 2 de dezembro de 2013 14:26:29, Thomas Hartmann wrote: Hi, yes, this was a conscious decision. Does it create usability issues for you? Usability? That's debatable. My eyesight is still pretty good, so I can read it. And I never read the project names on the Projects page (I only use the sessions feature). The project names and paths have blurry fonts because they're way too small. So I have to ask: why can't we use regular font size? It's not like we're out of screen real estate... It definitely creates an aesthetic issue, which is subjective, though. Well, we definitely tell it to use such horizontally squashed fonts. family “Helvetica”, pixelSize: 13 Using pixelSize instead of some point size is probably questionable though. Tell it to use system font size too. If you need bigger and smaller tests, add and subtract to it (or multiply), but don't specify hardcoded values. If I had poor eyesight and had configured my system to 18pt fonts so I could read, text with hardcoded font sizes would be unreadable. ___ 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,
the Controls have a Label item.
Kind Regards,
Thomas Hartmann
Am 02/12/2013 13:41, schrieb Robert Knight:
Just use this where you need native looking text:
Having to put that everywhere a Text {} element is used in a
cross-platform app is ugly. One could wrap this in a custom component
but it shouldn't be necessary for such a basic use case.
Regards,
Rob.
On 2 December 2013 11:11, Ziller Eike eike.zil...@digia.com wrote:
On Nov 30, 2013, at 10:29 PM, Mark Gaiser mark...@gmail.com wrote:
On Fri, Nov 29, 2013 at 7:01 PM, Thiago Macieira
thiago.macie...@intel.com wrote:
On sexta-feira, 29 de novembro de 2013 12:27:44, Sletta Gunnar wrote:
So, I'm asking that if you encounter issues with flickering, crashes, bad
rendering and similar, help us track which things are problematic by
filing
a bugreport on bugreports.qt-project.org and use the label driverissue
in
the task. Please include OS, windowing system, graphics hardware and
driver version. And since most of the workarounds have been applied to Qt
5.2, do test against the 5.2 RC1 or later.
Do you consider fonts looking the wrong size to be bad rendering and a
driver
issue? Fonts in the Creator welcome screen look to be of a different size
than
the rest of Creator.
I'd consider it a font issue only, not a driver issue.
What you refer to are probably the fonts rendered through QML. By
default QML renders fonts with the distance field stuff [1]. It
looks awesome on mobile, but looks horrible on the desktop. This has
been known for a while [2] but apparently there is no effort ongoing
to improve the situation for the desktop users.
Globally setting the QML_DISABLE_DISTANCEFIELD variable makes it use
the native font system again and makes it look nice:)
We are already using native text rendering in Qt Creator’s welcome screen,
so that won’t change anything for it.
Br, Eike
[1]
http://blog.qt.digia.com/blog/2011/07/15/text-rendering-in-the-qml-scene-graph/
[2] https://bugreports.qt-project.org/browse/QTBUG-28993
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
--
Eike Ziller, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B
___
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
--
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
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OpenGL drivers
Hi, yes, this was a conscious decision. Does it create usability issues for you? Kind Regards, Thomas Hartmann Am 01/12/2013 03:30, schrieb Thiago Macieira: On sábado, 30 de novembro de 2013 22:29:12, Mark Gaiser wrote: What you refer to are probably the fonts rendered through QML. By default QML renders fonts with the distance field stuff [1]. It looks awesome on mobile, but looks horrible on the desktop. This has been known for a while [2] but apparently there is no effort ongoing to improve the situation for the desktop users. Globally setting the QML_DISABLE_DISTANCEFIELD variable makes it use the native font system again and makes it look nice:) They look exactly the same way. I'm wondering if the smaller and more compressed fonts aren't intentional in the Qt Creator welcome page. ___ 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 Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Platform Content Selection
not see a problem. The selector should also work for file/directory imports. This means the selector can also be applied to directories. More precisely to the base name of a directory if the url is a directory, not to directories which just happen to be part of the path. It is easy even without any IDE to quickly see how many foo.jpg version there are. The use of url handlers make it easy to use this for everything, any resource, not just qml. If all static selectors are close, and also the current static selector, one can drop non used files. So I like Mohamed's suggestion. It's something the QML engine could enable, and should work well with C++ applications too. Not sure about the dynamic selectors, but that's another thread. To clarify the proposed implementation further, I assume the implementation has the following components: A) A function in Qt to translate relative paths into local application area paths B) A function in Qt to translate relative and absolute paths into local application area, selector-aware paths. C) QML engine integration so that URLs (including type and script URLs) can pass through that second function for easy content selection My idea was to implement it like resources are implemented. So it would be a feature in Qt Core not limited to QML at all (and completely transparent for QML). Since QAbstractFileEngine is deprecated in Qt 5, I do not know how feasible this is, but it would be still the preferred way from my side. It would also allow (optional) bundling all resources into a single file during deployment, as a feature for the future (not in the first implementation). I think we should continue to brainstorm and collect ideas, but I think this is the right direction. Kind Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QAction-like API for QML
Am 18/12/2012 00:53, schrieb André Pönitz: But back to the original issue, within the intended context: The point is that with the existence of arbitrary imperative blobs with arbitrary side effects and full access to global data a language's claim to be declarative is hard to defend - both in theory, and in practice. True. Once you have any imperative JS code or any binding to a function with side effects in QML it is clearly not declarative anymore. From the tooling side it is important to emphasize that there is a declarative sub lanugage hidden in QML that we can provide tooling for. But complete QML, including full imperative JS, is not declarative at all. Actually the next version of Qt Quick Designer will explcitly warn about imperative code it finds. Every feature properly supported by visual tooling has to be purely declarative. From the tooling side, not having a strict distincion between declarative and non declarative QML, is problematic at least. We still play with the idea to introduce something like a .qmlui format, which strictly enforces purely declarative QML. The reason we did not so (yet), is that in about 90% of the cases the imperative code is not relevant for the visual design and can be savely ignored by the tool. (e. g. the handler of a button clicked signal). Having that in mind I strongly propose a purely declarative api for actions in QML, if we want to support them in the tooling. Having addiontal imperative APIs is not a show stopper, but we will not support them. Also it has to be 100% that because QML is so much more verbose than .ui files and it includes a turing complete language (JS) there will always be QML files that do not benefit from any visual tooling. Which is not a problem in pratice at all. Kind Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML Singletons
Hi,
it's a bit weird that you need a qmldir for that. Wouldn't it be better if we
could mark this as singleton in the implementation (ie. inside single.qml)?
Maybe use a new keyword for that? static is already a reserved keyword in
Ecmascript 5.1, so we could maybe write single.qml as:
static QtObject {
property int myproperty;
...
}
But how would the engine know about single.qml being static? AFAIK all
.qml parsing is done on demand. The engine would have to know that
single.qml is a singleton from another source (Or scan all .qml files
upfront for the static keyword).
Another approach could be having something like a Singleton.qml in the
plugin.
Singleton.qml would be the general entry point to instantiate QML
singletons for a plugin.
Singleton.qml
Singletons {
MySingleton01 {
id: mySingleton01
}
MySingleton02 {
id: mySingleton02
}
QtObject {
id: mySingleton03
}
...
}
Everything defined in Singletons would be instantiated once in the root
context.
Kind Regards,
Thomas Hartmann
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] HEADS UP: Changes in QStyle subclasses
Hi, we are using QWindows style as a baseline for style sheets in the Qt Quick Designer. I tried using QCommonStyle instead and it works, BUT QToolButton::arrowType does not work with QCommonStyle. It would be nice if this could be fixed, otherwise we have to subclass QCommonStyle and fix this in a custom style. Kind Regards, Thomas Hartmann Am 24/11/2012 12:09, schrieb Nurmi J-P: Hi all, Thanks to QStyleFactory and QProxyStyle, it is possible to instantiate and customize any available style. This is not limited to the built-in styles in QtWidgets, but also works fine for any style plugin since it nicely avoids the build time dependency to the corresponding style implementation. When it comes to the actual style implementations, we have quite a few refactoring ideas on the table. These ideas include class renames, possible merges and inheritance hierarchy changes. Not to mention the possibility of later on pluginizing certain styles to avoid loads of dynamic function resolving. These ideas are not feasible to implement in time for Qt 5.0, and for compatibility reasons cannot be done later if the style implementations remain in the public API. Hence we would like to take this opportunity to hide the following QStyle subclasses from the public API in Qt 5.0: - QFusionStyle - QGtkStyle - QMacStyle - QWindowsCEStyle - QWindowsMobileStyle - QWindowsStyle - QWindowsVistaStyle - QWindowsXPStyle Notice that QCommonStyle will stay public, providing a convenient base for full custom style implementations. We do also realize that QWindowsStyle has been a commonly used base class for custom styles. To address that, we have recently promoted some generic styling code from QWindowsStyle to QCommonStyle, and changed QFusionStyle, QGtkStyle and QMacStyle to inherit QCommonStyle instead. We would like to invite anyone interested in custom styles to give it a try and let us know if any other parts should be promoted too. -- J-P Nurmi ___ 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
