<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><div>Hi I'll answer inline even so I usually don't like it.</div><div>And I fixed the clazy warnings.</div><div>Thanks for the feedback :) <br><br></div><div>> From: aleixpol@kde.org<br>> Date: Fri, 20 Nov 2015 01:51:13 +0100<br>> Subject: Re: Please review Snorenotify (Finish Incubating)<br>> To: vonreth@kde.org<br>> CC: kde-core-devel@kde.org<br>> <br>> On Wed, Nov 18, 2015 at 11:48 PM, Hannah von Reth <vonreth@kde.org> wrote:<br>> > Hi there,<br>> ><br>> > Mario guided me until now through the incubation process and we think it is<br>> > time to move Snorenotify from playground to extragear.<br>> > Snorenotify is a notification framework supporting Linux, Windows and Mac<br>> > OSX.<br>> > It is not meant to replace Knotifications, it is more targeted on Qt<br>> > applications without dependency to the plasma desktop, so it might become a<br>> > backend for Knotifications.<br>> ><br>> > I guess you can find the most important information here<br>> > https://community.kde.org/Incubator/Projects/Snorenotify.<br>> ><br>> > Besides Snorenotify there is also Snoretoast, a sub project of Snorenotify,<br>> > https://quickgit.kde.org/?p=snoretoast.git.<br>> > Snoretoast is a command line application and used within Snorenotify for<br>> > the Windows Toast notifications.<br>> > The application can only be build using the Microsoft compiler.<br>> ><br>> > So it would be great if Snorenotify could become a official KDE library and<br>> > maybe even a framework someday.<br>> > Currently it is used by Quassel and Tomahawk but hopefully more will start<br>> > to use it soon.<br>> ><br>> > So please review Snorenotify.<br>> ><br>> > If you find the idea of Snorenotify useful or you fancy notifications, like<br>> > I do, feel free to contribute ;) or start to use Snorenotify.<br>> <br>> Hi Hannah,<br>> I'm happy that you're decided to push this forward, I think it's a<br>> framework that could be definitely useful. In KDE Connect we'd like to<br>> be able to use it instead of KNotifications because it's leaner and<br>> more straightforward to our notifications use-case. As I said before,<br>> I already ported KDE Connect to use snore, nevertheless there's some<br>> issues like the API that I would suggest to review before committing<br>> to API and ABI stability.<br>> <br>> Here's some thoughts:<br>> - It feels overly complex that the Notification object is passed<br>> around by value rather than by reference. For starters, being able to<br>> connect to the notification would be very handy. I work-arounded it by<br>> setting a hint with the relevant information, but I have the feeling<br>> the API would be slightly smoother.</div><div>A Notification uses shared data and is not a QObject.</div><div>The reason why I use shared data is that neither the backend nor the frontend/application knows when to delete the notification.</div><div><br>> - There's a hard dependency on QtWidgets from the very core of the<br>> framework. This requires applications that would use it to use<br>> QApplication. In the case of KDE Connect, for instance, the plan was<br>> to make it possible to have it in a QCoreApplication (or<br>> QGuiApplication at least). It's a daemon from which we consider that<br>> it's acceptable to show notifications but we don't really plan to open<br>> a dialog from there. Do you think it could/should be worked out?</div><div>Hm I'll investigate what might be possible.<br>> - There's a daemon. We're kind of trying to get rid of daemons. When<br>> is it needed?</div><div>It might be useful on mac and Windows to display freedesktop notifications but can be disabled <font face="Calibri,sans-serif">-D</font><span style="color: rgb(0, 0, 0);"><font face="Calibri,sans-serif">BUILD_daemon=OFF</font></span><br>> - enum values are all-caps joined by underscore (e.g. GLOBAL_SETTING).<br>> Camel-case would be more Qt-friendly.</div><div>Will do so for the next release.<br>> - Some methods use wid as a windows id. Please use QWindow whenever<br>> possible, it's being an issue in Plasma nowadays already.</div><div>I'll have a look on it<br>> - Maybe we can port the internal logging infrastructure to just use<br>> QLoggingCategory?</div><div>I'll try :)<br>> <br>> Cheers! :)<br>> Aleix<br></div> </div></body>
</html>