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

List:       koffice-devel
Subject:    Re: Multiple tool dockers
From:       Thomas Zander <zander () kde ! org>
Date:       2008-07-04 19:52:06
Message-ID: 200807042152.06507.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thursday 3. July 2008 21:19:40 C. Boemann wrote:
> I'd like to give a proper presentation of the multiple tool dockers
> concept.

Thank you, I have been curious why this feature was added since I have not 
heard any usecases. And as always I'd love to be educated :)

> Currently we have one tool docker per tool, but for some tools that hasn't
> been big enough to hold all the options, so those tools have put a
> tabwidget inside the tool option docker.
>
> I believe this is a problem because it doesn't allow the users to see
> everything at the same time. Instead they have to change tabs to get what
> they need.

Its a balance, the design of having widgets take more screen real-estate makes 
for an easier overview (due to less widgets on screen at the same time). We 
discussed this less then two weeks ago[1] and everyone but you agreed we 
focus on widescreens.  Meaning that tabs are a good thing as we have taller 
widgets but multiple next to each other.

In other words, I fail to see how this is a problem and I got the strong 
suspicion I'm not alone, it only is a problem if you reject the notion that 
we design for widescreen. (and we still do)

To give a good example; many usability advisers will tell you that if you have 
more than 7 items in a combobox, you should consider using a list instead.  
In your example screenshot you converted the listbox (which most of the time 
has at least 7, possibly many more items) to a combobox.  So you are going 
the wrong way.

The next part of your mail seems seems to address one of my points I wrote in 
another thread where repeated my doubts about your suggestion;
Let me repeat the other points as well, some of which you failed to address;

On Thursday 3. July 2008 16:32:51 Thomas Zander wrote:
> > The points where your suggestions fail are multiple; the user needs to
> > manually organize more dockers and has to manually figure out which ones
> > fit together and which ones don't
> > With the suggestions of boudewijn to use a different size or at least a
> > smaller style for the dockers, having multiple tabs will make things look
> > bad since those tabs are from Qt dockers and thus will not use this
> > smaller size.
> >
> > The problem that we detected earlier that its hard to make stuff look
> > good by having a pre-defined ordering gets worse if you make each tool
> > show multiple tabs. Especially if they get added/removed automagically on
> > changing tool.
> >
> > Last; it would be weird that *tools* get the option to have multiple
> > dockers, but most dock-plugins don't. So people may get confused why some
> > tabs can be re-arranged and others can't.

Your answer;

> It's also bad because it's weird that some tabs (those within a tool option
> docker) can't be split apart whereas tabbed dockers can easily be split.
> People may get confused over this.

I don't think your counter argument holds. The tool-options docker has always 
been 1 docker which means that if you select a different tool exactly one 
docker changes, and it may indeed get tabs. The fact that one docker changes 
in one place on the screen due to user input. Well, I can't help but think 
that a user certainly will understand the relation there.
Whereas in your example maybe 3 dockers in different locations and different 
tabs may change. I hope you agree that this is not an improvement.
In the grand scheme of things I'm convinced that the design we had is much 
better then the design you added.
Also you ignored the various other problems I noted.

More to the point is that there seems to be no valid usecase for your new 
feature. The one usage you have is a design that everyone here disagreed is a 
path we should take[1].
But at the same time your new feature introduces new API that each (tool) 
plugin writer has to understand and implement.


I'm not sure what to say, the KOffice community is proud to share 
responsibility among all devs for the various koffice-libs components, which 
works by having consensus and not just a wild wild west of "he who programs 
decides". Still, after your ideas got shot down you end up committing the 
required components for that idea anyway. Without any discussion on this list 
or on the #koffice irc channel.

What do we do with this?

1) http://lists.kde.org/?l=koffice-devel&m=121399321130726&w=2
-- 
Thomas Zander

["signature.asc" (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


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