kdereview period is over

[Fathi Boudra]

Hi,

The 2 weeks review period in kdereview is over.
Krusader can be moved to extragear.

KDE extragear contains subdirs:
base
graphics
libs
multimedia
network
office
pim
sdk
security
sysadmin
utils

Krusader is the first file manager in KDE extragear.
Which subdir is the most appropriate ?

cheers,

Fathi

[Dirk Eschler]

Hi Fathi,

probably "utils".

bye,
Dirk

--
Dirk Eschler <esc...@gmail.com>
http://www.krusader.org

[Karai Csaba]

Hi,

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:

[Karai Csaba]

Shortly:

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.

Csaba


Karai Csaba írta:

[Fathi Boudra]

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.

cheers,

Fathi

[Frank Schoolmeesters]

On Mon, Jun 15, 2009 at 6:00 PM, Dirk Eschler<esc...@gmail.com> wrote:
>
> 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.
>>
>> KDE extragear contains subdirs:
>> base
>> graphics
>> libs
>> multimedia
>> network
>> office
>> pim
>> sdk
>> security
>> sysadmin
>> utils
>>
>> Krusader is the first file manager in KDE extragear.
>> Which subdir is the most appropriate ?
>
> Hi Fathi,
>
> probably "utils".
>
> bye,
> Dirk
>

I agree.

bye,

Frank

[Csaba Karai]

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

[Fathi Boudra]

> 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.

I understa

[Fathi Boudra]

oups mail sent before finishing my reply ;)

>> 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.

[Fathi Boudra]

at the moment, it will go to utils.

I'll wait until this week end before the move.

[shie erlich]

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.

shie

[Fathi Boudra]

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.

[shie erlich]

yes! that was my point (although it took me few sentences to make it...)

[Richard/g]

shie erlich escribió:

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.