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

List:       kde-pim
Subject:    Re: [Kde-pim] KAddressBook GUI design issues
From:       Anders Lund <temp_and () tiscali ! dk>
Date:       2002-10-01 22:55:10
[Download RAW message or body]

On Tirsdag den 1. oktober 2002 23:43, Tobias Koenig wrote:
> On Tue, Oct 01, 2002 at 01:28:16AM +0200, Cornelius Schumacher wrote:
> > On Monday 30 September 2002 21:59, Anders Lund wrote:
>
> Hi,
>
> > > * Nested tab widgets is downright bad GUI design. (Go here if you
> > > forgot why: http://www.iarchitect.com/mshame.htm) If the quickedit
> > > and the dist list manager should be displayed within the same widget,
> > > we should come up with an alternative control - possibly the tab bar
> > > used for Kate tool views could be used, placed in the bottom of the
> > > window (the same control is used in the konqueror navigation bar - so
> > > it probably will become familliar to users).
> >
> > The nested tabs as they are now are horrible. We can't release
> > KAddressBook before fixing this problem.
>
> Hmm, isn't it a bit late to come up with this?
>
> > Several additional
> > alternatives come to my mind:
> > - Use bottom tabs for the feature bar tab, that gives a slightly better
> > impression, but doesn't change very much.
> > - Provide menu items for enabling the distribution list editor and the
> > quick edit independently. This could also mean that we could have both
> > at once, but they could also be mutually exclusive. We could also add
> > tollbar buttons for the menu action to provide quicker access to these
> > options.
>
> Ok, where is the patch :)

If we can agree on how we should do, I'd gladly try to find time to help asap.

> > - Another alternative could be dock widgets, although I tend to not like
> > them, because they have the potential to make a GUI really confusing.
> >
> > > * I miss the option to display the dist list manager in the form of a
> > > dialog, as I dislike it embedded in the window in the current form by
> > > taste. As for the addressee editor, a dialog form should have
> > > keyboard accellerators while an embedded view none.
> >
> > We really should provide the distributon list editor also as dialog.
>
> I've removed it before one week and nobody objected!
> Could we at last come to a conclusion now??

> > Conclusion: the embedded version and the dialog version should be based
> > on the same code.
>
> It's a bit late for implementing it before the release since it has to be
> tested. Should the dialog have the same API like the one in the feature
> bar? Should the code moved to libkabc again?

I'm sorry that I have been abscent [right word?] from the discussion, I 
definately would have objected. Maybe we shouldn't rush, but consider if we 
should have general tools for tools that could be dialogs as well as embedded 
tool views?

As we want to promote KABC and the standard addressbook, any 
tools/widgets/dialogs that would possibly be usefull for other clients should 
go in libkabc, in my humble opinion (including for example the field 
selection widget).

> > > (I'm not sure if a [k]html view wouldn't do a much better job, using
> > > a such would also enable really flexible templates for advanced
> > > users. It has scrollbars/geometry management and supoorts
> > > selecting/copying)
> >
> > KHTML might be a bit heavy, but a QTextView could also be very useful to
> > provide rich-text formatting.
>
> Well, QTextBrowser would provide the linkClicked() signal that can be used
> for opening the email client or web browser.
> I'd like using QTextBrowser. Together with a cool CSS that would rock.

Problem: QTextEdit so far didn't learn CSS... Considering the improvements 
going on in khtml, maybe it would still be worth a try? or we'd have to live 
with the subset of HTML that qt supports, wouldn't kill me even if it would 
feel less fun;-)

-anders
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]