indicator-sound-developers team mailing list archive

[Vsevolod Velichko <torkvema@xxxxxxxxx>]

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.