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
>> $TDEHOME/apps/kicker/applets
>> I suspect other users in the community might be bit by this bug
too.
>I confirm the bug. Time for a new bug report I guess.
Experimenting indicates the behavior of the help handbook table of
contents depends upon how those directories are populated. The
user's $TDEHOME directory structure mimics the Trinity system
directory structure. When the user's applets directory does not
exist then there is nothing to override the system directory. All
applet handbooks appear in the table of contents. When the user has
an applet directory, then that directory overrides the system
directory. When I populate the user's applet directory with
*.desktop files from the system directory, then those items appear
in the handbook table of contents, but only those *.desktop files I
copy. When the user's applet directory is empty, then none appear
in the handbook table of contents.
This makes sense but a larger question is how do the user's
subdirectories get created in the first place? Seems to me none of
those user directories should exist until the users starts
customizing. Yet even then, was the original intent to mask help
handbook entries? Probably not.
>BTW after removing the applets folder, I can only see 6 applets
>manual. Is it all we have or are there other manuals that are not
>displayed?
That is all I am aware that exists:
Weather Report
System Monitor
Public File Server
Color Picker
Moon Phase
Klipper
Darrell
All, 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.
--
David C. Rankin, J.D.,P.E.
All,
After updating my systems to the most recent git (as of last
night), I ran into a strange bug. Some of my user accounts had
access to applet manuals in the khelpcenter, other accounts did not.
After some digging I discovered the problem. Any user account that
had the following directory in their user profile was unable to see
the applet manuals:
$TDEHOME/apps/kicker/applets
I suspect other users in the community might be bit by this bug too.
What is that directory used for?
Why does the existence of the directory --- and all were empty on
all user accounts, prevent listing applet manuals in khelpcenter?
Should we add a rule in r14-xdg-update to delete
$TDEHOME/apps/kicker/applets when the directory is empty? If not
empty, I presume that ties into the first question: What is that
directory used for?
Darrell
All,
Would one of you graphics experts please update the tdesvn svgz
icon?
In the git sources:
applications/tdesvn/src/icons/hisc-app-tdesvn.svgz
The text string in the image should be updated to T D E S V N.
All of the respective png files in that same directory are created
from that svgz.
Thanks!
Darrell
>Ugh, it probably saved as "Compressed Inkscape SVG" rather
>than "Compressed Plain SVG". The attached version should fix
>that.
>I rendered the PNG anyway, though (150 x 127, because it just
>would
>not give me that extra pixel).
Thank you!
Darrell
>This good?
Looks great. Thank you!
I am unable to convert your svgz to png using gwenview. I've used
gwenview in the past to convert, but this time the resulting png is
NOT the same as the original svgz.
Would you please create a 150x128 png from the svgz?
Thanks much.
Darrell