Thanks for this answer, I'm ready to exchange with you to "coordinate" ideas.

I'm looking at your slides.

At this moment, I've made a proposal for a wiki toolbar template: http://wiki.inkscape.org/wiki/index.php/Gradient_Toolbar

A very light and simple page with informations for new Inkscape users and developpers. It cames from the fact I've tried to help at debugging and had lost lot of time just to localize a specific toolbar source code, so I think other people would be happy to have such a usefull page :o) .

As soon as the upload file form is bug-free (I've send a mail to NeoPhyte_Rep https://launchpad.net/%7Eneophyte-rep), I will put the screenshot, but you can now have a clear view.

Something I want to know if whether we can have a tag system for each dialog and toolbar in order to have a glance at all bugs and whishlists related to the classes and files he is working on. For exemple :

* gradient-toolbar * calligraphy-toolbar * inkscape-preference-dialog * print-dialog * ...

Finally, a link will be better on the wiki than a dynamic bug list (look at my wiki template page). For blueprints, I did not find an easy way to find all pages so I've improvised with the search launchpad URL.

I don't know if the inkscape-devel list needs to be in copy for this discussion. Feel free to remove it if i'm spamming.

I will not be at your IRC chat.

Sincerily,

*Romain de Bossoreille*

Le 17/12/2011 07:47, Jon Cruz a écrit :

On Dec 16, 2011, at 2:07 PM, Romain de Bossoreille wrote:

...

Hi,

I'm working updating the wiki to have a more clear view on modules, works to be done and tips for developpers.

Ooh, interesting timing. I've been trying to finish up some higher level docs, breakdowns, etc.

Probably a good time to coordinate.

...

Here I'm working on the toolbars: http://wiki.inkscape.org/wiki/index.php/User_Interface_Modules#Toolbars

Some questions: • Nearly everything is in src/widgets/toolbox.cpp. The final goal is it to have breakdown in per-toolbar-files (like for exemple we have actually for Select and Gradient toolbars) + toolbox.cpp file?

No, actually the final goal is to have everything as individual actions that can be combined dynamically into any configuration of one or more toolbars that a given individual feels like having at the moment.

...

• If yes, can I work at this breakdown or is there already a work to do this?

Yes, there is helpful work to do. But it is in a slightly different direction.

...

• Is there a C++ migration guidance for toolbars? I've found nothing.

I'll take care of that this weekend. Much of it will be in clarifying the adaptive user interface approach.

I gave a presentation on this topic in general at linux.conf.au 2010, and much can overlap things presented at Libre Graphics Meetings by Michael Terry and his students.

The summary of mine is at http://www.lca2010.org.nz/programme/schedule/view_talk/50299?day=friday

and videos from the conference are at http://2009.r2.co.nz/20100118/

It looks like my talk can be streamed or downloaded from http://2009.r2.co.nz/20100118/50299.htm

...

• Can toolbars files move to a dedicated directory (ex: src/toolbars and then the C++ version in src/ui/toolbar) or will they still appears as widgets?

We actually want to go in a different direction, and focus on the abstract actions that can then be combined at runtime into toolboxes.

...

• In files we are speaking about "toolbars" and "toolboxes". What's the good word? I think it's toolbar, but just to be sure... Moreover, I would like to propose you to have one page per toolbar in the wiki with a screenshot, list of functions (like a user documentation but that could be also usefull for developpers to find their way), links to related source files and (if we can have an automatic link between the wiki and launchpad) links to all bugs/wishlist related to it (with a system of tags).

I think the naming was a bit of a mix, coming from legacy code that predated certain widgets appearing in GTK+, etc.

...

What do you think about it? Can I work in this direction?

Aside from the other information, look to the XML that is embedded directly in the toolbox.cpp source. It is of a form native to versions of GTK+2, and not best for exposing directly. The next step there is to get a slightly more abstract XML format to use for loading and saving. We'd want to avoid the physical and stick to the more abstract and generic. These also could be cascaded somewhat like CSS.

I've been a bit busy of late, but now am getting back on track to be in our IRC room evenings Pacific time, if you can drop by.

On Sat, 2011-12-17 at 08:34 -0800, Josh Andler wrote:

Romain,

The gradient toolbar should eventually look like the following: http://i.imgur.com/DZFC8.png

Note I hacked this together really quickly and it isn't pretty...

The 3rd gradient button is for Mesh gradients, which exist in a branch currently. Following changes get other existing options in the user's view. Repeat is the function from the Fill & Stroke dialog to allow None, Repeat, or Mirror options. Following that is a Reverse Gradient button (Shift+R in the gradient tool, but should have UI). Following are stop controls from the beyond broken gradient editor. Buttons to Add & Delete stops (Insert & Delete keys respectively), the Stop Selector, and the numeric Stop Offset widget. Note, all of the features already exist, they just need to be updated in the code and hooked up in the toolbar. Note the absence of the "Edit..." button. The VERY BROKEN Gradient Editor can be safely removed once these features are added to the toolbar.

It will be nice to no longer need the gradient editor. Note that I will probably add a fourth button to create a conical gradient (as a special form of mesh gradient). A number of the items will need to be grayed out when editing meshes: Repeat, Reverse, Offset. We may also want to specify the initial number of rows and columns in a mesh. But this is all a ways off.

Tav

On Sun, Dec 18, 2011 at 2:51 AM, Romain de Bossoreille <romain2boss@...48...> wrote:

Ok, thanks for this picture. I see I've choosen a good exemple :o) .

In my opinion, the wiki webpage I show you should contain only current state of the toolbar and links to proposals. If there is a work in progress or proposals, we should create a dedicated wiki page with all the discussions they need.

Is there already one to speak about your proposition? What's his status? Accepted? Proposal? One of many proposals? I will link it to my template proposal.

There is no wiki page about it to my knowledge.

Maybe I'm speaking after the war, but if you're asking my opinion (and I would be happy to share it on the proposal page):

I never use the gradient toolbar, I always work with the fill and stroke dialog and think the toolbar is a dupplicate and not handy way to do the same job :o) (it's hard to move it, having the toolbar changing at each function requires attention, the inline presentation is not very user-friendly for me and such a function, on my mind the left toolbar where the gradient button is is more for creating objects than for modifying them...).

You're missing out on a great deal of the power of Inkscape if you view the tool controls bar as simply something only to create things and not a great way to go back and modify what you've already created.

This proposal is mixing three concepts so the user can't differentiate them anymore. Unlike you I like the current interface because it let us differentiate them:

It's cleanly broken down. Create the gradient, modify the gradient, modify it's stops. Given that it removes the need to open a dialog and makes the whole process much faster, it's more of a win.

Don't forget a whichlist item that is to add a gradient rename feature (I'm part of those who are asking it!!),

If a single icon button right after the gradient selector widget to rename things is all that important in your view (and I can see the value), by all means add it to the mockup.

With a lonnnnnnnnnnnnnnnnng toolbar, will the user be able to use it easily on small screens? On multi-windows at a time?

It's shorter than the Calligraphy & Text Tool Controls bar, it's a non-issue. Multi-windows would function like it currently does and like all other tools are supposed to.

A toolbar is not very evolutive in terms of widget positionning, and you will still need to show dialogs to change the stop colors

I'm not sure how you propose to make it more evolutive with widget position. I'd say it's evolutive in terms of usability and requiring users to remember fewer shortcuts, have more control, and minimize the number of places needed to look to achieve one task (editing gradients). There's no need for showing dialogs, the same as it currently stands. You can do it via the swatches at the bottom of the screen or by using the Click+Drag feature of the color widget at the left of the swatches. If you don't quite understand what I'm saying, create an object, apply a gradient, select a gradient stop on-canvas, click a swatch at the bottom of the screen. The same way it's useful to have named gradients, with the swatches if you have a custom palette, it would speed up the workflow even more (I'm thinking comic or icon creation for example).

I would not love to go on fill and stroke, that opens a dialog and then to change the gradient it changes a toolbar in the main window (I think first I would not see it), and so hiding another one and I've to switch from the fill and stroke dialog to the main window... A strange workflow... I would rather prefer to include directly the gradient dialog in the gradient tab of the fill and stroke dialog and remove this toolbar or at least let the actual one simply doing:

How to apply the gradient, What gradient is selected

That is a really cumbersome approach. Plus, if you're worried about screen space (stated earlier), the Fill & Stroke dialog is monstrous as it stands, adding in gradient editing widgets will truly turn it into a franken-dialog.

This is how I use the gradient feature, but I understand others use it (or want to use it) in a different way!! If I'm hurting anyone, please let me know.

You're not hurting anyone at all, discussion is good and healthy (rarely does one mind have the ultimately best solution). But one of the things that we have worked towards over the years is requiring as few dialogs as possible. When I was talking to bulia about this, this was something we were heavily focused on (the gradient editing dialog has been in a deteriorating state for years now).

Cheers, Josh