Hello, all.
Aurélien, I think, you're absolutely right about main window, so I
implemented it in m-s-m.
However, I'd like to point out the non-sound-menu-related moment,that
such dbus-menu api would be useful for plain applications (e.g.
something like transmission, but written in Qt) providing their own
non-grouped application indicator.
Also, I've found the moment, which I suppose Conor can explain. Now
applications with canRaise()==false and with canRaise()==true are
similar in behaviour — they all provide the menuitem with the
application name and that menuitem can be clicked, whether it would
really raise the application window or not.
May be it should be changed somehow?
----
Best wishes and have a nice day,
Vsevolod Velichko
2011/1/17 Aurélien Gâteau<aurelien.gateau@xxxxxxxxxxxxx>:
I see your point. The only suggestion I would have is for m-s-m to provide a
main window. Even if it is very simple and only used for configuration.
It should be more discoverable than having everything in the sound menu
anyway, because when the user start m-s-m for the first time he will most
probably expect to be greeted by a window so that he can define the
necessary settings.
I am thinking about pointing to the mpd instance on the network, starting an
instance maybe? also whether m-s-m should be started at login (I assume this
is the kind of application which users would want to start at login). You
just have to make sure your application keeps running when the user closes
the window.
_______________________________________________
Mailing list: https://launchpad.net/~indicator-sound-developers
Post to : indicator-sound-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~indicator-sound-developers
More help : https://help.launchpad.net/ListHelp
