> The new feature should be present in SVN revision 1174561
> or higher.  It
> will detect when libcarddav or libcaldav are not present
> and automatically
> deactivate the affected resource(s).
> >
> I agree 100% there.  My earlier comment was based on
> this: The
> caldav/carddav libraries add the same type of functionality
> as was already
> present in kdepim resources such as Kolab and GroupDAV,
> which are always
> built (there is no way to shut them off; this has been so
> since their
> creation many, many KDE3 releases ago)  The only
> difference is that those
> resources don't rely on an external dependency.  So, I
> gather that the
> reason you want to deactivate carddav/caldav support is due
> to the
> external dependency required; not because the added
> functionality is
> unwanted.
> 
> This also brings up another question: Do you want the
> ability to
> individually deactivate each resource present in the
> kresources folder? 
> Since I figured out how to do this type of operation it
> won't be as
> difficult.

Parts of what you are explaining just results in glassy eyes. :) Let me see whether I can answer your quesations.

Traditionally, KDE always has been built in Slackware using stock sources. If you say much of the functionality was already provided within KDE, then in a stock Slackware that functionality would be present too. Patrick is not known for patching upstream sources to add or delete features. That attitude probably has much to do with why Slackware systems seem faster than other systems.

Of course, the definition of "stock" changes in Trinity. If I understand correctly, you have taken some built-in functionality and moved those features outside of KDE, which allows more than just kdepim to take advantage. In that respect then, building libical, libcaldav, and libcarddav as required dependencies makes sense because in the end KDE has the same functionality.

If I understand correctly, if a user's system does not have any DAV tools, then those features within kdepim become dead-end stubs.

As far as building packages, I suppose the end result is the same. From a pragmatic perspective, whether the functionality is built-in or external is immaterial. What is, is.

I can't speak for other Slackware users. I have no idea whether many or most want or need DAV hooks. I have no idea. I do know that traditionally, if a Slackware user thinks or perceives that software is bloated, then you might as well release the hounds. They never will use Trinity if the general belief among Slackware users is Trinity is bloated. Worse, they will spread their belief loudly. I have been a part of that community for several years. As I mentioned previously, I have fought that anal outlook just as long. Yet I also know I am unlikely to win the battle. The majority of Slackware users will not tolerate anything resembling bloat.

These are people who don't use GUI package managers. Your Kubuntu and Debian followers likely have no idea of what transpires and gets installed when they run Synaptic. Nor do they care. Slackers know. They do care. Period. If they consider additional packages to be bloat because those packages previously were not needed in KDE 3.5.x, then you've lost that potential target audience. Slackers can be a mean brutal bunch. Many times I have considered leaving to find a different distro, but nothing provides me the flexibility that Slackware provides.

Now for some philosophy. :)

I'm still mad at the KDE developers. They have no idea about focusing on users. They focus only on themselves. Their definition of users are fellow geeks. Bling, bling, bling. Screw the basic everyday user.

I think Trinity can fill that void. The everyday user doesn't care about bling, enterprise features, or online apps. The everyday user never uses any of that and likely never will. Most everyday users just want the basics.

I have been in technical and engineering fields all of my adult life (30+ years). Simple approach: function before form. The KDE developers have forgotten that simple engineering adage.

Another thing the KDE developers have forsaken are users of older hardware. Once upon a time there was a belief that Linux based systems kept old hardware out of the landfills. Not so with KDE4, that's for sure.

I have five machines here networked, but I look at usage as a single user and not an enterprise user or geek.  I don't use online apps. I reject the idea of placing my data somewhere out there in the nether land called the cloud. I don't use korganizer. I use kalarm for same basic reminders. I don't use kaddressbook. I'm content with the simple list kmail creates. I don't use kopete or any other instant messenger. Shoot, I refuse to enable the answering machine devices on my phones. :)

Simply put, I like my life simple. Most people do. Computers are supposed to help us, not hinder us. Bling and bloat introduces the latter, not the former.

Thus, I don't like having various features built into software that I am unlikely to use. I accept that other people find them useful. Yet every little bit added, even if the result is just a hook or stub, means longer startup times, additional RAM usage, etc. Many developers these days never notice or care because they all use modern hardware. My main system is a dual core box, but I have some old machines here. They run KDE 3.5.10. They never will be able to run KDE4.

My concern is that Trinity might grow to the point that those old machines no longer can run KDE 3.5.x comfortably. I want to see Trinity become a viable desktop alternative for old hardware and users who do not buy into the KDE developer's rah-rah.

I think Trinity can fill that void of people using old hardware. Yet every little hook and stub consumes resources. Almost every piece of software nowadays utterly shuns the user of old hardware. My point is why should people still run Windows 95 or 98 because they want to keep using old hardware? Running Windows for Workgroups 3.11 on my old 486 with 16 MB of RAM is in many ways snappier than KDE 3.5.10 on my Pentium I and II machines. That is sad.

Xfce is nowhere near as configurable as KDE 3.5.x. LXDE is an immature and unstable product (but getting better). Most everyday users want a desktop environment, not a window manager. They want point-and-click configuration, not to open terminal windows and text editors. I don't think either of those desktops will ever provide the configurability of KDE 3.5.x. The primary target for those desktops are the technically inclined, not the everyday user.

My reason for the option to deactivate carddav/caldav support is the folks running old hardware. I'm only seeking the option to disable, not a requirement. Every little bit of overhead makes a difference on old hardware. Those old machines don't have gigabytes of RAM, they have 256 MB. Distro maintainers would likely keep those hooks enabled as the default. Folks like me who want to build for older hardware can have the option to disable that overhead.

The overhead of supporting DAV might be immeasurable in both RAM and performance hit. Fair enough and likely true for modern hardware. Is the same true for old hardware? I don't know and won't speculate.

With that said, I think all developers should have one old box to test their software. Old hardware provides a new perspective on efficiency and speed.

Should package builders have the option to disable many of these resources? Yes, they should have the option. Possibly Trinity can be delivered in two flavors. One is with all hooks enabled. The other with most disabled. Users of older hardware and those who don't need bling can download the latter set of packages. Just a thought.

I hope I haven't overstayed my welcome!