Hide Forgot
Hi. Why is kde vcl plugin disabled in fedora openoffice.org packages? It is enabled in vanilla build. Have a look at the url. Also look at pl's first comment. According to it, gtk plugin does not work that well under kde. So IMO the best idea wold be to enable the kde vcl plugin in the offivial openoffice builds. Greets.
*** 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. ***