In the Neon 5 ISO there's an issue with Kwrite & Kate. When you go to re-configure the commands in the toolbar (right click on the toolbar and choose 'Configure toolbars..'), the single main toolbar seems to needlessly be divided up into several 'sub-toolbars' - 3 in Kate and 2 in Kwrite.

To use Kwrite as an example, when the 'Configure toolbars..' dialogue opens the 'Main toolbar <kwrite>' is selected from the drop down at the top of the dialogue and the right hand column shows the commands that will appear in the actual toolbar. By default these are New & Open, then 3 separators, then Close and 3 more separators. You need to change the toolbar being edited to 'Main toolbar <KatePartView>' to see the missing Save, Save as.., Undo & Redo commands but there seems to be no obvious way of dictating exactly where on the toolbar these commands will appear. The position of the default toolbar buttons seems to be fixed & if you add any commands to the 'Main toolbar <KatePartView>' toolbar then they're just tacked onto the right hand end of the toolbar regardless of their order in the 'Configure toolbars..' dialogue.

Here is a screenshot:


This is exactly the same in KDE 4 so my question is whether this is intentional or whether it's a bug that's been carried over to Plasma 5 and should be reported??

This is an artifact of the way Kate and KWrite are implemented: They're both basically shells around KatePart, the actual text editing component (and in Kate, kfiletreeplugin brings its own toolbar). So no, this isn't a bug.
It's one of the cases I describe as "The code is staring you in the face": From a usability POV, of course the implementation details of which toolbar comes from which component in the code should be completely hidden from the user (they don't care at all), but they're not.
I'm not sure if a bug report is the right medium to discuss this, but we sure have to discuss it.
I'll try to find out who to talk to about this.

It's the general KDE's XMLGUI that stabilized in KDElibs 3 times or so. No big changes UX-wise since then.

That said, In other universe:



I'd love to see this analyzed as a solution for every KDE app.

PS: IMO, no reason to expose all these technical-like details to the user. There's and idea of primary and secondary toolbar buried too but each app calls them differently.
Apart from the UX of the editor I am not fan of the "flexibility" of the whole XMLGUI understood this way: by default the toolbars are laid out quite randomly and the look hurts especially on non-maximized windows... XMLGUI is a blessing for developer but it's also utopian idea that the GUI will change automatically based on the context. This thinking comes from the MS Office 97 era. Large apps finally become Eclipse-like monsters with huge menus of merged actions. In KDE Plasma 4 I moved away with Kexi from the XMLGUI: 80% of the actions in menus/toolbars come from plugins. So they were moved to views from the main window. KDevelop was on the same ship and also drifted towards own perspective-based window (inspired by Eclipse it seems).

Yes, this goes in the same direction as I suggested in my "What can we learn from Firefox Australis?" blog post.
That would mean changes not only on the UI side, though, as controls coming from different technical sides (e.g. KatePart and the main Kate/KWrite) would have to be "merged" so users could mix and match between them regardless of their origin.

Personally, I'd just be happy being able to customise the toolbars and control where in the toolbar each icon appears - for that the existing UI is fine!

A suggestion for the future though, if changes are made to this UI - it might be worth tying in with what's being done to the 'Request for a new UI for configuring decoration buttons' thread whilst it's still a work-in-progress (viewtopic.php?f=285&t=123488), if the UI or behaviour could be designed so that it's suitable for both customising window buttons and the toolbars then that would make things feel nice and consistent. The toolbar UI redesign could be left until some other time in the future but when it's done everything will fit together perfectly.

Indeed, setting specific icon positions would be a great feature for our toolbars that has been long missing. It simply often makes sense if we right align a group of icons, center another and keep some actions left. That would make the toolbar more organized, since separators are not the greatest way to visualize groups of actions.

kdeuserk,

I meant just having a bog standard toolbar where you could change the order of the buttons to be exactly as you wanted them, using the existing UI without even realising those buttons might be from different components of the application (as I'd assume it would be).

I quite like the idea of being able to position buttons anywhere on the toolbar - leaving white space between them instead of separators (having them right, centre or left justified could be good). Do you think that it's still needed with the more spacious Breeze theme though??

Would a kind of variable width spacer like you could add to the panel work? I suppose you'd still need a more graphical UI for that though.

This was my second ever blog post I made: http://static.davidedmundson.co.uk/tool ... nge_01.ogv
Given this was when I was very new at C++ I was pretty pleased with it, but I also got stumped by:

as controls coming from different technical sides (e.g. KatePart and the main Kate/KWrite) would have to be "merged" so users could mix and match between them regardless of their origin.

This is not at all easy, and from konqueror's perspective usability wise it means you configure things and then they jump around 'randomly'. It made me give up.

david_edmundson wrote:This was my second ever blog post I made: http://static.davidedmundson.co.uk/tool ... nge_01.ogv

Oh, this looks soo much better than what we have now!

Given this was when I was very new at C++ I was pretty pleased with it, but I also got stumped by:

as controls coming from different technical sides (e.g. KatePart and the main Kate/KWrite) would have to be "merged" so users could mix and match between them regardless of their origin.

This is not at all easy, and from konqueror's perspective usability wise it means you configure things and then they jump around 'randomly'. It made me give up.

I agree: This does not work for toolbars that are shown or hidden depending on the context. Those would have to be separated. However, in the case of Kate, those toolbars are always there and therefore the separation doesn't make sense for users.

So, would it be possible to tell the configuration system which tools are context-dependent and which are permanent?

I realize this is a bit of thread necromancy, but this was pestering me today.

What about instead of katepart implementing a toolbar, kate and kwrite's toolbars could load katepart's toolbar commands? How do-able is that?