[KDE4] KNotification

[Aaron J. Seigo]

On Saturday 17 September 2005 16:46, Olivier Goffart wrote:
> Le Samedi 17 Septembre 2005 23:24, Aaron J. Seigo a écrit :
> If you have followed the discussion about that in kdg at fd.o , or read
> archive, you will see that they are *strongly* against extending the spec
> to anything else than popup.

yes, i'm very aware of this. i'm not sure if that's a good enough reason to 
let the spec fall short of what it ought to be? *shrug*

> > 	- provide a daemon that supersets the FD.o-submtited spec and, when an
> > app is run in GNOME using the GNOME daemon, the apps is just less
> > featureful. this will cause people to either not use the KDE app, use KDE
> > instead or use the KDE daemon in GNOME.
>
> I think that many of us agree that making our kde apps working outside of
> the "K Environment" is an important thing (look discussion about file
> dialog) but that should not reduce the feature of that app anyway.

at some level, i believe our apps will work better with other kde apps 
(including workspace) if only because of practical issues. the current 
KIMProxy is an example of this. over time it will improve, and our apps must 
at worst degrade gracefully when used outside of a full kde desktop (e.g. 
they must not suddenly be unusable when not in KDE; and right now we start 
knotify when necessary anyways, no?)

> > one thought: what happens to notifications when the hosting app goes
> > modal? do they as well lock up? probably, and that's not a good thing.
> > (c.f. the system tray and the bug reports around "when Foo App shows a
> > modal dialog box i can't access the Foo system tray icon anymore")
>
> In the current Kopete implementation, without daemon, there is the problem.
> But if we use a daemon for popup, I guess the problem will not be there.

from a user interaction standpoint, i think this is pretty important.

> > is it possible at all to do the notifications out-of-process of the
> > notifying app given the feature set you want? if so, that would actually
> > be preferable as it would allow multiple and varied presentations within
> > plasma. for the workspace, out of process is ungood.
>
> I don't understand this.

sorry, let me try again .. i'd like to have plasma be able to present 
notifications as they appear to the user in a unified and consistent manner. 
the FD.o notification spec allows for this, but i too find that spec rather 
limited in nature. if we add additional features, such as the ability to say 
"show a button labelled Foo" or "show this QWidget* in the notification" i 
hope to not have that degrade the ability for plasma to render and manage the 
display of that notification. if the widget is out of process for plasma, 
then we may have to use XEmbed which is something i'm trying to limit as much 
as possible but which may indeed be workable. just something i'm trying to 
keep in mind here for kde4.

does that make more sense than my previous ramble?

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050917/fe9bf16d/attachment.sig>