tde-devels

devels@trinitydesktop.org

2 participants
3755 discussions

Is anybody able to start the groupwise wizard in R14?

by Darrell Anderson

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

10 years, 11 months

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

by Darrell Anderson

> 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

10 years, 11 months

Request for screen shots

by Michele Calgaro

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

10 years, 11 months

Re: [trinity-devel] Alternative release version numbering scheme proposal

by Darrell Anderson

>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

10 years, 11 months

tdepim - no kmail icon in 'Internet' menu + config dialog way too small (clipping example captured!)

by David C. Rankin

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.

10 years, 11 months

Re: [trinity-devel] tde-Tork builds and works -- amazingly

by Darrell Anderson

> I had never built tork before and had no idea what it was, much >less what it >did -- well -- it works! Basically it is an internet anonymity >extension and >functions both as a proxy client and proxy server (configurable). >It is >basically a tool that allows you to browse/email/ssh anonymously. I don't think tor masks IP addresses in mail headers when sent through SMTP/POP3. Darrell

10 years, 12 months

Alternative release version numbering scheme proposal

by Michele Calgaro

Dear all, in etherpad 63 (http://trinity.etherpad.trinitydesktop.org/63) we had some discussions about switching to a fixed-time release cycle after R14.0.0 is out of the door. The end result of those discussions and the preliminary agreement of some developers is to use a 90-day release cycle (pending Tim's agreement too :) ). The idea is to issue a maintenance release R14.0.x every 3 months, containing bug fixes and minor improvements, and issue a minor release R14.y.0 every year containing bigger improvements. This will require bugs to be backported from the trunk to the R14.0.x branch for up to 9 months (which could become not that easy after several changes are done in the trunk) and would provide major improvements to the users only once a year. On the other hand, it may prove a more stable solution. An alternative scenario I have been tinkering for a while lately is one where every 3 months we ship whatever is in the trunk as the next release. In this case we do not need to backport any bug and users would be able to get major improvements up to 4 times each year. On the other hand we may introduce some degree of instability if a feature is not well tested before shipping it (but in any case that risk would exist also with the minor R14.y.0 releases of the first scenario), with the "fixing time" being the same (3 months in both scenarios). Given the limited amount of development resources that we have, I have come to like the second scenario the most, and I would like to hear the opinion of other developers as well. If we end up adopting the second scenario, I would also like to propose an alternative release version numbering schema: Ryy.x, where yy is the year number and x is a progressive release number within the yy year. So for example this year we would have R14.0, R14.1, R14.2 (and R14.3 is R14.0 is released before March 31). Then next year we would have R15.0, R15.1, R15.2 and R15.3 and so on.... Coincidentally, this year is 2014, so the year number matches the R14 release number too :) Also, a side-effect benefit would be that TDE would look more active to the general public with Ryy.x release numbers than R14.0.x release numbers, since the last would probably be thought of as "nothing major, just minor fixes". Looking forward for your opinions. Cheers Michele

10 years, 12 months

tde-Tork builds and works -- amazingly

by David C. Rankin

All, I had never built tork before and had no idea what it was, much less what it did -- well -- it works! Basically it is an internet anonymity extension and functions both as a proxy client and proxy server (configurable). It is basically a tool that allows you to browse/email/ssh anonymously. I still have no idea how to fully use it, but it was refreshing to see that some random app near the end of the applications build tree -- works -- without a lot of CPR. I haven't checked the code, but did see KDE4 patched tork for ipv6. We may need to do that as well. http://www.3111skyline.com/dl/dt/trinity/ss/tork-01.jpg -- David C. Rankin, J.D.,P.E.

10 years, 12 months

Re: [trinity-devel] OnlyShowIn=TDE or NotShowIn=KDE?

by Darrell Anderson

>That brings us to the point of -- "What is a proper XDG_* >environment for >trinity?" Right now in tqtinterface, we have complete control over >the XDG >environment with trinity.sh. I currently have: > >What additional can we do/(do better) with the environment setup? As I wrote previously, Debian based distros do not use /etc/profile.d. We need to explore how to modify the XDG_*variables without using /etc/profile.d. >+1 When I was shopping desktops, it was not uncommon to have kde3, >kde4, wm2 >fvmwm2, e-16, e-17, gnome, fluxbox, twm, blackbox, openbox, etc. >all installed >simultaneously. The only real havoc was caused by kde3/kde4/gnome. >That's why >the X11 project put out an entire menuing standard to handle what >is isn't >visible in each desktop. I've picked through the standard, but >never compared >between what we have and what is says. Further, in doing so, I >don't ever recall >seeing a clean way of preventing the kde3/kde4/gnome menu mess. It >is almost as >if there is a need for a global 'menuedit' to manage /etc/xdg/menu >on a global >and per/user basis to include/exclude apps in menus when multiple >desktop environments are installed. The menus we now install work well enough within Trinity. We have the option to compile with a "[KDE]" suffix. To reduce menu clutter from duplicate naming, the default Trinity menu places all KDE menu items in a separate "KDE" submenu. We also have an alternate menu that must be installed manually that excludes all KDE menu items. We probably should have a GUI option somewhere to swap those two menu options. The menu mess begins outside of Trinity. Darrell

10 years, 12 months

Re: [trinity-devel] OnlyShowIn=TDE or NotShowIn=KDE?

by Darrell Anderson

> Do you want a bug open on this one, or just push it? I think it >is small >enough just to push it. Get our fearless leader to comment, but >unless someone >wants a bug opened, I'd just push it if all give the nod. I will push changes for the few *.desktop files discussed. As I mentioned, the core problem is not OnlyShowIn=TDE but the XDG_* environment variables. In the broader scheme, we have no remedy for getting other environments to source /opt/trinity in the XDG_* environment variables. In distros that use /etc/profile.d, the solution is to ensure a script is installed (could be nothing more than the normal trinity.sh script). For the distros that don't use /etc/profile.d, such as Debian, I don't know how to ensure XDG_* variables are modified to recognize /opt/trinity. As I mentioned, when KDE4 is concurrently installed with Trinity, the result will be a menu mess one way or another, unless we provide distro maintainers a more organized menu structure to handle the KDE4/Trinity overload. Some might ask, why would users install Trinity and use a different environment? Many users prefer window managers rather than full desktops, but prefer a selection of apps from the full desktop environments. Many systems are multi-user, and the various users select what to run. In those instances, all options must be installed. There is a growing restlessness in the KDE4 community for PIM apps that do not rely on the akonadi/nepomuk foundation. Trinity PIM apps could fill that role, but without modifying the XDG_* environment variables, the apps won't be found in non-Trinity desktops. Darrell

10 years, 12 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels