>Some time ago I tested LibreOffice with TDE integration as
>available in
>LibreOffice-tde PPA on the build-farm.
>
>I tested version 4.0.3-14 on Debian Wheezy i386 and was very
>unuseable.
>On the File/Open nothing happened. On the File/Save as occurred
>freezing
>LibreOffice. I was forced to upgrade to LibreOffice from wheezy-
>backports
>(4.1.2-2~bpo70+1 without TDE integration).
>
>Then I tested version 4.0.2-0ubuntu4 on Ubuntu Saucy amd64 and
>there
>everything worked smoothly.
Seems we should do some testing. The link above is about KDE4 but
perhaps similar patching is needed for Trinity. To my understanding
there are two patches. One that affects dialog speed and another
that affects spreadsheets.
How long did compiling take on the build farm?
Darrell
All,
Has anybody been building LibreOffice packages with Trinity dialog
support?
We mention this support in our draft R14 press release.
Despite knowing that compiling LO takes several hours, I would like
to test Trinity dialogs. I suspect that anybody wanting Trinity
dialog support is more or less left on their own to build LO. I
doubt anybody upstream provides that support.
Yet I lack information how to proceed and I have not found any
written instructions.
Is the 'thirdparty' patch in the git repo current? I ask because of
this blog article about KDE4 integration:
http://dilfridge.blogspot.nl/2013/12/libreoffice-kde-
integration.html
The author implies that external dialog support has suffered bit
rot. I have no idea whether than includes Trinity or just KDE4.
What LO build script options are needed? Is something like one of
the following needed:
--enable-kde
--enable-kde3
--enable-qt
--enable-qt3
--enable-tqt
I never built LO from source therefore don't know what
configuration options are available or recognized.
If we are going to announce LO dialog support then should a handful
of us should test this support?
Darrell
> I was unclear. I was looking for a wiki page where we could post
>suggested
>changes to default values for apps, etc.. such as akregatorrc:
>
>[Browser]
>Close Button On Tabs=true
That kind of discussion probably is deep in the mail list archives
or an etherpad.
File an enhancement request and explain why the change should be
made. :)
Darrell
>In preparation for the R14.0.0 release, we would like to establish
>
>minimum system requirements for installing and running Trinity.
>Please refrain from "by gosh, by gum" guessing. :-) Please only
>share real-world experiences using Trinity with older hardware and
>
>distros as well as limited environments, such as the Raspberry Pi
>or ARM.
>
>We don't want to create absurd minimum requirements as has
>popular.
>We want to establish realistic minimum requirements.
>
>Thank you!
Tim has been fine-tuning Trinity code based upon his own testing of
a Raspberry Pi and me with a PI and PII. We've been conducting
these tests for about two weeks.
My test specs:
PI: 400 MHz K6-III+, 256 MB RAM (the maximum possible), ATA hard
drive, 66 MHz FSB, Diamond Stealth 3000 3D video card (4 MB RAM).
This was my primary system at the turn of the century. :)
PII: 350 MHz Deschutes CPU, 448 MB RAM (expandable only to 768 MB),
ATA hard drive, 100 MHz FSB, Creative Banshee AGP (16 MB RAM).
Direct rendering actually works on this first generation AGP card.
:)
Precise scientific testing method: stopwatch and eyeballs. :)
In my original tests with the PI and PII, the original Trinity
startup time was about 1:45. Tests as of today are down to about
1:05. All of the recent testing and patching is, very much, a
success. Other tests were performed but that one result indicates
the improvements. Bottom line is Trinity is usable on the PI and
PII. For sure I would not want to use these systems all day, yet at
least Trinity is palatable on these clunkers. :)
As noted previously in this list, the PI and PII are not energy
efficient. Much of the time they sit powered off under my desk, but
they both serve handily as good hardware to test various aspects of
Trinity and corner cases.
With this testing we now have a good idea how Trinity performs at
the bottom of the hardware barrel. Considering that KDE4 and GNOME
are unlikely to run on such systems, that leaves Trinity, Xfce,
LXDE/Razor-qt, and E17 as the remaining desktop candidates for
REALLY old hardware. That said, window managers likely are optimal
at the PI/PII level (not to mention that tasks such as online video
and audio streaming will really test a person's patience).
Although arguably we showed that a PI or PII could suffice as
minimum system requirements, real-world observations indicate such
claims should be as a sidenote.
If anybody has a P3 available and some time, testing would be
welcomed as to whether we can establish a P3 as an reasonable real-
world minimum for system requirements.
My testing was as simple as this:
Trinity startup time.
Starting preloaded konqueror.
Starting konsole.
Alt+F2 dialog.
Starting kate.
Starting kcontrol.
Alt+F1 menu.
Darrell
> At one time we had discussed updating various defaults for
>keystrokes, etc. I
>have run across an Akregator default change and can't find where
>we were listing
>them.
If I correctly understand your question, most defaults are found in
*.ui files. For akregator there are several:
tdepim/akregator/src/settings_archive.ui
tdepim/akregator/src/settings_appearance.ui
tdepim/akregator/src/mk4storage/mk4confwidgetbase.ui
tdepim/akregator/src/tagpropertieswidgetbase.ui
tdepim/akregator/src/settings_browser.ui
tdepim/akregator/src/settings_advancedbase.ui
tdepim/akregator/src/propertieswidgetbase.ui
tdepim/akregator/src/addfeedwidgetbase.ui
tdepim/akregator/src/settings_general.ui
Darrell
All,
At one time we had discussed updating various defaults for keystrokes, etc. I
have run across an Akregator default change and can't find where we were listing
them.
--
David C. Rankin, J.D.,P.E.
>Gotta love arch :)
>
>cups 1.7.0-2
>libpng 1.6.7-1
Thanks. :)
Please let me know when you have a successfully built a full R14
package against those packages. Then I'll bump the press release to
those versions.
>we also have libpng12. Is R14 still dependent on libpng 1.2.x?
Not that I'm aware. Over the months we have updated Trinity with
several libpng version-related patches. I recall you being involved
in a few of those patches. A few months ago Francois pushed some
more such patches.
Darrell
Tim,
Here is the specific LO build failure:
dev/shm/tmp-libreoffice/libreoffice-
4.1.4.2/vcl/Executable_tdefilepicker.mk:18: ***
gb_LinkTarget_set_include: include paths /dev/shm/tmp-
libreoffice/libreoffice-4.1.4.2/vcl/inc/unx/tde do not exist. Stop.
As reported, tmp-libreoffice/libreoffice-4.1.4.2/vcl/inc/unx/tde
does not exist. Looking through Executable_tdefilepicker.mk, there
is such a respective include directive: -I$(SRCDIR)/vcl/inc/unx/tde.
There are additional references in Executable_tdefilepicker.mk to
vcl/unx/kde/fpicker, which no longer exists.
There is a kde directory and only one file: kdedata.hxx.
Looking through the older LO Trinity patches, looks to me like the
directory structure has changed in the 4.1.x series.
Darrell
>Some time ago I tested LibreOffice with TDE integration as
>available in
>LibreOffice-tde PPA on the build-farm.
>
>I tested version 4.0.3-14 on Debian Wheezy i386 and was very
>unuseable.
>On the File/Open nothing happened. On the File/Save as occurred
>freezing
>LibreOffice. I was forced to upgrade to LibreOffice from wheezy-
>backports
>(4.1.2-2~bpo70+1 without TDE integration).
>
>Then I tested version 4.0.2-0ubuntu4 on Ubuntu Saucy amd64 and
>there
>everything worked smoothly.
The latest stable is 4.1.4. We should support that.
Yesterday I started trying to build LO. A dependency nightmare even
after I found a good build script to start with.
The 4.1.4 build halts early with failures related to TDE. I was up
way too late last night and did not copy the failure message, but I
am reasonably sure the failure message means we need to patch the
LO 4.1.4 sources.
Building LO with Trinity dialogs is going to be a never-ending
shuffle to keep LO patched. Nobody upstream is going to do that or
even care. Keeping LO patched falls on us.
Considering that compiling needs several hours, I ask that we build
LO on the server farm and then package as an rpm just like the LO
folks do. All Trinity packagers then can take that standard rpm and
repackage for their own distro.
Building on the server farm will not be a nightly affair. Only
build as needed when each new LO version is released. Perhaps two
or three times a year. Building on the server farm also guarantees
all Trinity packagers that LO is built correctly and provides a
common method for all Trinity users to test and validate the
Trinity dialogs.
As the final LO package is a monster 120+ MB, to control bandwidth
we could make the final package available only Trinity packagers
and developers.
For those who still want to build LO from source with Trinity
dialogs, at the wiki we should provide a build script template, a
list of required dependencies, a link to git of the respective
patches for each LO release version. Right now our draft press
release claim of Trinity dialog support is vaporware, at least
until we can prove others can build LO successfully with the
dialogs.
Thoughts?
Darrell