Today I updated LibreOffice to version 3.4.2. The Slackware package is nothing more than a converted RPM from the upstream Open Document Foundation (ODF).
There is no support for KDE3 file picker dialog boxes. No option even exists in the Options.
I'm using 3.5.10, which is not Trinity, but I'm guessing if the upstream RPM from ODF is like this then Trinity likely gets miffed too.
How do we convince the ODF developers to directly provide KDE3/Trinity support upstream when they build their official release?
Darrell
Today I updated LibreOffice to version 3.4.2. The Slackware package is nothing more than a converted RPM from the upstream Open Document Foundation (ODF).
There is no support for KDE3 file picker dialog boxes. No option even exists in the Options.
I'm using 3.5.10, which is not Trinity, but I'm guessing if the upstream RPM from ODF is like this then Trinity likely gets miffed too.
How do we convince the ODF developers to directly provide KDE3/Trinity support upstream when they build their official release?
Darrell
By providing a plugin that is maintained by the official TDE project. That is on our to-do list, but has not yet been started.
Essentially the following must happen: 1.) Pull the KDE3 picker code (including build script alterations) from the OpenOffice 3.2 / TDE 3.5.12 builds on QuickBuild. 2.) Ensure that they apply to LibreOffice and produce working binaries on TDE 3.5.13 with Qt3. 3.) Convert to TQt (a simple process that I can do in a day or so AFAIK) and rename all "KDE" strings to "TDE". 4.) Rebuild, test, etc. until everything works properly. 5.) Push the patches into our GIT and notify LibreOffice that we have a new plugin for them!
Volunteers are welcome as usual. ;-)
Tim
On Wednesday 17 August 2011 04:15:03 Timothy Pearson wrote:
There is no support for KDE3 file picker dialog boxes. No option even exists in the Options.
I'm using 3.5.10, which is not Trinity, but I'm guessing if the upstream RPM from ODF is like this then Trinity likely gets miffed too.
How do we convince the ODF developers to directly provide KDE3/Trinity support upstream when they build their official release?
Darrell
By providing a plugin that is maintained by the official TDE project. That is on our to-do list, but has not yet been started.
What plugin if nobody removed KDE3 support from LibreOffice?
Essentially the following must happen: 1.) Pull the KDE3 picker code (including build script alterations) from the OpenOffice 3.2 / TDE 3.5.12 builds on QuickBuild.
Why namely from 3.2? It works well in my 3.3.3 as well.
2.) Ensure that they apply to LibreOffice and produce working binaries on TDE 3.5.13 with Qt3. 3.) Convert to TQt (a simple process that I can do in a day or so AFAIK) and rename all "KDE" strings to "TDE". 4.) Rebuild, test, etc. until everything works properly. 5.) Push the patches into our GIT and notify LibreOffice that we have a new plugin for them!
Big plans, only why if the current LO builds well with KDE3 support?
On Wednesday 17 August 2011 04:15:03 Timothy Pearson wrote:
There is no support for KDE3 file picker dialog boxes. No option even exists in the Options.
I'm using 3.5.10, which is not Trinity, but I'm guessing if the
upstream
RPM from ODF is like this then Trinity likely gets miffed too.
How do we convince the ODF developers to directly provide KDE3/Trinity support upstream when they build their official release?
Darrell
By providing a plugin that is maintained by the official TDE project. That is on our to-do list, but has not yet been started.
What plugin if nobody removed KDE3 support from LibreOffice?
Essentially the following must happen: 1.) Pull the KDE3 picker code (including build script alterations) from the OpenOffice 3.2 / TDE 3.5.12 builds on QuickBuild.
Why namely from 3.2? It works well in my 3.3.3 as well.
This was a starting point; I know the code in 3.2 works because I patched and tested it myself on a large deployment of Linux. Of course if the newer versions work then that is good.
2.) Ensure that they apply to LibreOffice and produce working binaries on TDE 3.5.13 with Qt3. 3.) Convert to TQt (a simple process that I can do in a day or so AFAIK) and rename all "KDE" strings to "TDE". 4.) Rebuild, test, etc. until everything works properly. 5.) Push the patches into our GIT and notify LibreOffice that we have a new plugin for them!
Big plans, only why if the current LO builds well with KDE3 support?
And you will guarantee that the upstream LibreOffice project continues to build an unmaintained plugin just for us? In my experience unmaintained code in a project is usually purged after it creates a nontrivial build failure, if not sooner. Besides, the main distributions have spoken and they are NOT building the KDE3 plugin for us, which means that it is in especially high danger of being purged from the upstream codebase due to low usage.
Tim
On Wednesday 17 August 2011 06:07:16 Timothy Pearson wrote:
And you will guarantee that the upstream LibreOffice project continues to build an unmaintained plugin just for us?
Once it is not included then fork it. There is no problem right now.
On Wednesday 17 August 2011 06:07:16 Timothy Pearson wrote:
And you will guarantee that the upstream LibreOffice project continues to build an unmaintained plugin just for us?
Once it is not included then fork it. There is no problem right now.
I think it would be better to get a new plugin into LibreOffice before the KDE3 one is dropped, as this will avoid the whole unpleasantness that goes along with trying to re-add a dropped component (and many times prevents the new component from being included in the upstream project). It would also minimize the impact to users, who theoretically could end up without Trinity integration for at least one LibreOffice release cycle.
Tim
On Wednesday 17 August 2011 06:41:53 Timothy Pearson wrote:
On Wednesday 17 August 2011 06:07:16 Timothy Pearson wrote:
And you will guarantee that the upstream LibreOffice project continues to build an unmaintained plugin just for us?
Once it is not included then fork it. There is no problem right now.
I think it would be better to get a new plugin into LibreOffice before the KDE3 one is dropped, as this will avoid the whole unpleasantness that goes along with trying to re-add a dropped component (and many times prevents the new component from being included in the upstream project). It would also minimize the impact to users, who theoretically could end up without Trinity integration for at least one LibreOffice release cycle.
You mean you want to write a new plugin? :-\
Does it mean you also want to rewrite the styles support, address book support etc?
On Wednesday 17 August 2011 06:41:53 Timothy Pearson wrote:
On Wednesday 17 August 2011 06:07:16 Timothy Pearson wrote:
And you will guarantee that the upstream LibreOffice project
continues
to build an unmaintained plugin just for us?
Once it is not included then fork it. There is no problem right now.
I think it would be better to get a new plugin into LibreOffice before the KDE3 one is dropped, as this will avoid the whole unpleasantness that goes along with trying to re-add a dropped component (and many times prevents the new component from being included in the upstream project). It would also minimize the impact to users, who theoretically could end up without Trinity integration for at least one LibreOffice release cycle.
You mean you want to write a new plugin? :-\
NO!!
Does it mean you also want to rewrite the styles support, address book support etc?
No, not at all. See my second Email that crossed yours to the list :-)
Tim
On Wednesday 17 August 2011 06:07:16 Timothy Pearson wrote:
And you will guarantee that the upstream LibreOffice project continues to build an unmaintained plugin just for us?
Once it is not included then fork it. There is no problem right now.
I think it would be better to get a new plugin into LibreOffice before the KDE3 one is dropped, as this will avoid the whole unpleasantness that goes along with trying to re-add a dropped component (and many times prevents the new component from being included in the upstream project). It would also minimize the impact to users, who theoretically could end up without Trinity integration for at least one LibreOffice release cycle.
Tim
Thinking about this some more, I wonder if we can take ownership of the old KDE3 plugin and just rename it/patch it upstream. That would probably be easiest and produce a minimal amount of work for both us and LibreOffce.
The downside, of course, is that KDE3 support for versions <= 3.5.10 would be removed. I will dig around in the build system a bit as I have time and see what can be done.
Tim
On Wednesday 17 August 2011 06:54:45 Timothy Pearson wrote:
I think it would be better to get a new plugin into LibreOffice before the KDE3 one is dropped, as this will avoid the whole unpleasantness that goes along with trying to re-add a dropped component (and many times prevents the new component from being included in the upstream project). It would also minimize the impact to users, who theoretically could end up without Trinity integration for at least one LibreOffice release cycle.
Tim
Thinking about this some more, I wonder if we can take ownership of the old KDE3 plugin and just rename it/patch it upstream.
Why do you think it needs patching? It works well.
That would probably be easiest and produce a minimal amount of work for both us and LibreOffce. The downside, of course, is that KDE3 support for versions <= 3.5.10 would be removed.
Why do you want to break it?
I will dig around in the build system a bit as I have time and see what can be done.
Is something needs to be done actually if all works well?
On Tue, Aug 16, 2011 at 23:25, Ilya Chernykh anixxsus@gmail.com wrote:
On Wednesday 17 August 2011 06:54:45 Timothy Pearson wrote:
I think it would be better to get a new plugin into LibreOffice before the KDE3 one is dropped, as this will avoid the whole unpleasantness that goes along with trying to re-add a dropped component (and many times prevents the new component from being included in the upstream project). Â It would also minimize the impact to users, who theoretically could end up without Trinity integration for at least one LibreOffice release cycle.
Tim
Thinking about this some more, I wonder if we can take ownership of the old KDE3 plugin and just rename it/patch it upstream.
Why do you think it needs patching? It works well.
TQt intergration.
That would probably be easiest and produce a minimal amount of work for both us and LibreOffce. The downside, of course, is that KDE3 support for versions <= 3.5.10 would be removed.
Why do you want to break it?
KDE3 is technically obsolete.
I will dig around in the build system a bit as I have time and see what can be done.
Is something needs to be done actually if all works well?
Not with Trinity. See above.
On Wednesday 17 August 2011 07:33:20 Robert Xu wrote:
TQt intergration.
Not with Trinity. See above.
I think the reason why it does not work in Ubuntu is different.
On the other hand if the problem is actually in that it is not conpatible with tqtintegface, and requires rewrite, this shows that you people went too far in breaking compatibility with existing KDE3 software.
On Tue, Aug 16, 2011 at 23:43, Ilya Chernykh anixxsus@gmail.com wrote:
On Wednesday 17 August 2011 07:33:20 Robert Xu wrote:
TQt intergration.
Not with Trinity. See above.
I think the reason why it does not work in Ubuntu is different.
What do you mean?! it works in Ubuntu.
On the other hand if the problem is actually in that it is not conpatible with tqtintegface, and requires rewrite, this shows that you people went too far in breaking compatibility with existing KDE3 software.
I am so confused now. What are you getting at? What doesn't make sense? It's easy to be compatible with TQt - it doesn't need a complete rewrite. It's not so hard to put a T in front of every Qt call.
We didn't break compat with existing KDE3 at all. We're just making it easier to port to Qt4 when the time comes.
On Wednesday 17 August 2011 07:46:40 Robert Xu wrote:
TQt intergration.
Not with Trinity. See above.
I think the reason why it does not work in Ubuntu is different.
What do you mean?! it works in Ubuntu.
I meant KDE3 integration.
On the other hand if the problem is actually in that it is not conpatible with tqtintegface, and requires rewrite, this shows that you people went too far in breaking compatibility with existing KDE3 software.
I am so confused now. What are you getting at? What doesn't make sense? It's easy to be compatible with TQt - it doesn't need a complete rewrite. It's not so hard to put a T in front of every Qt call.
And why to do this if anyone just can call plain Qt3? Why do you need libreoffice to call tqtinterface rather than just Qt?
We didn't break compat with existing KDE3 at all. We're just making it easier to port to Qt4 when the time comes.
Libreoffice has its own front-end for Qt4. Just use this front-end when your system is built against Qt4.
On Tue, Aug 16, 2011 at 23:43, Ilya Chernykh anixxsus@gmail.com wrote:
On Wednesday 17 August 2011 07:33:20 Robert Xu wrote:
TQt intergration.
Not with Trinity. See above.
I think the reason why it does not work in Ubuntu is different.
What do you mean?! it works in Ubuntu.
<snip>
WHOA!
Everyone CALM DOWN!
First: Ilya, by your logic, we would be using green screen terminals still. Be careful; progress must continue. This project merely views "progress" differently than the KDE4 "throw everything out the window" paradigm. Please do not confuse this project with keeping KDE3.5.10 on ice, which apparently is what you are doing and want to continue to do. Good luck with that.
Second: I was merely thinking out loud. With trolls on this list apparently that is a bad idea; I will save my ideas for the meeting, where things have been more civil.
Third: I do not need to break the existing KDE3.5.10 plugin, but over time it WILL break itself. Good luck keeping it running when Qt3.3.8b won't even build anymore.
Fourth: For now we are keeping the upstream plugin. My entire train of thought here has been an attempt to be PROACTIVE instead of RETROACTIVE in fixing major functionality regressions. Having no part in the development of the upstream LibreOffice plugin is NOT a good thing, and has the potential to cause a MAJOR USER-VISIBLE regression if upstream dumps it or breaks it without our knowleged.
I will say no more on this topic for now.
Tim
On Wednesday 17 August 2011 07:53:17 Timothy Pearson wrote:
Second: I was merely thinking out loud. With trolls on this list apparently that is a bad idea; I will save my ideas for the meeting, where things have been more civil.
Third: I do not need to break the existing KDE3.5.10 plugin, but over time it WILL break itself. Good luck keeping it running when Qt3.3.8b won't even build anymore.
Instead of accusing me of trolling here you better should recalll that we use your patched version of Qt3. They are API-wise backward compatible and there is actually no need for rewriting anything that depends on purely Qt3.
Fourth: For now we are keeping the upstream plugin. My entire train of thought here has been an attempt to be PROACTIVE instead of RETROACTIVE in fixing major functionality regressions. Having no part in the development of the upstream LibreOffice plugin is NOT a good thing, and has the potential to cause a MAJOR USER-VISIBLE regression if upstream dumps it or breaks it without our knowleged.
OK, if you are talking just about obtaining accounts in their development system "de bene esse".
I will say no more on this topic for now.
On Wednesday 17 August 2011 07:53:17 Timothy Pearson wrote:
Second: I was merely thinking out loud. With trolls on this list apparently that is a bad idea; I will save my ideas for the meeting, where things have been more civil.
Third: I do not need to break the existing KDE3.5.10 plugin, but over time it WILL break itself. Good luck keeping it running when Qt3.3.8b won't even build anymore.
Instead of accusing me of trolling here you better should recalll that we use your patched version of Qt3. They are API-wise backward compatible and there is actually no need for rewriting anything that depends on purely Qt3.
API, yes. ABI, no.
Qt3 has several flaws in it that have, over time, spawned nasty hacks in the original KDE3 (now Trinity) source. These hacks are a constant source of consternation for our development team; they cause things to randomly crash or fail in a nonreproducible manner. One of our goals is to add new methods to Qt3 in order to clean up the hacks in the Trinity source, thereby stabilizing the system.
One of the bugs causes a crash sporadically when the filter bar is used in icon mode. The cause is a missing visibility set feature in QIconView. The only resolution is to fix Qt3. There are other examples, but I hope you get my drift.
Regarding trolling, you did make a very strong accusation and threat to me earlier (regarding LibreOffice and contacting the dev team), and very strongly asserted that you want to keep KDE3.5.10, which is long dead, available. Be careful what you say if you don't want to be judged.
By the way, if you continue to use the Qt C++ namespace you will run into problems eventually. Technically you are stepping on the toes of Qt4 and any applications built with Qt4, which is not a good thing to do. This namespace collision is at the heart of why Qt4 cannot render Qt3 widget styles and themes, as well as why Qt4 features cannot be utilized in Trinity. I refuse to halt progress in moving to the TQt namespace, which would open the door to a number of features including a good KHTML replacement, just to retain perfect compatibility with the long-obsolete KDE3.5.10 release.
I hope this clarifies some things.
Tim
On Wednesday 17 August 2011 08:16:37 Timothy Pearson wrote:
Second: I was merely thinking out loud. With trolls on this list apparently that is a bad idea; I will save my ideas for the meeting, where things have been more civil.
Third: I do not need to break the existing KDE3.5.10 plugin, but over time it WILL break itself. Good luck keeping it running when Qt3.3.8b won't even build anymore.
Instead of accusing me of trolling here you better should recalll that we use your patched version of Qt3. They are API-wise backward compatible and there is actually no need for rewriting anything that depends on purely Qt3.
API, yes. ABI, no.
And API is what we need to have LO working.
Qt3 has several flaws in it that have, over time, spawned nasty hacks in the original KDE3 (now Trinity) source. These hacks are a constant source of consternation for our development team; they cause things to randomly crash or fail in a nonreproducible manner.
No crashes for more than a year here.
One of our goals is to add new methods to Qt3 in order to clean up the hacks in the Trinity source, thereby stabilizing the system.
Good endeavor.
One of the bugs causes a crash sporadically when the filter bar is used in icon mode. The cause is a missing visibility set feature in QIconView. The only resolution is to fix Qt3. There are other examples, but I hope you get my drift.
Good. Is this patch already included in 3.3.8c?
Regarding trolling, you did make a very strong accusation and threat to me earlier (regarding LibreOffice and contacting the dev team),
This is not threat, just a fact. If somebody will try to make contributions that break work of our desktop, we will complain. A similar situation happened recently when the Gnome3 developer made a commit to the Suse settings that broke kcontrol.
and very strongly asserted that you want to keep KDE3.5.10, which is long dead, available.
Is it trolling? By the way if Robert would advance in packaging Trinity we would consider using Trinity now.
Be careful what you say if you don't want to be judged.
I just do not bother with your offenses.
By the way, if you continue to use the Qt C++ namespace you will run into problems eventually. Technically you are stepping on the toes of Qt4 and any applications built with Qt4, which is not a good thing to do.
Sorry I do not understand this. Which collisions are you speaking about? Collisions of filenames or something else?
This namespace collision is at the heart of why Qt4 cannot render Qt3 widget styles and themes, as well as why Qt4 features cannot be utilized in Trinity. I refuse to halt progress in moving to the TQt namespace, which would open the door to a number of features including a good KHTML replacement, just to retain perfect compatibility with the long-obsolete KDE3.5.10 release.
OK. I just do not understand why it is necessary to link with tqtinterface non-KDE and non-Qt3 applications such as LO.
Let's end this here. If you want to debate, you can Saturday. Everyone will be there to pitch in. Even me.
<snip>
No crashes for more than a year here.
Crashes sporadically on every version of KDE from 3.5.10 to the latest Trinity 3.5.12 for me. It probably has something to do with my heavy use of the filter bar on directories with lots of files; this makes perfect sense, as the underlying cause of the problem is a race condition caused by Trinity not having access to certain internal Qt data members.
One of our goals is to add new methods to Qt3 in order to clean up the hacks in the Trinity source, thereby stabilizing the system.
Good endeavor.
One of the bugs causes a crash sporadically when the filter bar is used in icon mode. The cause is a missing visibility set feature in QIconView. The only resolution is to fix Qt3. There are other examples, but I hope you get my drift.
Good. Is this patch already included in 3.3.8c?
No. There is an API stub and some initial work in the Qt3 GIT that has not yet been functionally tested, and probably will not be until after Trinity 3.5.13 is released.
<snip>
I don't like to call anyone a troll. Simply asking for clarification and stating your reasons for keeping the KDE3.5.10 plugin version would have avoided this entire flame war. In the future please ask a question and/or state your reasoning for needing something a certain way before making the types of strong statements that you made in this thread.
By the way if Robert would advance in packaging Trinity we would consider using Trinity now.
Robert, please advise here. I think we have been having more friction than neccessary between OpenSUSE and Trinity due to the lack of RPM packages. I noticed a lot of commits to the Trinity packaging GIT recently; how are things progressing?
Be careful what you say if you don't want to be judged.
I just do not bother with your offenses.
No offense intended!
By the way, if you continue to use the Qt C++ namespace you will run into problems eventually. Technically you are stepping on the toes of Qt4 and any applications built with Qt4, which is not a good thing to do.
Sorry I do not understand this. Which collisions are you speaking about? Collisions of filenames or something else?
Something else entirely--the class names buried within the shared object files. Google it. :-) Specifically, if there are two different versions of a class such as "QWidget" the C++ linker cannot decide which one to use, both at compile time and at runtime. This makes it impossible to use Qt3 and Qt4 together in a single application, and is something that is being corrected with the migration to TQt.
OK. I just do not understand why it is necessary to link with tqtinterface non-KDE and non-Qt3 applications such as LO.
LO *is* a KDE/TDE *and* Qt3 application as soon as you set that --enable-kde configure flag. Granted, the only files that will be compiled/linked against Qt3 and KDE/TDE are the file picker and themer, but they are still part of LO and still part of the resultant LO installation. If all the other Trinity source uses the TQt C++ classes, then the TDE portions of LO are among the only applications preventing usage of Qt3 and Qt4 together.
As I said, I am looking into the LO build system in detail now, and will advise later on as to what I think is feasible. For now we will use the old KDE3 integration present in LO 3.x.
Tim
On Aug 17, 2011, at 0:58, "Timothy Pearson" kb9vqf@pearsoncomputing.net wrote:
Robert, please advise here. I think we have been having more friction than neccessary between OpenSUSE and Trinity due to the lack of RPM packages. I noticed a lot of commits to the Trinity packaging GIT recently; how are things progressing?
I'm stuck on arts; see my error thread about it. I already modded tdelibs, next up is tdebase.
(aside) I don't have all the time in the world to work on this! I was not given these spec files so easily that all I would have to do is change the tarball name. But if you want to see what I have done (and maybe help?) you can look at Trinity GIT.
(back to the original topic) Cease this thread. Again.
On Wednesday 17 August 2011 08:58:24 Timothy Pearson wrote:
Something else entirely--the class names buried within the shared object files. Google it. :-) Specifically, if there are two different versions of a class such as "QWidget" the C++ linker cannot decide which one to use, both at compile time and at runtime. This makes it impossible to use Qt3 and Qt4 together in a single application, and is something that is being corrected with the migration to TQt.
We do not try to use Qt3 and Qt4 in a single application. Thus there is no collision expected. Qt4 will be deprecated soon and replaced with Qt5. It is quite difficult to catch up.
OK. I just do not understand why it is necessary to link with tqtinterface non-KDE and non-Qt3 applications such as LO.
LO *is* a KDE/TDE *and* Qt3 application as soon as you set that --enable-kde configure flag. Granted, the only files that will be compiled/linked against Qt3 and KDE/TDE are the file picker and themer, but they are still part of LO and still part of the resultant LO installation.
It is evident that linking themer with tqtinterface is senseless: either the result will be the same as when linking to pure Qt3 or (it you use tqt with Qt4) the theming most likely will be broken and anyway this will compete with the already existing Qt4 LO themer.
If all the other Trinity source uses the TQt C++ classes, then the TDE portions of LO are among the only applications preventing usage of Qt3 and Qt4 together.
As I understand it, you can build Trinity against Qt3 (probably with some calls to Qt4) or against Qt4. Thus one who uses LO can choose which themer suits his DE better - the Qt4 themer or Qt3 themer (or there can be made auto-detection).
As I said, I am looking into the LO build system in detail now, and will advise later on as to what I think is feasible. For now we will use the old KDE3 integration present in LO 3.x.
My advise would be better to look on other hundreds of KDE3 applications still not packaged for Trinity. Say, Kdissert, KBear, Kmyfirewall, Keep, Kallery, KPhotoAlbum, Guarddog, Guidedog, and many many others.
Again, you can discuss it over on Saturday. We can discuss it over a virtual and imaginary coffee. Better yet, we can get everyone's opinions! And be very clarified on the current stance. And also on the facts. I could even ask people from opensuse-kde3 to come and express what they think should happen! But right now, this is enough.
Fin.
Again, you can discuss it over on Saturday. We can discuss it over a virtual and imaginary coffee. Better yet, we can get everyone's opinions! And be very clarified on the current stance. And also on the facts. I could even ask people from opensuse-kde3 to come and express what they think should happen! But right now, this is enough.
Fin.
Works for me. I think the meeting chairman will need to keep this next meeting under very tight control though (to maintain order, not squelch ideas). ;-)
Tim
On Wednesday 17 August 2011 07:53:17 Timothy Pearson wrote:
Second: I was merely thinking out loud. With trolls on this list apparently that is a bad idea; I will save my ideas for the meeting, where things have been more civil.
Your thoughts were about forking kde3 plugin from LO 3.2. I just pointed you out that the plugin did not evaporate at least until LO 3.4.2.
On Wednesday 17 August 2011 06:54:45 Timothy Pearson wrote:
The downside, of course, is that KDE3 support for versions <= 3.5.10 would be removed.
If you are planning to make it Trinity-only and wreck compatibility with KDE3, I will be strongly against such move and will contact the LibreOffice developers to urge them not to accept such destructive patch.
On Tue, Aug 16, 2011 at 23:30, Ilya Chernykh anixxsus@gmail.com wrote:
On Wednesday 17 August 2011 06:54:45 Timothy Pearson wrote:
The downside, of course, is that KDE3 support for versions <= 3.5.10 would be removed.
If you are planning to make it Trinity-only and wreck compatibility with KDE3, I will be strongly against such move and will contact the LibreOffice developers to urge them not to accept such destructive patch.
OR, we could just keep both of them together. Whoever said that we had to destroy the old integration?
--- On Tue, 8/16/11, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
From: Timothy Pearson kb9vqf@pearsoncomputing.net Subject: Re: [trinity-devel] LibreOffice 3.4.2 To: trinity-devel@lists.pearsoncomputing.net Date: Tuesday, August 16, 2011, 7:15 PM
Today I updated LibreOffice to
version 3.4.2. The Slackware package is
nothing more than a converted RPM from the upstream
Open Document
Foundation (ODF).
There is no support for KDE3 file picker dialog boxes.
No option even
exists in the Options.
I'm using 3.5.10, which is not Trinity, but I'm
guessing if the upstream
RPM from ODF is like this then Trinity likely gets
miffed too.
How do we convince the ODF developers to directly
provide KDE3/Trinity
support upstream when they build their official
release?
Darrell
By providing a plugin that is maintained by the official TDE project. That is on our to-do list, but has not yet been started.
Essentially the following must happen: 1.) Pull the KDE3 picker code (including build script alterations) from the OpenOffice 3.2 / TDE 3.5.12 builds on QuickBuild. 2.) Ensure that they apply to LibreOffice and produce working binaries on TDE 3.5.13 with Qt3. 3.) Convert to TQt (a simple process that I can do in a day or so AFAIK) and rename all "KDE" strings to "TDE". 4.) Rebuild, test, etc. until everything works properly. 5.) Push the patches into our GIT and notify LibreOffice that we have a new plugin for them!
Volunteers are welcome as usual. ;-)
Tim
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Thank you for all the responses.
The whole point of my question, which I did not emphasize, is end-users should not need to recompile LibreOffice to obtain native file picker dialog boxes. Support for native dialogs should be transparent to users.
That OpenSuse provides such support does not help people using other distros. :)
My point is why can't the official release upstream from the Document Foundation developers include that native support from the beginning? If we need to provide those patches and hooks then fine, but the official build release of LibreOffice should not need to be recompiled downstream.
If I understand correctly, compiling LibreOffice requires several hours, even on a modern system. End users are not going to bother. Also, LibreOffice is not a standard app in all distros. Therefore having native dialog box support upstream is best for all end users. That approach eliminates packaging issues downstream. Further, even for those distros that support LibreOffice, most if not all of the packagers could care less about KDE3/Trinity support. They will ensure only that KDE4/GNOME is supported.
I believe that whatever effort or patches we provide should support the original KDE 3.5.10 too. KDE 3.5.10 is not yet dead despite whatever KDE developers want to believe. If we provide patches that support both platforms then that shows we are embracing more than just "our little world," which should motivate LibreOffice developers to embrace our patches. At least support KDE3 in the beginning. I think once Trinity is again in the news with the next official release that upstream attitudes will change and LibreOffice developers will accept supporting native file pickers.
Although nice, I'm not concerned with complete look-and-feel compatibility with KDE3/Trinity (for example, icons), just the file pickers. The LibreOffice file pickers are sh*t. :)
Darrell
On Wednesday 17 August 2011 22:07:35 Darrell Anderson wrote:
Thank you for all the responses.
The whole point of my question, which I did not emphasize, is end-users should not need to recompile LibreOffice to obtain native file picker dialog boxes. Support for native dialogs should be transparent to users.
This was how I understood it actually.
That OpenSuse provides such support does not help people using other distros. :)
Indeed.
My point is why can't the official release upstream from the Document Foundation developers include that native support from the beginning? If we need to provide those patches and hooks then fine, but the official build release of LibreOffice should not need to be recompiled downstream.
The OpenOffice from Oracle as distributed in binary form has support for Qt3 theming but still has no working KDE3 file picker plugin.
On Wednesday 17 August 2011 22:07:35 Darrell Anderson wrote:
Although nice, I'm not concerned with complete look-and-feel compatibility with KDE3/Trinity (for example, icons), just the file pickers. The LibreOffice file pickers are sh*t. :)
You can try to use kde3-kgtk program which is a wrapper that allows to start Qt3 and GTK applications in such a way that they use KDE3's file pickers.
On Wednesday 17 August 2011 22:07:35 Darrell Anderson wrote:
Although nice, I'm not concerned with complete look-and-feel compatibility with KDE3/Trinity (for example, icons), just the file pickers. The LibreOffice file pickers are sh*t. :)
You can try to use kde3-kgtk program which is a wrapper that allows to start Qt3 and GTK applications in such a way that they use KDE3's file pickers.
That won't work very well at all. I know from experience. ;-)
I am working on a way to get upstream support in place. The major barrier is going to be getting the distributions to add arts and kdelibs to their repositories; without that, the TDE plugins cannot be compiled by the distributions, forcing unofficial archives to include a rebuild of LO with TDE enabled,
Tim
On Wednesday 17 August 2011 23:21:57 Timothy Pearson wrote:
That won't work very well at all. I know from experience. ;-)
I am working on a way to get upstream support in place. The major barrier is going to be getting the distributions to add arts and kdelibs to their repositories; without that, the TDE plugins cannot be compiled by the distributions, forcing unofficial archives to include a rebuild of LO with TDE enabled,
openSUSE still has kdelibs3 and kdebase3-runtime in the main repo. Stephan Kulow, the release manager of openSUSE expressed that he will not object to the restoration of all KDE3 in openSUSE distro, calling the situation "completely different" from what was 3 releases before.
One major problem is the removal of hal from the future openSUSE release but now we have a patch that allows KDE3 to auto-detect media without hal.
On Wednesday 17 August 2011 23:21:57 Timothy Pearson wrote:
That won't work very well at all. I know from experience. ;-)
I am working on a way to get upstream support in place. The major barrier is going to be getting the distributions to add arts and kdelibs to their repositories; without that, the TDE plugins cannot be compiled by the distributions, forcing unofficial archives to include a rebuild of LO with TDE enabled,
openSUSE still has kdelibs3 and kdebase3-runtime in the main repo. Stephan Kulow, the release manager of openSUSE expressed that he will not object to the restoration of all KDE3 in openSUSE distro, calling the situation "completely different" from what was 3 releases before.
One major problem is the removal of hal from the future openSUSE release but now we have a patch that allows KDE3 to auto-detect media without hal.
Really? Can you send it in to this list? That would be a great help :)
Thanks!
Tim
On Wed, Aug 17, 2011 at 15:48, Ilya Chernykh anixxsus@gmail.com wrote:
One major problem is the removal of hal from the future openSUSE release but now we have a patch that allows KDE3 to auto-detect media without hal.
Are you sure it's a patch? I recall a message to os-Factory about udev rules.
On Thursday 18 August 2011 03:04:59 Robert Xu wrote:
On Wed, Aug 17, 2011 at 15:48, Ilya Chernykh anixxsus@gmail.com wrote:
One major problem is the removal of hal from the future openSUSE release but now we have a patch that allows KDE3 to auto-detect media without hal.
Are you sure it's a patch? I recall a message to os-Factory about udev rules.
udev rules do not affect kde3, i.e. what mediamanager detects.
On Wednesday 17 August 2011 03:46:32 Darrell Anderson wrote:
Today I updated LibreOffice to version 3.4.2. The Slackware package is nothing more than a converted RPM from the upstream Open Document Foundation (ODF).
There is no support for KDE3 file picker dialog boxes. No option even exists in the Options.
I'm using 3.5.10, which is not Trinity, but I'm guessing if the upstream RPM from ODF is like this then Trinity likely gets miffed too.
How do we convince the ODF developers to directly provide KDE3/Trinity support upstream when they build their official release?
Just build it with KDE3 support turned on.
On Wednesday 17 August 2011 03:46:32 Darrell Anderson wrote:
Today I updated LibreOffice to version 3.4.2. The Slackware package is nothing more than a converted RPM from the upstream Open Document Foundation (ODF).
There is no support for KDE3 file picker dialog boxes. No option even exists in the Options.
I'm using 3.5.10, which is not Trinity, but I'm guessing if the upstream RPM from ODF is like this then Trinity likely gets miffed too.
How do we convince the ODF developers to directly provide KDE3/Trinity support upstream when they build their official release?
You can try to use the packages from openSUSE
http://download.opensuse.org/repositories/LibreOffice:/Unstable/openSUSE_11....
The kde3 file picker support is there as well:
http://download.opensuse.org/repositories/LibreOffice:/Unstable/openSUSE_11.... http://download.opensuse.org/repositories/LibreOffice:/Unstable/openSUSE_11....
-
Darrell Anderson -
Ilya Chernykh -
Robert Xu -
Timothy Pearson