tde-devels

devels@trinitydesktop.org

2 participants
3811 discussions

Recent mouse click problems
by Darrell Anderson 20 Dec '13

20 Dec '13

All, Using git, creating fresh package sets frequently the past many days. Recently my mouse is not working correctly. I don't know whether the problem is me, the mouse, X, or Trinity. I don't think the mouse because I have tried two different devices. The recent problem is a single click does not always function like a single click. Sometimes the single click acts like a double-click and sometimes a single click does nothing at all. For example, single-click selecting an app icon in the taskbar or the launcher menu button might do nothing at all. I have to click again. Sometimes a single-click on a file opens the file rather than just selecting, like a double-click. Another problem is click-and-drag does not always hold. That is, I click-and-drag to select a snippet of text but when I release the mouse button the selection highlight disappears as though I single- clicked outside the selected area. I have the double-click time configured to 700 msecs (fairly slow) and I have tested different times. I have double-click set as the default icon selection action. I don't want to use a different desktop for a day or two to decide whether Trinity is involved. Has anybody else experienced these or similar events of late? Any ideas? Thanks. :-) Darrell

2 1

Re: [trinity-devel] tdelibs FTBFS: cmake 2.8.12: INTERFACE_LINK_LIBRARIES vs. LINK_INTERFACE_LIBRARIES
by Darrell Anderson 19 Dec '13

19 Dec '13

>I think that this is a bug in cmake - see: >http://cmake.org/gitweb?p=cmake.git;a=commit;h=239b0c6b0ed821fd012a >2a980961b9a9d43793e5 >You need update cmake to at least 2.8.12.1. Slavek, I updated cmake to 2.8.12.1. In the dependencies and core packages I saw no cmake warnings or errors and all packages built without error. Then tdebase failed to build. Here is the build log: http://humanreadable.nfshost.com/misc/trinity-tdebase-pre_R14.0.0- i586-14.1_32_git_2882_1-build.log The CMakeCache.txt file is part of the build log. These are the same types of errors I saw when I tried a patch backwards compatibility test building Trinity in Slackware 14.0 with cmake 2.8.10.2. Side note: I will approach the Slackware maintainer and ask to update cmake 2.8.12.1 as a bug fix, but I won't do that until all related bugs are resolved. I have to provide a good reason for the request, including how updating to 2.8.12.1 helped. :-) Darrell

1 0

Re: [trinity-devel] tdelibs FTBFS: cmake 2.8.12: INTERFACE_LINK_LIBRARIES vs. LINK_INTERFACE_LIBRARIES
by Darrell Anderson 18 Dec '13

18 Dec '13

>Therefore, I have prepared a patch that could solve both of these >problems. Please, test it. I started testing the patch in Slackware 14.1, which uses cmake 2.8.12. I have not yet tested backwards compatibility with older versions of cmake. Thus far I saw no cmake warnings in arts (good!), but tdelibs is filled with many instances of a single CMP0022 warning: CMake Error: Error evaluating generator expression: $<LINK_ONLY:-Wl,-whole-archive> $<LINK_ONLY> expression requires exactly one parameter. CMake Warning (dev) in tdecore/tdehw/networkbackends/network- manager/CMakeLists.txt: Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link interface. Run "cmake --help-policy CMP0022" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Static library target "network_manager_backend-static" has a INTERFACE_LINK_LIBRARIES property. This should be preferred as the source of the link interface for this library. Ignoring the property and using the link implementation as the link interface instead. This warning is for project developers. Use -Wno-dev to suppress it. I am not seeing any of the original warning messages. Darrell

2 1

Re: [trinity-devel] tdelibs FTBFS: cmake 2.8.12: INTERFACE_LINK_LIBRARIES vs. LINK_INTERFACE_LIBRARIES
by Darrell Anderson 18 Dec '13

18 Dec '13

>Therefore, I have prepared a patch that could solve both of these >problems. Please, test it. I will test. Will be a few hours before I can provide results. Darrell

1 0

tdelibs FTBFS: cmake 2.8.12: INTERFACE_LINK_LIBRARIES vs. LINK_INTERFACE_LIBRARIES
by Darrell Anderson 18 Dec '13

18 Dec '13

All, I gave a pass at compiling R14 on the newly released Slackware 14.1, which contains cmake 2.8.12. The arts package compiled with cmake warnings I never saw before and tdelibs FTBFS with the same warnings. The arts warnings: CMake Warning (dev) in libltdl/CMakeLists.txt: CMake Warning (dev) in flow/gsl/CMakeLists.txt: CMake Warning (dev) in libltdl/CMakeLists.txt: CMake Warning (dev) in libltdl/CMakeLists.txt: CMake Warning (dev) in libltdl/CMakeLists.txt: CMake Warning (dev) in flow/gsl/CMakeLists.txt: CMake Warning (dev) in libltdl/CMakeLists.txt: CMake Warning (dev) in libltdl/CMakeLists.txt: tdelibs: CMake Warning (dev) in tdecore/tdehw/CMakeLists.txt: CMake Warning (dev) in tdecore/tdehw/networkbackends/network- manager/CMakeLists.txt: CMake Warning (dev) in libltdl/CMakeLists.txt: CMake Warning (dev) in tdecore/svgicons/CMakeLists.txt: CMake Warning (dev) in tdeio/tdeio/CMakeLists.txt: CMake Warning (dev) in libltdl/CMakeLists.txt: CMake Warning (dev) in tdehtml/java/CMakeLists.txt: Following the colon of each warning: Common to both arts and tdelibs: CMake Warning (dev) in libltdl/CMakeLists.txt: Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link interface. Run "cmake --help-policy CMP0022" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Static library target "ltdlc-static" has a INTERFACE_LINK_LIBRARIES property. This should be preferred as the source of the link interface for this library. Ignoring the property and using the link implementation as the link interface instead. This warning is for project developers. Use -Wno-dev to suppress it. If I understand correctly from reading around the web, the cause is cmake 2.8.12 changed LINK_INTERFACE_LIBRARIES to INTERFACE_LINK_LIBRARIES. If that is correct, then seems TDEMacros.cmake:696 needs to be updated to handle both variables: target_link_libraries( ${_target} LINK_INTERFACE_LIBRARIES ${_shared_libs} ) I'm wild guessing something similar to this (I'm not a cmake guru): If (${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION}.${ CMAKE_PATCH_VERSION } GREATER 2.8.11) target_link_libraries( ${_target} INTERFACE_LINK_LIBRARIES ${_shared_libs} ) else() target_link_libraries( ${_target} LINK_INTERFACE_LIBRARIES ${_shared_libs} ) endif() I presume others will experience these same warnings and build failures when they update to cmake 2.8.12. Regardless, this requires a change to the common cmake sources, which need to be propogated through the source tree. Darrell

4 3

New motherboard advice
by Darrell Anderson 17 Dec '13

17 Dec '13

All, I'm considering an update to my office desktop computer I built 5 years ago. A new system with SATA III, USB 3.0, quad core, an SSD, etc, would seriously help with Trinity build times. I would like to keep the system as quiet as possible with no increase in the electric bill over my current dual core AMD system (about 65-80 watts). I'm grateful for suggestions and advice or sharing what you are using. Thanks :-) Darrell

4 3

Re: [trinity-devel] Need an svg expert
by Darrell Anderson 17 Dec '13

17 Dec '13

>Probably a good place to start. If KDE4 displays them at a >decent speed on the same hardware, dissect KDE4, since its >structure is still going to be somewhat more like Trinity's than >Gnome. > >Another possibility would be to do some sort of prerender-and- >cache-as-raster, although that's probably adding needless >complexity to the system. > >Or we can just hack the Kicker code to discard all >libreoffice*.svg >files and drop to the raster versions--crude, but doesn't require >cooperation from anyone else. We then ship a prerendered set >of PNGs matching what LibreOffice was using at the time of >release, and call it good . . . and hope that no one else decides >ridiculously oversized icons are a good idea. :-/ The LO 4.1 package I'm using comes with png files of the svg icons. As png files are already installed, then a short-term hack could ensure the svg files are not used. Long term, update the algorithm. >I don't think they're likely to change the icon set with every >update >to LO, so we can just check and update whenever *we* make a >new release. Only a few people are likely to notice or care >(unless >this also affects another DE's default icon set). The icon graphics likely do not change often. Just the file name of the icons, which use the version number. Darrell

1 0

Re: [trinity-devel] Need an svg expert
by Darrell Anderson 16 Dec '13

16 Dec '13

>The problem is just that they're very large and complex files, >from >the looks of it. Lots of shapes, lots of gradients, lots of >(unnecessary, >IMNSHO) clipping and masking. The SVG icon files that ship with >Trinity are mostly ten percent or less of that size, and much less >complex. Even in Inkscape on my quad-core, the LO files take >several seconds longer to load than, say, the old >crsc-app-openoffice.svgz icon that ships with our Crystal theme. > >The optimum solution would be to clonk whoever created the files >over the head with a blunt object and get them to redo them as >straightforward stacks of shapes and gradients without all the >unnecessary file-bloating crap. With your understanding of svg file formats, do you feel comfortable contacting the LO team and ask them to consider releasing palatable icons? >The code to look at in TDE is >the stuff related to clipping, masking, and cloning in SVGs, but >it >may never be possible to make these files open acceptably fast on >a slow machine. They're just not made with that in mind. This likely is the best solution. Use more recent svg algorithms that do not suffer the same rendering problems. What algorithms are being used in other desktops? --- Take advantage of GPL code sharing practices. :-) >The only workaround that occurs to me at this time is overwriting >the files with something simpler after LO is installed, or else >deleting the SVGs outright and (hopefully) forcing the system to >fall back on the raster versions of the icons. A challenge to that idea is the LO devs name the icons with the LO release number in the file name. Maintaining our own png icon set would be overwhelming because with each LO release a new Trinity icon set is needed. Not to mention all past LO icons sets as well because they have included the release number in the file names for a long time now. >I can attempt to redraw the icons to produce substantially >identical >smaller SVGs to overwrite them with, but it would take a while, >so I'm not going to start until and unless we decide that this is >the way to go. Does not sound productive at the moment. :-) BTW, I used Trinity Gwenview to convert the 8 LO svg files to 256x256 png files. The png files all opened much faster in image viewers. Yet again, the challenge is the LO release number is part of the file name. Thus converting the images to png is doable as proof-of-concept, but impractical to implement. Darrell

2 1

Re: [trinity-devel] Continnue interrupted git checkout
by Darrell Anderson 16 Dec '13

16 Dec '13

>Is there a way to continue an interrupted git checkout? Good question. I'd like to know too, especially after my recent weekend debacle with git. Darrell

1 0

Continnue interrupted git checkout
by Dr. Nikolaus Klepp 16 Dec '13

16 Dec '13

Hi all! Is there a way to continue an interrupted git checkout? Nik -- Please do not email me anything that you are not comfortable also sharing with the NSA. Dr. Nikolaus Klepp Einnehmerstraße 14 A-4810 Gmunden Tel.: +43 650 82 11 724 email: office(a)klepp.biz

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels