plasma-desktop on other environments (bis)

[René J. V. Bertin]

David Edmundson wrote:

>> Where and how exactly are the default sounds configured?
> .notifyrc files shipped with the application  / library.

That would mean changing lots of files then... I'm not sure how to do that in an 
efficient way if there isn't something like a category mechanism in place 
already that could by used in KNotifications to determine what "native" sound to 
use instead of the specified sound file, on platforms where this would be more 
appropriate.

Kai Uwe Broulik wrote:

> QApplication::beep()

I haven't checked, but that one undoubtedly plays the "alert sound", which is 
the only choice we have on OS X. Plus the option to play "user interface sound 
effects" or not. Nothing configurable there, nor any way to know which sound 
those are.

> I rather find this distinction awkward and would expect emptying the trash
> empty the whole trash, or not offering that from a KDE application in the
> first place (we don't do that except for Dolphin, and perhaps the file open
> dialog, do we?).

Any application that has an option to move files to a wastebin rather than 
deleting them directly moves them to the KDE trash AFAIK. That includes digiKam, 
which means you can end up with lots of rather large files hidden somewhere.
That was the reason I implemented a backend under KDE4 which has been ported to 
KF5.
I do not want a KDE application to empty the whole trash, and in this context 
I'll only need to justify that with the fact that no other application does 
this. Emptying the entire trash is done only by the Finder.

> Doesn't at least QPlatformMessageDialog use the native OS X message popup
> thingie?

Message popups use a more or less native "thingie", yes. I'd say that most 
popups posted by KDE software do too, by extension.

> Such as? Most notifications fall into the category of "error", "warning",
> "question", "info", and I bet OS X has counterparts for those sounds. Passive

Actually, no. There's just a single alert sound as I wrote above. Applications 
that feel the need to use a finer grained distinction provide there own 
notifications. So KDE isn't an outlier there.

> If I hear the generic Windows drum sound I know that an error happened. If I
> hear the Oxgen sound on Windows I might not do that.

For a generic alert sound that might be true. But I will remain convinced that 
most users of KDE applications on "other platforms" will chose to use them 
because they already do on Linux. More specific notifications are always useful 
(or they're not justified anywhere), and as someone who uses the same software 
on multiple platforms I know how useful it is if esp. my non-visual feedback is 
the same everywhere (just like things like shortcuts).

> "familiar KDE interface". I bet the average one-platform user group we imho
> should be targeting does the same.

There's not 1 category you should be targeting, but all potential users, and for 
me that also means not disabling features that could be seen as added value 
(like providing better-than-native configurability) just because some people 
have decided for whatever reason that those features are to be guarded 
jealously. It's fine to try to be as native as possible by default (as long as 
that doesn't increase maintenance burden too much) but that shouldn't make it 
impossible to provide a familiar cross-platform interface (there too as long as 
it doesn't increase maintenance burden too much).

> Please don't make our apps aliens in other environments.

Please don't tell users of other environments what they're allowed to do with 
their apps either.

> He's doing macports which is *very* different. Macports even has X11 and 
Fluxbox.
> If you're running kate on X with a fluxbox WM, having native OS X integration 
just because of your kernel doesn't make too much sense.

That's very true, even if the scenario is a little over the top. I can indeed 
run Kate5 under X11 using MacPorts (and even make it use Mac-style widgets in 
that case), but that's more a PoC and test-bed than something I do on a daily 
basis.

> On a side note, KNotification doesn't really have much other use on ~X11
> than playing sounds.

Oh? Maybe I mix KNotification and KNotifyConfig, but I find the mechanism to 
decide per event if you want sound and/or popup and/or something else to be very 
useful. OS X really simplifies too much there even if there are enough 
applications that provide this kind of feature, either rolling their own or 
using 3rd party frameworks like Growl.

R