Re: [Development] Request moving project (noron) to playground area

[André Hartmann]

Hi Brett,

Am 24.02.2017 um 15:08 schrieb Stottlemyer, Brett (B.S.):

On 2/24/17, 4:05 AM, "Hamed Masafi"  wrote:

  Hi


Hi Hamed


  I'd seen Qt Remote Objects. But is has not any document. I read wiki
  and some information and compiled source and examples. I hope Berrit
  add some information.


I imagine QtRO evolved like most projects, with code preceding documentation.  
It
is documented (although the docs definitely need cleanup before it moves out of 
TP
status), but you need to run make docs on the source to generate the Qt-style 
docs.

The overview and getting started are complete, as are the class descriptions.  
There
are places that needed to be updated with some of the feature changes that have
gone in.

Along those lines, it looks like only Qt 4.8, 5.6 and 5.8 docs are available 
online (from
doc.qt.io).  Is there a way to get to other versions, including possibly the 
5.9-alpha
versions?  Or will the docs for new modules only be available when 5.9 is 
released?
Last question is directed at someone at The Qt Company, but I’m not sure who.


Have a look at http://doc-snapshots.qt.io/

BR, André




  Overlas (as I understand)
  - Share a QObject on server and clients can be access

  Differences:
  Noron can serv an object per peer


You look like you are trying to reinvent QtRO.  I think what you call a Peer is 
what
QtRO calls a Node.  Your Classes are QtRO Source or Replica objects.  From the
limited README, it looks like the main difference is that your Class directly 
connects
to the Peer, while in QtRO you get your Replica from the Node.

You also have a blocking call built in, QtRO doesn’t (but it could be 
implemented in
user code, although it would probably be unwise).

Then there are a bunch of additions in QtRO:
* Registry (so you don’t need to know the address of every object)
* PODs/Enums (so you can pass more useful types)
* QAIM support (built in)
* Support for multiple backends (tcp/ip, localsocket, QNX backend right now)
* etc..

Hopefully if there are features you think are missing in QtRO you would 
contribute
to the module already going into Qt rather than creating another module?

Regards,
Brett

___
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] Maintenance Tool with offline install function?

[André Hartmann]

Hi all,

Yesterday I installed a Qt 5.9 beta snapshot and I'm impressed how much 
the Maintenance Tool improved! The possibility to install Qt versions in 
parallel and to remove single components is awesome!


There is one thing missing to make it perfect: Allow to store the 
downloaded archives local and install from that location later (The 
Cygwin setup allows this in a similar matter).


This will surely help all the companies where computers have on internet 
access at all. So far I have always downloaded the offline installers 
(Windows mostly), but thats a pain if you need them in parallel or want 
to update Qt Creator at a time (I don't remember how often I have set up 
Qt versions and Kits in Creator).


There is already a bugreport for this: 
https://bugreports.qt.io/browse/QTIFW-573 but there is no progress since 
two years.


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

Re: [Development] Release plan moving forward

[André Hartmann]

Hi Uwe,


On Tue, 09 May 2017 13:35:52 +, Lars Knoll wrote:


So we are now planning to make Qt 5.9 a LTS release. It's been 3 minor
releases since 5.6 and a lot of good things have happened in Qt, so this
should be very good news to those of our users that don't always want to
be on the bleeding edge but are looking for a stable version that's
supported for a long time.


Having more LTS releases is great, but I hope this does not mean, that
support for previous LTS releases will end ?

F.e. we have chosen 5.6 because of being a LTS release, hoping for "long"
being something long.


From Lars original mail:

> Of course, we will also continue to support 5.6 for the promised
> three years. We are planning to release 5.6.3 in Summer, after which
> 5.6 will move into the 'very strict' mode as defined in the branch
> policy QUIP.

André



ciao,
Uwe

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




--
Best regards / Mit freundlichen Grüßen
André Hartmann, Dipl.-Ing. (FH)
Software Project Manager

iseg Spezialelektronik GmbH |  phone: ++49 (0)351 26996-43
Bautzner Landstr. 23|  fax:   ++49 (0)351 26996-21
D-01454 Radeberg / Rossendorf   |  web:   www.iseg-hv.com

Geschäftsführer / Managing director: Dr. F. Gleisberg, Dr. J. Pöthig
Amtsgericht / Lower district court: Dresden HRB 16250
Ust.-Id.-Nr. / VAT-ID: DE812508942

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder
diese E-Mail irrtümlich erhalten haben, informieren Sie bitte
sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail
in error) please notify the sender immediately and delete this e-mail.
Any unauthorized copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] First Qt 5.9.1 snapshot available

[André Hartmann]

Hi Jani,

I've got two questions regarding the 5.9.1 release:

1. There have been no "changes file" templates provided so far. I guess 
this will lead to last-minute hectic if you want to release in June. It 
would be good to have such templates as soon as the release branch is 
created.


2. For 5.8.0, I saw that binary compatibility files were added. Did I 
miss something or is this discontinued for 5.9.0? How do you assure BC 
during the 5.9 patch releases?


Best regards,
André

Am 14.06.2017 um 08:00 schrieb Jani Heikkinen:

Hi all,

We have first Qt 5.9.1 snapshot available via online installer. It is a 
separate 5.9.1 node, not as an update to Qt 5.9.0. Instructions how to install 
it here: https://wiki.qt.io/How_to_get_snapshot_via_online_installer

Content of the snapshot is based on 
https://codereview.qt-project.org/#/c/196614/, delta to Qt 5.9.0 as an 
attachment.

RTA testing is ongoing and snapshot seems to be pretty much OK. So please test the 
snapshot & report your effort via https://wiki.qt.io/Qt59_release_testing

And please note: We will do regular patch releases for 5.9 series and so on we 
won't block the release because of old issues. Qt 5.9.1 is released on June and 
5.9.2 is targeted to be released on August so if there is still bad issues open 
in 5.9.1 there is time to fix those for soon coming Qt 5.9.2 (or even Qt 5.9.3 
which should be out ~September...)

br,
Jani





___
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] Qt 5.10 pre-built bunaries

[André Hartmann]

Hi Jani,

Am 13.06.2017 um 12:52 schrieb Jani Heikkinen:

Hi,

As a conclusion of subject:

only change related to pre-built binaries for 5.10 (from Qt 5.9) is dropping 32 
bit iOS.
And from 5.11 -> we will drop MSVC2013 as well.

There isn't conclusion about mingw yet but let's agree to switch from mingw 32 
bit to 64 bit one in 5.11


Right, there was no conclusion so far. Are there technical issues that 
you want to discontinue 32 bit packages? Most Windows applications are 
still 32 bit and they run fine in Windows 32 and 64 bit environments.


I still have a Development Notebook running 32 bit Windows 7 and I use 
the Qt MinGW package (as it contains Qt, Creator, Compiler and Debugger 
in one package).


If you drop MSVC2013, could you instead deliver both MinGW 32 and 64 bit?

Best regards,
André



There were also discussion about minimum GCC version but it isn't directly 
related to pre-built binaries and that's why it needs to be concluded in 
different thread

br
Jani
___
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] Nominating Denis Shienkov for Approver status

[André Hartmann]

I'd like to propose the nomination of Denis Shienkov for Approver
status.

Denis has been the maintainer of QtSerialPort for a long time now.
He also formed the architecture of QtSerialBus and provided several CAN 
plugins there. He further contributes to other parts of Qt and QtCreator 
and is actively reviewing other changes (for example he has 
constructively improved a lot of my changes to QtSerialBus).


This is his own Gerrit dashboard:

https://codereview.qt-project.org/#/q/owner:%22Denis+Shienkov+%253Cdenis.shienkov%2540gmail.com%253E%22,n,z

And these are his reviews:

https://codereview.qt-project.org/#/q/reviewer:%22Denis+Shienkov+%253Cdenis.shienkov%2540gmail.com%253E%22,n,z

Best regards,
André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Denis Shienkov for Approver status

[André Hartmann]

Hi Denis,

> WOW, I'm surprised.. Thanks. Need to drink.. :)

But don't drink too much ... you may have to review something later today :)

Honestly, this is also a "thank you" for your long-term Qt contribution. 
Keep it up!


Best regards,
André

Am 01.08.2017 um 12:18 schrieb Denis Shienkov:

WOW, I'm surprised.. Thanks. Need to drink.. :)

2017-08-01 10:20 GMT+03:00 Thiago Macieira >:


On segunda-feira, 31 de julho de 2017 23:54:02 PDT Denis Shienkov wrote:
> WOW, thanks... :)
>
> Q: Approver of what?

In the Qt Project. You get the rights throughout, but you're
expected to only
give +2 when you know what you're doing.

--
Thiago Macieira - thiago.macieira (AT) intel.com 
   Software Architect - Intel Open Source Technology Center

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





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



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

[Development] 5.10 branching status?

[André Hartmann]

Hi all,

We had 5.10 feature freeze two weeks ago but I still see no 5.10 branch 
in Gerrit. That means everything submitted to master now will land in 
5.10?! That effectively blocks master for new features, and if I want 
fixes for 5.10 I have to push them to master also, not knowing when a 
5.10 branch is created.


So my question is: How is the status about 5.10 branching?

Best regards,
André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] 5.10 branching status?

[André Hartmann]

Hi Jani,

thanks for the update. Good luck getting the integration succeeding :)

Best regards,
André

Am 22.08.2017 um 09:13 schrieb Jani Heikkinen:

Hi,


-Original Message-
From: Development [mailto:development-
bounces+jani.heikkinen=qt...@qt-project.org] On Behalf Of André
Hartmann
Sent: tiistai 22. elokuuta 2017 9.21
To: development@qt-project.org
Subject: [Development] 5.10 branching status?

Hi all,

We had 5.10 feature freeze two weeks ago but I still see no 5.10 branch in
Gerrit. That means everything submitted to master now will land in 5.10?!
That effectively blocks master for new features, and if I want fixes for 5.10 I
have to push them to master also, not knowing when a
5.10 branch is created.

So my question is: How is the status about 5.10 branching?



We are still waiting successfully qt5.git integration before we can start 
branching. There has been progress but few tests are still failing and so on 
blocking the successfully qt5.git integration. You can follow-up the progress from 
https://codereview.qt-project.org/#/c/201350/ & see open blockers from 
https://bugreports.qt.io/issues/?filter=18856
  
The plan is to start branching immediately after qt5.git integration succeed in 'dev' . Final downmerge from 'dev' to '5.10' will be done ~after a week from starting. So yes, unfortunately this means new feature development in blocked in 'dev' at the moment, sorry about that. We are doing our best to proceed as soon as possible


br,
Jani




--
Best regards / Mit freundlichen Grüßen
André Hartmann, Dipl.-Ing. (FH)
Software Project Manager

iseg Spezialelektronik GmbH |  phone: ++49 (0)351 26996-43
Bautzner Landstr. 23|  fax:   ++49 (0)351 26996-21
D-01454 Radeberg / Rossendorf   |  web:   www.iseg-hv.com

Geschäftsführer / Managing director: Dr. F. Gleisberg, Dr. J. Pöthig
Amtsgericht / Lower district court: Dresden HRB 16250
Ust.-Id.-Nr. / VAT-ID: DE812508942

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder
diese E-Mail irrtümlich erhalten haben, informieren Sie bitte
sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail
in error) please notify the sender immediately and delete this e-mail.
Any unauthorized copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Maintainers, your actions needed: Change files for Qt 5.6.3

[André Hartmann]

Hi Jani,

I have some comments to the change file process:

1. The commit message is "Add change file for Qt 5.6.3" but it should be
   "Add changes file for Qt 5.6.3" (plural)
2. In the last releases, this initial version was WIP, so the maintainer
   needed to adjust the message so it could be merged. I think this is
   useful.
3. How about projects with no changes between 5.6.2 and 5.6.3
   (like qtserialbus)? Usually there is also a changes file with a line
   "No relevant changes in this release", but right now there is no file
   a all.

I know it is some effort for the release team to create these templates,
but with good templates you get consistent final files for the whole
project.

Best regards,
André

Am 29.08.2017 um 06:53 schrieb Jani Heikkinen:

Hi all,

We have now created initial change files for Qt 5.6.3. Please do needed 
modifications immediately and get '+2' as soon as possible. We need to get 
these in to be able to proceed with Qt 5.6.3 release. You can find all open 
change files for Qt 5.6.3 here: 
https://codereview.qt-project.org/#/q/branch:5.9+status:open+message:%22Add+change+file%22,n,z

After approval those change files will be direct pushed in '5.9', cherry picked 
in '5.6.3' and finally direct pushed there, see 
http://lists.qt-project.org/pipermail/development/2017-August/030722.html

br,
Jani Heikkinen
Release Manager


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





--
Best regards / Mit freundlichen Grüßen
André Hartmann, Dipl.-Ing. (FH)
Software Project Manager

iseg Spezialelektronik GmbH |  phone: ++49 (0)351 26996-43
Bautzner Landstr. 23|  fax:   ++49 (0)351 26996-21
D-01454 Radeberg / Rossendorf   |  web:   www.iseg-hv.com

Geschäftsführer / Managing director: Dr. F. Gleisberg, Dr. J. Pöthig
Amtsgericht / Lower district court: Dresden HRB 16250
Ust.-Id.-Nr. / VAT-ID: DE812508942

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder
diese E-Mail irrtümlich erhalten haben, informieren Sie bitte
sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail
in error) please notify the sender immediately and delete this e-mail.
Any unauthorized copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt Coding style and C++11

[André Hartmann]

Hi, since a while C++11 is allowed in Qt and there is ongoing effort 
porting e.g. examples to the new possibilities.


The section "Conventions for C++11 usage" in [1] states:

 "Note: This section is not an accepted convention yet.
  This section serves as baseline for further discussions."

I'd like to push this discussion, because if code is converted to a new 
base, it should be clear to everyone HOW to do so.


What I like to add, is to encourage the use of C++11 member 
initialisation. They are already used in QtSerialBus (from the 
beginning) and QtCreator (ongoing changes to existing codebase).


What do you think?

Best regards,
André

[1] https://wiki.qt.io/Coding_Conventions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Coding style and C++11

[André Hartmann]

Hi Kevin,

Am 15.09.2017 um 10:47 schrieb Kevin Funk:

On Friday, 15 September 2017 06:42:34 CEST André Hartmann wrote:

Hi, since a while C++11 is allowed in Qt and there is ongoing effort
porting e.g. examples to the new possibilities.


Slightly OT but I hope still useful: I'm out of the loop how you are doing
these code transformations, but refactoring code to use C++11 member init can
be largely automated via clang-tidy:
   
https://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidelines-pro-type-member-init.html


> I think one of the real important questions here is: Do we want to do
> large-scale changes on our code base?

Ok, looks like an useful tool! In first case I didn't think on 
mass-conversion from old to new style; I'd like to have rules how new 
code should look like.


If existing code should be changed as drive-by or in one large commit, 
may depend on the maintainers (I already expect good arguments in both 
directions).


> (1) I'd personally really like to see:
> - Replacing all uses Q_DECL_OVERRIDE with override
> - Replacing all uses Q_DECL_NULLPTR with nullptr


That wiki page also still talks about Q_DECL_OVERRIDE, and does not mention
nullptr either. For new code override/nullptr should always be used.


+1

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

Re: [Development] codereview website down?

[André Hartmann]

Am 01.10.2017 um 08:37 schrieb Christian Gagneraud:

https://codereview.qt-project.org is not loading, it hangs. Is it just for me?



Hi Chris,

I was just about asking the same question ;)

"
Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /.

Reason: Error reading from remote server
"

Andre



Chris
___
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] codereview website down?

[André Hartmann]

Am 02.10.2017 um 10:56 schrieb Edward Welbourne:

Am 01.10.2017 um 08:37 schrieb Christian Gagneraud:

https://codereview.qt-project.org is not loading, it hangs. Is it just for me?


André Hartmann (1 October 2017 08:39)

I was just about asking the same question ;)


I trust this is now back in working order for you.
It works for me, at least.

Eddy.



Hi Eddy,

The website started working again yesterday around midday, right.

I just have the problem that some of my patches pushed yesterday [1] 
don't have a sanity review. I looks like the bot took some downtime, too.


Is there anything I can do about without having to upload the patches 
again? This would be very boring for my reviewers too.


Best regards, André

[1] Affected patches:
https://codereview.qt-project.org/#/c/206019/
https://codereview.qt-project.org/#/c/206020/
https://codereview.qt-project.org/#/c/206022/
https://codereview.qt-project.org/#/c/206023/
https://codereview.qt-project.org/#/c/206024/
https://codereview.qt-project.org/#/c/207355/
https://codereview.qt-project.org/#/c/207356/
https://codereview.qt-project.org/#/c/207357/

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

Re: [Development] codereview website down?

[André Hartmann]

Hello again,

I just wanted to give a quick "thank you" to the one (Eddy?) that 
convinced Sanity Bot! Everything is fine now.


André

Am 02.10.2017 um 11:08 schrieb André Hartmann:

Am 02.10.2017 um 10:56 schrieb Edward Welbourne:

Am 01.10.2017 um 08:37 schrieb Christian Gagneraud:
https://codereview.qt-project.org is not loading, it hangs. Is it 
just for me?


André Hartmann (1 October 2017 08:39)

I was just about asking the same question ;)


I trust this is now back in working order for you.
It works for me, at least.

Eddy.



Hi Eddy,

The website started working again yesterday around midday, right.

I just have the problem that some of my patches pushed yesterday [1] 
don't have a sanity review. I looks like the bot took some downtime, too.


Is there anything I can do about without having to upload the patches 
again? This would be very boring for my reviewers too.


Best regards, André

[1] Affected patches:
https://codereview.qt-project.org/#/c/206019/
https://codereview.qt-project.org/#/c/206020/
https://codereview.qt-project.org/#/c/206022/
https://codereview.qt-project.org/#/c/206023/
https://codereview.qt-project.org/#/c/206024/
https://codereview.qt-project.org/#/c/207355/
https://codereview.qt-project.org/#/c/207356/
https://codereview.qt-project.org/#/c/207357/

___
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] Seeking advise using git and code review

[André Hartmann]

Hi Daniel,

thanks for your first contribution.

Reading your message remembers me when I started learning Git and 
contributing to Qt (Creator) some years back ...


The others already said very important things, so I'm just concentrating 
on one:


> When checking the branch  with "git branch", I found that I was on a
> detached head now.

That sounds like you didn't work on a local branch, but rather on the 
remote branch. When commiting there, you go into detached head. But 
that's no problem, it just needs special handling.


> I couldn't go back to the branch, because git told me that I would
> lose my changes.

Then you most likely have uncommited changes there. What does

 git status

say?

Best regards,
André


Am 04.10.2017 um 08:55 schrieb Daniel Savi:

Hello everybody

I've just pushed my first commit to QtGui, trying to follow the 
contribution guidelines posted here 
http://wiki.qt.io/Qt_Contribution_Guidelines. Now I have some questions 
regarding the process. It seems that I have done it at least partly 
wrong ;-)


The codereview to my changes is as follows: 
https://codereview.qt-project.org/#/c/207540/


After pushing my changes, the sanity bot found some typos in my commit 
message. Now, how would I proceed? Do I change the commit message? If 
so, how would I do that?


Another probably more serious problem: I've checked out the source for 
5.10 and created a branch "myfix5.10" and used "git checkout myfix5.10". 
Then I mad a diff to my locally changed files in another directory and 
patched the files from 5.10 in a temporary folder. After checking that 
the patched files looked how they should, I copied them back to the 
original folder. Then I did a "git commit -a". When checking the branch 
with "git branch", I found that I was on a detached head now. I couldn't 
go back to the branch, because git told me that I would lose my changes. 
So I pushed them anyway. Now, my submit type in Gerrit is "cherry pick". 
What should I have done, when encountering the detached head state? Is 
the "cherry pick" type a problem?


Third and last, I didn't know how to find reviewers so I picked some 
almost randomly from the git log and added the QtGui maintainer, too. 
Probably not such a good idea? How could I find reviewers for my changes 
to QTextDocumentWriter?


Sorry for the lengthy post.

___
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] Needing another advise using git

[André Hartmann]

Hi Daniel,

I'm currently reviewing your patch :)

> While amending my commits I must somehow have pushed another commit
> again that is not from me at all. It is this one:
> https://codereview.qt-project.org/#/c/207639/

I think this is no big deal. To avoid more confusion I'd suggest to 
leave everything as-is for now. We can abandon this unneeded commit 
after your patch is submitted. We need to abandon it anyway, but doing 
it now would require a rebase on your side (i.e. dropping it from your 
local commit stack).


Best regards,
André

Am 04.10.2017 um 19:28 schrieb Daniel Savi:

Thank you all for the helpful comments on my previous message.

I think that I have now managed to amend my changes into one commit and 
may understand how to react on comments.


While amending my commits I must somehow have pushed another commit 
again that is not from me at all. It is this one: 
https://codereview.qt-project.org/#/c/207639/


I certainly did not intend to push this one. How should I proceed to 
delete this commit from my changes?


___
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] Speeding up the review process (was: PostgreSQL cross compile for Pi)

[André Hartmann]

Hi Victor,

just my 2 cent to one part:


 4. I don't think we need to be as paranoid towards contributions from > 
our own employees as we need to be towards external contributions.
Anyone with approver rights should be aware of his powers and use them 
carefully, no matter if he is employed at The Qt Company or an external 
contributor.


As it was stated on this mailing list some weeks ago: Only approve if 
you can take the blame on breaking something.


Best regards,
André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Review for new widget module [your advices are needed]

[André Hartmann]

Hi Chris,

Am 16.10.2017 um 08:11 schrieb Christian Gagneraud:
 From an end user point of view, i think it's a great idea but I think 
it conflicts with Qml.
At work we have our own set of highly customised widgets, for embedded 
devices, it simply works, no need (yet) for Qml.


I would be interested to see your work and give my opinion if it can help.

Full disclosure: I've never been a reviewer, but went through the 
process as a contributor a couple of times (qt or not).

Don't expect a +1 from me as I'm not a Qt Project member.


That does not matter. Everyone (with a Qt account) can give a +1. And 
everyone can participate on reviews to make the changes better.


Best regards,
André

Thiago sent a link recently to a blog post regarding code review 
process. Step 1 is all about the idea itself.


Chris

--
Answering from my phone, please excuse my brievity.

On 16/10/2017 6:53 pm, "iman ahmadvand" <mailto:iman72...@gmail.com>> wrote:


No one interested ?

On Sat, Oct 14, 2017 at 11:03 AM, iman ahmadvand
mailto:iman72...@gmail.com>> wrote:

Hi everyone.

Before I send some code base on codereview and decide whether my
implementation meets the requirements,  I  just want to know
your thoughts about design decision for the new module I’m
trying to add to Qt Play ground.

So as you probably guessed my plan is to developing a new widget
module (which I’m going to name it MaterialWidgets) for Qt, a
modern collection of widgets that should have the same look and
feel on all platforms. All the GUI parameters and styles are
taken from material style guide
line(https://material.io/guidelines
<https://material.io/guidelines>). You can think of
MaterialWidgets as the MaterialStyle in QML design but in pure C++.

Here is a few things to clarify:
1.Why someone need to use material styled widgets in Qt?
There are a bunch of app out there that need this to be
available on widgets so they can easily take the benefit of
newly added widget set.

2.Why a new widget set? why just no to use already built-in styles?
Material widgets are going to be a special set of controls which
has animations by default, and GUI parameters are differs from
built-in QtWidgets. for an example material style has a
component called ContinuousSlider which has two sub component
Thumb and Track and two state On(value == 0) and Off(value != 0)
and a color palette for each state, so doing this with styles
can't be done unless we change the enumerators and maybe more!

3.Are every thing from scratch ?
No. not at all.
I just make some changes in inherited classes from built-in
QtWidgets (basics AND abstracts), so the logics behind those
widgets should be the same.

A note for animation implementation  in MaterialWidgets:
A class called Animation is responsible for animating those
widgets, the simple idea behind that is to have a target object
(which mostly is a widget) associated with animation objet and
after every refresh in animation (updateCurrentValue) we should
make an update of type StyleAnimationUpdate in target widget so
it makes the code base more cleaner.

Here you can see just a review version of module (just
ContinuousSlider is included): ​
qtmaterialwidgets.zip

<https://drive.google.com/file/d/0BxRSkzkLrTjVeS1xd0VRMHJQS0k/view?usp=drive_web>
​

I'm ready to hear your advices and thoughts.

Regards
Iman.



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




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




--
Best regards / Mit freundlichen Grüßen
André Hartmann, Dipl.-Ing. (FH)
Software Project Manager

iseg Spezialelektronik GmbH |  phone: ++49 (0)351 26996-43
Bautzner Landstr. 23|  fax:   ++49 (0)351 26996-21
D-01454 Radeberg / Rossendorf   |  web:   www.iseg-hv.com

Geschäftsführer / Managing director: Dr. F. Gleisberg, Dr. J. Pöthig
Amtsgericht / Lower district court: Dresden HRB 16250
Ust.-Id.-Nr. / VAT-ID: DE812508942

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder
diese E-Mail irrtümlich erhalten haben, informieren Sie bitte
sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
Ma

[Development] Nominating Lorenz Haas for approver

[André Hartmann]

Hello all,

I'd like to nominate Lorenz Haas for approver status.

Lorenz has been contributing to Qt and Qt Creator since spring 2013. He 
has provided some high quality patches to Creators C++ Editor and is the 
author of Creators Beautifier plugin.


He is actively reviewing patches in these areas, and recently started 
contributing to and reviewing others patches for Qt OPC UA and MQTT also.


These are his own contributions:
https://codereview.qt-project.org/#/q/owner:%22Lorenz+Haas%22,n,z

and these are his reviews:
https://codereview.qt-project.org/#/q/reviewer:%22Lorenz+Haas%22,n,z

Best regards,
André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Coding style and C++11

[André Hartmann]

Hi Kevin,

Am 15.11.2017 um 17:39 schrieb Kevin Funk:

On Monday, 18 September 2017 10:03:40 CET Kevin Funk wrote:

On Monday, 18 September 2017 09:38:53 CEST Ville Voutilainen wrote:

On 18 September 2017 at 10:36, Lars Knoll  wrote:

But for new plugins that target a known platform that supports c++11,
they can most likely use new conventions. Unless someone can come up
with technical reasons the new c++11 member initialization is better
than what is there now, I’d rather keep it the same as it is now.>>


If you have more than one constructor that set a member to the same
value, it's arguably simpler and less error-prone
to use a member initializer.


I also think that we should be using member initialisers when writing
new
code (or when refactoring existing code). But doing a global
search/replace of existing code might lead to subtle errors as it's easy
to miss the rare case when different constructors initialise members
differently.


Note that if you have both a member initializer and a ctor-initializer
(the colon-list after the constructor signature, X() : foo(a),
bar(b)), the ctor-initializer
is used. It is non-trivial to remove ctor-initializers and replace
them with member-initializers, I don't know whether the clang-tools
can do that.


I have to take back my claim that clang-tidy can automatically transform
initialization via initializer list to initialization via in-class field
initializers.

I just remembered that this cppcoreguidelines-pro-type-member-init checker
just *adds* in-class field initializers for fields which haven't been
initialized altogether *before*. It does nothing if the initializer list
initializes all fields already. So in order to actually port all uses of
initializer lists to something more modern, clang-tidy would need to be
extended.

So I guess the discussion whether to a global search/replace for this
particular C++11 feature is moot for now, since doing this port on all of Qt
is infeasible without proper tooling.


Heya,

And I have to revive this thread again.

Actually the clang-tidy check to do this kind of transformation indeed exists
already (since Clang 5.0 release):
   
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-default-member-init.html


Thanks for the hint.

That reminds me, that the wiki page [1] for C++11 stil states:

  "Note: This section is not an accepted convention yet.
  This section serves as baseline for further discussions."

Regards,
André

[1] https://wiki.qt.io/Coding_Conventions



Just for your information.

Regards,
Kevin
  

Regards,
Kevin

  ___


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




--
Best regards / Mit freundlichen Grüßen
André Hartmann, Dipl.-Ing. (FH)
Software Project Manager

iseg Spezialelektronik GmbH |  phone: ++49 (0)351 26996-43
Bautzner Landstr. 23|  fax:   ++49 (0)351 26996-21
D-01454 Radeberg / Rossendorf   |  web:   www.iseg-hv.com

Geschäftsführer / Managing director: Dr. F. Gleisberg, Dr. J. Pöthig
Amtsgericht / Lower district court: Dresden HRB 16250
Ust.-Id.-Nr. / VAT-ID: DE812508942

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder
diese E-Mail irrtümlich erhalten haben, informieren Sie bitte
sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail
in error) please notify the sender immediately and delete this e-mail.
Any unauthorized copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pushing to gerrit.

[André Hartmann]

Hi Igor,

Am 01.01.2018 um 13:20 schrieb Igor Mironchik:

Hi,



Looks good. Now verify your git remote (is the port correct there?)

Also make sure git uses the right ssh and therefore finds the public 
key.


The problem *is* on your computer.

Are you on Windows?


Think that I found a mistake: possibly this is because of wrong Gerrit 
user name.


I'm on Linux.


I fixed mistake with wrong user name. Now I have following error:

igor@gmi:~/Work/Qt/qt5/qtbase$ git push gerrit HEAD:refs/for/5.10
Enter passphrase for key '/home/igor/.ssh/id_rsa':
Total 0 (delta 0), reused 0 (delta 0)
remote: Processing changes: refs: 1, done
To ssh://igor.mironc...@codereview.qt-project.org:29418/qt/qtbase.git
  ! [remote rejected] HEAD -> refs/for/5.10 (no new changes)
error: failed to push some refs to 
'ssh://igor.mironc...@codereview.qt-project.org:29418/qt/qtbase.git'




Strange. Usually this error appears when you have pushed your changes to 
Gerrit and then try to re-push them without new changes (as the message 
already says).


Have you already committed your changes? Are you on the correct local 
branch?


What does the commands

 git log --pretty=oneline | head

 git branch

say?

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

Re: [Development] Pushing to gerrit.

[André Hartmann]

Am 01.01.2018 um 17:11 schrieb Igor Mironchik:

Hi,


On 01.01.2018 18:50, André Hartmann wrote:

Hi Igor,

Am 01.01.2018 um 13:20 schrieb Igor Mironchik:

Hi,



Looks good. Now verify your git remote (is the port correct there?)

Also make sure git uses the right ssh and therefore finds the 
public key.


The problem *is* on your computer.

Are you on Windows?


Think that I found a mistake: possibly this is because of wrong 
Gerrit user name.


I'm on Linux.


I fixed mistake with wrong user name. Now I have following error:

igor@gmi:~/Work/Qt/qt5/qtbase$ git push gerrit HEAD:refs/for/5.10
Enter passphrase for key '/home/igor/.ssh/id_rsa':
Total 0 (delta 0), reused 0 (delta 0)
remote: Processing changes: refs: 1, done
To ssh://igor.mironc...@codereview.qt-project.org:29418/qt/qtbase.git
  ! [remote rejected] HEAD -> refs/for/5.10 (no new changes)
error: failed to push some refs to 
'ssh://igor.mironc...@codereview.qt-project.org:29418/qt/qtbase.git'




Strange. Usually this error appears when you have pushed your changes 
to Gerrit and then try to re-push them without new changes (as the 
message already says).


Have you already committed your changes? Are you on the correct local 
branch?


What does the commands

 git log --pretty=oneline | head

 git branch

say?


I did a commit on local branch, but after it I had to re-init 
repository. And this did something with the head.


init-repository is effective git submodule update. And yes, that checks 
out the SHA1 of each submodule as it is specified in qt5.git.


Thank you for the suggestion I just checked out my local branch 
again and push completed successfully



Thank you guys.


You're welcome. And thanks for your fix.

Andre

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

Re: [Development] Stop delivering 32 bit MinGW binaries from 5.12 ->

[André Hartmann]

Hi Jani and Roland,

First: Happy New Year to all!

Am 21.12.2017 um 11:59 schrieb Roland Winklmeier:
2017-12-21 11:37 GMT+01:00 Jani Heikkinen >:


With Qt 5.11 it seems we can finally drop MSVC2013 so we could
"temporarily" add MinGW 64 bit pre-build binaries in our packages in
addition to 32 bit ones and remove 32 bit MinGW pre-built binaries
from 5.12 onwards. Making this decision now would complete this
discussion finally and still give users time to move from 32 bit to
64 bit ones...


Hi Jani,

adding MinGW 64 bit sounds great. I would prefer to keep the MinGW 32 
bit ones too, because there are several projects which are plugins to 
host applications in 32 bit. So sometimes its not in the scope of the 
developer to change his project to 64 bit. Please keep that in mind.


I fully acknowledge this!

I personally use MSVC2017 together with MSVC2015 32 bit binaries for the 
published product. But I regularly use MinGW for daily development. 
Other people might prefer MinGW over MSVC for published products though.

So 32 bit software projects are still very common on Windows platforms.


And not to forget, 32 bit Windows programs run without problems on 64 
bit Windows systems; the opposite is not true.


Best regards,
André


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

Re: [Development] Project ERROR: Could not find feature future.

[André Hartmann]

Hi,
Am 04.01.2018 um 12:12 schrieb Thiago Macieira:

On Thursday, 4 January 2018 08:40:43 -02 Igor Mironchik wrote:

Hi,

On 04.01.2018 13:00, Thiago Macieira wrote:

On Thursday, 4 January 2018 06:35:33 -02 Oswald Buddenhagen wrote:

On Thu, Jan 04, 2018 at 09:27:06AM +0300, Igor Mironchik wrote:

Maybe I need to checkout all projects to dev branch?


yes, you do.


All projects in the same branch.


Yes, I did it, it helped. But I have one question: is it possible to
switch branch "automatically" for qt5?

I know about git submodule foreach --recursive but it will now help. Not
all submodules have dev, 5.10 branches...


This is the solution, with ignoring the errors in the modules that don't have
those branches.


Maybe its worth to mention that you don't need to build all submodules. 
Just build qtbase and the modules you want to work in.


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

Re: [Development] Goodbye

[André Hartmann]

Hi Jake,

I'd also like to thank you for all your work on Qt and especially QBS.

Best wishes for your future!

André

Am 09.02.2018 um 21:14 schrieb Jake Petroules:

Steve Jobs once said:


“I have looked in the mirror every morning and asked myself: "If today were the last day of my 
life, would I want to do what I am about to do today?" And whenever the answer has been 
"No" for too many days in a row, I know I need to change something.”



After 8 years of Qt, it's time to say goodbye. Both from my employment in The 
Qt Company and my roles in the Qt Project. I'd like to thank those of you in 
the company and in the Qt Project who have supported me over the years in 
various ways. It's been a great adventure. Friday, February 23rd will be my 
last day.

I hereby relinquish my role as Maintainer of Apple build system support across 
all projects under the Qt Project umbrella (nominating Oswald Buddenhagen as my 
replacement), and my role as Maintainer of the Apple watchOS platform 
(nominating Tor Arne Vestbø as my replacement).

Please feel free to contact me at jake.petrou...@petroules.com if you have any 
questions, comments, or otherwise.

I wish you all the best.

Sincerely,
Jake Petroules
___
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] Nominating Valentyn Doroshchuk for Approver status

[André Hartmann]

+1 from my side also :)

André

Am 20.03.2018 um 14:29 schrieb Laszlo Agocs:

+1 from me as well.

Cheers,
Laszlo

-Original Message-
From: Development  On 
Behalf Of Shawn Rutledge
Sent: tirsdag 20. mars 2018 14.28
To: development@qt-project.org
Subject: Re: [Development] Nominating Valentyn Doroshchuk for Approver status

+1 from me
___
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] Proposing Albert Astals Cid for Approver

[André Hartmann]

+1 of course :)

André

Am 21.03.2018 um 12:49 schrieb Lars Knoll:

He isn’t an approver yet? I agree, that we should change that :)

+1 from my side!

Cheers,
Lars


On 21 Mar 2018, at 12:33, Sérgio Martins  wrote:

Hi,


Albert has been a long time contributor to KDE and Qt and very well known in 
the community.

His dashboards speak for himself, with many bugs fixed:
(For some reason pasting-and-opening URLs from gerrit is broken, so you'll have 
to search yourself)


at KDAB:
owner:"Albert Astals Cid "


at Canonical:
owner:albert.ast...@canonical.com


on his free-time with KDE hat:
owner:"Albert Astals Cid "



And recently he was tricked into fixing many printing and CUPS bugs, so thanks 
Albert!


Disclaimer: He's a collegue of mine at KDAB, knew him from KDE and lives 
somewhat near me, in the Iberian peninsula.



Regards,
--
Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts
___
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

[Development] Patch stucking in integration

[André Hartmann]

Hello,

my patch is stucking in integration since yesterday:

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

Can someone with mighty powers have a look please? Normally, the 
integration takes 10 minutes.


Thanks,
André

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

Re: [Development] Patch stucking in integration

[André Hartmann]

Sorry, wrong link: I meant THIS one:

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

Thanks.

Am 23.03.2018 um 08:13 schrieb André Hartmann:

Hello,

my patch is stucking in integration since yesterday:

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

Can someone with mighty powers have a look please? Normally, the 
integration takes 10 minutes.


Thanks,
André



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

Re: [Development] Patch stucking in integration

[André Hartmann]

Thanks Jani!

Am 23.03.2018 um 08:25 schrieb Jani Heikkinen:

I have informed CI team about the issue. I could cancel the integration & 
re-stage it but I didn't because CI team might want to do some studies first.

br,
Jani

From: Development  on behalf 
of André Hartmann 
Sent: Friday, March 23, 2018 9:15 AM
To: development@qt-project.org
Subject: Re: [Development] Patch stucking in integration

Sorry, wrong link: I meant THIS one:

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

Thanks.

Am 23.03.2018 um 08:13 schrieb André Hartmann:

Hello,

my patch is stucking in integration since yesterday:

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

Can someone with mighty powers have a look please? Normally, the
integration takes 10 minutes.

Thanks,
André



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





--
Dipl.-Ing. (FH) André Hartmann
Softwareentwicklung / Software Development

E-Mail: andre.hartm...@iseg-hv.de | Tel: +49 351 26996-43 | Fax: +49 351 
26996-21


iseg Spezialelektronik GmbH - HIGH VOLTAGE. EXACTLY.
iseg-hv.de | iseg-hv.com | download.iseg-hv.com

Bautzner Landstr. 23, 01454 Radeberg / Rossendorf, Germany
Geschäftsführer / Managing directors: Dr. Frank Gleisberg, Dr. Joachim 
Pöthig

Amtsgericht / Lower district court: Dresden HRB 16250
Umsatzsteuer-Id: / VAT-ID: DE812508942

News / Information
https://iseg-hv.com/en/products/control#isegControl2 isegControl2 - 
Unified Control Software
https://iseg-hv.com/en/products/detail/EHS EHS FLEX - Customize and keep 
the price
https://iseg-hv.com/en/products/detail/EHS EHS STACK - Perfect for GEM 
Detectors
https://iseg-hv.com/files/iseg-high-voltage-power-supplies.pdf NEW! 
Product catalog 2017 / 2018 released
https://iseg-hv.com/en/products/detail/NHR NHR - NIM HV-Supply with 
reversible polarity


Links
https://www.linkedin.com/company/12726924 iseg on LINKEDIN | Let's stay 
connected!
https://www.youtube.com/channel/UC5AL-ZgOqSim_1gYNnndyzQ iseg on YOUTUBE 
| Tutorials and more ...

https://www.twitter.com/iseg_hv iseg on TWITTER | please follow!
https://iseg-hv.com/files/iseg-high-voltage-power-supplies.pdf iseg 
CATALOG | download product catalog as PDF
http://download.iseg-hv.com/ iseg DOWNLOADS | manuals, software, 
firmware and more...


Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
Informationen. Wenn Sie nicht der richtige
Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren 
Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte 
Weitergabe dieser Mail ist nicht

gestattet.

This e-mail may contain confidential and/or privileged information. If 
you are not the intended recipient
(or have received this e-mail in error) please notify the sender 
immediately and destroy this e-mail.
Any unauthorized copying, disclosure or distribution of the material in 
this e-mail is strictly forbidden.

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

Re: [Development] Which gerrit branch for minor bug fix?

[André Hartmann]

Hi Paul,

Am 27.04.2018 um 10:52 schrieb Paul Colby:

Hi,

I want submit a very small bug fix to the QtXmlPatterns module.  I think 
I have git and Gerrit all setup, but just wanted to confirm a two things.


The bug to be fixed has been present, untouched since at least Qt 4.6.  
Looking at the QUIP5 guidelines, I'd say its classified as "Bugs: Other" 
(ie, not a regression, or crash), which suggests the Gerrit ref should 
be "Stable".  So then, should I be doing:


git push gerrit HEAD:refs/for/5.10


That would be correct in principle, but 5.10 is already closed.

Please use 5.11. (Please note that we can move patches later easily
within Gerrit also).

Also, is it considered helpful / good practice to create a bugreport in 
JIRA to associate with the push, or that considered unecessary noise?


If it's a small fix, then usually not. You can of course search if 
someone else has reported it already and then integrate a


 Task-number: QTBUG-12345

in your commit message, directly above the Change-Id line.


Thanks! :)


You're welcome :)

André



Paul.


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




--
Dipl.-Ing. (FH) André Hartmann
Softwareentwicklung / Software Development

E-Mail: andre.hartm...@iseg-hv.de | Tel: +49 351 26996-43 | Fax: +49 351 
26996-21


iseg Spezialelektronik GmbH - HIGH VOLTAGE. EXACTLY.
iseg-hv.de | iseg-hv.com | download.iseg-hv.com

Bautzner Landstr. 23, 01454 Radeberg / Rossendorf, Germany
Geschäftsführer / Managing directors: Dr. Frank Gleisberg, Dr. Joachim 
Pöthig

Amtsgericht / Lower district court: Dresden HRB 16250
Umsatzsteuer-Id: / VAT-ID: DE812508942

News / Information
https://iseg-hv.com/en/products/control#isegControl2 isegControl2 - 
Unified Control Software
https://iseg-hv.com/en/products/detail/EHS EHS FLEX - Customize and keep 
the price
https://iseg-hv.com/en/products/detail/EHS EHS STACK - Perfect for GEM 
Detectors
https://iseg-hv.com/files/iseg-high-voltage-power-supplies.pdf NEW! 
Product catalog 2017 / 2018 released
https://iseg-hv.com/en/products/detail/NHR NHR - NIM HV-Supply with 
reversible polarity


Links
https://www.linkedin.com/company/12726924 iseg on LINKEDIN | Let's stay 
connected!
https://www.youtube.com/channel/UC5AL-ZgOqSim_1gYNnndyzQ iseg on YOUTUBE 
| Tutorials and more ...

https://www.twitter.com/iseg_hv iseg on TWITTER | please follow!
https://iseg-hv.com/files/iseg-high-voltage-power-supplies.pdf iseg 
CATALOG | download product catalog as PDF
http://download.iseg-hv.com/ iseg DOWNLOADS | manuals, software, 
firmware and more...


Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
Informationen. Wenn Sie nicht der richtige
Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren 
Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte 
Weitergabe dieser Mail ist nicht

gestattet.

This e-mail may contain confidential and/or privileged information. If 
you are not the intended recipient
(or have received this e-mail in error) please notify the sender 
immediately and destroy this e-mail.
Any unauthorized copying, disclosure or distribution of the material in 
this e-mail is strictly forbidden.

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

Re: [Development] Proposing Orgad Shaneh as Maintainer of Version Control modules in Qt Creator

[André Hartmann]

+1. Orgad is doing great work (everywhere in Creator, not only in the 
VCS intregration).


Disclaimer: I'm no maintainer.

Regards, André

Am 02.05.2018 um 13:03 schrieb Jaroslaw Kobus:

Of course +1


*From:* Development 
 on behalf of 
Tobias Hunger 

*Sent:* Wednesday, May 2, 2018 12:14:14 PM
*To:* qt-crea...@qt-project.org; development@qt-project.org
*Subject:* [Development] Proposing Orgad Shaneh as Maintainer of Version 
Control modules in Qt Creator

Hello,

I want to propose Orgad Shaneh as maintainer of the version control 
related modules in Qt Creator.


So far I have been handling that responsibility, but since I took over 
the project-related Qt Creator plugins, I had way too little time on my 
hands to take a lead in the version management related code.


Orgad has been working in those modules, he did a lion's share of the 
reviews involved and he added functionality during that time and he is 
willing to take on the responsibility involved. So I would like formally 
propose Orgad as maintainer of the version management code. I am sure he 
will take good care of the code, especially of the vcsbase and git plugins.


Best Regards,
Tobias

--
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B


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


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




--
Dipl.-Ing. (FH) André Hartmann
Softwareentwicklung / Software Development

E-Mail: andre.hartm...@iseg-hv.de | Tel: +49 351 26996-43 | Fax: +49 351 
26996-21


iseg Spezialelektronik GmbH - HIGH VOLTAGE. EXACTLY.
iseg-hv.de | iseg-hv.com | download.iseg-hv.com

Bautzner Landstr. 23, 01454 Radeberg / Rossendorf, Germany
Geschäftsführer / Managing directors: Dr. Frank Gleisberg, Dr. Joachim 
Pöthig

Amtsgericht / Lower district court: Dresden HRB 16250
Umsatzsteuer-Id: / VAT-ID: DE812508942

News / Information
https://iseg-hv.com/en/products/control#isegControl2 isegControl2 - 
Unified Control Software
https://iseg-hv.com/en/products/detail/EHS EHS FLEX - Customize and keep 
the price
https://iseg-hv.com/en/products/detail/EHS EHS STACK - Perfect for GEM 
Detectors
https://iseg-hv.com/files/iseg-high-voltage-power-supplies.pdf NEW! 
Product catalog 2017 / 2018 released
https://iseg-hv.com/en/products/detail/NHR NHR - NIM HV-Supply with 
reversible polarity


Links
https://www.linkedin.com/company/12726924 iseg on LINKEDIN | Let's stay 
connected!
https://www.youtube.com/channel/UC5AL-ZgOqSim_1gYNnndyzQ iseg on YOUTUBE 
| Tutorials and more ...

https://www.twitter.com/iseg_hv iseg on TWITTER | please follow!
https://iseg-hv.com/files/iseg-high-voltage-power-supplies.pdf iseg 
CATALOG | download product catalog as PDF
http://download.iseg-hv.com/ iseg DOWNLOADS | manuals, software, 
firmware and more...


Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
Informationen. Wenn Sie nicht der richtige
Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren 
Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte 
Weitergabe dieser Mail ist nicht

gestattet.

This e-mail may contain confidential and/or privileged information. If 
you are not the intended recipient
(or have received this e-mail in error) please notify the sender 
immediately and destroy this e-mail.
Any unauthorized copying, disclosure or distribution of the material in 
this e-mail is strictly forbidden.

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

Re: [Development] [qtserialbus]PeakCAN plugin support for macOS

[André Hartmann]

Hi Miklos,

thanks for your interest in QtSerialBus!

> - Are there any interest of upstreaming such a patch?

Of course. We don't have any macOS support for now, so this would 
greatly improve the situation.


> - The library named differently (PCBUSB vs. pcanbasic). This issue can
> be easily resolved by a simple ifdefs. I have consulted with the
> author an he said he is not planning to change the name to pcanbasic
> (since it is a different library).

That would be fine with me.

> - The official pcanbasic API uses some non fixed sized types (DWORD,
> long etc.) and the same types were used in the PCBUSB too. The ID
> fields of the CAN messages (and another data fields int the API)
> defined as DWORD which is unsigned long in the PCBUSB headers. This
> type is compiled to 64 bit wide integer on 64 bit macOS
> 
, 


> while in the peakcan_symbols_p.h
> 
 


> it is defined as a quint32. This could be also workarounded by some
> ifdefs.

Maybe we can introduce a special type for this, that maps to the 
different OS specific types - could be best decided when we have actual 
code to discuss (in Gerrit).


Are you already familiar with code submission to Qt? If not, please read 
http://wiki.qt.io/Gerrit_Introduction first and ask here if you have 
further questions.


If you have specific questions to QtSerialBus you can mail me directly. 
It may just take some time as I'm in vacation, and I can't support you 
with macOS specific issues, but otherwise I'm glad to help.


Regards,
André

Am 04.07.2018 um 22:11 schrieb Miklos Marton:

Hello all,

We are using the qtserialbus for developing some internal tools 
communicating with devices via PEAK CAN adapters and there were some 
interest of getting it working on macOS.


The PEAK Systems does not offer official API for their products on MAC, 
however there is a 3rd party developer who builds an API which is 
--nearly-- compatible with the pcanbasic API:


http://www.mac-can.com/

I would like to raise some discussion on them before submitting a patch.

- Are there any interest of upstreaming such a patch?

I have came over the following issues with getting it working on MAC:

- The library named differently (PCBUSB vs. pcanbasic). This issue can 
be easily resolved by a simple ifdefs. I have consulted with the author 
an he said he is not planning to change the name to pcanbasic (since it 
is a different library).


- The official pcanbasic API uses some non fixed sized types (DWORD, 
long etc.) and the same types were used in the PCBUSB too. The ID fields 
of the CAN messages (and another data fields int the API) defined as 
DWORD which is unsigned long in the PCBUSB headers. This type is 
compiled to 64 bit wide integer on 64 bit macOS 
, 
while in the peakcan_symbols_p.h 
 
it is defined as a quint32. This could be also workarounded by some ifdefs.


Thank you for your feedback in advance!

--
Best regards,
Miklos Marton



___
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] Timeout for QFuture::waitForFinished()

[André Hartmann]

Hi Lorenz,

I can only reply to the second half of your request.


Follow-up question if a timeout could be added: AFAIK adding an new
parameter to waitForFinished() or adding an overload is BiC. 


That's only true if you *change* the existing method. Adding a new
overload while keeping the existing method *is possible*. So if you have:

  void QFutureWatcher::waitForFinished();

you can add in Qt 5:

  void QFutureWatcher::waitForFinished(int timeout);

and merge both in Qt 6:

  void QFutureWatcher::waitForFinished(int timeout = 3); // or -1

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

Re: [Development] which branch to use for a fix in 5.9 ?

[André Hartmann]

Hi Martin,

The branch 5.9 is in cherry-picking mode, so all fixes need to go to 
5.11 currently. If they are considered relevant for 5.9, they can be 
cherry-picked afterwards.


Regards,
André

Am 11.07.2018 um 10:50 schrieb Martin Koller:

Hi,

I want to create a patch for the 5.9 version,
however it's not clear for me which branch to use.

This guide http://wiki.qt.io/Branch-Guidelines
says:
"All bugfixes go into the "most frozen" maintained branch which they are relevant 
for."

So I assume I should use 5.9 and not 5.9.6, right ?

What is unclear is also:

"release: the current deep-frozen branch. It corresponds with one actual release and 
consequently has a name like 5.3.1. It is (usually) created from the stable branch when a 
release is imminent. It is terminated by a release tag, after which the branch is merged 
and deleted."

especially the last part "...after which the branch is merged and deleted."
However there are multiple 5.x.y branches. Shouldn't they be no more ?


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

Re: [Development] Closing issues automatically with new keyword

[André Hartmann]

Hi Frederik,

one more question: does the script also sets the final Git-SHA1 in the 
Jira "commits" field?


If yes, that would really be a *big* improvement.

> Everything else (wip/foobar, other branch names) will be ignored,
> unless someone explains what to do with them otherwise.

I think that's acceptable.

André

Am 08.08.2018 um 11:58 schrieb Frederik Gladhorn:

On tirsdag 7. august 2018 14.10.08 CEST Alex Blasche wrote:

-Original Message-
From: Development  On Behalf Of Jani Heikkinen


The plan is to update the fix versions and close the task as done when
a line in the commit message starts with "Fixes:".
If the issue is already closed (e.g. cherry-pick) it can add an
additional fix version (e.g. 5.9.7).


The devil is in the detail. We don't want FixVersion to be set to 5.11 but
set to 5.11.x.  When you look at a bug 6 month down the road you don't want
to know that it was fixed in 5.11 but you want to know the exact patch
level release. Especially the LTS releases tend to have many patch lvl
number.

This implies that the script needs to know when 5.11.x was branched off and
that every following commit to 5.11 branch will imply 5.11.x+1. Whether x+1
may never be released is irrelevant though as that's a simple bulk change
when the decision to not have x+1 comes through. Is this what you intend to
do?


Indeed, I have to make some assumptions.
Right now I have the simple case done: branch == x.y.z -> set fix version to
x.y.z.

Then there are two cases that I will handle:
branch is 'dev' or 'master' -> find the next minor version
branch is x.y -> find the next valid patch version

Everything else (wip/foobar, other branch names) will be ignored, unless
someone explains what to do with them otherwise.


I see at least one problem there: If bug is affecting to several branches
it will be closed when fix for first branch is done even in that case it
shouldn't be closed until every branch has a fix...


That's the developer's decision as much as it is today already. If you know
that the fix should go to multiple branches you should probably not use the
"Fixes" keyword for the first commit but the existing "Task-number"
keyword.


My plan was to let the bot add additional fix versions as changes move through
branches.
So if a Fixes: QTBUG- goes into 5.12.1, the bug gets closed and fix
version set to 5.12.1. When it then gets cherry-picked to 5.9.8, the bot will
see the change again and will add a fix version 5.9.8.


Another concern or question is that in which phase we should close the
bug; is it done immediately when fix is in or should it be done when fix
is in the packages and someone can verify that fix is there and really
fixes the problem...

It can only ever be when it is in the code line. That's correct for 90% of
all cases. We cannot optimize for the case when releasing becomes creative
and starts shifting around SHA's or decides to create the package. I am
sure releasing does not want to be responsible for setting the fix version
across all tasks. It does not scale. In other words the status quo applies.


Agreed. There is no magic solution and we need to close bugs, even when the
fix is not released yet, otherwise JIRA becomes useless.
Everyone will understand that if something is closed for 5.12.0 today, it will
not be in their copy of Qt 5.11.0.
Right now we often don't set the fix version at all, which is even more
harmful in my opinion.

Frederik



--
Alex





___
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] Windows 7 support future removal

[André Hartmann]

Am 24.08.2018 um 10:58 schrieb André Pönitz:


"Being out of support by Microsoft" seems to be for quite a few people
a rather unimportant line of reasoning in comparison to having to submit
to Windows 10-style forced system upgrades and snooping on user activities.


I couldn't agree you more.

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

Re: [Development] Configure Qt gerrit git ssh access via Tor on Linux

[André Hartmann]

Hi Denis and Konstantin,

I've run into problems on Debian testing recently and it appears to have 
been the same problem as you're having. Perhaps you could try something 
like this:


GIT_SSH_COMMAND="ssh -c aes256-cbc" 


Looks like https://bugreports.qt.io/browse/QTQAINFRA-1530


It's been a month or so, but as far as I can remember this solved it for me.


Probably you got an SSH client update...

Please note that you can always use git and Gerrit with HTTPS, the HTTPS 
password is in your personal settings page in Gerrit. I've already used 
that in environments where SSH was blocked.


Best regards,
André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Requesting a wip/qt6 branch for QtSerialBus

[André Hartmann]

Hi all,

I allready have some ideas for QCanBusDevice which requires 
binary-incompatible changes and therefore needs to be done for Qt6 [1].


To be able to already start the work, I'm hereby requesting a wip branch 
that could be merged when the "real" Qt6 development begins.


The advantage would be, that others could already pick up that changes 
and test them, which hopefully will improve the code quality.


Regards,
André

[1] https://bugreports.qt.io/browse/QTBUG-64145
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Requesting a wip/qt6 branch for QtSerialBus

[André Hartmann]

Hi Oswald,

> the more pragmatic approach is to "hide" the qt6 variant behind ifdefs.

If that is the "official" way, fine with me.

> note that the qt(core) code is already full of QT_VERSION_CHECK(6,0,0)
> which does effectively the same, but to activate it you would need to
> change .qmake.conf instead of just calling configure -qt6.

Ok, I'll try this next time, seems like a sensible solution.

I've also played a bit with the comment hjk gave me in [1] and it seems 
some of the changes can even be done for Qt5 - which is even better.


I hereby declare that for now I don't need a wip branch, as enough other 
possiblities exist.


Thanks for your time.

Regards,
André

[1] https://bugreports.qt.io/browse/QTBUG-64145

Am 02.10.2018 um 13:08 schrieb Oswald Buddenhagen:

On Tue, Oct 02, 2018 at 10:37:24AM +0200, André Hartmann wrote:

I allready have some ideas for QCanBusDevice which requires
binary-incompatible changes and therefore needs to be done for Qt6 [1].

To be able to already start the work, I'm hereby requesting a wip branch
that could be merged when the "real" Qt6 development begins.

The advantage would be, that others could already pick up that changes
and test them, which hopefully will improve the code quality.


the more pragmatic approach is to "hide" the qt6 variant behind ifdefs.

in fact, the introduction of a respective configure feature (so you
would #if QT_CONFIG(qt6)) has been on the table for quite a while
already, but nobody pushed for it yet, presumably because we haven't
officially started qt6 yet.

note that the qt(core) code is already full of QT_VERSION_CHECK(6,0,0)
which does effectively the same, but to activate it you would need to
change .qmake.conf instead of just calling configure -qt6.
___
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] qMoveToConst helper for rvalue references to movable Qt containers?

[André Hartmann]

Hi all,

I fully agree, Olivier.

Looking at https://docs.kdab.com/analysis/qtcreator/clazy.html gives 
currently 223 potential detaching containers within range-based for, and 
qtbase alone has 46 (https://docs.kdab.com/analysis/qt5/clazy.html).


Even if there may be some false positives, who is going to check and fix 
them all? If we don't manage to use the range-based for correctly (for 
Qt-containers), why should we force the user to port away from foreach?


Just my two cent.

Best regards,
André

Am 29.10.18 um 12:43 schrieb Olivier Goffart:

On 10/28/18 8:17 PM, Thiago Macieira wrote:

On Sunday, 28 October 2018 11:49:08 PDT Olivier Goffart wrote:
It is a bit ironic that one reason given to deprecate Q_FOREACH is 
that it

may copy the container in some cases, while the alternative has the same
problem in much more common cases. (It is my impression that implicitly
shared container such as QList/QVector are by far much more used than 
the

one that are not within a typical Qt code base)


There are two problems with Q_FOREACH:

1) it will copy containers. For Qt containers, that's rather cheap 
(two atomic
refcount operations), but it's not free. And for Standard Library 
containers,

that is likely very expensive.


But using for(:) with a Qt container will cause a detach in the most 
common case, so I'd say is even worse.

Which is why i'm saying using this reason is a bit ironic.



2) it's implemented by way of a for loop inside a for loop, which is 
known to

throw optimisers out, generating slightly worse code


I would consider that the missed optimization is quite small, if not 
negligible.

And it can be solved in C++17:
https://codereview.qt-project.org/243984/

Our rule already was: Don't use foreach in Qt code. (it was fine in 
examples)


Using iterators and now using the ranged for may need more typing, but
produces optimal code.


What could be done is to only deprecate partial specialization of
qMakeForeachContainer for QVarLenghtArray and the standard containers.
Or for containers that do not have a 'detach' function.
That way, users would get a warning for the problematic containers, but
would continue to work just fine with with the containers most Qt 
developer

use.


I disagree. The optimisation problem is not solved.


I'm ok with discouraging Q_FOREACH, but deprecating such a function need 
more thinking.
Deprecating means you will force user to port all their codebase away 
from it, which is a huge work. If the rationale is just that they will 
save a couple of atomic operations, i do not think it is worth it.


Deprecating it only for non-shared container seems more logical, since 
we then warn only when there is actually a problem.


And for the Qt shared container case, using foreach is less typing, but 
also less error prone. (do i have to use qAsConst? or make a copy? or 
even return a const object which even lead to more problems)



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

Re: [Development] Missing documentation in Qt 5.12

[André Hartmann]

Hi Martin,

the all-members list is very useful to get an overview about a class. 
You're searching for a function to perform a specific task, that you 
assume to be in a class. Searching through all inherited classes is a 
tedious task.


If there are no technical limitations, I'm for keeping the all-members list.

André

Am 18.12.18 um 08:39 schrieb Martin Smith:

I'll argue with you about it being a p1. If the problem is confined to the 
all-members list, it's not a p1 problem because the information is still there 
via the inherits links, which are more useful for seeing what is inherited 
anyway. My own opinion is that the all-members list should be removed.

martin


From: Konstantin Shegunov 
Sent: Monday, December 17, 2018 11:03:50 PM
To: Martin Smith
Cc: Sze Howe Koh; Qt development mailing list
Subject: Re: [Development] Missing documentation in Qt 5.12

Not only are members missing, but links lead noplace. For example in the 
mentioned page metaObject() goes to 
http://doc.qt.io/qt-5.12/qwidget.html#metaObject which naturally doesn't exist. 
From what I can tell nothing that is inherited, beside the things explicitly 
overriden, appear in the list. Although I wouldn't presume to place fault, for 
me the bad impression was left not by the bug itself, which is pretty 
embarrassing, as so much as bouncing it around on the tracker for 10 days until 
ultimately a ping on the list prompted action ... I mean, we get it, there's 
not enough people and hours to handle all the bugs, but I *hope* it is not 
going to be necessary to bring P1s to the list so at least they get attention 
...

Disclaimer: I had conversed with Sze-Howe about this bugreport before he 
started this thread.

Nitpick: Between 5.10 and 5.11 we magically got qt_metacall and qt_metacast 
(expanded out of Q_OBJECT) into the members list and of course the links are 
broken, but this listing of private(-use) members is long-standing (from Qt 4); 
although I'm pretty sure these are not intended to be employed by the users and 
they're never going to get a proper documentation page.
___
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] Missing documentation in Qt 5.12

[André Hartmann]

Hi again,


But it sounds like you're asking for a better search mechanism.


Not really. Sometimes you need to read a bit to see what is there and 
what can be done. But if half of the members is inherited, it's hard to 
get an overview.


André


____
From: André Hartmann 
Sent: Tuesday, December 18, 2018 9:19:07 AM
To: Martin Smith; Konstantin Shegunov
Cc: Qt development mailing list
Subject: Re: [Development] Missing documentation in Qt 5.12

Hi Martin,

the all-members list is very useful to get an overview about a class.
You're searching for a function to perform a specific task, that you
assume to be in a class. Searching through all inherited classes is a
tedious task.

If there are no technical limitations, I'm for keeping the all-members list.

André

Am 18.12.18 um 08:39 schrieb Martin Smith:

I'll argue with you about it being a p1. If the problem is confined to the 
all-members list, it's not a p1 problem because the information is still there 
via the inherits links, which are more useful for seeing what is inherited 
anyway. My own opinion is that the all-members list should be removed.

martin


From: Konstantin Shegunov 
Sent: Monday, December 17, 2018 11:03:50 PM
To: Martin Smith
Cc: Sze Howe Koh; Qt development mailing list
Subject: Re: [Development] Missing documentation in Qt 5.12

Not only are members missing, but links lead noplace. For example in the 
mentioned page metaObject() goes to 
http://doc.qt.io/qt-5.12/qwidget.html#metaObject which naturally doesn't exist. 
From what I can tell nothing that is inherited, beside the things explicitly 
overriden, appear in the list. Although I wouldn't presume to place fault, for 
me the bad impression was left not by the bug itself, which is pretty 
embarrassing, as so much as bouncing it around on the tracker for 10 days until 
ultimately a ping on the list prompted action ... I mean, we get it, there's 
not enough people and hours to handle all the bugs, but I *hope* it is not 
going to be necessary to bring P1s to the list so at least they get attention 
...

Disclaimer: I had conversed with Sze-Howe about this bugreport before he 
started this thread.

Nitpick: Between 5.10 and 5.11 we magically got qt_metacall and qt_metacast 
(expanded out of Q_OBJECT) into the members list and of course the links are 
broken, but this listing of private(-use) members is long-standing (from Qt 4); 
although I'm pretty sure these are not intended to be employed by the users and 
they're never going to get a proper documentation page.
___
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] Corrupted ML archive

[André Hartmann]

Hi,

The Qt Creator archive seems broken too.

https://lists.qt-project.org/pipermail/qt-creator/2019-January/thread.html 
only contains two mails, but I'm pretty sure there has been more.


Regards,
André

Am 08.01.19 um 12:20 schrieb Edward Welbourne:

On 21/11/2018 13.10, Danila Malyutin wrote:

It looks like [the archive] has lost all mails from 4th of November
up until now. [...]
I don't know if there any mirror/way for someone
not subscribed to this ML to see these mails


Our sysadmins tell me the archive is now repaired.
A cursory look shows, indeed, many mails between the 4th and 21st of
November.  Please check for anything you remember sending in the
interval to verify it has indeed been restored !

Eddy.
___
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] Corrupted ML archive

[André Hartmann]

Thanks!

Am 09.01.19 um 11:25 schrieb Edward Welbourne:

André Hartmann (8 January 2019 14:09) wrote:

The Qt Creator archive seems broken too.

https://lists.qt-project.org/pipermail/qt-creator/2019-January/thread.html
only contains two mails, but I'm pretty sure there has been more.


Same as developer.
I've poked the sysadmins again ...

Eddy.



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

[Development] Coding style for lambdas with empty parameter list

[André Hartmann]

Hi all,

I recently found an inconsistency regarding empty lambda parameter lists
between [1] and [2]. While the first states, that parentheses have to be
written always, the latter is missing this section.

My request to syncronize both [3] lead to the conclusion, to change the rule,
so that empty parameter lists should be written as

 [] { // lambda content }

instead

 []() { // lambda content }

If anyone has objections against this change, please vote at [3]. 
I'll keep this commit open a while and adopt the Wiki [1] once the change
is approved without objections.

Thanks and regards,
André

[1] https://wiki.qt.io/Coding_Conventions#Lambdas
[2] https://code.woboq.org/qt5/qt-creator/doc/api/coding-style.qdoc.html#772
[3] https://codereview.qt-project.org/249192
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Gerrit: Sanity-Review is lost after moving changes

[André Hartmann]

Hi all,

I just stumbled about the problem, that the new Gerrit removes the
sanity review vote after a change was moved to a new destination branch.

While it's probably good to remove code review votes on branch change,
the sanity review should not be affected from this. Or if it is, the
sanity bot should probably be triggered again.

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

Re: [Development] Moving to Gerrit 2.16.9

[André Hartmann]

Hi all,

I'm not sure if it's related to the gravatars, but Gerrit became
horrible slow here (this is on a 2MBit DSL line). It's almost unuseable.

Has someone else experienced the same?

Regards,
André

Am 01.07.19 um 19:57 schrieb André Pönitz:

On Mon, Jul 01, 2019 at 02:43:43PM +, Frederik Gladhorn wrote:

and I'll give Gravatar a spin:
https://gerrit-review.googlesource.com/admin/repos/plugins/avatars-gravata
r


It's there, enjoy and put your avatar up at https://gravatar.com .


I know it's a bit late and it won't change anything anyway.

Still: Was there an explanation of the benefits of using gravatar somewhere,
also perhaps in the light of discussions like

https://meta.stackexchange.com/questions/4553/can-we-use-non-gravatar-avatars/5658#5658

?

Andre'
___
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] Oslo, we have a problem [char8_t]

[André Hartmann]

Hi Thiago,

> But QByteArray is encoding-indeterminate since it can carry any type.

Correct, it is often used as "generic raw data array", e.g. in QFile,
Q*Socket, QSerialPort, QCanBusFrame etc. Here we really need to treat
the data as-is, without interpretation.

> Arguably, toUpper() and toLower() should be removed, since
>
>QByteArray(u8"Résumé").toLower()
> is mojibake.

I vote against that. If you got the "raw" data from a device as
described above, you might want to do .toHex().toUpper() which is fully
valid.

So either:

- restrict the functions now operating on Latin1 functions to pure ASCII
- or give a possibility to select the encoding in QByteArray
  (e.g. by adding fromLatin1() and fromUtf8()). That would also
  add the possibility to correctly operate on UTF-8 strings.
  But probably a separate QString8 class would be better.

> I wouldn't mind a udata() function anyway, since there's a lot of code
> dealing with "bytes" as unsigned char.

+1

> Are we willing to add ubegin() and begin8() too?

If that all fit's in one class, why not?!

Best regards,
André


On 06.07.19 18:59, Thiago Macieira wrote:

On Saturday, 6 July 2019 11:09:36 -03 Mutz, Marc via Development wrote:

Anyway, QByteArray has *Latin1* text-manipulation functions (toUpper
and
toLower), its split(char) function will happily split on indivdual
bytes of an
UTF-8 multibyte sequence, so adding char8_t overloads seems just wrong
to me.


const char* in Qt is always assumed to be UTF-8-encoded. You need to use
QLatin1String to have it interpreted as Latin-1:

https://doc.qt.io/qt-5/qstring.html#QString-8
https://doc.qt.io/qt-5/qstring.html#QString-7


That's QString, not QByteArray.

But QByteArray is encoding-indeterminate since it can carry any type.
Arguably, toUpper() and toLower() should be removed, since

QByteArray(u8"Résumé").toLower()
is mojibake.

In fact, QByteArray should use std::byte in functions like data(), but that's
unwieldy and breaks too much compatibility.


What did you try to use QByteArray with that showed problems?


Just QByteArray(u8"Hello") already fails when compiled with -std=c++2a.
And this is also why we need to fix it. The same compiles fine in C++17,
and does the expected thing.


I think we need to talk to SG16.

We can add the template overloads to all functions so we can take char,
unsigned char, std::byte and char8_t without complaining. I am with you that
this could result in explosive compile times[1]. But it also does not solve
the problem of what type data() / constData() and the iteration functions
return.

I wouldn't mind a udata() function anyway, since there's a lot of code dealing
with "bytes" as unsigned char. Are we willing to add ubegin() and begin8()
too?

[1] Please, no one say "Modules!" here, it's not a full solution, even if we
can use them in Qt 6's lifetime.



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

Re: [Development] Gerrit very slow?

[André Hartmann]

Hi Christian,

for me in Germany the web interface is slower than usual, but still useable.

André

On 14.07.19 04:07, Christian Gagneraud wrote:

Hi there,

Is it just me or code-review.qt-project.org is very slow?
I have no problem with other web sites, but code-review keeps timing out?
Anyone else has the same problem?

Chris
___
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] Save the date: Qt Contributors Summit 2019 is 19th - 21st November in Berlin

[André Hartmann]

Hi Tuukka,

any update on this? Do you already have a location and maybe a rough plan?

Best regards,
André



Hi Thiago,

I hope you and other contributors can attend despite the days being 
middle of the week.


Yours,

Tuukka


*Lähettäjä:* Development  käyttäjän 
Thiago Macieira  puolesta

*Lähetetty:* Saturday, July 6, 2019 3:21:23 AM
*Vastaanottaja:* development@qt-project.org
*Aihe:* Re: [Development] Save the date: Qt Contributors Summit 2019 is 
19th - 21st November in Berlin

On Friday, 5 July 2019 09:13:52 -03 Tuukka Turunen wrote:

Save the date: Qt Contributors Summit 2019 is in Berlin at 19th – 21st
November 2019.


As I explained when I was asked if the dates are good: they are not. Those
dates are the middle of a week. That means travel on Monday and on Friday.

That means I don't know if I can make it this year.

--
Thiago Macieira - thiago.macieira (AT) intel.com
   Software Architect - Intel System Software Products



___
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




--
Dipl.-Ing. (FH) André Hartmann
Softwareentwicklung / Software Development

E-Mail: andre.hartm...@iseg-hv.de | Tel: +49 351 26996-43 | Fax: +49 351 
26996-21


iseg Spezialelektronik GmbH - HIGH VOLTAGE. EXACTLY.
iseg-hv.de | iseg-hv.com | download.iseg-hv.com

Bautzner Landstr. 23, 01454 Radeberg / Rossendorf, Germany
Geschäftsführer / Managing directors: Dr. Frank Gleisberg, Dr. Joachim 
Pöthig

Amtsgericht / Lower district court: Dresden HRB 16250
Umsatzsteuer-Id: / VAT-ID: DE812508942

News / Information
https://iseg-hv.com/en/products/control#isegControl2 isegControl2 - 
Unified Control Software
https://iseg-hv.com/en/products/detail/EHS EHS FLEX - Customize and keep 
the price
https://iseg-hv.com/en/products/detail/EHS EHS STACK - Perfect for GEM 
Detectors
https://iseg-hv.com/files/iseg-high-voltage-power-supplies.pdf NEW! 
Product catalog 2017 / 2018 released
https://iseg-hv.com/en/products/detail/NHR NHR - NIM HV-Supply with 
reversible polarity


Links
https://www.linkedin.com/company/12726924 iseg on LINKEDIN | Let's stay 
connected!
https://www.youtube.com/channel/UC5AL-ZgOqSim_1gYNnndyzQ iseg on YOUTUBE 
| Tutorials and more ...

https://www.twitter.com/iseg_hv iseg on TWITTER | please follow!
https://iseg-hv.com/files/iseg-high-voltage-power-supplies.pdf iseg 
CATALOG | download product catalog as PDF
http://download.iseg-hv.com/ iseg DOWNLOADS | manuals, software, 
firmware and more...


Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
Informationen. Wenn Sie nicht der richtige
Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren 
Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte 
Weitergabe dieser Mail ist nicht

gestattet.

This e-mail may contain confidential and/or privileged information. If 
you are not the intended recipient
(or have received this e-mail in error) please notify the sender 
immediately and destroy this e-mail.
Any unauthorized copying, disclosure or distribution of the material in 
this e-mail is strictly forbidden.

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

Re: [Development] Nominating Vitaly Fanaskov as Approver

[André Hartmann]

Hi Timur,

I'm sure you didn't mean me, but as I'm a André too I'll answer:


AndrЁ: I'm probably missing something, but ... yeah, it's about Vitaly,
who's this Kirill you're talking about? Sorry if I misunderstood this ...


Just click on the links ;)

Regards,
André


 > Looks like Kirill did indeed a good job.

Bye.



*From:* Development  on behalf of
André Pönitz 
*Sent:* Wednesday, October 2, 2019 10:01 PM
*To:* Shawn Rutledge 
*Cc:* Qt development mailing list 
*Subject:* Re: [Development] Nominating Vitaly Fanaskov as Approver
On Wed, Oct 02, 2019 at 11:22:33AM +, Shawn Rutledge wrote:

Hi all,

I would like to nominate Vitaly Fanaskov as approver for the Qt Project.
Vitaly joined the Qt Quick and Widgets team about a year ago.  He has been 
fixing bugs in widgets and Qt Quick, making it easier to use and customize 
color palettes in Qt Quick, working on the speech module, working on 
KUserFeedback (which we will use for  telemetry in Creator), teaching us how to 
use some modern C++ features

that some of us didn’t know about before, etc.

I trust that he will follow Qt guidelines and will use the approver rights 
responsibly.

Here is his list of changes:
https://codereview.qt-project.org/q/owner:


vitaly.fanaskov%2540qt.io


and reviews:
https://codereview.qt-project.org/q/reviewer:vitaly.fanaskov%2540qt.io


Looks like Kirill did indeed a good job.

Andre'

___
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] Missing JIRA notifications recently

[André Hartmann]

Hi all,

It seems JIRA don't send me an email anymore when a comment is added to
a report I'm watching.

I'm not aware that I have changed something in that regard, so has
anyone else noticed the same?

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

Re: [Development] Notes from "Releasing" session in QtCon19

[André Hartmann]

Hi all,


The script creating the changlog still oversees a lot of QTBUG - > entries. I 
could not find out why the bug number is sometimes added

to> the changelog entry and sometimes doesn't.> See for example>
https://codereview.qt-project.org/c/qt/qtbase/+/281862/2..3/dist/changes-5.14.0

I've experienced the same with
https://codereview.qt-project.org/c/qt/qtserialbus/+/281838/1..4/dist/changes-5.14.0

Had to add many of them by hand.

Greetings,
André



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


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

Re: [Development] Nominating André Hartmann for maintainer for QCanBus API

[André Hartmann]

Hi Alex,

thank you very much, that is a great honor for me.

I would also like to thank my supporters, you are great!

I'm looking forward working on new challenges with you.

Best regards,
André

On 07.02.20 09:39, Alex Blasche wrote:

Its been a while and I lost track of this thead.

Congratulations to André. I recorded the change of maintainership in 
https://wiki.qt.io/Maintainers

--
Alex


From: Development  on behalf of Alex Blasche 

Sent: Tuesday, 26 November 2019 09:36
To: development@qt-project.org
Subject: [Development] Nominating André Hartmann for maintainer for QCanBus API

Hi,

The QCanbus API is part of the QtSerialBus module. Since its first release it has 
come a long way. In particular, André Hartmann & Denis Shienkov made big 
contributions over time. For that I am very grateful. Thank you.

As the current maintainer of the QCanBus API I would like to hand the 
maintainer baton over to André.

He has done a very good job of fixing the day-to-day issues popping up on a 
regular base. Unrelated to QtSerialBus, he contributed to Qt Creator and other 
parts in QtBase.

--
Alex
___
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] Co-maintainer of QtNetwork

[André Hartmann]

Hi all,

I want to propose a colleague of mine, Mårten Nordheim, as a co-maintainer of 
QtNetwork module with him
becoming the maintainer of  „High-Level network access (HTTP)"* (which 
essentially means QNetworkAccessManager
and related classes/code, sub-module 'access' etc.)  component and me continuing as 
the maintainer of  "Low-level
access (Sockets, SSL, Hostname resolution, Bearer mgmt, etc)"**. Since the 
first day he joined the Qt Core
and Network team several years ago, Mårten is making a significant contribution 
to the QtNetwork module, which
includes numerous improvements and fixes in QNetworkAccessManager and also new 
developments (among other things
he is the author of SChannel TLS backend on Windows). He has a good, solid 
knowledge of QtNetwork code/components
and making him the maintainer "de jure" will help us (the Qt Core and Network 
team) to optimise and streamline the
future developments in QtNetwork module.

Best regards,
    Timur.

* and ** - these are names taken from our wiki page on the Qt maintainers.


+1


+1 from me too.

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

Re: [Development] [Qt-creator] Stepping down as maintainer of Qt Creator's C/C++ language support

[André Hartmann]

Am 18.05.20 um 08:31 schrieb Nikolai Kosjar:

Hiya,

as this is my last month with the Qt Company, I'm stepping down as the 
maintainer of Qt Creator's C/C++ language support.


It was my pleasure to work with some extraordinary ladies and gentlemen. 
Thank you.


The Qt Company is interested in a successor. Until a long-term 
replacement is found/evolves, Christian Kandeler will keep an eye on the 
C/C++ language support.


Nikolai


Dear Nikolai,

I like to thank you very much for your work on Qt Creator and the 
integration of Clang & Co. during the last 8 years. It was always good 
and joyful working with you. I have probably driven you crazy more than 
once with my extraordinary bug reports and suggestions, but you managed 
that easily.


So thanks for making Creators C++ integration really awesome. I wish you 
all the best on your future path!


And because it comes up: Christian, you did a great job polishing the 
Project Management subsystem during the last 18 month. A lot of really 
old bugs were resolved, so I like to express my respect. All the best 
with your new tasks, too.


Best regards,
André

--
André Hartmann, Dipl. Ing. (FH)
Softwareentwicklung / Software Development

E-Mail: andre.hartm...@iseg-hv.de
Tel: +49.351.26996-43 | Fax: +49.351.26996.21

iseg Spezialelektronik GmbH - HIGH VOLTAGE. EXACTLY.
iseg-hv.de | iseg-hv.com | download.iseg-hv.com

Bautzner Landstr. 23, 01454 Radeberg / Rossendorf, Germany
Geschäftsführer / Managing directors: Dr. Tanju Gleisberg, Tobias Pöthig
Amtsgericht / Lower district court: Dresden HRB 16250
Umsatzsteuer-Id: / VAT-ID: DE812508942

iseg on LINKEDIN | Let´s stay connected!
iseg on YOUTUBE | Tutorials and more ...
iseg on TWITTER | please follow!
iseg CATALOG | download iseg´s latest product catalog as PDF
iseg DOWNLOADS | manuals, software, firmware and more...
iseg high voltage power supply

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder
diese E-Mail irrtümlich erhalten haben, informieren Sie bitte
sofort den Absender und vernichten Sie diese Mail. Das unerlaubte
Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht
gestattet.

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail
in error) please notify the sender immediately and destroy this e-mail.
Any unauthorized copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Proposing Alex Trotsenko as approver

[André Hartmann]

Hi all,

I like to propose Alex Trotsenko as approver.

Alex has been contributing to Qt since 2014, and has done *a lot*
of low level optimization and fixes. He has a deep knowledge of
QIODevice, Q*Socket, QProcess, and related classes.

Furthermore, he is also an active and helpful reviewer. His constructive
feedback makes changes better and improves the overall Qt quality.

All this makes me believe he will be a good approver.

Now the interesting part:

His patches:
https://codereview.qt-project.org/q/owner:alex1973tr%2540gmail.com

And his reviews:
https://codereview.qt-project.org/q/reviewer:alex1973tr%2540gmail.com

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

Re: [Development] Stepping down as QtSerialPort maintainer

[André Hartmann]

Dear Denis,

I'd also like to thank you for starting and maintaining QtSerialPort for
such a long time.

I have successfully used it in many projects, and as Tomasz already
said, it's really fun to work with that module.

Currently I don't have enough time for maintaining another module, but
I'm ready to help the new maintainer with reviews.

All the best for your new projects, Denis!

Best regards,
André

On 07.10.20 09:54, Tomasz Siekierda wrote:

On Wed, 7 Oct 2020 at 09:40, Denis Shienkov mailto:denis.shien...@gmail.com>> wrote:

[...]


Thanks so much for using QtSerialPort, I'm glad it was useful
to someone.


Thanks for all your work, that module is awesome, I've used it many times.


BR,
Denis


___
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] Gerrit staging problems

[André Hartmann]

Hi all,

I have staging problems for some time with the following patch:
https://codereview.qt-project.org/c/qt/qtserialbus/+/325691

The error is:

 Continuous Integration: Failed

 Failed to install a source archive. That should not happen, please
 contact the Coin admins and maybe try to restage your changes.

 The error was in "qt/qtserialbus", revision:
 a50760b20802d0bf6c8a10ddd05b515ab5cafe97

Has anyone an idea how to fix that problem?

Thanks and best regards,
André
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Gerrit staging problems

[André Hartmann]

Thanks Andreas,

it seems Liang already added the cmake experts to the patch, so let's
hope they are able to resolve the problems.

Happy Sunday!

André

On 09.01.21 15:22, Andreas Buhr wrote:

Hi André,

On 09.01.21 14:20, André Hartmann wrote:
 > I have staging problems for some time with the following patch:
 > https://codereview.qt-project.org/c/qt/qtserialbus/+/325691
 >
 > The error is:
 >
 >   Continuous Integration: Failed
 >
 >   Failed to install a source archive. That should not happen, please
[snip]

I think Coin now uses CMake only and qserialbus is not ported to CMake
yet. There might be additional Coin problems at the moment, but it will
be a few more weeks until qserialbus passes Coin again. Currently, the
CMake port of its dependency qserialport is being done.

best,
Andreas




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

Re: [Development] Nominating Frank Meerkoetter for Approver status

[André Hartmann]

+1

Am 20.05.2016 um 15:09 schrieb Shawn Rutledge:

+1


On 20 May 2016, at 15:00, Robin Burchell  wrote:

+1 :)

On Fri, May 20, 2016, at 02:49 PM, Simon Hausmann wrote:

Hi,


I would like to nominate Frank for approver status. He has done a fair
bit of surgery in the QML engine and also seems to be active on
qtopcua/serialbus.


I appreciate his input on my patches and I trust him to responsibly
review.



Simon
___
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



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

[Development] Adding 3rdpary libraries to QtSerialBus

[André Hartmann]

Hi all,

[Re-sent as I think something went wrong the first time,
the mail did not appear in the archive.]

I'm working on a new feature for QCanBus to enumerate all available CAN 
interfaces and query more information about them [0].


As it turns out, the Linux SocketCAN API allows a lot, but exactly this 
task is a bit complicated, see mailing list thread [1].


In this thread, Kurt Van Dijck proposed his network interface 
enumeration library [2], licensed under LGPL V3, which perfectly allows 
to query all SocketCAN devices. QNetworkInterface::allInterfaces() lists 
them too, but there is for now no way to find out which of them are 
SocketCAN interfaces.


Now I really don't know how to proceed. I already saw some libs like 
pcre included in the Qt source tree, but I don't know if this is 
possible with libenumif too, and which technical and legal requirements 
are needed.


The same problem may occur with libsocketcan [3] which provides more 
low-level function like CAN controller hardware reset. But this library 
is more widely used and really stable, so dynamically loading with 
QLibrary may be enough here.


Thanks for any pointers!

Best regards,
Andre

[0] https://codereview.qt-project.org/#/c/166460
[1] https://marc.info/?l=linux-can&m=147074084303882&w=2
[2] https://github.com/kurt-vd/enumif
[3] http://git.pengutronix.de/?p=tools/libsocketcan.git
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Adding 3rdpary libraries to QtSerialBus

[André Hartmann]

Hi Edward,

> How hard would it be to teach QNetworkInterface how to detect
> CAN-iness in the interfaces it's clearly able to enumerate ?

I'm currently trying to find this out. What I know so far, is that
you can compare "something" to

#define ARPHRD_CAN  280

to find out the interface is of type SocketCAN. As there are more of 
these definitions in /usr/include/linux/if_arp.h, a generic way to get 
the "type" of an interface could be added to QNetworkInterface.


Maybe someone with more Linux programming knowlegde has a hint - 
libenumif surely knows it, but looks like a sledgehammer for my small 
problem.


Cheers,
Andre

Am 11.08.2016 um 15:47 schrieb Edward Welbourne:

André Hartmann

[Re-sent as I think something went wrong the first time,
the mail did not appear in the archive.]


I haven't seen it before, at least.


In this thread, Kurt Van Dijck proposed his network interface
enumeration library [2], licensed under LGPL V3, which perfectly allows
to query all SocketCAN devices. QNetworkInterface::allInterfaces() lists
them too, but there is for now no way to find out which of them are
SocketCAN interfaces.

[2] https://github.com/kurt-vd/enumif


How hard would it be to teach QNetworkInterface how to detect CAN-iness
in the interfaces it's clearly able to enumerate ?

Eddy.



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

Re: [Development] Adding 3rdpary libraries to QtSerialBus

[André Hartmann]

Hi,

oops, looks like I triggerd an avalanche.

Just to clarify, if we can solve the problem within Qt, then there is no 
need to include external libraries.


Thiagos patch https://codereview.qt-project.org/#/c/167772/ looks quit 
promising, at least for an important part of my problem.


Best regards,
Andre

Am 11.08.2016 um 19:50 schrieb Alexander Nassian:

Am 11.08.2016 um 19:42 schrieb Thiago Macieira :



On quinta-feira, 11 de agosto de 2016 19:12:26 PDT Alexander Nassian wrote:
Why should that not be possible? With Chromium we already have L-GPLv2 and
many other. Qt itself is also available as v3.


WebKit (including JSC) was an exception and Chromium inherited that exception.
It's one that didn't please commercial customers much.

And they're LGPLv2. The v3 clauses cause lots of companies to run away.


Really? v3 just clarifies some of the implications of v2 in a more suitable way 
for lawyers. Many people that run away don't know how to get their products 
safe with the requirement to let the user on the system. But it's possible and 
no real reason against v3.



--
Thiago Macieira - thiago.macieira (AT) intel.com
 Software Architect - Intel Open Source Technology Center

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


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



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

Re: [Development] Adding 3rdpary libraries to QtSerialBus

[André Hartmann]

Am 11.08.2016 um 22:22 schrieb Thiago Macieira:

On quinta-feira, 11 de agosto de 2016 19:58:48 PDT André Hartmann wrote:

Thiagos patch https://codereview.qt-project.org/#/c/167772/ looks quit
promising, at least for an important part of my problem.


Nice to know.

Note the patch is crude at this point. It's at the earliest a Qt 5.9 feature.


Maybe it can be at least used internally in 5.9? The SocketCAN plugin 
already uses QT += core-private, so I guess this should be no big problem.


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

Re: [Development] Adding 3rdpary libraries to QtSerialBus

[André Hartmann]

Hi Denis,

I've already have a prototype parsing the sysfs. It has no dependencies, 
consists of less than 100 lines code and determines the SocketCAN 
interfaces, checks if an interface is virtual and if the interface is 
CAN FD capable.


You will be able to review it soon :)

Best regards,
Andre

Am 12.08.2016 um 07:39 schrieb Denis Shienkov:

Hi Andre,

We can try to use libudev (or to parse the sysfs entries) to find out
additional information too.
At first, we just need to check what we can take from it.

BR,
Denis

11.08.2016 16:28, André Hartmann пишет:

Hi all,

[Re-sent as I think something went wrong the first time,
the mail did not appear in the archive.]

I'm working on a new feature for QCanBus to enumerate all available
CAN interfaces and query more information about them [0].

As it turns out, the Linux SocketCAN API allows a lot, but exactly
this task is a bit complicated, see mailing list thread [1].

In this thread, Kurt Van Dijck proposed his network interface
enumeration library [2], licensed under LGPL V3, which perfectly
allows to query all SocketCAN devices.
QNetworkInterface::allInterfaces() lists them too, but there is for
now no way to find out which of them are SocketCAN interfaces.

Now I really don't know how to proceed. I already saw some libs like
pcre included in the Qt source tree, but I don't know if this is
possible with libenumif too, and which technical and legal
requirements are needed.

The same problem may occur with libsocketcan [3] which provides more
low-level function like CAN controller hardware reset. But this
library is more widely used and really stable, so dynamically loading
with QLibrary may be enough here.

Thanks for any pointers!

Best regards,
Andre

[0] https://codereview.qt-project.org/#/c/166460
[1] https://marc.info/?l=linux-can&m=147074084303882&w=2
[2] https://github.com/kurt-vd/enumif
[3] http://git.pengutronix.de/?p=tools/libsocketcan.git
___
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] [5.7.1] release schedule?

[André Hartmann]

Am 24.09.2016 um 11:04 schrieb Tim Blechmann:
> hi all,
>
> the 5.7.1 release was scheduled for sept/oct ... october is almost over,
> so i wonder what's the state of it?
>
> thanks a lot,
> tim

Hi Tim,

I don't know the exact release plan either, but I guess they want to get 
5.6.2 released first. The branch 5.7.1 already exists, so this will be 
the next step...


> october is almost over,

No, there are still five weeks left to release 5.7.1 in october :)

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

Re: [Development] Qt 5.9

[André Hartmann]

Hi,

This nice thing about the MinGW package is, that you get Qt, Creator, 
the compiler and the debugger in one package. I already recommended this 
package to people that wanted to start Windows development and this 
always worked fine.


So another +1 for MinGW 32bit build from my side.

Andre

PS: And I never want to got back to early Creator 2.x times, when you 
had to put all this together your own, and the requirements changed for 
every new Creator version...


Am 25.11.2016 um 09:39 schrieb Eric Lemanisser:

We have been using the MinGW binaries of Qt for years in production
without problems. Until now 64bit has not been required, so we only used
32bit which is able to run on all windows platforms. A non-negligible
part of users are using 32bit windows (on tablets for example), so it
does not seem a very good move to stop offering MinGW 32bits. That said
we would definitely make use of MinGW 64bits binaries !

Eric Lemanissier

Le ven. 25 nov. 2016 à 08:03, Bo Thorsen mailto:b...@vikingsoft.eu>> a écrit :

Den 23-11-2016 kl. 23:10 skrev Thiago Macieira:
> On quarta-feira, 23 de novembro de 2016 21:14:52 PST Simon Everts
wrote:
>>> That is not relevant here. I am using Windows 10 (64-bit) but I
am still
>>> forced (because of 3rt-party-libraries) to develop
32-bit-Qt-applications.
>>> Even if the operating system is 64-bit there can be a lot of 32-bit
>>> application, e.g. VS 2013 and VS 2015 are still 32-bit applications.
>>
>> +1
>>
>> As a machine manufacturer we are still deploying 32bit windows
systems
>> because of this reason. We'll be on 64bit windows soon, but need
to support
>> the 32bit systems for at least 5 years. A lot of industrial computer
>> suppliers still install 32bit images on computers because there
aren't any
>> 64bit drivers available for the hardware.
>
> Good, thanks for the information, Simon and Helmut.
>
> I know the sample size here is horrible, but in your opinion what
compiler
> should we keep offering a 32-bit binary build for?
>
> MSVC 2013
> MSVC 2015
> MinGW

The reason for doing 32 bit MSVC releasees is 3rd party libraries. Is
that a valid reason for MinGW? I would have thought that the guys using
it pretty much have to compile everything themselves anyway.

I don't know, though. I won't ever use MinGW myself unless a customer
forces me to.

Bo Thorsen,
Director, Viking Software.

--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org <mailto:Development@qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development



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




--
Best regards / Mit freundlichen Grüßen
André Hartmann, Dipl.-Ing. (FH)
Software Project Manager

iseg Spezialelektronik GmbH |  phone: ++49 (0)351 26996-43
Bautzner Landstr. 23|  fax:   ++49 (0)351 26996-21
D-01454 Radeberg / Rossendorf   |  web:   www.iseg-hv.com

Geschäftsführer / Managing director: Dr. F. Gleisberg, Dr. J. Pöthig
Amtsgericht / Lower district court: Dresden HRB 16250
Ust.-Id.-Nr. / VAT-ID: DE812508942

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder
diese E-Mail irrtümlich erhalten haben, informieren Sie bitte
sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail
in error) please notify the sender immediately and delete this e-mail.
Any unauthorized copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] HEADS-UP: 5.6 / LTS is now open for business

[André Hartmann]

Hi,

and what about changes already uploaded to Gerrit, containing a 
cherry-pick line?


They cannot be uploaded again without changing at least the commit 
message. What should happen there?


Best regards,
André

Am 06.02.2017 um 08:34 schrieb Alex Blasche:

Hi,

It would help to actually state the rules the bot is following.

This case below is an assumption since you don't really name the rules and I am 
interpreting in between your lines:

How do I stage a change that is not a cherry-pick? Yes, they do exist and I can 
name a few cases where this makes sense especially since we are talking about 3 
minor releases of Qt in between.

--
Alex

From: Development  on 
behalf of Oswald Buddenhagen 
Sent: Friday, 3 February 2017 11:22:22 PM
To: development@qt-project.org
Subject: [Development] HEADS-UP: 5.6 / LTS is now open for business

moin,

we finally managed to add a cherry-pick validator to the sanity bot, so
i dared to open the 5.6 branch for staging again.

caveat: patchsets created before the final forward merge got a positive
review while they aren't cherry-picks. i don't suppose anyone would
stage such an old patchset as-is anyway, but please check.

note that there is an exception to the policy as well: the qt5 super
repo continues to operate in forward-merge mode also for the LTS branch.
you probably don't care unless you're in the release or CI team.

there is also another consideration: these off 5.6 integration runs of
course cost CI resources. maybe it would be smart as a matter of policy
to have a dedicated team do the staging in batches.
___
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




--
Best regards / Mit freundlichen Grüßen
André Hartmann, Dipl.-Ing. (FH)
Software Project Manager

iseg Spezialelektronik GmbH |  phone: ++49 (0)351 26996-43
Bautzner Landstr. 23|  fax:   ++49 (0)351 26996-21
D-01454 Radeberg / Rossendorf   |  web:   www.iseg-hv.com

Geschäftsführer / Managing director: Dr. F. Gleisberg, Dr. J. Pöthig
Amtsgericht / Lower district court: Dresden HRB 16250
Ust.-Id.-Nr. / VAT-ID: DE812508942

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder
diese E-Mail irrtümlich erhalten haben, informieren Sie bitte
sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail
in error) please notify the sender immediately and delete this e-mail.
Any unauthorized copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] HEADS-UP: 5.6 / LTS is now open for business

[André Hartmann]

Hi Oswald,

> look at the changes' review comments?

Sorry for the noise. Now I got it :)

Thanks, André

Am 06.02.2017 um 10:59 schrieb Oswald Buddenhagen:

On Mon, Feb 06, 2017 at 09:24:33AM +0100, André Hartmann wrote:

and what about changes already uploaded to Gerrit, containing a
cherry-pick line?


look at the changes' review comments?
___
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] Gerrit change move request

[André Hartmann]

Dear Gerrit admins,

can you please move the change [1] to dev? For some reason (too old?) it
is missing the "move change" menu.

Thanks in advance,
André

[1] https://codereview.qt-project.org/c/qt/qtserialbus/+/199255
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Jira update on 3rd Janaury 2023

[André Hartmann]

Hi Alex,

it seems I now have gray "Edit" and "Delete" buttons below every Jira
report comment. I think that was a pen at the right top of every comment
in the old version.

Was this change intentional?

For me, this disturbs the thread reading flow and it is easy to click
such a button by mistake.

Any chance to revert this to the old behavior (maybe a setting)?

Regards, André


Am 03.01.23 um 07:58 schrieb Alex Blasche via Development:

Hi,

The server has been back for a while but just to conclude here, the update is 
complete.

Testing will continue and please forward any issues to 
jira-ad...@qt-project.org. Thank you.

--
Alex


From: Development  on behalf of Alex Blasche via 
Development 
Sent: Wednesday, 21 December 2022 09:18
To: development@qt-project.org
Subject: [Development] Jira update on 3rd Janaury 2023

Hi,

We will update Jira on 3rd January 2023. The update will cause about two hours 
of service outage and starts at 6:00 am CET.

For those interested in details, we will update Jira from version 8.13 to 8.20. 
This upgrade will bring along many new features and security updates. If you 
want to know more, check out the release notes for the releases starting with 
8.14 up to 8.20. They can be found under

https://confluence.atlassian.com/jiracore/jira-core-release-notes-781386726.html

--
Alex
___
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] Jira update on 3rd Janaury 2023

[André Hartmann]

Hi Thiago,


Some users see the option to edit anyone's comments. I don't know what group
options applied, but I am on that list.


I think this is the Approvers group. My Jira possibilities increased
massively when I gained Approver rights.


I preferred the less intrusive older UI, but I can work with this.


Same here.

André


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

Re: [Development] Jira update on 3rd Janaury 2023

[André Hartmann]

Hi Alex,


IMO everybody should only be able to modify their own comments.


This is true for almost all cases; but I remember e.g. fixing links in
other's comments to make further reader's life easier.

But that is such a rare thing that it should be hidden in a menu or so.


So yes, I reverted the behavior but maybe not in the sense you expected ;)


It looks much cleaner now, I think I can live with that :)

André


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

Re: [Development] Proposing new Qt Creator module: Qt Creator Solutions

[André Hartmann]

Good morning,

for me both suggestions (first separate the code, then moving it to Qt)
sounds good to me.

+1

André

Am 30.11.23 um 23:00 schrieb apoenitz:

On Thu, Nov 30, 2023 at 07:41:06PM +, Fabian Kosmale wrote:

Hi,

I agree that it would be nice to properly separate Solutions (to enforce their
reusability, and to make it easier to include the module into other projects).

I'm also convinced that Jarek would do a good job as the maintainer of the
module.

I have however two questions:
1. How this will affect packaging/releasing of QtCreator?


In the current setup that's not affecting nor meant to be affecting anything
like that at all, i.e. the main difference between libs/solution/tasktree and,
say, src/plugins/git is that the former does not depend on anything outside Qt
proper whereas the latter can and does depend on other items in Creator's
src/plugins/* and other src/libs/* bits that cannot so eaily be split off in
self-contained pieces.

Once one libs/solution/* is considered reasonably complete and stable API-wise
there may be a suggestion to move it over to Qt. Or not. (I don't think we need
a QFakeVim in the end but I'd probably make that one of the "Solutions" at some
time nevertheless.)


2. Will the release cycle of the modle be coupled to Creator's release cycle?


At least for now: As long as it's not upstreamed, yes.

[The interesting granularity here would actually be individual solutions, i.e.
currently "TaskTree", "Terminal", and "Spinner". I currently think that we
shouldn't overengineer this by, say, having "Sub-component" maintainers, but
given that the "Solutions" are by definition independent of each other _maybe_
that's the way to go mid-term. The current proposal is basically to start with
minimal bureacratic and maintenance overhead and see how far we get with that.]

Andre'


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

Re: [Development] [Qt-creator] Nominating André Hartmann as new Maintainer of VCS support in Qt Creator

[André Hartmann via Development]

Hi all,

Thank you very much for your trust. You really make me feel like I'm
part of the team.

And Orgad, thank you very much for many years of actively bringing
Creator forward. As I said privately before, you leave big footsteps
behind you. I really hope you stay around for reviews and a helping hand
whenever I need it.

About me: I'm a Creator user since version 1.2 (that was probably Qt 4.6
times). I wrote my first bugreport almost exactly 14 years ago, and
finally joined Gerrit in late 2011. I still use Creator on a daily
basis, but mostly for embedded C development, and Qt on second place.

If anyone wants to help bringing the VCS support in Creator forward:
I have a wishlist in Jira [1] and it would be nice to have more closed
tasks there.

And if you have any suggestions: feel free to contact me directly or
just add a task in Jira. I can't promise quick solutions, but I will
look at all of them.

Best regards,
André

[1] https://bugreports.qt.io/browse/QTCREATORBUG-19721

Am 26.06.24 um 13:45 schrieb Christian Kandeler via Development:

On 6/19/24 10:24 AM, Eike Ziller via Qt-creator wrote:

Resent, to fix the cc to the Development mailing list.


Am 19.06.2024 um 10:17 schrieb Eike Ziller via Qt-creator
:

Hi,

I nominate André Hartmann as the new maintainer of Version Control in
Qt Creator. His contribution history in Qt Creator goes back to 2011
as well, and he regularly worked on improving our version control
support (as well as contributing to Qt and maintaining
qtserialbus/CANBus).
https://codereview.qt-project.org/q/owner:aha_1...@gmx.de
Jarek is already maintainer under the Qt Governance Model (parts of
Qt Creator and QtHelp) and can certainly act as a backup.

Br, Eike


+1


Christian



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