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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
