D19311: Add navigation history to forward/back buttons

[David Hallas]

hallas added a comment.


  In D19311#526881 <https://phabricator.kde.org/D19311#526881>, @felixernst wrote:
  
  > In D19311#508519 <https://phabricator.kde.org/D19311#508519>, @hallas wrote:
  >
  > > We have previously discussed various ways to simplify this change, but no other suitable solutions has been found, but I am still open to simpler solutions :)
  >
  >
  > This is what I think can produce the wanted behaviour:
  >  KToolBarPopupAction uses QToolButton internally so Indicators are drawn (because of style rules if I understand correctly). If there is no way to use QToolButton and hide indicators without forcing style changes (which was blocked) then it seems to me like the only way forward is //not// using a QToolButton.
  >  AFAICT there are two ways forward:
  >
  > - Further modify KToolBarPopupAction to not use QToolButton internally in the case of menuIndicator being turned off and instead internally implement the same behaviour using some other button class. The QAbstractButton with it's pressed and clicked signals might be enough to handle it but there are possibly more fitting specialised button classes. This way no changes to the Breeze style or any other style for that matter should be necessary.
  > - It might be a bit difficult to imitate the behaviour of KToolBarPopupAction without using a QToolButton so alternatively it might be easier to not modify KToolBarPopupAction at all and create or use a different class. In this case you don't have to mimic all options of KToolBarPopupAction perfectly since it is expected that the new class behaves differently. You could then copy from/use Falkon's NavigationBarToolButton <https://cgit.kde.org/falkon.git/tree/src/lib/navigation/navigationbartoolbutton.cpp> (like @david.fontanals suggested in D19311#432597 <https://phabricator.kde.org/D19311#432597>) . I'm pretty sure the license of that class is incompatible with frameworks though so that would have to be handled if it's supposed to land in KWidgetAddons.
  >
  >   Take my analysis with a grain of salt though since it is mainly based on me reading documentation without having ever actually tried similar stuff.
  
  
  Thanks for the analysis :) I still think we should get the change in with the current KToolBarPopupAction functionality (like Nate suggest), and then work on refining the user experience. But feel free to pinch in on the user experience part.

REPOSITORY
  R318 Dolphin

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

To: hallas, #dolphin, ngraham, elvisangelaccio, #vdg
Cc: felixernst, nerdopolist, mart, richardl, ognarb, david.fontanals, abetts, kfm-devel, iasensio, fprice, MrPepe, fbampaloukas, alexde, Codezela, feverfew, meven, spoorun, navarromorales, firef, andrebarros, emmanuelp, mikesomov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20190907/835e13cb/attachment.htm>