tde-devels

devels@trinitydesktop.org

9 participants
3790 discussions

Start a nNew thread

Re: [trinity-devel] Tellico source old - new source requires kde4/qt4 - author contacted
by Darrell Anderson 14 Feb '14

14 Feb '14

>Added as: http://bugs.pearsoncomputing.net/show_bug.cgi?id=1932 Now beg Francois and Slavek to help. :) Darrell

1 0

Re: [trinity-devel] Tellico source old - new source requires kde4/qt4 - author contacted
by Darrell Anderson 14 Feb '14

14 Feb '14

>Got a response from the Author: > >1.3.6 was the last version for KDE3. You can grab the tarball >here: >http://tellico-project.org/download > >It's tagged in the git repo as v1.3.6, which is probably an upload >of the tarball. > >We should consider updating the TDE code to 1.3.6. File an enhancement request. Francois and Slavek have gotten good at pulling in KDE3 apps into Trinity. Darrell

2 1

Tellico source old - new source requires kde4/qt4 - author contacted
by David C. Rankin 13 Feb '14

13 Feb '14

All, I have built tellico for the first time and it looks like a good collection manager (any collection, music, wine, whatever..) that we will want to keep. The problem is the source is quite old (1.3.2.1 - 2008). Tellico continues as an active ongoing project led by Robby Stephenson. http://tellico-project.org/ I've contacted him to determine what the latest version is that will build on kde3/qt3. Many new features have been added to tellico and I would like to see TDE take advantage of the updates. The current tellico code is hosted in a git repository: git clone git://anongit.kde.org/tellico I'll report back with the response. If we have the latest, then it may be worth while to take a look at what it would take to patch/port the current code to again build on TDE and perhaps create a new branch on the project git repo. -- David C. Rankin, J.D.,P.E.

1 1

Re: [trinity-devel] tdepim - no kmail icon in 'Internet' menu + config dialog way too small (clipping example captured!)
by Darrell Anderson 13 Feb '14

13 Feb '14

>Sounds good to me, too. Pushed to git in commits f2321faa for tdelibs and ed95608f for tdepim. The groupware title bar branding was fixed in ed95608f too. Darrell

1 0

Re: [trinity-devel] tdepim - no kmail icon in 'Internet' menu + config dialog way too small (clipping example captured!)
by Darrell Anderson 13 Feb '14

13 Feb '14

After fiddling and tweaking here is my proposal: Personal Information Management submenu Move to Internet menu: Mail Alert (Korn) Mail Client (KMail) Move to Office menu: Address Manager (KAddressBook) Encryption tool (KGpg) Note Taker (KJots) Personal Alarm Scheduler (KAlarm) Personal Information Manager (Kontact) Personal Organizer (KOrganizer) Personal Time Tracker (KArm) Signature Editor (KSig) TDE Groupware Wizard TNEF File Viewer (KTnef) Delete Personal Information Management submenu from the menu structure. With this arrangement, including the KDE(4) submenu, and an almost full Trinity install, on my 1280x800 laptop screen I can open the Trinity Internet and Office menus without unfolding into a second column. Hopefully there are very few users who install every single Trinity app. Therefore menu size and clutter should not be a problem for most users. Is this acceptable? Darrell

4 3

Is anybody able to start the groupwise wizard in R14?
by Darrell Anderson 13 Feb '14

13 Feb '14

I cannot and I found the following reasons: ldd /opt/trinity/bin/groupwarewizard libegroupwarewizard.so => not found libsloxwizard.so => not found libkolabwizard.so => not found libexchangewizard.so => not found ldd /opt/trinity/bin/egroupwarewizard libegroupwarewizard.so => not found ldd /opt/trinity/bin/exchangewizard libexchangewizard.so => not found ldd /opt/trinity/bin/kolabwizard libkolabwizard.so => not found ldd /opt/trinity/bin/scalixwizard libscalixwizard.so => not found ldd /opt/trinity/bin/groupwisewizard libgroupwisewizard.so => not found My build script includes: -DWITH_ALL_OPTIONS=ON -DBUILD_ALL=ON The *.so files exist, but none of the binaries are linked correctly. Darrell

2 2

Re: [trinity-devel] tdepim - no kmail icon in 'Internet' menu + config dialog way too small (clipping example captured!)
by Darrell Anderson 13 Feb '14

13 Feb '14

> kmenu/office/personal information management/ > > The menu was almost impossible to spot due to it being non- >standard all lower >case. It looks like this was just a temporary placeholder that got >forgotten >about. Is this an intended change? If so, I suggest a patch to put >an 'e-mail' >entry back under 'internet' where people usually look for >'internet' apps and I have no idea how you get all lower case. On my system the menu is proper mixed case: Personal Information Management >perhaps shortening the sub-menu folder name from > > personal information management > >to simply > > PIM > >or > > Trinity - PIM Acronyms in a menu? How does 'PIM' translate in Swahili? Not going to happen. > Burring kmail, kaddressbook, kontact, kalarm, and kgqg under >kmenu/office/personal information management/ just seems like a >recipe for complaint: You are the first and only person to complain since we made the changes many, many months ago. >http://www.3111skyline.com/dl/dt/trinity/ss/tdepim-submenu.jpg According to that image, I don't see any all lower case instances of anything. All proper mixed case. > If we are dead-set on having a "personal information management" >menu, then at >least make it consistent in standard "title" case and move it to a >top-level >menu as: > >Personal Information Management That is how the menu already appears on my system and in your screenshot. Something is wrong at your end. > And at least add kmail and kontact entries back to the Internet >menu. Further >regarding the 'Internet' menu -- all submenus have disappeared. >Looking.. All >submenus in tmenu or kmenu are gone except for one 'Super User' >submenu under >System and the normal 'Games', 'Development' and 'Edutainment' >submenus. I like >the menu cleanup, but we need to put internet apps back under >'Internet'. That all said, I am uncomfortable with the Personal Information Management sub menu. Our original goal was to reduce clutter. Try using the original menu in 3.5.13.x with KDE4 concurrently installed. Impossible to navigate with all the duplication and the menu size exceeds the desktop height. Even now, on a 1200x800 laptop screen, with a full Trinity installation, the menu is long and nearly pushes the edge of the top of the screen. Without the KDE submenus, the problem would be exactly the same. Pulling the apps from the Personal Information Management submenu into parent menus will make the menus longer. Try using Xfce with Trinity and KDE4 installed. There are no submenus. Horrible. Office seems more natural to me than Internet to find KMail. Lots of people use mail clients in local office networks. I suspect most office users do not consider mail an internet app but an office app. Likewise for other PIM apps. The internet is only an extension of those office related apps. I'll tinker to see what we can do. Darrell

2 1

Request for screen shots
by Michele Calgaro 13 Feb '14

13 Feb '14

Darrell, see attached some screenshots from a clean base system (tqt3 to tdebase) installation. Michele

1 0

Re: [trinity-devel] Alternative release version numbering scheme proposal
by Darrell Anderson 13 Feb '14

13 Feb '14

>Looking forward for your opinions. To Michele: I prefer the version system we have. The 90-day cycle will create the desired impression that Trinity is an active project. The long lapse caused by R14 has not helped us and is unusual, but hasn't killed us either --- we did have two maintenance releases. To David: We are not embracing a rapid release schedule. We are embracing a maintenance release schedule. The focus is a timely release of bug and security fixes. We do not have the resources for rapid release. We do not have the desire for rapid release. Trinity is not about using software as a playground to test ideas and brainstorms while users suffer. Trinity is all about retaining a traditional desktop interface. The types of new features we introduce conform to that project goal, which means we should never see a feature that breaks everything. I am not in favor of Yet Another Number in the Version scheme. Three numbers is enough. I'll scream and shout for anything longer than tree. I don't mind the R14 version scheme. I was not in favor of using 3.5.13.1 and 3.5.13.2 as versions. Those versions should have been 3.5.14 and 3.5.15. Or, because of ABI breakage, 3.6 and 3.6.1. What is done is done. Moving forward we need the new version scheme to form our own identity. We discussed all of this long ago, even before you departed for many months. The new version scheme is explained in the release notes. Open the help handbook, select the "Welcome to TDE" handbook, and select the Release Notes link. I won't resist dropping the "R" from the version number. I'm fine with R14.0.0 or 14.0.0. Soap box time: =========================== The current version scheme is explained in tdeversion.h: R <ABI VERSION> . <FEATURE REVISION> . <BUG AND SECURITY PATCH LEVEL> Initial release is always R<ABI VERSION>.0.0. BUG AND SECURITY PATCH LEVEL is always updated with a point release. FEATURE REVISION is updated when new features are introduced or existing features are significantly updated. A FEATURE REVISION release does NOT include ABI changes. A new FEATURE REVISION level always resets the BUG AND SECURITY PATCHLEVEL. A new ABI version resets both the FEATURE REVISION and BUG AND SECURITY PATCH LEVEL. =========================== The big difference between current practices and post R14.0.0? We have to plan and to discipline ourselves. We have not done that at all during the R14 cycle. We just push and build. Considering the way things have been done in the past, our current version scheme will always requires a main branch. We are not finished with package and library renaming. More to come. ABI/API breakage seems to occur frequently enough. Or, did frequently enough at one time. Usually unannounced. Future ABI/API breakage will have to be planned. Such patches will have to sit and wait until all other plans are finished and everybody is ready to proceed. Throughout the R14 cycle, we have not adhered to this version scheme. We have been regularly throwing darts and changing everything. After R14.0.0 we will have to discipline ourselves. =========================== From a public awareness perspective, and I emphasize public awareness perspective, we're not dead yet as a project, but the R14 cycle has been a slow and painful journey toward death for Trinity. I want to emphasize and defend that we need a maintenance release cycle. We need to get back into the public eye. The R14 cycle has been grueling. Many users have all but forgotten Trinity. That is not good for us. Better awareness in the free/libre community means more users, more eyes, hopefully more people helping patch and improve Trinity. We have been super cautious about releasing R14. I believe we will be rewarded with good reviews. We need to motivate ourselves with keeping users happy. We do that with a maintenance release cycle. They have not been seeing Trinity much in the news the past 18 months. They are not seeing bug fixes. Is Trinity dead? A maintenance release cycle stifles such questions. The Xfce project is a good example. They strictly use the "release when ready" strategy. Their last release announcement on their web site is getting close to two years old. Not comforting to users. I appreciate Michele's long thoughts about the challenges we face. At the moment I remain open but I am not convinced to release the main trunk. Why? * Our commit history is evidence for not doing that. * We have no quality control program. * We have no cmake conversion audit program. * We have no mechanism to ensure i18n files are updated concurrently with parent modules (within the limitations of translation). * We have no program to ensure help handbooks are updated timely, which includes i18n too. * We tend to push patches that "work for me" but occasionally do not work for others (and all of us have pushed such patches, including me). That is, releasing from the main trunk will slowly hurt the project to the point that the only users will be the developers. I appreciate the energy required to maintain multiple branches. But unlike LO, we will only maintain two active branches. When the R14.0.1 tarballs are released we stop supporting R14.0.1 and that branch is frozen, perhaps even deleted after the tarballs are released. We then create the R14.0.2 or R14.1.0 branch. Or, the R14.0.1 branch automatically becomes the R14.0.2 or R14.1.0 branch after the tarballs are released. We need only maintain the main trunk and the next maintenance release branch. Simple. We will need to plan future releases. That way we know exactly what to backport and when. =========================== Our goals with the 90-day cycle is not to play the idiotic version scheme of some well-known software. Our goals include 1) ensuring bug fixes are released in a timely manner and 2) keeping Trinity in the public eye. After R14.0.0 we need to keep bug and security patches rolling. The ultra long R14 cycle has been a grand exception. A nominal press release every 90 days keeps Trinity in the news. A 90-day release cycle keeps the bug patches flowing in a timely manner. Yes, the 90-day schedule is intended to be hard-fast. Whether we release with 3 bug fixes or 30 is irrelevant. We release every 90 days. No, the 90-day schedule is not intended to be a rapid release schedule. The focus is very much timely releases of bug patches. We can release sooner than 90 days but only when a show stopper bug slips by all of us and cause great pain for users. Likewise for severe security issues. By design, each maintenance release will increment the last number in the version sequence: R14.0.1, R14.0.2, etc. Renaming changes and new features will increment the MINOR number in the version sequence: R14.1.0, R14.2.0, etc. =========================== A significant difference between future maintenance releases and 3.5.13.1 and 3.5.13.2 is we won't suffer the challenge of renaming. The bug fix patches included in the 3.5.13.x releases all had to revert renaming changes. That was a huge burden. That will not happen in future maintenance releases. We will have no need to revert renaming changes in the maintenance release cycle. All we need do with future renaming changes is bump the MINOR version number. Future renaming changes are <FEATURE REVISION> and not <BUG AND SECURITY PATCH LEVEL>. The first set of renaming changes after R14.0.0 bumps the version to R14.1.0. This includes cmake conversions. We have seen renaming changes introduce severe bugs. We will need to plan and test renaming changes in the main trunk before backporting to the next maintenance release. We need to discipline ourselves. Unlike the R14 cycle, we need to plan renaming events. There are many apps that we can and should rename. tdevelop and tdesdk remain a convoluted mess of tde* and kde* names. We don't blindly push such patches. We agree on when such patches will be pushed. We agree on when such patches are backported. Agreeing on such patches will reduce stress and help maintain the multiple branches in a sane manner. We can push almost anything into the main trunk, but what gets pulled into the next maintenance release branch should be a part of a plan. For example, R14.0.1: bug fixes only. R14.1.0: tde-i18n changes and bug fixes. R14.1.1: bug fixes. Bug fixes always get backported to the next maintenance release branch. Other patches might not get backported immediately, but if we backport more than bug fixes then we bump the MINOR number. All of us involved at the development level will need to learn from other projects how people maintain different branches. For example, the LO folks now have a main trunk, a 4.2 branch, a 4.1 branch, a 3.6 branch. How do they decide what gets backported? Yet they seem to handle this with no problems. We learn how to do likewise. =========================== To summarize: Maintenance releases will be released as tarballs. Users are never affected by anything that happens in the main trunk. Easy to forget that those of us using git are volunteer guinea pigs. Users are not. This is not a rapid release schedule. Primarily this is a focus on timely releases of bug fixes and planned feature releases. Future releases will be planned. At the moment I'm comfortable with the current version scheme and am not in favor of pushing the main trunk as an official release. Darrell

2 1

tdepim - no kmail icon in 'Internet' menu + config dialog way too small (clipping example captured!)
by David C. Rankin 13 Feb '14

13 Feb '14

All, There is no kmail menu entry under internet? I have always seen an Internet/E-Mail menu and if not an e-mail submenu, then at least an entry for kmail under internet. Now I searched and finally found kmail under the: kmenu/office/personal information management/ The menu was almost impossible to spot due to it being non-standard all lower case. It looks like this was just a temporary placeholder that got forgotten about. Is this an intended change? If so, I suggest a patch to put an 'e-mail' entry back under 'internet' where people usually look for 'internet' apps and perhaps shortening the sub-menu folder name from personal information management to simply PIM or Trinity - PIM Burring kmail, kaddressbook, kontact, kalarm, and kgqg under kmenu/office/personal information management/ just seems like a recipe for complaint: http://www.3111skyline.com/dl/dt/trinity/ss/tdepim-submenu.jpg If we are dead-set on having a "personal information management" menu, then at least make it consistent in standard "title" case and move it to a top-level menu as: Personal Information Management And at least add kmail and kontact entries back to the Internet menu. Further regarding the 'Internet' menu -- all submenus have disappeared. Looking.. All submenus in tmenu or kmenu are gone except for one 'Super User' submenu under System and the normal 'Games', 'Development' and 'Edutainment' submenus. I like the menu cleanup, but we need to put internet apps back under 'Internet'. Second issue. When you configure kmail and press the [Test] button to test your email connection, the current dialog doesn't even come close to accommodating the information displayed: http://www.3111skyline.com/dl/dt/trinity/ss/kmail-config-clipped.jpg HAH, THIS ALSO CAUGHT AN EXAMPLE OF HOW NEARLY ALL DIALOG ENTRIES ARE CLIPPED IN-HALF WHEN THE DIALOG IS FIRST DISPLAY... The line showing 'Use Secure Connection (SSL)' is clipped in half. This is the way almost all of my TDE dialogs look when first displayed until focus leaves and then returns to the dialog. I knew I would catch an example of this :) -- David C. Rankin, J.D.,P.E.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels