[Interest] Exceptions
Turtle Creek Software
support at turtlesoft.com
Fri May 24 18:25:37 CEST 2024
>> Install a terminate handler instead.
Is there some way to get from there back to the event loop? If so, that
would solve our problem. If not, there's nothing we can do safely in a
handler. Doing a database commit would cause worse chaos if there are
unfinished records. It needs GUI code to check that.
It's been a few years since we worked in Obj-C, but it was possible to give
a message, throw an exception then continue work. I don't remember whether
they were caught in an Obj-C++ override of the event loop, or if Cocoa just
swallowed the throws. If necessary we can go back and check the details.
Thanks,
Dennis Kolva
Programming Director
TurtleSoft.com
On Fri, May 24, 2024 at 6:00 AM <interest-request at qt-project.org> wrote:
> Send Interest mailing list submissions to
> interest at qt-project.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.qt-project.org/listinfo/interest
> or, via email, send a message with subject or body 'help' to
> interest-request at qt-project.org
>
> You can reach the person managing the list at
> interest-owner at qt-project.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Interest digest..."
> Today's Topics:
>
> 1. Re: Exceptions (Turtle Creek Software)
> 2. Re: Exceptions (Thiago Macieira)
> 3. Undefined symbols when porting from Qt5 to Qt6
> (Corentin Bacqu?-cazenave)
> 4. Re: Undefined symbols when porting from Qt5 to Qt6
> (Thiago Macieira)
> 5. Re: Undefined symbols when porting from Qt5 to Qt6
> (Corentin Bacqu?-cazenave)
> 6. Update widget geometry BEFORE window shown (David M. Cotter)
> 7. Re: Undefined symbols when porting from Qt5 to Qt6
> (Thiago Macieira)
> 8. Re: Update widget geometry BEFORE window shown (Volker Hilsheimer)
> 9. Re: Update widget geometry BEFORE window shown (coroberti)
> 10. Support for deployment on iOS 17 devices ?
> (worldwidestar at sina.com)
>
>
>
> ---------- Forwarded message ----------
> From: Turtle Creek Software <support at turtlesoft.com>
> To: interest at qt-project.org
> Cc:
> Bcc:
> Date: Thu, 23 May 2024 10:57:39 -0400
> Subject: Re: [Interest] Exceptions
> *Qt 6.7 > Best Practice Guides > Exception Safety* as currently written
> seems very reasonable. We'd much rather see that extended to ARM rather
> than abandoned.
>
> This link states that ARM fully supports C++ exception handling:
>
> https://developer.arm.com/documentation/dui0491/i/C-and-C---Implementation-Details/C---exception-handling
>
> If the problem is with Apple/Cocoa/SwiftUI, would a throw just skip their
> code in the stack unwind? That might cause unknown errors, but would still
> be better than fast termination.
>
> In a GUI app, there's always a tall pile of QWidgetry on the stack.
> Catching rare errors before it means extra code that will never be used.
> More time and clutter. Throws to the event loop are such an elegant
> solution.
>
> Dennis Kolva
> Programming Director
> TurtleSoft.com
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Thiago Macieira <thiago.macieira at intel.com>
> To: interest at qt-project.org
> Cc:
> Bcc:
> Date: Thu, 23 May 2024 12:14:01 -0300
> Subject: Re: [Interest] Exceptions
> On Thursday 23 May 2024 11:57:39 GMT-3 Turtle Creek Software wrote:
> > *Qt 6.7 > Best Practice Guides > Exception Safety* as currently written
> > seems very reasonable. We'd much rather see that extended to ARM rather
> > than abandoned.
>
> That is pending an investigation on whether the frames provided by Apple
> frameworks support unwinding. If they don't, then there's nothing we can
> do
> and you can argue with Apple.
>
> > This link states that ARM fully supports C++ exception handling:
> >
> https://developer.arm.com/documentation/dui0491/i/C-and-C---Implementation-D
> > etails/C---exception-handling
>
> That's irrelevant for Objective C, which is what Apple writes their code
> in.
>
> > If the problem is with Apple/Cocoa/SwiftUI, would a throw just skip their
> > code in the stack unwind? That might cause unknown errors, but would
> still
> > be better than fast termination.
>
> No, it makes unwinding impossible. You can't unwind a frame if you don't
> know
> how to unwind it. The only possibility is to std::terminate().
>
> > In a GUI app, there's always a tall pile of QWidgetry on the stack.
> > Catching rare errors before it means extra code that will never be used.
> > More time and clutter. Throws to the event loop are such an elegant
> > solution.
>
> Install a terminate handler instead.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Principal Engineer - Intel DCAI Fleet Engineering and Quality
>
>
>
> ---------- Forwarded message ----------
> From: "Corentin Bacqué-cazenave" <corentin at progaccess.net>
> To: "interest at qt-project.org Interest" <interest at qt-project.org>
> Cc:
> Bcc:
> Date: Thu, 23 May 2024 23:14:01 +0200
> Subject: [Interest] Undefined symbols when porting from Qt5 to Qt6
>
> Hi,
>
> I'm trying to port an application from Qt5 to Qt6.
>
> I get a lot of errors regarding undefined symbols reference like XUngrabKey,
> XFree, XStringToKeysym, XFlush...
>
> All symbols related to X11 seam to be missing.
>
> Does anyone have an idea?
>
> Thanks
> --
>
> Corentin : expert certifié 2022 et <https://linktr.ee/CoBC1>Sponsor
> <https://github.com/sponsors/nvaccess?sp=CoBC> NVDA, Référent commission
> Cécité & Co et Mandataire CNCPH à la commission Accessibilité Universelle -
> Fédé 100% Handinamique <https://www.handinamique.org/>
>
>
>
> ---------- Forwarded message ----------
> From: Thiago Macieira <thiago.macieira at intel.com>
> To: interest at qt-project.org
> Cc:
> Bcc:
> Date: Thu, 23 May 2024 19:01:42 -0300
> Subject: Re: [Interest] Undefined symbols when porting from Qt5 to Qt6
> On Thursday 23 May 2024 18:14:01 GMT-3 Corentin Bacqué-cazenave via
> Interest
> wrote:
> > Hi,
> >
> > I'm trying to port an application from Qt5 to Qt6.
> >
> > I get a lot of errors regarding undefined symbols reference like
> > XUngrabKey, XFree, XStringToKeysym, XFlush...
> >
> > All symbols related to X11 seam to be missing.
> >
> > Does anyone have an idea?
>
> Hello Corentin
>
> Where are those symbols being used? Is it from your application or is it
> from
> some Qt code? If it's from your application, then you probably forgot to
> link
> to the X11 library. Something in the buildsystem changed and your indirect
> dependency is not there any more.
>
> Qt5's GUI libraries, unlike Qt 4 and Qt 6, did not link to libX11. Qt 4
> did
> because it did not have the feature as a plugin; Qt 6 has to do it because
> of
> OpenGL. But because of this, I wouldn't expect to see this problem at all:
> libX11 is in use.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Principal Engineer - Intel DCAI Fleet Engineering and Quality
>
>
>
> ---------- Forwarded message ----------
> From: "Corentin Bacqué-cazenave" <corentin at progaccess.net>
> To: Thiago Macieira <thiago.macieira at intel.com>, interest at qt-project.org
> Cc:
> Bcc:
> Date: Fri, 24 May 2024 00:06:59 +0200
> Subject: Re: [Interest] Undefined symbols when porting from Qt5 to Qt6
>
> Hi,
>
> yes, it's from my application.
>
> So I probably have to link LibX11 in CmakeList.txt, not sure how however :(
>
> Thanks for the help :)
>
> Corentin : expert certifié 2022 et <https://linktr.ee/CoBC1>Sponsor
> <https://github.com/sponsors/nvaccess?sp=CoBC> NVDA, Référent commission
> Cécité & Co et Mandataire CNCPH à la commission Accessibilité Universelle -
> Fédé 100% Handinamique <https://www.handinamique.org/>
> Le 24/05/2024 à 00:01, Thiago Macieira a écrit :
>
> On Thursday 23 May 2024 18:14:01 GMT-3 Corentin Bacqué-cazenave via Interest
> wrote:
>
> Hi,
>
> I'm trying to port an application from Qt5 to Qt6.
>
> I get a lot of errors regarding undefined symbols reference like
> XUngrabKey, XFree, XStringToKeysym, XFlush...
>
> All symbols related to X11 seam to be missing.
>
> Does anyone have an idea?
>
> Hello Corentin
>
> Where are those symbols being used? Is it from your application or is it from
> some Qt code? If it's from your application, then you probably forgot to link
> to the X11 library. Something in the buildsystem changed and your indirect
> dependency is not there any more.
>
> Qt5's GUI libraries, unlike Qt 4 and Qt 6, did not link to libX11. Qt 4 did
> because it did not have the feature as a plugin; Qt 6 has to do it because of
> OpenGL. But because of this, I wouldn't expect to see this problem at all:
> libX11 is in use.
>
>
>
>
>
> ---------- Forwarded message ----------
> From: "David M. Cotter" <dave at kjams.com>
> To: Qt Project <Interest at qt-project.org>
> Cc:
> Bcc:
> Date: Thu, 23 May 2024 15:52:44 -0700
> Subject: [Interest] Update widget geometry BEFORE window shown
> I need to do something like this:
>
> windowP->layout()->updateGeometry(); // causes all widget geometry to
> update
> DoSomethingImportant(windowP->GetWidget(“someWidget”).geometry()); // do
> something with the geometry of a widget (which must be up to date)
> windowP->setGeometry(windowP->GetInitialGeometry()); // pos/size now based
> on the fact that we KNOW the geometry of one of the widgets BEFORE the
> window is shown
> windowP->show(); // only NOW show the window, NOT before now
>
> How do I do something like the first line? Cause all widget geometry
> (Recursively), to know / figure out its size AND position? And this BEFORE
> the window or any widget is “shown” via the windowP->show() command?
>
> Please don’t try to tell me to do it differently. If you don’ know how to
> answer it, please don’t chime in, thanks.
>
> -Dave
>
>
>
> ---------- Forwarded message ----------
> From: Thiago Macieira <thiago.macieira at intel.com>
> To: interest at qt-project.org
> Cc:
> Bcc:
> Date: Thu, 23 May 2024 23:08:34 -0300
> Subject: Re: [Interest] Undefined symbols when porting from Qt5 to Qt6
> On Thursday 23 May 2024 19:06:59 GMT-3 Corentin Bacqué-cazenave via
> Interest
> wrote:
> > So I probably have to link LibX11 in CmakeList.txt, not sure how however
> 🙁
> >
> > Thanks for the help 🙂
>
> https://cmake.org/cmake/help/latest/module/FindX11.html
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Principal Engineer - Intel DCAI Fleet Engineering and Quality
>
>
>
> ---------- Forwarded message ----------
> From: Volker Hilsheimer <volker.hilsheimer at qt.io>
> To: "David M. Cotter" <dave at kjams.com>
> Cc: Qt Project <Interest at qt-project.org>
> Bcc:
> Date: Fri, 24 May 2024 07:38:13 +0000
> Subject: Re: [Interest] Update widget geometry BEFORE window shown
>
>
> On 24 May 2024, at 00:52, David M. Cotter <dave at kjams.com> wrote:
>
> I need to do something like this:
>
> windowP->layout()->updateGeometry(); // causes all widget geometry to
> update
> DoSomethingImportant(windowP->GetWidget(“someWidget”).geometry()); // do
> something with the geometry of a widget (which must be up to date)
> windowP->setGeometry(windowP->GetInitialGeometry()); // pos/size now based
> on the fact that we KNOW the geometry of one of the widgets BEFORE the
> window is shown
> windowP->show(); // only NOW show the window, NOT before now
>
> How do I do something like the first line? Cause all widget geometry
> (Recursively), to know / figure out its size AND position? And this BEFORE
> the window or any widget is “shown” via the windowP->show() command?
>
> Please don’t try to tell me to do it differently. If you don’ know how to
> answer it, please don’t chime in, thanks.
>
> -Dave
>
>
> Hi David,
>
> QLayout::activate should do what you are looking for. And
> QLayout::sizeHint should give you the size the layout would the window to
> have. You might be able to just call windowP->sizeHint() though.
>
> It might depend on what your various functions do, though. If any of them
> changes any widget’s content in such a way that the widget’s sizeHint would
> change (in which case that widget is supposed to call
> QWidget::updateGeometry, which posts a layout requests event), then you are
> back in some asynchronous situation where the processing of events will
> result in the layout activating again, after you showed the window. Forcing
> the processing of QEvent::LayoutRequest with
> QCoreApplication::sendPostedEvents before calling windowP->show() might
> help then. Or you can deactivate the layout, or give windowP a fixed size
> based on its sizeHint, when you are confident that future changes should be
> ignored.
>
>
> Volker
>
>
>
>
> ---------- Forwarded message ----------
> From: coroberti <coroberti at gmail.com>
> To: "David M. Cotter" <dave at kjams.com>
> Cc: Qt Project <Interest at qt-project.org>
> Bcc:
> Date: Fri, 24 May 2024 10:47:48 +0300
> Subject: Re: [Interest] Update widget geometry BEFORE window shown
> David,
> Try
> yourWidget->layout()->update();
> yourWidget->layout()->activate();
>
> If not,
> let the event loop to run, ie. arranging a short timer.
>
> Kind regards,
> Robert Iakobashvili
> ............................
>
> On Fri, May 24, 2024 at 1:53 AM David M. Cotter <dave at kjams.com> wrote:
> >
> > I need to do something like this:
> >
> > windowP->layout()->updateGeometry(); // causes all widget geometry to
> update
> > DoSomethingImportant(windowP->GetWidget(“someWidget”).geometry()); // do
> something with the geometry of a widget (which must be up to date)
> > windowP->setGeometry(windowP->GetInitialGeometry()); // pos/size now
> based on the fact that we KNOW the geometry of one of the widgets BEFORE
> the window is shown
> > windowP->show(); // only NOW show the window, NOT before now
> >
> > How do I do something like the first line? Cause all widget geometry
> (Recursively), to know / figure out its size AND position? And this BEFORE
> the window or any widget is “shown” via the windowP->show() command?
> >
> > Please don’t try to tell me to do it differently. If you don’ know how
> to answer it, please don’t chime in, thanks.
> >
> > -Dave
> > _______________________________________________
> > Interest mailing list
> > Interest at qt-project.org
> > https://lists.qt-project.org/listinfo/interest
>
>
>
>
> ---------- Forwarded message ----------
> From: worldwidestar at sina.com
> To: interest <interest at qt-project.org>
> Cc:
> Bcc:
> Date: Fri, 24 May 2024 17:37:18 +0800
> Subject: [Interest] Support for deployment on iOS 17 devices ?
> Hello.
>
> The lastest release of Qt creator does not support deploying apps on iOS
> 17 device. Currently I have to switch between Xcode and Creator, one for
> deployment and the other for development.
>
> Is it possible to support it in the future?
>
> Thanks.
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20240524/c945a8b5/attachment-0001.htm>
More information about the Interest
mailing list