[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Collection of missing features in QFiledialog
From:       Reginald Stadlbauer <reggie () troll ! no>
Date:       1999-11-05 19:06:26
[Download RAW message or body]

On Fri, 05 Nov 1999, Christian Esken wrote:
I hit sent too early in the last reply, so the next trial:


>Hi,
>
>as probably heared on KDE Two, I am a strong supporter of KFileDialog.
>Yesterdays discussion (which I have read today) made me think about it.
>I compiled a
>
>                   LIST OF MISSING FEATURES IN QFILEDIALOG
>
>Quickly thinking about it I found 8 points. I am sure, I will find more.
>
>Am Don, 04 Nov 1999 schrieb weis:
>> Hi,
>> 
>> I know that some people have strong feelings about this issue
>> but nevertheless I want to bring it up again.
>> 
>> I got all kinds of problems with the KFileDialog
>
>Several of your bug reports are not valid (especially the "it is
>too big" issue): You really should know that it saves its preferred
>size.
>
>And QFileDialog is not bug-free as well (see below).
>
>> So I want to suggest the following:
>> 
>> 1) libkfile stays where it as for compatibility and for someone who
>>    wants to fix it somewhen
>> 2) I derive KFileDialog from QFileDialog and put that in libkdeui.
>>    Currently KFileDialog has no extended functionality compared to
>>    QFileDialog.
>
>Wrong:
>- It allows switching off that stupid mixing of direcories and files.
>- It has single click
>- It has bookmarks
>- It has navigation buttons (prev, up, right, home)
>- It shows "forbidden" folders and files via icon
>- It has the dropdown list for quickly navigating to the parent directories

All this has been answered yesterday.

>- It saves its preferred state in a KDE compliant configuration file:
> Especially the layout and size of the file selector is saved. Every

If we would have use QFileDIalog KDE would have save the size.

> QFileSelector I saw opens with a ridiculous small window size.
>- And (the best of all): It lacks the ugly window-ish look-and-feel

Thatīs personal taste => void argument.

>
>Oh, and I just tested the Qt fileselector (tested with the "application" demo).
>Apparently this is not stable, too:
>
>a) It fails to remove directories.
>b) It does not support ftp (though it was rumoured it does).
>   BTW: Will it be possible to support any protocol we do (especially ftp, smb)

Answered in the last mail.

>c) The keyboard handling is broken: On the "Delete directory"
>   popup, I  cannot use the "Y" and "N" keys.

Try pressing ALT at the same time :-))

>Point c) leads me to i18n: Can this be done with the Qt fileselector?

Seems you didnīt do a lot with Qt 2 yet - ever heared of tr?

>IMO we will end up with deriving from QFileselector and winning nothing
>because every method will have to be reimplemented.

Hehe, nice to hear that my code is such a shit that we would need to
reimplement everything I wrote :-)) Maybe you should start subclassing KWord
and reimplement everything - and KPresenter too (sorry, couldnīt resist :-))

>BTW: When you click on QFileSelector "ListView" button and then press
>the "cursor left" key on your keyboard, the filedisplay shrinks to half size
>and a panner appears.
>What is this behaviour good for? Some kind of "preview area" perhaps?

That was a bug which is already fixed.

>Oh, found another bug: When the Qt fileselector is in this state, you can
>press as often as you want on "Tab", but the focus never goes back to
>the "ListView" or "DetailView" buttons any more.

Works for me - seems you have a quite old Qt.

Ok, but all this isnīt interesting for KDE anymore anyway :-)

-- 
Reggie

[prev in list] [next in list] [prev in thread] [next in thread]