Re: notifications in gtk

2012-11-07 Thread Steve Frécinaux

On 11/06/2012 04:39 PM, Olav Vitters wrote:

Would a Qt/KDE application be able to show notifications as well? Would
this require freedesktop.org work, or is the intention to keep this
limited to GNOME shell implementation?


Also, what about Gnome/Gtk+-based applications on alternative desktop 
environments (XFCE, KDE) ? Would the client application also fall back 
to the existing dbus API ?


Shouldn't the existing API be evolved to meed the current requirements 
instead of creating a new, private, API ?


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: notifications in gtk

2012-11-06 Thread Olav Vitters
On Tue, Nov 06, 2012 at 10:23:40AM -0500, Matthias Clasen wrote:
 A new api
[..]
 Portability considerations
 
 - Most of the GtkNotification api can probably be implemented against
 org.freedesktop.Notifications (except the fire-and-forget aspects),
 and this is what I think we should start out with
 
 - The api that we are presenting here is fairly similar to OS X'
 NSNotification api, and should be easily implementable on top of it
 
 - After looking for notification apis on windows, we are confident
 that this api proposal is confident with the win8 notification
 guidelines and api ('toast'...). It will not be a very good fit for
 traditional icon+balloon messages.

Would a Qt/KDE application be able to show notifications as well? Would
this require freedesktop.org work, or is the intention to keep this
limited to GNOME shell implementation?

Wondering if you also looked at iOS and Android.

-- 
Regards,
Olav
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: notifications in gtk

2012-11-06 Thread Olav Vitters
On Tue, Nov 06, 2012 at 04:39:26PM +0100, Olav Vitters wrote:
 Wondering if you also looked at iOS and Android.

Ignore this, you obviously did.

-- 
Regards,
Olav
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: notifications in gtk

2012-11-06 Thread Matthias Clasen
On Tue, Nov 6, 2012 at 10:39 AM, Olav Vitters o...@vitters.nl wrote:

 Would a Qt/KDE application be able to show notifications as well? Would
 this require freedesktop.org work, or is the intention to keep this
 limited to GNOME shell implementation?

I envision the server-side would continue to offer the
org.freedesktop.Notifications interface for a long time - we can't
just drop it...
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: notifications in gtk

2012-11-06 Thread Cosimo Cecchi
On Tue, Nov 6, 2012 at 10:39 AM, Olav Vitters o...@vitters.nl wrote:

 Would a Qt/KDE application be able to show notifications as well? Would
 this require freedesktop.org work, or is the intention to keep this
 limited to GNOME shell implementation?

I don't think this proposal wouldn't change the current state of
things for Qt/KDE applications - the org.fdo.Notifications DBus
protocol we use today would still be supported as a fallback.

Cosimo
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: notifications in gtk

2012-11-06 Thread Kristian Rietveld

On Nov 6, 2012, at 4:23 PM, Matthias Clasen wrote:
 Problems with GtkStatusIcon
 
 - It is really centered around the idea that apps just export a small
 bit of their UI into the 'panel'
 
 - It assumes that all desktops want to offer a permanent place
 (system tray) for applications to present a clickable icon with a
 context menu
 
 - It requires the application to be running as long as its icon is
 present, essentially forcing a daemon mode onto applications (eg
 evolution-alarm-notify)
 
 - The X implementation uses XEmbed and can't really be made to work
 nicely in a composited environment
 
 - The win32 implementation is also problematic

I would argue the OS X implementation is also problematic. Showing the icon in 
the OS X menu bar is quite easy, however, in response we currently typically 
pop up a GtkMenu. This gives interesting problems with grabs/event handling. 
Also, it looks quite out of place because native applications show a native 
menu. The current GtkStatusIcon makes it close to impossible to automatically 
convert a GtkMenu into a native menu (e.g. custom menu items) and there's also 
the case where the status icon pops up something that's not a menu.



regards,

-kris.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: notifications in gtk

2012-11-06 Thread John Ralls

On Nov 6, 2012, at 8:01 AM, Kristian Rietveld k...@loopnest.org wrote:

 
 On Nov 6, 2012, at 4:23 PM, Matthias Clasen wrote:
 Problems with GtkStatusIcon
 
 - It is really centered around the idea that apps just export a small
 bit of their UI into the 'panel'
 
 - It assumes that all desktops want to offer a permanent place
 (system tray) for applications to present a clickable icon with a
 context menu
 
 - It requires the application to be running as long as its icon is
 present, essentially forcing a daemon mode onto applications (eg
 evolution-alarm-notify)
 
 - The X implementation uses XEmbed and can't really be made to work
 nicely in a composited environment
 
 - The win32 implementation is also problematic
 
 I would argue the OS X implementation is also problematic. Showing the icon 
 in the OS X menu bar is quite easy, however, in response we currently 
 typically pop up a GtkMenu. This gives interesting problems with grabs/event 
 handling. Also, it looks quite out of place because native applications show 
 a native menu. The current GtkStatusIcon makes it close to impossible to 
 automatically convert a GtkMenu into a native menu (e.g. custom menu items) 
 and there's also the case where the status icon pops up something that's not 
 a menu.

All very true. This *helps* Matthias's case to get rid of GtkStatusIcon.

Another point in favor of Matthias's proposal is dbus-independence. Dbus is 
great on Linux, but is a poor fit for OSX, and Win32. Dunno about Android, but 
iOS is decidedly daemon-hostile, so dbus isn't likely to happen there.

As an aside, has anyone ever gotten a Gtk-based program into the iTunes Store 
-- or the App Store, for that matter?

Anyway, all-in-all this looks very good to me.

Regards,
John Ralls


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: notifications in gtk

2012-11-06 Thread Matthew Barnes
On Tue, 2012-11-06 at 10:23 -0500, Matthias Clasen wrote:
 It has been clear for a while that GTK+ should provide an api to
 support notifications, so that applications don't have to a separate
 library (libnotify) for such a minor detail. Since our apis should
 serve the application designs that are implemented with it, lets have
 a look at these designs (for GNOME) before getting into the details:

Probably a naive question having not considered the implementation, but
I'm not seeing anything GTK-specific in the proposed API.  Is there any
reason this couldn't be bolted onto GApplication instead?

Matthew Barnes

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: notifications in gtk

2012-11-06 Thread Bastien Nocera
A couple of comments:
- Would system software (eg. battery notification) be using parts of
this API, or would we need to come up with our own helpers on top of the
D-Bus API?
- gtk_application_get_notifications() doesn't mention that activated
notifications will still be present if recurring.
- For recurring notifications (say, alarms), we have no way of knowing
for which GDateTime/GTimeSpan the display was for.
- What are the application use cases?
  - Alarm? (wake me up at 7AM every weekday not at the week-end, and
don't forget to amend for daylight saving changes; snooze)
  - Timer? (notify me in 10 minutes)
  - Music Player track notifications? (always visible, setting of the
image after the notification was shown for cover art)
  - Meetings (every Tuesday at 2 PM, but only until the end of the year;
every week until end of time, but not those 2 weeks I'm on holidays)
- it's unclear to me how applications that do light processing from the
network might behave when not running and an event occurs (weather
application with notifications turned on for a storm for example), is
that something we could use to extend GtkApplication with. iOS can go
and poke at the network on behalf of applications for example.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: notifications in gtk

2012-11-06 Thread Matthew Brush

On 12-11-06 07:23 AM, Matthias Clasen wrote:

It has been clear for a while that GTK+ should provide an api to
support notifications, so that applications don't have to a separate
library (libnotify) for such a minor detail. Since our apis should
serve the application designs that are implemented with it, lets have
a look at these designs (for GNOME) before getting into the details:

[snip]

Let us know what you think about this.



I hope it's not off-topic to give ideas/feedback in a usability sense 
here (as opposed to technical/API-wise).


Speaking strictly as a user, I absolutely 100% despise notification 
bubbles/overlays/distractions of all manner (whether attached to a 
status icon or not). The balloons famous for annoying Windows XP users 
are a good example and the libnotify ones (or whatever XFCE uses) being 
another good example of how to completely tear the user's attention away 
from what they're focusing on for what is 99% of the time not attention 
worthy.


Actually, one of my favourite things about OSX is that it does not have 
these annoying notifications (except when apps force them using 3rd 
party libraries that users have to disable). If OSX has something really 
important to tell you, it pops up a proper dialog box (ex. when the 
battery is almost depleted or updates need to be installed).


So just a few suggestions with my user hat on:

* There should be some HIGs describing when using them is a good idea 
(ex. low battery, hardware failure, etc.) to minimize the flagrant use 
of notifications that plagues Windows and Linux desktops (and oddball 
OSX apps) currently.


* On win32 and (certain) Linux DEs it could use the flashing of the 
window in the taskbar (not sure what it's called, the thing with the 
app's icon and window title that shows in the panel that you can click 
to (de)iconify windows) which, while still super annoying, is far less 
annoying than bubbles. One example of this is Firefox's Downloads dialog 
when a download finishes.[note1]


* On OSX it could use the feature where the app's icon in the dock does 
some little animated wiggling to let you know it needs your attention 
(which is again annoying as hell, but far less than popup 
overlays/bubbles). One example of this is Colloquy when someone pings 
you.[note1]


* An alternative for all 3 operating systems would be to just animate 
an icon in the panel's notification area. An example of this is XChat 
when someone pings you. This is by far the least annoying of all others 
I've encountered.[note1]


* It should be possible to globally disable all notifications entirely 
as opposed to simply per-application.


* No matter what, it shouldn't use the clichéd semi-transparent black 
overlays/HUD/OSD that everyone is using lately :) Regular old dialog 
boxes (with or without window decorations) have the advantage here since 
they'll naturally fit in with the users theme.


Just some ideas/feedback, feel free to ignore.

Cheers,
Matthew Brush

[note1] Obviously these do require a running, non-daemonized 
application, but perhaps they could be used as a default where the 
application is a normal running GUI application and real GtkDialog 
boxes could be used for background-type applications.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: notifications in gtk

2012-11-06 Thread Ross Burton
On Wednesday, 7 November 2012 at 01:23, Matthew Brush wrote:
 Actually, one of my favourite things about OSX is that it does not have
 these annoying notifications (except when apps force them using 3rd
 party libraries that users have to disable). If OSX has something really
 important to tell you, it pops up a proper dialog box (ex. when the
 battery is almost depleted or updates need to be installed).


Actually, Mountain Lion added the Notification Centre, which is essentially 
Growl plus a docked notification list.  http://www.apple.com/osx/whats-new/ has 
screenshots if you've never seen this in action.

Ross
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list