Re: [Development] Proposal: New branch model

[Aleksey Kontsevich]

Good point. Also thinking this way every time need to deal with Gerrit. Any 
chance to replace it to something more modern and convenient and less time 
wasting like GitLab, etc?

-- 
Best regards,
Aleksey
Linked in  https://www.linkedin.com/in/alekseykontsevich


24.01.2019, 12:28, "Vitaly Fanaskov" :
>> Why not X instead?
>> --
>>
>> - GitFlow, GitHub <= both are based on feature branches, that doesn't 
>> work
>>  well with gerrit.
>
> So, the only problem here is gerrit (aside from personal preferences and
> habits of course). The question is shouldn't we abandon gerrit as this
> tool doesn't feet with the needs well? Inventing new approaches is of
> course super cool... But not always necessary.
>
> What's wrong with using, say, gitflow + gitlab + upsource? Upsource is
> optional, but it's the way better for code review than gerrit.
>
> On 1/23/19 4:51 PM, Jedrzej Nowacki wrote:
>>  Hi,
>>
>> It is time to rethink our branch model. We are approaching Qt6 
>> development
>>  and I'm worried that what we have now, will simply not scale. As you know, 
>> our
>>  branch model is mainly(*) based on merging from stable up to development
>>  branches. In general, it is a very good model, which make sure that release
>>  branches are not getting obsolete too quickly, that most of the fixes are in
>>  the right places, that every commit is only once in the git history. It is a
>>  very clean model. It is also a very slow model, with a single point of
>>  failure.
>>
>> It is hard to maintain:
>> My impression is that the current model works great for a single release
>>  branch, but we have: 5.6 5.9 5.12 and soon we will have 5.13, that is 
>> without
>>  counting temporary patch level branches. Merging through them is hard, we
>>  already had to use "cherry-pick mode" in some places. When we add to the
>>  picture dev and qt6 branches, merging will be very, very hard. It is
>>  practically a full time job to update qt5 repository and coordinate all the
>>  merges now (thank you Liang!), shortly after qt6 branch opening amount of 
>> work
>>  will be much bigger.
>> It is slow:
>> The merges take time. We produce a lot of code, we have a lot of tests 
>> that
>>  needs to pass. Even single failure delays merge propagation by at least one
>>  day. If by bad luck, the merge contains some API incompatible changes an
>>  intermediate jump through Qt5 integration is required, that adds at least 3
>>  days of delay.
>>
>> --
>>
>> Proposal in short: let's use cherry-pick mode everywhere.
>>
>> All(**) changes would go to dev. From which they would be automatically
>>  cherry-picked by a bot to other branches. The decision to which branch 
>> cherry-
>>  pick, would be taken based on a tag in the commit message. We could add a
>>  footer that marks the change risk level as in quip-5 
>> (http://quips-qt-io.herokuapp.com/quip-0005.html), so for example "dev", 
>> "stable", "LTS". By
>>  default everything would be cherry-picked to qt6 branch unless "no-future" 
>> tag
>>  would be given. Of course we can bike-shed about the tag names.
>>
>> Advantages:
>> - no waiting for merges, a fix can be used right away after integration
>> - faster propagation of fixes targeting all branches, as there are no 
>> merges
>>  of merges
>> - simpler for new contributors, always push to dev
>> - in most cases a reviewer does no need to know what the current version
>>  number is
>> - conflict resolution is distributed and affects mostly the author of the
>>  change
>> - documents a change intent, which may be useful for people keeping own
>>  forks
>> - over time with increased amount of conflicts old branches, in natural 
>> way,
>>  stay untouched
>>
>> Disadvantages:
>> - git history would be a bit wilder, "git branch --contains" would not 
>> work
>> - commit messages in some branches would have kind of ugly footer as an
>>  effect of "cherry-pick -x"
>> - there is a chance, that some cherry-picked commits may be left 
>> forgotten
>>  in gerrit after a failed integration
>>
>> Bot details:
>>
>> The bot would listen only for changes in dev, in some unusual cases one
>>  could target an other branch directly, but bot would not trigger automatic
>>  cherry-pick(***). The bot would wait for a successful dev integration before
>>  creating cherry-picked changes. The bot would use cherry-pick -x to annotate
>>  the origin patch. After the cherry-pick creation, it would push it to 
>> gerrit,
>>  +2 and stage once. It would be up to the author to re-stage in case of
>>  flakiness. In case of a cherry-pick conflict it should push unresolved 
>> conflict
>>  to gerrit and add all reviewers and author to handle the issue.
>>
>>  The list below shows branch targets for automatic cherry-pick based on given
>>  tag.
>>
>>  dev (qt6)
>>  stable (qt6, 5.13)
>>  

Re: [Development] Qt 5.13 feature freeze is getting closer

[Aleksey Kontsevich]

Kevin, it is not spyware : Code and docs are open so you can examine it.

-- 
Best regards,
Aleksey
Linked in  https://www.linkedin.com/in/alekseykontsevich



18.01.2019, 04:26, "Kevin Kofler" :
> Aleksey Kontsevich wrote:
>>  Whether Qt Telemetry module will be included:
>>  
>> https://codereview.qt-project.org/gitweb?p=playground%2Ftelemetry.git;a=summary
>>  ?
>
> One discussion point that I miss here is whether spyware tooling should ever
> become a Qt component in the first place, independently of the outcome of
> the code and API reviews.
>
> Kevin Kofler
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 5.13 feature freeze is getting closer

[Aleksey Kontsevich]

Your are mostly talking about the plugin not telemetry module which is ok now. 
And even in the plugin most of your concerns related not to API or logic (there 
was much misunderstanding) like code styling and conventions explicit keyword 
for ctor, connect() styles, comments, etc. 

-- 
Best regards,
Aleksey
Linked in  https://www.linkedin.com/in/alekseykontsevich


17.01.2019, 14:19, "Christian Stenger" :
>> There were not concerns about code quality, :) was concerns about code 
>> styles conventions, etc. All of these was fixed, only qdoc left to do
>
> You must be kidding... This is still a complete mess and definitely not ready 
> for more than a playground.
>
> ____
> From: Development  on behalf of Aleksey 
> Kontsevich 
> Sent: Thursday, January 17, 2019 1:03:55 PM
> To: Maurice Kalinowski; Lars Knoll; Thiago Macieira
> Cc: Qt development mailing list
> Subject: Re: [Development] Qt 5.13 feature freeze is getting closer
>
>> That is beside all the concerns about the quality of the code and missing 
>> actions to fix these.
>
> There were not concerns about code quality, :) was concerns about code styles 
> conventions, etc. All of these was fixed, only qdoc left to do.
>
> --
> Best regards,
> Aleksey
> Linked in https://www.linkedin.com/in/alekseykontsevich
>
> 17.01.2019, 10:22, "Maurice Kalinowski" :
>>  Well even for TP there should be some consensus on whether it should be 
>> part of Qt or not, no?
>>
>>  We are lacking documentation on the process here, all I could find was 
>> https://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt#Graduating_from_the_Playground.
>>
>>  “This decision is done on the qt-development mailing list, based on the 
>> technical and spirit fit to Qt, and it requires the approval of the Chief 
>> Maintainer.”
>>
>>  To my knowledge this has not happened at all. There was only a repository 
>> request so far, none for integrating it into the product line.
>>
>>  That is beside all the concerns about the quality of the code and missing 
>> actions to fix these.
>>
>>  Maurice
>>
>>  From: Development  On Behalf Of Lars 
>> Knoll
>>  Sent: Wednesday, January 16, 2019 8:56 PM
>>  To: Thiago Macieira 
>>  Cc: Qt development mailing list 
>>  Subject: Re: [Development] Qt 5.13 feature freeze is getting closer
>>
>>>  On 16 Jan 2019, at 19:54, Thiago Macieira  
>>> wrote:
>>>
>>>  On Wednesday, 16 January 2019 09:44:40 PST Aleksey Kontsevich wrote:
>>>
>>>>  In Nov, there was long discussion in review:
>>>>  https://codereview.qt-project.org/#/c/240347/ Request was initially for
>>>>  both: plugin and library - latter was transformed to Qt module.
>>>
>>>  Given that this is a complete surprise, I don't think we can find enough 
>>> time
>>>  to do a review of it as a module in time for 5.13.
>>
>>  As far as I understood it the request was for a TP status, not a fully 
>> supported module.
>>
>>>  In particular, I want to
>>>  take a look to see how it can integrate with a project my team is working 
>>> on:
>>>   https://clearlinux.org/documentation/clear-linux/concepts/telemetry-about
>>
>>  Why should that project influence a telemetry module for Qt?
>>
>>>  So I think that for 5.13, the module can be at no higher state than
>>>  experimental. That will allow getting API reviews and testing by others.
>>
>>  See above, I don’t think anything else was being asked for.
>>
>>  Cheers,
>>
>>  Lars
>>
>>  ,
>>
>>  ___
>>  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 mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 5.13 feature freeze is getting closer

[Aleksey Kontsevich]

>That is beside all the concerns about the quality of the code and missing 
>actions to fix these.

There were not concerns about code quality, :) was concerns about code styles 
conventions, etc. All of these was fixed, only qdoc left to do.

-- 
Best regards,
Aleksey
Linked in  https://www.linkedin.com/in/alekseykontsevich



17.01.2019, 10:22, "Maurice Kalinowski" :
> Well even for TP there should be some consensus on whether it should be part 
> of Qt or not, no?
>
> We are lacking documentation on the process here, all I could find was 
> https://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt#Graduating_from_the_Playground.
>
> “This decision is done on the qt-development mailing list, based on the 
> technical and spirit fit to Qt, and it requires the approval of the Chief 
> Maintainer.”
>
> To my knowledge this has not happened at all. There was only a repository 
> request so far, none for integrating it into the product line.
>
> That is beside all the concerns about the quality of the code and missing 
> actions to fix these.
>
> Maurice
>
> From: Development  On Behalf Of Lars Knoll
> Sent: Wednesday, January 16, 2019 8:56 PM
> To: Thiago Macieira 
> Cc: Qt development mailing list 
> Subject: Re: [Development] Qt 5.13 feature freeze is getting closer
>
>> On 16 Jan 2019, at 19:54, Thiago Macieira  wrote:
>>
>> On Wednesday, 16 January 2019 09:44:40 PST Aleksey Kontsevich wrote:
>>
>>> In Nov, there was long discussion in review:
>>> https://codereview.qt-project.org/#/c/240347/ Request was initially for
>>> both: plugin and library - latter was transformed to Qt module.
>>
>> Given that this is a complete surprise, I don't think we can find enough time
>> to do a review of it as a module in time for 5.13.
>
> As far as I understood it the request was for a TP status, not a fully 
> supported module.
>
>> In particular, I want to
>> take a look to see how it can integrate with a project my team is working on:
>>  https://clearlinux.org/documentation/clear-linux/concepts/telemetry-about
>
> Why should that project influence a telemetry module for Qt?
>
>> So I think that for 5.13, the module can be at no higher state than
>> experimental. That will allow getting API reviews and testing by others.
>
> See above, I don’t think anything else was being asked for.
>
> Cheers,
>
> Lars
>
> ,
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 5.13 feature freeze is getting closer

[Aleksey Kontsevich]

In Nov, there was long discussion in review: 
https://codereview.qt-project.org/#/c/240347/ Request was initially for both: 
plugin and library - latter was transformed to Qt module.

-- 
Best regards,
Aleksey
Linked in  https://www.linkedin.com/in/alekseykontsevich


16.01.2019, 19:28, "Thiago Macieira" :
> On Monday, 14 January 2019 09:50:23 PST Aleksey Kontsevich wrote:
>>  Whether Qt Telemetry module will be included:
>>  https://codereview.qt-project.org/gitweb?p=playground%2Ftelemetry.git;a=summ
>>  ary ?
>
> When did this become a Qt module?
>
> The only email with "telemetry" in the past 10 months was a request for a Qt
> Creator plugin.
>
> --
> 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

Re: [Development] Qt 5.13 feature freeze is getting closer

[Aleksey Kontsevich]

>There were lots of comments about coding style and the generic approach

That were fixed.


>Additionally no API review has taken place yet.

That was not done - true.

-- 
Best regards,
Aleksey
Linked in  https://www.linkedin.com/in/alekseykontsevich


15.01.2019, 09:55, "Oliver Wolff" :
> Hi Aleksey,
> On 14/01/2019 18:50, Aleksey Kontsevich wrote:
>>  Hi,
>>
>>  Whether Qt Telemetry module will be included:
>>  
>> https://codereview.qt-project.org/gitweb?p=playground%2Ftelemetry.git;a=summary
>>  ?
>
> If I remember correctly, there was quite a large amount of comments
> about the initial patch. As far as I can see, there were no followup
> commits so I think the status still is, that there is still a lot of
> work to be done until the module can be part of Qt (even as tech preview).
>
> There were lots of comments about coding style and the generic approach
> for example. Additionally no API review has taken place yet.
>
> I doubt that the module will be ready in time for 5.13 in its current state.
>
> Best regards,
> Olli
>
>>  --
>>  Best regards,
>>  Aleksey
>>  Linked in https://www.linkedin.com/in/alekseykontsevich
>>
>>  14.01.2019, 13:01, "Jani Heikkinen" :
>>>  Hi all,
>>>
>>>  There is only a bit more than two week to Qt 5.13 feature freeze, see 
>>> https://wiki.qt.io/Qt_5.13_Release. At this point we should already know if 
>>> there will be some new submodules in Qt 5.13 so please get possible new 
>>> submodule in qt5 as soon as possible; those really needs to be in before we 
>>> start soft branching (25.1.2019)! And of course inform us about those new 
>>> submodules; we need to create packaging configurations for
>>>  those as well.
>>>
>>>  And please start updating Qt 5.13 new features page here: 
>>> https://wiki.qt.io/New_Features_in_Qt_5.13
>>>
>>>  br,
>>>  Jani Heikkinen
>>>  Release Manager
>>>
>>>  ___
>>>  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 mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 5.13 feature freeze is getting closer

[Aleksey Kontsevich]

Hi,

Whether Qt Telemetry module will be included: 
https://codereview.qt-project.org/gitweb?p=playground%2Ftelemetry.git;a=summary
?

-- 
Best regards,
Aleksey
Linked in  https://www.linkedin.com/in/alekseykontsevich


14.01.2019, 13:01, "Jani Heikkinen" :
> Hi all,
>
> There is only a bit more than two week to Qt 5.13 feature freeze, see 
> https://wiki.qt.io/Qt_5.13_Release. At this point we should already know if 
> there will be some new submodules in Qt 5.13 so please get possible new 
> submodule in qt5 as soon as possible; those really needs to be in before we 
> start soft branching (25.1.2019)! And of course inform us about those new 
> submodules; we need to create packaging configurations for
> those as well.
>
> And please start updating Qt 5.13 new features page here: 
> https://wiki.qt.io/New_Features_in_Qt_5.13
>
> br,
> Jani Heikkinen
> Release Manager
>
> ___
> 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] Qwt and Qt Charts

[Aleksey Kontsevich]

Renamed discussion topic. :) Agree with Uwe. I was using Qwt for many years and 
was surprised when Qt Charts appeared. Thought it has some advantages or 
interesting effects. If not, it is also not clear to me why not to contribute 
to Qwt which is feature rich, extremely fast and make it candy, modern look and 
feel and standard de facto for Qt? Existing chart solutions for Qt are too poor 
comparing with D3.js features for example - good to improve!

-- 
Best regards,
Aleksey
Linked in  https://www.linkedin.com/in/alekseykontsevich



10.01.2019, 14:22, "Uwe Rathmann" :
> On Thu, 10 Jan 2019 10:48:37 +, Tuukka Turunen wrote:
>
>>  Related to your comment about the Qt Charts being limited I would tend
>>  to disagree.
>
> https://www.qtcentre.org/threads/69718-QChartView-and-QScatterSeries-
> overrdide-the-label-of-a-QPointF
>
> https://www.qtcentre.org/threads/69094-3D-Plot
>
> I leave it up to you to google for more ...
>
> You might have noticed, that questions on the Qt mailing lists regarding
> Qt/Charts mostly end up in not being answered, but at least you find this
> statement from the maintainer:
>
> https://lists.qt-project.org/pipermail/development/2016-November/
> 055337.html
>
> If you prefer "simple charting" or "not be the be-all-end-all charting
> solution" over "limited" - I don't care, we can agree on Miikkas wording.
>
> But it doesn't affect my conclusion, that Qt users ( including your
> customers ) would have a better solution, if you would have contributed
> to an existing 3rd party library instead of reinventing the wheel.
>
>>  Discussion about Qt Charts is of course welcome, but perhaps not that
>>  relevant for discussion about creating a new repository for Lottie-Qt.
>
> True, but Qt/Chart is a good example of what happens, when ignoring
> existing 3rd party software without technical reasons.
>
> And on a more general note: if LGPLv2+ makes code not being appropriate
> for the Qt project, then don't be surprised that you are not attractive
> for developers without having a business case in mind.
>
> My 2 cents,
> Uwe
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started

[Aleksey Kontsevich]

Just answered. As I said my email does not functioning (disabled), so did not 
see the question. Actually initial bug description contains full url.

-- 
Best regards,
Aleksey
Linked in  https://www.linkedin.com/in/alekseykontsevich


07.01.2019, 10:44, "Denis Kormalev" :
> I would at least suggest to answer Ekkehard and BogDan in QTBUG-72687. They 
> are waiting for 4 days for answer from you.
>
> --
> Regards,
> Denis Kormalev
>
>>  On Jan 7, 2019, at 12:08 AM, Aleksey Kontsevich  wrote:
>>
>>  Very strange. May I move them to P0-Blocker then? :)
>>
>>  --
>>  Best regards,
>>  Aleksey
>>  Linked in https://www.linkedin.com/in/alekseykontsevich
>>
>>  07.01.2019, 07:37, "Jani Heikkinen" :
>>>>   -Original Message-
>>>>   From: Development  On Behalf Of
>>>>   Aleksey Kontsevich
>>>>   Sent: lauantai 5. tammikuuta 2019 12.23
>>>>   To: ekke ; developm...@lists.qt-project.org
>>>>   Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1'
>>>>   started
>>>>
>>>>   Hi,
>>>>
>>>>   What about QTBUG-72687 and QTBUG-72227?
>>>
>>>  QTBUG-72687 or QTBUG-72227 aren't really a release blocker, sorry.
>>>
>>>  br,
>>>  Jani
>>  ___
>>  Development mailing list
>>  Development@qt-project.org
>>  https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started

[Aleksey Kontsevich]

I see, will do now. My email is blocked so did not see issue needs more info.

-- 
Best regards,
Aleksey
Linked in  https://www.linkedin.com/in/alekseykontsevich


07.01.2019, 10:29, "Andy Shaw" :
> Unfortunately no (
>
> Though if you want them to be addressed sooner, then at least providing the 
> missing info for QTBUG-72687 would help in that case at least.
>
> Andy
>
> -Opprinnelig melding-
> Fra: Development  på vegne av Aleksey 
> Kontsevich 
> Dato: mandag 7. januar 2019 09:23
> Til: Jani Heikkinen , ekke , 
> "developm...@lists.qt-project.org" 
> Emne: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started
>
> Very strange. May I move them to P0-Blocker then? :)
>
> --
> Best regards,
> Aleksey
> Linked in https://www.linkedin.com/in/alekseykontsevich
>
> 07.01.2019, 07:37, "Jani Heikkinen" :
> >> -Original Message-
> >> From: Development  On Behalf Of
> >> Aleksey Kontsevich
> >> Sent: lauantai 5. tammikuuta 2019 12.23
> >> To: ekke ; developm...@lists.qt-project.org
> >> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1'
> >> started
> >>
> >> Hi,
> >>
> >> What about QTBUG-72687 and QTBUG-72227?
> >
> > QTBUG-72687 or QTBUG-72227 aren't really a release blocker, sorry.
> >
> > br,
> > Jani
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started

[Aleksey Kontsevich]

Very strange. May I move them to P0-Blocker then? :)

-- 
Best regards,
Aleksey
Linked in  https://www.linkedin.com/in/alekseykontsevich


07.01.2019, 07:37, "Jani Heikkinen" :
>>  -Original Message-
>>  From: Development  On Behalf Of
>>  Aleksey Kontsevich
>>  Sent: lauantai 5. tammikuuta 2019 12.23
>>  To: ekke ; developm...@lists.qt-project.org
>>  Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1'
>>  started
>>
>>  Hi,
>>
>>  What about QTBUG-72687 and QTBUG-72227?
>
> QTBUG-72687 or QTBUG-72227 aren't really a release blocker, sorry.
>
> br,
> Jani
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started

[Aleksey Kontsevich]

Hi,

What about QTBUG-72687 and QTBUG-72227?

-- 
Best regards,
Aleksey
Linked in  https://www.linkedin.com/in/alekseykontsevich



05.01.2019, 12:18, "ekke" :
> Am 20.12.18 um 10:40 schrieb Jani Heikkinen:
>>>  ...
>>  Hi!
>>
>>  There is still open p0 (QTBUG-72561) and fixes are coming in '5.12'. That's 
>> why final downmerge is delayed. Target is to get that done still during this 
>> week. But that means Qt 5.12.1 will happen on January 2019
>>
>>  br,
>>  Jani
>
> Hi,
>
> QTBUG-72561 is fixed, also QTBUG-72101 :)
>
> Thanks to all the hard work done to fix these issues.
>
> Hopefully Qt 5.12.1 now isn't too far away ;-)
>
> Wish you a GREAT 2019
>
> ekke
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 5.12 branch is broken for Android

[Aleksey Kontsevich]

Hi Oswald,

Should I assign this regression to You as well: 
https://bugreports.qt.io/browse/QTBUG-72687?

-- 
Best regards,
Aleksey
Linked in  https://www.linkedin.com/in/alekseykontsevich



02.01.2019, 18:47, "Oswald Buddenhagen" :
> On Wed, Jan 02, 2019 at 02:35:42PM +0200, Bogdan Vatra via Development wrote:
>>    I'm trying to compile Qt for Android and 5.12 branch received quite a lot
>>  configure changes which broke Android builds
>
>>  (though I thought that 5.12 branch is for bug fixes only).
>
> the series did fix quite some bugs, at the cost of being somewhat
> invasive. ok, massively invasive. 5.12 is at the beginning of an LTS
> lifecycle, so i took some liberties. ^^
>
>>  Now configure mixes host libs with the target (android) ones, which IMHO is
>>  very wrong when cross-compiling :).
>>  Can some qmake master take a look and fix the problem?
>
> if you're sure you have the latest revision and a completely clean build
> tree (including no stray .qmake.cache/.stash/.super files there or
> up-tree), make a _proper_ bug report on jira and make sure it's assigned
> to me.
> that applies to any _recent_ regressions introduced by me.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QTBUG-43096 - QML instantiation performance decadence

[Aleksey Kontsevich]

Gyus, why you would not hire Uwe to improve QML/Qt/QQC1/QQC2?! :) -- Best regards,AlekseyLinked in  https://www.linkedin.com/in/alekseykontsevich   26.05.2018, 12:32, "Uwe Rathmann" :On Fri, 25 May 2018 22:35:58 +0200, Robin Burchell wrote:  The first point I would make in reply, though, is that the convenience of creating code with a/b/c are going to be significantly better in my experience.Code for d) look like this:https://github.com/uwerat/qskinny/blob/master/examples/buttons/buttons.qmlIMHO the code for a/b would be very similar, the only one that requiresmore work would be c as you need extra code for creating the buttonitself.  Let's take another good example from the top of my head: Item::anchors. Behind the scenes, it's implemented as a QQuickAnchors, which is a QObject. Let's turn it into a Q_GADGET, and we're done, right?No, but please let's stay with gradients, where the answer is yes.QSkinny offers this class to expose gradients to QML: https://github.com/uwerat/qskinny/blob/master/src/common/QskGradient.hNow when having an control with a property like this:class MyRectangle : public QQuickItem{Q_OBJECTQ_PROPERTY( QskGradient gradient READ gradientWRITE setGradient RESET resetGradient NOTIFY gradientChanged )...};you can write your QML code this way:MyRectangle{gradient {orientation: "Vertical"stops: [{ position: 0.0, color: "MediumAquamarine" },{ position: 0.5, color: "..." },{ position: 1.0, color: "DarkSeaGreen" },]}}The equivalent code offered by Qt/Quick needs 4 QObjects - for eachinstance of an item. So when having 100 rectangles these are 400 QObjects- good for nothing.Uwe___Development mailing listDevelopment@qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt library link errors under Windows

[Aleksey Kontsevich]

Thiago,

Of course all these 1-5 points are followed as You can see visiting 1st 
mentioned link:
https://stackoverflow.com/q/50064670/630169
https://stackoverflow.com/a/50064976/630169

Please take a look at the line which causes the link problem:
QMetaEnum myEnum = QMetaEnum::fromType();

It happen only for combination: Q_NAMESPACE, Q_ENUM_NS(MyEnumClass), build 
under Windows.

You may try it to build yourself under Windows to see the problem: 
https://github.com/akontsevich/ConnectedCreatorPlugin

Thanks! :)

-- 
Best regards,
Aleksey
Linked in  https://www.linkedin.com/in/alekseykontsevich


27.04.2018, 21:18, "Thiago Macieira" <thiago.macie...@intel.com>:
> Hello Aleksey
>
> None of your questions looks like problems in Qt itself, so I've taken the
> liberty of replying to the interest mailing list (discussion about *using*
> Qt).
>
> On Friday, 27 April 2018 10:11:52 PDT Aleksey Kontsevich wrote:
>>  mydialog.obj:-1: error: LNK2001: unresolved external symbol
>>  "struct QMetaObject const MyLibrary::staticMetaObject"
>>  (?staticMetaObject@MyLibrary@@3UQMetaObject@@B)
>
> Make sure that:
>
> 1) class MyLibrary is in a header file
> 2) that header file is listed in the library's .pro file HEADERS line
> 3) moc was run in the header and the resulting output was compiled
> 4) your definition contains an export macro:
>
>   class MY_LIBRARY_EXPORT MyLibrary : 
>
> 5) said macro is __declspec(dllexport) when compiling the library and
> __declspec(dllimport) when linking the library. This is "Windows DLL Basics"
> and you need to learn it.
>
> --
> 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] Qt library link errors under Windows

[Aleksey Kontsevich]

Project builds just fine in Linux, however fails to link under Windows.  
Building with Qt 5.10.1 and MSVC 2015.

1st issue (solved)
Solved here: https://stackoverflow.com/q/50064670/630169
--

2nd issue:
In the library .pro file VERSION variable is defined and resulting library has 
name MyLibrary1.lib. Thereafter I get error:

:-1: error: LNK1181: cannot open input file 'MyLibrary.lib'

What is better way to solve the problem here: remove VERSION or fix .pro file? 
How?
--

3rd issue:
Another link error:

mydialog.obj:-1: error: LNK2001: unresolved external symbol 
"struct QMetaObject const MyLibrary::staticMetaObject" 
(?staticMetaObject@MyLibrary@@3UQMetaObject@@B)

Error happen because of the following line in code (disappears when commented 
out):

## mydialog.cpp:

QMetaEnum myEnum = QMetaEnum::fromType();

## mylibrary.cpp:

namespace MyLibrary {

Q_NAMESPACE

enum class MYLIBRARYSHARED_EXPORT MyEnumClass {
...
};

Q_ENUM_NS(MyEnumClass)
...
} // namespace MyLibrary

And how to solve the 3rd one? What is it: Qt or Windows (MSVC) bug? Code or 
link flags problem?

Thanks!

-- 
Best regards,
Aleksey
Linked in  https://www.linkedin.com/in/alekseykontsevich
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Free VPN server required

[Aleksey Kontsevich]

Write petition to Rostelecom? -- Best regards,AlekseyLinked in  https://www.linkedin.com/in/alekseykontsevich   25.04.2018, 11:37, "Denis Shienkov" :Hi guys, Is it possible to pick-up a free VPN server on your side (on Qt-company side) and give for some maintainers the login/password (e.g. for me)?Because reason is that (ours russian goverment) blockes the some other resources. The Qt resources fall into this by accident, and then it is not possible to contribute to Qt at all (the git && qt doc and other Qt's resources are blocked). ((( BR,Denis,___Development mailing listDevelopment@qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style

[Aleksey Kontsevich]

Really! I have other information. Many people in IT know about and search for 
Android or iOS alternatives when want to make stuff secure. Also people who 
tried SailfishOS found it very convenient and fast in usage and do not realize 
how they worked without it and with Android before :)

And I'm mostly talking about tendency, trend not some changing or fixed 
"current" state.

-- 
Best regards,
Aleksey
Linked in  https://www.linkedin.com/in/alekseykontsevich


06.04.2018, 21:35, "Konstantin Tokarev" <annu...@yandex.ru>:
> 06.04.2018, 21:18, "Aleksey Kontsevich" <tantr...@ya.ru>:
>>  Hi all,
>>
>>  Only one argument.
>>
>>>  I don't see any point in moving this to QtProject as we don't have 
>>> Sailfish OS platform upstreamed.
>>
>>  Just let's not miss the moment when it become upstreamed. :-) Things move 
>> very fast recent days. Rostelecom and Russian universities make much effort 
>> to promote and advance it. Since it is the only mobile OS certified by FSS, 
>> and only approved by government - it will be the primary OS applications 
>> will be developed for in government and corporate sectors where security is 
>> a corner stone. It is sales hit in Russia currently among civilian users 
>> (https://buyon.ru/1311520/inoi-r7/)
>
> Really? Almost nobody is aware of its existence, even in IT circles, and the 
> only device can be bought in one place. AFAIK it has no presence in mobile 
> shops
>
>>  and become upstreamed very fast with and like Russia become upstreamed 
>> already and become much more developed in nearest future.
>>
>>  Or You mean upstreamed in QtProject? :-) Let's make it upstream then! :-)
>>
>>  Agree with the rest.
>>
>>  --
>>  Best regards,
>>  Aleksey
>>  Linked in https://www.linkedin.com/in/alekseykontsevich
>>
>>  06.04.2018, 18:40, "Alexander Akulich" <akulichalexan...@gmail.com>:
>>>   Hi all,
>>>
>>>   I highly doubt that it can be done as a part of GSoC and I don't see
>>>   any point in moving this to QtProject as we don't have Sailfish OS
>>>   platform upstreamed. We just need this style to make QQC2 applications
>>>   look native on Sailfish OS. I think that we'll have to rely on
>>>   closed-yet components and the style is not going to look nice with
>>>   mocks.
>>>
>>>   That said, I see a number of issues and I hope that we'll discuss and
>>>   agree on some changes to the QQC2 API:
>>>   1) I would like to propose ComboDelegate — a pair of ComboBox and
>>>   Label, combined in a platform-specific way (similar to CheckDelegate
>>>   and RadioDelegate).
>>>   2) We also need a delegate to display a label and an associated value.
>>>   It is named "DetailItem" in Silica, but I would agree to go with a
>>>   name like ValueDelegate.
>>>   3) Yet another point is that we need to properly style delegate
>>>   descriptions, so I want to propose "description" property at least for
>>>   Combo, Radio and Switch delegates (we even don't have a 'buddy'
>>>   property here, though it still would be very hacky to go in this way).
>>>
>>>   Probably it makes sense to start another thread to discuss Qt Quick
>>>   Controls 2 API, but I need at least three weeks to think and
>>>   experiment with what we have right now. :-)
>>>
>>>   My work is available at
>>>   https://git.merproject.org/Kaffeine/qtsilicastyle (compatible with Qt
>>>   5.9 and 5.10), but I don't think that it can be interesting for anyone
>>>   in its current shape.
>>>
>>>   On Fri, Apr 6, 2018 at 4:11 PM, Alexey Andreyev
>>>   <yetanotherandre...@gmail.com> wrote:
>>>>    Got it, thank you, Mitch! :)
>>>>
>>>>    Yes, I have contacted Jolla devs, got answer:
>>>>
>>>>> Providing Sailfish support for Qt Quick Controls 2 would definitely be
>>>>>    valuable. Sailfish OS cannot build app ecosystem alone, and improving 
>>>>> the
>>>>>    cross-platform story would help us getting Qt app contributions from 
>>>>> other
>>>>>    platforms, and help 3rd party developers target multiple platforms like
>>>>>    Android and iOS with the same code base.
>>>>
>>>>>    You are free to use what license you choose, but I would recommend
>>>>>    something permissive like BSD3 or LGPL2, which we also use in Sailfish 
>>>>> OS
>>&

Re: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style

[Aleksey Kontsevich]

und repo is documented here:
>>>
>>>  
>>> http://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt#Getting_started_with_new_ideas_on_Qt_Project.27s_Playground.
>>>
>>>  Have you discussed this project with the Sailfish devs, by the way?
>>>  Perhaps they would be interested in integrating your efforts upstream.
>>>
>>>  One potential problem I see is that it seems that the source code is not
>>>  public:
>>>
>>>  
>>> https://together.jolla.com/question/6780/request-sourcecode-for-silica-core-components/
>>>
>>>  The closest thing is this repo, which doesn’t seem to be complete:
>>>
>>>  https://github.com/dm8tbr/sailfishsilica-qt5
>>>
>>>  How do you plan on implementing the style in light of this?
>>>
>>>  Speaking for myself: I would be happy to answer any questions you may have
>>>  with regards to implementing a Controls 2 style, but I don’t think I can 
>>> put
>>>  aside enough time to be a mentor for this.
>>>
>>>  Cheers.
>>>
>>>  From: Alexey Andreyev [mailto:yetanotherandre...@gmail.com]
>>>  Sent: Tuesday, 3 April 2018 2:14 PM
>>>  To: Aleksey Kontsevich <tantr...@ya.ru>
>>>  Cc: Mitch Curtis <mitch.cur...@qt.io>; development@qt-project.org
>>>
>>>  Subject: Re: [Development] [Google Summer of Code] [Project Ideas] Qt
>>>  Quick Controls 2 Sailfish Silica Style
>>>
>>>  Hi, Aleksey Kontsevich! Thank you for your support, I do agree that
>>>  Sailfish OS is receiving a huge contribution from Russian speaking
>>>  developers and focusing on other local markets too. There's also related
>>>  AsteroidOS community about smartwatches. They have a demo [1]
>>>
>>>  Talking about popularity: from my point of view, while Microsoft is
>>>  providing their Metro unified look for desktop and Intel-based tablets (and
>>>  Xbox) for example, looks like they do not have any plans for new mobile
>>>  devices (I mean arm-based) to provide. While Sailfish OS is mobile OS with
>>>  GSM-stack support for real arm-based systems. [1] Correct me if I'm wrong, 
>>> I
>>>  do not want to mislead anyone.
>>>
>>>  Mitch Curtis, thank you for your feedback sincerely. I do understand your
>>>  skepticism about yet another controls in mainline to support. (but I do not
>>>  share this personally :)
>>>
>>>  I'm new to qqc2 internals. I've cloned qtquickcontrols2 repo 5.10.1 brach
>>>  (to play on my Arch Linux system). Dependency from some private APIs looks
>>>  tricky for me at first glance. I'm trying to sort out. I'm not against
>>>  providing silica style as some custom repo, the result I want to get is 
>>> open
>>>  source solution to run Qt application in my personal environment with 
>>> native
>>>  Silica look and feel. Will be happy to get any hints about basic repo draft
>>>  in that case (should I look at Kirigami approach?)
>>>
>>>  Anyway, as I wrote at my GSoC proposal, GSoC campaign is just money
>>>  support, I love Silica style, using Sailfish OS for several years and can't
>>>  stand that no one is willing to port it to modern QQC2 approach :) I guess
>>>  it could radically change skepticism about qt quick controls approach in
>>>  general from ios and android developers.
>>>
>>>  [1]: https://www.youtube.com/watch?v=Rd86KTs2Les
>>>
>>>  [2]: https://wiki.merproject.org/wiki/Adaptations/libhybris
>>>
>>>  2018-04-03 13:38 GMT+03:00 Aleksey Kontsevich <tantr...@ya.ru>:
>>>
>>>  Hi all, my 2 cents here:
>>>
>>>  >The controls look nice, but my concern is how relevant the Silica style
>>>  > is these days (in the context of how many people are developing apps for 
>>> the
>>>  >Sailfish OS).
>>>
>>>  Sailfish OS become VERY popular in Russia and in Latin America, and for
>>>  people who wants their data and communication be secure. Market in Russia
>>>  growing very fast, Sailfish OS devices are hits of sales, leading
>>>  universities created courses for Sailfish OS, government certified
>>>  it for corporate and government use and since 2019 all mobile applications
>>>  from national software list (government and corporate use) should work in
>>>  Sailfish OS (according to import replacing law all applications should be
>>>  Russian-native and secure).
>>>
>>>  --
>&g

Re: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style

[Aleksey Kontsevich]

qpm for Qt is an npm analogue for Node.JS? Cool!

-- 
Best regards,
Aleksey
Linked in  https://www.linkedin.com/in/alekseykontsevich



03.04.2018, 15:42, "Jean-Michaël Celerier" <jeanmichael.celer...@gmail.com>:
> If the controls don't end up in qtquickcontrols2, please at least consider 
> putting them in qpm (https://www.qpm.io/) so that other people can benefit 
> from them easily :)
>
> ---
> Jean-Michaël Celerier
> http://www.jcelerier.name
>
> On Tue, Apr 3, 2018 at 2:13 PM, Alexey Andreyev 
> <yetanotherandre...@gmail.com> wrote:
>> Hi, Aleksey Kontsevich! Thank you for your support, I do agree that Sailfish 
>> OS is receiving a huge contribution from Russian speaking developers and 
>> focusing on other local markets too. There's also related AsteroidOS 
>> community about smartwatches. They have a demo [1]
>>
>> Talking about popularity: from my point of view, while Microsoft is 
>> providing their Metro unified look for desktop and Intel-based tablets (and 
>> Xbox) for example, looks like they do not have any plans for new mobile 
>> devices (I mean arm-based) to provide. While Sailfish OS is mobile OS with 
>> GSM-stack support for real arm-based systems. [1] Correct me if I'm wrong, I 
>> do not want to mislead anyone.
>>
>> Mitch Curtis, thank you for your feedback sincerely. I do understand your 
>> skepticism about yet another controls in mainline to support. (but I do not 
>> share this personally :)
>> I'm new to qqc2 internals. I've cloned qtquickcontrols2 repo 5.10.1 brach 
>> (to play on my Arch Linux system). Dependency from some private APIs looks 
>> tricky for me at first glance. I'm trying to sort out. I'm not against 
>> providing silica style as some custom repo, the result I want to get is open 
>> source solution to run Qt application in my personal environment with native 
>> Silica look and feel. Will be happy to get any hints about basic repo draft 
>> in that case (should I look at Kirigami approach?)
>>
>> Anyway, as I wrote at my GSoC proposal, GSoC campaign is just money support, 
>> I love Silica style, using Sailfish OS for several years and can't stand 
>> that no one is willing to port it to modern QQC2 approach :) I guess it 
>> could radically change skepticism about qt quick controls approach in 
>> general from ios and android developers.
>>
>> [1]: https://www.youtube.com/watch?v=Rd86KTs2Les
>> [2]: https://wiki.merproject.org/wiki/Adaptations/libhybris
>>
>> 2018-04-03 13:38 GMT+03:00 Aleksey Kontsevich <tantr...@ya.ru>:
>>> Hi all, my 2 cents here:
>>>
>>>>The controls look nice, but my concern is how relevant the Silica style is 
>>>>these days (in the context of how many people are developing apps for the
>>>>Sailfish OS).
>>>
>>> Sailfish OS become VERY popular in Russia and in Latin America, and for 
>>> people who wants their data and communication be secure. Market in Russia 
>>> growing very fast, Sailfish OS devices are hits of sales, leading 
>>> universities created courses for Sailfish OS, government certified
>>> it for corporate and government use and since 2019 all mobile applications 
>>> from national software list (government and corporate use) should work in 
>>> Sailfish OS (according to import replacing law all applications should be 
>>> Russian-native and secure).
>>>
>>> --
>>> Best regards,
>>> Aleksey
>>> Linked in  https://www.linkedin.com/in/alekseykontsevich
>>>
>>> 03.04.2018, 13:13, "Mitch Curtis" <mitch.cur...@qt.io>:
>>>> Hi Alexey.
>>>>
>>>> The controls look nice, but my concern is how relevant the Silica style is 
>>>> these days (in the context of how many people are developing apps for the 
>>>> Sailfish OS).
>>>>
>>>> For each style we currently have, I would justify their inclusion into 
>>>> qtquickcontrols2.git for the following reasons:
>>>>
>>>> Default - extremely high performance at the cost of a very basic 
>>>> appearance. Tries to be neutral in terms of looks.
>>>>
>>>> Fusion - bridges the gap in terms of Desktop styling. An additional/more 
>>>> specific point that I think it is important here is that the controls are 
>>>> more compact (smaller) than any other pre-built style we offer (the 
>>>> Material style has a dense variant now, but that’s still larger if I 
>>>> recall correctly).
>>>>
>>>> Imagine - p

Re: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style

[Aleksey Kontsevich]

Hi all, my 2 cents here:

>The controls look nice, but my concern is how relevant the Silica style is 
>these days (in the context of how many people are developing apps for the 
>Sailfish OS).

Sailfish OS become VERY popular in Russia and in Latin America, and for people 
who wants their data and communication be secure. Market in Russia growing very 
fast, Sailfish OS devices are hits of sales, leading universities created 
courses for Sailfish OS, government certified 
it for corporate and government use and since 2019 all mobile applications from 
national software list (government and corporate use) should work in Sailfish 
OS (according to import replacing law all applications should be Russian-native 
and secure).

-- 
Best regards,
Aleksey
Linked in  https://www.linkedin.com/in/alekseykontsevich



03.04.2018, 13:13, "Mitch Curtis" :
> Hi Alexey.
>
> The controls look nice, but my concern is how relevant the Silica style is 
> these days (in the context of how many people are developing apps for the 
> Sailfish OS).
>
> For each style we currently have, I would justify their inclusion into 
> qtquickcontrols2.git for the following reasons:
>
> Default - extremely high performance at the cost of a very basic appearance. 
> Tries to be neutral in terms of looks.
>
> Fusion - bridges the gap in terms of Desktop styling. An additional/more 
> specific point that I think it is important here is that the controls are 
> more compact (smaller) than any other pre-built style we offer (the Material 
> style has a dense variant now, but that’s still larger if I recall correctly).
>
> Imagine - puts power in the hands of designers, frees up time for developers.
>
> Material - very relevant in terms of Android market share. Looks really nice; 
> a good candidate for “non-native” cross-platform apps.
>
> Universal - relevant in terms of Windows market share.
>
> As mentioned, I do think the Silica controls look nice, but that’s the only 
> justification I could think of for including them in qtquickcontrols2.git. 
> For each new style we add, the maintenance cost increases, so this is 
> something that we need to consider.
>
> What is your opinion on this?
>
> Cheers.
>
> From: Alexey Andreyev [mailto:yetanotherandre...@gmail.com]
> Sent: Friday, 23 March 2018 8:49 PM
> To: Mitch Curtis 
> Cc: development@qt-project.org
> Subject: Re: [Development] [Google Summer of Code] [Project Ideas] Qt Quick 
> Controls 2 Sailfish Silica Style
>
> Thank you Mitch for the feedback!
> I've also tried to record current controls on a real device: 
> https://youtu.be/T-qUZMuTGqw (hope not only 360p will be available soon)
>
> 2018-03-23 21:55 GMT+03:00 Alexey Andreyev :
>> Silica cheat sheet:
>> https://sailfishos.org/wp-content/uploads/2016/06/component_cheatsheet.png
>> Theme cheat sheet:
>> https://sailfishos.org/wp-content/uploads/2016/06/theme_cheatsheet.png
>> Icon reference:
>> https://sailfishos.org/wp-content/uploads/2016/06/icon_reference.png
>> code example:
>> https://gist.github.com/jaymzznoori/a980314f8248e0a1e7904c29c88ecdf3
>>
>> Youtube video with timestamp for platform-specific PulleyMenu element 
>> example: https://youtu.be/jByW7UNmbxU?t=11m38s
>>
>> 2018-03-23 21:40 GMT+03:00 Mitch Curtis :
>>> Hello.
>>>
>>> Are there any screenshots of it? I read that entire page and the Silica 
>>> docs but couldn’t see anything.
>>>
>>> Cheers.
>>>
>>> From: Development 
>>> [mailto:development-bounces+mitch.curtis=qt...@qt-project.org] On Behalf Of 
>>> Alexey Andreyev
>>> Sent: Friday, 23 March 2018 5:39 PM
>>> To: development@qt-project.org
>>> Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick 
>>> Controls 2 Sailfish Silica Style
>>>
>>> Hello!
>>> My name is Alexey, what do you think about Silica Style for QQC2 as a gsoc 
>>> project?
>>> I have some notes here: http://aa13q.ru/qqc2-silica-style-en/
>>>
>>> and want to create a proposal.
>
> ,
>
> ___
> 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