From koffice-devel Tue May 06 22:23:09 2003 From: Karl-Heinz Zimmer Date: Tue, 06 May 2003 22:23:09 +0000 To: koffice-devel Subject: Re: KChart development X-MARC-Message: https://marc.info/?l=koffice-devel&m=105225973419862 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 "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