Re: [Development] New survey roll-out on doc.qt.io

[Samuel Gaist via Development]

Hi,

Just in case, the link to the survey is at the bottom of each page, just above 
the footer.

You might miss it if you don’t scroll down enough.

Best regards

Samuel

> On 2 May 2024, at 14:58, Safiyyah Moosa via Development 
>  wrote:
> 
> This email is from an unusual correspondent. Make sure this is someone you 
> trust.
> Hi All
> 
> The Documentation team has launched a new survey on doc.qt.io. Help us to 
> improve our documentation by filling out the survey and letting us know your 
> thoughts!
> 
> Kind Regards,
> Safiyyah Moosa
> 
> 
> Kind Regards,
> Safiyyah Moosa
> Bsc Electronic Engineering
> Documentation EngineerQt Group
> Sandakerveien 116
> 0484 Oslo
> Norway
> safiyyah.mo...@qt.io
> +47 47794451
> www.qt.io
> --
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development




signature.asc
Description: Message signed with OpenPGP
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Christian Ehrlicher and Andy Shaw as Qt SQL co-maintainers

[Samuel Gaist via Development]

On lundi, 26 septembre 2022 09.11:23 h CEST Volker Hilsheimer wrote:
> Hi,
> 
> 
> I would like to nominate Christian and Andy as co-maintainers for Qt SQL.
> 
> Mark Brand, who is currently listed as the maintainer of Qt SQL, hasn’t
> responded to any of my emails, including one from two weeks ago where I
> explicitly informed him that he will be removed as maintainer if he doesn’t
> respond (as per the recent addition to the governance model [1], I cc’ed
> Alex Blasche as a second maintainer in that email).
 
> Christian and Andy have already agreed to take on the responsibility
> together. they both have a long history of working with the module, and as
> we support a number of SQL drivers in Qt it’s good to have more than one
> person looking after things.
 
> 
> Volker
> 
> [1] https://codereview.qt-project.org/c/meta/quips/+/423766
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

+1

Cheers

Samuel
-

signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Volker Hilsheimer as maintainer of Qt Speech

[Samuel Gaist via Development]

> On 13 Jun 2022, at 09:19, Frederik Gladhorn  wrote:
> 
> Hello :)
> 
> I've lately not had time to contribute to Qt (personal life keeping me busy).
> Since Volker and others did a great job porting Qt Speech to Qt 6, they know 
> the code better than me by this time. I'd like to step down as maintainer and 
> allow those who actually contribute to take over.
> 
> Hereby I nominate Volker as maintainer (he's agreed privately already).
> 
> Cheers,
> Frederik
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development


Hi :)

+1

Best regards

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

Re: [Development] New Chief Maintainer

[Samuel Gaist via Development]

Hi,

+1

Best regards

Samuel

> On 18 May 2022, at 10:28, Lars Knoll  wrote:
> 
> Hi all,
> 
> As I’ve said in my other email, I am resigning from my position at The Qt 
> Company to join a small startup in Norway that is working with things 
> unrelated to Qt.
> 
> As such, I won’t have too much time to spend with Qt in the future anymore, 
> and will resign from my position as the Chief Maintainer because of that.
> 
> Qt obviously needs a new Chief Maintainer to take over from me. I’ve had a 
> couple of discussions with various people over the last few weeks, and I 
> believe I’ve found a great candidate for the job.
> 
> I’d like to nominate Volker Hilsheimer as the next Chief Maintainer of Qt.
> 
> I believe that the Chief Maintainer should be someone who works full time 
> with Qt. He should know the technology, and needs to have the trust of the 
> other Maintainers. He needs to understand Qt as an Open Source project and 
> have the passion to bring the project forward. I also believe that ideally 
> the person should work for and be well connected within The Qt Company. 
> Volker has all of those aspects, and I couldn’t think of a better person to 
> take care of the Open Governance of Qt going forward.
> 
> Cheers,
> Lars
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

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

Re: [Development] Leaving The Qt Company

[Samuel Gaist via Development]

Hi Lars,

Thank you for the ride !

The road has seen some bumps but your teams and you have managed to keep Qt 
moving forward in interesting ways through all these years.

It has been a pleasure to work with you on some of my contributions.

All the best for your new journey !

Samuel

> On 18 May 2022, at 10:27, Lars Knoll  wrote:
> 
> Hi all,
> 
> Let’s take the big news first. I’ve resigned from my position at The Qt 
> Company. More on that and what it means for the Qt Project further below. 
> 
> 
> But as I’ve spent almost exactly 25 years in the Qt ecosystem, 22 of those 
> working for the various companies owning Qt, I hope it’s ok if this gets a 
> bit longer and I spend some paragraphs looking back into history.
> 
> As said, it’s been almost exactly 25 years, since I first heard about Qt. At 
> that time, I read an article in the German C’t computer magazine about a new 
> Desktop project for Linux called KDE. The underlying technology being used 
> was Qt. As a person that used Linux extensively during his studies, I 
> immediately got interested and it didn’t take long until I started my first 
> steps learning Qt.
> 
> As some of you might know I got involved rather deeply about a year or two 
> later, when I started the KHTML project to create a new HTML engine for KDE 
> in 1998/1999. That project was later forked by Apple to form the basis for 
> their WebKit project, the Safari browser and Google’s Chrome browser. It's 
> cool to think that the browser engine(s) that most people use today started 
> off as a Qt based project all those years ago.
> 
> I remember getting to know some of the people working for Trolltech back then 
> at KDE conferences. In the winter of 2000, they invited me over to Oslo to 
> have a look at Qt. The company was at that time still tiny with 11 or 12 
> employees. I got a great tour of Oslo including the ski jumping tournament at 
> Holmenkollen and signed up for the job.
> 
> I was originally expecting to spend 2-3 years at Trolltech and then at some 
> point move back to Germany. As you all can see, that’s not how it went 
> though. I ended up staying in Norway and have been working with and for Qt 
> ever since.
> 
> Starting with Qt 1.0, Trolltech released the source code to Qt (at that time 
> only for Linux/Unix), and the Open Source nature of Qt played a big part in 
> its success. I’m very happy that we could continue on that path, by over time 
> making all platforms Qt supports available as Open Source as well as moving 
> over to more standard and freer licensing (first GPL, later LGPL).
> 
> At the end of the Trolltech years, we started looking into how to make it 
> easier for the community to contribute to Qt, and first had a model where our 
> users could submit patches to us. That never really worked very well, and I’m 
> really happy that we moved over to our current governance model in 2011. 
> Since then Qt has truly been an Open Source project.
> When Qt got sold by Nokia in 2012, many people considered it a dead 
> technology. But I and many of you believed in the technology, and together 
> we’ve managed to turn this into a great success.
> 
> As you all know, Qt is a dual licensed technology. That Qt has the backing of 
> a commercial business behind it, is what made the required investments 
> possible to keep the technology competitive. 
> 
> I’m extremely proud of what we achieved with Qt over the last 10 years. It 
> happened because everybody on this list put in a lot of work into making Qt 
> one of the best development frameworks on this planet. 
> 
> Qt is something that I care deeply about. I’ve been with it all the way and 
> through all the ups and downs from when Trolltech got its first larger 
> investment to now. But seeing what you all are doing, I know it’s in very 
> good hands moving forward.
> 
> 
> 
> Leaving The Qt Company and in the future spending most of my time outside the 
> Qt ecosystem has been a difficult decision. But in the end, after those 25 
> years, it does feel very much like the right decision for me. I want to try 
> out something else. 
> 
> So I will be joining a small Norwegian startup with one of the founders of 
> Trolltech. While still in Software, it’ll be something rather different, not 
> related to C++ or developer tools. 
> 
> 
> 
> So how do things continue from here? 
> 
> First of all, I’ll still be working for Qt until my summer vacations at the 
> end of June. 
> 
> After that, I will have significantly less time for Qt, but I certainly won’t 
> be completely gone. I will continue to read the Qt project mailing lists and 
> maybe come by for events such as the Contributor or World Summit. Also, feel 
> free to send me a mail at any time, I’ll try to help where I can.
> 
> I will also keep my position as a maintainer for Qt Multimedia. I believe the 
> module is now in a decent shape, and I should be able to spend some hours per 
> week on it.
> But a few hours per week will 

Re: [Development] New Qt Multimedia

[Samuel Gaist via Development]

> On 28 May 2021, at 11:31, Tor Arne Vestbø  wrote:
> 
> 
> Cheers,
> Tor Arne
> 
>> On 28 May 2021, at 10:54, Samuel Gaist via Development 
>>  wrote:
>> 
>>> 
>>> On 28 May 2021, at 10:37, Lars Knoll  wrote:
>>> 
>>> How have you implemented those? If you implemented a gstreamer element for 
>>> those cameras, and gst-device-monitor lists them correctly, we’ll simply 
>>> pick them up.
>>> 
>>> Cheers,
>>> Lars
>> 
>> Not GStreamer as almost all devices required a custom SDK to operate the 
>> hardware.
>> 
>> These SDKs were available for different platforms. The main targets were 
>> macOS and Windows with testing on Linux when possible.
>> 
>> They were all QMediaService plugins providing Q_MEDIASERVICE_CAMERA.
> 
> Similar to GStreamer, could these HW not be implemented/exposed as camera 
> providers at the OS level on macOS and Windows? 
> 
> Tor Arne 

Technically speaking, these were not cameras but “multimedia acquisition” 
hardware, you could have one or more inputs that would in the end be connected 
to a camera or a device proving video/audio data.
Their SDKs allowed me to integrate the acquisition and control parts within Qt 
Multimedia in a clean and simple way.
I must say that I did not try to implement something else that was platform 
specific since we were provided with these SDK’s and how to use them in 
applications. Each platform was getting a set of header, libraries and samples.
One could do the rendering in a more direct way but integrating these with 
QtMultimedia allowed to take advantage of the infrastructure in place and be 
able to use both widgets and QtQuick with the same set of devices.

Best regards

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

Re: [Development] New Qt Multimedia

[Samuel Gaist via Development]

> On 28 May 2021, at 10:37, Lars Knoll  wrote:
> 
>> On 28 May 2021, at 10:27, Samuel Gaist  wrote:
>> 
>> 
>>> On 28 May 2021, at 10:09, Lars Knoll  wrote:
>>> 
>>>> On 28 May 2021, at 09:15, Alberto Mardegan  
>>>> wrote:
>>>> 
>>>> Hi Lars,
>>>> 
>>>> On 26/05/21 15:09, Lars Knoll wrote:
>>>>> The hope is that we can change that for Qt 6. To make this possible, we 
>>>>> have changed not only parts of the public API, but completely redone its 
>>>>> internal architecture, especially how multimedia connects to the platform 
>>>>> specific backends. Apart from cleaning up the backend API and greatly 
>>>>> simplifying it, I also chose to make it private and remove the plugin 
>>>>> architecture around it. The backend is now selected at compile time, and 
>>>>> we’re now only supporting one backend per platform.
>>>> 
>>>> can you please clarify what this would mean for projects (like Ubuntu
>>>> Touch) which are using their own QtMultimedia plugins?
>>>> Supporting one plugin per platform seems reasonable, but making the
>>>> plugin API private and selecting the plugin at compile time probably
>>>> means that all multimedia backends must be made part of QtMultimedia git
>>>> repository, right?
>>> 
>>> For the moment that is correct. The reason is that it greatly simplifies 
>>> maintenance of the module, something we’ve been struggling with for the 
>>> whole lifetime of Qt 5.
>>> 
>>> Having a public API for the backend was one of the main problems that made 
>>> it extremely difficult to work and maintain the module. And plugins for the 
>>> backend didn’t make much sense once the backend API is private.
>>> 
>>> A public backend API with a BC promise is simply not an option IMO, as it 
>>> will make it significantly harder to implement new functionality for Qt MM 
>>> in the future.
>>>> 
>>>> Or is it so that the backend is selected at compile time, but it can
>>>> still be dynamically loaded from a separate plugin binary?
>>> 
>>> No, selection is done at compile time right now.
>>>> 
>>>> This has the potential to make things harder to develop, especially for
>>>> smaller projects like ours. I'm especially thinking of:
>>> 
>>> Before we go into the topics below, can we take a step back, please? I’d 
>>> first like to know *why* you were developing and maintaining your own 
>>> multimedia backend.
>>> 
>>> Cheers,
>>> Lars
>>> 
>> 
>> There might also be a need to define exactly what "multimedia backend" means 
>> here.
>> 
>> I have implemented several custom QCamera backends for hardware that were 
>> not accessible through the system multimedia API.
>> 
>> For example network cameras, AJA capture cards, BlackMagic capture cards, 
>> etc.
>> 
>> Would that still be possible with the Qt 6 implementation ?
> 
> How have you implemented those? If you implemented a gstreamer element for 
> those cameras, and gst-device-monitor lists them correctly, we’ll simply pick 
> them up.
> 
> Cheers,
> Lars

Not GStreamer as almost all devices required a custom SDK to operate the 
hardware.

These SDKs were available for different platforms. The main targets were macOS 
and Windows with testing on Linux when possible.

They were all QMediaService plugins providing Q_MEDIASERVICE_CAMERA.

Best regards

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

Re: [Development] New Qt Multimedia

[Samuel Gaist via Development]

> On 28 May 2021, at 10:09, Lars Knoll  wrote:
> 
>> On 28 May 2021, at 09:15, Alberto Mardegan  
>> wrote:
>> 
>> Hi Lars,
>> 
>> On 26/05/21 15:09, Lars Knoll wrote:
>>> The hope is that we can change that for Qt 6. To make this possible, we 
>>> have changed not only parts of the public API, but completely redone its 
>>> internal architecture, especially how multimedia connects to the platform 
>>> specific backends. Apart from cleaning up the backend API and greatly 
>>> simplifying it, I also chose to make it private and remove the plugin 
>>> architecture around it. The backend is now selected at compile time, and 
>>> we’re now only supporting one backend per platform.
>> 
>> can you please clarify what this would mean for projects (like Ubuntu
>> Touch) which are using their own QtMultimedia plugins?
>> Supporting one plugin per platform seems reasonable, but making the
>> plugin API private and selecting the plugin at compile time probably
>> means that all multimedia backends must be made part of QtMultimedia git
>> repository, right?
> 
> For the moment that is correct. The reason is that it greatly simplifies 
> maintenance of the module, something we’ve been struggling with for the whole 
> lifetime of Qt 5.
> 
> Having a public API for the backend was one of the main problems that made it 
> extremely difficult to work and maintain the module. And plugins for the 
> backend didn’t make much sense once the backend API is private.
> 
> A public backend API with a BC promise is simply not an option IMO, as it 
> will make it significantly harder to implement new functionality for Qt MM in 
> the future.
>> 
>> Or is it so that the backend is selected at compile time, but it can
>> still be dynamically loaded from a separate plugin binary?
> 
> No, selection is done at compile time right now.
>> 
>> This has the potential to make things harder to develop, especially for
>> smaller projects like ours. I'm especially thinking of:
> 
> Before we go into the topics below, can we take a step back, please? I’d 
> first like to know *why* you were developing and maintaining your own 
> multimedia backend.
> 
> Cheers,
> Lars
> 

There might also be a need to define exactly what "multimedia backend" means 
here.

I have implemented several custom QCamera backends for hardware that were not 
accessible through the system multimedia API.

For example network cameras, AJA capture cards, BlackMagic capture cards, etc.

Would that still be possible with the Qt 6 implementation ?

Best regards

Samuel

>> 
>> 1) The QtProject might even flatly refuse to include a backend which is
>> only used in a minor platform
>> 2) It will be hard (if not impossible) to run CI on it, we'll only be
>> able to test the Qt builds in our own CI, but that might be too late (I
>> mean, it's not really CI anymore)
>> 3) Licensing issues (well, this is not a problem for our specific case,
>> I think)
>> 
>> Ciao,
>> Alberto
>> 
>> -- 
>> http://www.mardy.it - Geek in un lingua international
>> ___
>> 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] New Qt Multimedia

[Samuel Gaist via Development]

> On 27 May 2021, at 14:35, Lars Knoll  wrote:
> 
>> On 27 May 2021, at 14:25, Eike Hein  wrote:
>> 
>> May 27, 2021 8:14 AM, "Lars Knoll"  wrote:
>>> The one thing I want to avoid is what we had in Qt 5, where you could force 
>>> Qt MM to use a
>>> different/custom gstreamer pipeline based on environment variables. That 
>>> part made maintaining the
>>> code base extremely hard. Other than that I’m of course open for patches 
>>> and improvements. If some
>>> integration points are needed, we can discuss those separately, but unless 
>>> they are trivial, they
>>> will probably need to wait until after 6.2.
>> 
>> Hmm - does that mean the `gst-pipeline:` URL scheme for `setMedia`/the 
>> `source`
>> prop is getting dropped as well?
> 
> That’s correct. It’s has honestly been a huge cludge, and something we didn’t 
> have anywhere else. I’d rather see that we fix issues inside Qt MM instead of 
> working around them with hacks such as this one.
>> 
>> If memory serves right, this was possible accidentally at some point and then
>> was raised to the status of Official Footgun in 5.12+:
>> 
>> https://doc.qt.io/qt-5/qmediaplayer.html#setMedia
> 
> Footgun is probably the right name for it, and a reason I don’t want to 
> continue with it for Qt 6.
>> 
>> A potential troublemaker for sure, but also very powerful. With QtGStreamer
>> being deprecated (an old set of Qt bindings to GStreamer API - also something
>> at least one KDE app I'm aware of still carries an internal fork of, sadly),
>> a QtMM w/ custom pipeline support sort of the next best thing.
> 
> Lets rather have a look at the use cases that people want to have supported 
> and how we can get those working.
> 
> Cheers,
> Lars
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

I think one of the main use case I have seen for custom GStreamer pipelines is 
to be able to get rtsp or other network streams in Qt applications.

Best regards

Samuel

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

Re: [Development] A face for the Qt Project

[Samuel Gaist via Development]

> On 18 Mar 2021, at 19:38, Cristián Maureira-Fredes 
>  wrote:
> 
> Dear community,
> 
> The Qt Project is a huge effort from many people, and for the same
> reason, it's quite interesting to (1) Learn how to contribute and be
> part of it, and (2) Analyze the interactions of the many
> Qt modules.
> 
> For people new to the project, contributing to Qt might be challenging,
> but I'm certain we all agree that being clear, and provide all the
> information in one place is crucial to at least enable them to do
> the first step.
> 
> On the other hand, if you have been around for a while,
> you know that Thiago's blog has a good set of statistics [1]
> that helps a lot to get an overview of the current state of the project.
> 
> With these two ideas in mind, it makes sense to use qt-project.org
> as the face of the Qt Project, highlighting the two previous points
> I described.
> 
> I would like to ask the community, if we are in favor of using
> the proposal from [2] as qt-project.org.
> 
> The goal will be to have this repository under our open governance,
> so anyone will be able to suggest changes, as we do in Qt.
> 
> The idea will be not to duplicate content from https://qt.io,
> but focus on aspects related to contributing to the project.
> 
> 
> # About the implementation
> 
> The page you can see on [2] was generated with Dash,
> a Python module based on Plotly [3], and the data comes from the
> meta qt5.git repository, including also the qt-creator and pyside-setup
> ones.
> 
> The text you see on the left-side cards, comes from local Markdown
> files, so also it would be straightforward to edit them.
> 
> I will upload the code if the community agrees to go forward,
> so then we could be able to create a public repository to keep
> this code.
> 
> Cheers
> 
> 
> [1] https://www.macieira.org/blog/qt-stats/
> [2] https://qt-project-org.herokuapp.com
> [3] https://dash.plotly.com/
> 
> --
> Dr. Cristián Maureira-Fredes
> R Manager
> 
> The Qt Company GmbH
> Erich-Thilo-Str. 10
> D-12489 Berlin
> 
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Jouni Lintunen
> Sitz der Gesellschaft: Berlin,
> Registergericht: Amtsgericht
> Charlottenburg, HRB 144331 B
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

+1

Great Idea !
And it looks pretty nice.

Samuel


signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Aleix Pol Gonzalez for approver status

[Samuel Gaist via Development]

> 
> On 18 Feb 2021, at 07:30, Eskil Abrahamsen Blomfeldt 
>  wrote:
> 
> Hi all!
>  
> I would like to nominate Aleix Pol Gonzalez as an approver for the Qt Project.
>  
> Aleix has been a contributor to KDE and Qt for many years, touching on many 
> different areas of Qt, and has lately been actively involved in Qt Wayland to 
> help improve its position on the Linux desktop: 
> https://codereview.qt-project.org/q/owner:aleixpol%2540kde.org
> 
> Eskil Abrahamsen Blomfeldt
> Senior Manager, Graphics
> 
> The Qt Company
> Sandakerveien 116
> 0484 Oslo, Norway
> eskil.abrahamsen-blomfe...@qt.io
> http://qt.io
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

Hi,

+1

Best regards

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

Re: [Development] Proposing Alex Trotsenko as approver

[Samuel Gaist via Development]

> On 17 Sep 2020, at 11:37, André Hartmann  wrote:
> 
> 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

+1

Best regards

Samuel

--
Samuel Gaist
Senior Research And Development Engineer
Idiap Research Institute,
Centre du Parc,
CH-1920 Martigny
http://www.idiap.ch/







signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QHelpEngineCore::documentsForIdentifier

[Samuel Gaist via Development]

Hi,

> On 27 Aug 2020, at 19:07, Edward Welbourne  wrote:
> 
> Martin Koller (14 August 2020 17:06) wrote:
> 
>> I found myself getting an empty list when using
>> QHelpEngineCore::documentsForIdentifier(id) but getting 1 element when
>> using the deprecated QHelpEngineCore::linksForIdentifier(id).
> 
> Definitely sounds like a bug, although I find no
> QHelpEngineCore::linksForIdentifier() - did you mean
> QHelpCollectionHandler::linksForIdentifier() ?
> 
>> Checking the code I stumbled over something which I believe is a bug:
>> 
>> QHelpEngineCore::documentsForIdentifier(const QString , const
>> QString ) does
>> 
>> if (!d->setup() || !d->usesFilterEngine)
>>return QList();
>> 
>> so it checks if the new filter engine is active, but I think this is
>> not needed here, since in this code, the filter engine is not used at
>> all, since the filterName is already given as argument.
> 
> Sounds plausible.
> Also, QHelpEngineCore::documentsForIdentifier(const QString ) calls
> documentsForIdentifier(const QString , const QString )
> passing a filterName that it determines based on d->usesFilterEngine,
> which rather suggests it thinks d->usesFilterEngine isn't a prerequisite
> of getting any entries.
> 
>> Since I ported older code to the new api but did not call
>> setUsesFilterEngine(true) (which I believe should not be needed when I
>> don't work with filters), this check was hit and I get no results.
>> 
>> Am I right ?
> 
> I don't know this code at all but it sounds like reasonable grounds to
> submit a patch to Gerrit and ask for review by folk implicated in the
> review that added this code (this March):
> https://codereview.qt-project.org/c/qt/qttools/+/291144
> 
>   Eddy.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

You need to enable the new filter engine using:

https://doc.qt.io/qt-5/qhelpenginecore.html#setUsesFilterEngine

The documentation has been modified for the next release to make it clearer.

--
Samuel Gaist







signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Coin: Maintainer has changed

[Samuel Gaist via Development]

Hi Aapo,

Thanks for the great work on our beloved CI.

And welcome on board Toni !

Samuel

> On 27 Mar 2020, at 08:35, Aapo Keskimölö  wrote:
> 
> Hi Qt Developers,
> 
> I would like to let you know that I will be leaving development tasks at Qt 
> for the time being to follow my other dream in the field of software 
> engineering and therefore I am forced to step out of the Coin maintainer role 
> that has been the most fun project that I have ever had the opportunity to 
> work with.
> 
> I will be leaving the responsibility to capable hands
> 
>  Toni Saario
> 
> who has despite of his young age been eager to learn about the maintainership 
> which is by no means trivial task based on my couple of years of experience 
> on it.
> 
> Let's welcome Toni as the new Coin component leader!!
> 
> 
> Ystävällisin terveisin / Kind regards,
> 
> Aapo Keskimölö
> Senior Software Engineer | Coin Component Owner
> Qt RnD Delivery Automation | CI Team
> The Qt Company | Finland | Oulu
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

--
Samuel Gaist
Senior Research And Development Engineer
Idiap Research Institute,
Centre du Parc,
CP 592,
CH-1920 Martigny
http://www.idiap.ch/






signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Github issues

[Samuel Gaist via Development]

> On 6 Mar 2020, at 12:00, Alex Blasche  wrote:
> 
>> Thanks for the heads up. Whoever is maintaining those repos (?) need to turn 
>> off issues: 
>> >https://help.github.com/en/github/managing-your-work-on-github/disabling-issues
> 
> I wish this could be done via the parent organization. But there doesn't seem 
> to be an option for it. Sigh, I guess I have to walk each repo.
> 
> --
> Alex
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

You don’t have to do all the repos, just the ones I have listed (well for the 
issue disabling part)

Best regards

Samuel


signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Github issues

[Samuel Gaist via Development]

Hi,

For once, something not strictly code related :-)

Some of the latest Qt modules that have been synced to GitHub still have 
"issues" activated and for example:

https://github.com/qt/qtquick3d

has already several posted.

Also concerned:

https://github.com/qt/qtshadertools
https://github.com/qt/qtlottie
https://github.com/qt/qtlanguageserver
https://github.com/qt/qtvoiceassistant
https://github.com/qt/qtanalytics

Beside issues, overall, many of the repositories on Github have one or more 
pull requests that might be of interest.

Best regards

Samuel



signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Samuel Gaist]

> On 26 Nov 2019, at 09:36, Alex Blasche  wrote:
> 
> 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

+1

-- 
Samuel Gaist
Research And Development Engineer
Idiap Research Institute, 
Centre du Parc, 
CP 592, 
CH-1920 Martigny
http://www.idiap.ch/



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

Re: [Development] HTML5/CSS vs Qt QML and QtCreator / Assistant

[Samuel Gaist]

> On 28 Jun 2019, at 11:32, Cristian Adam  wrote:
> 
> Hi,
>  
> Some of you might have been familiar with white papers such as Qt QML v HTML5 
> – a practical comparison.
>  
> Qt Creator already ships with QML support, why not transform the HTML offline 
> documentation into QML?
> Does it have to be HTML5/CSS?
>  
> Having the documentation as QML will have no additional constrains for Qt 
> Creator. No 76MiB Qt5WebEngineCore.dll file, no memory increase, no startup 
> penalty.
>  
> QML is supported on all platforms, right? Builds with MinGW on Windows, and 
> so on.
>  
> Cheers,
> Cristian.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

Hi,

While I find the idea interesting in itself, as silly as it may sound, it has 
one main constraint: OpenGL.

On my old Mac, using QtQuick triggers the high end graphic card which drains 
the battery and make my machine heat go up.

I (and I know am not the only one) usually start Qt Creator with all QtQuick 
related plugins disabled to avoid that when possible.

So this use case would make the documentation not accessible for these people.

Best regards

Samuel

-- 
Samuel Gaist
Research And Development Engineer
Idiap Research Institute, 
Centre du Parc, 
CP 592, 
CH-1920 Martigny
http://www.idiap.ch/



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

Re: [Development] Assistant WebKit/WebEngine support

[Samuel Gaist]

> On 28 Jun 2019, at 07:59, Martin Smith  wrote:
> 
>> That's what I'm trying to explain. I can't use what Creator gives me right 
>> now
>> as it doesn't match what is published on Qt's very own documentation site
>> (https://doc.qt.io).
> 
> Shouldn't Creator go directly to the documentation site to get what it needs?

Hi,

Please, no.

One of the strong point of Assistant or the Qt Creator help module is that you 
have the full Qt documentation at hand
whenever you need it with or without internet connection.

Personally, I’d rather avoid the always online mode. Not everybody has a good 
quality internet link nor unlimited data plan.
I know it’s "only documentation" and it’s going to be compressed, etc to lower 
bandwidth usage but still, the less
data you need to download the better.
You have people that have to work in restricted environments who might not even 
have internet access for that matter.
So even if the documentation is somehow cached after download, it’s still going 
to be an additional check to do and network
usage need that doesn’t exists currently.

Best regards

Samuel

> 
> 
> From: Development  on behalf of Palaraja, 
> Kavindra 
> Sent: Friday, June 28, 2019 7:40 AM
> To: development@qt-project.org
> Subject: Re: [Development] Assistant WebKit/WebEngine support
> 
> On 27.06.19, 20:59, "Development on behalf of André Pönitz" 
>  wrote:
> 
> 
>> People propose adding functionality to QTextBrowser instead. I do not
>> thing that’s a viable solution (we’ve tried that in the past and our
>> technical writers hit the next issue some weeks/months later). The
>> problem is not that one could not add support for one or two new
>> features to QTextBrowser, it is that we do not know what features we
>> will need in our docs in the future.
> 
>The current feature set is kind of sufficient to get the job done.
>Nobody claims that it is perfect or even close to that. Also, my "our"
>technical writers (which surprisingly seem to be different from your
>"our" technical writers) hinted that the missing table borders might
>actually be a recent regression in QTextBrowser.
> 
> Andre, you are trying to reduce the problem down to "one table rendering bug" 
> and otherwise saying "it gets the job done."
> 
> I have demonstrated in earlier e-mails that the problem is actually threefold:
> 
> 1. Our users are complaining that their own External Content is not rendered 
> correctly since 16 March 2016: 
> https://bugreports.qt.io/browse/QTCREATORBUG-15887
> 2. Our own official documentation, generated with the official qdoc, also 
> does not render correctly.
> 3. The technology we are using to display the documentation is not 
> futureproof. I have demonstrated this by giving multiple example of how our 
> competition is using today's technology to convey difficult technical topics 
> in a beautiful and intuitive way to attract and retain their users.
> 
> As you've read in another e-mail, we've officially lost Richard as a user. 
> He's not going to use Creator's Help Integration anymore.
> 
>> And that we (as Kavindra pointed out) are wasting a lot of our
>> technical writers time trying to ensure the content is rendered in a
>> somewhat usable way in Creator.
> 
>The time is wasted only if the result cannot be used, e.g. when one
>doesn't take the target environment into account when doing the work.
> 
> That's what I'm trying to explain. I can't use what Creator gives me right 
> now as it doesn't match what is published on Qt's very own documentation site 
> (https://doc.qt.io).
> As a customer, you don't even realize you've fallen into this problem as it's 
> not mentioned anywhere in the documentation for using the QtHelp Framework 
> https://doc.qt.io/qt-5/qthelp-framework.html
> Notice that QTextBrowser only shows up once there, and nothing is mentioned 
> about its limitations.
> 
> Kavindra.
> 
> 
> 
> 
> This e-mail and any attachment(s) are intended only for the recipient(s) 
> named above and others who have been specifically authorized to receive them. 
> They may contain confidential information. If you are not the intended 
> recipient, please do not read this email or its attachment(s). Furthermore, 
> you are hereby notified that any dissemination, distribution or copying of 
> this e-mail and any attachment(s) is strictly prohibited. If you have 
> received this e-mail in error, please immediately notify the sender by 
> replying to this e-mail and then delete this e-mail and any attachment(s) or 
> copies thereof from your system. Thank you.

[Development] Coin mailing issue

[Samuel Gaist]

Hi guys,

Does anybody know what is happening with coin ?

Over the last couple of hours I have received more that an hundred of emails 
about integration failure some of which don’t even contains patches I have 
submitted, participated in or reviewed.

Best regards

Samuel

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

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Samuel Gaist]

that QHash/QMap are all but
>> unusable in C++11 ranged for loops, because of decltype(*it)?
> 
> Can't we just add a keySet() method (named after the Java one that does
> something similar) that returns a wrapper object that just forwards begin()
> to the map's keyBegin() etc.? Then you could just write something like:
> for (auto key : map.keySet())
> and it should do conceptually the same as:
> for (auto key : map.keys())
> but without ever having to build the list of keys as a list.
> 
> Or, probably even more efficiently, add cursorBegin() etc. iterator methods
> that return iterators returning key-value pairs as QPair, and a cursorSet()
> that returns a wrapper object for them like keySet() above. Then:
> for (auto cursor : map.cursorSet())
> would get you key-value pairs, wouldn't it?

Since Qt 5.10, QHash and QMap have something for that:

https://doc.qt.io/qt-5/qhash.html#keyValueBegin
https://doc.qt.io/qt-5/qhash.html#keyValueEnd

And their corresponding const versions. 

Note that the iterator returns a std::pair.

Best regards

Samuel

-- 
Samuel Gaist
Research And Development Engineer
Idiap Research Institute, 
Centre du Parc, 
CP 592, 
CH-1920 Martigny
http://www.idiap.ch/



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

Re: [Development] Nominating Brett Stottlemeyer for Approver status

[Samuel Gaist]

+1 from me too

> On 18 Mar 2019, at 09:05, Ville Voutilainen  wrote:
> 
> Brett is the maintainer of Qt Remote Objects. Thus he should be 
> documented as a maintainer, and should also be an approver. Brett has 
> been effectively maintaining QRO since 2014, so it seems like a slam 
> dunk to give him the rights.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Samuel Gaist
Research And Development Engineer
Idiap Research Institute, 
Centre du Parc, 
CP 592, 
CH-1920 Martigny
http://www.idiap.ch/



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

Re: [Development] QtWebEngine file path too long

[Samuel Gaist]

> On 13 Mar 2019, at 00:00, Thiago Macieira  wrote:
> 
> On Tuesday, 12 March 2019 15:44:22 PDT Samuel Gaist wrote:
>> The solution currently is to move the build out of the encrypted partition.
> 
> That's not an option for me. Company requires full hard-drive encryption.
> 
> What OS and what encryption are you using?
> 
> -- 
> 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

I’m using KDE Neon with the default setup for encrypted disk. IIRC it’s done 
through LVM.

Best regards
Samuel
-- 
Samuel Gaist
Research And Development Engineer
Idiap Research Institute, 
Centre du Parc, 
CP 592, 
CH-1920 Martigny
http://www.idiap.ch/



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

[Development] QtWebEngine file path too long

[Samuel Gaist]

Hi,

I’ve been hit by this surprising error when building QtWebEngine.

Luckily (well…) I was recently facing the same issue while trying to build a 
conda package. Searching how to fix that gave me a solution that is also 
working for the build of QtWebEngine.

As it turns out, it was due to me building this stuff on an encrypted partition.

The solution currently is to move the build out of the encrypted partition.

Best regards

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

Re: [Development] New linguist maintainer nomination

[Samuel Gaist]

> On 7 Jan 2019, at 13:51, Alex Blasche  wrote:
> 
> Hi,
> 
> After Ossi stepping down as maintainer for Linguist and related tools 
> (lupdate/lrelease) I would like to propose Kai Koehne to take over. Kai has a 
> long history working on Qt and even more specifically with Qt's translation 
> tools. 
> 
> --
> Alex
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

Hi,

+1

Best regards

Samuel
-- 
Samuel Gaist
Research And Development Engineer
Idiap Research Institute, 
Centre du Parc, 
CP 592, 
CH-1920 Martigny
http://www.idiap.ch/



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

Re: [Development] Nominating Christian Ehrlicher for Approver

[Samuel Gaist]

Hi,

> On 20 Nov 2018, at 09:38, Richard Gustavsen  wrote:
> 
> Hi,
> 
> I'd like to nominate Christian Ehrlicher for approver rights.
> 
> He has done a lot of work in Qt, especially Widgets and Item Views, with more 
> than 150 patches being merged during the last year.
> 
> He has also been equally active in Jira, verifying bug reports, identifying 
> duplicates, etc.
>  
> His work:
> https://codereview.qt-project.org/#/q/owner:%22Christian+Ehrlicher%22,n,z 
> 
> His reviews:
> https://codereview.qt-project.org/#/q/reviewer:%22Christian+Ehrlicher%22,n,z
> 
> Br,
> Richard Moe Gustavsen
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

+1

He’s also an active member on the forum.

Cheers

Samuel

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

Re: [Development] Orphan modules

[Samuel Gaist]

Hi Eddy,

If you guys think my competences fill the bill, I can take on the qtmacextras
module maintenance.

Best regards

Samuel

> On 30 Aug 2018, at 15:27, Edward Welbourne  wrote:
> 
> I notice, as part of seeking folk to look at API reviews, that we have
> several modules with no Maintainer: qtandroidextras, qtgraphicaleffects,
> qtmacextras, qtquick1, qtquickcontrols, qtsvg, qtwinextras and (the one
> that brought this to my attention) qtxmlpatterns, according to [0].
> 
> * [0] https://wiki.qt.io/Maintainers
> 
> (There's also qtdoc, with no person as maintainer, but with "Norway" in
> the Country column, which I interpret as the doc-team here in Oslo; and
> there's qtfeedback, which is unsupported; two other unsupported modules
> do in fact have Maintainers.)
> 
> If anyone out there feels an urge to volunteer to adopt one of these
> orphans, it'd be worth speaking up,
> 
>   Eddy.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development





signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposing Samuel Gaist for approver status

[Samuel Gaist]

Hi,

Thank you very much for the vote of confidence !

Samuel

> On 20 Aug 2018, at 12:48, Alex Blasche  wrote:
> 
> Congratulations to Samuel. OGApprover rights have been set.
> 
> --
> Alex
> 
> 
> From: Development 
>  on behalf of 
> André 
> Sent: Saturday, 28 July 2018 10:56:37 AM
> To: development@qt-project.org; samuel.ga...@idiap.ch
> Subject: [Development] Proposing Samuel Gaist for approver status
> 
> Hello all,
> 
> I'd like to propose Samuel as approver. He has been active in the Qt project 
> for ages.
> 
> He not only provides code changes [0], he is also active reviewing others 
> changes [1].
> 
> But that's not all: Samuel is *extremly* active in the Qt Forum [2], where he 
> works
> as moderator and answers plenty of questions every day.
> 
> Some of his patches arised from forum questions, therefore Samuel perfectly 
> bridges
> between the end users and the Qt main developers.
> 
> I think this all qualifies Samuel for the approver status.
> 
> Best regards,
> André
> 
> [0] 
> https://codereview.qt-project.org/#/q/owner:%22Samuel+Gaist+%253Csamuel.gaist%2540idiap.ch%253E%22,n,z
> [1] 
> https://codereview.qt-project.org/#/q/reviewer:%22Samuel+Gaist+%253Csamuel.gaist%2540idiap.ch%253E%22,n,z
> [2] https://forum.qt.io/user/sgaist
> ___
> 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
> 

--
Samuel Gaist
Research And Development Engineer
Idiap Research Institute,
Centre du Parc,
CP 592,
CH-1920 Martigny
http://www.idiap.ch/





signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Samuel Gaist]

> On 14 Aug 2018, at 13:48, Jani Heikkinen  wrote:
> 
> Hi!
> 
> We have soft branched '5.12' from 'dev' today. We are planning to have final 
> downmerge and Qt 5.12 Feature Freeze Monday 20.8.2018. So there is still time 
> to finalize ongoing task in 'dev' and start using '5.12' for new changes 
> targeted to Qt 5.12 release.
> 
> br,
> Jani Heikkinen
> Release Manager
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

Hi,

I just received approval for an API addition to QTextEdit and QPlainTextEdit 
(QRegularExpression find overload).

Is it still on time for feature freeze since it happens today ?

It’s nothing vital, I just want to know whether I should change the 
documentation to 5.13 and resubmit.


Thanks

Samuel


signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposing David Faure as maintainer of Qt Models

[Samuel Gaist]

Big +1

Cheers,
Samuel

> On 12 Mar 2018, at 18:10, Sérgio Martins  wrote:
> 
> Hi,
> 
> 
> Although the wiki says Qt Models don't have a maintainer I'd say David Faure 
> has been an unofficial maintainer.
> David is one of the top contributors to model related code and is someone 
> you'll always want to add as reviewer.
> 
> He's well known in the community and already maintains QtXmlPatterns, Qt 
> mimetypes and Qt3Support.
> 
> Disclaimer: David works with me at KDAB.
> (And if you're wondering if KDAB has any plans for this module, the answer is 
> no. In fact I hope it remains low change volume).
> 
> 
> Finally, a big thanks to the previous maintainer, Stephen Kelly, who did a 
> great job, both on Qt and KDE models!
> 
> 
> 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
> 



signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Ville Voutilainen as approver

[Samuel Gaist]

+1

Best regards

Samuel

> On 27 Feb 2018, at 10:36, Simon Hausmann  wrote:
> 
> Hi,
> 
> I would like to nominate Ville as approver. Due to his work in the GCC 
> project he is certainly experienced with strict code reviews. Based on my 
> interaction with him I'm convinced that he has successfully demonstrated the 
> same skill set during code reviews in Qt.
> 
> 
> 
> Simon
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Goodbye

[Samuel Gaist]

> On 9 Feb 2018, at 21:14, Jake Petroules  wrote:
> 
> 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
> 

Hi Jake,

-2 ;-)

Sad to see you go but grateful for all what you did.

Thanks for the reviews, collaboration, insights of the Apple platforms and all 
the rest.

Good luck for your next endeavours !

Best regards,

Samuel


signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] how to include further changes while previous commit is still under review?

[Samuel Gaist]

> On 18 Jan 2018, at 22:42, Daniel Savi  wrote:
> 
> Hello qt devs
> 
> I'm back with another newbie question. I have committed a patch that is still 
> under review on gerrit.
> 
> Meanwhile, I've got a local and unrelated patch on the same file, that I 
> would like to commit, too.
> 
> Now, how would I include this patch into my local git repo and how would I 
> commit it as a separate patch to the first?
> 
> How could I still work on the first patch, once more comments are coming in?
> 
> Would I create separate branches?
> 
> Sorry for my very basic level of git-foo.
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

Hi,

Since the patch is unrelated, use a different topic branch for that one and 
submit it like the other one.

Depending on the impact of your change, you might want to look at 
https://git-scm.com/docs/git-worktree and have a separate build for it.

Cheers

Samuel


signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Repository request: Qt Notifier

[Samuel Gaist]

> On 16 Jan 2018, at 15:04, Shawn Rutledge  wrote:
> 
> 
>> On 16 Jan 2018, at 14:49, Kari Oikarinen  wrote:
>> 
>> 
>> On 15.01.2018 17:25, Ryan Chu wrote:
>>> Hi all,
>>> I'm working on a task supporting "Push Notification" for Qt applications. 
>>> This feature will be implemented on Android and iOS devices as the first 
>>> stage. A new module called "Qt Notify" will be created for all platforms. 
>>> Therefore I request a repository.
>> 
>> This sounds like it overlaps with qtcloudmessaging which also seems
>> to be about push notifications? Or are they actually about something
>> different and I'm mixing things?
>> 
>> http://blog.qt.io/blog/2018/01/02/qt-cloud-messaging-api-available-embedded-systems/
> 
> Good catch.  So is the API suitable for expanding to mainstream platforms?
> 
> Also “Qt Notifications” sounds too generic to me, and maybe a bit misleading… 
> we know we need to add support for system/desktop notifications (like the 
> sidebar on macOS, and other UIs on Android and iOS and others) and some work 
> was supposed to be in the pipeline for that at some point - not that it needs 
> its own repo, but this concept might still be the first association for many 
> people.  Cloud-based notification is more specific.

Hi,

The work you are thinking about is likely this one: 
https://codereview.qt-project.org/#/c/166456/. I’d be happy to reactivate it.

Cheers

Samuel


signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Seeking advise using git and code review

[Samuel Gaist]

> On 4 Oct 2017, at 08:55, Daniel Savi  wrote:
> 
> Hello everybody

Hi and welcome new contributor :)

> 
> 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?

Edit the commit message on your machine and push again to the code review 
server the same way you did the first time. The Change-Id that has been added 
to the commit message will serve as identifier so your new version of the patch 
will be appended to the review.

> 
> 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?

If you are in a detached state: git checkout -b branch_name, this will create a 
new branch from where you are and change to it directly keeping your commit(s).
What you see on the gerrit page is the command list to cherry-pick the patch 
for anybody who would like to either test it, improve on it etc. You can click 
on the other possibilities depending on the git workflow you want to use.

> 
> 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?

Usually, take a look at the log of the files you modified to see who reviewed 
the last changes excluding the copyright updates. If nothing moved after some 
times or if the reviewer(s) associated are no longer active, add the module 
maintainer.

> 
> Sorry for the lengthy post.
> 

It’s fine.

Cheers
Samuel

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



signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] "Getting started" tutorials (Was: Examples and Demos in qtdoc)

[Samuel Gaist]

> On 16 Jun 2017, at 16:17, Sze Howe Koh  wrote:
> 
> On 15 June 2017 at 01:29, Tuukka Turunen  wrote:
> > Hi,
> >
> > Yes, we would like to overall improve the examples. This is related to 
> > having a new repo for examples, but not fully the same thing. Main goal in 
> > example improvement being to make them more useful in what they are: 
> > examples of how to use Qt. Currently there are some examples that implement 
> > their own rudimentary controls instead of using Qt Quick Controls 2. We 
> > also have some examples that do not properly leverage our tooling. Some 
> > examples might not show the very best way to do things, as the new APIs 
> > allow even better way than at the time of creating the example.
> >
> > What comes to WOW, we do need to have great looking demos and at least some 
> > examples should look good as well. However, that WOW should not be the 
> > ultimate goal. The purpose of examples is to help users make better use of 
> > Qt and sometimes making things too shiny can be counterproductive. Another 
> > thing is that this WOW is a quite subjective matter and different trends 
> > come and go. It is fine to make an example look great, but that should not 
> > be the sole purpose.
> >
> > Yours,
> >
> > Tuukka
> 
> Understood.
> 
> On the topic of showing users "how to use Qt" and "leverage our tooling", I 
> feel that our "getting started" tutorials/examples need some love too.
> 
> IMHO, the "Getting Started" tutorial from Qt 4.3 
> (https://doc.qt.io/archives/4.3/tutorial-t1.html) is more accessible to 
> beginners than http://doc.qt.io/qt-5/gettingstartedqt.html mainly because the 
> Qt 4.3 tute presents material in digestible chunks. Readers are introduced to 
> the bare bones, and get to compile and interact with their code very early 
> on. Then, the tute gradually introduces more and more concepts across a 
> number of chapters; each chapter builds upon the previous. The reader gets to 
> build and try out the new concepts in each chapter, before moving on to the 
> next.
> 
> In contrast, the Qt 5 tutorial takes the reader through a multitude of 
> concepts (Qt Designer, the UIC file format, the *.pro file, subclassing 
> widgets, the Q_OBJECT macro, properties, signals and slots, layouts, and many 
> different classes) before the reader is taught how to compile and run their 
> first app. If the reader made a mistake somewhere along the way, it's hard to 
> find out where. There is far too much material packed into a single "getting 
> started" article.
> 
> I'm thinking of spending some time to update the Qt 4.3 tutorial (chapters 1 
> - 7) for Qt 5, presented in a few different ways to show how to do the same 
> thing using different Qt technologies:
> 
> 1. C++ only
> 2. C++ with Qt Designer
> 3. QML only
> 4. QML with Qt Quick Designer
> 
> Is this something you'd want in the official documentation?
> 
> 
> Regards,
> Sze-Howe
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

+100

We seem to, lately, have a lot of beginners on the forum that would benefit 
from such a nice set of tutorials.

Cheers,
Samuel



signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Someone please fix the remaining qrand cases in SSL code

[Samuel Gaist]

> On 12 Jun 2017, at 22:45, Thiago Macieira  wrote:
> 
> I can't submit changes to SSL-related code, so can someone apply the
> equivalent of https://codereview.qt-project.org/191738 to the files listed in
> that commit's message?
> 
> I cannot review your change either.
> 
> --
> 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

Hi,

AFAIK, I am not under that restriction so:

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

Cheers
Samuel


signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Periodical digest from the CI (2017/05) - CI Performance, HW and SW changes

[Samuel Gaist]

> On 30 May 2017, at 09:15, Tony Sarajärvi  wrote:
> 
> Hi all!
> 
> I was due to write you something about the CI. This time I’ll cover the 
> topics performance as well as upcoming hardware and software changes.
> 
> Performance:
> 
> You have all noticed that the CI system is behaving poorly to what comes to 
> the performance. Sometimes autotests take over 30 times longer to run 
> compared to a normal situation. Now why is that?
> 
> We actually have different kinds of bottlenecks. One is the bandwidth with 
> which the virtual machines (VMs) store local data to their virtual hard 
> drives. The servers on which our virtual machines run have no local hard 
> drives. They instead store all their data on a centralized storage called the 
> Compellent (https://en.wikipedia.org/wiki/Dell_Compellent). So when a VM 
> wants to store data on its virtual hard drive, the host it runs on actually 
> stores the data on the centralized storage.
> 
> We have several generations of hardware installed, and they have different 
> speeds on their SAN interface with which they are connected to the 
> Compellent. As your build picks up a server, it can be a new rack server, or 
> it can be an older generation Blade 
> (https://en.wikipedia.org/wiki/Blade_server). Also, all the other VMs on 
> these servers share the same bandwidth, so depending on what the other builds 
> do, your SAN connection can be affected. Sadly, our test of prioritization 
> these VMs, didn’t produce expected results and really didn’t much at all.
> 
> These generations of hardware and type of hardware also affect the amount of 
> other VMs the hardware can run simultaneously.  We have Mac mini’s running 
> our macOS builds. Those generally run 1 VM per physical Mac mini. Then we 
> have old Blades that run around 4 VMs per Blade. The latest additions to our 
> hardware pool are dual socket 20 core CPU server racks. Those run up to 26 
> VMs simultaneously. Running more on the same hardware reduces costs for us, 
> but also increases the odds of one build affecting the next.
> 
> Another bottleneck is the Compellent itself. The storage system has 120 + 10 
> spare hard drives spinning at 15K RPM. However great the IOPS performance is 
> in that system, when we decide to start 200+ VMs in the CI, it goes down to 
> its knees. And when it does that, all builds and autotest run are affected. 
> You could think of this as you having 2 computers at home sharing the same 
> spinning disk.
> 
> Now that all is grim and morbid, let’s continue with the good news.
> 
> Upcoming hardware changes:
> 
> We’re replacing the current hardware stack with a completely new one. The 
> parts have arrived and are being installed as I type right now. Not only did 
> we acquire new hardware that is faster, but we also redesigned the building 
> concepts so that they utilize the hardware differently. The new hardware can 
> be easily expanded and we designed the system so, that we don’t produce 
> bottlenecks even when expanding it.
> 
> Before I go in to details, I need to explain a bit how the CI systems 
> generally works. So heading off on a tangent here! When developer stages a 
> commit in Gerrit (codereview.qt-project.org), the CI picks it (or multiple 
> commits) up. The CI or Coin as the piece of software is figuratively called, 
> generates work items based on the data received. If let’s say the commits was 
> for QtDeclarative, Coin now produces work items for itself to handle that 
> QtDeclarative build on top of circa 30 different target platforms. Each of 
> these work items depend on QtBase to be built. So now Coin also creates these 
> circa 30 work items for QtBase. As QtDeclarative is built on top of the 
> current qt5.git’s QtBase, it means in normal situations that QtBase has 
> already been built previously. These artifacts have been stored by Coin and 
> can now be reused. So instead of rebuilding QtBase for QtDeclarative, Coin 
> simply checks its storage and links the previous builds to the current one 
> and promptly continues with building QtDeclarative. This is the major change 
> in how we build Qt nowadays compared to old days with Jenkins where every 
> build always rebuilt the entire stack up to its point.
> 
> Continuing into more details. Whenever Coin starts to build something, it 
> needs a VM for the task. We have “templates” in vSphere that represent 
> different operating systems. They are virtual machines that have operating 
> systems installed in them along with some basic things set up like user 
> accounts and SSHD etc. Then they have been shut down ready to be used. Now 
> when a build needs a VM, it clones a template VM and launches the clone. The 
> clone is actually only a linked clone. This means that we don’t really clone 
> anything, but only create a new virtual machine that links or points to the 
> original one. Now, when the new clone is powered on, it _reads_ from the 
> original template, 

Re: [Development] [docs] changing the way overloads are documented and presented

[Samuel Gaist]

> On 28 Apr 2017, at 09:35, Marc Mutz  wrote:
> 
> Hi.
> 
> TL;DR: I propose to document overloaded functions with a single comment block,
> containing multiple \fn's and a common documentation text, to be rendered as
> one documentation block preceded by a listing of all the \fn's, instead of as
> individual functions.
> 
> Since I learned that a qdoc comment block can contain multiple \fn statements,
> I have tried to use it to document overloads with less duplication. E.g.:
> 
>  /*!
>\fn bool QStringView::startsWith(QStringView str, Qt::CaseSensitivity cs) 
> const
>\fn bool QStringView::startsWith(QLatin1String l1, Qt::CaseSensitivity cs)
> const
>\fn bool QStringView::startsWith(QChar ch) const
>\fn bool QStringView::startsWith(QChar ch, Qt::CaseSensitivity cs) const
> 
>Returns \c true if this string-view starts with string-view \a str,
>Latin-1 string \a l1, or character \a ch, respectively;
>otherwise returns \c false.
> 
>If \a cs is Qt::CaseSensitive (the default), the search is case-sensitive;
>otherwise the search is case-insensitive.
> 
>\sa endsWith(), qStartsWith()
>  */
> 
> instead of
> 
>  /*!
>\fn bool QStringView::startsWith(QStringView str, Qt::CaseSensitivity cs) 
> const
> 
>Returns \c true if this string-view starts with string-view \a str;
>otherwise returns \c false.
> 
>If \a cs is Qt::CaseSensitive (the default), the search is case-sensitive;
>otherwise the search is case-insensitive.
> 
>\sa endsWith(), qStartsWith()
>  */
> 
>  /*!
>\fn bool QStringView::startsWith(QLatin1String l1, Qt::CaseSensitivity cs)
> const
> 
>Returns \c true if this string-view starts with Latin-1 string \a l1;
>otherwise returns \c false.
> 
>If \a cs is Qt::CaseSensitive (the default), the search is case-sensitive;
>otherwise the search is case-insensitive.
> 
>\sa endsWith(), qStartsWith()
>  */
> 
>  /*!
>\fn bool QStringView::startsWith(QChar ch) const
> 
>Returns \c true if this string-view starts with character \a ch;
>otherwise returns \c false.
> 
>The search is case-sensitive.
> 
>\sa endsWith(), qStartsWith()
>  */
> 
>  /*!
>\fn bool QStringView::startsWith(QChar ch, Qt::CaseSensitivity cs) const
> 
>Returns \c true if this string-view starts with character \a ch;
>otherwise returns \c false.
> 
>If \a cs is Qt::CaseSensitive, the search is case-sensitive;
>otherwise the search is case-insensitive.
> 
>\sa endsWith(), qStartsWith()
>  */
> 
> And that's just startsWith(). QString::contains() current has 8,
> QString::arg() has 14, not counting the 8 additional multi-arg() overloads.
> 
> Each of them contains mostly the same text. It's a long time since I had to
> consult QString documentation, but I guess for users, this is as hard to read
> as it is for us to write. Sure. cut-n-paste gives you fast initial results.
> But fear the day when you have to make a change to all of the contains()
> documentation blocks, and be it just for adding a missing hyphen.
> 
> So, I hear you say, if qdoc already supports multiple \fn in one comment
> block, why don't you just use it.
> 
> This is where http://bugreports.qt.io/browse/QTBUG-60420 comes in.
> 
> Currently, any content in a multi-\fn block pertains to all functions
> designated by an included \fn, with no way to change. The initial example,
> e.g., copies the text, which is clearly written to refer to the overload set,
> not any particular funciton, verbatim for each of the four functions. As a
> consequence of this, it also throws warnings about invalid \a references.
> 
> So, name the parameters the same in every overload...
> 
> That works as long as all overloads were added in the same Qt release,
> because, as I said, all content, and thus \since, pertains to all \fn's. IOW:
> you cannot represent the fact that one overload was added in a later Qt
> version.
> 
> What I would like to see is something more akin to the presentation in
> cppreference.com. Before you shout: no, I don't like the numbered listing of
> all overloads followed dumbly by a numbered listing of documentation for each
> overload. What I like is the numbered listing of the overloads, followed by
> free-form text, as in the initial example. It's up to the individual
> documentation writer and his reviewers to avoid falling into a
> cppreference.com-style of itemised text. I think that the initial example is
> an elegant way of how to document that particular set of overloads without
> having to refer to any of them in particular.
> 
> I would like to see a multi-\fn comment block (and only those) transformed
> into a multi-function block in the documentation, too, first listing all the
> functions designated by the \fn's, with \since, \obsolete, ... attached to a
> function (like in cppreference.com, following the signature, in parentheses),
> not the whole block, followed by the free-form block.
> 
> Naturally, 

Re: [Development] QHash iteration vs std::unordered_map

[Samuel Gaist]

> On 16 Apr 2017, at 17:53, Thiago Macieira  wrote:
> 
> Em domingo, 16 de abril de 2017, às 08:05:21 PDT, Mark Gaiser escreveu:
>> That again makes me wonder, why did Qt diverge from that?
> 
> We didn't diverge. We never had that. The Qt style predates the Standard
> Library having relevance in Qt. When the first QHash-like class was added, it
> was just like that.
> 
> Also remember that at the time, you wouldn't think of a Standard Library
> associative container as such. It was just a sequential container that held a
> std::pair, with some convenience functions for searching the first of the 
> pair.
> Returning a pair was a consequence of that. I don't know if it was intentional
> thinking, or it just happened.
> 
>> And... if Qt plans to change it in Qt6?
> 
> No, cannot due to source compatibility. Ever.
> 
> --
> 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
> 

Hi,

Just in case, there’s a work in progress at

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

to add these "missing" iterators to QHash and QMap.

Cheers,
Samuel


signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] P0 Mac help needed due to Daylight savings

[Samuel Gaist]

> On 26 Mar 2017, at 20:11, Thiago Macieira  wrote:
> 
> This test began failing today:
> 
> FAIL!  : tst_QLocale::macDefaultLocale()
> 'timeString.contains(expectedGMTSpecifier) ||
> timeString.contains(expectedGMTSpecifierZeroExtended)' returned FALSE.
> (timeString `1:02:03 AM GMT+02:00', expectedGMTSpecifier `GMT+3' or `GMT+03')
> 
> The expectation is correct, since Finland is now in Summer time at GMT+3.
> Someone on a Mac, please check why it's getting GMT+02.
> 
> --
> 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

Hi,

Likely a “time propagation” problem. Switzerland changed also in the night of 
Saturday to Sunday. I have checked that the test failed while I was starting to 
look into the macOS specific code, midnight passed and then test started to 
succeed again.

I did a quick and rough check using NSCalendar in place of CFGregorianDate and 
the result was the same, the update to the timezone was only done once march 27 
started. Before that, GMT+1 was returned.

Samuel


signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Bug in qtimageformats WBMP plugin

[Samuel Gaist]

> On 15 Mar 2017, at 10:04, Michał 'Khorne' Lowas-Rzechonek 
>  wrote:
> 
> Hi,
> 
> I know that WBMP is not a popular format since WAP is long dead, but in our 
> application it's useful for transferring small bitmaps over a serial bus.
> 
> I've noticed there is a bug in the implementation when the bitmap dimensions 
> are multiples of 128. In such cases, variable-length integer should be 
> encoded as 2 bytes, not 1.
> 
> I've never contributed to Qt so I don't know where am I supposed to send the 
> patch... It's actually very simple:
> 
> 
> diff --git a/src/plugins/imageformats/wbmp/qwbmphandler.cpp 
> b/src/plugins/imageformats/wbmp/qwbmphandler.cpp
> index cd9b04a..d2dec87 100644
> --- a/src/plugins/imageformats/wbmp/qwbmphandler.cpp
> +++ b/src/plugins/imageformats/wbmp/qwbmphandler.cpp
> @@ -81,6 +81,7 @@ static bool readMultiByteInt(QIODevice *iodev, quint32 *num)
> 
> static bool writeMultiByteInt(QIODevice *iodev, quint32 num)
> {
> +quint8 width = 1;
> quint64 tmp = num & 0x7F;
> num >>= 7;
> 
> @@ -88,13 +89,15 @@ static bool writeMultiByteInt(QIODevice *iodev, quint32 
> num)
> quint8 c = num & 0x7F;
> num = num >> 7;
> tmp = (tmp << 8) | (c | 0x80);
> +width += 1;
> }
> 
> -while (tmp) {
> +while (width) {
> quint8 c = tmp & 0xFF;
> if (!iodev->putChar(c))
> return false;
> tmp >>= 8;
> +width -= 1;
> }
> return true;
> }
> 
> cheers
> --
> Michał 'Khorne' Lowas-Rzechonek
> Social Bicycles Inc.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 

Hi and thanks for contributing !

You can find the documentation here:

https://wiki.qt.io/Gerrit_Introduction

on how to get up and running with code contributions.

Cheers

Samuel



signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] standalone building of sql plugins

[Samuel Gaist]

> On 7 Feb 2017, at 17:25, René J.V. Bertin  wrote:
> 
> Hello,
> 
> MacPorts has always shipped the Qt sql plugins as separate packages, so the 
> main (QtBase) component could be built without unnecessary libraries 
> installed. That is, qtbase is configured with -no-sql-$driver
> 
> This was implemented quite simply: to build say the PostGresql plugin we'd 
> unpack the qtbase component (except for the mkspecs directory), and invoke 
> the installed qmake in /path/to/source/qtbase/src/plugins/sqldrivers/psql . 
> Run make and make install, and the libqsqlpsql.dylib binary would be 
> installed in the appropriate location.
> 
> This approach is broken in Qt 5.8.0; is it still possible to build these 
> plugins separately? Would this work by calling qmake in qtbase/src/sql for 
> instance, with the appropriate arguments?
> 
> Thanks!
> 
> R.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

Hi,

https://bugreports.qt.io/browse/QTBUG-58372

might be of help.

Regards,

Samuel


signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New library in qtbase

[Samuel Gaist]

> On 15 Jan 2017, at 15:04, Robin Burchell <robin.burch...@crimson.no> wrote:
> 
> On Fri, Jan 13, 2017, at 11:58 PM, Samuel Gaist wrote:
>> Short summary, we have three possibilities:
>> 1) Own module (and current implementation)
>> 2) One “core" module and one GUI module to separate concerns for system
>> not requiring a GUI connection (Jake’s suggestion)
>> 3) Put everything in QtGui and implement the stuff in the QPA parts with
>> the implication that a QGuiApplication will be required.
>> 
>> Can we come to an agreement about which one to implement ?
> 
> My own vote would be tending towards 3 once the concept is nailed down.
> The existing change looks a little confused from a quick skim, e.g. you
> have a QCocoaNotifier which seems to be public API, but this is not the
> way I would expect to see this (at least, not in QtGui); I'd expect to
> see a "notification" class without any platform specifics, as far as
> possible, which then hooked into platform-specific code to "do its
> magic".
> 
> As the "magic" would tend to be platform-specific, QPA seems to be the
> logical place to me; this then also allows a platform implementer to
> provide their own custom notification handling, should it be required –
> thinking more on the embedded or new platform front here, which is
> typically where QPA comes in anyway, where you may not necessarily have
> existing services or standards to follow.
> 
> I can agree that it's "sad" to have to switch a QCoreApplication to a
> QGuiApplication once you need something in it, even if you don't have a
> GUI to present (though really, is this a common problem?), but aside
> from puritanical concerns, does that actually cause many concrete
> issues?
> 
> So, considering that, and as it's a problem that already exists for
> non-graphical applications to have to interact with images/clipboard,
> for syntax highlighting and other text manipulation, etc, I don't think
> that adding another case to that problem is a death sentence. I think
> it's an extension of a minor inconvenience, but I don't think that
> arbitrary splitting of a feature or class is a good way to address that.
> It leads to a harder to use & understand API for little gain as I
> imagine it, though it is hard to say without a concrete suggestion on
> API to review.
> 
> In the much longer term, on a separate tangent from your work, it might
> be interesting to think about rearranging things to properly address
> this problem if the gain is worth it, but even then, that starts to get
> tricky & requires a lot of care and research, especially when you
> realize that not everything you may want can be done without a windowing
> system: clipboard access, for instance, I'd say is almost certainly
> impossible to do without a windowing system on all platforms
> 
> The same may apply to presenting notifications. Do you know the specific
> requirements of the APIs for, say, Windows/macOS/iOS/Android? If any of
> those (or future platforms) required the WS, then you'd essentially be
> left with a useless API on anything that did not have a QGuiApplication.
> 
> I'd say that ultimately, requiring a QGuiApplication instance is a
> lesser evil than providing an API that won't work universally.
> 
> --
>  Robin Burchell
>  ro...@crimson.no
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 

Hi Robin,

Thanks for your thorough analysis.

The implemented plugin classes are not meant to be public API at all. They 
follow the naming scheme from QPA since the original implementation was done 
through it but in a less re-usable manner. This is definitely an area that will 
be cleaned up.

Thinking about your comments and the suggestion from Jake, I was wondering if 
cutting things a bit in the middle would be an interesting solution: what about 
having the integration in QPA and the implementation in a separated module ? 
This would allow to avoid making the GUI module bigger with code that is not 
directly GUI related (as in actively drawing) while keeping the platform 
specific stuff together.

Cheers
Samuel



signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New library in qtbase

[Samuel Gaist]

> On 6 Dec 2016, at 15:44, Shawn Rutledge  wrote:
> 
> 
>> On 3 Dec 2016, at 00:36, Kevin Kofler  wrote:
>> 
>> Shawn Rutledge wrote:
>>> http://www.galago-project.org/about.php
>>> 
>>> sounds like it’s just for “presence” to tell instant-messaging clients
>>> whether you are using the computer or not.
>> 
>> I did not suggest you use the Galago software, just this specification:
>> https://people.gnome.org/~mccann/docs/notification-spec/notification-spec-latest.html
>> older versions of which were hosted on:
>> http://www.galago-project.org/specs/notification/
>> (which is how it came to be known as the "Galago (notification) spec”).
> 
> That page doesn’t mention Galago.  Anyway org.freedesktop.Notifications is 
> the specification we are already using in qtbase/src/platformsupport/dbustray.
> 
> But we know that increasingly notifications are being used independently from 
> tray icons, and that basically every platform has some kind of notifications, 
> so maybe we’ll end up with another Qt API for that eventually.  It’s 
> unintuitive that if you only want to show notifications but don’t need a tray 
> icon, you have to use QSystemTrayIcon::showMessage().
> 
>> If you want to use an existing library, libnotify is what you are looking
>> for:
>> https://developer.gnome.org/libnotify/
> 
> Well why should Qt depend on another library which does the D-Bus 
> communication in its own way, when we already have Qt D-Bus?
> 
>> All these are GNOME URLs, but the protocol is also supported by KDE Plasma
>> and by other desktop environments:
>> https://wiki.archlinux.org/index.php/Desktop_notifications
> 
> Yeah, that was the idea of implementing it that way, to get it working on 
> Gnome and Ubuntu and KDE.
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 

Hi guys,

Thanks for the suggestions provided.

However this is now derailing the thread’s original purpose: decide where the 
notification related stuff should go.

Short summary, we have three possibilities:
1) Own module (and current implementation)
2) One “core" module and one GUI module to separate concerns for system not 
requiring a GUI connection (Jake’s suggestion)
3) Put everything in QtGui and implement the stuff in the QPA parts with the 
implication that a QGuiApplication will be required.

Can we come to an agreement about which one to implement ?

Note that creating a completely separated module (meaning out of qtbase) is not 
an option since one of the goal beside providing our fellow developers an easy 
to use API is to replace the current QSystemTrayIcon code with the use of that 
module and it wouldn’t make sense to have qtbase depending on an external 
module.

Just to be clear, we are talking here about local notifications not push 
notifications. That’s another subject with other requirements.

Thanks,
Samuel


signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Jira action buttons

[Samuel Gaist]

Hi,On 9 Jan 2017, at 09:21, Alexander Blasche  wrote:Hi,-Original Message-From: Development [mailto:development-bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Samuel GaistSent: Sunday, 8 January 2017 23:44Is there any rule/filter that are applied on the bug reports related to the actionsmade available ?For example:https://bugreports.qt.io/browse/QTBUG-57991: I have  Edit, Comment, Assign,Morehttps://bugreports.qt.io/browse/QTBUG-57996 : Same as above plus Notenough info, Accept, CloseI wanted to close https://bugreports.qt.io/browse/QTBUG-57993 as a duplicateof https://bugreports.qt.io/browse/QTBUG-57992 but I can’t do it currentlybecause for both of them I only get the reduced set of buttons.This is a bug. Nobody had any state transition options for this task. Jira ran out of disk space last week. Maybe this has caused the problem. In any case, I have recovered the work flow state and marked QTBUG-57993 as duplicate of QTBUG-57992.--Alex___Development mailing listDevelopment@qt-project.orghttp://lists.qt-project.org/mailman/listinfo/developmentIt might not be fully solved yet.https://bugreports.qt.io/browse/QTBUG-57991 still shows me a reduced set of action.In any case, thanks for checking !Samuel___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Jira action buttons

[Samuel Gaist]

Hi,

Is there any rule/filter that are applied on the bug reports related to the 
actions made available ?

For example:

https://bugreports.qt.io/browse/QTBUG-57991: I have  Edit, Comment, Assign, More

https://bugreports.qt.io/browse/QTBUG-57996 : Same as above plus Not enough 
info, Accept, Close

I wanted to close https://bugreports.qt.io/browse/QTBUG-57993 as a duplicate of 
https://bugreports.qt.io/browse/QTBUG-57992 but I can’t do it currently because 
for both of them I only get the reduced set of buttons.


Thanks
Samuel


signature.asc
Description: Message signed with OpenPGP
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New library in qtbase

[Samuel Gaist]

> On 29 Nov 2016, at 09:31, Thiago Macieira <thiago.macie...@intel.com> wrote:
> 
> On terça-feira, 29 de novembro de 2016 09:07:47 PST Samuel Gaist wrote:
>>> On 27 Nov 2016, at 20:44, Thiago Macieira <thiago.macie...@intel.com>
>>> wrote:> 
>>> On domingo, 27 de novembro de 2016 20:22:25 PST Samuel Gaist wrote:
>>>> Currently there’s macOS and iOS already working.
>>>> 
>>>> The plan is to add
>>>> - Android
>>>> - Linux through DBus
>>>> - Win10 (there will be some constraints if I understood their
>>>> documentation
>>>> correctly)
>>> 
>>> How about the older X11 / XEmbed way?
>> 
>> I was writing the list from memory and I forgot that one.
>> 
>> I haven’t took a deep look yet at it but I don’t see any reason to not have
>> it.
> 
> So it really looks like this should be part of QtGui with implementation in 
> each QPA plugin.
> 
> -- 
> 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
> 

In the case of Linux, if I understood the situation correctly, there might be 
several backends possible which is unlikely on other platforms expect for Growl 
but it’s not “native” and doesn’t look actively maintained currently although 
it’s still working AFAIK.

Thus what would be the recommended architecture ? 

The first 2 rounds of implementation were run time based while the last, 
following the comments on gerrit, is build time based.


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

Re: [Development] New library in qtbase

[Samuel Gaist]

> On 29 Nov 2016, at 13:39, Shawn Rutledge <shawn.rutle...@qt.io> wrote:
> 
>> 
>> On 29 Nov 2016, at 09:07, Samuel Gaist <samuel.ga...@edeltech.ch> wrote:
>> 
>>> On 27 Nov 2016, at 20:44, Thiago Macieira <thiago.macie...@intel.com> wrote:
>>> 
>>> On domingo, 27 de novembro de 2016 20:22:25 PST Samuel Gaist wrote:
>>>> Currently there’s macOS and iOS already working.
>>>> 
>>>> The plan is to add
>>>> - Android
>>>> - Linux through DBus
>>>> - Win10 (there will be some constraints if I understood their documentation
>>>> correctly)
>>> 
>>> How about the older X11 / XEmbed way?
>> 
>> I was writing the list from memory and I forgot that one.
>> 
>> I haven’t took a deep look yet at it but I don’t see any reason to not have 
>> it.
> 
> A system tray icon can emit notifications, but you aren’t putting the whole 
> tray icon implementation into this library, are you?
> 
> XEmbed is a way of rendering tray icons, whereas we don’t need it for 
> notifications themselves, right? because they are shown as separate windows.  
> In some cases we render them; in others, the rendering is done in another 
> desktop-wide process.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


No, I’m not. 

The idea is to implement the notification part which would be then used by 
QSystemTrayIcon.


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

Re: [Development] CI error: "creation of work items failed"

[Samuel Gaist]

> On 29 Nov 2016, at 11:35, Simon Hausmann <simon.hausm...@qt.io> wrote:
> 
> Hi,
> 
> The bug was a file descriptor memory leak in coin, which was caused by a new 
> upstream version of the python sh module. We
> didn't pin the version, so we "accidentally" got a new version that had the 
> leak. I've reverted to a non-leaking sh version and
> am working on a test-case for an upstream bug report.
> 
> 
> Simon

Thanks !

Samuel

> From: Development <development-bounces+simon.hausmann=qt...@qt-project.org> 
> on behalf of Dominik Holland <dominik.holl...@pelagicore.com>
> Sent: Tuesday, November 29, 2016 10:50:20 AM
> To: development@qt-project.org
> Subject: Re: [Development] CI error: "creation of work items failed"
>  
> Am 11/29/2016 um 09:54 AM schrieb Samuel Gaist:
> > 
> >> On 29 Nov 2016, at 09:53, Marc Mutz <marc.m...@kdab.com> wrote:
> >>
> >> Hi,
> >>
> >> I'm seeing
> >>
> >> Continuous Integration: Cancelled
> >>
> >> Creation of work items failed: The module (qt/qtbase) sha1 needs to be 
> >> known 
> >> if it is not part of product (qt/qt5)
> >>
> >> Details: 
> >> http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480407444
> >>
> >> errors on the CI for 5.8 recently (since yesterday?).
> >>
> >> Would appreciate if someone looked into it.
> >>
> >> Thanks,
> >> Marc
> >>
> >> -- 
> >> Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer
> >> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> >> Tel: +49-30-521325470
> >> KDAB - The Qt, C++ and OpenGL Experts
> >>
> >> From: "Qt CI Bot (Code Review)" <gerrit-nore...@qt-project.org>
> >> Subject: Change in qt/qtbase[5.8]: QListViewItem: add constexpr
> >> Date: 29 November 2016 at 09:17:31 GMT+1
> >> To: Marc Mutz <marc.m...@kdab.com>
> >> Cc: Friedemann Kleint <friedemann.kle...@qt.io>, Qt Sanity Bot 
> >> <qt_sanity...@qt-project.org>, "Olivier Goffart (Woboq GmbH)" 
> >> <ogoff...@woboq.com>, Thiago Macieira <thiago.macie...@intel.com>, Sérgio 
> >> Martins <sergio.mart...@kdab.com>, Giuseppe D'Angelo 
> >> <giuseppe.dang...@kdab.com>
> >> Reply-To: qt_ci_...@qt-project.org
> >>
> >>
> >> Qt CI Bot has posted comments on this change.
> >>
> >> Change subject: QListViewItem: add constexpr
> >> ..
> >>
> >>
> >> Continuous Integration: Cancelled
> >>
> >> Creation of work items failed: The module (qt/qtbase) sha1 needs to be 
> >> known if it is not part of product (qt/qt5)
> >>
> >> Details: 
> >> http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480407444
> >>
> >> Tested changes (refs/builds/qtci/5.8/1480407442):
> >>   
> >> https://codereview.qt-project.org/#/q/baf6e39ab16de581e4f836226af0156694e43a88,n,z
> >>  QListViewItem: add constexpr
> >>
> >> -- 
> >> To view, visit https://codereview.qt-project.org/173313
> >> To unsubscribe, visit https://codereview.qt-project.org/settings
> >>
> >> Gerrit-MessageType: comment
> >> Gerrit-Change-Id: Ibae16792d822ff183a0c542380501978f2108d93
> >> Gerrit-PatchSet: 2
> >> Gerrit-Project: qt/qtbase
> >> Gerrit-Branch: 5.8
> >> Gerrit-Owner: Marc Mutz <marc.m...@kdab.com>
> >> Gerrit-Reviewer: Friedemann Kleint <friedemann.kle...@qt.io>
> >> Gerrit-Reviewer: Giuseppe D'Angelo <giuseppe.dang...@kdab.com>
> >> Gerrit-Reviewer: Marc Mutz <marc.m...@kdab.com>
> >> Gerrit-Reviewer: Olivier Goffart (Woboq GmbH) <ogoff...@woboq.com>
> >> Gerrit-Reviewer: Qt Sanity Bot <qt_sanity...@qt-project.org>
> >> Gerrit-Reviewer: Sérgio Martins <sergio.mart...@kdab.com>
> >> Gerrit-Reviewer: Thiago Macieira <thiago.macie...@intel.com>
> >> Gerrit-HasComments: No
> >>
> >>
> >> ___
> >> Development mailing list
> >> Development@qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/development
> > 
> > Hi,
> > 
> > I just noticed that the same happened to dev
> > 
> > Regards
> > 
> > Samuel
> > 
> > 
> > Qt CI Bot has posted comments on this

Re: [Development] CI error: "creation of work items failed"

[Samuel Gaist]

> On 29 Nov 2016, at 09:53, Marc Mutz <marc.m...@kdab.com> wrote:
> 
> Hi,
> 
> I'm seeing
> 
> Continuous Integration: Cancelled
> 
> Creation of work items failed: The module (qt/qtbase) sha1 needs to be known 
> if it is not part of product (qt/qt5)
> 
> Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480407444
> 
> errors on the CI for 5.8 recently (since yesterday?).
> 
> Would appreciate if someone looked into it.
> 
> Thanks,
> Marc
> 
> -- 
> Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt, C++ and OpenGL Experts
> 
> From: "Qt CI Bot (Code Review)" <gerrit-nore...@qt-project.org>
> Subject: Change in qt/qtbase[5.8]: QListViewItem: add constexpr
> Date: 29 November 2016 at 09:17:31 GMT+1
> To: Marc Mutz <marc.m...@kdab.com>
> Cc: Friedemann Kleint <friedemann.kle...@qt.io>, Qt Sanity Bot 
> <qt_sanity...@qt-project.org>, "Olivier Goffart (Woboq GmbH)" 
> <ogoff...@woboq.com>, Thiago Macieira <thiago.macie...@intel.com>, Sérgio 
> Martins <sergio.mart...@kdab.com>, Giuseppe D'Angelo 
> <giuseppe.dang...@kdab.com>
> Reply-To: qt_ci_...@qt-project.org
> 
> 
> Qt CI Bot has posted comments on this change.
> 
> Change subject: QListViewItem: add constexpr
> ..
> 
> 
> Continuous Integration: Cancelled
> 
> Creation of work items failed: The module (qt/qtbase) sha1 needs to be known 
> if it is not part of product (qt/qt5)
> 
> Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480407444
> 
> Tested changes (refs/builds/qtci/5.8/1480407442):
>   
> https://codereview.qt-project.org/#/q/baf6e39ab16de581e4f836226af0156694e43a88,n,z
>  QListViewItem: add constexpr
> 
> -- 
> To view, visit https://codereview.qt-project.org/173313
> To unsubscribe, visit https://codereview.qt-project.org/settings
> 
> Gerrit-MessageType: comment
> Gerrit-Change-Id: Ibae16792d822ff183a0c542380501978f2108d93
> Gerrit-PatchSet: 2
> Gerrit-Project: qt/qtbase
> Gerrit-Branch: 5.8
> Gerrit-Owner: Marc Mutz <marc.m...@kdab.com>
> Gerrit-Reviewer: Friedemann Kleint <friedemann.kle...@qt.io>
> Gerrit-Reviewer: Giuseppe D'Angelo <giuseppe.dang...@kdab.com>
> Gerrit-Reviewer: Marc Mutz <marc.m...@kdab.com>
> Gerrit-Reviewer: Olivier Goffart (Woboq GmbH) <ogoff...@woboq.com>
> Gerrit-Reviewer: Qt Sanity Bot <qt_sanity...@qt-project.org>
> Gerrit-Reviewer: Sérgio Martins <sergio.mart...@kdab.com>
> Gerrit-Reviewer: Thiago Macieira <thiago.macie...@intel.com>
> Gerrit-HasComments: No
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

Hi,

I just noticed that the same happened to dev

Regards

Samuel


Qt CI Bot has posted comments on this change.

Change subject: Add configurable connect timeout for QAbstractSocket
..


Continuous Integration: Cancelled

Creation of work items failed: The module (qt/qtbase) sha1 needs to be known if 
it is not part of product (qt/qt5)

Details: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1480349268

Tested changes (refs/builds/qtci/dev/1480349266):
  
https://codereview.qt-project.org/#/q/f580628a219f5b588e3f9c221f2f016213bfa085,n,z
 Add configurable connect timeout for QAbstractSocket

-- 
To view, visit https://codereview.qt-project.org/141210
To unsubscribe, visit https://codereview.qt-project.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I1dc4051be2c74f925f7a9e0a9ccef332efc2e370
Gerrit-PatchSet: 8
Gerrit-Project: qt/qtbase
Gerrit-Branch: dev
Gerrit-Owner: Samuel Gaist <samuel.ga...@edeltech.ch>
Gerrit-Reviewer: Alex Blasche <alexander.blas...@qt.io>
Gerrit-Reviewer: Giuseppe D'Angelo <giuseppe.dang...@kdab.com>
Gerrit-Reviewer: Lorn Potter <lorn.pot...@canonical.com>
Gerrit-Reviewer: Markus Goetz (Woboq GmbH) <mar...@woboq.com>
Gerrit-Reviewer: Qt Sanity Bot <qt_sanity...@qt-project.org>
Gerrit-Reviewer: Richard J. Moore <r...@kde.org>
Gerrit-Reviewer: Samuel Gaist <samuel.ga...@edeltech.ch>
Gerrit-Reviewer: Thiago Macieira <thiago.macie...@intel.com>
Gerrit-HasComments: No

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

Re: [Development] New library in qtbase

[Samuel Gaist]

> On 28 Nov 2016, at 01:05, Aleix Pol <aleix...@kde.org> wrote:
> 
> On Sat, Nov 26, 2016 at 12:51 AM, Samuel Gaist <samuel.ga...@edeltech.ch> 
> wrote:
>> Hi,
>> 
>> As requested by Thiago in https://codereview.qt-project.org/#/c/166456/ I’d 
>> like to open a discussion about adding a new library in qtbase.
>> 
>> Why this discussion ?
>> 
>> Currently in work a pluggable notification system developed in its own 
>> library in qtbase.
>> 
>> Why add a new library ?
>> 
>> Originally the submission was integrated in QPA however after some thoughts 
>> and discussion, it was reworked to avoid that so that developers of non-GUI 
>> application could also take advantage of notifications without the need of a 
>> QGuiApplication.
>> 
>> One of my motivation to move the code in its own library was that the second 
>> implementation provided a run-time plugin selection mechanism much like the 
>> QtSql module. After further discussion, the plugin selection has been moved 
>> to build-time.
>> 
>> The library as it is currently could even be in its own repository however 
>> the goal in the long run is to replace the code used in QSystemTrayIcon by 
>> calls to this module which at this time duplicates the showMessage logic for 
>> macOS. Therefore having it as a separated repo would mean that qtbase would 
>> depend on it to be build which IMHO is not an option.
>> 
>> So basically we are at this point:
>> 
>> 1) Keep the new notifications module
>> 2) Move the code in the gui module since QImage might be used
>> 
>> In any case, the outcome of this discussion should likely be written in a 
>> QUIP so we have a clear set of rules about adding new libraries in existing 
>> Qt modules.
>> 
>> Thank you for your attention
> 
> This is very interesting! We've missed this in several occasions and
> at the moment it's a bit of a stopper for some KDE applications to
> flourish on some platforms (thinking of KDE Connect at the moment but
> I'm sure that others too).
> 
> IMHO the inflection point it's whether it's going to require
> QCoreApplication or QGuiApplication. Without having sat down into
> details, not only QImage but QIcon should also be part of the API. I'd
> say that QtGui will end up being required.
> 
> Aleix

That’s one of the “trick" I used, I didn’t put the QIcon interface on purpose. 
Without it you don’t need a QGuiApplication.

One possibility might be to do like Jake suggested and have one non-gui and one 
gui library provide by the module.

If we go with Allan's suggestion, putting it in QPA (which corresponds a bit 
like my first implementation), then there would be no way around a 
QGuiApplication.

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

Re: [Development] New library in qtbase

[Samuel Gaist]

> On 27 Nov 2016, at 20:44, Thiago Macieira <thiago.macie...@intel.com> wrote:
> 
> On domingo, 27 de novembro de 2016 20:22:25 PST Samuel Gaist wrote:
>> Currently there’s macOS and iOS already working.
>> 
>> The plan is to add
>> - Android
>> - Linux through DBus
>> - Win10 (there will be some constraints if I understood their documentation
>> correctly)
> 
> How about the older X11 / XEmbed way?
> 
> -- 
> 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
> 


I was writing the list from memory and I forgot that one.

I haven’t took a deep look yet at it but I don’t see any reason to not have it.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New library in qtbase

[Samuel Gaist]

> On 26 Nov 2016, at 07:50, Thiago Macieira <thiago.macie...@intel.com> wrote:
> 
> On sábado, 26 de novembro de 2016 00:51:06 PST Samuel Gaist wrote:
>> The library as it is currently could even be in its own repository however
>> the goal in the long run is to replace the code used in QSystemTrayIcon by
>> calls to this module which at this time duplicates the showMessage logic
>> for macOS. Therefore having it as a separated repo would mean that qtbase
>> would depend on it to be build which IMHO is not an option.
> 
> What platforms are you targetting, besides macOS? Which ones have you already 
> developed?
> 
> -- 
> 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
> 

Currently there’s macOS and iOS already working.

The plan is to add
- Android
- Linux through DBus
- Win10 (there will be some constraints if I understood their documentation 
correctly)

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

[Development] New library in qtbase

[Samuel Gaist]

Hi,

As requested by Thiago in https://codereview.qt-project.org/#/c/166456/ I’d 
like to open a discussion about adding a new library in qtbase.

Why this discussion ?

Currently in work a pluggable notification system developed in its own library 
in qtbase.

Why add a new library ?

Originally the submission was integrated in QPA however after some thoughts and 
discussion, it was reworked to avoid that so that developers of non-GUI 
application could also take advantage of notifications without the need of a 
QGuiApplication.

One of my motivation to move the code in its own library was that the second 
implementation provided a run-time plugin selection mechanism much like the 
QtSql module. After further discussion, the plugin selection has been moved to 
build-time.

The library as it is currently could even be in its own repository however the 
goal in the long run is to replace the code used in QSystemTrayIcon by calls to 
this module which at this time duplicates the showMessage logic for macOS. 
Therefore having it as a separated repo would mean that qtbase would depend on 
it to be build which IMHO is not an option.

So basically we are at this point:

1) Keep the new notifications module
2) Move the code in the gui module since QImage might be used

In any case, the outcome of this discussion should likely be written in a QUIP 
so we have a clear set of rules about adding new libraries in existing Qt 
modules.

Thank you for your attention

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

Re: [Development] Multiple Qt branches on Coverity Scan

[Samuel Gaist]

> On 3 oct. 2016, at 23:09, Thiago Macieira  wrote:
> 
> On segunda-feira, 3 de outubro de 2016 22:42:23 CEST Giuseppe D'Angelo wrote:
>> I'd say we should at least get 5.6 and dev covered (we can then bikeshed
>> on the naming -- "stable" and "dev"?). What do you think?
> 
> Please do. That's a good idea, even if we don't have a lot of people looking
> at those results, any help is good.
> 
> I think the names should be "5.6" or "lts", the other one stays named as it
> is.
> 
> --
> 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

Hi,

I’d go for LTS, this way it’s clearer why it’s covered and doesn’t need to be 
changed in the future.

Samuel


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New configuration system

[Samuel Gaist]

On 23 juin 2016, at 09:29, Lars Knoll  wrote:

> Hi,
> 
> As some of you might know, I’ve been working for some time now on developing 
> a new configuration system for Qt. As the first large change went in 
> yesterday evening, I guess it’s time I describe it a little, and also tell 
> you a bit about what’s still coming.
> 
> The goal of the new system is twofold. First of all, we are seeing a large 
> need, especially with our embedded users, to customise how Qt is being built. 
> Many of them have size restrictions ore rather hard testing requirements, 
> where being able to limit the functionality available in Qt is extremely 
> helpful. We had such a system (see src/corelib/global/qfeatures.txt) before, 
> but it was disconnected from the configure script, wasn’t really maintained 
> since Qt 4 times, and had quite many limitations that I hope to solve with 
> the new system.
> 
> Secondly, we have had to deal for a long time with two different 
> configuration systems. We had a monster of a shell script for unix, and an Qt 
> based executable on Windows. Changes to Qt often required changing both, and 
> it was very easy to sneak subtle errors in. Maintainability of the old system 
> was in general very poor.
> 
> So with that comes the new system. As I said, the first (but largest) patch 
> went yesterday evening (see https://codereview.qt-project.org/#/c/149202/). 
> It basically moves most of the configuration handling from the shell script 
> over to a declarative json file (currently configure.json) that is being 
> processed by qmake. This currently only affects Unix, Windows platforms are 
> still being configured through configure.exe. The change aims to be a 1 to 1 
> (or at least as close as possible) mapping of the old shell script to the new 
> system. So if you find that some configuration you’re using is suddenly 
> broken let me know.
> 
> I’ll send out a separate email describing the new system in more detail for 
> those who are interested.
> 
> For everybody else, there are a couple of changes that will still come in 
> over the next couple of weeks:
> 
> * Give every module a qtmoduleglobal.h and qtmoduleglobal_p.h file
> 
> We already have per module global files for many modules (they are often 
> required for the export/import handling of classes/symbols). With the new 
> system we will add a public and private global file per module. I’ll start 
> requiring that all public headers of the module include the public global 
> file first, all private headers the private global file.
> 
> This is needed some steps below to modularise the configuration system and to 
> allow us to track whether a certain feature we rely upon in code is actually 
> available or not.
> 
> See https://codereview.qt-project.org/#/c/161143 and subsequent changes (the 
> change adding global_p.h is still missing here, but will come as well)
> 
> * Saner handling of 3rd party libs
> 
> Currently all our dependencies to external libs are handled in a rather 
> ad-hoc way in the pro files. The goal is to unify this, see 
> https://codereview.qt-project.org/#/c/161660/
> 
> * Modularisation of the new configuration system
> 
> I have some patches pending to modularise the new system. We will basically 
> have one json configuration file per module/shared library. This will also 
> allow us to use the system fully on repositories outside of qtbase, who 
> currently have rather limited support for being configured.
> 
> With this change, we will start creating a qtmodule-config.h and 
> qtmodule-config_p.h file as well as a corresponding public and private .pri 
> files for each module. qtmodule-config.h will get included from the public 
> global header for the module, qtmodule-config_p.h from the private one.
> 
> The public pro file will contain definitions for the features that are being 
> exported by the module, the private one for features that are only relevant 
> in the context of the module itself. As an example, ‘mimetypes’ would be a 
> public feature of QtCore (as it changes the set of available API), whereas 
> ‘glib’ would be most likely a private one (as it only determines which event 
> loop to use and doesn’t change API).
> 
> See change https://codereview.qt-project.org/#/c/159604/40 and the following 
> commit
> 
> * Integration of the old feature system
> 
> As said above, there is the old feature system (see qfeatures.txt in 
> corelib/global). With the work above done, integrating it into the system 
> will be trivial (change https://codereview.qt-project.org/#/c/159763/)
> 
> * With this done, I will also want to introduce a new mechanism to handle 
> features in our cpp and header files. The current double negated #ifndef 
> QT_NO_FOO is hard to read and unsafe. By unsafe, I mean that the compiler 
> won’t error out or warn us if the feature ‘foo’ isn’t available (because of a 
> typo or because the feature is actually defined in widgets and you tried 
> using it in 

Re: [Development] Qt QuickLook plugin

[Samuel Gaist]

On 2 mai 2016, at 09:07, Eike Ziller <eike.zil...@qt.io> wrote:

> 
>> On May 1, 2016, at 01:47, Jake Petroules <jake.petrou...@qt.io> wrote:
>> 
>> That would be pretty awesome. It's possible we could ship it inside of Qt 
>> Creator? You can put them in either ~/Library/QuickLook or in 
>> $BUNDLE_CONTENTS/Library/QuickLook

Sure thing, that's the direction I was looking for if possible :)

Note that currently it is a really bare bone plugin. If it's made part of Qt 
Creator, we could maybe implement highlighting using Qt Creator's code model ?

> 
> That made me start wondering why I do see a text preview for .qml files. We 
> do declare these as OSType text in Qt Creator’s Info.plist.
> So I tried https://codereview.qt-project.org/157721 for .pro, .pri, .qbs and 
> .qrc as well, so far without any effect, but maybe that is because of some 
> fancy OS caching of these values?
> 
> Br, Eike

Sorry, I currently don't know what may be the cause of this.

Samuel

> 
>>> On Apr 30, 2016, at 4:09 PM, Samuel Gaist <samuel.ga...@edeltech.ch> wrote:
>>> 
>>> Hi,
>>> 
>>> I wrote a small QuickLook plugin for OS X that allows to get a preview of 
>>> Qt's .pro, .pri and .qrc files without opening any editor.
>>> 
>>> Would there be any interest in making it part of the standard OS X 
>>> installation ?
>>> 
>>> If so, what would be the process to include it ?
>>> 
>>> Cheers
>>> Samuel
>>> 
>>> 
>>> ___
>>> Development mailing list
>>> Development@qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/development
>> 
>> --
>> Jake Petroules - jake.petrou...@theqtcompany.com
>> Consulting Services Engineer - The Qt Company
>> Qbs build system evangelist - qbs.io
>> 
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt QuickLook plugin

[Samuel Gaist]

Hi,

I wrote a small QuickLook plugin for OS X that allows to get a preview of Qt's 
.pro, .pri and .qrc files without opening any editor.

Would there be any interest in making it part of the standard OS X installation 
?

If so, what would be the process to include it ?

Cheers
Samuel




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Volker Krause for Approver status

[Samuel Gaist]

+1
On 30 mars 2016, at 10:34, Sean Harmer  wrote:

> Hi All,
> 
> I'd like to nominate Volker Krause for approver status. Volker is one of the
> main authors of GammaRay, is very active in the Qt Automotive sphere where he
> leads up KDAB's contributions, and has touched many parts all over Qt
> (including Qt 3D).
> 
> His dashboard is at:
> 
> https://codereview.qt-project.org/#/q/owner:%22Volker+Krause%22,n,z
> 
> and reviews at:
> 
> https://codereview.qt-project.org/#/q/reviewer:%22Volker+Krause%22,n,z
> 
> Can I get a +1 please?
> 
> Cheers,
> 
> Sean
> 
> Disclaimer: I work at KDAB with Volker.
> --
> Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
> KDAB - Qt Experts - Platform-independent software solutions
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Coding Guidelines

[Samuel Gaist]

On 16 mars 2016, at 16:14, Koehne Kai  wrote:

> Hi there,
> 
> We have had quite some discussions about the use of C++11 features and right 
> API in the past on this mailing list - but if there has been a consensus 
> (which is sometimes hard to find out), it was often buried pretty deep in the 
> mailing thread. IMO it would be good to make decisions more explicit, and 
> write them down also somewhere outside of this list.
> 
> We already have the coding conventions page: 
> https://wiki.qt.io/Coding_Conventions . But we haven't done a good job at 
> keeping it up to date - and one reason is IMO that, given that it's a wiki 
> everybody can edit, people in a twist of irony stay away from editing it to 
> avoid editing wars.
> 
> I've been contemplating whether we should instead use some more formalized 
> decision process. We could have a document uploaded in git, and every change 
> needs to be reviewed and approved by Lars. While at it, this fresh start 
> would also be a good opportunity to check whether all the rules in above wiki 
> page, and the structure of the document in general, can be improved.
> 
> As sort of a demo I created
> 
> https://github.com/kkoehne/qt-coding-guidelines/blob/master/qt-coding-guidelines.md
> 
> What do you think? If nobody sees the value in this, I'll refrain from 
> sinking more time into it.
> 
> Regards
> 
> Kai
> 
> --
> Kai Köhne, Senior Manager R - The Qt Company
> 
> The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
> Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
> Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 
> B
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 

Hi,

+1

It could go in the qtqa repository or maybe qtbase so no need for additional 
online resources when coding (always nice when on battery)

Samuel


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.5.1 Download Problem

[Samuel Gaist]

On 15 oct. 2015, at 19:12, Giuseppe D'Angelo  wrote:

> Il 15/10/2015 19:06, Volny ha scritto:
>> ‎Same on Linux.
> 
> It's https://bugreports.qt.io/browse/QTBUG-48781 , no idea about an ETA. You 
> could try redownloading until you get a good mirror :(
> 
> HTH,
> -- 
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer
> KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
> KDAB - The Qt Experts
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

Or use https://github.com/JKSH/QtSdkRepoChooser

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

Re: [Development] QT_NO_DRAGANDDROP qt 5.6 git build fails

[Samuel Gaist]

On 8 sept. 2015, at 14:36, Gunnar Roth <gunnar.r...@gmx.de> wrote:

> Hello Samuel and Giuseppe 
>  
> i am not capable to create a patch in qt gerrrit. i get an http 403 error as 
> written in an previous mail.
> So maybe one of you could do me the favour and create patches in gerrit for 
> me?
> I made some patch diff files gainst qt 5.6 for this issue and attached them 
> to this mail.
>  
> Regards,
> Gunnar Roth

Hi,

https://codereview.qt-project.org/127023
https://codereview.qt-project.org/127024
https://codereview.qt-project.org/127025
https://codereview.qt-project.org/127026

Note that they are only for to the drag and drop part currently as some of your 
modifications are related to other matters.

Regards
Samuel


> Gesendet: Mittwoch, 02. September 2015 um 16:06 Uhr
> Von: "Samuel Gaist" <samuel.ga...@edeltech.ch>
> An: "Giuseppe D'Angelo" <giuseppe.dang...@kdab.com>
> Cc: development@qt-project.org
> Betreff: Re: [Development] QT_NO_DRAGANDDROP qt 5.6 git build fails
> 
> On 2 sept. 2015, at 15:35, Giuseppe D'Angelo <giuseppe.dang...@kdab.com> 
> wrote:
> 
> > Il 02/09/2015 15:02, Gunnar Roth ha scritto:
> >> If you wonder why i need that, its because of wc2013 it has no DnD
> >> support ( as wec7 had).
> >
> > Submit a patch? :)
> >
> > Unfortunately Qt is not tested in all the possible -no-feature switches.
> >
> > Cheers,
> > --
> > Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer
> > KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
> > KDAB - The Qt Experts
> >
> 
> +1 for the patch but the problem is rather that QWidget has the corresponding 
> methods surrounded by #ifndef QT_NO_DRAGANDDROP and not QGraphicsView so it 
> would make more sense to do it also for that class and not only for the 
> content of the implementation.
> 
> Cheers
> Samuel
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> <80_fix_non_dnd_no_clipboard_p0.diff><81_fix_non_dnd_no_clipboard_p1.diff><82_fix_non_dnd_no_clipboard_p2.diff><83_fix_non_dnd_no_clipboard_p3.diff><87_fix_no_dnd_widgets_fix_static.diff>

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

Re: [Development] QT_NO_DRAGANDDROP qt 5.6 git build fails

[Samuel Gaist]

On 2 sept. 2015, at 15:35, Giuseppe D'Angelo  wrote:

> Il 02/09/2015 15:02, Gunnar Roth ha scritto:
>> If you wonder why i need that, its because of wc2013 it has no DnD
>> support ( as wec7 had).
> 
> Submit a patch? :)
> 
> Unfortunately Qt is not tested in all the possible -no-feature switches.
> 
> Cheers,
> -- 
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer
> KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
> KDAB - The Qt Experts
> 

+1 for the patch but the problem is rather that QWidget has the corresponding 
methods surrounded by #ifndef QT_NO_DRAGANDDROP and not QGraphicsView so it 
would make more sense to do it also for that class and not only for the content 
of the implementation.

Cheers
Samuel

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

Re: [Development] [RFC] decommissioning the qtonpi mailing list

[Samuel Gaist]

On 13 août 2015, at 11:47, Oswald Buddenhagen 
oswald.buddenha...@theqtcompany.com wrote:

 moin,
 
 the qtonpi mailing list didn't have a single message in close to a year;
 interest@ and development@ serve the remaining needs much better at this
 point.
 to cut down maintenance effort, i'd like to shut the list down, leaving
 only the archives intact. objections?
 
 if you want to nominate other lists which have outlived their purpose,
 go ahead.

Hi,

+1 

It seems that currently the forum is the place people use for Qt on Pi related 
questions

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

Re: [Development] Qt Speech: text to speech in 5.6

[Samuel Gaist]

On 4 août 2015, at 09:24, Frederik Gladhorn 
frederik.gladh...@theqtcompany.com wrote:

 Hello all,
 
 I would like to propose the tts parts of QtSpeech (the current dev branch) 
 for 
 inclusion in Qt 5.6.0. Along with that I'd like to invite everyone to review 
 QtSpeech, it's not much code and works on most platforms. Notably iOS is 
 still 
 missing, although I have proof of concept patches (if someone wants to finish 
 them let me know, I don't know if I'll get around in time). I have no idea 
 about non-desktop Windows in this area.
 
 Cheers,
 Frederik
 

Hi,

I might have some time to help on the iOS side

Best regards
Samuel

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

Re: [Development] Avoid overloading of 'error'

[Samuel Gaist]

On 10 juin 2015, at 16:20, Koehne Kai kai.koe...@theqtcompany.com wrote:

 Hi,
 
 I'm currently converting a codebase from old-style connects to new-style 
 ones. Thanks to Qt Creator's refactoring support this is actually quite easy 
 ... it gets ugly though when either the signal or slot method name is 
 overloaded, and you have to write nice code like
 
   connect(process, static_castvoid 
 (QProcess::*)(QProcess::ProcessError)(QProcess::Error), this, 
 MyClass::processError);
 
 There can be done little to avoid this in general, but actually the 
 overloading of 'error' stands out: E.g. QProcess, QNetworkReply, 
 QNetworkSession, QAbstractSocket all feature both an error() signal and an 
 error() accessor.
 
 Ideas how to mitigate this:
 
 1. We could deprecate the error() signal, and add a failed() signal (still in 
 Qt 5).
 2. We could rename error() accessor to lastError() in Qt 6.
 3. your idea goes here
 
 Comments?
 
 Regards
 
 Kai
 
 
 Kai Köhne, Senior Software Engineer - The Qt Company GmbH
 
 The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
 Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
 Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 
 B
 
 
 

Hi,

I agree that signal and accessor of the same name should be avoided.

What about errorOccured ? 

failed doesn't always mean there was an error with a direct relation.

Regards

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

Re: [Development] [Interest] Qt XML patterns

[Samuel Gaist]

On 8 mai 2015, at 14:32, Frederik Gladhorn frederik.gladh...@theqtcompany.com 
wrote:

 Hello all,
 
 I’ve just looked a bit at the QtXmlPatterns module. The module has a few 
 issues and is not actively maintained. I wonder if it should see improvements 
 or if there are good alternatives which might be more spec compliant which 
 people end up using. One option in the long term might be to wrap some other 
 library instead of trying to do our own.
 
 I’m interested in usage of it - please let me know if you do use it or if you 
 ended up using alternative libraries. I’m also interested in which parts, 
 since the module supports XPath, XQuery, XSLT and XML Schema validation.
 
 Greetings,
 Frederik
 
 Please not that this question is unrelated to the XML classes in QtBase (sax, 
 stream-reader/writer, dom).
 

Hi,

I've used it for schema validation which worked nicely.

Most of the questions i've seen on the forum were related to XQuery and XPath 
and IIRC XmlListModel was involved most of the time so not directly this module.

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

Re: [Development] Qt 4.8.7 release candidate available

[Samuel Gaist]

Hi,

It's back since 5.2 with an implementation for OS X waiting for Qt 5 (also for 
Qt 4 but since it's considered a new feature it won't get in)

Samuel

On 30 avr. 2015, at 19:37, Hausmann Simon simon.hausm...@theqtcompany.com 
wrote:

 IMO this isn't a Qt bug, I commented on Jira.
 
 I suspect another app isn't implementing the protocol directly, but if we 
 really want to protect ourselves then we should probably ditch the entire 
 session management code from Qt 4 (it's gone in Qt 5, too :)
 
 Simon
 
  Original Message
 From: Matthew Woehlke
 Sent: Thursday, April 30, 2015 16:49
 To: development@qt-project.org
 Cc: releas...@qt-project.org
 Subject: Re: [Development] Qt 4.8.7 release candidate available
 
 
 On 2015-04-30 09:17, Salovaara Akseli wrote:
 If blocker issues for Qt 4.8.7 release (i.e. new regression) are found 
 please report those to bugreports.qt.io and raise issue also (with bug id) 
 on releasing mailing list.
 
 Is there no hope for getting https://bugreports.qt.io/browse/QTBUG-38599
 fixed? This is a really nasty bug that cripples all (newly launched) Qt
 applications when it happens. It's listed as P1 and has been reproduced,
 but I don't know enough about the bowels of QSessionManager to suggest a
 solution.
 
 KDE4 is likely to be around for a while yet (e.g. LTS distros) and it
 would be good if this can be fixed.
 
 --
 Matthew
 
 ___
 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] Update and resubmit on reverted submission

[Samuel Gaist]

On 2 mars 2015, at 04:24, Thiago Macieira thiago.macie...@intel.com wrote:

 On Monday 02 March 2015 00:31:08 Samuel Gaist wrote:
 Hi,
 
 I've had a submission merged but then reverted because of an unforeseen bug.
 I've updated the code, added a new test and wanted to push it again to keep
 the history and discussion going. Logically it failed since it's closed.
 Following qtqa's documentation, it seems that I have no choice but to make
 a new submission thus losing the discussion, am I right ?
 
 Correct. You need to submit a new one, with a new change-id.

Ok, good, thanks for the confirmation

Samuel


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

[Development] Update and resubmit on reverted submission

[Samuel Gaist]

Hi,

I've had a submission merged but then reverted because of an unforeseen bug. 
I've updated the code, added a new test and wanted to push it again to keep the 
history and discussion going. Logically it failed since it's closed. Following 
qtqa's documentation, it seems that I have no choice but to make a new 
submission thus losing the discussion, am I right ?

Samuel


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

Re: [Development] Item View Maintainer

[Samuel Gaist]

On 1 mars 2015, at 10:50, Sune Vuorela nos...@vuorela.dk wrote:

 On 2015-03-01, Samuel Gaist samuel.ga...@edeltech.ch wrote:
 Hi,
 
 Since Stephen Kelly ended his work at KDAB, he also got out of gerrit/jira 
 so it seems that there's no official maintainer for the Item View module, 
 unless he's there with a new account I missed ? 
 
 I spotted him some time ago in gerrit as 'ske'
 
 /Sune
 

Searching for ske did work while when I was searching for Stephen this entry 
didn't show.

Thank you very much !

Samuel

PS: Should I update the maintainer list with the new informations ?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Item View Maintainer

[Samuel Gaist]

Hi,

Since Stephen Kelly ended his work at KDAB, he also got out of gerrit/jira so 
it seems that there's no official maintainer for the Item View module, unless 
he's there with a new account I missed ? 

If not is there anybody planned for the role ?

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

Re: [Development] QUrl setPath Qt4 vs Qt5

[Samuel Gaist]

On 29 sept. 2014, at 09:08, Ziller Eike eike.zil...@digia.com wrote:

 Just for completeness ;)
 
 https://bugreports.qt-project.org/browse/QTBUG-27728
 

Thanks :)

Since it's a documentation update and 5.4 is not officially out, should I 
target 5.3 ?

 
 On Sep 28, 2014, at 9:52 AM, Samuel Gaist samuel.ga...@edeltech.ch wrote:
 
 
 On 28 sept. 2014, at 03:26, Thiago Macieira thiago.macie...@intel.com 
 wrote:
 
 On Sunday 28 September 2014 01:02:11 Samuel Gaist wrote:
 Hi,
 
 Following a post on the forum, I've checked and there's been a behavior
 change in QUrl's setPath between Qt 4 and Qt 5 that is not mentioned in the
 C++ API changes chapter.
 
 If I understood correctly:
 
 QUrl example1(http://www.example.com;);
 example1.setPath(pub/something);
 
 makes example1 invalid in Qt 5 due to the fact that pub/something is a
 relative path (following QUrl documentation and test) but in Qt 4 the
 result is http://www.example.com/pub/something;.
 
 Should it be considered bug in Qt 4 that needs fixing ? However fixing it
 might break existing application that could be relying on that behavior. In
 this case, simply add the API break in Qt 5's documentation ?
 
 Yes, it's a bug in Qt 4, bug I won't fix it because it's not that important 
 and 
 would require a major change.
 
 QUrl in Qt 4 has quite a few known issues with encoding and decoding of 
 delimiters too. And its QString constructor is a completely flawed design 
 and 
 should never be used.
 
 QUrl changed considerably in Qt 5 to comply better with the URL 
 specifications 
 and with brokenness out there. If we add anything to the documentation, it 
 would be the previous sentence, with no extra details.
 
 I remember now following a discussion about that matter some time ago.
 
 Fine for me. I'll update the API change doc to include that so future users 
 won't be surprised.
 
 Samuel
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
 
 -- 
 Eike Ziller, Senior Software Engineer - Digia, Qt
 
 Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
 Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
 Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, 
 HRB 144331 B
 
 

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

Re: [Development] QUrl setPath Qt4 vs Qt5

[Samuel Gaist]

 On 28 sept. 2014, at 03:26, Thiago Macieira thiago.macie...@intel.com wrote:
 
 On Sunday 28 September 2014 01:02:11 Samuel Gaist wrote:
 Hi,
 
 Following a post on the forum, I've checked and there's been a behavior
 change in QUrl's setPath between Qt 4 and Qt 5 that is not mentioned in the
 C++ API changes chapter.
 
 If I understood correctly:
 
 QUrl example1(http://www.example.com;);
 example1.setPath(pub/something);
 
 makes example1 invalid in Qt 5 due to the fact that pub/something is a
 relative path (following QUrl documentation and test) but in Qt 4 the
 result is http://www.example.com/pub/something;.
 
 Should it be considered bug in Qt 4 that needs fixing ? However fixing it
 might break existing application that could be relying on that behavior. In
 this case, simply add the API break in Qt 5's documentation ?
 
 Yes, it's a bug in Qt 4, bug I won't fix it because it's not that important 
 and 
 would require a major change.
 
 QUrl in Qt 4 has quite a few known issues with encoding and decoding of 
 delimiters too. And its QString constructor is a completely flawed design and 
 should never be used.
 
 QUrl changed considerably in Qt 5 to comply better with the URL 
 specifications 
 and with brokenness out there. If we add anything to the documentation, it 
 would be the previous sentence, with no extra details.

I remember now following a discussion about that matter some time ago.

Fine for me. I'll update the API change doc to include that so future users 
won't be surprised.

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

[Development] QUrl setPath Qt4 vs Qt5

[Samuel Gaist]

Hi,

Following a post on the forum, I've checked and there's been a behavior change 
in QUrl's setPath between Qt 4 and Qt 5 that is not mentioned in the C++ API 
changes chapter. 

If I understood correctly:

QUrl example1(http://www.example.com;);
example1.setPath(pub/something);

makes example1 invalid in Qt 5 due to the fact that pub/something is a 
relative path (following QUrl documentation and test) but in Qt 4 the result is 
http://www.example.com/pub/something;.

Should it be considered bug in Qt 4 that needs fixing ? However fixing it might 
break existing application that could be relying on that behavior. In this 
case, simply add the API break in Qt 5's documentation ?

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

Re: [Development] moc 4.8.6 macros

[Samuel Gaist]

On 17 sept. 2014, at 17:20, Olivier Goffart oliv...@woboq.com wrote:

 On Tuesday 16 September 2014 23:52:36 Thiago Macieira wrote:
 On Tuesday 16 September 2014 23:00:06 Samuel Gaist wrote:
 Good question, I'll have to check.
 If that where not the case, what should I write to give additional include
 paths to moc ?
 
 Replace QT_DEPRECATED_SINCE with the actual contents of the macro. Also
 expand QT_VERSION_CHECK.
 
 Qt 4 moc does not expand macros.
 
 Qt 4 moc does expand macros in #if directive.
 
 (and QT_DEPRECATED_SINCE is defined to 1 for Qt4 in qtserialportglobal.h)
 

Indeed it's defined, but it looks like moc doesn't handle the case when the 
macro has one or more parameter(s) even if defined in the same file

Samuel

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

Re: [Development] moc 4.8.6 macros

[Samuel Gaist]

On 12 sept. 2014, at 11:14, Olivier Goffart oliv...@woboq.com wrote:

 On Thursday 11 September 2014 22:03:03 Samuel Gaist wrote:
 On 11 sept. 2014, at 21:49, Thiago Macieira thiago.macie...@intel.com 
 wrote:
 On Thursday 11 September 2014 21:44:15 Samuel Gaist wrote:
 What would be the correct procedure to handle QT_DEPRECATED_SINCE ?
 Removing it from around the signal declaration would make the code a bit
 inconsistent.
 
 By the way, how is it handled in Qt 5 since building goes without any
 problem even with the macros around the signal ?
 
 moc is smarter in Qt 5: it expands macros.
 
 But the recommendation stands: do not #if (of any kind) anything that
 isn't
 #defined in the same source, in a header next to the one being compiled,
 or
 passed as -D in the command-line.
 
 That means: don't hide signals and slots with #if, even for deprecation.
 
 I thought I've read somewhere that moc got better at this job :-)
 
 I would not be as strict as Thiago.  
 In Qt5 it's fine to use the preprocessor as long as moc can see the defines 
 (that is, if they don't rely on compiler built-in or need special include 
 paths.)
 QT_DEPRECATED_SINCE should be fine.
 
 It is strange it does not work with Qt4.  Are you sure that all the include 
 paths are passed to moc?

Good question, I'll have to check. 
If that where not the case, what should I write to give additional include 
paths to moc ?

 Otherwise, you will have to work around it somehow.
 try #if not QT_DEPRECATED_SINCE() #else
 Or some other trick with Q_MOC_RUN

I forgot about that one, might be a starting point

 
 You can also use the QT_MOC_COMPAT macro in front of a declaration so QObject 
 will throw a runtime warning when connecting to this signal. (in debug mode)

Good to know

 
 It seems that the new moc doesn't use much of the Qt 5 only classes, would
 it be useful to backport it to Qt 4 to avoid having to break the code
 style for modules supporting both series ?
 
 This is out of question.
 This is a behaviour change as Qt4 code relied on moc not expending the macro 
 in some cases.
 
 (At some point it will be time to switch fully to Qt5 and drop Qt4 support)

I agree, but there are still lots of people locked to Qt 4… There's even posts 
on the forum asking for Qt 3


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

Re: [Development] Qt5.3.2 final candidate packages available

[Samuel Gaist]

Hi,

I don't think it qualifies as a showstopper but currently the build of 
QtSerialPort is broken for Qt 4. Since people could use the sources from the 
released packages to build that module it could create some mild grievance 
amongst our users.

There's
https://codereview.qt-project.org/#/c/94448/ - Make the tests build
https://codereview.qt-project.org/#/c/94451/ - code/doc cleanup
https://codereview.qt-project.org/#/c/94682/  - Make the library build

To fix the situation

Best regards

Samuel

On 12 sept. 2014, at 06:47, Heikkinen Jani jani.heikki...@digia.com wrote:

 Arg, we will repackage the packages but no updates to qt content
 
 Br,
 Jani
 
 -Original Message-
 From: Loehning Robert
 Sent: 11. syyskuuta 2014 19:11
 To: development@qt-project.org; Heikkinen Jani
 Subject: Re: [Development] Qt5.3.2 final candidate packages available
 
 https://bugreports.qt-project.org/browse/QTBUG-41261
 
 Am 11.09.2014 um 18:10 schrieb Robert Löhning:
 Hi Jani,
 
 the Installer for Linux claims to contain Qt Creator 3.2.0 (wrong) but
 it installs Qt Creator 3.2.1 (right). Might this be a showstopper?
 
 Best Regards,
 Robert
 
 
 Am 11.09.2014 um 16:38 schrieb Heikkinen Jani:
 Hi all,
 
 Qt 5.3.2 final candidate packages are available here:
 
 Windows: http://download.qt-
 project.org/snapshots/qt/5.3/5.3.2/2014-09-11_150
 Linux: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09-
 11_141
 Mac: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09-
 11_119
 
 Mirroring is ongoing and first packages are already there. Rest ones
 should be available within next few hours.
 
 We are targeting to release Qt5.3.2 (these packages) Tue 16th Sep if
 nothing serious found during testing.
 Please take a tour  check that everything is still working as expected
 and report your effort via http://testresults.qt-project.org/forms/release-
 testing/index.pl
 
 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 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] moc 4.8.6 macros

[Samuel Gaist]

Hi,

I've stumbled on https://bugreports.qt-project.org/browse/QTBUG-41190 which 
states that QtSerialPort cannot be built with Qt 4.8.6. 

From a quick look and build, it's the use of the QT_DEPRECATED_SINCE macro 
around the signals that makes moc miss them and thus the compilation fails.

Is there something that can be done outside of moc to workaround the problem ? 
Or does moc need to be improved ?

Thanks

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

Re: [Development] moc 4.8.6 macros

[Samuel Gaist]

On 11 sept. 2014, at 20:50, Thiago Macieira thiago.macie...@intel.com wrote:

 On Thursday 11 September 2014 18:28:58 Samuel Gaist wrote:
 Hi,
 
 I've stumbled on https://bugreports.qt-project.org/browse/QTBUG-41190 which
 states that QtSerialPort cannot be built with Qt 4.8.6.
 From a quick look and build, it's the use of the QT_DEPRECATED_SINCE macro
 around the signals that makes moc miss them and thus the compilation
 fails.
 Is there something that can be done outside of moc to workaround the problem
 ? Or does moc need to be improved ?
 
 NEVER #ifndef signals and slots, unless it's a simple #ifdef/#ifndef and the 
 #define is present in the source file being processed.
 

The thing is, it's not even a #ifdef, it's only a #if

What would be the correct procedure to handle QT_DEPRECATED_SINCE ? Removing it 
from around the signal declaration would make the code a bit inconsistent.

By the way, how is it handled in Qt 5 since building goes without any problem 
even with the macros around the signal ?


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

Re: [Development] moc 4.8.6 macros

[Samuel Gaist]

On 11 sept. 2014, at 21:49, Thiago Macieira thiago.macie...@intel.com wrote:

 On Thursday 11 September 2014 21:44:15 Samuel Gaist wrote:
 What would be the correct procedure to handle QT_DEPRECATED_SINCE ? Removing
 it from around the signal declaration would make the code a bit
 inconsistent.
 
 By the way, how is it handled in Qt 5 since building goes without any
 problem even with the macros around the signal ?
 
 moc is smarter in Qt 5: it expands macros.
 
 But the recommendation stands: do not #if (of any kind) anything that isn't 
 #defined in the same source, in a header next to the one being compiled, or 
 passed as -D in the command-line.
 
 That means: don't hide signals and slots with #if, even for deprecation.

I thought I've read somewhere that moc got better at this job :-)

It seems that the new moc doesn't use much of the Qt 5 only classes, would it 
be useful to backport it to Qt 4 to avoid having to break the code style for 
modules supporting both series ?

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

Re: [Development] QStorageInfo

[Samuel Gaist]

Hi,

Solid uses IOKit as backend on OS X

Best Regards

Samuel

On 25 août 2014, at 15:26, Иван Комиссаров abba...@gmail.com wrote:

 I don't think libsolid works on Mac:) Correct me if i'm wrong.
 
 Иван Комиссаров
 
 25 авг. 2014 г., в 15:55, Allan Sandfeld Jensen k...@carewolf.com 
 написал(а):
 
 Hello
 
 On Monday 25 August 2014, Matthias WALTER wrote:
 
 I see the preview doc about  QStorageInfo  on this website :
 http://doc-snapshot.qt-project.org/qt5-5.4/qstorageinfo.html#fileSystemType
 
 But I don't see anything about the type of the drives : internal,
 external, remote, .
 
 Will it come in the near feature ?
 
 In general if someone wants more information and functionality in this area 
 than QStorageInfo provides I would recommend taking a look at Solid from 
 KDE. 
 See http://solid.kde.org
 In the new KDE Frameworks it is a tier1 API which means it only depends on 
 Qt 
 and system libraries, so maybe that can cover your use case.
 
 Best regards
 `Allan
 
 ___
 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] QtCS2014 - Sponsoring Community Contributors

[Samuel Gaist]

Hi,

The summary of the Sponsoring Community Contributors session can be found here

http://qt-project.org/groups/qt-contributors-summit-2014/wiki/QtCS14SponsoringCommunityContributors

The content is a starting point based on the various input and analyses during 
the session.

Cheers !

Samuel

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

[Development] QtCS2014 - Qt In Scientific Researches session

[Samuel Gaist]

Hi,

The notes form the Qt In Scientific Researches session session are available at
http://qt-project.org/groups/qt-contributors-summit-2014/wiki/QtCs14QtInScientificResearches

Basically it's an overview of the round table we had. If someone has more 
ideas/suggestions/information, feel free to add them !

Cheers !

Samuel

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

Re: [Development] Changelogs for 5.3.0

[Samuel Gaist]

Hi,

On 23 avr. 2014, at 01:09, Thiago Macieira thiago.macie...@intel.com wrote:

 Here's some editing I've done. This serves as suggestions for other editors.
 
 - QPA/Android:
   * [QTBUG-36025] Fixed a memory leak in the clipboard
 
 Moved to Android changes. Why was this in QtCore in the first place? QPA is a 
 QtGui technology…
 

My bad, I was thinking GUI core component and mistyped the module.

 -
 - QTBUG-4714:
   * [QTBUG-4714] Use the grid size for wordwrapping when available in icon
 mode Task-number: QTBUG-4714 Change-Id:
 I2cb63809d3ee8bd262f38bc11de91df9ff5cf237 Reviewed-by: Stephen Kelly
 stephen.ke...@kdab.com
 

QtWidgets/QListView:

Until now, when QListView was in icon mode, the word wrapping was always done 
using the icon size which would be ugly if you had small icons on a big grid. 
From now on, if the grid size is set, it will be used for word wrapping.



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

Re: [Development] Changelogs for 5.3.0

[Samuel Gaist]

On 23 avr. 2014, at 09:16, Thiago Macieira thiago.macie...@intel.com wrote:

 Em qua 23 abr 2014, às 08:49:47, Samuel Gaist escreveu:
 - QTBUG-4714:
  * [QTBUG-4714] Use the grid size for wordwrapping when available in
 icon
mode Task-number: QTBUG-4714 Change-Id:
I2cb63809d3ee8bd262f38bc11de91df9ff5cf237 Reviewed-by: Stephen Kelly
stephen.ke...@kdab.com
 
 
 
 QtWidgets/QListView:
 
 Until now, when QListView was in icon mode, the word wrapping was always
 done using the icon size which would be ugly if you had small icons on a
 big grid. From now on, if the grid size is set, it will be used for word
 wrapping.
 
 Can you make it a little shorter? Please use the rest of the changelog as a 
 template.
 


Sure, I can try. This one sounds more concise and clear:

 * [QTBUG-4714] Fixed QListView ignoring the grid size for word wrapping in 
icon mode

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

Re: [Development] how to contribute?

[Samuel Gaist]

Hi,

It's not being ignored, it's just unknown to the others.

You need to add reviewers to your patch

You can see here how to do it

http://qt-project.org/wiki/Gerrit-Introduction#35584fc6462d3d2171b795208c180ac5

Regards
Samuel

On 4 avr. 2014, at 07:34, Martin Koller kol...@aon.at wrote:

 Hi,
 
 I wanted to contribute a small fix and put it already here:
 https://codereview.qt-project.org/#change,81261
 but it's ignored, so I probably missed a step.
 What should I do in addition so that a patch gets some attention ?
 -- 
 Best regards/Schöne Grüße
 
 Martin
 A: Because it breaks the logical sequence of discussion
 Q: Why is top posting bad?
 
 ()  ascii ribbon campaign - against html e-mail 
 /\- against proprietary attachments
 
 Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at
 ___
 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] New snapshot build from Qt 4.8.6 available

[Samuel Gaist]

On 17 mars 2014, at 19:07, Salovaara Akseli akseli.salova...@digia.com wrote:

 Hi all,
 
 New snapshot build from Qt 4.8.6 available: 
 http://download.qt-project.org/snapshots/qt/4.8/2014-03-17_517/ 
 
 Packages are built against sha1 6ede9f99f98ed511b78935f7c6537470dce94239 
 network: fix doc typo in QNetworkConfigurationManager (HEAD) and this build 
 also has MinGW4.8.2 upgrade from Mingw-Builds 
 i686-4.8.2-release-posix-dwarf-rt_v3-rev2 to Mingw-Builds 
 i686-4.8.2-release-posix-dwarf-rt_v3-rev3. If blocker issues for Qt 4.8.6 
 release are found please report those to bugreports.qt-project.org and raise 
 issue also on releas...@qt-project.org.
 
 We would like to try freeze sha1 again and issue Release Candidate during 
 this week. If you have critical patch pending on codereview please act 
 according to that schedule in mind. All changes before rebuild 
 configure.exe (not yet in codereview, expected to be available on this 
 Wednesday) will be part of Qt 4.8.6 release. After that sha1 changes will be 
 considered case by case.
 
 Br,
 Akseli
 
 Akseli Salovaara
 Digia, Qt
 

Hi,

There's currently a discussion about this potential issue 
https://bugreports.qt-project.org/browse/QTBUG-37514 so there's nothing in 
gerrit yet but it might worth to keep an eye on it.

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

Re: [Development] Missing documentation

[Samuel Gaist]

Hi !

On 20 févr. 2014, at 15:32, Sze Howe Koh szehowe@gmail.com wrote:

 Hi all,
 
 The following functions/types need documenting. (This list excludes
 constructors, destructors, and operators). Could those who are
 familiar with these functions/types please add them?
 
 qtbase.git
QWidget::macCGHandle()
QWidget::macQDHandle()
 

These two are currently not implemented anywhere in stable, should this be 
reported as a bug ?

 qtmacextras.git
QtMac::applicationIconBadgeNumber()
QtMac::badgeLabelText()
QtMac::currentCGContext()
QtMac::fromCGImageRef()
QtMac::fromNSData()
QtMac::fromNSString()
QtMac::fromNSURL()
QtMac::isMainWindow()
QtMac::setApplicationIconBadgeNumber()
QtMac::setBadgeLabelText()
QtMac::toCGImageRef()
QtMac::toNSData()
QtMac::toNSImage()
QtMac::toNSString()
QtMac::toNSURL()
 

Is there a task number associated with that ?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Samuel Gaist]

On 29 janv. 2014, at 18:50, Konrad Rosenbaum kon...@silmor.de wrote:

 Hi,
  
 On Wednesday, Wednesday 29 January 2014 at 11:02, Koehne Kai wrote:
   -Original Message-
   From: development-bounces+kai.koehne=digia@qt-project.org
   [...]
   Later on: when a plan has been found to expose the low-level OpenSSL API
   to Qt this implementation could be changed to use OpenSSL and fall back
   to qrand if it is not available.
  
  How about just making this plan A?
  
  Maybe I'm naïve, but that would just require that
  - qtwebsockets link against openssl directly (see e.g.
  qtbase/src/network/ssl/ssl.pri)
  
 The first problem I could see with this: is it binary compatible to later on 
 relax this requirement?
  
 Direct linking may also cause problems if QSslSocket for some strange reason 
 then tries to load a different version of OpenSSL later on...
  
 After reading myself a bit into the API: I don't think a fast start on this 
 is a particularly great idea. OpenSSL is not thread-safe per default and 
 needs some specific initialization for thread safety. This initialization 
 needs to be done EXACTLY once.
  
 In short: we need a unified interface into OpenSSL for Qt before we attempt 
 to do this.
  
  - Use the API described in
  http://wiki.openssl.org/index.php/Random_Numbers to generate the random
  number.
  
  I also don't think you even need the 'no-openssl available' use case.
  
 While OpenSSL is commonly available on most systems. It may not be available 
 on all embedded platforms and it may not be the expected version. I can see 
 scenarios in which Websockets are needed, but OpenSSL is not available or not 
 desired by the user (e.g. embedded industrial apps that need to access some 
 networked resource with a very strange protocol[tm] while the boss insists 
 that he would run into export restrictions if he allowed OpenSSL).
  
  
   Konrad

If I may chime in, iOS officially doesn't provide OpenSSL and the documentation 
recommends to use Apple's own cryptographic framework.

https://developer.apple.com/library/mac/DOCUMENTATION/Security/Conceptual/cryptoservices/GeneralPurposeCrypto/GeneralPurposeCrypto.html

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

Re: [Development] OS X bundle detection

[Samuel Gaist]

On 24 janv. 2014, at 18:05, Thiago Macieira thiago.macie...@intel.com wrote:

 On sexta-feira, 24 de janeiro de 2014 09:25:35, Samuel Gaist wrote:
 Extending this list would make the current test (if else if) getting a bit
 long and not necessarily the good thing to do (™) so once the list of
 extension is decided I would like to know what would be the Qtish way to
 store it:
 
 A static QVector inside the function ?
 A static QVector outside the function with an intializing function ?
 Other container/algorithm best suited ?
 
 An indexed string table, generated with generate_string_table.pl which you 
 can 
 find in the kdesdk repository. You can see examples of it in qsimd.cpp and in 
 qdbuserror.cpp. It's also what moc generates behind the scenes.
 
 Marc has some code to be able to generate them with macros but he hasn't yet 
 fixed the issues we pointed out. They'll miss 5.3.
 

Nice, thank you ! 

Is the macro version already viewable somewhere ?

One more thing, what's the best way to provide the original data ? In a comment 
above the generated table or a text file ?

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

[Development] OS X bundle detection

[Samuel Gaist]

Hi guys,

While reviewing https://codereview.qt-project.org/#change,59523 Jake Petroules 
brought up an interesting point about the list of extensions that would be 
worth testing. 

Extending this list would make the current test (if else if) getting a bit long 
and not necessarily the good thing to do (™) so once the list of extension is 
decided I would like to know what would be the Qtish way to store it:

A static QVector inside the function ?
A static QVector outside the function with an intializing function ?
Other container/algorithm best suited ?

Also, since this update would first go in Qt 5, I would like to know what would 
be the procedure to get it back in Qt 4: update this change set to include the 
new code ? Push this one and cherry pick the additional changes ? Cherry pick 
both and squash them ? I don't know if the last one is doable nor recommended. 
Any advice on this matter appreciated

Thanks !

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

Re: [Development] How to write a ChangeLog entry

[Samuel Gaist]

On 21 janv. 2014, at 00:43, Thiago Macieira thiago.macie...@intel.com wrote:

 On segunda-feira, 20 de janeiro de 2014 23:58:21, Samuel Gaist wrote:
 On 20 janv. 2014, at 23:44, Thiago Macieira thiago.macie...@intel.com 
 wrote:
 On segunda-feira, 20 de janeiro de 2014 22:59:09, Samuel Gaist wrote:
 Yes it does, with that, QLocale supports the various possible negative
 signs 
 Can you verify if the change also affects QString::toInt, toDouble, etc.?
 
 5.1.1 doesn't support U+2212.
 
 Sure, I'll do it tomorrow
 
 IIRC, the patch went in for 5.2
 
 Right, this is the 5.2.1 change log.

As promised:

QString str(\u2212\x31\x36);

qDebug()  str.toShort()  str.toInt()  str.toDouble()  str.toLong()  
str.toLongLong()  str.toFloat();

all returns -16

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

Re: [Development] How to write a ChangeLog entry

[Samuel Gaist]

On 20 janv. 2014, at 21:59, Thiago Macieira thiago.macie...@intel.com wrote:
 
 QtCore
 --
 
 - [QTBUG-35069] Fixed a bug that caused negative number input using '-' to
   be rejected because the current locale uses e.g. 0x2212. QIntValidator
   and QDoubleValidator now accepts both signs as well as the locale minus
   sign.
 
 Neither class is in QtCore. I'm moving this to QtWidgets.
 


Hi,

shouldn't the major area be the place where the fix is ? 

Here the side effect is that it solves a problem reported in QtWidgets. 

In that case, my log message might not be clear enough 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How to write a ChangeLog entry

[Samuel Gaist]

On 20 janv. 2014, at 22:40, Thiago Macieira thiago.macie...@intel.com wrote:

 On segunda-feira, 20 de janeiro de 2014 22:21:54, Samuel Gaist wrote:
 On 20 janv. 2014, at 21:59, Thiago Macieira thiago.macie...@intel.com 
 wrote:
 QtCore
 --
 
 - [QTBUG-35069] Fixed a bug that caused negative number input using '-'
 to
 
  be rejected because the current locale uses e.g. 0x2212. QIntValidator
  and QDoubleValidator now accepts both signs as well as the locale minus
  sign.
 
 Neither class is in QtCore. I'm moving this to QtWidgets.
 
 Hi,
 
 shouldn't the major area be the place where the fix is ?
 
 Here the side effect is that it solves a problem reported in QtWidgets.
 
 In that case, my log message might not be clear enough
 
 It should be where the fix is visible, what code gets affected. Does this 
 affect 
 QLocale too? If so, then I can leave it in the QtCore part and just add the 
 extra info.
 
 -- 

Yes it does, with that, QLocale supports the various possible negative signs
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How to write a ChangeLog entry

[Samuel Gaist]

On 20 janv. 2014, at 23:44, Thiago Macieira thiago.macie...@intel.com wrote:

 On segunda-feira, 20 de janeiro de 2014 22:59:09, Samuel Gaist wrote:
 Yes it does, with that, QLocale supports the various possible negative signs
 
 Can you verify if the change also affects QString::toInt, toDouble, etc.?
 
 5.1.1 doesn't support U+2212.
 

Sure, I'll do it tomorrow

IIRC, the patch went in for 5.2

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

Re: [Development] Nokia/Digia copyright in PDF produced by QPrinter

[Samuel Gaist]

On 3 nov. 2013, at 18:28, John Layt jl...@kde.org wrote:

 On Monday 07 Oct 2013 10:35:26 David Boddie wrote:
 On Sun Oct 6 20:51:40 CEST 2013, Lars Knoll wrote:
 
 I think this is fully correct, and doesn't assert any copyright over the
 generated PDF. It states that the PDF got produced by the PDF generator of
 Qt 5.1.1, which is (C) Digia.
 
 While this interpretation may be valid, it is unusual to put the copyright
 of the creation tool in the Producer string. I can find documents with the
 following Producer strings on my disk:
 
 (AFPL Ghostscript 8.54)
 (Acrobat 5.0 Image Conversion Plug-in for Macintosh)
 (Adobe PDF library 4.800)
 (Aladdin Ghostscript 6.01)
 (GNU Ghostscript 7.07)
 (GPL Ghostscript 9.05)
 (ImageMagick 6.3.8 01
 (Inkscape inkscape 0.44.1)
 (LaTeX with hyperref)
 (Mac OS X 10.5.8 Quartz PDFContext)
 (MiKTeX pdfTeX-1.40.9)
 (Microsoft� Publisher 2010)
 (cairo 1.9.5 (http:
 (pdfTeX-2.00.0)
 (pdfeTeX-1.403)
 (xdvipdfmx \(0.7.5\))
 
 The only two that I found that included a copyright symbol were Qt and
 Microsoft Word. The above Microsoft Publisher string presumably includes a
 registered trademark symbol, which is more common.
 
 I suggest removing the Producer copyright string to avoid confusion since it
 is clear that Digia doesn't seek to claim copyright on user-generated
 content. Along the same lines, it might be useful to add a setProducer()
 function to QPrinter for applications that create PDFs as a key part of
 their functionality.
 
 Good analysis David, makes it clear this is not normal practice.  I've raised 
 change https://codereview.qt-project.org/#change,70182 to remove the 
 copyright 
 statement for 5.2 (which will need to be back-ported to 4.8).  I'll leave the 
 Producer api for 5.3.
 
 Cheers!
 
 John.

The backport is available at
https://codereview.qt-project.org/#change,70187

Cheers !

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

Re: [Development] Split submission

[Samuel Gaist]

On 10 oct. 2013, at 01:49, Thiago Macieira wrote:

 On quinta-feira, 10 de outubro de 2013 01:36:18, Samuel Gaist wrote:
 Hi,
 
 I just started to split a submission in several patches like Stephen Kelly
 taught me.
 
 There's just one thing I forgot to ask him: how should the patches be
 organized and sent since when broken down (it should be three patches), the
 last one would only apply once the second patch is applied ?
 
 The first and second part can be separated (so two different submissions)
 since they solve two different but related problems (the second being
 triggered when solving the first).
 
 Also what would be the best/recommended setup git wise ? Should I make a
 topic branch from my topic branch ?
 
 The easiest is to just git push all three. They will be reviewed 
 independently. And you are the person to hit the stage button, so you should 
 know which one needs to go in which order.
 
 Now, the problem is when the second or third patch needs to be updated. You 
 should avoid updating the first (and second) patch(es) when submitting the 
 update, unless you actually want that. To do that, you should check out the 
 parent commit and then cherry-pick the new change.
 
 Steps:
 1) open the review page in Gerrit
 2) copy the SHA-1 of the latest patch
 3) in your shell, right:
   git checkout [paste the SHA-1]~
 remember to include the ~ at the end
 4)git cherry-pick [your new commit]
 5)git gpush :stable
 
 or, if you're using my gerrit-pick script, you can do it in one command:
 
   git gp -t stable -b [paste here]~ [your commit]
 
 -- 
 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

Thank you for the instructions !

Is there already a wiki describing that ? Something like Advanced Gerrit 
Usage ?

That might come handy for people not having their git-fu black-belt yet
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Split submission

[Samuel Gaist]

Thank you for the informations and tips !

On 10 oct. 2013, at 07:50, Ziller Eike wrote:

 Hi,
 
 you can just have the patches sequentially in your local branch and push 
 these together (git push gerrit HEAD:refs/for/dev or whereever that should 
 go, that pushes all your local commits up to HEAD). Gerrit shows dependency 
 information in the changes if you push them together, i.e. the 'later' 
 changes show the changes they depend on in the dependencies section of the 
 page. Gerrit never prevents that changes are (tried to be) submitted in a 
 different order though, even with topic branches afaik. If you want to make 
 sure that your reviewers are not confused (if you haven't talked to them 
 already anyhow), you can add a comment about the dependency too.
 
 Br, Eike
 
 --
 Eike Ziller
 Senior Software Engineer
 
 Digia Germany GmbH
 Rudower Chaussee 13, D-12489 Berlin
 Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, 
 HRB 144331 B,
 Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
 
 
 From: development-bounces+eike.ziller=digia@qt-project.org 
 [development-bounces+eike.ziller=digia@qt-project.org] on behalf of 
 Samuel Gaist [samuel.ga...@edeltech.ch]
 Sent: 10 October 2013 01:36
 To: development@qt-project.org
 Subject: [Development] Split submission
 
 Hi,
 
 I just started to split a submission in several patches like Stephen Kelly 
 taught me.
 
 There's just one thing I forgot to ask him: how should the patches be 
 organized and sent since when broken down (it should be three patches), the 
 last one would only apply once the second patch is applied ?
 
 The first and second part can be separated (so two different submissions) 
 since they solve two different but related problems (the second being 
 triggered when solving the first).
 
 Also what would be the best/recommended setup git wise ? Should I make a 
 topic branch from my topic branch ?
 
 Thank you
 ___
 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