faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: Reduction of features
by Peter Penz on Sunday 06/Jan/2008, @22:40
|
> For example, in file dialog there are no more owner, group and
> permissions columns or "folder first", "separate folders" and
> "case sensitive" options, WHY?
I ported the file-dialog from KDE 3 to KDE 4 and the reasons for having this features not available in KDE 4.0 are just because we've been running out of time. As Aaron explained already especially the file-view related parts in KDE 4 had to be rewritten nearly from scratch due to Interview from Qt4. We'll add such kind of missing features again in the 4.x releases :-) |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Reduction of features
by MamiyaOtaru on Monday 07/Jan/2008, @01:18
|
This is the point where I get frustrated with KDE's monolithic releases ;) I'd love to see such stuff come in without necessarily having to wait for 4.1 (and without having to run SVN). The monolithic thing just seems to slow things down sometimes. I wasn't happy at all when Kopete went into KDE, as that meant new features would only come out with KDE releases.
Obviously it works well (for all but the illogically impatient perhaps) so I'm not advocating change. I guess it's my way of saying I'm glad to hear changes are coming and I look forward to them!
|
[
Reply To This | View ]
|
Re: Reduction of features
by D Kite on Monday 07/Jan/2008, @07:46
|
Set yourself up a build environment where you can use the latest from svn code. Set yourself up a proper and robust backup method for your data.
Then run the latest and greatest. During the kde 3 development cycle I found it very satisfying to experience the maturation as it happened. And I found it surprisingly stable.
Some inside baseball: don't update during the two weeks preceeding a code freeze. It will break.
Derek
|
[
Reply To This | View ]
|
Re: Reduction of features
by anonymous coward on Monday 07/Jan/2008, @12:05
|
This approach usually does not work. If your preferred app resides in a KDE mayor package, you can't cherry-pick it but have to pull the hole package, which maybe only builds against the unstable trunk kdelibs, but not against any stable version. That means that you have only two reasonable options:
(1) Live on the bleeding edge and use the trunk for all your KDE apps.
(2) Wait until the next release.
A more modular approach (i.e. git repositories for each app) would allow an app to proceed at its own pace and state its own preconditions.
|
[
Reply To This | View ]
|
Re: Reduction of features
by Morty on Monday 07/Jan/2008, @13:45
|
This approach does usually work, even if you have to get the whole major package you don't have to compile more than the application you want. Much the same way distributions split it in to individual packages for each application. The KDE packages are very modular.
As stated the only problem you can have are when the application require functionality not present in the current stable kdelibs, but the ability to only pick the application you want makes this less likely. In the past this has even been done officially by application maintainers, for instance Kopete has been released both as part of the kde and as separate releases.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
