>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
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.
>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
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
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
> 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
>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
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.
> 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