Bug 177734

Summary:	searchbar should be in toolbar
Product:	[Applications] kcharselect	Reporter:	Stefan Majewsky <majewsky>
Component:	general	Assignee:	Bryce Nesbitt <bryce>
Status:	RESOLVED INTENTIONAL
Severity:	normal	CC:	laidig
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Compiled Sources
OS:	Unspecified
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Stefan Majewsky 2008-12-14 00:03:38 UTC

Version:            (using Devel)
Installed from:    Compiled sources

The toolbar with only one button looks... funny. Instead, the searchbar should be directly in the toolbar, just as in systemsettings.

Comment 1 Daniel Laidig 2008-12-14 02:39:31 UTC

Actually, there should be no toolbar by default. The one-button toolbar was an unwanted side effect of adding actions with shortcuts etc.

At the moment, the toolbar should be disabled by default and proably I will completely delete it, now that a recent fix in kdelibs makes this possible.

So, I don't see a real reason for creating a toolbar just for the search line, as in my opinion the current location makes sense.

That's why I am closing this bug. Feel free to object if you have a good reason. :)

Off topic: Do you really see the toolbar with a current trunk version? If so, does .kde4/share/apps/kcharselect/kcharselectui.rc exist?

Comment 2 Stefan Majewsky 2008-12-14 12:37:31 UTC

About your "off-topic" question: The directory .kde4/share/apps/kcharselect does exist, but is empty. I'm using 4.1.82 packages on openSUSE 11.0, which should include the most recent version of KCharSelect.

For semantics: You should mark the bug as "RESOLVED/WONTFIX" or such, as "RESOLVED/FIXED" usually means that the report has been incorporated into the app. I'm changing the resolution now to make the status clearer to third persons, even if I'm not really comfortable with this solution.

I see that you're on a totally different viewport here. Like already mentioned, I (as a user) love the way systemsettings uses the toolbar for navigational actions, yet I (as a developer) understand the problem that the current design of the KCharSelect class does not allow for much flexibility in the application layout, which renders the toolbar useless. Technically, it would be no problem to adapt the KCharSelect widget to using the toolbar by exposing an internal KActionCollection which could be merged by the containing dialog (although I do not know whether this is a valid solution for other applications using KCharSelect).

You say that "the current location [of the searchbar] makes sense", but the location would not change if it was in the toolbar, so I do not really think this is a valid point. As far as I see it, the UI is designed for a top-down workflow where one starts at the top and works its way down to the bottom.

Perhaps it might be better to contact a UI specialist for this one.