[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:       Thomas Zander <zander () microweb ! nl>
Date:       2003-09-19 20:11:01
[Download RAW message or body]

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?

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.

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


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

-- 
Thomas Zander
_______________________________________________
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]