Review Request 111298: Add a URL handler for help:/// urls

[Kevin Ottens]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111298/#review35425
-----------------------------------------------------------



staging/kwidgets/src/urlhandler.cpp
<http://git.reviewboard.kde.org/r/111298/#comment25954>

    Well, this whole block creates such a help:/foo and then calls QDesktopService::openUrl again with the newly built URL.
    
    Which indeed makes me wonder what happens to said URL... Who handles it if it's not in this code?


- Kevin Ottens


On July 1, 2013, 5:13 p.m., Aleix Pol Gonzalez wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/111298/
> -----------------------------------------------------------
> 
> (Updated July 1, 2013, 5:13 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Description
> -------
> 
> Following a task in the kdelibs_cleanup Epics, make it so Qt can properly open help:// urls.
> 
> I added some "magic" query arguments so we can be passed the application in case we want to deprecate KHelpClient::invokeHelp, I'm unsure if we should port the invokeHelp code to call this.
> 
> 
> Diffs
> -----
> 
>   staging/kwidgets/src/CMakeLists.txt e337b81 
>   staging/kwidgets/src/urlhandler.cpp PRE-CREATION 
>   staging/kwidgets/tests/CMakeLists.txt f173b80 
>   staging/kwidgets/tests/openurltest.cpp PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/111298/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130702/45f7fef8/attachment.html>