Version: (using KDE 4.1.3)
put import, export, component in the same line -- vertical space preservation
There are huge widgets there which take too much space, I opt for rearranging them to preserve some space. Namely:
kde component: [ kmix ] [ export scheme ] [ import scheme ]
[ export scheme ] [ import scheme ]
kde component: [ kmix ] search: _____________
Also put the width of shortcuts box to maximum of the module.
And maybe labels could be arranged better: "shortcuts" is just before "search"... I'll give an eye :-)
True, I would opt for removing this label at all because shortcuts is this section so it is the main element. So it is redundant.
The "Shortcuts:" label can be removed.
The search bar can't be merged with other widgets as it's part of the List widget (it seems)
I'm trying to merge the export/import scheme buttons :)
Another thoughts about this: The Export/Import Scheme buttons are global (for all the components), so if they are inline with the component chooser it may be confusing.
@Maciej: what do you think about ? Is there any other possibility to compress the layout ?
search and component chooser can be at the same line.
Could export/import use the line of apply, defaults, etc?
btw. can list take all space horizontally?
If you ask me I still opt for using one line for export/import/search/composer chooser even maybe. True it _might_ be a little confusing but I doubt it would become major confusing factor.
(In reply to comment #5)
> search and component chooser can be at the same line.
The search bar is part of KShortcutEditor (kdelibs/kdeui) widget and can't be merged with the Component chooser line as the last one is in KGlobalShortcutEditor (keys-kcm)
> Could export/import use the line of apply, defaults, etc?
I'm going to investigate about this, it would be a good solution
> btw. can list take all space horizontally?
Sure, removing the "Shortcuts" label
> If you ask me I still opt for using one line for export/import/search/composer
> chooser even maybe. True it _might_ be a little confusing but I doubt it would
> become major confusing factor.
Addind Celeste to the CC as this is an usability issue
SVN commit 921404 by mjansen:
I removed the "Shortcut:" label. I think everyone agreed it took to much
M +21 -21 kglobalshortcutseditor.ui
M +4 -22 select_scheme_dialog.ui
WebSVN link: http://websvn.kde.org/?view=rev&revision=921404
To the other options.
I don't like "kde component" too. Should we change that to application? Or remove it completely too.
I'm about to add another button to that dialog. The user needs a possibility to remove unneeded/unwanted components and/or shortcuts manually. This change will go hand in hand with bookkeeping how long an application / shortcut hasn't been seen. if a treshold is reached i want to either remove the component or let the user decide.
I'm thinking about gathering all of these in one button with menu. But what text should that button have?
Menu -> Import scheme / Export Scheme / Remove Component
And where to put the global settings section we will need with 4.3. You are able to configure how kde should handle global shortcut conflicts, the treshold, which applications to block completely from global shortcuts etc.
> The user needs a possibility to
> remove unneeded/unwanted components and/or shortcuts manually.
What for? Is he/she does not use shortcut, well, so be it.
How do you add shortcut back? Or component? More buttons?
It is just more and more complex without real necessity.
> This change will
> go hand in hand with bookkeeping how long an application / shortcut hasn't
> seen. if a treshold is reached i want to either remove the component or let
> the user decide.
Please don't do this -- it is really usability killer. Once shortcut is removed user will have real problems to configure it back, and there will be always some doubt, if she/he cannot assign a shortcut because KDE is broken, or because the shortcut was removed by this mechanism.
We are not in such trouble with HDD that removing shortcut will significantly free some space.
SVN commit 929646 by mjansen:
Put "Import configuration", "export configuration" and "cleanup" into one
menu on the same row as the component combo box.
I'm open for wording suggestions for
- the text on this menu button (currently "File")
- the text in the confirmation dialog after "Revise Component".
The idea behind "Revise Component" is to remove stale global shortcuts
a) The complete application was deinstalled.
b) The application was renamed or otherwise lost track of some of it's
registrations. Happened to plasma and amarok.
So we just remove all registrations for currently not active global
shortcuts. If nothing is left the complete component / application is
removed too. This does no harm because an application on startup
reregisters everything we just deleted. Now could someone please reformat
this description into something suitable for the dialog. I'm a much better
at programming than at wording in this cases. And that says more about my
wording skills than my programming skills :-)
M +2 -65 globalshortcuts.cpp
M +0 -3 globalshortcuts.h
M +62 -14 kglobalshortcutseditor.cpp
M +2 -0 kglobalshortcutseditor.h
M +3 -3 kglobalshortcutseditor.ui
WebSVN link: http://websvn.kde.org/?view=rev&revision=929646
> Put "Import configuration", "export configuration" and "cleanup"
> into one menu on the same row as the component combo box.
Micheal, thank you very much.
> The idea behind "Revise Component" is to remove stale global
> shortcuts registrations because
I opt for removing the button, but keeping the feature. It is no use when user has to use it explictly, from the description I see it is completely automatic maintenance feature, so it should triggered when the module is loaded.
> I opt for removing the button, but keeping the feature. It is no use when user
> has to use it explictly, from the description I see it is completely automatic
> maintenance feature, so it should triggered when the module is loaded.
It is not a automatic maintenance feature. You will loose your shortcut configurations (if any) for the shortcuts that were removed because applications only keep track of the default shortcut. Thta's why doing it autmatically is bad.
Only the user knows if he never intends to start application xyz again. That's the primary use case for this feature. Perhaps i should just rename it to "remove component|application". If the user triggers it i could test and if the component is running print something explaining that only inactive shortcuts will be removed. If the component|application is not running i could just remove it after a confirmation dialog.
I think that's the best solution. This revise thing isn't very intuitive.
Micheal, just to ensure myself :-) because I feel (intuition?) that something is not right.
User A & B defined shortcuts for Amarok. Both users deleted Amarok.
User A wants to keep defined shortcuts because she/he might use them again (after reinstalling Amarok).
User B is positive she/he won't use Amarok shortcuts, so she/he wants to delete it as well.
Because of A, we don't want to do auto-delete, right? But now about B -- why we want to delete shortcuts at all? They could be kept -- why not?
We want to allow deleting the shortcuts:
- Because it keeps the dialog tidy. Remember just installing every package your distro provides and running each app once to see what it does. You end up with many apps there you never want to start again.
- Because the shortcuts are still reserved for those applications. Sure you can reassign them here. But you have to open the shortcuts kcm. If you delete the shortcuts reservatiions a new application can just take the then unreserved global shortcuts.
- We had cases in kde when developer messed up their applications global shortcuts handling code. A user can clean that up with that functionality.
> - Because it keeps the dialog tidy.
True, but to achieve this it is sufficient to deactivate app's settings (deleted app).
> - Because the shortcuts are still reserved for those applications.
Same as above.
> - We had cases in kde when developer messed up their applications
> global shortcuts handling code. A user can clean that up with that
This is actually not the place to solve this for two reasons. First of all the mess is done at low level, so the solution can be low level too. Second reason -- user can have highly customized set of shortcuts, I don't see deleting my work as a solution to the mess. In other words -- it is not a solution, just a crude way to solve developer's problems. It should be other way.
You mentioned distro that installs a lot of stuff. But what with case when user installs app A, uses it for a while, customize it, uninstall, and then wants to come back (after two months for example). Keeping settings (in terms of storage) is one of the cheapeast things I know. So why not to keep them in deactivated state (frozen, archived)?
The purpose: if/when user comes back he/she can start when she/he finished.
Btw. those above are just my considerations, because I am not convinced we (KDE) need deleting settings. The above approach would work for everybody with advantage of being automatic -- you uninstall app -> app is no longer registered -> its shortcuts are kept as archive (i.e. those shortcuts will be activated on reinstall only).
Less buttons, less manual intervention.