| |||||||||||||
|
| |||||||||||||
KDE struggles with feature requestsKDE struggles with feature requestsPosted Aug 13, 2009 6:18 UTC (Thu) by amit (subscriber, #1274)In reply to: KDE struggles with feature requests by BlueLightning Parent article: KDE struggles with feature requests
My comment was mostly neutral as to just desktop environments as against KDE in particular.
However, there are a lot of bugs/wishes I've filed in the KDE bugzilla requesting for some sanity in some of the apps.
As an example, kmail loses imap email; it loses mail on /tmp full, etc. The latter bug report has been open for maybe 5 yrs now.
(Log in to post comments)
KDE struggles with feature requests Posted Aug 13, 2009 7:22 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
I also gave up on kmail at the time (pre-4.0) when I still used KDE. But you didn't give any examples of where you thought more reuse in DEs would be appropriate, and I would be genuinely interested in hearing your thoughts on the subject.
KDE struggles with feature requests Posted Aug 13, 2009 9:09 UTC (Thu) by amit (subscriber, #1274) [Link]
OK, so some KDE-specific examples:
- kmail could configure fetchmail and present a GUI around downloaded mail. fetchmail is proven, secure, etc. I don't want to rely on desktop people to implement RFCs word-by-word.
- Extend PulseAudio to make it work across platforms and actively get involved in its development instead of Phonon (cross-platform and a stable API were the arguments why Phonon was developed).
- Open up the graphics acceleration layer as a library or use compiz instead of keeping it inside KWin
KDE struggles with feature requests Posted Aug 13, 2009 11:16 UTC (Thu) by quintesse (subscriber, #14569) [Link]
I can't comment about KMail but the other 2 points have been beaten to
death and the developers have explained a thousand times the WHYs of their decisions. Very very short:
- Phonon - it's just a layer! The KDE devs have neither the experience nor
- KWin & Compiz - The Compiz 3D effect are nice but it's not a Window
Don't just think that because you don't like/know/understand the reasoning
KDE struggles with feature requests Posted Aug 18, 2009 19:35 UTC (Tue) by maco (guest, #53641) [Link]
Er...Compiz is indeed a window manager. Maybe you're thinking of xcompmgr?
KDE struggles with feature requests Posted Aug 14, 2009 16:13 UTC (Fri) by mightyduck (guest, #23760) [Link]
> - kmail could configure fetchmail and present a GUI around downloaded
mail. fetchmail is proven, secure, etc. I don't want to rely on desktop people to implement RFCs word-by-word.
This is h*rseshit. I for instance explicitly DON'T want to download my
KDE struggles with feature requests Posted Aug 15, 2009 9:36 UTC (Sat) by BlueLightning (subscriber, #38978) [Link]
Indeed. If you want to know a bit more about why KMail currently is the way it is and what's
happening next, check out Thomas Maguire's talk from GCDS:
http://www.geeksoc.org/gcds/Thomas%20McGuire,%20KMail%202...
KDE struggles with feature requests Posted Aug 20, 2009 16:41 UTC (Thu) by astrophoenix (guest, #13528) [Link]
fetchmail has an option to leave the mail on the server...
KDE struggles with feature requests Posted Aug 20, 2009 17:15 UTC (Thu) by mightyduck (guest, #23760) [Link]
Sure, it can leave a copy on the server. But it still downloads
everything. The point of IMAP is to download only the pieces you really want to read. That is first the header information and then the message text for the messages you want to read and download multi-MB attachments only if you want to save them locally. Also, how do you maintain message flags on the server with fetchmail? For instance, I want to know which messages I already replied to or forwarded, even if I connect from a different location (from my cellphone for instance).
So, for me good IMAP support in KMail is essential and wrapper around
fetchmail as Kmail back-end Posted Aug 15, 2009 23:38 UTC (Sat) by rfunk (subscriber, #4054) [Link]
As someone who's been somewhat involved (at various levels) in the
development of fetchmail over the years, I can say with some authority that using fetchmail as a Kmail back-end would be a Bad Thing.
For one thing, at this point fetchmail is basically developed by one guy
For another thing, fetchmail was never designed to be the sort of back-end
Oh yeah, and one of the reasons that I'm not so involved with fetchmail
KDE struggles with feature requests Posted Aug 17, 2009 13:36 UTC (Mon) by bfeeney (subscriber, #6855) [Link] kmail could configure fetchmail and present a GUI around downloaded mail. fetchmail is proven, secure, etc. I don't want to rely on desktop people to implement RFCs word-by-word. KMail is due to use Akonadi, a backend explicitly designed to support multiple DE clients (as opposed to fetchmail, which lacks the integration DEs need). Evolution or Gnome clients could equally use this backend if they chose. Qt is no longer an issue having being broken up into small libraries each licensed under the LGPL. Extend PulseAudio to make it work across platforms and actively get involved in its development instead of Phonon (cross-platform and a stable API were the arguments why Phonon was developed). This is exactly what the KDE 2.0 devs did. They took the best audio-server available at the time (arts), and built the DE around it. When arts failed to live up to expectations, they were stuck, and a load of hacks ensued as app writers were forced to create their own code to talk to various backends such as Xine or GStreamer. Phonon is simply a thin layer over all audio servers. This means KDE and distributors can choose whichever audio-server they feel is best. Further, this facilitates the behaviour you sought in your fetchmail example above: the devs use an existing audio-server, instead of writing one themselves. Open up the graphics acceleration layer as a library or use compiz instead of keeping it inside KWin Numerous worries have been raised in the past about Compiz's stability and future (see http://lwn.net/Articles/313710/). Developers felt it would be safer to do compositing themselves. I've used both Compiz and KWin, and thus far I prefer KWin (though I've little interest in effects other than exposé and desktop cube). KWin can be used with Gnome as far as I know. As regards a graphics acceleration layer library: that's existed for 3-4 years now. It's a part of Qt called Arthur, and is comparable to Clutter. I should point out, this is fourth comment of this kind I've posted on lwn.net, so I can empathise with Aaron's frustrations, but I think his behaviour is pretty poor: he's a bit old to be throwing tantrums. Better to simply create a FAQ and refer users to it.
KDE struggles with feature requests Posted Aug 17, 2009 14:10 UTC (Mon) by amit (subscriber, #1274) [Link]
OK, a lot of folks pointed out why my examples were bad ones.
Even then, I'd imagine:
As for phonon and kwin, the KDE community could have stepped up and taken up a greater role and say in some upstream communities rather than just saying "it might break" or "we don't want the maintenance overhead".
I'd again like to emphasize that my comments were not originally about KDE in particular but about DEs in general.
KDE struggles with feature requests Posted Aug 18, 2009 10:49 UTC (Tue) by johnflux (subscriber, #58833) [Link]
Even then, I'd imagine:
- there would be an imap library which can be shared across projects
Heh, as the poster just above you said, KMail is currently switching to using an imap library that can be shared across projects - Akonadi.
- my example was about the dimap support; I failed to mention that.
Next version will support Akonadi.
KDE struggles with feature requests Posted Aug 18, 2009 10:52 UTC (Tue) by amit (subscriber, #1274) [Link]
Akonadi is the storage backend, not an imap library.
KDE struggles with feature requests Posted Aug 24, 2009 14:01 UTC (Mon) by krake (subscriber, #55996) [Link]
Akonadi is not a storage backend.
IMAP servers, maildir folder or mbox file are possible storage backends for mail in Akonadi.
KDE struggles with feature requests Posted Aug 13, 2009 8:57 UTC (Thu) by jospoortvliet (subscriber, #33164) [Link]
You are right in that often new apps are developed while there already are
applications for that purpose.
But if you think about how FOSS works, it's almost inevitable. Often the
I'm not saying it's a good thing but as I said I think it is inevitable.
|
|
||||||||||||