User talk:Bygdog: Difference between revisions

From KDE TechBase
mNo edit summary
(Revision following feedback from bradh)
Line 1: Line 1:
Once, there was an idea: ''to add '''contexts''' to KDE4''. Among other things, this was to apply to tooltips. Somewhere in a taskbar or desktop extension, the user was to be able to use DCOP shortcuts to set the context of messages. Context was to be defined as ''relating to the current activity of the user'' and meant that messages would be different depending on the user's choice of context.
''Draft idea "lavalamp" event filter: 0.0.0.2''


                              [[Image:20070319-titletooltip-KDE3.jpg]]{{tip|text}}
There was an idea: ''to add '''contexts''' to KDE4''. It applied to tooltips and Konqueror-style accessibility shortcuts in the desktop (toggled by Ctrl). Using a taskbar or desktop extension, the user was could set the context of messages. Context was defined as ''declared user activity''. Messages would change depending on the user's chosen context.
For example, if the user wanted to work with development, tooltips for widgets would supply relevant information. Instead. they displayed the relevant source code ("'''development activity'''" context). In other user activities, the tooltip showed an ordered task trail ("'''workflow'''" context) or displayed a translation ("'''linguistic activity'''" context).


Now, requiring (Super-) Karamba for this sort of thing seems excessive, since the context feature described here is simple. The infrastructure needed is, without little doubt, already in the code. The proposed feature is good because it could lower the bar for contributors who want to participate in KDE, but who are hindered by current documentation. The issue of code contribution and documentation improvement is a chicken-and-egg problem. Documents need to improve but so does code, and it is hard (impossible?) to have one without the other.
DCOP could be used to display the messages, after the program and its GUI retreived out what to display, and how.
                              {{tip|[[Image:20070319-titletooltip-KDE3.jpg]]}}
 
For example, if the user wanted to work with development they would declare it using the program GUI so that tooltips for widgets would supply relevant information. They displayed the relevant source code ("'''development activity'''" context). In other activities, the tooltips showed a position in an ordered task trail ("'''workflow'''" context) or displayed a translation ("'''linguistic activity'''" context).
 
This proposed implementation seeks to be small, simple, effective and extensible. It  could help contributors who want to participate more effectively in KDE development. The infrastructure needed may already be in the KDE code base.
 
There may be a problem getting applications to give up their ''regular'' tooltips for alternative tooltips.
 
Code links:
http://doc.trolltech.com/4.0/signalsandslots.html
http://www.phptr.com/articles/article.asp?p=667415&seqNum=3&rl=1 --from bradh on irc

Revision as of 11:42, 20 March 2007

Draft idea "lavalamp" event filter: 0.0.0.2

There was an idea: to add contexts to KDE4. It applied to tooltips and Konqueror-style accessibility shortcuts in the desktop (toggled by Ctrl). Using a taskbar or desktop extension, the user was could set the context of messages. Context was defined as declared user activity. Messages would change depending on the user's chosen context.

DCOP could be used to display the messages, after the program and its GUI retreived out what to display, and how.

Tip


For example, if the user wanted to work with development they would declare it using the program GUI so that tooltips for widgets would supply relevant information. They displayed the relevant source code ("development activity" context). In other activities, the tooltips showed a position in an ordered task trail ("workflow" context) or displayed a translation ("linguistic activity" context).

This proposed implementation seeks to be small, simple, effective and extensible. It could help contributors who want to participate more effectively in KDE development. The infrastructure needed may already be in the KDE code base.

There may be a problem getting applications to give up their regular tooltips for alternative tooltips.

Code links: http://doc.trolltech.com/4.0/signalsandslots.html http://www.phptr.com/articles/article.asp?p=667415&seqNum=3&rl=1 --from bradh on irc