There shouldn't be any Breeze specific code in client apps. It's a sign of something being wrong.

What's a navigation style toolbutton and where do you want to use this?

In D20867#457570, @davidedmundson wrote:

There shouldn't be any Breeze specific code in client apps. It's a sign of something being wrong.

What's a navigation style toolbutton and where do you want to use this?

It is this patch D19311 that has been driving this change. If you have suggestions for a better way to solve this it would be more than welcome :D

QToolButton::setArrowType?

In D20867#457575, @davidedmundson wrote:

QToolButton::setArrowType?

I just tried that, but it doesn't seem like Breeze honors this property - at least not for the QToolButton produced by KToolBarPopupAction. So adding

button->setArrowType(Qt::ArrowType::NoArrow);

to

QWidget *KToolBarPopupAction::createWidget(QWidget *_parent)

still display the arrows :/ Or am I doing something wrong?

In D20867#457575, @davidedmundson wrote:

QToolButton::setArrowType?

After reading the documents and experimenting a bit, I think that this property is not what we are looking for. The Arrow Type property is to display the Tool Button as an arrow instead of an icon and this is not what we use to draw the down arrow indicator on Tool Buttons with a popup menu, instead this is drawn "directly" by Breeze.

In D20867#457580, @hallas wrote:

In D20867#457575, @davidedmundson wrote:

QToolButton::setArrowType?

I just tried that, but it doesn't seem like Breeze honors this property - at least not for the QToolButton produced by KToolBarPopupAction. So adding

That's probably a breeze bug and that's where it should be addressed.
an application can't link to breeze, especially if is private api. (and would explode dependencies in distros package managers)

In D20867#461499, @mart wrote:

In D20867#457580, @hallas wrote:

In D20867#457575, @davidedmundson wrote:

QToolButton::setArrowType?

I just tried that, but it doesn't seem like Breeze honors this property - at least not for the QToolButton produced by KToolBarPopupAction. So adding

That's probably a breeze bug and that's where it should be addressed.
an application can't link to breeze, especially if is private api. (and would explode dependencies in distros package managers)

@mart - I am not sure I follow? I think the QToolButton::ArrowType is intended for something else then what we are trying to do here. I am not trying to make any application depend directly on breeze. Instead these properties are loosely coupled, so an application setting a property doesn't impose that the application needs to link with breeze. It is simply a hint to the style.

With that being said, I am certainly open to other ways of solving this problem, so feel free to pinch in ;)

Hi @ngraham - any update on this one? Should we move forward with this approach or should we do something else?

Actually maybe it just needs a rebase on master...

In D20867#482950, @ngraham wrote:

Actually maybe it just needs a rebase on master...

Let me give it a rebase then :D

Hi @ngraham - I have looked into this patch set and it is a little tedious to test, you have to do the following:

1. Apply the following patch to KWidgetAddons F6773036 then build and install it
2. Apply this patch to breeze then build and install it
3. Apply D19311 to Dolphin
4. Then make the following changes to Dolphin:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index ef0e28e76..a86256950 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -65,6 +65,7 @@ find_package(KF5 ${KF5_MIN_VERSION} REQUIRED COMPONENTS
     Notifications
     Crash
     WindowSystem
+    WidgetsAddons
 )
 find_package(KF5 ${KF5_MIN_VERSION} OPTIONAL_COMPONENTS
     Activities
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 8a025e584..80a767aa9 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -148,6 +148,7 @@ target_link_libraries(
     KF5::ConfigCore
     KF5::NewStuff
     KF5::Parts
+    KF5::WidgetsAddons
     KF5::WindowSystem
 )
 
diff --git a/src/dolphinmainwindow.cpp b/src/dolphinmainwindow.cpp
index 1f1c1cea6..80db0bbe9 100644
--- a/src/dolphinmainwindow.cpp
+++ b/src/dolphinmainwindow.cpp
@@ -1292,6 +1292,7 @@ void DolphinMainWindow::setupActions()
     }
     m_backAction->setDelayed(true);
     m_backAction->setStickyMenu(false);
+    m_backAction->setMenuIndicator(false);
     connect(m_backAction, &QAction::triggered, this, &DolphinMainWindow::goBack);
     connect(m_backAction->menu(), &QMenu::aboutToShow, this, &DolphinMainWindow::slotAboutToShowBackPopupMenu);
     connect(m_backAction->menu(), &QMenu::triggered, this, &DolphinMainWindow::slotGoBack);
@@ -1327,6 +1328,7 @@ void DolphinMainWindow::setupActions()
     }
     m_forwardAction->setDelayed(true);
     m_forwardAction->setStickyMenu(false);
+    m_forwardAction->setMenuIndicator(false);
     connect(m_forwardAction, &QAction::triggered, this, &DolphinMainWindow::goForward);
     connect(m_forwardAction->menu(), &QMenu::aboutToShow, this, &DolphinMainWindow::slotAboutToShowForwardPopupMenu);
     connect(m_forwardAction->menu(), &QMenu::triggered, this, &DolphinMainWindow::slotGoForward);

then build and install Dolphin, and then (phew) you should be able to see that the arrows are gone :D

I have also rebased this patch.

But if we agree to how this feature is implemented, I would suggest that we get this patch merged, then merge the patch for KWidgetAddons, and then when those two has been released, we merge the patch for Dolphin.

What do you think?

Here is a screenshot of how it looks with everything applied:

Sorry for the delayed response! Let me block out some time to give it a whirl. I am left wondering if there's any simpler way we can do it though. KWidgetsAddons, Breeze, and Dolphin each have different release cycles, so making sure everything gets in at the right time and things work without other bits already present may be challenging.