[rekonq] Re: Review Request: Changes to the context menu

[Andrea Diamantini]

> On Jan. 17, 2011, 10:18 a.m., Andrea Diamantini wrote:
> > I'm not completely satisfied from this patch. Please, give people time to review code. In example, I'm a bit dubious about the use of the "showDeveloperTools" bit. Shouldn't we use the WebKit "developerExtras" flag instead?
> 
> Benjamin Poulain wrote:
>     Just trying to help. :(
>     If you want to review every patch I think that will not scale. Worse case we can just revert it.
>     
>     I think it makes sense to have it separated from developerExtras because it aslo change the "view page source" action. At the moment, WebKit's developerExtras can be enabled in all cases in my opinion, so you can enable showDeveloperTools without having to reload all the pages.
> 
> Andrea Diamantini wrote:
>     You did it well, Benjamin. 
>     I don't absolutely want to review all patches to be merged, in particular those just debated. I have had just this question about the developer flag and I thought the easiest way was to reopen the request.
>     In fact we have here IMHO same strange behaviors. Let me give you some examples: with showDeveloperTools disabled we don't have dev options on context menu (good) but we have them on rekonq menu (in the development submenu. Good?) . Activating one option from there, WebKit developerExtras is automatically enabled, so that you can see code / inspector / net analyzer, but rekonq showDeveloperTools will remain disabled.
>     I think this opens some options and I thought about this in the morning but I couldn't decide what is better:
>     1) use just WebKit developerExtras flag. This will be enabled/disabled on the settings menu and while activating the developer options.
>     2) remove also developer submenu from rekonq menu when showDeveloperTools is disabled.
>     3) maintain code as is, adding extrachecks during webview context menu creation to show dev tools when either showDeveloperTools and developerExtras are set.
>     
>     In case 2) & 3), I think the setting should be removed from the webkit group and added into a misc one.
>     
>     What do you guys think?
> 
> Benjamin Poulain wrote:
>     I use the main menu so little that I actually never saw there was developer tools there as well. You are right, they should be disabled there as well. :)
>     
>     I am not sure it is worth disabling developerExtras ever. The overhead is low on Desktop. Enabling it and disabling it at runtime will require reload of pages to have everything working.

uhm.. let me understand. You are actually saying we can load and use the inspector without setting the developerExtras flag on?


- Andrea


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


On Jan. 14, 2011, 10:08 p.m., Felix Rohrbach wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/100374/
> -----------------------------------------------------------
> 
> (Updated Jan. 14, 2011, 10:08 p.m.)
> 
> 
> Review request for rekonq.
> 
> 
> Summary
> -------
> 
> This patch contains the changes to the context menu which we decided in our meeting:
> 
> 1. Hide new tab entry if it is not necessary.
> 2. Print and Search action: I removed the print action. The search action is now in the "search with" submenu if some text is selected.
> 3. Hide the development menu entries and add an option to show them.
> 
> Clone: git://anongit.kde.org/clones/rekonq/felixr/rekonq
> Branch: meetingMenuChanges
> 
> 
> Diffs
> -----
> 
>   src/mainwindow.h 7dfc186 
>   src/mainwindow.cpp 599295f 
>   src/rekonq.kcfg cda76d8 
>   src/settings/settings_webkit.ui 58fbe45 
>   src/webview.cpp 49fa103 
> 
> Diff: http://git.reviewboard.kde.org/r/100374/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Felix
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/rekonq/attachments/20110117/0d411660/attachment-0001.htm