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

List:       koffice-devel
Subject:    Re: [PATCH] Custom formats in date/time dialogs
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2003-09-20 1:32:10
[Download RAW message or body]

On Friday 19 September 2003 22:11, Thomas Zander wrote:
> On Fri, Sep 19, 2003 at 08:43:45PM +0200, Nicolas Goutte wrote:
> > On Friday 19 September 2003 09:45, Thomas Zander wrote:
> > > On Thursday 18 September 2003 23:24, Nicolas Goutte wrote:
> > > > The attached patch is for koffice/lib/kotext.
> > > >
> > > > It allows again to make custom format in the date or time dialogs.
> > > > (Problem was that combobox was used as a list and not as an editable
> > > > combobox.)
> > >
> > > Don't use an editable combobox here.  They are not usable for this
> > > purpose. Since you are working on this dialog; would you like me to
> > > make a UI file for the dialog, since many other small things are not
> > > quite nice.
> >
> > Well, I do not want to make a UI that we will need to drop in KoText 1.4.
> > (Why are fixed and variable date variable inserted with a dialog? But
> > creation, modification and print date are not (and therefore have not any
> > custom formats.))
> >
> > And if you would want not to use the editable combo box, what do you
> > propose instead?
>
> Ehh;
> You don't want a ui file since that would be too much work.
> And you want me to propose a new UI?
>
> I wanted to do a proposal in designer (since that would take me a maximum
> of 10 minutes) so I gather you have no experience with implementing them?
> Or what is exactly the problem with using a .ui file?

As written in the other email, the date and time dialogs are documented with 
pictures. So we cannot change them for KOffice 1.3.

>
> I would propose to have a second text line; but that was in the initial
> design I made with laurant, so I'm confused it has been lost in the first
> place.

As for your previous proposal, well, perhaps Laurent had not time to finish to 
code. It would explain the unfinished feeling that I have when looking at the 
code.

>
> Anyway; do you want me to make a .ui file, or not?

Otherwise, I would have been glad to have an UI file.

>
> > > This line: (end of QString DateFormatWidget::resultString())
> > > +    return "yyyy-MM-dd"; // Something is wrong, give back a default
> > > seems wrong; you want to get the locale default and return that; don't
> > > hardcode locale dependent variables.
> >
> > This should never appear!
>
> That is irrelevant.
> You return it; and if you do the you either make it really clear its a bug,
> as it is with 'null'.
> Or you show a good default.  A hardcoded default is neither.
> So please fetch the locale from the system and return that; or return a
> null again.
>
> > But a user will probably more bug us when he sees
> > yyy-MM-dd than if he sees a QStrfing::null. (Because he will oversee the
> > QString::null as non-implemented, which is not the case here. If it shows
> > there is a bug somwhere!)
>
> You said it will never appear; so if it does its a bug, right?  What is
> wrong with showing the user a value to allows him to conclude it indeed is
> a bug? Your alternative is to show him something he did not expect; he will
> blame it on himself and never file a bug report. (and will find the
> application harder to use at the same time).

I think I see your point. You prefer something that breaks completely. 
(returning locale would then be wrong too, as the user would think that he 
has made the error.) So as we have no i18n("Error") available that means back 
to QString::null.

Have a nice day!
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel

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