All,
Do any Trinity users use scrollkeeper? Trinity maintains legacy
KDE3 code to support scrollkeeper, but scrollkeeper hasn't been
supported in a decade. The successor is something called rarian,
which Trinity does not support and seems to be a GNOME app.
Do we want to continue scrollkeeper support?
Further, do we want to support metasearch engines at all? We
maintain kerry, which is a beagle front-end. Beagle has not been
supported in a number of years.
Darrell
>As I mentioned in the beginning - I tested the binary packages
>from LibreOffice-TDE PPA on build-farm.
>
>+ 4.0.3-14 on Debian Wheezy
>+ 4.0.2-0ubuntu4 on Ubuntu Saucy
Always trust Debian to be a version or two behind. :) The latest LO
stable is 4.1.4.
You're fortunate that whoever supports LO upstream in Debian is
building LO with Trinity support.
Darrell
>FYI: I tested last Thursday LibreOffice-TDE on the machine where I
>had when
>first testing fundamental problems. And now I have no problems. I
>do not know
>what caused the problem in the first test.
Are you using a premade LO binary or compiling your own LO package?
What version of LO?
I do not have the luxury of somebody else compiling LO with Trinity
dialog support. I have to do that on my own. That is why I need
information to compile LO with Trinity support.
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.
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
>If you can do one of your global renaming tricks and get those
>into shape, then
>they are definitely worth including. It just makes the desktop
>more of what it
>was intended to be. Not only the best for users, but friendly for
>developers to
>foster app development.
When the web site is moved to the new format, which is in progress
behind the scenes, we will have a navigation link for developers.
Later we can massage these off site files into those locations.
I can perform basic editing and massaging into Trinity specific
documents, but one of the code gurus will need to be locked into a
room with Twinkies and sodas to read and ensure the material is
updated correctly. as well as augment the material as necessary.
>If there are pieces needed from kde.org (pages, etc.) they are
>currently marked
>for deletion, so we may need to get with Martin or whoever the
>current kde.org
>emissary is and see if we can get a copy/backup of the pages that
>help navigate
>the examples and headers.
I've already spidered the web pages to my computer. No need to
worry about them disappearing, although I don't expect that to
happen any time soon. We're covered one way or another.
Darrell
All,
I'm doing a lot of cleanup work with the help handbook files.
kdiff3 contains many html files that get included in the final
package. Originally the html files were intended for users not
using KDE3. These html files cause problems with the help handbook
table of contents and cause error messages seen in the xsession-
error log.
I want to modify the Makefile.am file not to include the html files
in the package.
I've looked around the web in frustration.
How do I do that?
Thanks?
Darrell
All,
Of interest to Trinity developers:
http://techbase.kde.org/Development/Tutorials/KDE3http://www.beginning-kdevelop-programming.co.uk/
I've downloaded the pages to my computer. Perhaps we can massage
that information to our wiki, updated with appropriate Trinity
references.
In the mean time, if you are interested you might want to bookmark
the sites. :)
If you have a local tree of the git sources, you can create a
bookmark to the orginal Qt3 reference material:
{local trinity git tree}/main/dependencies/qt3/doc/html/index.html
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
>Well, I'm getting old I guess,
>
> tde-libksquirrel has xmedcon as an optional dependency that
>provides medical
>image handling and conversion. (CT, MRI, PET, etc..) I always
>build it because I
>use the functionality. My question was for these type of
>applications is whether
>there is any preference whether they are built against GTK2 or
>GTK3 if we have a
>choice.
>
> The reason it matters to me is that if some apps are built with
>a gtk2
>dependency, you pull in gtk2 as a build dependency, if against
>gtk3, then you
>pull in gtk3. (that looks like it will happen for the foreseeable
>future
>anyway). I didn't know if there had been any discussion about
>trying to minimize
>build dependencies such that if an option existed to use either
>gtk2 or 3, if
>there was a preference for one or the other.
>
> Smacks self -- there I go thinking someone else will actually be
>building tde
>on arch except me -- never mind...
I think this still goes back to "Apps like xmedcon are outside the
scope of Trinity. Distro packagers and maintainers ensure the
dependencies are satisfied."
If xmedcon is not installed then ksquirrel does not build that
support. If you are supporting Trinity packages for other users and
they want xmedcon support, I'm sure they will let you know.
Whether gtk2 or gtk3 is preferred, I don't know of any distro
maintainers dropping gtk2 support any time soon. Perhaps the
question is moot for the next few years?
Darrell
> Going through build scripts for dependency/helper application
>like xmedcon, I
>was building them against gtk2 last year for both tde13 and R14.
>Do we have any
>'tde' standard we are trying to enforce for minimizing the
>dependencies for a
>complete tde install?
>
> What I mean is that if someone goes to install tde-full with all
>helper apps,
>do we want and try to say all apps with a gtk requirement should
>be built
>against gtk3 instead of gtk2? I for one prefer gtk2, but I can
>see the logic in
>standardizing around a version to minimize dependencies (and to
>prevent build
>failures when gtk2 is dropped)
>
> Has anyone given this any thought? I don't like the prospect of
>having to
>recode older apps against a new gtk, but it is doable. The number
>of apps this
>will apply to is minimal.
What is a "helper app"?
Apps like xmedcon are outside the scope of Trinity. Distro
packagers and maintainers ensure the dependencies are satisfied.
Darrell