[Differential] [Commented On] D2958: QtCreator-style "Focus Editor or Hide Docks"

antonanikin (Anton Anikin) noreply at phabricator.kde.org
Fri Oct 28 12:55:29 UTC 2016


antonanikin added a comment.


  > - you call that QtCreator style. I'd say we can find a more meaningful name than that.
  
  Ok, I will think about new name. Suggestions are welcome :)
  
  > - View shortcuts toggle: 2 states (visible, hidden) instead of 3 (visible, focused, hidden).
  >   - would it maybe make sense to just make the 2 states the new default? We can have some discussion WRT how people should give a toolview the focus and what are the use-cases.
  
  Maybe I misunderstood you, correct me please. I think we should have 3 states:
  
  1. focused - when we open some tool view (with shortcut or "by hand" (mouse click)) we should focus it to do something inside. For example if we show context help it seems to be useful to focus help page for scroll, find, etc with keyboard.
  
  2. unfocused - when we return to editor, tool view lost focus, but don't closed.
  
  3. hidden - when we use some mechanism for close tool view.
  
  New behavior uses all 3 states. If we focused inside some tool view and run new "focus or hide" action we go to the editor and tool view will be unfocused. Second action run will close (hide) all unlocked tool views.
  
  > - I see why you want it but I really think it's a corner use-case. I haven't seen a bug report complaining about it. I suggest moving the action to the context menu at least, so we can have some text explaining what it does and so it doesn't add clutter.
  
  Ok, but for which element we should add such context menu item? Adding it for each tool view seems to be an "overhead" and produce user's confusing. Adding it to whole dock can leads to situation, when we have too many toolviews on some side, which hides dock panel and also "hides" panel's context menu. Maybe we should adds such settings to KDevelop config page? I think "blocking/unblocking" sides is not so frequent operation and this way may be preferable.

REPOSITORY
  rKDEVPLATFORM KDevPlatform

REVISION DETAIL
  https://phabricator.kde.org/D2958

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: antonanikin, #kdevelop
Cc: apol, kdevelop-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20161028/a42d00ae/attachment.html>


More information about the KDevelop-devel mailing list