In the last commit, most of the includes were changed to use the KDE version instead of QT. QLineEdit->KLineEdit
I strongly disagree with this commit, and it would be better to revert it. The KDE libraries are very very instable and I'm afraid, that this change corrupted the quality of the code.
I also don't want to write a new Krusader for every KDE release, and don't have time to browse KDE's code why a functionality is broken. I avoided using KDE's libraries because of their poor quality.
I personally remember many cases when I fixed the code by dropping KDE's libraries. I guess noone checked whether Krusader works well now, just the code was automatically replaced to use KDE's junk.
QLineEdit->KLineEdit adds an extra unnecessary risk to the code.
Till now Krusader failed only if QLineEdit was buggy. After this change
Krusader will fail either QLineEdit or KLineEdit is buggy, without
adding any benefit to the code.
The best is to depend as little as we can on KDE and use Qt instead.
> In the last commit, most of the includes were changed to use the KDE
> version instead of QT. QLineEdit->KLineEdit
> I strongly disagree with this commit, and it would be better to revert
> it. The KDE libraries are very very instable and I'm afraid, that this
> change corrupted the quality of the code.
> I also don't want to write a new Krusader for every KDE release, and
> don't have time to browse KDE's code why a functionality is broken. I
> avoided using KDE's libraries because of their poor quality.
> I personally remember many cases when I fixed the code by dropping KDE's
> libraries. I guess noone checked whether Krusader works well now, just
> the code was automatically replaced to use KDE's junk.
> Thanks,
> Csaba
> Dirk Eschler írta:
>> Am Montag 15 Juni 2009 17:31:45 schrieb Fathi Boudra:
>>> Hi,
>>> The 2 weeks review period in kdereview is over.
>>> Krusader can be moved to extragear.
> In the last commit, most of the includes were changed to use the KDE > version instead of QT. QLineEdit->KLineEdit
Yes, it's recommended to use K classes instead of Q classes for a KDE application.
Why ? Don't use Qt 4 classes that are deprecated. Additionally make sure to use the KDE version of some Qt GUI elements to provide a consistent look and feel for the KDE desktop. The KDE classes are not just adding functionalities to the Qt base class and are mostly not even based on the Qt class.
> I strongly disagree with this commit, and it would be better to revert > it. The KDE libraries are very very instable and I'm afraid, that this > change corrupted the quality of the code.
kdelibs instable ? current version is 4.2.4 and 4.3.0 will come soon. there's some API changes but ABI is kept. You could say plasma is very instable but not kdelibs, imho. Otherwise, points some real examples.
> I also don't want to write a new Krusader for every KDE release, and > don't have time to browse KDE's code why a functionality is broken. I > avoided using KDE's libraries because of their poor quality.
And you don't need to write another Krusader for every KDE release. Krusader contains many embedded copy of kdelibs source code. Fortunately, kdelibs is fixed. Wrt, Krusader isn't always fixed.
Only base component are used, not all the Q classes have a good replacement.
> I personally remember many cases when I fixed the code by dropping KDE's > libraries.
yes, kdelibs contains bugs like Qt, and most (all?) softwares. I'll suggest to reports the bug and fixed it in the right place.
> I guess noone checked whether Krusader works well now, just > the code was automatically replaced to use KDE's junk.
No, I checked it.
>QLineEdit->KLineEdit adds an extra unnecessary risk to the code.
I don't think that's a risk as I checked it and don't do blind changes.
>Till now Krusader failed only if QLineEdit was buggy. After this change >Krusader will fail either QLineEdit or KLineEdit is buggy, without >adding any benefit to the code.
false, you missed all the dependency chain: libc -> qt -> kdelibs -> krusader
for the benefit: consistent look and feel
>The best is to depend as little as we can on KDE and use Qt instead.
I disagree.
I think it's a strong alarm for such a small changes. There's many places in Krusader where the code is really ugly and deserves real fixes. Q to K classes isn't part of them, especially Qlinedit to Klineedit.
OK, I'm very tolerant. I've tried the new Krusader and it worked well.
Every KDE UI class will have a chance to remain, but after the first
bug, I'll kick them.
As for the UI: Krusader doesn't follow KDE's UI convention.
- Krusader widgets have focus rectangle, while KDE hasn't (I wrote a
style proxy to make the focus rectangle visible)
- Krusader has a separate color chooser
- Krusader's selection handling is totally different from KDE's
- The single click / double click / rename is also different in
Krusader
- the panel's keyboard / mouse handlers are independent of KDE/QT. If
you check the code, the original function is rarely called.
That's why I didn't understand why this change was important...
When I saw your changes, I was frightened, as Krusader overrides many
virtual methods without calling the original one, and I guessed that
it can cause problem to KDE UI classes.
One thing which is important: please don't change the panels to use
KTreeWidget. As most of their methods are overwritten, and
eventFilters are defined on them, I don't think it would ever work.
As for KDE's stability: there was a bug in KDE 4.2.2 in the Yes/No/
Cancel dialog (!), and when the user pressed enter on "Cancel", then
Krusader deleted the file. I don't know how KDE released 4.2.2 without
any testing.
:-)
Thanks,
Csaba
On Jun 16, 8:25 am, Fathi Boudra <fbou...@gmail.com> wrote:
> > In the last commit, most of the includes were changed to use the KDE
> > version instead of QT. QLineEdit->KLineEdit
> Yes, it's recommended to use K classes instead of Q classes for a KDE
> application.
> Why ? Don't use Qt 4 classes that are deprecated. Additionally make sure to
> use the KDE version of some Qt GUI elements to provide a consistent look and
> feel for the KDE desktop. The KDE classes are not just adding functionalities
> to the Qt base class and are mostly not even based on the Qt class.
> > I strongly disagree with this commit, and it would be better to revert
> > it. The KDE libraries are very very instable and I'm afraid, that this
> > change corrupted the quality of the code.
> kdelibs instable ? current version is 4.2.4 and 4.3.0 will come soon.
> there's some API changes but ABI is kept.
> You could say plasma is very instable but not kdelibs, imho.
> Otherwise, points some real examples.
> > I also don't want to write a new Krusader for every KDE release, and
> > don't have time to browse KDE's code why a functionality is broken. I
> > avoided using KDE's libraries because of their poor quality.
> And you don't need to write another Krusader for every KDE release.
> Krusader contains many embedded copy of kdelibs source code.
> Fortunately, kdelibs is fixed. Wrt, Krusader isn't always fixed.
> Only base component are used, not all the Q classes have a good replacement.
> > I personally remember many cases when I fixed the code by dropping KDE's
> > libraries.
> yes, kdelibs contains bugs like Qt, and most (all?) softwares.
> I'll suggest to reports the bug and fixed it in the right place.
> > I guess noone checked whether Krusader works well now, just
> > the code was automatically replaced to use KDE's junk.
> No, I checked it.
> >QLineEdit->KLineEdit adds an extra unnecessary risk to the code.
> I don't think that's a risk as I checked it and don't do blind changes.
> >Till now Krusader failed only if QLineEdit was buggy. After this change
> >Krusader will fail either QLineEdit or KLineEdit is buggy, without
> >adding any benefit to the code.
> false, you missed all the dependency chain:
> libc -> qt -> kdelibs -> krusader
> for the benefit: consistent look and feel
> >The best is to depend as little as we can on KDE and use Qt instead.
> I disagree.
> I think it's a strong alarm for such a small changes.
> There's many places in Krusader where the code is really ugly and deserves
> real fixes. Q to K classes isn't part of them, especially Qlinedit to
> Klineedit.
> OK, I'm very tolerant. I've tried the new Krusader and it worked well.
> Every KDE UI class will have a chance to remain, but after the first
> bug, I'll kick them.
Thanks Csaba \o/
> As for the UI: Krusader doesn't follow KDE's UI convention.
> - Krusader widgets have focus rectangle, while KDE hasn't (I wrote a
> style proxy to make the focus rectangle visible)
> - Krusader has a separate color chooser
> - Krusader's selection handling is totally different from KDE's
> - The single click / double click / rename is also different in
> Krusader
> - the panel's keyboard / mouse handlers are independent of KDE/QT. If
> you check the code, the original function is rarely called.
> That's why I didn't understand why this change was important...
> When I saw your changes, I was frightened, as Krusader overrides many
> virtual methods without calling the original one, and I guessed that
> it can cause problem to KDE UI classes.
> One thing which is important: please don't change the panels to use
> KTreeWidget. As most of their methods are overwritten, and
> eventFilters are defined on them, I don't think it would ever work.
> As for KDE's stability: there was a bug in KDE 4.2.2 in the Yes/No/
> Cancel dialog (!), and when the user pressed enter on "Cancel", then
> Krusader deleted the file. I don't know how KDE released 4.2.2 without
> any testing.
> :-)
> Thanks,
> Csaba
> On Jun 16, 8:25 am, Fathi Boudra <fbou...@gmail.com> wrote:
>> Hi Csaba,
>> I have done the changes you mentionned.
>> > In the last commit, most of the includes were changed to use the KDE
>> > version instead of QT. QLineEdit->KLineEdit
>> Yes, it's recommended to use K classes instead of Q classes for a KDE
>> application.
>> Why ? Don't use Qt 4 classes that are deprecated. Additionally make sure to
>> use the KDE version of some Qt GUI elements to provide a consistent look and
>> feel for the KDE desktop. The KDE classes are not just adding functionalities
>> to the Qt base class and are mostly not even based on the Qt class.
>> > I strongly disagree with this commit, and it would be better to revert
>> > it. The KDE libraries are very very instable and I'm afraid, that this
>> > change corrupted the quality of the code.
>> kdelibs instable ? current version is 4.2.4 and 4.3.0 will come soon.
>> there's some API changes but ABI is kept.
>> You could say plasma is very instable but not kdelibs, imho.
>> Otherwise, points some real examples.
>> > I also don't want to write a new Krusader for every KDE release, and
>> > don't have time to browse KDE's code why a functionality is broken. I
>> > avoided using KDE's libraries because of their poor quality.
>> And you don't need to write another Krusader for every KDE release.
>> Krusader contains many embedded copy of kdelibs source code.
>> Fortunately, kdelibs is fixed. Wrt, Krusader isn't always fixed.
>> Only base component are used, not all the Q classes have a good replacement.
>> > I personally remember many cases when I fixed the code by dropping KDE's
>> > libraries.
>> yes, kdelibs contains bugs like Qt, and most (all?) softwares.
>> I'll suggest to reports the bug and fixed it in the right place.
>> > I guess noone checked whether Krusader works well now, just
>> > the code was automatically replaced to use KDE's junk.
>> No, I checked it.
>> >QLineEdit->KLineEdit adds an extra unnecessary risk to the code.
>> I don't think that's a risk as I checked it and don't do blind changes.
>> >Till now Krusader failed only if QLineEdit was buggy. After this change
>> >Krusader will fail either QLineEdit or KLineEdit is buggy, without
>> >adding any benefit to the code.
>> false, you missed all the dependency chain:
>> libc -> qt -> kdelibs -> krusader
>> for the benefit: consistent look and feel
>> >The best is to depend as little as we can on KDE and use Qt instead.
>> I disagree.
>> I think it's a strong alarm for such a small changes.
>> There's many places in Krusader where the code is really ugly and deserves
>> real fixes. Q to K classes isn't part of them, especially Qlinedit to
>> Klineedit.
>> When I saw your changes, I was frightened, as Krusader overrides many >> virtual methods without calling the original one, and I guessed that >> it can cause problem to KDE UI classes.
I understand your point of view and open to discuss it. I won't enforce my changes and your comments are really appreciated.
>> One thing which is important: please don't change the panels to use >> KTreeWidget. As most of their methods are overwritten, and >> eventFilters are defined on them, I don't think it would ever work.
sure.
>> As for KDE's stability: there was a bug in KDE 4.2.2 in the Yes/No/ >> Cancel dialog (!), and when the user pressed enter on "Cancel", then >> Krusader deleted the file. I don't know how KDE released 4.2.2 without >> any testing.
yes, very strange. I missed that bug. In general, there's a call for blocker bugs before the release (1-2 weeks). This kind of bug should be raised and block the release until it's fixed.
csaba,i'm afraid that these kind of things are a part of moving to kde.
during the last few years i mostly avoided the move as i was afraid of these
kind of things :-(
having said that, it's best to be tolerant at first, and try to explain why
things are as they are, so other won't garbage stuff.
On Tue, Jun 16, 2009 at 1:01 PM, Csaba Karai <cska...@freemail.hu> wrote:
> OK, I'm very tolerant. I've tried the new Krusader and it worked well.
> Every KDE UI class will have a chance to remain, but after the first
> bug, I'll kick them.
> As for the UI: Krusader doesn't follow KDE's UI convention.
> - Krusader widgets have focus rectangle, while KDE hasn't (I wrote a
> style proxy to make the focus rectangle visible)
> - Krusader has a separate color chooser
> - Krusader's selection handling is totally different from KDE's
> - The single click / double click / rename is also different in
> Krusader
> - the panel's keyboard / mouse handlers are independent of KDE/QT. If
> you check the code, the original function is rarely called.
> That's why I didn't understand why this change was important...
> When I saw your changes, I was frightened, as Krusader overrides many
> virtual methods without calling the original one, and I guessed that
> it can cause problem to KDE UI classes.
> One thing which is important: please don't change the panels to use
> KTreeWidget. As most of their methods are overwritten, and
> eventFilters are defined on them, I don't think it would ever work.
> As for KDE's stability: there was a bug in KDE 4.2.2 in the Yes/No/
> Cancel dialog (!), and when the user pressed enter on "Cancel", then
> Krusader deleted the file. I don't know how KDE released 4.2.2 without
> any testing.
> :-)
> Thanks,
> Csaba
> On Jun 16, 8:25 am, Fathi Boudra <fbou...@gmail.com> wrote:
> > Hi Csaba,
> > I have done the changes you mentionned.
> > > In the last commit, most of the includes were changed to use the KDE
> > > version instead of QT. QLineEdit->KLineEdit
> > Yes, it's recommended to use K classes instead of Q classes for a KDE
> > application.
> > Why ? Don't use Qt 4 classes that are deprecated. Additionally make sure
> to
> > use the KDE version of some Qt GUI elements to provide a consistent look
> and
> > feel for the KDE desktop. The KDE classes are not just adding
> functionalities
> > to the Qt base class and are mostly not even based on the Qt class.
> > > I strongly disagree with this commit, and it would be better to revert
> > > it. The KDE libraries are very very instable and I'm afraid, that this
> > > change corrupted the quality of the code.
> > kdelibs instable ? current version is 4.2.4 and 4.3.0 will come soon.
> > there's some API changes but ABI is kept.
> > You could say plasma is very instable but not kdelibs, imho.
> > Otherwise, points some real examples.
> > > I also don't want to write a new Krusader for every KDE release, and
> > > don't have time to browse KDE's code why a functionality is broken. I
> > > avoided using KDE's libraries because of their poor quality.
> > And you don't need to write another Krusader for every KDE release.
> > Krusader contains many embedded copy of kdelibs source code.
> > Fortunately, kdelibs is fixed. Wrt, Krusader isn't always fixed.
> > Only base component are used, not all the Q classes have a good
> replacement.
> > > I personally remember many cases when I fixed the code by dropping
> KDE's
> > > libraries.
> > yes, kdelibs contains bugs like Qt, and most (all?) softwares.
> > I'll suggest to reports the bug and fixed it in the right place.
> > > I guess noone checked whether Krusader works well now, just
> > > the code was automatically replaced to use KDE's junk.
> > No, I checked it.
> > >QLineEdit->KLineEdit adds an extra unnecessary risk to the code.
> > I don't think that's a risk as I checked it and don't do blind changes.
> > >Till now Krusader failed only if QLineEdit was buggy. After this change
> > >Krusader will fail either QLineEdit or KLineEdit is buggy, without
> > >adding any benefit to the code.
> > false, you missed all the dependency chain:
> > libc -> qt -> kdelibs -> krusader
> > for the benefit: consistent look and feel
> > >The best is to depend as little as we can on KDE and use Qt instead.
> > I disagree.
> > I think it's a strong alarm for such a small changes.
> > There's many places in Krusader where the code is really ugly and
> deserves
> > real fixes. Q to K classes isn't part of them, especially Qlinedit to
> > Klineedit.
On Saturday 20 June 2009 08:09:03 shie erlich wrote:
> csaba,i'm afraid that these kind of things are a part of moving to kde. > during the last few years i mostly avoided the move as i was afraid of > these kind of things :-( > having said that, it's best to be tolerant at first, and try to explain why > things are as they are, so other won't garbage stuff.
discussions never hurt. everybody can do mistakes.
On Sat, Jun 20, 2009 at 9:51 AM, Fathi Boudra <fbou...@gmail.com> wrote:
> On Saturday 20 June 2009 08:09:03 shie erlich wrote: > > csaba,i'm afraid that these kind of things are a part of moving to kde. > > during the last few years i mostly avoided the move as i was afraid of > > these kind of things :-( > > having said that, it's best to be tolerant at first, and try to explain > why > > things are as they are, so other won't garbage stuff.
> discussions never hurt. > everybody can do mistakes.
yes! that was my point (although it took me few sentences to make it...)
> On Sat, Jun 20, 2009 at 9:51 AM, Fathi Boudra <fbou...@gmail.com > <mailto:fbou...@gmail.com>> wrote:
> On Saturday 20 June 2009 08:09:03 shie erlich wrote: > > csaba,i'm afraid that these kind of things are a part of moving to > kde. > > during the last few years i mostly avoided the move as i was afraid of > > these kind of things :-( > > having said that, it's best to be tolerant at first, and try to > explain why > > things are as they are, so other won't garbage stuff.
> discussions never hurt. > everybody can do mistakes.
> yes! that was my point (although it took me few sentences to make it...)
I suggest that the quality of kdelibs, etcetera, will improve due to Krusader's entrance into KdeGear. Using their tools will reveal bugs and help to make them more reliable, resilient and useful. A PITA to Krusader programmers to have to use routines that are unstable. Such is Kde4.
Some code always breaks when you push the limits. Kde4 has some great ideas but it is a tremendous change from Kde3. I am thankful for those who are using the latest Kde4 everyday, since therein lies the future stability for the rest of us.
I have high hopes that 4.3x will approach the stability and utility of 3.5. Currently running openSuse11.1 w/Kde4.1.3 on my desktop but keep my failsafe sidux/testing partition held to Kde3.5.10, just in case.
|
