[kde-guidelines] KStyleguide

[David Edmundson]

On Sun, May 26, 2013 at 1:23 AM, Thomas Pfeiffer <colomar at autistici.org> wrote:
> On Sunday 26 May 2013 01:55:31 Heiko Tietze wrote:
>> Am Sonntag, 26. Mai 2013, 00:17:18 schrieb Thomas Pfeiffer:
>> > On Friday 24 May 2013 00:17:08 Thomas Pfeiffer wrote:
>> > I've now inserted links to existing HIGs in the new structure...
>>
>> Wow. Looks like a real styleguide now.
>
> :)
>
>> |Do not add controls to notification. Thomas: I would remove this. Adding
>>
>> action buttons is allowed in the API and has reasonable use cases, other
>> controls simply cannot be added technically)
>> We talked about this recently. David: "As the developer of the app, you
>> can't add controls to the notification system." but the last ticket
>> contains some strange buttons. Do we talk about the same issue?
>

If you are talking about this:
https://git.reviewboard.kde.org/r/110389/

This is not a developer using the notification framework, this is a
developer changing the notification framework.
The latter should not be covered in the HIG, as the HIG needs to say
how to use the frameworks we have in order to stay relevant.

> A notification can have simple buttons, but no other controls. I have seen
> several reasonable uses for these buttons (like "View" in an incoming message
> or "Open" in a finished download, or "Accept" and "Reject" for an incoming
> instant messaging contact request), and any other controls are simply not part
> of the API, so unless that changes, we're safe.
>
>> |Do not override system settings. (remark: more specific) Thomas: Which
>>
>> settings do you mean here?
>> First of all, time until the panel fades out, and behaviour on mouse over.
>> Depends on what Qt allows. I have only experience with Freepascal and you
>> can influence a lot there. Maybe I should to learn Qt now.
>
> I'd rather say "Depends on what the notification API allows". David, can you
> point us to an API reference for notifications? I tried to find something on
> Techbase, but no luck :( If I understood David correctly, it is not possible
> to change a notification in any other way than those explicitly offered in the
> API.
> So I think we should have a look at what's possible before speculating. And if
> we decide that something which the API currently allows to change should not
> be changed, we should try to convince the developers to change the API (which
> iirc won't happen for the 4.x series anymore, though, because kdelibs is
> frozen until the KDE Frameworks 5 release) instead of discouraging it in the
> HIG, because offering something in an API but then telling developers "Please
> don't use it" won't have a great chance for success I guess.
>
Notifications in KDE are here:
http://api.kde.org/4.10-api/kdelibs-apidocs/kdeui/html/classKNotification.html

Ping me to explain any part of it.
This sends a signal to the running notification system, in a cross
desktop standard (https://developer.gnome.org/notification-spec/) to
the running notification server.

On Plasma Desktop this is generally the (i) in the panel.
However, we also have to remember KDE applications also run on Gnome,
XFCE etc. where the notification display. Even on KDE users can set an
alternative, such as Colibri.

David

>> -------------------------------
>>
>> Am Donnerstag, 23. Mai 2013, 15:33:51 schrieb David Edmundson:
>> > I assume by KCM you mean the KCM at System Settings -> Application and
>> > System Notifications -> Manage Notifications
>> >
>> > If so, yes they are. Though it also possible to configure
>> > notifications in other places _as well_ but they will still always
>> > appear here.
>>
>> In all cases when developers can decide between alternatives we should