I did not foresee a big discussion on this topic, as the 'tabs' came as a natural solution to me. Some comments to what has been mailed:
Date: Fri, 15 Sep 2006 23:06:38 +0100 (BST) From: Alan Horkan <horkana@...44...>
If you are going to introduce the extra complexity and inconsistency and inflict tabs in what should be a clear and simple user interface why not just go the whole hog and use python+glade to create the extension user interfaces?
In fact, I first wanted to make my own UI, because the funcplot extension really needs to be able to read the SVG and change the UI depending on the contents of the SVG. (if you select a function plot, you should be able to change its formula; now you have to recreate a rectangle and apply a new formula) Because I want the extension to work on all Inkscape distributions I did not advance into Python libs there are not supported by the current distro. (if this is desired, then inkscape should come with a separate installer for Python, and not include it in itself)
I worry about any effect that has so many options that it requires seperate tabs.
I like options :). The funcplot extention should have a "config" tab where you can specify wether it has to delete the rectangle or not, what the stepsize is to calculate the numerical derivative, wether to actually do anything with the derivative or just make a sharp cornered 'curve', etc :) I usually want to make things as versatile as possible, which maybe is bad indeed. (certainly eats up a lot of time)
Date: Sat, 16 Sep 2006 03:55:10 -0300 From: "bulia byak" <buliabyak@...400...>
I see absolutely no problem with tabs for effects UI. If you wish you can consider them just semantic groupings that Inkscape chooses to show as tabs.
My thoughts exactly. At first I intended to make "frames". To group parameters in a framed box. But for sake of "tinyness", I made tabs so the UI window can be kept small.
Date: Sat, 16 Sep 2006 00:58:41 -0700 From: "Jon A. Cruz" <jon@...18...>
At first I was thinking that we might want to shift it away from the containment of items inside of pages, and instead go with attributes on things to mark them as belonging to the same groups. Then as I was looking to tuning things up, I realized that the way things are in funcplot.inx at the moment could be one good way to present paged UI in an abstract manner. So things could go a few different ways internally.
I did only a little thinking myself before I came up with the XML as it is now, but I don't know wether it is correct use of XML or not. I hope it is. One side effect of the way it is now, is that the notebook is really a parameter: you can read back which page was being displayed when the user clicked OK. This has to do with the way I made the implementation and was not really intended. Probably that does invite bad and unclear design. Note that the XML syntax for notebooks springs from ease of implementation and having control over positioning. (you can position a notebook halfway for example, with parameters above and below it. Clearly ugly :)