On Fri, 27 Apr 2012 11:05:12 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
I mean if we started using kwin, we would definitely have influence upon it because we would be the users. Reporting bugs requesting features. I am not sure what else you mean by "influence". KWin4 does everything TWin does.
One of the points of contention with this and other related topics is how much influence do KDE4 users have? Please notice I did not write users have no influence. Nor did I write developers don't listen or respond to users. I only asked rhetorically how much influence.
Consider that nepomuk/akonadi/strigi remain non negotiables, despite users requesting this from Day One. The argument that these services can be disabled is not the same as not installing them in the first place. When other apps depend upon the libraries of those three packages then disabling the services accomplishes little. The overhead remains. The dependencies remain.
[disclaimer: I'm not a KDE4 developer and I don't receive any dividend on the success of either KDE or TDE] Writing a program in C++ has some overhead, compared to writing it directly in asm or in C (for example, the brain-dead name mangling in the GNU v3 ABI, which brings an overhead for the dynamic linker). Removing your C++ compiler will accomplish little in building a lighter TDE. The overhead remains. The dependency on a C++ compiler remains.
Considering that, do you see people requesting TDE or KDE being rewritten in C or x86 asm ? I think with Akonadi this is the same. Akonadi uses an industrial-strength DB engine, which is (in the case of MySQL at least) geared for servers with GBs of RAM. On the performance side, it takes ~150M of RAM on a x86_64 system where KMail handles ~14K mails weighing ~800M and where there is ~1,5G more free RAM; IMHO it is satisfactory. (and for nepomuk and strigi, they are not really mandatory AFAIK)
Many non enterprise users have no need or interest in social networking, regardless of the potential merits. The entire nepomuk/akonadi/strigi philosophy never has been optional within KDE4. Few people have argued that those features be ripped from KDE4. They argued that they should be optional. Truly optional. People who run a half dozen KAlarm events and check email twice a day don't need or want a caching engine running in the background. They don't care about sharing desktops or activities with other people. They don't care or need massive meta data indexing.
Sharing desktops and activities _are_ optional in KDE4, since I don't use it. And the data indexing won't be massive if there isn't much data to index.
Yet building KDE4 without those three modules is not possible. Much like using Windows without IE is impossible. Where is the true choice and influence (other than using a different desktop environment)?
Using KDE without Qt is impossible. Where is the true choice and influence ?
If I could use KDE PIM apps without akonadi then likely I would be using KDE4 part time. Not to mention that I still read reports that KMail remains broken to one degree or another --- four years later.
IIRC the old KMail in KDE 4.4 didn't require Akonadi. Since KDE is backwards compatible between major version numbers you should be able to use it even on KDE 4.8/4.9.
How much influence would Trinity users have with kwin4 development? I don't know. I have read too many KDE bug reports that were closed as Won't Fix.
Those are some of my thoughts about influence.
A significant point about this kwin4 discussion is if kwin4 integration is doable then let the hacking begin. Put up or shut up (not you Calvin but anybody who wants this integration should put up or shut up, including those proposing the idea). We Trinity folks don't go pimping in the KDE4 forums. If we tried that we would be banned in less than 24 hours. Why do certain individuals think that pimping KDE4 products here in the Trinity lists is any more acceptable?
Certain people need to stop acting like a telemarketer. Annoying. Leave us alone. The proposal has been made. The door to integration is open. Let the hacking begin.
Let's keep it friendly and to the point.
Indeed. Be friendly. Be open. Stay focused. Block email addresses.
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting