> On Oct. 28, 2014, 6:09 p.m., Andrea Diamantini wrote:
> > src/application.cpp, line 731
> > <https://git.reviewboard.kde.org/r/120794/diff/3/?file=322475#file322475line731>
> >
> >     It's not clear to me why you chose parse() instead of process() here.
> >     Can you please argument this?
> 
> David Narváez wrote:
>     It would be equivalent to process() because the --help and --version 
> arguments were already handled by the original application if they were 
> present (i.e., the application would have died before requesting our 
> activation).

Moreover, if you were to use process() here, and external entity could "shoot 
your application dead" if it sends --help or --version parameters through the 
right D-Bus call. I guess this is an important point to mention in a porting 
guide.


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120794/#review69318
-----------------------------------------------------------


On Oct. 29, 2014, 1:57 p.m., David Narváez wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120794/
> -----------------------------------------------------------
> 
> (Updated Oct. 29, 2014, 1:57 p.m.)
> 
> 
> Review request for KDE Frameworks and rekonq.
> 
> 
> Repository: rekonq
> 
> 
> Description
> -------
> 
> This is my humble attempt to implement the Unique Mode properly. I have been 
> trying to do this for the longest time in a way that avoids code duplication 
> but I can't find a way to jump over all the hurdles these API impose. I tried 
> learning from other ports from KUniqueApplication but a quick look at LXR 
> shows there are plenty of applications that blindly ported to Unique Mode but 
> didn't bother implementing activateRequested and the one I found that did was 
> plasmawindowedcorona.cpp which does not need a QCommandLineParser, so the 
> code duplication is less evident. At this point, I would like someone who 
> knows about the QCommandLineParser + KDBusAddons dance to look at this and 
> tell if it is reasonable or not.
> 
> The current patch just makes it possible to open several Rekonq applications. 
> It does not do the right thing when a Rekonq window is already open in the 
> current activity and a user clicks a link elsewhere (step 4 in the Testing 
> Done section) because it starts a brand new Rekonq window, but that's a 
> different patch. It also does some funky thing asking you if you want to 
> restore the previous session when nothing has crashed, I have to check that.
> 
> 
> Diffs
> -----
> 
>   src/application.h 7ccd60d 
>   src/application.cpp c7c297d 
>   src/main.cpp 7592f7a 
> 
> Diff: https://git.reviewboard.kde.org/r/120794/diff/
> 
> 
> Testing
> -------
> 
> 1. Open one Rekonq window
> 2. Try opening Rekonq again
> 3. Try opeining Rekonq from a command line with some URLs
> 4. Assuming Reknoq is your default browser (why wouldn't it be?) click on a 
> link somewhere (I click on the links at the title of the Konversation 
> channels I am in)
> 5. Open rekonq from the console using rekonq --incognito
> 6. Open rekonq from the console using reknoq --webapp twitter.com
> 7. Open rekonq from the console pointing it to some local HTML file
> 
> Before this patch, nothing happens in steps 2 - 7. After a first version of 
> this patch that does not avoid the QCommandLine parser if the argument list 
> is not empty, the window opened at 1 crashes because the activateRequested 
> signal passes an empty list of arguments - not even the binary name - so 
> QCommandLine parser dies. With this patch, every step opens a new window 
> properly, step 5 opens an incognito window and step 6 opens a webapp window 
> (simple window). Step 7 opens the current working directory because local URL 
> handling is broken.
> 
> 
> Thanks,
> 
> David Narváez
> 
>

_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Reply via email to