[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 14:02:03
[Download RAW message or body]

On Tirsdag den 1. oktober 2002 01:28, Cornelius Schumacher wrote:
> On Monday 30 September 2002 21:59, Anders Lund wrote:
> > First the QuickEdit + distribution list manager:
> >
<snip>
> > * It contains keyboard accellerators for controls, that may conflict
> > with those of the kaddressbook window's menus. I think all
> > accellerators should be removed to get a clean design, whereas the
> > addressee editor dialog is lacking accellerators, preferably every
> > single control in a dialog should provide a keyboard accellerator.
>
> All controls in a window should have accelarators. As this is almost
> impossible to achieve manually (especially if you consider
> translations), we should probably try to do this automatcially. There
> is KAcceleratorManager in libkdeui. This might be worth a try.

I agree in principle. The accellerators will be different in the embedded and 
dialog versions, but Ok, let's see if it works.

Maybe I should take a look at using that class for some of our menus, the 
"views" one for example...

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

<snip>

> > * 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, as said I'll come up with something.

> > Btw I often think that categories should be usable as dist lists
> > automatically, in which case the distribution list system could even
> > be dropped (unless someone cares for the option to select a different
> > email address for a specific purpose in a dist list...). Anyway
> > beeing able to send email to a category directly from kmail
> > forexample would be kinda cool, I do know that that could easily be
> > added in the kmail code, but having the adderssbook returning
> > categories as dist lists would be cleaner.
>
> Using categories to create some kind of implicit distribution lists
> sounds like a cool idea.
>
> I don't think that we could replace the distributiobn lists by
> categories. They are used in a different way. For categories you have
> the set of all your addressees and try to classify them by different
> categories. For distribution lists you don't have the intention to
> classify your addressees, but you have to select a certain subgroup
> because of a common interest or some very specialized reason. The
> difference is that you come from a very generalzed point of view when
> using categories and come from a very specialized point of view when
> you use distribution lists. Of course ther is some overlap, but it's
> something different.

Ok. All we need is basically a function to find all addressees that are 
members of a specified category. I'll write one when writing the category 
manager, so I'll try making that part a class that may be reused elsewhere.

> > * I would like to add the option to decide weather to display the
> > quickedit and details panes to the view configuration, with the
> > options for each to display, not display or inherit current state.
> > That way I could create views handy for editing and views handy for
> > viewing. (Again, just agree and I'll go on)
>
> I like that idea.

Ok, I'll provide a patch to add that to the view configuration dialog. I also 
have the idear that the "create view" functionality should provide a wizard 
rather than a series of dialogs. Currently canceling the action does not work 
correct. That means that all dialog pages should be seperate classes, 
reusable in a wizard as well as in the "modify view" dialog. Comments?

> > I don't know if a generic way of removing all accels inside a widget
> > exists, but maybe we should come up with one?
>
> As said above, try to use KAccelaratorManager.

Is this a suggestion that I take a look at that? and in that case, will the 
original authors of the dialog and dist list editor cooperate with me?

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