> On 13 Dec 2016, at 14:51, Edward Welbourne wrote:
>
> Morten Sorvig supplied:
>
>> For some background, here’s what typical application startup looks
>> like on macOS, NaCl, and Emscripten:
>
> I've updated [0] to illustrate these.
> [0] https://wiki.qt.io/Application_Start-up_Patterns
Than
On 2016-12-09 19:43, Thiago Macieira wrote:
> Em sexta-feira, 9 de dezembro de 2016, às 16:50:29 PST, Matthew Woehlke
> escreveu:
>> On 2016-12-09 16:23, Thiago Macieira wrote:
>>> That's a valid concern, but not one that warrants a QApplication subclass.
>>
>> Right; that one is an issue if the u
Morten Sorvig supplied:
> For some background, here’s what typical application startup looks
> like on macOS, NaCl, and Emscripten:
I've updated [0] to illustrate these.
[0] https://wiki.qt.io/Application_Start-up_Patterns
> macOS: Define the application delegate, create instance of it in main()
quite easy I think.
Simon
From: Simon Hausmann
Sent: Tuesday, December 13, 2016 11:24:48 AM
To: Laszlo Agocs; Mathias Hasselmann; development@qt-project.org
Subject: Re: [Development] A new approach for Qt main()
Hi,
I don't think it does handle those
__
From: Laszlo Agocs
Sent: Tuesday, December 13, 2016 10:42:05 AM
To: Simon Hausmann; Mathias Hasselmann; development@qt-project.org
Subject: RE: [Development] A new approach for Qt main()
Hi,
How does this handle the cases that need code before the QGuiApplicatio
; development@qt-project.org
Subject: Re: [Development] A new approach for Qt main()
Hi,
The joke of the bikeshedding aside I for one do like the idea of exporting a
QObject sub-class instead of a function. That makes it easier to extend in the
future with more entry-points as slots for
Mathias Hasselmann
Sent: Monday, December 12, 2016 7:53:50 PM
To: development@qt-project.org
Subject: Re: [Development] A new approach for Qt main()
Hi,
Seems this turned into a nice bike shed discussion quickly, so let me
use the chance to present my preferred Qt main(). I am totally convinced
that
Em segunda-feira, 12 de dezembro de 2016, às 21:12:31 PST, Morten Sorvig
escreveu:
> > Can we get a description of what those problems are, for those of us who
> > have never developed anything for those OSes, so we're not discussing
> > things in the abstract?
>
> For some background, here’s wh
> On 10 Dec 2016, at 01:43, Thiago Macieira wrote:
>
> Em sexta-feira, 9 de dezembro de 2016, às 16:50:29 PST, Matthew Woehlke
> escreveu:
>> On 2016-12-09 16:23, Thiago Macieira wrote:
>>> Em sexta-feira, 9 de dezembro de 2016, às 15:28:13 PST, Matthew Woehlke
>>>
>>> escreveu:
I can wor
> On 9 Dec 2016, at 18:05, Thiago Macieira wrote:
>
> Em sexta-feira, 9 de dezembro de 2016, às 10:44:24 PST, Lars Knoll escreveu:
>> Well, the problem is that the main() entry point is causing huge amounts of
>> issues on at least Android and iOS. We’d help those platforms a lot if we
>> didn’t
Hi,
Seems this turned into a nice bike shed discussion quickly, so let me
use the chance to present my preferred Qt main(). I am totally convinced
that this one should rule the Qt world:
class BlueBikeShedApplication : public QApplication
{
Q_OBJECT
public:
using
On segunda-feira, 12 de dezembro de 2016 16:11:07 PST Edward Welbourne wrote:
> I haven't seen an actual reply to that, but these fragments at least
> point towards a sketch of the reply:
We already have a solution for those cases and that's
QAbstractEventDispatcher.
--
Thiago Macieira - thiago
On segunda-feira, 12 de dezembro de 2016 11:07:56 PST Benjamin TERRIER wrote:
> 2016-12-12 10:56 GMT+01:00 Mark De Wit :
> > I have an application based on qt-solutions qtwinmigrate sample.
> >
> > Because we're integrating Qt into an existing MFC application, we're not
> > even running QApplicati
Em sexta-feira, 9 de dezembro de 2016, às 10:44:24 PST, Lars Knoll escreveu:
> Well, the problem is that the main() entry point is causing huge
> amounts of issues on at least Android and iOS. We’d help those
> platforms a lot if we didn’t support this kind of entry point (on
> thos
12.12.2016, 13:08, "Benjamin TERRIER" :
> 2016-12-12 10:56 GMT+01:00 Mark De Wit :
>> I have an application based on qt-solutions qtwinmigrate sample.
>>
>> Because we're integrating Qt into an existing MFC application, we're not
>> even running QApplication exec. The application uses MFC's en
2016-12-12 10:56 GMT+01:00 Mark De Wit :
> I have an application based on qt-solutions qtwinmigrate sample.
>
> Because we're integrating Qt into an existing MFC application, we're not even
> running QApplication exec. The application uses MFC's entry point for
> startup and drives the Qt event
MFC event loop.
Mark
-Original Message-
From: Development
[mailto:development-bounces+mark.dewit=iesve@qt-project.org] On Behalf Of
Thiago Macieira
Sent: 10 December 2016 00:43
To: development@qt-project.org
Subject: Re: [Development] A new approach for Qt main()
Em sexta-feira, 9
Em sexta-feira, 9 de dezembro de 2016, às 16:50:29 PST, Matthew Woehlke
escreveu:
> On 2016-12-09 16:23, Thiago Macieira wrote:
> > Em sexta-feira, 9 de dezembro de 2016, às 15:28:13 PST, Matthew Woehlke
> >
> > escreveu:
> >> I can work around that, though it's obnoxious. I'm more concerned abou
On 2016-12-09 16:23, Thiago Macieira wrote:
> Em sexta-feira, 9 de dezembro de 2016, às 15:28:13 PST, Matthew Woehlke
> escreveu:
>> I can work around that, though it's obnoxious. I'm more concerned about
>> not being able to tinker with the CLI arguments before Qt gets them.
>
> That's a valid c
Em sexta-feira, 9 de dezembro de 2016, às 15:28:13 PST, Matthew Woehlke
escreveu:
> I can work around that, though it's obnoxious. I'm more concerned about
> not being able to tinker with the CLI arguments before Qt gets them.
That's a valid concern, but not one that warrants a QApplication subcl
On 2016-12-09 12:10, Thiago Macieira wrote:
> Em sexta-feira, 9 de dezembro de 2016, às 11:10:15 PST, Matthew Woehlke
> escreveu:
>> Also, how does this work if someone wants to subclass Q*Application?
>> (Again, I have projects that do that...)
>
> But why do they do that?
...because I have a n
Em sexta-feira, 9 de dezembro de 2016, às 20:13:57 PST, Konstantin Tokarev
escreveu:
> 09.12.2016, 20:11, "Thiago Macieira" :
> > Em sexta-feira, 9 de dezembro de 2016, às 11:10:15 PST, Matthew Woehlke
> >
> > escreveu:
> >> Also, how does this work if someone wants to subclass Q*Application?
09.12.2016, 20:11, "Thiago Macieira" :
> Em sexta-feira, 9 de dezembro de 2016, às 11:10:15 PST, Matthew Woehlke
> escreveu:
>> Also, how does this work if someone wants to subclass Q*Application?
>> (Again, I have projects that do that...)
>
> But why do they do that?
To override virtua
Em sexta-feira, 9 de dezembro de 2016, às 11:10:15 PST, Matthew Woehlke
escreveu:
> Also, how does this work if someone wants to subclass Q*Application?
> (Again, I have projects that do that...)
But why do they do that?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect -
Em sexta-feira, 9 de dezembro de 2016, às 10:44:24 PST, Lars Knoll escreveu:
> Well, the problem is that the main() entry point is causing huge amounts of
> issues on at least Android and iOS. We’d help those platforms a lot if we
> didn’t support this kind of entry point (on those platforms) anymo
On 2016-12-09 04:35, Morten Sorvig wrote:
> We should consider changing the way Qt initialization and startup works.
> This is something I’ve personally been wanting to do for some time, and
> a recent offline discussion pushed it on my stack again.
>
> Currently, Qt and application startup looks
> On 9 Dec 2016, at 14:51, Andre Poenitz wrote:
>
>
> Whatever the problem is, I think we should try hard to have a solution
> that 1. does not use macros and 2. that does not optically change the
> int main(int argc, char *argv[]) { QApplication app(argc, argv)... } stanza.
This sounds like
> On 9 Dec 2016, at 11:41, Laszlo Agocs wrote:
>
>
> Special macros for straightforward applications on exotic systems? Sure.
> Forcing an unnecessary change on existing and future applications on
> platforms that are doing just fine (i.e. the majority)? No.
>
>
> Also, if migration fo
> On 9 Dec 2016, at 12:11, Laszlo Agocs wrote:
>
> There are two separate things in there, though: the entry point and the
> construction of the Q(Core|Gui)Application object. The problem is with the
> latter: is it not clear why Morten’s proposal moves that under the
> framework’s control. I
opment on
behalf of Lars Knoll
Sent: Friday, December 9, 2016 11:44 AM
To: Simon Hausmann; Friedemann Kleint; development@qt-project.org
Subject: Re: [Development] A new approach for Qt main()
Well, the problem is that the main() entry point is causing huge amounts of
issues on at least Android
On 09/12/2016 14:10, Jake Petroules wrote:
Again, I think you're missing Lars' point - "causing huge amount of
issues" doesn't necessarily mean that we are constantly finding and
fixing issues every week - in this context it means "the fact that we
have a workaround at all", i.e. a suboptimal sol
On vineri, 9 decembrie 2016 12:58:46 EET Eskil Abrahamsen Blomfeldt wrote:
> Den 09.12.2016 12:40, skrev Tor Arne Vestbø:
> > On 09/12/2016 11:44, Lars Knoll wrote:
> >> Well, the problem is that the main() entry point is causing huge amounts
> >> of issues on at least Android and iOS.
> >
> > I d
> On Dec 9, 2016, at 5:02 AM, Tor Arne Vestbø wrote:
>
> On 09/12/2016 12:49, Jake Petroules wrote:
>>> On Dec 9, 2016, at 3:40 AM, Tor Arne Vestbø
>>> wrote:
>>>
>>> On 09/12/2016 11:44, Lars Knoll wrote:
Well, the problem is that the main() entry point is causing huge
amounts of is
On 09/12/2016 12:58, Eskil Abrahamsen Blomfeldt wrote:
Den 09.12.2016 12:40, skrev Tor Arne Vestbø:
On 09/12/2016 11:44, Lars Knoll wrote:
Well, the problem is that the main() entry point is causing huge amounts
of issues on at least Android and iOS.
I don't know about Android, but on iOS thi
On 09/12/2016 12:49, Jake Petroules wrote:
On Dec 9, 2016, at 3:40 AM, Tor Arne Vestbø
wrote:
On 09/12/2016 11:44, Lars Knoll wrote:
Well, the problem is that the main() entry point is causing huge
amounts of issues on at least Android and iOS.
I don't know about Android, but on iOS this is
Den 09.12.2016 12:40, skrev Tor Arne Vestbø:
On 09/12/2016 11:44, Lars Knoll wrote:
Well, the problem is that the main() entry point is causing huge amounts
of issues on at least Android and iOS.
I don't know about Android, but on iOS this is patently false. While
the workaround is complex,
> On Dec 9, 2016, at 3:40 AM, Tor Arne Vestbø wrote:
>
> On 09/12/2016 11:44, Lars Knoll wrote:
>> Well, the problem is that the main() entry point is causing huge amounts
>> of issues on at least Android and iOS.
>
> I don't know about Android, but on iOS this is patently false. While the
> w
On 09/12/2016 11:44, Lars Knoll wrote:
Well, the problem is that the main() entry point is causing huge amounts
of issues on at least Android and iOS.
I don't know about Android, but on iOS this is patently false. While the
workaround is complex, it has worked very well in the 3 years since it
Hi,
from the Windows POV, support for wmain() with wide arguments would be a
nice thing to have (see https://bugreports.qt.io/browse/QTBUG-46118 ):
int wmain( int argc, wchar_t *argv[ ], wchar_t *envp[ ] )
Maybe that can be implemented by some smart modularization.
Regards,
Friedemann
--
Fr
To: Lars Knoll
Cc: Qt Project Development Mailing-List
Subject: Re: [Development] A new approach for Qt main()
Does this relates to moving Qt main loop to a different thread other than the
main thread? Cause currently creating the QtApp from a different thread causes
problems. In particular the
st on the platforms where this is
> problematic.
>
>
>
> Cheers,
>
> Lars
>
>
>
> *From: *Development
> on behalf of Simon Hausmann
> *Date: *Friday, 9 December 2016 at 11:17
> *To: *Friedemann Kleint , Qt development mailing
> list
> *Subject: *Re
alf of Friedemann Kleint
Sent: Friday, December 9, 2016 11:00:00 AM
To: development@qt-project.org
Subject: Re: [Development] A new approach for Qt main()
Hi,
> Q_GUI_MAIN(appInit, appExit);
Magic macros for main should be avoided, IMO.
A typical application main() can look like
int ; development@qt-project.org
Subject: Re: [Development] A new approach for Qt main()
Yes, and we will forever (?) support that kind of main function and application
entry point. I don't think that we can break that.
I'm all interested in supporting a second supported way of descri
eint
Sent: Friday, December 9, 2016 11:00:00 AM
To: development@qt-project.org
Subject: Re: [Development] A new approach for Qt main()
Hi,
> Q_GUI_MAIN(appInit, appExit);
Magic macros for main should be avoided, IMO.
A typical application main() can look like
main()
{
QApplication a
Hi,
> Q_GUI_MAIN(appInit, appExit);
Magic macros for main should be avoided, IMO.
A typical application main() can look like
main()
{
QApplication a();
Initialization code for other libraries
parseArguments(), return if failed
show some FileDialog prompting for argument if
Without getting too much into the technical details, I'm all for it in
principle. It would certainly help on iOS especially as there's a lot of
complexity for the main() situation there, which is made even worse by trying
to support dynamic libraries.
Can you give an example of what the definit
Hi,
We should consider changing the way Qt initialization and startup works.
This is something I’ve personally been wanting to do for some time, and
a recent offline discussion pushed it on my stack again.
Currently, Qt and application startup looks something like this:
int main(int argc, char
47 matches
Mail list logo
