tde-devels October 2012

devels@trinitydesktop.org

20 participants
56 discussions

Re: [trinity-devel] A few duplicate locolor icons
by Slávek Banko 23 Oct '12

23 Oct '12

Dne Monday 22 of October 2012 21:41:45 jste napsal(a): > On Monday 22 of October 2012 21:36:31 Francois Andriot wrote: > > >> I show the following in my package sets: > > >> > > >> kbabel.png: > > >> tdeartwork, tdesdk > > >> > > >> ktimemon.png: > > >> tdeartwork, tdeaddons > > >> > > >> Darrell > > > > > > Yes, we have the same files - Debian binary packages are more > > > granulary. I will update the installation, to be installed in only one > > > of these packages. The question is, from which package? > > > > > > a) All from tdearwork > > > b) From tdeaddons and tdesdk > > > c) None of the above => another interesting idea :) > > > > > > Slavek > > > > I think the locolor icons should go with the package that provides the > > "index" for the locolor theme. > > Without the index installed, the icons are useless. > > I believe the package providing locolor index is tdeartwork. > > > > Francois > > François, absolutely perfect note! > The decision was made :) > > Thank you. > > Slavek It's a little complicated. Icons are installed in the standard way (automake as well as cmake) == automatically installs all variants of the icon that are available. It appears that there are three possible solutions: 1) Remove locolor icon. 2) Rename icon or move to a subfolder. 3) Skip icon during packaging in individual distributions. Any other ideas? Which solution seems preferable? Slavek --

2 4

RPM packages for 3.5.13.1
by Darrell Anderson 22 Oct '12

22 Oct '12

Some favorable comments here about Trinity: http://lxer.com/module/forums/t/33920/ Folks are looking for 3.5.13.1 RPM packages but the Trinity web site has no links. I recall reading Francois had made RPM packages for several distros. Where are the links on the web page? Darrell

5 11

A few duplicate locolor icons
by Slávek Banko 22 Oct '12

22 Oct '12

Hi all, With commit e5a2da23 showed few duplicate locolor icons: tdeartwork-theme-icon-trinity: opt/trinity/share/icons/Locolor/16x16/apps/kbabel.png opt/trinity/share/icons/Locolor/16x16/apps/ktimemon.png opt/trinity/share/icons/Locolor/32x32/apps/kbabel.png opt/trinity/share/icons/Locolor/32x32/apps/ktimemon.png kicker-applets-trinity: opt/trinity/share/icons/locolor/32x32/apps/ktimemon.png opt/trinity/share/icons/locolor/16x16/apps/ktimemon.png kbabel-trinity: opt/trinity/share/icons/locolor/32x32/apps/kbabel.png opt/trinity/share/icons/locolor/16x16/apps/kbabel.png I have a very simple question is: From which package exclude their installation? I'd recommend installing with the tdeartwork and exclude from tdeaddons and tdesdk. What is your opinion? Slavek --

3 6

To hide or not to hide (symbols)
by Darrell Anderson 22 Oct '12

22 Oct '12

Been a long time since we discussed gcc hidden visibility for symbols. Last I remember, this was supported in (T)Qt3, arts, tdelibs, and tdebase. I tried building my normal package suite with this option enabled in every package. Some packages built but ignored the configure option. Some failed to build. Some built and there were no messages at all about the option. Removing the option from the failure group allowed the packages to build. For the latter group, as no errors or build failures occurred, I presume the option is supported. Still, is this a good idea? I read a bit about the topic and the information is way over my head. The only thing I do understand is using the option is supposed to reduce libary size and improve loading speeds. Darrell

2 7

Q_ENUMS->TQ_ENUMS
by Darrell Anderson 22 Oct '12

22 Oct '12

Tim, I pushed patches for koffice and kmymoney to update Q_ENUMS->TQ_ENUMS. They both failed to build last night during my build run. Both now build. Darrell

1 0

Tim: Commit f209ff4b, et. al. breaks tdebindings
by Darrell Anderson 21 Oct '12

21 Oct '12

I built my normal package set on Oct. 15. Today I can't. My local tree is current. The failure messages with tdebindings: x_16.cpp:5632: error: ISO C++ forbids initialization in array new x_16.cpp:5632: error: no matching function for call to 'TQStyleControlElementGenericWidgetData::TQStyleControlElementGenericWidgetData(TQStyleControlElementGenericWidgetData [4])' x_16.cpp:5656: error: expected primary-expression before '[' token x_16.cpp:5656: error: expected primary-expression before ')' token x_16.cpp:5656: error: expected ';' before 'x' Looking at the commits since Oct. 15 I see f209ff4b, which has code that matches the failure messages. x_16.cpp, which is generated during the build, has #include <ntqstyle.h>. After rebuilding tqt3, /opt/trinity/include/ntqstyle.h includes class TQStyleControlElementGenericWidgetData. How do we fix? Darrell

2 2

kate/kwrite stalls a long time opening any *.kcrash file
by Darrell Anderson 21 Oct '12

21 Oct '12

Latest R14. Would somebody please confirm this behavior? Run crashtest. Save the backtrace. Open the file with kate or kwrite. Open directly from within or through konqueror. On my dual core system with SATA II drives, opening a *.kcrash file takes more than a minute to open, creating the impression the app has stalled or locked. Thanks. Darrell

3 4

Quick 3.5.13.1 test please
by Darrell Anderson 20 Oct '12

20 Oct '12

Would somebody running 3.5.13.1 please test opening kopete? Thank you! Darrell

3 4

cmake help building amarok (Serghei?)
by Darrell Anderson 19 Oct '12

19 Oct '12

I'm trying to resolve bug report 1040 with respect to amarok not building with cmake. Under normal conditions, the build always fails with the following: /dev/shm/amarok/amarok/src/amarokcore/amarokdcophandler.cpp:914: error: 'ScriptManager' has not been declared /dev/shm/amarok/amarok/src/amarokcore/amarokdcophandler.cpp:919: error: 'ScriptManager' has not been declared /dev/shm/amarok/amarok/src/amarokcore/amarokdcophandler.cpp:924: error: 'ScriptManager' has not been declared I concluded that amarokdcophandler.cpp was not finding scriptmanager.h, which is in the parent directory. As a test, I copied scriptmanager.h to the same directory as amarokdcophandler.cpp. The build failures disappeared and the package built. Seems that amarok/amarok/src/amarokcore/CMakeLists.txt needs to be fixed but I don't know what to do. Thanks much! Darrell

2 9

bug update
by Calvin Morrison 19 Oct '12

19 Oct '12

Darrell, I have updated the bug tracker to automatically add you to the CC list, and I have just added you as a CC for all current bugs. It may take several minutes to complete that operation but should go through fine. Anyone else need bugzilla related things? Calvin

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels October 2012