Summary: | Settings - Configure Toolbars panel unlike actual Toolbar, and gripes. | ||
---|---|---|---|
Product: | [Unmaintained] kdelibs | Reporter: | LaChenal <bIllachenal> |
Component: | kdeui | Assignee: | kdelibs bugs <kdelibs-bugs> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | Git | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
Kate gui ConfigureToolbars against actual toolbar
Kate config toolbar agaist actual toolbar |
Comment on attachment 76221 [details]
Kate gui ConfigureToolbars against actual toolbar
file:///home/mint/Documents/Kate Toolbahs.png
Created attachment 76222 [details]
Kate config toolbar agaist actual toolbar
Is this a kdelibs issue? Thanks, Dominik kdelibs? I couldn't say! I thought I had set it to product "kate". I have again set it to "kate". This was at kate 3.8.3: it seems the version has moved on. I'm not using kde just now so I'm marking it as the 3.8. latest My apologies if it has been looked at in the interim. LaCenal, I wanted to get feedback from kdelibs developers, not that you reassign it to Kate. Anyway: I'm not sure I get what you are talking about. Is this a bug? Can you please say in precisely in few words what you want? Thanks, Dominik,
If you think it's a bug at the kdelibs level, perhaps you could register it as a kdelibs bug & link it here.
I'm just reporting the bug the kate user sees.
Did you mean to say "I think this is a kdelibs issue because..." ?
Do you believe it's a kdelibs issue?
It certainly is a kate issue at the surface. That's where I would search for it.
It may indeed be deeper than kate, whatever is constructing the gui.
I thought I had registered it as kate bug (or that it was auto-registered as such), since that's where I came from ("report bug" button, if memory serves).
Is it a bug? Yes, it's a bug.
DESCRIPTION OF BUG STARTS AT TOP, HERE. Plz read. (soory, caps lock got stuck.)
Whatever, it's been there a while, I've seen it before though I was only now moved to report it since I thought it would be picked up sooner (by the kate devs).
".. what you want?"
What I would like to see instead is a correct correspondence between kate gui's actual toolbar and the (Settings - Configure Toolbars) panel that purports to configure that toolbar.
The discrepancy at time of reporting is explicit in the attachment 2013 [details]-01-06 00:46.
Look at that. See the kate toolbar. See the configuration default.
You will see an "open" specified in first position (position zero?), which never appears in kate's surface gui.
Then the default installation has three separators - only one appears.
Then look at the toolbar, see <back >forward etc - none of which is in the configure panel.
You know, I'd expect the toolbar to conform with the toolbar-configuration, as a sort of general policy.
It doesn't.
That's the bug (in kate, not in the general policy).
The other gripes I've detailed above for any dev that's interested.
This is a kdelibs issue, since toolbar merging of part and host app is done there. *** This bug has been marked as a duplicate of bug 315430 *** |
Created attachment 76221 [details] Kate gui ConfigureToolbars against actual toolbar The panel that sets the Toolbar items (Settings - Configure Toolbars - split selection) bears little or no relationship to what actually appears on the toolbar. I find it hard to believe nobody else has noticed this - at least I did not find any similar observations here - or is it just me? (And consistently between distros?) I happen to be using Mint 13 KDE just now, but I've seen this behaviour before, Kate is "Version 3.8.3 Using KDE Development Platform 4.8.3 (4.8.3)" Right now, selected in the gui (after my addition of the Open Recent) I see: Open New Open Open Recent --- separator --- --- separator --- --- separator --- (X) Close --- separator --- --- separator --- --- separator --- whereas the toolbar shows: (? first "Open" not there) New Open Open Recent separator | Back (where did that come from?) Forwards (and where is that specifed?) separator | Save (and that?) Save As (and that?) separator | (X) Close separator | > newline Undo (Rabbits out of hats?) Redo (and hares?) (Plus, 'next line' items are almost impossible to use) If I were to apply a Wilcoxon ranking test, that would be pretty much a fail. I enjoyed the joke of the missing Open in position 00. The other non-correspondences just left me cold, bamboozled. They must have made sense at the time, to someone, I suppose. Maybe. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ALLIED GRIPES ~~~~~~~~~~~~~~~~~~~ Bringing me to further gripes: I wanted 'Open Recent' because I find it useful. I did nOt want an icon and text taking up so much real-estate in the toolbar. In fact, I find all the toolbar entries are cumbersome, too big, too wordy, amateurish. I'm sure better could be done. The extra term shoves the undo/redo onto a second 'on demand' line, unless the Kate panel is full (or large enough) width. That second pop-down toollbar is almost impossible to use without a suprememly steady hand - one must move cursor down and along the entire line without losing it. Thank Heaven for T'ai Chi Chuan and gin. Not that I would use Undo/Redo -- I'd use ctrl+Z etc So wouldn't it be useful to add the hotkeys to the icons? Ctrl+S for Save. Ctrl+W for X-Close (go figure)? etc. etc. Perhaps as tooltips, if not creating too much bloat? So, my aim was achievable with the gui plus only a little mystery puzzlement. That gui has a plethora of other options I didn't go into, but with no clear pointer to documentation, anywhere. Just go search Help. (I didn't - I'm making a massive assumption that there is actually such documentation. Congratulations if there is.) I expect they are very useful to someone who knows what they do. My point is that descriptions of such options should be available at "point of sale", not squirreled miles away elsewhere. That's it.