tde-devels

devels@trinitydesktop.org

9 participants
3789 discussions

Re: [trinity-devel] LibreOffice and Trinity dialogs
by Darrell Anderson 14 Jan '14

14 Jan '14

>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

2 1

Re: [trinity-devel] LibreOffice and Trinity dialogs
by Darrell Anderson 14 Jan '14

14 Jan '14

>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

4 4

Re: [trinity-devel] Developer information
by Darrell Anderson 14 Jan '14

14 Jan '14

>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

1 0

How to exclude files from installing in the final package
by Darrell Anderson 14 Jan '14

14 Jan '14

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

2 1

Developer information
by Darrell Anderson 14 Jan '14

14 Jan '14

All, Of interest to Trinity developers: http://techbase.kde.org/Development/Tutorials/KDE3 http://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

2 1

LibreOffice and Trinity dialogs
by Darrell Anderson 14 Jan '14

14 Jan '14

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

2 3

Re: [trinity-devel] GTK dependency standard for helper packages/apps?
by Darrell Anderson 14 Jan '14

14 Jan '14

>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

2 1

Re: [trinity-devel] GTK dependency standard for helper packages/apps?
by Darrell Anderson 13 Jan '14

13 Jan '14

> 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

2 1

Re: [trinity-devel] R: [trinity-devel] Strange khelpcenter bug
by Darrell Anderson 13 Jan '14

13 Jan '14

>> $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

1 0

GTK dependency standard for helper packages/apps?
by David C. Rankin 13 Jan '14

13 Jan '14

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.

1 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels