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

List:       koffice-devel
Subject:    KChart UI discussion
From:       Andreas Nicolai <Andreas.Nicolai () gmx ! net>
Date:       2003-05-08 8:36:36
[Download RAW message or body]

Hi Karl-Heinz!

Thanks for your quick answer and your thoughts about the UI change of KChart. 
I've been thinking a bit about "how to do this exactly" and here are some of 
my ideas about the things you pointed out:

> If your property toolbox depends on the kind of object selected by the
> user (like it was done e.g. by Aldus Freehand many years ago) then she
> does not have the chance to apply properties to many different objects
> of different types.

The toolbox should contain ALL properties that can be adjusted using this 
specific chart: The following property subtree for the title property is just 
an incomplete example but should show the basic idea:

+- title (bool)  -> means: show title or not
  +- title text (rich text)
  +- default frame positioning (flag - several options or manual)
  +- title frame (rectangle)
  |  +- x position	(int)
  |  +- y position	(int)
  |  +- frame width	(int)
  |  +- frame height	(int)
  +- text frame properties
     +- text color (QColor)
     +- background color (QColor)
     +- background image (image file name)
     + horizontal text align (flag)
     + vertical text align (flag)
     + text rotation (int -> degrees: 0 = horizontal)

Using this small example I should explain the property concept a bit more in 
detail:

In general a chart will be composed of objects that have a fixed position or 
at least a fixed position with respect to the main charting frame (axes, grid 
lines, the data series etc.) and movable components (title, legend etc. all 
components enclosed in movable frames).

It should be possible to position the movable frames by default (like the 
legend: centered on top, or at the sides) and custom positions defined by the 
user (dragging the frame to the right place).

Example: The  "title" property is a movable component
The default placement can be made using the property "default frame 
positioning" which moves the frame to the given position and adjusts all 
dependent frames (like the main charting area). 

Now the user might want to move the title to some place else, and this should 
be possible by either specifying the x/y position directly or dragging the 
title frame to a new position 
(which both changes the "default frame positioning" property to "manual").

How could this dragging be done?

> Attaching frames or aligning custom text boxes to these areas could be
> done by the user selecting a frame icon in your proposed properties
> toolbox, or by selecting a text box like icon...

This would be one possibility, but because all movable frames should have a 
frame property (and thus a boundary rectangle) the user could simply click on 
the desired frame (which would be shown selected) and move it with the mouse.

Programwise this would mean the following:
- grab a mouse click event on the chart widget
- loop over all visible movable components of the chart until you find one 
where the mouse x and y coordinates fit in
 NOTE: There should be a precedence given for the different chart components, 
so that for instance the title is always positioned over the legend or 
something like this -> also necessary for drawing (from back to front)
- mark the enclosing frame as selected (and remember the frame)
- as long as the mouse button keeps pressed just move the frame around 
(adjusting it's x and y coordinates as well as its "default positioning" 
flag) and redraw the frame continuously
- unmark the frame when mousebutton was released


This approach solves two issues:
1. The user can intuitively move the movable components of the frame
2. Using the property toolbox the user can always specify exact positions and 
(in case he accidently moved the component out of view) reset the frame 
position to a default location


> But *where* would the user see *all* her text boxes, or how would she
> modify *all* her frames...?
> e.g. she might want to use another line style (or color, or width...)
> for the frame lines used: following the toolbox concept she would have
> to click on each and every object to change its respective property. :(

Since the property toolbox contains all properties of the chart (all immovable 
and movable components) the user can change the properties for all components 
BUT - as pointed out - only for one component at a time. So there is actually 
the need for setting properties for multiply frames at the same time. 

About this issue I'm a still thinking of a good solution. The idea of 
selecting multiply frames at the same time (for instance by using a selecting 
rectangle or holding CTRL while clicking) and adjusting the toolbox (showing 
only the properties that can be changed for the selected frames) sounds like 
a lot of work. But maybe this is the most intuitive solution although I don't 
like the idea of click and select -> this would result in the same problems I 
meantioned in the earlier mail when summarising the drawbacks of the other 
charting programs.

Another  possible other solution would be a dialog box style where you can 
select the components to change and the properties (just an addition to the 
already existing configuration dialog). So the dialog could offer a list of 
all components of the chart which can be selected/deselected and a adjustable 
toolbox inside the dialog. 

A compromise between the two solutions would be the following:

Instead of having a dialog we could introduce another toolbox (activated like 
the Gideon toolbars) which just allows selecting chart components by name 
(thus avoiding the dreadful pixel clicking). As soon as multiple chart 
components are selected in this toolbox the property toolbox will contain 
only those properties, that are common to the selected components (or grey 
out the others). 

This would be my favorite solution (because neither a second dialog and chart 
clicking is required) but any other ideas are welcome!

Sorry for the long mail (again) but maybe I should start writing a concept 
file which would contain all these ideas. And once we have such a complete 
concept we could start distributing the coding work :-)

Bye - Andreas

_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]