[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&D 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å 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
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 > 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 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 wrote: >> On 2 December 2013 16:44, Thiago Macieira 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, 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] 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 wrote:
>>
>> On Nov 30, 2013, at 10:29 PM, Mark Gaiser wrote:
>>
>>> On Fri, Nov 29, 2013 at 7:01 PM, Thiago Macieira
>>> 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] Platform Content Selection
at direct access URL then the conflict scope is > lessened even further and an effective workaround is provided (because > the only time it's inconvenient to provide a URL is QML type > selection). With that level of compatibility with existing QML, I > think it could be turned on in QQmlApplicationEngine by default > (existing deployed apps still aren't affected, but anyone brining > their QML to the new creator templates would be). If we limit this feature to urls stating with e.g. "res:" I do 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
Am 11/12/2012 10:23, schrieb Knoll Lars:
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).
>
> Sure, but it won't matter until you reference Single somewhere. The singleton
> should not get loaded before that anyway. And once you have a reference to
> it, the QML engine will try to load the file and then figure out it's static.
> That would require some work in the engine, but I think it might be doable.
>
Ah. I thought the singletons would still be referenced by one global id.
If the singleton is accessed by an object definition then the question
is what exactly is allowed.
All properties would probably have to be read only for example, or we
would depend on the order of instantiation.
MySingleton {
id: myLocalAccessId
}
MyItem {
localProperty: myLocalAcessId.property
}
Not sure if just using an id would not be simpler:
MyItem {
localProperty: mySingleton.property
}
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] QML-Development Mailing List
Hi, +1 for Andre. I think we really should emphasise that QML is part of Qt and not something different that has its own mailing list. Also keeping the QML discussions in the core mailing list ensures visibility and might even attract new people to QML. Kind Regards, Thomas Hartmann Am 08/12/2012 19:13, schrieb André Pönitz: > To be honest, I am not sure this is a good idea. Part of the problems of > the past as well as some of them we still have stem from the fact that > QML development was done somehow differently, disconnect from other > parts of the Qt world. > > While this is certainly ok for non-critical add-ons which people can > just ignore when don't need it, I don't think it's acceptable for > something that's touted as Qt's way forward. > > Sure, I can subscribe to yet another mailing list without any > problem, but a lot of people won't. So the already existing > schism is more likely to deepen, instead of being flattened out. > > So please, no. Nobody here is likely to be appalled by discussing > something that's considered a core technology for Qt. > > Andre' > ___ > 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] 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
[Development] QML Tooling Renames (was: Pending decisions on co-installation)
Hi, > qmleasing was for easy importing of After Effects easing curves, and > easingcurveeditor was for more manual manipulation of curves. But both > tools display an easing curve, a rectangle to test it with, and an > array output that you can paste into a QML animation. It makes sense > to have one easing curve tool, which can import from AE and then let > you play with it a bit. Still there's no problem waiting for Thomas to > review it, it's not really urgent (although it would be nice to have > it fit in with the rest of the tool renames). We kept it as two tools, because there was no immediate idea how the ui of the common tool should look like. Then other things got higher priority. If you have a nice solution for integrating qmleasing into easingcurveeditor, I will happily review it. Also most people still do not seem to know about custom easing curves (Context: Developer Days in Berlin). One guy, I talked to, still stated it is an important missing feature. So I am planning to blog about it once 5.0 is out, improving the visibility of the feature. Kind Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
