Created attachment 43570 [details]
a simple patch

I'll leave "patch" unset as this isn't a solution for something trying to be
cross-windowing system

Could we search for gtk_recent_manager_get_default and
gtk_recent_manager_add_item in the global name table and use the functions when
we find them ? This would avoid linking against libgtk++ and serve as an
auto-detection as well ..

sounds reasonable to me, at least assuming that it works.

The dlsym approach seems to work (at least for me). However, due to "warning
free code" using dlsym outside of SAL has become even more ugly.

I will propose a SAL/OSL API for this purpopse.

obr - surely we can use the standard oslModule API to do this - right ? :-)

Wrt. detecting gtk+ - the approach sounds fine - elsewhere we hook
g_object_get_class ("GdkDisplay") to see if gtk+ is initialized too - worth
doing that I guess.

A load of distros still use gtk 2.8.x (at least SLED does), so clearly leaving
the old code to write the obsolete file in is best.

The existing OSL module API lacks support for the RTLD_DEFAULT special handle.
What I have in mind is something like "osl_getAsciiFunctionSymbol(oslModule,
const sal_Char *)", which explicitly allows to pass NULL as the first parameter
(and mapps it to RTLD_DEFAULT). I have to check for possible implementations on
Windows though.

ah; interestingly we need a similar API (using a const char *) in i#70166# :-)

Hmm, gtk_recent_manager_add_item uses g_get_prgname to construct the exec line,
which I just changed from soffice.bin to soffice in issue 70388. Fortunately
vanilla OOo has a "soffice" link in /usr/bin, but what about the bundled versions ? 

ah, well fedora has one.

The distributions using ooo-build should have had the symlink "/usr/bin/soffice"
 since OOo-2.0.4.

It is also used by the Java UNO components, see the section "Finding a UNO
installation" at
http://udk.openoffice.org/common/man/spec/transparentofficecomponents.html

Finally commited a fix in CWS obr05.

@tm: OOo now should use .recently-used.xbel when running on GNOME >= 2.10
desktop. Please verify also that .recently-used is still used on GNOME < 2.10.

checked and verified in cws obr05 -> OK !

closed

It appears that when upgrading from older versions and when user profile is
conserved, the fixed doesn't work (which is confirmed). This has been reported
in Ubuntu Gutsy, OO.o version 2.3.0, when upgrading from Feisty (version 2.2.0).
See https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/66933 for more
information.
Could you investigate further to find out how to fix/work around this? Thanks

Having built OOG680_m7 on FreeBSD 7.0-BETA3 on amd64 I get this when trying to
close the file or sometimes when opening:

gdb) list
676      */
677     GtkRecentManager *
678     gtk_recent_manager_new (void)
679     {
680       return g_object_new (GTK_TYPE_RECENT_MANAGER, NULL);
681     }
682
683     /**
684      * gtk_recent_manager_get_default:
685      *
(gdb) where
#0  IA__gtk_recent_manager_new () at gtkrecentmanager.c:681
#1  0x000000080f11a136 in IA__gtk_recent_manager_get_default () at
gtkrecentmanager.c:698
#2  0x000000080d51ab2c in SystemShell::AddToRecentDocumentList () from
/usr/local/openoffice.org-OOG680_m7/program/libsfx680fx.so

g_object_new fails:

(process:78374): GLib-GObject-CRITICAL **: gtype.c:2242: initialization
assertion failed, use IA__g_type_init() prior to this function
(process:78374): GLib-CRITICAL **: g_once_init_leave: assertion
`initialization_value != 0' failed
(process:78374): GLib-GObject-CRITICAL **: g_object_new: assertion
`G_TYPE_IS_OBJECT (object_type)' failed

Any idea why the type 'GTK_TYPE_RECENT_MANAGER' is not getting registered?
Is that because I'm not using mozilla integration?

Created attachment 50125 [details]
Turn the GTK Recent Manager feature off

Looks like in my case GTK does not get initialized at all.

I think either (at least) check with g_object_get_class should be implemented
or a proper setup of gtk types should take place.

I have attached a dirty patch that solves my issue - just by turning that GTK
thing off and reverting to the old method. 

Can we reopen this bug please?

So ... clearly we need a check to see if we are using gtk+ already, I guess.
That could be done in one of several ways.
The File picker does:

	OUString aDesktopEnvironment (Application::GetDesktopEnvironment());
	if (aDesktopEnvironment.equalsIgnoreAsciiCaseAscii ("gnome"))
		return OUString (RTL_CONSTASCII_USTRINGPARAM
("com.sun.star.ui.dialogs.GtkFilePicker"));

It's possible that we need to do a "g_type_init", followed by a:
g_object_get_class ("GdkDisplay") != NULL to check that we are using the gtk+
plug before using that code.

Or failing that, just the g_type_init I guess.

Reset target.

Created attachment 52382 [details]
Patch to remove GTK recent file manager functionality (for now)

This feature got integrated together with obr05 into MWS and is still present
there as of DEV300_m5. 

http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=SRC680%2Fobr05

What's the process of backing this out?

Add CC CWS owner

Created attachment 52789 [details]
alternative approach

a) I assume that your desktop environment is KDE or something ?
b) How about trying the above alternative patch along mmeeks suggestion (as used
in other similar shell components), does that resolve your problem ?

If it does (or even if it doesn't actually) then I suggest we open another
issues for the specific issue of non-gtk using environments and attach the patch
rather than following the alternative approach of rolling back the changes done
for this originally issue which of course would return to the previous state of
not working with >= gnome 2.10

I am using few other window managers (fluxbox, dwm, etc.). It should not matter
what desktop environment I am in, since this is all X11.

However, I _do_ have gtk library installed (also qt* for that matter). 

X11 has really no idea of the "desktop environment" and I think this is not so
bad. It does not really matter (as long as it's X11 and not Windows/Aqua of course).

The problem with this approach is that GTK is not getting initialized
*anywhere*. This patch attempts to dynamically use GTK features without
initializing it. It may work if something *else* by chance registers GTK types.
Do you know how this happens? (Mozilla integration or something else?)

Besides, why should the gtk recent file list updated _only_ when we are running
GNOME environment? There are possibly other applications that can use this list
and GNOME is not required for that?

My proposal is to have a separate GTK integration component, that will (1) check
if gtk is there, (2) what features it supports (i.e. "is this gtk new enough to
support recent manager and system tray" (3) initialize GTK properly.

I like g_object_get_class()-like much better because it does not imply to much
about my environment - it checks the *right thing* straight away.

Then you can use window-manager-based guesses to determine whether user wishes
to have GNOME, KDE or whatever File->Open dialog. Since I personally dislike
GNOME "improved" file dialogs I wish I am not stuck with it just because the gtk
is available on my system.

We *may* work it around the same way as external/libegg/source/eggtrayicon.c is
doing, but I don't think it's worth it in the long run. 

In the last weeks we got at least few persons suddenly complaining "cannot save
ODT files", "OOO crashes", etc. etc. on the FreeBSD lists and I don't think this
feature is worth it. It just makes too many environmental assumptions.

That's why I think it is important to backout this feature for now out of the
main tree and continue working on this and other aspects of GTK integration.

I will be more than happy to work on this as well. I will also have a look at
your patch as soon as I get my DEV300_m5 working again. 

> The problem with this approach is that GTK is not getting initialized
> *anywhere*. This patch attempts to dynamically use GTK features without
> initializing it. It may work if something *else* by chance registers GTK 
> types.

The code looks for gtk symbols in the process's address space, it does not load
gtk itself and assumes the code that brings in does so. I admit this may easily
fail if some other module links against libgtk unnecessarily.

If the gtk backend is used, libgtk is initialized properly. This can even be
enforced (for testing) by setting the SAL_USE_VCLPLUGIN environment variable to
"gtk".

Maybe we should just move the code over to VCL ?

> Since I personally dislike GNOME "improved" file dialogs I wish I am not stuck
> with it just because the gtk is available on my system.

Tools -> Options -> OpenOffice.org -> General -> Use OpenOffice.org dialogs is
your friend.

I want to basically move this into vcl 

*** This issue has been marked as a duplicate of 104306 ***

close as duplicate of new effort