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.

On Fri, 15 Sep 2006, Jon A. Cruz wrote:

...

...

From: Johan Engelen <johane@...1482...> To: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Inkscape-devel Digest, Vol 4, Issue 17

Re: Announcing: 'tabs' in the UI for effects. (bulia byak)

Ugh. The one benefit of Script-fu with the gimp was simplicity. That had the knock on effect of keeping things reasonably consistent.

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?

Glade + this problem == Eww!!!

Note: I'm not advocating getting rid of the simple system just that it be kept simple and more complicated things be handled another way.

Glade is overkill for this problem, so are tabs. If you have an extension that is so overcroweded you feel it needs tabs then an autogenerated user interface is not a good idea at all. You may as well seperate out the interface entirely and glade is one way to seperate out the user interface. Take a look at the glade+python demo that is include with pygtk.

I'm not saying Glade doesn't suck in various ways but what I am saying is that most effects shouldn't need anywhere near this level of complexity, or else their are serious problems in the effect user interface or Inkscape itself is missing a large chunk of functionality if someone is trying to cram so much into an extension.

What we want to end up with is going the other way. Have the extensions describe their *logical* needs and let Inkscape hosting them worry about the *physical* presentation.

Like script-fu, good up to a point. After that point I'd still say use Glade because you aren't going to be able to autogenearate a good enough interface there comes a point where you need to desing it to fit the task.

Seperating out the logical needs and letting Inkscape worry about the presentation will be especially good if that presentation is relatively easy to change. Each of the scripting languages in gimp ended up with a slighly different and inconsistent user interface for their version of gimp-fu (and I'll be interested to see what new inconsistencies the Ruby scripting introduces to the gimp user interface).

There are a few script-fu which are too tall for smaller screens the simple interface works well enough. You could do a lot worse than copying it.

If you want to justify Tabs look at how few of the gimp plugins use tabs. Gimpressionist in particular is an abomination, and it wouldn't need so many tabs if it weren't carrying around an entirely seperate brush and pattern system from gimp core.

Hint's for grouping of the extension's data would be good. Then leave Inkscape to pick the best representation.

Expanders/disclosure triangles might follow on better from the current approach.

...

I worry about any effect that has so many options that it requires seperate tabs.

yeah I have issues with tabs, but they are all too often abused like they were in the old preferences dialog and offering them in this context is inviting bad design

Now this is the good concern. If we can hammer out some good "rules" for what is good use of tabs and what is not, and how to "hint" extensions to keep things moving well.

While writing this response I looked through all of the current Effects, and noticed checkboxes where the check follows the text, eek! (In the interpolate effect for example.) Someone must secretely hate GTK not to mention the Gnome Human Interface Guidelines.

My other big concern about Extensions is input checking at the time of input, rather than waiting until the script is run to check if the input values are valid.

Extensions are in theory "slow" at least compared to native built in functionality there is an extra step. (Of course if an extension does exactly what you need it can turn out to be much faster in practice.) There is some input which could be checked as the user types rather than waiting until the big step when script is run, especially cases where a developer wants to try and have a < b < c.

I was trying to find a specific example but none comes to mind. The grid effect allows a line width of Zero, which is a plain old bug and bad input which shouldn't ever be allowed.

The L-System fractal is rather complicated and I defy anyone to understand how to use it without already knowing the algorithm or reading the documentation (which I cannot find right now if it exists yet). The use of a text entry allows for all kinds of bad input but a combo box or drop down menu might be enought to restrict it to sensible inputs.

Similarly other scripts are usign text entries when they should be using number inputs. Maybe rules are needed to point this out. Take for example "Effects, Visualise Path, Number Nodes" which uses a text input for "dot size: 10px". Delete the px (perhaps while changing the number and it fails. What is worse there is the next time you run the script there is no way to Reset to the defualt values and it is very hard to undo your mistake. The Reset button in script-fu was a really good idea, one I hope Inkscape copies.

Sincerely

Alan Horkan

Inkscape http://inkscape.org Open Clip Art http://OpenClipArt.org