*** Bug 171907 has been marked as a duplicate of this bug. ***

I'm changing the description to be more precise

Please, oh most merciful OpenOffice maintainer, put us hapless KDE users out 
of our GTK misery! :-) Having just upgraded to FC5, we rush along eagerly to 
find out if at last OpenOffice has now got all that native Qt goodness. But 
oh, what do we find? The abomination of the "just-in-from-1998" GTK printing 
dialogue (it doesn't even display my printers (which do show up in the 
'Printer Settings' dialogue), which is another bug, but really, I just want 
that dialogue to die, not to be improved). The icons flicker horribly (and I'm 
not using gtk-qt-engine).

Trying to avoid the GTK-abomination, I run with "SAL_USE_VLCPLUGIN=gen" - but 
this just causes the whole thing to fall over when I open the printing 
dialogue. (Big crash).

Have pity on us! Bring back our openoffice.org-kde ! :-)

It's not even funny anymore... Is there any particular reason this plugins is
disabled in fedora builds? Licesning issue? Something else? Can you shed some light?

My hope here would be to modularize the OOo build to the extent that the KDE vcl
plugin can be built outside the rest of OOo and be seperately maintained by a
dedicated KDE-head. When the KDE plug was last available the maintainance
overhead of two different plugs was overwhelming.

Thank you for the information. Modularisation would be extremely nice,
especially if performed along with unleashing KDE.

I am not sure if I should add my comment here or not...

I am trying to get OpenOffice to use the default KDE file selector dialog when 
using the KDE desktop environment. This works fine with (K)ubuntu and OpenSUSE. 
On my Fedora box (FC6, x86_64, up to date) the "open" or "save as" dialog are 
not the KDE ones.

Is that also related to the absence of the KDE vcl plugin in the Fedora build? 

yes, that's part of the KDE specific OOo portion.

Thanks for clarifying. So if I understand well, the only way to have that 
feature working at the moment would be to use the binaries from OO.org and not 
the Fedora ones. And this vcl plugin might get activated at a later stage in 
the Fedora build when a modular version of OOo is used. Is there a roadmap for 
this? (I wonder as OOo 2.1 is now out).

This is a bit of problem.
OO is a core package - which means nobody can push the KDE support into extra.
Any possible solution?

- Gilboa

Core is planned to be opened for fc7 in in order to avoid such problems in future.

Re: comment #11, Gilboa, there are lots of Extras' packages that addon to Core
packages.  

There's nothing preventing it in this case, though suggesting that solution here
would be an insane amount of work and insanely innefficient to do so.  Have I
mentioned insane?

It would be far, far, far easier to simply (re)enable tke kde vcl plugin in
Core's ooo build.  It's like 1 configure switch, and 1 extra (kde) subpkg.  Have
I mentioned how much more easier this would be? (;

On the other hand enabling the KDE vclplug near doubles the amount of effect
required from me to support OOo, I'm not in a mad hurry to return to those
times. It was an endless pain in the ass.

Doing enough work on my side to make it possible to build it separately from the
rest of OOo and having it available for some other misfortunate to support
appeals better to me :-)

Caolan, thanks for clarification and rationale for not including it (though I
disagree your assertion of doubled workload).  So, shouldn't this be closed
WONTFIX, or just keep open indefinitely as a Wishlist item?

No leave it open, I have a plan(tm). At the last OOoCon I outlined a split of
the build into the URE (uno runtime engine) and non URE parts of OOo which will
take us towards building bits of OOo separately, with one of the end goals being
able to build the vcl plugs independantly.

Excellent.  Sounds like a good plan indeed. (:

Sounds great Caolan! Thanks for the update(s). Do you have any date/schedule in 
regarding this split of components? I.e. FC7, 8? Note, that I am *not* putting 
pressure here, just trying to find out when this might become available.

I'm hoping FC-7

*** Bug 247947 has been marked as a duplicate of this bug. ***

Any updates on this?

*** Bug 426117 has been marked as a duplicate of this bug. ***

Maybe one of us KDE folks can comaintain OO.o now that there's no longer 
separate Core and Extras? (I'm not sure I have the patience to sit through 
endless OO.o builds though, making things buildable separately would definitely 
help a lot.)

So is there a plan to split into a GNOME and KDE package?  I see that this bug 
report is over a year old and the maintainer said they would do this for F7.  

Created attachment 291302 [details]
proposed .src.rpm

*** Bug 428487 has been marked as a duplicate of this bug. ***

So what's the plan? Do you want one of us KDE SIG members to adopt this SRPM, 
submit it for review and maintain it?

Yeah, that's the plan. I need to get another spin of openoffice.org to get the
-devel package right and then fiddle with this .src.rpm to build the kde fpicker
as well and then go look for a volunteer to maintain the separate kde components.

Not *quite* there yet, but it'll be sorted out by end of next week I believe. 

Caolan:  Sorry to have bothered you with this duplicate.  I did search under
OpenOffice.org and dialog, and a few other combinations, but did not find this.

So, you are saying that if I use the 'generic' OOo binaries, I will get the
enhanced dialogs I desire?  I'd much rather abandon the Fedora binaries if this
is the case.

Finally, you seem to be saying that this feature will be available soon in the
Fedora binaries?  If so, I can wait.  If not, I'm going to get the 'vanilla'
package from OOo and begin using that.

Thanks for all your hard work.  You are appreciated.

Created attachment 291463 [details]
proposed src.rpm

Hmm, well here's how it would work to get the fpicker built. But there's an
interesting wrinkle. The actual kde fpicker code is *not* in openoffice.org. It
only seems to exist as a set of patchs in ooo-build and was never upstreamed
into the vanilla version.

So while this task is a pre-requisite for getting a kde fpicker it would be up
to the maintainer of this package to determine if they want to go and extract
those patches from ooo-build and apply them to this srpm to build the kde
fpicker (or help push ooo-build to upstream those patches into vanilla).

So wrt. Frank's question, what that means is that if you use the generic OOo
binaries you will not get a kde file picker either as it doesn't exist in the
canonical www.openoffice.org version AFAICS.

We'll see what we can do then. We appear to be the only major distribution not 
to use ooo-build as their upstream. :-(

I believe this small patch will need to be applied to the main OO.o package:
http://svn.gnome.org/viewvc/ooo-build/trunk/patches/src680/fpicker-common-scp2.diff?revision=8827&view=markup
(either with the #ifdef ENABLE_KDE omitted, or ENABLE_KDE needs to be set 
somewhere).

Sorry, disambiguating the "we"s here:

We (KDE SIG) will see what we (KDE SIG) can do then. We (Fedora) appear to be 
the only major distribution not to use ooo-build as their upstream. :-(

There's also this one which modifies common code to export a symbol needed by 
the KDE fpicker:
http://svn.gnome.org/viewvc/ooo-build/trunk/patches/src680/fpicker-kde-gcc4-visibility.diff?revision=9334&view=markup

OK, thanks, guys, for your fine efforts.  In the meantime I will just politely
add my voice to the chorus of those asking that this feature be implemented as
soon as you are reasonably able to do it.

Created attachment 291991 [details]
latest version

Oky doky, should build now with todays 2.4.0-2.2.fc9. I installed and tested it
under kde and it worked fine as far as I could see.

So all that's needed is someone to take ownership of this and turn it into a
package request. So NEEDINFO is the closest state to that. I suggest to just get
the vclplug in place, if afterwards the kde fpicker is patched in I'm happy to
make whatever changes are needed in the core bit to enable that.

I suggest sticking me as co-maintainer or at least allow commit rights and I'm
more than willing to keep it up to date and in sync with the rest of OOo. 

But I'm not really in a position to support possibly kde-specific vclplug
issues. So from my side all bugs with KDE running and -kde installed would
initially get reassigned to openoffice.org-kde for triage, but if they can be
shown to happen without -kde installed then moved to openoffice.org and I can
take care of them.

Caolan:

Please excuse my abject ignorance here.  What do I need to do to obtain the
fixed version of OOo that has the enhanced dialogs enabled in KDE?  As a
relatively non-technical end user, much of what is being discussed here is
beyond me.  Will it simply be included as an update that PUP will advise me about?

Thanks again for your hard work, and the hard work of the many others that make
this all possible.

Frank.

It will likely be in F9, otherwise you don't really have any current options
except to try and get "vanilla" rpms from www.openoffice.org (which still won't
have the fpicker though it will have the "render dialogs etc like kde does" ability)

Caolan:

Thanks.  I can wait.  I'm just very happy that it is coming.  :)

With the KDE-LiveCD, I imagine that more KDE users are going to join the fold.

I'll try to get this packaged ASAP, was busy with other stuff.

Any word on this?  I know it was suppose to make F9 but didn't.  This bug has been opened for sometime now.

*** Bug 598236 has been marked as a duplicate of this bug. ***