Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#5 On screen display ported to KNotify4 (only Linux)

open
nobody
None
5
2013-01-13
2010-08-06
Richard Plangger
No

Ported the OSD to KNotify. Works fine with KDE.

Windows & Mac using the old OSD System.

TODO: Test on Windows Mac and decide it port it to KNotify or leaf it! ( I'm not using windows at all, so i cant do it )

Discussion

  • OSD to KNotify

     
    Attachments
  • Peter Grasch
    Peter Grasch
    2010-08-07

    The patch you uploaded is not complete. It for examples changes the not yet existing simon.notifyrc.

    However, as far as I can tell you just did a direct port of showMessage() to knotify.

    To take full advantage of the configurability of knotify, you should grep the source code for showMessage() calls and identify individual types of messages. For example:
    * Command notifications
    * Connection notifications (connected, disconnected, activated, etc.)
    * Filter

    Some other calls (like the one telling you to move the word from the the vocabulary to the training pane on the right to train it) should probably be simply removed and again others (like the error reporting in the calculator) should probably be ported to something else entirely (like a label right in the calculator widget that auto-hides after the given time).

    Btw, the requester of this feature at least told me that knotify was available on windows. Also, Mac OS X is not yet supported at all.

     
  • I would suggest to split the class SimonInfo into SimonSplash and SimonNotification.

    SimonSplash becasue the biggest part of SimonInfo is the KSplashScreen and not information.
    SimonNotification displays the old OSD messages via KNotify. To identify the notif. you call different static methods on SimonNotification and not only showMessage().

    What you think?

    (cause the biggest part of the SimonInfo class is the start splashscreen and not information)

     
  • remove "(cause the biggest part of the SimonInfo class is the start splashscreen
    and not information) "

    why can't i edit my own comment?

     
  • Peter Grasch
    Peter Grasch
    2010-08-08

    I completely agree to split the classes. Go ahead!

    However, the different static functions work well when looking at the whole of simon (including its plugins) as one entity but in practice the simoninfo library should not know what notifications are going to be displayed through it (seeing as this could also be used from 3rd party plugins).

    Without looking at the knotify documentation: How do they identify the different notifications? Is it some type of ID?

     
  • In the constructer you set the eventId string defined in simon.notifirc (the missing file). That could be an identification, but you can raise more events of one eventId. So there is also the actionId (Integer) when the notif. is clicked.
    Of coure you can set an ObjectName to truely identify the KNotifiaction as it is inherted from QObject.

    What would you suggest beside static methods?

     
  • Splitted SimonInfo int SimonNotification and SimonSplash

     
    Attachments
  • Added a new patch containing the new SimonSplash and SimonNotification classes.

    Now i have to modify SimonNotification to fit our special needs (now its still a direct port from OSD to KNotification class)

     
  • Peter Grasch
    Peter Grasch
    2010-08-09

    Thanks for the updated patch.

    A view notes:
    * Please remove the check for Darwin; It really is nice that you thought of it but nothing in simon supports OS X and notifications would be the least of our problems :) Also, this of course brings up an issue in Krazy (because you don't use the HAVE_ macro).
    * At the notifyrc: It's "simon listens" not "Simon Listening"
    * You should add the notification configuration to the simon main window;

    Also an architectural problem: The OSD implementation can not be directly ported. For example, the OSD is also used in ksimond which won't use the simon.notifyrc (because the appname there is ksimond).

    I don't think there is plugging for notifyrcs (like there is with translations) so adding new types of events from plugins seems out of the question.

    To identify the individual events you will probably want to pass the id of the notification to the showMessage function so you could add a fallback there to the static event() function if it's not in the notifyrc.

    However the cleanest solution would probably to port the whole notification system over to kttsd (if it works well on windows) and ditch the notification stuff from the simoninfo library completely. Then the plugins (and ksimond) could have their own config file.

    This would leave how to configure the plugins notifications but that shouldn't be hard to solve.

    For now this is what I'd do:
    Move the notifyrc to simon (form simonlib) and add another for ksimond;
    Add the different types of the events including one "command" or something for the plugins;
    Add a protected showMessage function in the commandmanager that calls simoninfo with the first parameter fixed to the plugins notification type and port the calls in the plugins to this new call.

    I think that's a good compromise for now...

    Regards,
    Peter

     
  • Updated version

     
    Attachments
  • I updated the patch like your description in the last comment!

    What do you mean with:
    "* You should add the notification configuration to the simon main window"

    plan_rich

     
  • some missing files!

     
    Attachments
  • Peter Grasch
    Peter Grasch
    2010-08-26

    Thanks for the update.

    I'm on holiday right now so I can't really look into it but it looks a lot better IMHO.

    What I meant with adding it to the main window is that you usually see a "Configure notifications..." entry in the settings of an application using KNotify. Ther you can adjust the notifications to e.g. use sounds, text to speech, etc.

    Regards,
    Peter