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

List:       koffice-devel
Subject:    Re: KChart development
From:       Karl-Heinz Zimmer <khz () kde ! org>
Date:       2003-05-06 22:23:09
[Download RAW message or body]

Hi Andreas,

thx for your very interesting mail!

On Monday 05 May 2003 10:41, you wrote:
(...)
> UI idea:
> ----------
> In many modern applications the so-called property toolboxes have been
> introducued, probably most well known is the property view of the QT
> designer (I don't have to explain this, do I :-)
> Anyway, having such a tool view for a chart would offer a concise access
> to all the features and settings of the chart. Property hierarchies
> could help group things that are usually displayed in a dialog box:
>
> Example: A chart needs a title, which can be drawing with the following
> information
> - the text itself (rich-text with formatting)
> - the title frame (x, y position and width and height)
> - the text alignment in this frame (left, right, center etc.)
> - the text rotation (degrees)
>
> All these settings would show up in the folded "title" property of the
> chart.
>
> The major advantage of this approach would be to have ALL settings in one
> place (easy to learn and use) and it is very easy to add new features and
> settings (easy to maintain). There is no longer a dialog-box-confusion and
> in general the creation of a chart should be much faster and more simple.
>
> Now my question is, would it be possible to change the UI of KChart in
> such a way that the chart creation process (steps 1..4) can be
> incorporated and secondly to have a "property view" in the program?

Since KChart is a KDE program nearly everything can be done of course!

The question normally is not if something is possible but if it is
desirable: as you pointed out there are several ways how to design
the UI of a charting component and not all of them are very good.  ;-)

Let us be carefull when discussing the new UI of KChart: not everything
that looks bright must be a good solution.

e.g. Your approach surely solves some problems but on the other hand
some new questions show up then, the one coming to my mind immediately
is this:

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.

example: KD Chart now uses an 'areas' concept allowing the user to add
frames or attach custom text boxes to every part of the chart  -  this
includes the title areas (here called header and footer areas) and it
includes the legend area or the data area, but *also* it includes the
little areas occupied by one data point, like e.g. a bar, or the marker
of a line point, or a pie slice...

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

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

Following the (not so elegant) settings-dialog concept she would just
open the tab page with the text box configuration or the one with the
frames configuration and there she would find all text boxes (or all
frames, resp.) that were defined by her previously...

NOTE: I am /not/ trying to tell you that your idea is bad, but I think
      perhaps it would be good to *also* keep the old settings-dialog
      way working!

Of course this would result in something people sometimes don't like
very much: in a program where most parameters can be set in TWO ways:
either using the toolbox (when you have clicked on the respective
object) or using the settings-dialog.

but:  I am *not* sure if that would necessarrily be bad.

> I would volunteer to program that but please tell me your thoughts
> about this beforehand.

Was that 'nough thoughts?    :-)


> PS: I'm pretty sure that the KD chart engine can handle most commonly used
> chart types and settings, but I was wondering if it can show logarithmic
> scales and display colour maps?

Log. axes are possible for Line charts and planned for Bar charts.

Colour maps are not possible ATM, but they sound like a good idea.

2D line charts *are* possible, where every data cell stores two
coordinates (one for the ordinate, one for the abscissa).

Karl-Heinz
-- 
Karl-Heinz Zimmer, Senior Software Engineer, Klarälvdalens Datakonsult AB
<mailto:khz@klaralvdalens-datakonsult.se>            <mailto:khz@kde.org>
 "For every complex problem there is an
  answer that is clear, simple, and wrong."  H. L. Mencken, 1880 - 1956

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

Configure | About | News | Add a list | Sponsored by KoreLogic