16 Aug
2011
16 Aug
'11
4:46 p.m.
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
16 Aug
16 Aug
5:15 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
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
6:21 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
On Wednesday 17 August 2011 04:15:03 Timothy Pearson wrote:
What plugin if nobody removed KDE3 support from LibreOffice?
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.
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?
7:07 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
On Wednesday 17 August 2011 04:15:03 Timothy Pearson
wrote:
What plugin if nobody removed KDE3 support from LibreOffice?
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.
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.
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?
7:34 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
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.
7:41 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
On Wednesday 17 August 2011 06:07:16 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
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.
7:52 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
On Wednesday 17 August 2011 06:41:53 Timothy Pearson wrote:
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:07:16 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. 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.
7:55 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
On Wednesday 17 August 2011 06:41:53 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.
You mean you want to write a new plugin? :-\
NO!!
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.
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
7:54 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
On Wednesday
17 August 2011 06:07:16 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
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.
8:25 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
On Wednesday 17 August 2011 06:54:45 Timothy Pearson wrote:
Why do you think it needs patching? It works well.
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.
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?
8:33 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
On Tue, Aug 16, 2011 at 23:25, Ilya Chernykh <anixxsus(a)gmail.com> wrote:
KDE3 is technically obsolete.
Not with Trinity. See above.
--
later, Robert Xu + rxu AT lincomlinux DOT org
On Wednesday 17 August 2011 06:54:45 Timothy Pearson
wrote:
Why do you think it needs patching? It works well.
TQt intergration.
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.
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?
8:43 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
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.
8:46 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
On Tue, Aug 16, 2011 at 23:43, Ilya Chernykh <anixxsus(a)gmail.com> wrote:
On Wednesday 17 August 2011 07:33:20 Robert Xu wrote:
What do you mean?! it works in Ubuntu.
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.
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.
--
later, Robert Xu + rxu AT lincomlinux DOT org
8:52 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
On Wednesday 17 August 2011 07:46:40 Robert Xu wrote:
What do you mean?! it works in Ubuntu.
I meant KDE3 integration.
And why to do this if anyone just can call plain Qt3? Why do you need libreoffice
to call tqtinterface rather than just Qt?
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.
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.
Libreoffice has its own front-end for Qt4. Just use this front-end when your
system is built against Qt4.
8:53 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
On Tue, Aug 16, 2011 at 23:43, Ilya Chernykh
<anixxsus(a)gmail.com> wrote:
<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:33:20 Robert Xu
wrote:
What do you mean?! it works in Ubuntu.
TQt intergration.
Not with Trinity. See above.
I think the reason why it does not work in Ubuntu is different.
9:06 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
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.
9:16 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
On Wednesday 17 August 2011 07:53:17 Timothy Pearson
wrote:
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
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.
9:40 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
On Wednesday 17 August 2011 08:16:37 Timothy Pearson wrote:
API, yes. ABI, no.
And API is what we need to have LO working.
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. 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.
9:53 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
Let's end this here. If you want to debate, you can Saturday.
Everyone will be there to pitch in. Even me.
9:58 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
<snip>
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.
No offense intended!
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.
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? 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. 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? 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
10:16 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
On Aug 17, 2011, at 0:58, "Timothy Pearson" <kb9vqf(a)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.
10:20 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
On Wednesday 17 August 2011 08:58:24 Timothy Pearson wrote:
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.
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. 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.
10:30 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
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.
10:55 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
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
9:08 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
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.
8:30 p.m.
New subject: [trinity-devel] LibreOffice 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.
8:33 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
On Tue, Aug 16, 2011 at 23:30, Ilya Chernykh <anixxsus(a)gmail.com> wrote:
On Wednesday 17 August 2011 06:54:45 Timothy Pearson
wrote:
OR, we could just keep both of them together. Whoever said that we had
to destroy the old integration?
--
later, Robert Xu + rxu AT lincomlinux DOT org
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.
17 Aug
17 Aug
11:07 a.m.
New subject: [trinity-devel] LibreOffice 3.4.2
--- On Tue, 8/16/11, Timothy Pearson <kb9vqf(a)pearsoncomputing.net> wrote:
From: Timothy Pearson
<kb9vqf(a)pearsoncomputing.net>
Subject: Re: [trinity-devel] LibreOffice 3.4.2
To: trinity-devel(a)lists.pearsoncomputing.net
Date: Tuesday, August 16, 2011, 7:15 PM
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
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(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-devel-help(a)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
12:04 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
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.
12:10 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
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.
12:21 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
On Wednesday 17 August 2011 22:07:35 Darrell Anderson
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,
Tim
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.
12:48 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
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.
12:50 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
On Wednesday 17 August 2011 23:21:57 Timothy Pearson
wrote:
Really? Can you send it in to this list? That would be a great help :)
Thanks!
Tim
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.
4:04 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
On Wed, Aug 17, 2011 at 15:48, Ilya Chernykh <anixxsus(a)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.
--
later, Robert Xu + rxu AT lincomlinux DOT org
21 Aug
21 Aug
10:46 a.m.
New subject: [trinity-devel] LibreOffice 3.4.2
On Thursday 18 August 2011 03:04:59 Robert Xu wrote:
On Wed, Aug 17, 2011 at 15:48, Ilya Chernykh
<anixxsus(a)gmail.com> wrote:
udev rules do not affect kde3, i.e. what mediamanager detects.
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.
16 Aug
16 Aug
6:18 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
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.
6:29 p.m.
New subject: [trinity-devel] LibreOffice 3.4.2
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…
4844
days inactive
4849
days old
36 comments
4 participants
participants (4)
-
Darrell Anderson -
Ilya Chernykh -
Robert Xu -
Timothy Pearson