On Mon, Oct 28, 2002 at 04:51:15PM +0100, kudling@kde.org wrote: > Dirk Sch?nberger schrieb am 28.10.2002, > 16:34:47: > > > > And my other _Office apps_ doesn't have it, so? > > > > > As i said, if you force me to decide between usability and compliance > > > it's very clear which way i'll go. > > > > And as I said, without compliance there can be no useability. If I have to > > relearn the > > UI of each application apart, there is no useability. > > And what if the gui of a certain program is proven to be _very_ good? OF > COURSE the gui of a graphic app IS different to a word processor. Don't > try to equalize things which are not. Just to point out; all usability studies, and most graphics artist agree that the GUI of Adobe Illustrator is a the worst in usability on the market. Problem is that it is the standard and graphics-schools actually teach Illustrator (which should say something by itself). I'm just picking this message to reply to; but about this thread there are some points I'd like to talk about. First about the current toolbox widget. Since the bottom widget is so wide that it takes 2 columns of buttons I don't see any way to nicely put that in another toolbar without creating something ugly and unusable. The 2 column (or 2 row if you dock it at the top/bottom) is therefor no problem IMO, and just what lots of people expect. > > All modern GUI applications have a menubar, and a toolbar with the _user > > selected_ mostly used functionality. > > All modern operating systems have a mach kernel, now what? I must disagree here, Dirks point is valid since a user expects consistency. More below. > > Becuase things like "change stroke properties" and "change fill properties" > > aren't implemented as KActions, it isn't possible to create truely useable > > toolbars. > > You don't need to, since you have dockers/dialogs with tabpages. If you choose to access a config via a dialog, the action to access that dialog should be in the menu. This is like that in all KDE applications, and its been done for a reason. (I hope you can just accept that certain GUI design decisions are in the styleguide after being made by well-informed people) If you want to do it in a docker; then do so via actions. So the docker (which should be a toolbar) can be configured normally. Lenny has a very good point that some things are not really nice in their implementation if you have to follow the KDE rules. For example I really like the idea of dockers! A point I made last week stands though, a user WILL still expect the defaults to be usable. So a docker should just be a toolbar for maximum conformaty. For example I implemented the toolbox to use a grid, but it is still a toolbar! If Dirk then wants a number of toolbars that have the actions formatted via the xml toolbars. Let him! The only change is that the toolbuttons used currently should be KActions. Is that a problem? -- Thomas Zander _______________________________________________ koffice-devel mailing list koffice-devel@mail.kde.org http://mail.kde.org/mailman/listinfo/koffice-devel