Re: [Inkscape-devel] Announcing: 'tabs' in the UI for effects.
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 :)
On Mon, 18 Sep 2006, Johan Engelen wrote:
Date: Mon, 18 Sep 2006 11:10:10 +0200 From: Johan Engelen <johane@...1482...> To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Announcing: 'tabs' in the UI for effects.
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:
Ever since Opera (and much later Mozilla) used a tabbed document interface it has seemed natural to throw them at everything. It does sort of work like the same way you can hammer a screw into a wooden board.
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.
You see now you have gone beyond SVG. Maybe Inkscape could support generic plotting functionality but trying to do it all through an extension is too much.
If I knew what problems you were trying to solve I might be able to recommend something, like perhaps plotting your data in Gnumeric and exporting the graph as 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)
That is exactly the kind of one off behaviour I would expect from effects and I do think you are making things more difficult than they should be by trying to do it through an effect.
current distro. (if this is desired, then inkscape should come with a separate installer for Python, and not include it in itself)
I'm sure an option to use a common version of Python will come in time but including it by default is a far more robust solution.
I worry about any effect that has so many options that it requires seperate tabs.
I like options :).
I like my penknife too but in most cases I'd be happier with a proper knife or a proper philips head screwdriver and there are many features I will never use, it just happens that a penknife is conveniently portable and good enough when I dont have the real thing.
The funcplot extention should have a "config" tab
I respect your determination to gradually build the parts you need of full graphing system in Inkscape. It doesn't make it a particularly good default and I suspect there are easier ways to achieve whatever results you really want, like perhaps graphing in another application and importing into Inkscape to apply the final touches.
I usually want to make things as versatile as possible, which maybe is bad indeed. (certainly eats up a lot of time)
If you were doing this as a third party plugin for Inkscape I'd say go nuts, provide all the options you think your audience needs.
Take a look at some of the very complicated plugins included with the GIMP. They are certianly interesting but things like a fractal browser aren't particulary useful in terms of creating general artwork. (The can be used to create some very specific features but plugins like Gimpressionist badly reinvents so much of what should be general functionality.)
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.
I'm sure bulia is the kind of user who will struggle and put the time in to learn the software if he believes it will save him time in the long run. Not many people have that same determination.
Take a look at other software, Gimp, Adobe, etc. and see how their add-ons and plugins are relatively simple. Sure you will see some third party plugins that resemble the cockpit of a 747 airplane but most avoid the kind of complexity that would require tabs.
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 :)
As Jon was saying seperating the content from the presentation is a good idea, so conversely manually specifying the tab positioning is a bad idea for all but the most horribly complicated extensions. My point is that extensions that complicated should be rare enough and complicated enough to merit using glade and python.
On Sep 18, 2006, at 8:47 AM, Alan Horkan wrote:
As Jon was saying seperating the content from the presentation is a good idea, so conversely manually specifying the tab positioning is a bad idea for all but the most horribly complicated extensions. My point is that extensions that complicated should be rare enough and complicated enough to merit using glade and python.
Ah, but here we have a disconnect of eventual roadmap.
A base item is that regardless of the implementation details, the long-term goal is to get Inkscape to the point where the bulk of functionality is from extensions. We're trying to move to that, so the complex functionality is not to be the "rare" case, but rather should end up as the normal case.
So eventually we'll need to work out all the ways to best address the needs from both sides. Alan does a pretty good job of detailing many of the UI issues. Others focus well on the internals. However, if you have need of some of this, we can probably bump up some of it. Mainly, we have a lot of features to be implemented, and are mainly limited to areas where bodies are interested in coding.
participants (3)
-
Alan Horkan -
Johan Engelen -
Jon A. Cruz