tde-devels

devels@trinitydesktop.org

3 participants
3805 discussions

R14 idea
by Darrell Anderson 15 May '12

15 May '12

Just an idea, nothing more: ============================================ Trinity Community, Those of us involved with developing and supporting the Trinity Desktop Environment want the next release to be the best yet. With that goal we ask you to help us by participating in some simple polls. 1. Which bugs listed in the bug tracker are your favorites as paper cut candidates? A paper cut candidate is bug which in and of itself is insignificant and might be trivial to fix, but when combined with similar bugs creates an overall impression of an unfinished, buggy piece of software. 2. Which bugs listed in the bug tracker are your Most Hated Bugs? This is the type of bug that hampers productivity, causes data corruption or loss, or is something that doesn't work as expected or intended. 3. Which enhancement requests in the bug tracker do you want to see in the next Trinity release? We will strive to resolve the top 20 vote getters in each of the first two lists and the top five vote getters for the third list. No priorities are needed. Just provide us your list. Limit the first two lists to 20 items per list per person and the third list to five items per person. Note: Only bug reports and enhancement requests listed in the bug tracker are eligible for these polls. Note: Build issues are not candidates because we expect and intend to resolve those issues one way or another before the next release. Bug tracker: http://bugs.pearsoncomputing.net/ At the bottom of the page the bug tracker contains links for commonly used search criteria. To list all reports filed, use the ALL search criteria. Any list can be sorted by selecting the appropriate column heading link. Thank you for helping and thank you for supporting and using Trinity! ============================================ Post this or a similar request to all mail lists asking community members to vote. I believe we have work remaining before we can consider a soft freeze for R14 preparations. These three polls would help us considerably with that preparation. Not to mention providing a good way for community involvement. Get users involved in a nominal way. The resulting corresponding resolutions show users they that have a voice and matter to us. The bug tracker provides a priority mechanism, but these polls help us refine those priorities. We all are itching for the next official release. Tentatively that release is scheduled for May, this month. Let's ignore hard deadlines and do this right. A serious effort now to make R14 as bug free as practical means fewer bugs for the next cycle. Not to mention more time for us all just to use and enjoy Trinity. For many of us summer is around the corner and all of us look forward to a more leisurely pace. If we truly polish the next release then we all can do just that. :-) Again, just an idea. Darrell

3 2

Build KDE3 on gcc 4.7 to test kwrite issue?
by David C. Rankin 14 May '12

14 May '12

Darrell, Do you have the capability to build Kde3 on gcc 4.7 to test the kwrite issue. I don't know if you have the same capabilities to build KDE as you do TDE, but since I don't and since I haven't gotten a confirmation from the SuSE folks, I'm curious if building 3.5.10 will show the same crash. If you have the sources and build scripts for it, it is probably worth doing just to see if we can eliminate the tqtinterface code as a possible source. If it is the same crash in KDE as it is in TDE, then tqtinterface should be able to be eliminated. Just a couple of stray thoughts that might add another piece of info to the puzzle. If it is tdelibs, then I'm not sure that it is even worth doing, but think about it. Also, Tim, have you been able to set up a gcc 4.7 build environment yet? I know you have another 26,539 things to do, but the more eyes we get on this thing, the sooner we will find the culprit. If anyone else has thought of another test they would like to see, then just let me know, happy to do it here -- as long as I know what to do. Thanks. -- David C. Rankin, J.D.,P.E.

3 3

Re: [trinity-devel] kwrite crash - it is tdelibs! (tqt3-46, tdelibs-47, tdebase-46 => crash)
by Timothy Pearson 14 May '12

14 May '12

> Tim, Darrell, All, > tdelibs is the package that causes the kwrite/kate/etc.. crash when > built on > gcc 47. The backtrace is good this time and points to: > at (i=<optimized out>, this=<optimized out>) at > /opt/tqt3/include/ntqstring.h:641 > 641 { return i < d->len ? d->unicode[i] : TQChar::null; } That is valuable information! This is also not an issue of ignoring build warnings, as there are none which relate to the failing code. If you can, please try the attached patch. It will probably do nothing, but there is half a chance that gcc 4.7 did not inline the functions where gcc 4.6 did, *potentially* causing a crash due to misuse of parameters passed by reference. Tim

4 13

Resizing kcontrol module windows launched from kcmshell
by Darrell Anderson 12 May '12

12 May '12

How are kcontrol module window sizes determined when launched from kcmshell? For example, 'kcmshell audiocd' opens to a window size of 765,778 and 'kcmshell media' opens to a window size of 765,512. I get the feeling the width of 765 is hard-coded somewhere but I can't find anything. I'd like to know how the width number is fixed, but at the moment I am more interested in how the height is determined for each window. Thanks. Darrell

1 1

Fw: Re: Adding to Registered OnlyShowIn Environments
by Darrell Anderson 11 May '12

11 May '12

I'm forwarding the following message. Please follow either link and pay attention to the table. :-) Darrell --- On Fri, 5/11/12, Vincent Untz <vuntz(a)gnome.org> wrote: > From: Vincent Untz <vuntz(a)gnome.org> > Subject: Re: Adding to Registered OnlyShowIn Environments > To: xdg(a)lists.freedesktop.org > Date: Friday, May 11, 2012, 7:13 AM > Le lundi 23 avril 2012, à 09:14 > +0200, Vincent Untz a écrit : > > Le samedi 21 avril 2012, à 07:44 -0700, Darrell > Anderson a écrit : > > > Greetings, > > > > > > I am writing on behalf of the members of the > Trinity Desktop Environment (TDE) project. > > > > > > TDE is a continuation of the KDE 3.5 desktop. > > > > > > We want to add TDE to the list of Registered > OnlyShowIn Environments: > > > > > > http://standards.freedesktop.org/menu-spec/latest/apb.html > > > > > > Please let me know how to proceed further. > > > > Do you prefer "TDE" or "Trinity" to be registered? > > > > Any objection? If no, this will go in the spec next > week. > > I was away for a bit, so it took more than a week ;-) But > it's done now: > http://specifications.freedesktop.org/menu-spec/menu-spec-latest.html#onlys… > > I also updated desktop-file-utils. > > Vincent > > -- > Les gens heureux ne sont pas pressés. > _______________________________________________ > xdg mailing list > xdg(a)lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xdg >

3 2

KControl and configuring autostart
by Darrell Anderson 10 May '12

10 May '12

Does Trinity support any methods for configuring autostart apps? I came across this applet but the links to the sources are dead: http://kde-apps.org/content/show.php?content=45975&forumpage=0&PHPSESSID=e1… With that said, looks like the applet might still exist: http://packages.ubuntu.com/search?keywords=kcontrol-autostart Darrell

5 20

Preparing updates for 3.5.13
by Slávek Banko 10 May '12

10 May '12

Hi In the user-list, I announced the state of preparation updates for 3.5.13: http://trinity-users.pearsoncomputing.net/?0::3008 I also strongly modify the article in Etherpad. Now there is also a current listing of included patches. This will be easier for me to keep it up to date... and perhaps even easier for you: http://trinity.etherpad.trinitydesktop.org/16 I would like to discuss with you whether further delay the official release updates? I intended to add to updates all packages for which were following patches: - Remove additional unneeded tq method conversions - Rename obsolete tq methods to standard names - Rename a few stragglers - Fix inadvertent "TQ" changes For some packages, already contained in the update, these patches solve tricky problems. But these patches applies to almost all the remaining packages. Therefore, I ask if I should go into it (will take some time to process it), or ask Tim whether to issue updates as they are ready now? Personally, I tend to do - to release as soon as possible. Updates already solves many errors. And that's why I find it useful to release as soon as possible. What is your opinion? I attach link to archive containing the current set of patches (5.4 MiB). Maybe useful for others who prepare packages for other distributions. http://www.axis.cz/linux/trinity-3.5.13-udpate-patches-1.tgz Slávek --

8 27

Two Settings menu options
by Darrell Anderson 09 May '12

09 May '12

In the TDE menu there are two menu options named "Settings," both inherited from 3.5.10. One Settings menu option is static and contains various items to configure application settings, not necessarily TDE related. The other Settings menu is dynamic, optional, and is related only to KControl preferences. Having two menu options with the same name is potentially confusing. Translations pose a challenge for renaming the static Settings menu (tdebase/applnk/tde-settingsmenu.directory). Renaming that menu option is further complicated because of XDG expectations. Renaming this menu option is best avoided. Renaming the dynamic menu option to "Control Center" or "Preferences" seems straightforward. There are at least two files that need editing: tdebase/kicker/menuext/prefmenu/prefmenu.desktop and prefmenu.cpp. Whereas translating to "Preferences" would be a steep uphill challenge, renaming to "Control Center" is almost painless. Although not a perfect one-to-one correspondence but very close, we would use KControl.desktop to copy and repopulate the Name keys. In all, quite doable. I don't know how renaming the dynamic menu option affects the Konqueror "settings:/" kio slave, if at all. Thoughts? Comments? Darrell

2 1

Why is HAL a bad word?
by David C. Rankin 09 May '12

09 May '12

Tim, All, After the discussion both here and on the suse list about the removal of HAL, that brought up a question that I don't fully understand. I know that everyone is moving away from HAL and that it is the way of the future, but "Why?" Briefly - what is wrong with HAL? Is it dead upstream? Does is pose limitations on the ability to do X or Y going forward? If so what are X or Y? Is it udev? What? Like Qt3, all of the past versions of KDE3 and TDE have used HAL and work fantastically - what is the motivation for dumping it? A short sentence or two would help me understand -- or a simply link to why if you have one will do. Thanks, I just want to make sure I understand the issue better... -- David C. Rankin, J.D.,P.E.

5 6

Re: [opensuse-kde3] suse versions and kde3
by David C. Rankin 07 May '12

07 May '12

On 05/07/2012 01:19 AM, Ilya Chernykh wrote: > On Monday 07 May 2012 08:12:48 Carolin Liefke wrote: > >> I asked about that before, but you didn't comment on it - what happened to >> this package in 12.1 since it's not in the repos? > > It requires hal. The reality is there is NO 'drop-in' replacement for HAL for either openSuSE's builds of KDE3 or TDE -- yet. HAL will be removed from both and all of the desired functionality WILL be preserved going forward -- BUT -- it will take time to iron all the issues out and make the transition. HAL is tightly integrated with the core of KDE3. As a result, moving away from HAL will take significant effort both from the gifted developers that code the removal AND from the user-base to provide feedback and bug reports of what does and does not work. If we were smart, we would coordinate the transition away from HAL among all the projects that support and develop KDE3 so that all projects can collaborate on the effort and benefit from what has already been done. Primarily to keep from reinventing the wheel and prevent against inconstancies being introduced by independent solutions. There is nothing wrong with exploring and attempting different solutions along the way, but there should be a common road-map to insure we all end up at the same finish line. What are your thoughts on where/how to coordinate these efforts? cc: trinity-devel -- David C. Rankin, J.D.,P.E.

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels