Re: [Development] Support for *Notes and UpstreamFiles fields in qt_attributions.json files
> -Original Message- > From: Development On Behalf Of Ulf > Hermann via Development > Subject: Re: [Development] Support for *Notes and UpstreamFiles fields in > qt_attributions.json files > > YAML is really quite terrible. If we're going to switch, let's choose > something > else. > > Basically, YAML is extremely complex, ambiguous, and incompatible between > different versions. See for example > https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell for > an in-depth explanation. > > Toml seems to be popular these days. I'd be open to all kinds of formats if we'd start on a green field. But we're not, and I don't think reimplementing qtattributionsscanner + redo the build system integration + convert all existing qt_attributionsscanner.json files to a new format is worth the time. Unless, of course, somebody volunteers Regards Kai -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Meeting minutes from Qt Release Team meeting 14.2.2023
Qt 6.5 status - Qt 6.5 beta3 preparations ongoing * Content not frozen yet but target is to freeze it as soon as possible * Target is to release Qt 6.5.0 beta3 at the beginning of next week - Qt 6.5 API Change review mostly done, see https://codereview.qt-project.org/q/topic:api-change-review-6.5 - Updating 3rd party components for Qt 6.5 mostly done as well, see https://bugreports.qt.io/browse/QTBUG-110331 - Soft string freeze will be announced Wed 15th February Qt 6.4 status - Qt 6.4.3 preparations started * First snapshot created, looking good * Branching from '6.4' to '6.4.3' will happen at the beginning of next week * Target is to release Qt 6.4.3 at the end of February as planned Next meeting Tue 21st February 2023 16:00 CET br, Jani Heikkinen Release Manager irc log below: [17:00:19] akseli: ablasche: carewolf: frkleint_: lars__:mapaaso: The-Compiler: thiago: vladimir-minenko: vohi: ping [17:00:29] jaheikki3: pong [17:01:01] jaheikki3: pong [17:01:30] jaheikki3: pong [17:01:37] time to start qt release team meeting [17:01:48] on agenda today: qt 6.5 status [17:01:54] Qt 6.4 status [17:02:02] Any additional item to the agenda? [17:03:38] Let's start from qt 6.5 status [17:03:49] Qt 6.5 beta3 preparations ongoing [17:04:06] Content isn't frozen yet but target is to freeze it asap [17:04:24] currently waiting fixes for QTBUG-40 [17:04:45] it is blocking us to build b2qt packages for beta3 [17:05:20] checking [17:05:24] the target is to release Qt 6.5.0 beta3 at the beginning of next week [17:05:41] the header review for QtCore still has a lot of unresolved comments: https://codereview.qt-project.org/q/topic:api-change-review-6.5; otherwise we are mostly good I think, a few reviews unapproved but at least not a lot of pending comments [17:06:23] Yeah, otherwise Qt 6.5 API Change is mostly done [17:06:57] Updating 3rd party components for Qt 6.5 mostly done as well [17:06:59] see https://bugreports.qt.io/browse/QTBUG-110331 [17:07:47] Soft string freeze will be in announced wed 15th February, official string freeze for Qt 6.5 wed 23rd february [17:08:06] not sure I can help qtgrpc, but I'll post questions [17:08:34] thnx [17:08:56] that's all about 6.5 status at this time. Any comments or questions? [17:10:40] ok, then Qt 6.4 status [17:10:53] Qt 6.4.3 preparations started [17:11:22] first snapshot created & RTA tests done, looking good [17:11:38] Branching from '6.4' to '6.4.3' will happen at the beginning of next week [17:12:07] and target is to release Qt 6.4.3 at the end of February as planned [17:12:39] that's all about 6.4 status at this time, any comments or questions? [17:13:47] sounds like a plan [17:14:20] Great. Let's end this meeting now and have new one tue 21st february at this same time. [17:14:31] Thanks for your participation, bye! [17:14:32] thanks! [17:14:35] bye [17:15:13] bye -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Support for *Notes and UpstreamFiles fields in qt_attributions.json files
YAML is really quite terrible. If we're going to switch, let's choose something else. Basically, YAML is extremely complex, ambiguous, and incompatible between different versions. See for example https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell for an in-depth explanation. Toml seems to be popular these days. best regards, Ulf -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Support for *Notes and UpstreamFiles fields in qt_attributions.json files
On Tuesday, 14 February 2023 07:07:00 PST Kai Köhne via Development wrote: > First, let's agree that JSON sucks for the task at hand. It doesn't have any > explicit support for comments, and no support for multi-line strings > (though our implementation tolerates this). How about switching to YAML? Those files are consumed by qtattributionsscanner. That looks like a very simple application that can be rewritten in Python, or it could launch Python or yq to convert YAML to JSON on the fly. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Support for *Notes and UpstreamFiles fields in qt_attributions.json files
Hi,
+1 to the approach suggested by Kai.
Having comments would be very helpful, but I do not think that we need a
separate comment field for each entry.
Best regards,
Ivan
From: Development on behalf of Kai Köhne
via Development
Sent: Tuesday, February 14, 2023 4:07 PM
To: Edward Welbourne ; Development@qt-project.org
Subject: Re: [Development] Support for *Notes and UpstreamFiles fields in
qt_attributions.json files
Hi Eddy,
> -Original Message-
> From: Development On Behalf Of
> Edward Welbourne via Development
> Sent: Tuesday, February 14, 2023 3:14 PM
> To: Development@qt-project.org
> Subject: [Development] Support for *Notes and UpstreamFiles fields in
> qt_attributions.json files
>
> Hi all,
>
> Having taken part in various third-party updates and felt a need to leave
> notes
> for those who will do the same in future, I have run up against JSON not
> having
> a comment format. To work round that, I propose to allow some fields to be
> included in a qt_attribution.json file for that purpose. As a general
> pattern, I
> propose allowing ${Field}Notes for any ${FIELD} that already exists; and a
> separate UpstreamFiles field, corresponding to the Files one, to list where in
> the upstream source tree to find the files that are to be copied.
First, let's agree that JSON sucks for the task at hand. It doesn't have any
explicit support for comments, and no support for multi-line strings (though
our implementation tolerates this).
Anyhow, I wonder whether it wouldn't suffice to have _one_ comments field,
instead of a dedicated UpstreamFiles field, and *Notes fields for every single
entry. E.g.
{
"Comments": [
"Upstream files were copied from:",
" src/dir1, src/dir2",
"The license and copyright was derived from dist/LICENSE.txt"
]
}
The benefit I see is that qtattributionsscanner (and any other JSON tool that
might be used by others) has only to care about one additional field, not
multiple ones.
Regards
Kai
--
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] Support for *Notes and UpstreamFiles fields in qt_attributions.json files
Hi Eddy,
> -Original Message-
> From: Development On Behalf Of
> Edward Welbourne via Development
> Sent: Tuesday, February 14, 2023 3:14 PM
> To: Development@qt-project.org
> Subject: [Development] Support for *Notes and UpstreamFiles fields in
> qt_attributions.json files
>
> Hi all,
>
> Having taken part in various third-party updates and felt a need to leave
> notes
> for those who will do the same in future, I have run up against JSON not
> having
> a comment format. To work round that, I propose to allow some fields to be
> included in a qt_attribution.json file for that purpose. As a general
> pattern, I
> propose allowing ${Field}Notes for any ${FIELD} that already exists; and a
> separate UpstreamFiles field, corresponding to the Files one, to list where in
> the upstream source tree to find the files that are to be copied.
First, let's agree that JSON sucks for the task at hand. It doesn't have any
explicit support for comments, and no support for multi-line strings (though
our implementation tolerates this).
Anyhow, I wonder whether it wouldn't suffice to have _one_ comments field,
instead of a dedicated UpstreamFiles field, and *Notes fields for every single
entry. E.g.
{
"Comments": [
"Upstream files were copied from:",
" src/dir1, src/dir2",
"The license and copyright was derived from dist/LICENSE.txt"
]
}
The benefit I see is that qtattributionsscanner (and any other JSON tool that
might be used by others) has only to care about one additional field, not
multiple ones.
Regards
Kai
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] Support for *Notes and UpstreamFiles fields in qt_attributions.json files
Hi all,
Having taken part in various third-party updates and felt a need to
leave notes for those who will do the same in future, I have run up
against JSON not having a comment format. To work round that, I propose
to allow some fields to be included in a qt_attribution.json file for
that purpose. As a general pattern, I propose allowing ${Field}Notes
for any ${FIELD} that already exists; and a separate UpstreamFiles
field, corresponding to the Files one, to list where in the upstream
source tree to find the files that are to be copied.
This will make the work easier for those who do third-party updates and
avoid various kludges presently in use to work round the lack of
comments (for example, abusing an existing field to first write the note
and then over-write it with the value; the tools that process the files
cope, but it's malformed JSON).
See:
* https://codereview.qt-project.org/c/meta/quips/+/460358
* https://codereview.qt-project.org/c/qt/qttools/+/460116
* https://codereview.qt-project.org/c/qt/qttools/+/460181
* https://codereview.qt-project.org/c/qt/qtbase/+/458824
The last triggered this; the previous two implement it and the first is
an update to QUIP 7.
Eddy.
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Help me, check bug Qt topic 142770, very urgent!
Hi Florian ,
I send you my problem :
I am development my application with the qt 5.15 (c++ code) .The my
application is implement using objects are child of the QWidget class. Every
time that I open a child class connect the closing signal at the slot to parent
class to delete the object child :
PARENT CLASS :
windows = new ChildClass ( ) ;
connect ( )
disconnect(childClass,::signalClose,parentClass,::closeChildClass);
windows-> showFullScreen ( ) ;
CHILD CLASS :
emit signalClose ( ) ;
PARENT CLASS :
slot closeChildClass :
windows-> deleteLater ( ) ;
I have Implement a application to execute this simple code, if I can keep
press the touch screen with my finger when the application execute the
windows-> deleteLater ( ) instruction, the touch screen is freeze, I don't can
to press the button of the my application with the display touch. While if I
connect the mouse I can press the button correctly, but if to press button with
the finger not spring the ::released event. If I can to active
::released event with mouse, means that my application is not block
and the button is enabled. If I comment the windows-> deleteLater ( )
instruction I don't this problem. Afer that problem occurred if I restart the
application it work correctly, without power off the pc, so the display touch
work correcty.
Can you help me ?
This problem blocking the release the my application !
Thanks
Code :
--- home.h -`
#ifndef HOME_H
#define HOME_H
#include
//-
//INCLUDE VALIDI PER TUTTE LE FINESTRE
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
//-
#include "lavaggio.h"
#include
#include
#include
#include
namespace Ui {
class Home;
}
class Home : public QWidget
{
Q_OBJECT
public:
explicit Home ( Init *tmp_init = nullptr, QWidget *parent = nullptr ) ;
~Home();
protected:
void paintEvent(QPaintEvent *)
{
QStyleOption opt;
opt.init(this);
QPainter p(this);
style()->drawPrimitive(QStyle::PE_Widget, , , this);
}
signals :
public slots :
void openAvvioLavaggio();
void closeAvvioLavaggio();
private slots:
private :
Ui::Home *ui ;
Lavaggio *window = nullptr ;
} ;
#endif // HOME_H
--- home.cpp -
Home::Home (Init * tmp_init , QWidget * parent ) :
QWidget ( parent ) ,
ui ( new Ui::Home )
{
qDebug ( ) << "Load Home" ;
ui->setupUi(this);
this -> setWindowFlags ( Qt::Window | Qt::CustomizeWindowHint ) ;
connect(ui->btn_avvio_lavaggio, ::released, this,
::openAvvioLavaggio);
}
void Home::openAvvioLavaggio(){
qDebug ( ) <<"Start 'wash'.";
// creo istanza oggetto finestra Avvio Lavaggio
window= new Lavaggio();
//collego slot-signal all'eventi di chiusura del widget
// Note : time to execute this instruction about 500ms
connect(window,::closeLavaggio,this,::closeAvvioLavaggio);
//visualizzo schermata Avvio Lavaggio
window->showFullScreen();
// Remove the 'stays on top hint'
this -> setWindowFlags ( Qt::Window | Qt::CustomizeWindowHint ) ;
}
void Home::closeAvvioLavaggio()
{
qDebug ( ) <<"closeAvvioLavaggio";
//scollego slot-signal all'eventi di chiusura del widget
disconnect(window,::closeLavaggio,this,::closeAvvioLavaggio);
window->deleteLater();
window = nullptr ;
}
--- lavaggio.h -
#ifndef LAVAGGIO_H
#define LAVAGGIO_H
#include
//-
//INCLUDE VALIDI PER TUTTE LE FINESTRE
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
//-
#include "pagamentolavaggioasciugatura.h"
#include "messagebox.h"
#include "ChooseTypeWash.h"
#include "laundrysettings.h"
#include "laundryapp.h"
namespace Ui {
class Lavaggio;
}
class Lavaggio : public QWidget
{
Q_OBJECT
public:
explicit Lavaggio( QWidget *parent = nullptr);
~Lavaggio();
protected:
void paintEvent(QPaintEvent *)
{
QStyleOption opt;
opt.init(this);
QPainter p(this);
style()->drawPrimitive(QStyle::PE_Widget, , , this);
}
signals :
// Close the window
void closeLavaggio ( ) ;
private slots:
// Exit from screen
void exitWash ( ) ;
private:
Ui::Lavaggio *ui;
} ;
#endif // LAVAGGIO_H
--- lavaggio.cpp -
Lavaggio::Lavaggio ( QWidget *parent ) :
QWidget(parent),
ui(new Ui::Lavaggio)
{
qDebug ( ) <<"Load Lavaggio";
//--
//CARICAMENTO GRAFICA
//avvio caricamento grafica
ui->setupUi(this);
//
Re: [Development] Help me, check bug Qt topic 142770, very urgent!
Hi, On Tue, Feb 14, 2023 at 09:38:43AM +0100, g.scarpe...@u-tech.it wrote: > Can you help me to resolve the problem illustrated in the discussion > with topic 142770 ? This is a community mailinglist, which is the wrong place to get "very urgent" help with a non-public bug. Most people here (me included) won't even be able to see the thing you mention. Florian -- m...@the-compiler.org | https://www.qutebrowser.org https://bruhin.software/ | https://github.com/sponsors/The-Compiler/ GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ signature.asc Description: PGP signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Help me, check bug Qt topic 142770, very urgent!
Hello, Can you help me to resolve the problem illustrated in the discussion with topic 142770 ? Name topic : The touch screen events are block after deleteLater function Best regards, Gianmarco Scarpelli [microtechsrl_1486503464_F.png] *-*-*-*-*-*-*-*-*-*-*-*-* Dot. Gianmarco Scarpelli Microtech Srl Via Mameli, 94 53043 Chiusi (Si) http://www.microtechsrl.net Tel +39 0578 294621 Fax +39 0578 1900218 Attenzione: Le informazioni contenute in questo messaggio di posta elettronica sono private e confidenziali, riservate solo all'attenzione del destinatario. Qualora doveste ricevere questo messaggio per errore, Vi notifichiamo con la presente che ogni diffusione, riproduzione, distribuzione o utilizzo del presente messaggio è altamente proibita. Siete pregati di informare il mittente con un messaggio di risposta e cancellare immediatamente il presente messaggio ed il suo eventuale contenuto, senza copiarlo o aprirlo. * This e-mail and any file transmitted with it, which may contain confidential and/or privileged material, is legally privileged and intended solely for the recipient. Access to this e-mail by anyone else, use it for any purpose, store, copy, disclose the contents to any other person totally or partially is strictly prohibited and illegal. If you are not the intended recipient(s), please do not read this e-mail, delete this message and any attachments from your system and contact the sender by reply e-mail or by telephone. * -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Qt 6.6 initial schedule (was: Proposal: let's change the release schedules a bit)
Hi all, It seems there isn't that much support to change the release schedule frame so let's keep the old one & plan new minor releases in March & September. So my proposal for Qt 6.6 schedule is: * Qt 6.6 Platform and Module freeze 19.5.2023 * Qt 6.6 Feature Freeze 2.6.2023 * Qt 6.6 Beta1 14.6.2023 * Qt 6.6 RC 12.9.2023 * Qt 6.6 Final release 26.9.2023 This is pretty much similar schedule we had with Qt 6.4.0. With this schedule we should be able to get the beta1 release out before midsummer & summer break. br, Jani Heikkinen Release Manager > -Original Message- > From: Development On Behalf Of > Kevin Kofler via Development > Sent: maanantai 13. helmikuuta 2023 16.59 > To: development@qt-project.org > Subject: Re: [Development] Proposal: let's change the release schedules a bit > > Volker Hilsheimer via Development wrote: > > But for the release team, the busy time is shortly before, and > > significantly after the freeze. So from that perspective, having the > > feature freeze either significantly before the summer break, or > > afterwards, makes most sense. They are the ones most impacted. > > > > So, if Jani and the team believe that their work will be made easier > > by moving the feature freeze to be after the holidays, then let’s do > > that. If we find out that it causes problems that outweigh the > > benefits, then we can adjust again based on that experience. > > So you think it makes sense to inconvenience dozens of developers for the > convenience of a handful release managers? Having only contributed small > patches to Qt so far, I do not have a personal preference for the release > schedule, but the way you are weighing the tradeoffs looks very odd to me. > > Kevin Kofler > > -- > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
