Bug 36318 - QtLauncher doesn't start when using Qt/QWS
Summary: QtLauncher doesn't start when using Qt/QWS
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-18 12:39 PDT by Anders Bakken
Modified: 2010-03-22 15:56 PDT (History)
3 users (show)

See Also:


Attachments
This patch fixes the bug #36318 (1.13 KB, patch)
2010-03-18 12:49 PDT, Anders Bakken
no flags Details | Formatted Diff | Diff
Updated patch for 36318 (1.14 KB, patch)
2010-03-18 13:40 PDT, Anders Bakken
hausmann: review+
commit-queue: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Anders Bakken 2010-03-18 12:39:35 PDT
Qt/QWS apps need to run as GuiServer when running standalone. The app needs to either pass -qws or pass QApplication::GuiServer to the QApplication constructor.
Comment 1 Anders Bakken 2010-03-18 12:49:31 PDT
Created attachment 51074 [details]
This patch fixes the bug #36318
Comment 2 Simon Hausmann 2010-03-18 13:02:53 PDT
No objection from me, just curious: Why not pass -qws on the commandline? Or is that a recently changing trend in qws apps to not require it anymore but instead use this flag?
Comment 3 Simon Hausmann 2010-03-18 13:03:36 PDT
Comment on attachment 51074 [details]
This patch fixes the bug #36318


>  LauncherApplication::LauncherApplication(int& argc, char** argv)
> -    : QApplication(argc, argv)
> +    : QApplication(argc, argv
> +#ifdef Q_WS_QWS
> +                   , QApplication::GuiServer
> +#endif
> +    )
>      , m_isRobotized(false)
>  {

Is the #ifdef worth it? Why not always pass GuiServer?
Comment 4 Anders Bakken 2010-03-18 13:36:43 PDT
(In reply to comment #2)
> No objection from me, just curious: Why not pass -qws on the commandline? Or is
> that a recently changing trend in qws apps to not require it anymore but
> instead use this flag?

Mostly because I didn't easily understand how to add arguments to the scripts that run the launcher (webkit-tests etc). It seemed like it requires hacking perl code.
Comment 5 Anders Bakken 2010-03-18 13:37:58 PDT
(In reply to comment #3)
> (From update of attachment 51074 [details])
> 
> >  LauncherApplication::LauncherApplication(int& argc, char** argv)
> > -    : QApplication(argc, argv)
> > +    : QApplication(argc, argv
> > +#ifdef Q_WS_QWS
> > +                   , QApplication::GuiServer
> > +#endif
> > +    )
> >      , m_isRobotized(false)
> >  {
> 
> Is the #ifdef worth it? Why not always pass GuiServer?

No reason. I am fine with changing that. It's a noop on desktop anyway.
Comment 6 Anders Bakken 2010-03-18 13:40:08 PDT
Created attachment 51086 [details]
Updated patch for 36318
Comment 7 Simon Hausmann 2010-03-18 13:57:32 PDT
Comment on attachment 51086 [details]
Updated patch for 36318

Thanks Anders :)
Comment 8 WebKit Commit Bot 2010-03-18 22:28:01 PDT
Comment on attachment 51086 [details]
Updated patch for 36318

Rejecting patch 51086 from commit-queue.

Found no modified ChangeLogs, cannot create a commit message.
All changes require a ChangeLog.  See:
http://webkit.org/coding/contributing.html
Comment 9 Simon Hausmann 2010-03-19 00:20:26 PDT
Committed r56222: <http://trac.webkit.org/changeset/56222>
Comment 10 Eric Seidel (no email) 2010-03-22 12:35:07 PDT
@simon:

There was a bug in the ChangeLog, which is why the queue rejected it. You didn't correct it when you landed either. :(

double >> in the date line.
Comment 11 Simon Hausmann 2010-03-22 15:56:40 PDT
(In reply to comment #10)
> @simon:
> 
> There was a bug in the ChangeLog, which is why the queue rejected it. You
> didn't correct it when you landed either. :(
> 
> double >> in the date line.

Oops! Indeed, the name appeared twice with too many angle brackets. Fixed up in r56364.

/me bows low to the bot and his/her master