[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 13:51:18
[Download RAW message or body]

On Tirsdag den 1. oktober 2002 15:14, Mirko Boehm wrote:
<snip>

> Anders is right.

I'll put that in my .signature file :-\

> I do not know what GUI style and fonts you guys use, but I use either a 19
> or a 21 inch display and the quickedit most of the time does simply not
> display all its contents, nor does it use scrollbars (due to the layout
> management used).
>
> I posted a message some time ago stating that quickedit is basically not
> usable at 800x600 or below, even with a maximized kaddressbook. Or as a
> dialog.

So maybe a scrollbar solution would be nice anyways?

> >> * 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).
>
> I absolutely agree. The double tab bar is a result of the development
> process :-)

Thought so. Good that we are aware;)

> My intention was to modify it to be a details view. Tobias stated that he
> does not like the idea of detail view implementations that allow the user
> to modify the selected addressee, but I do like it. In fact, since most
> displays provide a larger width than height, this should solve the size
> problems, too, with a little layout work in quickedit.

I like editable views too, so there is a discussion to make. Anyway, even not 
editable, some views - detail is one of them - needs selection/copying 
features.

I'm not sure what you mean by "be a details view" - the details view is 
showing details about the current item in a list|card|icon view, and is 
currently displayed in a vertical frame, whereas the addressee editor and the 
dist list manager seems to work better as horizontal frames.

> > The nested tabs as they are now are horrible. We can't release
> > KAddressBook before fixing this problem. 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.
>
> Bottom tabs seem to be no solution to me, sorry. I consider it acceptable
> in situation where there is no other choice, but for me it is just as bad
> taste.

Again, open a recent Kate and activate the bottom dock view, it a tab bar 
right, but it has a very different look.

> >> * 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. The
> >  embedded version is really cool, because of the drag&drop feature, but
> > there is no reason why a dialog based version couldn't do the same and
> > the embedded version could also provide the controls for selecting an
> > addresse from a list.
>
> This is obviously a matter of taste, because if found the dialog based
> solution unusable. Since there are people who like a dialog and some who
> not, we can provide both options easily.
>
> > Conclusion: the embedded version and the dialog version should be based
> > on the same code.
>
> Agreed.
Yes.

> >> And some suggestions:
> >>
> >> * Since we allready has such tool views, maybe adding a "manage by
> >> categories" view would be good, pretty much like the dist list
> >> editor, so that you could create a category and drag contacts to it
> >> from the main view (Just agree, I'll volunteer to create it in time
> >> for 3.2 if you do).
> >
> > Agreed ;-)

Ok, I'll come up with a class that can handle the work and be used as a 
embedded tool view as well as a dialog. That is if noone allready did it? 
I'll give you a few days to alert me if so:)

> This is in fact intended use and has only been delayed for 3.1.
>
> >> Some notes about the details pane:
> >>
> >> * It is not working well GUI-wise when displayed in a vertical pane,
> >> because it does not have an understanding of the width it requires. It
> >> should consider the required width and either provide scrollbars or
> >> claim the space it needs, preferably the first since the width will
> >> depend on the amount and length of the data in individual
> >> contacts.
> >
> > It doesn't seem to provide a minimum width. That's a bug.
>
> Remembering the reason ... it is because there is no generic minumim
> width. It is either undefined or wrong :-) The solution could be to just
> set some kind of minimum width and use scrollbars.

It needs to calculate the required space during it's paint() or loadAddresse() 
[whatever it is called] method. <hint>There is a QPainter::drawText() variant 
that takes a rect which contains the measures of the used space when the 
function returns.</hint>

<snip>

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

/me loves CSS based design :-))

> I tried KHTML, and it did not feel well. When you switched through entries
>  fast it was not able render anything. QTextView would be nice. On the
> other hand, it is rather limited, too. But we can have a QTextVeiw based
> details style to be chosen by the user.
>
> This is the advantage of having different styles that can be developed by
> different people - we can provide solutions for different taste.

Ok, that just leaves you with a lot of work with that widget...

-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]