[kde-guidelines] KStyleguide

Thomas Pfeiffer colomar at autistici.org
Wed May 15 20:34:22 UTC 2013


On Wednesday 15 May 2013 12:07:23 David Edmundson wrote:
> > 3. Presentation
> > 3.1 Layout
> > - Notification panel's size is 100 x 42px.
> > - Notification panel cannot be resized.
> > - Content of notification has 8px space around.
> > - ...
> > 3.3 Text
> > - Notification has a caption with system font, sized +1, central aligned.
> > - Notification text is system standard, justified to panel width.
> > - ...
> 
> Can I suggest we separate the tasks  "how an app developer should use
> existing KDE libs" and trying to change what the KDE libs do.
> 
> I suggest we do this because otherwise we will spiral into redesigning
> everything anew and not really come up with anything that developers
> can actually benefit from. This is something I've seen happen before.

> In this example, from a technical point of view the app developer has
> absolutely no control over how the notification is shown. A developer
> can only set the the raw text + icon + actions.
> The content size + font + margins + resizing is down to the native
> notification display system which is generally, but not always,
> Plasma. Given the developer has no control, there would be no point
> listing it.

The only reason I see for listing it in the HIG is for cases where a developer 
cannot use the default notification system but wants to recreate its look and 
feel. An alternative approach to this would of course be "Use only the 
standard notification system, no hacks, no tricks!"

> Whether there's an icon to configure the notifications or changing the
> font size is trying to change what's there and not saying how one
> should use what's there.

The configure icon is already in kdelibs, isn't it (see 
http://git.reviewboard.kde.org/r/110389/ )? I guess the information about font 
size was just a placeholder for [insert here what kdelibs gives you]
 
> Obviously if there is a view that some KDE library behaviour is wrong,
> we can and should still follow that up in the relevant channels,  now
> is almost the perfect time to do that. However, we should avoid
> writing these things into the HIG.

+1. The HIGs should always match the current reality (as I said, descriptive, 
not prescriptive). If we don't like the current reality, we should change it 
first and then reflect the new, improved reality in the HIG.


More information about the kde-guidelines mailing list