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), 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 :

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.