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

List:       kde-core-devel
Subject:    RE: questionYesNo (again)
From:       David Faure <David.Faure () cramersystems ! com>
Date:       1999-12-08 10:28:23
[Download RAW message or body]

I would suggest moving the stringlist version to libkonq.
As many pointed out, this has to be part of several applications
before it gets its way to kdeui.
As I also pointed out in a cvs log, even more file-related stuff
might be needed, like showing a mini-icon in front of each line,
so that you see whether they are files or directory.
If we add a public API listRecursive method to kiojob (coolo: feature
request !),
we could even make the list a tree, and really show the files that
are going to be deleted.
All this is too file-oriented to be in kdeui.

The new widget would get another name, so it would solve this minor
issue at the same time.

--
David Faure
faure@kde.org - KDE developer
david@mandrakesoft.com - Mandrake
david.faure@cramersystems.com - Cramer Systems



> -----Original Message-----
> From: antonio@max.tat.physik.uni-tuebingen.de
> [mailto:antonio@max.tat.physik.uni-tuebingen.de]On Behalf Of Antonio
> Larrosa
> Sent: Wednesday, December 08, 1999 12:01 AM
> To: kde-core-devel
> Subject: questionYesNo (again)
> 
> 
> Hi,
> 
> I don't know if it's me, my compiler, or whatever, but 
> there's something wrong.
> Currently, there are two questionYesNo methods:
> questionYesNo(QWidget *,  const QString &,
>                           const QString & = QString::null,
>                           const QString & = QString::null,
>                           const QString & = QString::null);
> 
> and the recently added one :
> 
> questionYesNo(QWidget *, const QString &,
>                           const QStringList &,
>                           const QString & = QString::null,
>                           const QString & = QString::null,
>                           const QString & = QString::null); 
> 
> I thought : "well, as that's a QStringList and the other 
> method needed a
> QString, there isn't any problem, I can add that and none of 
> the existing
> code will call this new method because it has no default value".
> 
> That's _wrong_ because one of the constructors of QStringList 
> accept a QString
> and so, when someone makes a call to  
> questionYesNo(mywidget, myqstring1, myqstring2, myqstring3, 
> myqstring4);
> the compiler calls the QStringList method !
> 
> There are three solutions :
>  1) Do what coolo said, and put the QStringList as last parameter.
>    Pro: keeps compatibility with "old" code
> 
>  2) Fix the CVS code that needs the last three parameters to 
> pass an empty list.
>    Pro: keeps the standard in the KMessageBox class, putting 
> the buttons' text
>        as the last parameters.
> 
>  3) Change its name to questionYesNoStrList or something like that
>    Con: The name is ugly
> 
>  4) Call the ANSI C++ committee to give priority to exact 
> type matching
>    methods over methods that could be called by using special 
> constructors
>    in the parameters :/
> 
> What would be the best solution ? 
> I'm really thinking about the third one, as it could be made 
> before KRASH
> and the "Con" is not that bad :-)
> (only konqueror and the KMessageBox test are ussing this 
> method for now)
> 
> Waldo: While I'm at it, can I remove the old method and 
> implement it just
> as a call to this one with an empty list as you proposed ? 
> (The look is
> exactly the same in this case)
> 
> Greetings,
> 
> --
> Antonio Larrosa Jimenez (angry with himself)
> Student of Mathematics
> antlarr@arrakis.es        larrosa@kde.org
> http://www.arrakis.es/~rlarrosa
> Klein bottles for rent -- inquire within.
> 
> 

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