> If KDE has finally gotten their act together for even part of they
> desktop, we should look at deprecating parts of TDE which duplicate
> functionality.
> 
> KOffice immediately springs to mind, but we would need some consensus from
> users that the KDE4 application is a true replacement for the old TDE
> application before proceeding.
> 
> One area where I want to see greater cooperation between TDE/XFCE/KDE/Gnome is in kioslaves and file handling
> dialogs.  As far as I am concerned this is the last great barrier between
> mixing/matching toolkits in a single session.  IMHO there is no reason
> why we shouldn't be able to hammer out some kind of extensible common API to
> handle these tasks; computers have been dealing with file selection and
> management for decades; the fact that all the major toolkits have
> reinvented the wheel in incompatible/nonextensible ways is absurd.
> 
> The only other thing that still concerns me is the continual breakage from
> the upstream Qt project; Qt 4.8 for example contains a number of drawing
> bugs that make non-pixmap based styling very difficult.  Anyone who has
> tried the TDE/Qt4 theme engine on Qt >= 4.8 will know exactly what I am
> referring to. ;-)
> 
> As the KDE4 "desktop" itself does things very differently than TDE there
> is very little chance that the TDE desktop  will ever be able to be
> replaced, but this cannot be said about the application ecosystem itself.
> If a better, feature-full KDE4 application exists we should seriously
> consider deprecating the TDE equivalent to reduce our maintenance load.
> When I say feature-full I mean that the new application can do everything
> the TDE equivalent could, including supporting the original TDE workflow.
> 
> Thoughts are of course welcome!

I believe the answer to your question depends upon perspective. As a developer I would want to reduce duplicity and overhead --- when palatable. As a user I want consistency in my environment.

I understand that the Trinity version of KOffice is getting a little long in the tooth. I also agree that OpenOffice/LibreOffice probably is a better replacement for many users. Yet as we have discussed in the past, the Trinity version remains useful --- but must be advertised appropriately. We should not mislead users by claiming that Trinity KOffice is a powerful or market-competitive office suite of apps. We advertise KOffice as a lightweight office suite that is suitable for home and small business users with modest needs. With that focus we reduce maintenance on the package to bug fixes. Don't build expectations and there won't be any. :)

If KOffice were to be abandoned, there are a handful of apps in the collection that could be saved. Or, as requested in enhancement request 464, we split KOffice into individual packages. That move reduces maintenance and retains the smaller apps. We do need to address a few issues such updating ODT support and possibly abandoning ruby support.

Unless or until we form a serious collective effort to improve Trinity for the enterprise, we should be realistic that most Trinity users are and will be home users and small business users. From that perspective retaining KOffice seems palatable to me. Large-scale enterprise administrators will opt for an enterprise office suite such as OpenOffice or LibreOffice. We need not delude ourselves. Likewise for other apps too even if they like Trinity as the basic desktop. Yet from the focus of home and small business users, I see no reason that Trinity KOffice need be abandoned.

I can't discuss kio slaves because that is over my head. :) I agree with the sentiment, but people well versed in coding kio slaves need to step forward and promote those discussions among the developers of the leading desktops.

Regarding other aspects about KDE4, we don't need to rehash those arguments. Yes, finally KDE4 is looking like the desktop environment promised and envisioned years before the developers abandoned KDE3. I'd like to see some limited integration, such as webkit for Konqueror, but otherwise I myself am not interested in anything further. Other than such limited integration, I much rather want to see the bug tracker attacked in a serious way to render Trinity the best damn small desktop environment of all.

I agree we should shed some weight by evaluating the source tree. That is a goal listed in the R14 road map. We should not panic or go hog wild. As Trinity and KDE4 can be installed concurrently without conflict, I see no reason to rush into decisions. That is, users who need or want apps from Qt4/KDE4 need only install and off they go. I also believe that any serious pruning decisions should be post R14. We have an etherpad for collecting post R14 ideas.

Unless a slew of skilled people join the development team, we cannot keep pace with innovations in KDE4, and I have no illusions of us backporting major segments of code for apps such as krita, kdenlive, okular, etc. People who need or want those apps will have to use them from KDE4 because Trinity does not offer anything like that. Conversely, I don't believe the Trinity user is focused on those types of apps or wants significant changes in how they use desktop software. We stay focused on those users, regardless of how small the community. The Xfce folks are doing just fine for those GTK fans who dislike the changes in GNOME, yet I'd be much surprised if the Xfce user base is anything close to the size of the GNOME or KDE4 user base.

Despite the improvements, and after more than four years of active development, I remain amazed that many people using KDE4 still long for the KDE3 desktop. This not nostalgia, these people miss the way certain things are done. Thus there is a niche to fill and serve. I believe then that our post R14 evaluations are two fold: 1) how to retain a desktop environment built upon the KDE3 style and 2) which apps to retain and which to abandon.

As a post R14 topic, I believe we address both questions nicely if we move toward splitting all modules to individual component apps. For the most part this is a packaging issue but we would need guidance for all packagers in order that all packagers provide the same package set. From that point we more easily decide which components to abandon, which to retain in maintenance mode only, and which to continually improve.

If app usage will drive Trinity's future, then split apps into individual packages. This provides end-users significant flexibility when they want to mix and match apps from different desktops. We still need to provide a fundamental desktop, one that is robust, stable, and highly functional. In that light I don't see much change with tdelibs or the other core modules, but I envision even tdebase being split.

Trinity fills a nice segment of the free/libre desktop collection. Many of the KDE4 developers recognize that and have no issue with people using or maintaining Trinity. They are content to leave us alone to scratch our own itch. As long as we don't mislead users and we remain active with maintenance, I believe that segment will be well served for a long time.

In short we keep tending our garden and we find peace in that. :)

Darrell