Colin Walters wrote:
> The main tricky situation comes when the app implements
> single-instance behavior internally, and does some sort of IPC (dbus,
> whatever) to talk to an existing instance. In GNOME 3 this doesn't
> matter as much because we do single-instance by default, but otherwise
> it'
Could you help me to fix qtiplot? After I add StartupNotify=true to
qtiplot.desktop, it times out instead of disappearing when the app window comes
up under gnome2.
Regards,
Chen Lei
On 2010-03-15 23:07:02，"Colin Walters" wrote：
>On Mon, Mar 15, 2010 at 10:44 AM, Chen Lei wrote:
>> Should
Hi Mary,
On Mon, Mar 15, 2010 at 11:14 AM, Mary Ellen Foster wrote:
>
> Well, for Firefox at least, it's option 2 and has been for a while (at
> least under KDE):
> https://bugzilla.redhat.com/show_bug.cgi?id=445543
I guess I should take some time to fix the most important app, yes.
This turn
On Mon, Mar 15, 2010 at 1:07 AM, Colin Walters wrote:
> Hi,
>
> For GNOME 3 to more reliably do application tracking, we will be
> associating through startup-notification. Some background here:
>
> http://lists.freedesktop.org/archives/xdg/2010-February/011321.html
>
> However for startup notifi
On 15 March 2010 15:07, Colin Walters wrote:
> On Mon, Mar 15, 2010 at 10:44 AM, Chen Lei wrote:
>> Should we also add StartupWMClass=someting if StartupNotify=true doesn't
>> work?
>
> You're going to need to elaborate on "doesn't work".
>
> * You don't see a "Starting..." notification in the t
On Mon, Mar 15, 2010 at 10:44 AM, Chen Lei wrote:
> Should we also add StartupWMClass=someting if StartupNotify=true doesn't
> work?
You're going to need to elaborate on "doesn't work".
* You don't see a "Starting..." notification in the tasklist in GNOME 2?
* You do, but it times out instead o
Should we also add StartupWMClass=someting if StartupNotify=true doesn't work?
在2010-03-15 22:33:58，"Colin Walters" 写道：
>On Sun, Mar 14, 2010 at 5:40 PM, Ville Skyttä wrote:
>>
>> If an app uses GTK+ or Qt, does that alone always imply that it satisfies the
>> desktop entry spec's requirement
On Sun, Mar 14, 2010 at 5:40 PM, Ville Skyttä wrote:
>
> If an app uses GTK+ or Qt, does that alone always imply that it satisfies the
> desktop entry spec's requirements for StartupNotify=true, i.e. no further
> examination of the app's behavior is necessary?
The main tricky situation comes when
On Sun, Mar 14, 2010 at 6:35 PM, Victor Vasilyev
wrote:
>
> FYI When the StartupNotify=true was specified in the desktop file of the
> NetBeans I've seen bugs in launching of the NetBeans' child processes
> (e.g FireFox [3]) due to the DESKTOP_STARTUP_ID environment variable. It
> was fixed in the
Michael Schwendt wrote:
> On Sun, 14 Mar 2010 15:37:24 -0400, Colin wrote:
>
> Currently can only find:
> https://fedoraproject.org/wiki/Packaging:Guidelines#Desktop_files
>
> | Installed .desktop files MUST follow the desktop-entry-spec , paying
> | particular attention to validating correct usage
On Sunday 14 March 2010, Colin Walters wrote:
> If you maintain a desktop app, please check for StartupNotify=true,
> and if your app uses GTK+ or Qt, then please submit a patch *upstream*
> to add it, and at your option apply that patch in Fedora.
If an app uses GTK+ or Qt, does that alone alway
On Sun, 14 Mar 2010 15:37:24 -0400, Colin wrote:
> However for startup notification to work, for compatibility reasons,
> the upstream .desktop file must have StartupNotify=true. It's come to
> my attention that a lot of .desktop files are missing this, even
> though they use GTK+.
Hmmm, I'm ce
Hi,
For GNOME 3 to more reliably do application tracking, we will be
associating through startup-notification. Some background here:
http://lists.freedesktop.org/archives/xdg/2010-February/011321.html
However for startup notification to work, for compatibility reasons,
the upstream .desktop fil
13 matches
Mail list logo
