Revision as of 20:39, 21 March 2007

Draft idea lavalamp event filter: 0.0.0.2

Activity- & Task-oriented Messages

The user sets their activity in a Kicker extension. The extension runs specific applications and refers to defined information resources ─ specified URIs, directories, files and metadata. Information is displayed to facilitate and guide the user through their chosen activities.

The kicker extension optionally logs the user's choices of activities. When they select a subsequent activity, the user can choose to comment on their progress. The comment gets stored in Kontact or another user-defined personal information management suite.

Tip

Generally, this idea applies to such things as tooltips and Konqueror-style accessibility shortcuts in the desktop (toggled by Ctrl). Using a taskbar or desktop extension, the user will set the context of messages. Context, defined as declared user activity results in different messages depending on the user's chosen context.

}

DCOP can be used to display the messages, after the program (applet) and its GUI retreived the display method content.

Tip

Use Case Examples

For example, if a user wanted to work with development they would declare it using the program GUI so that tooltips for widgets would supply relevant information. For example, showing the relevant source code (development activity context). In other activities, the tooltips showing a position in a defined task trail (workflow context) or displaying a translation (language work context). The information to display would not be compiled in, but lifted from a specified reference file or directory.

This proposed implementation seeks to be small, simple, effective and extensible. It could help contributors who want to participate more effectively in KDE development.

It appears applications may not want to give up their regular tooltips for alternative tooltips. dcop

Code links:

Other interesting information:

@@ Line 1: / Line 1: @@
 ''Draft idea '''lavalamp''' event filter: 0.0.0.2''
-How can activity-oriented messages be used in KDE4? This applies to tooltips and Konqueror-style accessibility shortcuts in the desktop (toggled by Ctrl). Using a taskbar or desktop extension, the user will set the context of messages. Context, defined as ''declared user activity'' results in different messages depending on the user's chosen context.
+= Activity- & Task-oriented Messages =
+The user sets their activity in a Kicker extension. The extension runs specific applications and refers to defined information resources ─ specified URIs, directories, files and metadata. Information is displayed to facilitate and guide the user through their chosen activities.
+The kicker extension optionally logs the user's choices of activities. When they select a subsequent activity, the user can choose to comment on their progress. The comment gets stored in Kontact or another user-defined personal information management suite.
+{{tip|
+Generally, this idea applies to such things as tooltips and Konqueror-style accessibility shortcuts in the desktop (toggled by Ctrl). Using a taskbar or desktop extension, the user will set the context of messages. Context, defined as ''declared user activity'' results in different messages depending on the user's chosen context.
+}}}
 DCOP can be used to display the messages, after the program (applet) and its GUI retreived the display method content.
                                 {{tip|[[Image:20070319-titletooltip-KDE3.jpg]]}}
+= Use Case Examples =
 For example, if a user wanted to work with development they would declare it using the program GUI so that tooltips for widgets would supply relevant information. For example, showing the relevant source code ('''development activity''' context). In other activities, the tooltips showing a position in a defined task trail ('''workflow''' context) or displaying a translation ('''language work''' context). The information to display would not be compiled in, but lifted from a specified reference file or directory.
-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 is presumably already in the KDE code base.
+This proposed implementation seeks to be small, simple, effective and extensible. It  could help contributors who want to participate more effectively in KDE development.
-There may be a problem getting applications to give up their ''regular'' tooltips for alternative tooltips.
+It appears applications may not want to give up their ''regular'' tooltips for alternative tooltips. dcop
 Code links: