Created attachment 26056 [details]
Screenshot illustrating problem

I can confirm that the issue still exists in KDE 4.2.

This topic is/was discussed on usability ML -- "Keyboard shortcuts dialog". Of course I am all for solving this problem.

*** Bug 153913 has been marked as a duplicate of this bug. ***

*** Bug 183854 has been marked as a duplicate of this bug. ***

SVN commit 976518 by cfeck:

Fix broken rendering of shortcut editor widget

Only tested with Oxygen, Plastique, and Skulpture, but uses
PE_FrameMenu, so should work fine with any other style.

BUG: 166359


 M  +18 -5     kshortcuteditwidget.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=976518

SVN commit 976541 by cfeck:

Revert to old design

Appearantly, the old design was the result of some usability
considerations, need to investigate further.

CCBUG: 166359


 M  +5 -19     kshortcuteditwidget.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=976541

Reopen until we find a new design.

Could someone in the know please summarize the relevant usability concerns. Thanks.

I asked Christoph and he said "the commit basically used a Menu frame around the thing, making it look like a separate window". I asked why that was considered bad, he said "you would have to ask mjansen, I think he has the link to the usability discussion list [where he asked for this to be reverted]." Cc'ing, then.

Sorry, I wasn't clear about this. Michael asked me to revert on IRC, mentioning that the old design was the result of usability considerations.

Full log of the discussion:

<mjansen>	kdepepo, ping
<kdepepo>	mjansen, pongo
<mjansen>	you are the one working on kshortcutsedit?
<mjansen>	currently ... layout
<kdepepo>	mjansen, I just fixed that bug...
<kdepepo>	mjansen, not that I want to completely redesign it :)
<mjansen>	i'm not so sure it's an improvement
<mjansen>	did you just do something or did you discuss with some usability people?
<mjansen>	just because some people open bug reports it doesn't mean it is a bug
<mjansen>	the old design was made after conversation with  an usability expert
<mjansen>	ask maelcum for more info
<maelcum|konv>	i have the mockup somewhere :)
<kdepepo>	mjansen, I only changed the rendering of the frame, because it was seriously broken. Maybe for 4.4 we have something completely different.
<maelcum|konv>	kdepepo: it was really supposed to look that way. it's as much a frame as the line between tabs and content page is a frame.
<mjansen>	yeah ... but i'm no friend of changing just to change
<kdepepo>	hm
<maelcum|konv>	otoh people have filed bug reports, so if you can do something decent to shut them up it's okay.
<mjansen>	maelcum|konv, recompile kdelibs and have a look
<maelcum|konv>	yes, i'm recompiling right now.
<mjansen>	i don't think it's an improvement. the frame now stands really out. more liek an window hivering over the dialog
<kdepepo>	it was reported three times ... and it was about the odd looking frame. And there are color role issues using widgets without a background (radio buttons) inside a view
<kdepepo>	maybe we can have a more flat frame
<maelcum|konv>	i don't like that look at all. it looks like a foreign object.
<maelcum|konv>	the background should be whatever the listview background is.
<mjansen>	kdepepo, three times is nothing for kde :-)
<maelcum|konv>	the idea is not to open some kind of window-ish thing, you just show more of the listview element.
<mjansen>	but i too think the old version was bad.
<mjansen>	btu when fixing we should do it right
<maelcum|konv>	kdepepo: maybe you want to ask ellen reitmayr?
<kdepepo>	yep, I think I used menu frame because it is the only frame type in oxygen that has the good rounding
<maelcum|konv>	state the problems and if she has some solutions. or ask pinheiro.
<kdepepo>	maelcum|konv, do you know her nick?
<kdepepo>	or list she watches :)
<maelcum|konv>	kdepepo: she's not online often enough. i'll try to find her mail address...
<maelcum|konv>	the list would be kde-usability.
<kdepepo>	ah, I only know seele ...
<kdepepo>	I read the thread about that in usability, it had nothing about the look, only mentioned that bug report.
<kdepepo>	had the impression the thread is about the workflow.
<kdepepo>	would it help if the shortcut text above would be included in the frame (like a tab)
<maelcum|konv>	yeah, i agree
<kdepepo>	not sure if I can make them glue together nicely with just style calls... but will try this
<mjansen>	kdepepo, i would say revert for now and prepare a patch
<mjansen>	send it to the list.
<mjansen>	i think changing it now with 4.3 at the door is not a good idea
<kdepepo>	ok
<mjansen>	kdepepo, maelcum|konv doesn't this also somehow apply to kget?
<mjansen>	they use that delegate tpp
<mjansen>	s/tpp/too/
<kdepepo>	nope, the frame is rendered inside kshortcuteditwidget.cpp not in the delegate
<mjansen>	you could have a look how kget uses it.
<kdepepo>	kget uses something different let me check
<mjansen>	http://lxr.kde.org/ident?i=KExtendableItemDelegate
<mjansen>	it's also used in packagekit
<kdepepo>	mjansen, yeah, but that does not offer any visual indication, the user of that class just passes a widget as the "extender"
<maelcum|konv>	yeah, i went with the mechanism not policy (well, looks) rule, since i couldn't think of a good implementation for everybody - or in fact a really good implementation.
<kdepepo>	kget uses a group frame
<kdepepo>	and it has serious color role issues :)
<maelcum|konv>	i have nothing against adding a good standard implementation. it would have to be optional for compatibility reasons and i'd want to have a say in the api... :)
<maelcum|konv>	it would also help to make this kind of delegate perceived as a standard part of the kde ui. at least until we get itemview-ng which may or may not make it obsolete.
<pinheiro>	wsup?
<pinheiro>	kdepepo:  maelcum
<kdepepo>	pinheiro, I was trying to solve bug 166359
<bugbot>	KDE bug 166359 in kdelibs (kdeui) "Configure Shortcuts method looks like an incorrectly-drawn popup" [Normal,Reopened] https://bugs.kde.org/166359
<kdepepo>	pinheiro, and I was too fast at that :)
<maelcum>	hi
<pinheiro>	hum...
<pinheiro>	not sure i get the bug
<pinheiro>	the screenshot is fsked up by huge fonts
<pinheiro>	and ozone windeco :P
<kdepepo>	pinheiro, the bug is about the two blue lines... they look like a cropped frame
<maelcum>	the idea of the bug report is that the frame looks bad or even broken
<pinheiro>	it does
<pinheiro>	me wondering if its couse of the huge fonts?
<maelcum>	i programmed it according to a mockup from ellen reitmayr who does usability.
<kdepepo>	nah, the fonts need to be huge with 200 dpi displays :)
<pinheiro>	:)
<pinheiro>	I know ellen
<pinheiro>	:)
<maelcum>	to keep the spirit an improved version should still look like the view item has grown imho, not like some foreign widget was inserted.
<pinheiro>	yes i agrea
<pinheiro>	dont see the need for the blue frame
<maelcum>	something vaguely similar to the groupbox frame, but ask ellen if you have any doubts.
<maelcum>	oh, if you think it works without a frame i won't disagree.
<pinheiro>	well we could have some "groping efect" but dosent need to be on your face
<pinheiro>	im sure selle will agrea on this
<maelcum>	cool
<pinheiro>	there was afix?
<pinheiro>	a fix?
<pinheiro>	can i see it
<maelcum>	kdepepo: do you have a screenshot?
<kdepepo>	pinheiro, I took the error report by word, and made it use a popup frame (like a menu)
<pinheiro>	humm maybe to much no
<kdepepo>	ah no, I already recompiled with the revert, but could do
<maelcum>	solid grey with rounded borders in oxygen style
<maelcum>	i've also recompiled already
<pinheiro>	would look a bit beter but still abit lçike a buton
<pinheiro>	like
<pinheiro>	i mooked somthing for the systemsetings some time ago that would do this joob quite well imo
<pinheiro>	let me see if i can find it
<kdepepo>	the other problem is about color roles... the radio buttons are not prepared to render against View color (they are designed for Window background)
<kdepepo>	(ignoring the fact, that Oxygen still has color role bugs, too :)
<maelcum>	are there color schemes that work otherwise but break in this place?
<pinheiro>	has color role bugs ??
<pinheiro>	hones t question
<pinheiro>	i know just about zero about code
<pinheiro>	http://imagebin.ca/img/etUDf8d.png somthing like this
<sreich>	ooo, me likes
<kdepepo>	maelcum, if your Window and View text colors are not identical, you could end up reading dark on dark or white on white.
<maelcum>	okay, that looks good to me as well.
<kdepepo>	it looks wavy
<maelcum>	kdepepo: but does anyone actually have completely different text colors in window and views?
<maelcum>	i guess nobody who is not a programmer really knows or wants to know the difference between a view and other widgets.
<kdepepo>	maelcum, you can change them indepently using the system settings color kcm
<maelcum>	that said, maybe a palette hack is possible, i.e. pass the widgets a modified palette?
<pinheiro>	IM quite prowd od having done the design of the intire oxygen style artwork and not knowing the name of 90% of the widgets
<maelcum>	kdepepo: yeah, but who is going to use it?
<pinheiro>	:)
	 * sreich hands pinheiro a typo-proof keyboard ;P
<kdepepo>	sreich, pssst :)
<maelcum>	imho if you have dark on bright window colors and bright on dark itemview colors you have big problems anyway
<pinheiro>	sreich: im bewond repair
<sreich>	:)
<pinheiro>	me goes back to work
<pinheiro>	but a identation or that would be fine by me
<pinheiro>	and its  completly valid bug
<maelcum>	how do you mean indentation?
<pinheiro>	like list
<pinheiro>	but it would need to be obviusly visible
<pinheiro>	the identation bit
<pinheiro>	and it can be a truky thing to do
<pinheiro>	triky
<maelcum>	you mean just shift the stuff that is inside the frame now more to the right?
<pinheiro>	yes
<pinheiro>	and without framing
<maelcum>	yeah, sure
<kdepepo>	so it would look like an expanded tree, makes sense.
<pinheiro>	yes
<maelcum>	fwiw, i also like the system settings mockup. but it would mean more work :>
<kdepepo>	maybe even have the tree lines there...
<maelcum>	kdepepo: afaict this (the tree lines) is not going to be easy
<maelcum>	iirc i've never tried working with style primitives directly though
<pinheiro>	maelcum: if it would be aplied in other parts of kde it would be totaly worth it
<kdepepo>	maelcum, I have ;)
<pinheiro>	but just for this case ..... no
<maelcum>	yeah, the idea is that when we have something that's good to standardize on that.
<pinheiro>	cool
<pinheiro>	i would try
<pinheiro>	well but i dont code :) so ist esy for me
<pinheiro>	easy
<pinheiro>	:)
	 * pinheiro realy goes now :)
<kdepepo>	maelcum, the only problem is the tree line in the parent item list... look at the screen shot in the bug report, the tree line there is centered.
<kdepepo>	hm, we could get around that by using a real tree model
<kdepepo>	but then again, we do not have the simple + - to expand, as we have "shortcut" "alternate" and "global"
<maelcum>	i remember that i tried to use the lines in some way but eventually i gave up.
<kdepepo>	Qt has clever code to align the tree lines to the first text line for multi line items, but unfortunately, that is not in QCommonStyle.
<kdepepo>	Maybe I should move it for Qt 4.6

See also bug 163489.