This "VCLSalFrame" is not wrong IMO, I suggested this on purpose as issue 70388
so that there is a single consistent name for OOo "VCLSalFrame" in at-poke
regardless of what the binary name of the launcher is called.

I can not reproduce the failure of issue 70361 with m195 on Solaris x86.

I also lowered the priority since AFAIK AT tools don't use the name of the
top-level object at all. If they do, it might make sense to set "OpenOffice.org"
as prgname as well (as we do for appname).

Orca uses the application name (the name of the top level at-spi object for an
application) as a means to determine which script to use.  For example, it looks
for an application name of 'gedit' for gedit and 'soffice.bin' for OOo.  A
somewhat meaningful application name is helpful as well for debugging purposes
(i.e., I'd have no clue that 'VCLSalFrame' is for OOo). It would be great if OOo
could use a consistent and meaningful name from release to release.

Wouldn't it be also helpful for ORCA to have a generic name like soffice.bin
instead of OpenOffice.org / StarOffice / StarSuite ? If so, I'd vote for
switching back to soffice.bin again (but now consistantly).

By all means - consistency is useful and we currently look for soffice.bin.  We
also do a regular expression match for SOffice strings we've seen in the past,
but I hate depending upon that and would much rather have soffice.bin.  Thanks!

Since the patch for issue 70388 has been integrated into OOo 2.1 as well, is
this issue considered important enough to be a stopper for 2.1 ?

We can handle crazy name changes in Orca (we had to do so, for example, with
Firefox because they kept on changing their name from release to release), so I
wouldn't consider this a show stopper.  But...I would highly encourage keeping
the name consistent and meaningful.

To give us more time to discuss the optimal solution, we reverted the patch for 70388 for OOo 2.1 
(OOE680), which makes a vanilla OOo build appear as soffice.bin again. However, it is still VCLSalFrame 
for OOo 2.2 (SRC680), so I raise the Priority again to make sure the final solution gets into OOo 2.2 in 
time.

What is speaking against a hardcoded  "soffice.bin" is that a) tools like unopkg, which use VCL as well, 
would expose "soffice.bin" as well and b) the ".bin" part is an implementation detail, which should not 
exposed as part of an application name.

OTOH using "OpenOffice.org" would result in several names for ORCA to check for (StarOffice, StarSuite 
...). 

By the ICCCM (we're talking about the WM_CLASS hint here) first there should be
parsing the commandline for "-name", if that fails look into the RESOURCE_NAME
environment variable, after that use an application name. This has been
VCLSalFrame for ages (well before OOo ever went OpenSource), only in the
gtkplugin it was never set until cmc's fix - which i still consider correct.

But of course no one ever uses "-name" and RESOURCE_NAME and ends up with the
hardcoded string anyway. Since this has been VCLSalFrame for ages i vote for
leaving it that way. Changing it to "soffice.bin" or "fnoerbl" has no advantage
at all IMHO. It should be ensured though, that all vcl plugins behave the same
way in this regard, which was what cmc's fix made happen.

Of course it's unfortunate that this issue did not come up earlier and thus we
created a situation where orca has a dependency on false behaviour on OOo's side.

Wouldn't that leed to VCLSalFrame being exposed for unopkg & co as well ? ORCA needs to be able to 
destinguish between these and OOo.

Also, where did you get from that the name set with g_set_prgname should be identical to WM_CLASS hint 
?

I'm not sure the ICCCM and the AT-SPI are tightly bound and whether they should
be.  However, consistency of name from release to release is far more important
than the name itself, as long as the name is pretty much unique across all apps.

Of course that would lead to all VCL frames having the class VCLSalFrame; as
would a hard "soffice.bin". And i got the notion that g_set_application_name and
g_set_prgname set the class hint from issue 70388. (WM_CLASS consists of two
strings, res_name and res_class).

However we could solve that by explicitly setting wm class for each frame when
initializing it, so that might obsolete g_set_prgname. Incidentally cmc wrote
initially that he wanted to set g_set_prgname for the benifit of atk, perhaps he
could explain what was really intended and whether or not that intention
included the WM_CLASS hint.

Yeah, just the WM_CLASS res_name.

I've the same goal as everyone else, that there's a consistent atk name for all
the OOo components that are typically launched from soffice -something.

The atk name seems to be just pulled from the WM_CLASS name. And the default
name for gtk apps for the wmclass_name defaults to the prgname, i.e.

static void
gtk_window_init (GtkWindow *window)
{
  ...
  window->wmclass_name = g_strdup (g_get_prgname ());
  window->wmclass_class = g_strdup (gdk_get_program_class ());
  ...
}

The reason that I care, is that without g_set_prgname the default prgname is the
name of the binary, typically soffice.bin, but we have some custom binary
launchers for OOo of swriter.bin, simpress.bin (in issuezilla somewhere or
other) etc which optimize the launching of those components and I want the name
to be the same regardless of which custom launcher is used.

so I suggested using X11SalData::getFrameResName to set the prgname as that ends
up as the wmclass_name by default. It seemed a good idea to make the gtk vclplug
consistent with the traditional gen plugin so that OOo had the same WM
properties regardless of the plugin in use.

So I don't really care what the WM_CLASS res_name is, I just wanted it to not be
different if launched from swriter.bin vs simpress.bin

So would it be a solution, if we use getFrameResName() for the WM_CLASS hint and
let g_set_prgname be defaulted to soffice.bin ? It seems to me that we just need
to dissolve the binding between gtk defaulting its WM_CLASS to g_get_prgname. Or
have i missed something ? Orca does not depend on WM_CLASS but on g_set_prgname,
yes ?

BTW: vcl69 just got integrated, so by virtue of issue 70779 the 680m196 will
have the VCLSalFrame name set.

Just discussed this with obr and we think the best solution is to set this
string from the application binary. This way we could have "soffice" for OOo and
Caolans startup binaries and "spadmin" for spadmin (as an example). Further the
GtkSalFrame should set its WM_CLASS hint explicitly (instead of inheriting
g_get_prgname), so it would get the VCLSalFrame string.

Any objections ?

Just to make sure I understand - would the following all result in a name of
soffice?

ooffice, oowriter, oocalc, ooimpress, socalc, sowriter, ...

If so, I think this is OK.  We sometimes wish we could more easily tell what
kind of content the user is navigating (i.e., are they in a spreadsheet, are
they in a document, are they in a presentation).  Do you know of a way we could
do that?

yes, ooffice, .... would result in the same name (all that use the same binary),
at least that's the plan.

About more context info: currently even OOo's own lower layers don't have that
info; we'd need an API that sets some kind of identifier on a window to do that.
The APi itself wouldn't be hard, just implementing it everywhere would be costly
- depending how fine a granularity one would want to achieve. Actually for a
correct WM_CLASS name this would be the preferred thing to do. Originally one of
those two strings (the res name) was for the benefit of the X resource system;
OOo just never used that resource system, so there never were such identifiers.

Created attachment 42365 [details]
Patch overriding the accessible name of the root object with Application::GetAppName

The following patch (applied in CWS atkbridge) uses Application::GetAppName() to set the name of the 
root accessible. Luckily, it is set to "soffice" /framework/desktop/source/app/app.cxx, line 1478.

For all VCL apps that do not set a unique AppName yet, VCLSalFrame will be the default (so we might need 
to add SetAppName calls to spadmin, unopkg, etc. ).

NOTE for Orca: there no longer is a trailing ".bin" in the name.

I'am sorry, but the previous changes come to late during office initialization,
so I had to revert. 

I also reverted the patch of i70388 and will re-open this issue.

The accessible name of the root accessible is back to "soffice.bin".

please verify.

Verified in cws atkbridge5

Ok in OOF_m5