-1

Everybody uses computers and the same programs to doing different tasks, like preparing text document or only print it.

Actually KDE SC is most useful piece of code on the world, but not everybody uses all options.

The idea is to allow globally hiding some options of applications, but not similar user can do this on application. We must define group of task and user habits, like textual interface, printing, viewing information, editing (lots of different) documents.

Plasma will change KRunner options and menu entries automatically. Dolphin should too.

There's no reason to have print button on text processor even we won't print.

There's no reason to have run command on plasma desktop in some cases.

There's no reason to using open terminal button in tools menu of dolphin, when we don't enable textual interface habit.

There's no reason to showing a lots unnecessary information if some habit are not set(like fast view)

Some other hints:
We can guess settings looking on groups user belongs.
We can show settings dialog once KDE SC is first run.
We can show more backup options for operator(user with administrative habit, for example in operator group).
We can disable some advanced option if user haven't advanced habit(but that's too complicated to guess in which extend user is advanced)
Some basic habits: textual interface, letter writer, printing, fast view, viewing information, editing images, editing videos, editing music/songs, editing documents, operator, advanced document writer, messaging, social

Most software can reads our habit and changing sets of hidden option. For example to letter writers we can show send by e-mail options in each software.
Software could also prepare page called first step to give a links onto interesting topics, like printing.
I think, that we could also connected habits onto activity, so based on social/messaging habit messages from IM could have greater or less priority.
Plasma widget manager could deliver habits based group, where are delivered widget matched to our habits.

We can also define lots of habits to preparing habits based help page, like:

terminal based job control, editing (for example music), obscured (software should take care about our privacy and show some information in documentation, for example for to remove some information, where data is stored, etc.)

KLaunch can offer to install software based on habits, but that's a far future. We had only clicked on image and KDE SC asks us to we would like to edit this image, view it, etc.

Whoah, how is KDE meant to know what you want to do?

My idea is to change user interface based on user habits, like buttons on top panel.

I see two parts to this idea:
Add a configuration system for "habits" where each "habit" would enable/disable different settings/options/behaviors (per application), add/remove application launchers/widgets, etc.
The second part is for KDE (applications) to automatically select different habits for the user based on user actions. This would require some extensive development to take some statistics and do some analysis of the things that the user does (frequently uses browser vs. frequently uses konsole, likes to fiddle with settings vs. never touches settings) and automagically select/deselect different habits. I don't foresee this part happening as it would be far too complex with little benefit, and in many cases would only lead to confuse users when it removes functionality that it thought the user wasn't going to use.

As for the first part, much of that functionality may be implementable using Activities; that is the current activity (and maybe some data tied to the activity) will be available to the applications as an Akonadi resource. Therefore applications will be able to make use of this information to present different data or even a different interface to the user based on their current Activity.

airdrik wrote:I see two parts to this idea:
Add a configuration system for "habits" where each "habit" would enable/disable different settings/options/behaviors (per application), add/remove application launchers/widgets, etc.
The second part is for KDE (applications) to automatically select different habits for the user based on user actions. This would require some extensive development to take some statistics and do some analysis of the things that the user does (frequently uses browser vs. frequently uses konsole, likes to fiddle with settings vs. never touches settings) and automagically select/deselect different habits. I don't foresee this part happening as it would be far too complex with little benefit, and in many cases would only lead to confuse users when it removes functionality that it thought the user wasn't going to use.

As for the first part, much of that functionality may be implementable using Activities; that is the current activity (and maybe some data tied to the activity) will be available to the applications as an Akonadi resource. Therefore applications will be able to make use of this information to present different data or even a different interface to the user based on their current Activity.

Habits would been never selected automatically.

I think you should reconsider this idea for integration with KDE's upcoming "Activities". Perhaps each Activity will remember its own windeco/shortcuts/buttons on toolbars settings.

However having KDE fade out buttons if we don't click on them often is just silly imho