Review Request 129261: Hide the "Show Menu Bar" action if all the menubars are native

[David Faure]

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




src/kstandardaction.cpp (line 84)
<https://git.reviewboard.kde.org/r/129261/#comment68072>

    override



src/kstandardaction.cpp (line 105)
<https://git.reviewboard.kde.org/r/129261/#comment68073>

    If this code is called twice (e.g. because a window is shown/hidden/shown), then it will overwrite the old value of wasChecked with "true".
    
    If the point of all this is to toggle between the mode "all menu bars are native" and the opposite (at least one menu bar is not native), then you need a bool that remembers in which mode you were in, at the last time the event filter was called, in order to detect when you're actually switching modes.
    
    Ah, that's actually your wasNative bool. So all that is missing is to change the conditions to
    
    if (allMenuBarsNative && !wasNative) {
      ..
    } else if (!allMenuBarsNative && wasNative) {
      ..
    }
    
    => if you're not changing modes, nothing should happen.



src/kstandardaction.cpp (line 199)
<https://git.reviewboard.kde.org/r/129261/#comment68074>

    If an application creates many "show menu bar" actions, e.g. one per window in a many-windows process, then it will end up with many event filters (a somewhat costly construct).
    
    I'm wondering if this shouldn't be a singleton, where you register all the show-menubar QActions, so that it can handle them all in one go. To handle removal, it would mean connecting to the destroyed() signal of the action in order to remove it from the list.
    
    Hmm, on the other hand, storing wasChecked and wasVisible for every action becomes a bit cumbersome (QMap or dynamic properties).
    
    So maybe ignore this. Just food for thought.



src/kstandardaction.cpp (line 204)
<https://git.reviewboard.kde.org/r/129261/#comment68075>

    Isn't there some missing code to handle the initial state of the action? I'm wondering about a sequence like
    
    - show mainwindow
    - create show menubar action, for instance in a context menu
    
    => the initial state of the action will not be set.
    
    You could extract most of the event filter code into a separate method and call it from here.


- David Faure


On Dec. 28, 2016, 10:47 p.m., Albert Astals Cid wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129261/
> -----------------------------------------------------------
> 
> (Updated Dec. 28, 2016, 10:47 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kconfigwidgets
> 
> 
> Description
> -------
> 
> Some applications have a "Show Menu Bar" action that is a bit silly on systems where the menubar is part of the shell (for example Unity 7).
> 
> This patch attempts to fix it by iterating all the main windows when they are shown and if all the menubars of all mainwindows are native, then hides the show menu bar action (basically erasing it from existence).
> 
> It's not the nicest of the codes and probably has some edge cases but works on the general case so i think it's worth the effort.
> 
> 
> Diffs
> -----
> 
>   src/kstandardaction.cpp 89d011e 
> 
> Diff: https://git.reviewboard.kde.org/r/129261/diff/
> 
> 
> Testing
> -------
> 
> Tried konsole, kate and dolphin under Unity 7 on Ubuntu 16.10
> 
> konsole and kate work fine (i.e. the action is gone from the menus and all is good)
> 
> dolphin is not 100% "perfectly behabed" (i.e. the "control" toolbar item is supposed to not be shown when menubars are shown and in this case it's shown) but it's not a regression and imho it's the dolphin code being a bit weird (i can propose a patch for it if this gets accepted)
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20161229/9c019fb6/attachment.html>