Hello list again, I sent my patch to Alexandre P. for him to commit it. It's a naïve implementation for the low hanging https://bugs.launchpad.net/inkscape/+bug/171255 . It's really nothing but I like the calligraphic tool a lot better with this small adjustment: I added 4 icons for dip, pen, brush and reed in the toolbox with hard coded matching settings. Clicking one button sets the calligraphic tool with the matching presets. I also removed the reset button (the default settings are the dip settings) On the negative side, the toolbox gets very very long, and there is no way to customize those presets, but I think those are quite sane. If you want to suggest more presets, ore some improvements, or your disagreements, please go.
Aubanel.
On Thu, Mar 13, 2008 at 8:28 PM, Aubanel MONNIER wrote:
Hello list again, I sent my patch to Alexandre P. for him to commit it. It's a naïve implementation for the low hanging https://bugs.launchpad.net/inkscape/+bug/171255 .
The crappy wi-fi connection prevents me from committing it. Could you please submit both icons.svg and toolbox.diff to the tracker?
Alexandre
I attached a patch to the tracker: https://bugs.launchpad.net/inkscape/+bug/171255
Can someone commit it ?
Thanks,
Aubanel.
2008/3/13, Alexandre Prokoudine <alexandre.prokoudine@...400...>:
On Thu, Mar 13, 2008 at 8:28 PM, Aubanel MONNIER wrote:
Hello list again, I sent my patch to Alexandre P. for him to commit it. It's a naïve implementation for the low hanging https://bugs.launchpad.net/inkscape/+bug/171255 .
The crappy wi-fi connection prevents me from committing it. Could you please submit both icons.svg and toolbox.diff to the tracker?
Alexandre
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Nevermind, my svn account now works ! thanks !
2008/3/13, Aubanel MONNIER <aubanel@...400...>:
I attached a patch to the tracker: https://bugs.launchpad.net/inkscape/+bug/171255
Can someone commit it ?
Thanks,
Aubanel.
2008/3/13, Alexandre Prokoudine <alexandre.prokoudine@...400...>:
On Thu, Mar 13, 2008 at 8:28 PM, Aubanel MONNIER wrote:
Hello list again, I sent my patch to Alexandre P. for him to commit it. It's a naïve implementation for the low hanging https://bugs.launchpad.net/inkscape/+bug/171255 .
The crappy wi-fi connection prevents me from committing it. Could you please submit both icons.svg and toolbox.diff to the tracker?
Alexandre
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Aubanel:
I think only 4 presets is too few, and giving each one a button on the bar is too wasteful. I would prefer a drop-down list with a wider variety of styles, and I think it should be at the right end of the toolbar, because it's a more specialized control. And of course, ideally it should have "Save" and "Delete" buttons as well for managing the presets.
2008/3/13, bulia byak <buliabyak@...400...>:
Aubanel:
I think only 4 presets is too few, and giving each one a button on the bar is too wasteful. I would prefer a drop-down list with a wider variety of styles, and I think it should be at the right end of the toolbar, because it's a more specialized control. And of course, ideally it should have "Save" and "Delete" buttons as well for managing the presets.
I agree with many of those remarks.
1/ How do I store many those presets ? 2/ Is there a combo widget with optional icons an rename-able fields ? 3/You are welcome to propose more meaningfull presets ;) 4/About the position in the toolbar, I started with buttons on the right, but they are hardly accessible, while I'm sure if we provide 4 to 7 meaningfull presets those will be use 99% of the time. And it's a bit against the workflow: a/ choose the closest preset b/ adjust the values if needed
On Thu, Mar 13, 2008 at 6:25 PM, Aubanel MONNIER <aubanel@...400...> wrote:
I agree with many of those remarks. 1/ How do I store many those presets ?
The correct way is to add a new group to prefs, under the calligraphic tool group, and store that stuff there.
2/ Is there a combo widget with optional icons an rename-able fields ?
Not sure on that. I guess not but I'm not a great fan of GTK and may be missing something. Can anyone comment?
Actually I think you can make it this way: have just a single button on the toolbar which, when pressed, opens a menu with a list of presets and, after a separator, the "Delete" and "Add" command. If the current parameters match those of a preset, that preset gets a checkmark in the menu and Delete applies to it; otherwise Delete is disabled. This should be easy enough to code, provide all the necessary features, and take little space on the toolbar (just one button).
3/You are welcome to propose more meaningfull presets ;)
I will once we have an easily extensible framework to add them to, instead of those fixed buttons :)
4/About the position in the toolbar, I started with buttons on the right, but they are hardly accessible, while I'm sure if we provide 4 to 7 meaningfull presets those will be use 99% of the time. And it's a bit against the workflow: a/ choose the closest preset b/ adjust the values if needed
That makes some sense too. Maybe we can put it on the left if it's just one button as described above.
On Mar 13, 2008, at 2:25 PM, Aubanel MONNIER wrote:
I agree with many of those remarks. 1/ How do I store many those presets ? 2/ Is there a combo widget with optional icons an rename-able fields ? 3/You are welcome to propose more meaningfull presets ;) 4/About the position in the toolbar, I started with buttons on the right, but they are hardly accessible, while I'm sure if we provide 4 to 7 meaningfull presets those will be use 99% of the time. And it's a bit against the workflow: a/ choose the closest preset b/ adjust the values if needed
Guess what? I've been doing coding to allow for a nice UI for just that sort of thing!
http://codewideopen.blogspot.com/2008/03/new-tablet-config.html
So we will need to coordinate on getting what you're working on playing nice with the tablet stuff I'm working on.
As far as widgets go, there are a few already. I added some based on GTK+ Actions so that they will flow from toolbar to overflow menu, etc. One example to look at is the "mode" on the tweak tool sub toolbar. Another is "Close gaps" on the paint bucket sub toolbar. In toolbox.cpp look for EgeSelectOneAction* act = ege_select_one_action_new ( "TweakModeAction", _("Mode"), (""), NULL, GTK_TREE_MODEL(model) ); and EgeSelectOneAction* act2 = ege_select_one_action_new ( "AutoGapAction", _("Close gaps"), (""), NULL, GTK_TREE_MODEL(model) );
Look at ege-select-one-action.h and the uses in the codebase of ege_select_one_action(). To flip from a set of side-by-side buttons to a single drop-down, a call to ege_select_one_action_set_appearance () is made feeding it "full, "compact", or "minimal".
As long as the settings are based on named actions, we will be able to use dynamic config and allow users to place things wherever they want on the toolbars and menus. :-)
2008/3/14, Jon A. Cruz <jon@...18...>:
On Mar 13, 2008, at 2:25 PM, Aubanel MONNIER wrote:
I agree with many of those remarks. 1/ How do I store many those presets ? 2/ Is there a combo widget with optional icons an rename-able fields ? 3/You are welcome to propose more meaningfull presets ;) 4/About the position in the toolbar, I started with buttons on the right, but they are hardly accessible, while I'm sure if we provide 4 to 7 meaningfull presets those will be use 99% of the time. And it's a bit against the workflow: a/ choose the closest preset b/ adjust the values if needed
Guess what? I've been doing coding to allow for a nice UI for just that sort of thing!
http://codewideopen.blogspot.com/2008/03/new-tablet-config.html
So we will need to coordinate on getting what you're working on playing nice with the tablet stuff I'm working on.
As far as widgets go, there are a few already. I added some based on GTK+ Actions so that they will flow from toolbar to overflow menu, etc. One example to look at is the "mode" on the tweak tool sub toolbar. Another is "Close gaps" on the paint bucket sub toolbar. In toolbox.cpp look for EgeSelectOneAction* act = ege_select_one_action_new( "TweakModeAction", _("Mode"), (""), NULL, GTK_TREE_MODEL(model) ); and EgeSelectOneAction* act2 = ege_select_one_action_new( "AutoGapAction", _("Close gaps"), (""), NULL, GTK_TREE_MODEL(model) );
Look at ege-select-one-action.h and the uses in the codebase of ege_select_one_action(). To flip from a set of side-by-side buttons to a single drop-down, a call to ege_select_one_action_set_appearance() is made feeding it "full, "compact", or "minimal".
As long as the settings are based on named actions, we will be able to use dynamic config and allow users to place things wherever they want on the toolbars and menus. :-)
OK, just committed something using this kind of code and making use of prefs so anyone can add sensible defaults to preferences-skeletton. Two questions I need to solve before going further: 1: Problem on init. Settings are positioned on the change signal. This cause problems on init if re-selecting the already selected profile. Is there some kind of /set/ signal instead of /change/ ? 2: Is there a way to display svg icons in the combo box along side the text ? (I'll read its value from a property /icon_id/ in configuration)
On Fri, Mar 14, 2008 at 11:59 AM, Aubanel MONNIER <aubanel@...400...> wrote:
OK, just committed something using this kind of code and making use of prefs so anyone can add sensible defaults to preferences-skeletton.
Some comments:
max_presets="7" - why so few? If I'm doing serious work I may have dozens of my own presets. It's like the maximum number of recent documents in File menu - most other apps have 4 or 5 which alone makes them nearly useless for serious work. Inkscape has 36, and even that only because otherwise the submenu wouldn't fit into the screen :)
It's misleading when it claims that I have "Dip pen" active when I didn't choose it, or have already changed some parameters. It must show no preset by default, until I choose one. Here's what I propose:
- remove the "Profiles:" label
- add a new item to the top of menu: "No preset", which will be chosen by default and will also serve to explain the purpose of this control
- when I change something and it does not match the current present, let this control sense that and switch to No preset automatically
- eventually, add "New preset" (with a dialog popping up for typing a name) and "Delete preset" (disabled if no preset is current) to the bottom of the menu
2008/3/14, bulia byak <buliabyak@...400...>:
On Fri, Mar 14, 2008 at 11:59 AM, Aubanel MONNIER <aubanel@...400...> wrote:
OK, just committed something using this kind of code and making use of
prefs
so anyone can add sensible defaults to preferences-skeletton.
Some comments:
max_presets="7" - why so few? If I'm doing serious work I may have dozens of my own presets. It's like the maximum number of recent documents in File menu - most other apps have 4 or 5 which alone makes them nearly useless for serious work. Inkscape has 36, and even that only because otherwise the submenu wouldn't fit into the screen :)
that's temporary, I need a way to query the preferences for the number of sub-prefs in a group. That should'nt be too hard.
It's misleading when it claims that I have "Dip pen" active when I
didn't choose it, or have already changed some parameters. It must show no preset by default, until I choose one. Here's what I propose:
remove the "Profiles:" label
add a new item to the top of menu: "No preset", which will be chosen
by default and will also serve to explain the purpose of this control
- when I change something and it does not match the current present,
let this control sense that and switch to No preset automatically
That's one of the possibility I envisionned, so OK, I'll do that
- eventually, add "New preset" (with a dialog popping up for typing a
name) and "Delete preset" (disabled if no preset is current) to the bottom of the menu
I'm not a great fan of popups but I guess that's the easiest to implement.
--
bulia byak Inkscape. Draw Freely. http://www.inkscape.org
2008/3/15, Aubanel MONNIER <aubanel@...400...>:
2008/3/14, bulia byak <buliabyak@...400...>:
On Fri, Mar 14, 2008 at 11:59 AM, Aubanel MONNIER <aubanel@...400...> wrote:
OK, just committed something using this kind of code and making use of
prefs
so anyone can add sensible defaults to preferences-skeletton.
Some comments:
max_presets="7" - why so few? If I'm doing serious work I may have dozens of my own presets. It's like the maximum number of recent documents in File menu - most other apps have 4 or 5 which alone makes them nearly useless for serious work. Inkscape has 36, and even that only because otherwise the submenu wouldn't fit into the screen :)
that's temporary, I need a way to query the preferences for the number of sub-prefs in a group. That should'nt be too hard.
It's misleading when it claims that I have "Dip pen" active when I
didn't choose it, or have already changed some parameters. It must show no preset by default, until I choose one. Here's what I propose:
- remove the "Profiles:" label
- add a new item to the top of menu: "No preset", which will be chosen
by default and will also serve to explain the purpose of this control
- when I change something and it does not match the current present,
let this control sense that and switch to No preset automatically
That's one of the possibility I envisionned, so OK, I'll do that
- eventually, add "New preset" (with a dialog popping up for typing a
name) and "Delete preset" (disabled if no preset is current) to the bottom of the menu
I'm not a great fan of popups but I guess that's the easiest to implement.
--
bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Ok, I'v been fiddling with that and I'm quite stuck with some limitations of the prefs API. I need a way to get each children without knowing it's id (I did that with reprs ans XML::Nodes but that break encapsulation, should I add a function in the prefs API that returns a GSList of strings for the ids of the children to be queried later by the pref API ?) I need a way to create a child preference. I have difficulies in making that work too, I tried something like: Node *parent=the_parent; Node new_child=parent->document()->createElement("group"); but that does not seem to work. Any hint ? About breaking encapsulation, I'm not sure of what I must do, because the xml/nodes.h interface is already included in toolbox.cpp and it requires to add non-frequently used elsewhere functions into prefs and introduces additional memory considerations (should I free or should I go ? ) on the GSList. OTOH breaking encapsulation is bad for the day we change the prefs implementation.
Another different topic, I need a way to be notified that a setting has been changed from the toolbox. I such a signal existing somewhere ?
Tank you for any direction, Cheers, Aubanel.
On Tue, Mar 18, 2008 at 3:35 PM, Aubanel MONNIER <aubanel@...400...> wrote:
Ok, I'v been fiddling with that and I'm quite stuck with some limitations of the prefs API. I need a way to get each children without knowing it's id (I did that with reprs ans XML::Nodes but that break encapsulation, should I add a function in the prefs API that returns a GSList of strings for the ids of the children to be queried later by the pref API ?)
Yes, we didn't need this before, but now that we need it, I think the best approach is to extend the prefs API. This had to happen sooner or later, you are just the first to hit the wall :)
I need a way to create a child preference. I have difficulies in making that work too, I tried something like: Node *parent=the_parent; Node new_child=parent->document()->createElement("group"); but that does not seem to work. Any hint ?
Did you attach the new_child to the_parent?
About breaking encapsulation, I'm not sure of what I must do, because the xml/nodes.h interface is already included in toolbox.cpp and it requires to add non-frequently used elsewhere functions into prefs and introduces additional memory considerations (should I free or should I go ? ) on the GSList.
I don't think prefs pose the risk of becoming a resource hog, at least not in the foreseeable future.
Another different topic, I need a way to be notified that a setting has been changed from the toolbox. I such a signal existing somewhere ?
When I needed it, I just added a listener to the repr of the pref setting, and was notified whenever that setting is changed by no matter who. E.g. look into the tool style indicator (at the right end of control bars of object-creating tools).
Did you attach the new_child to the_parent?
Yes, the complete code is: bool create_pref(gchar const *father_path, gchar const *child){ Inkscape::XML::Node *father = inkscape_get_repr(INKSCAPE, father_path); if (! father ) return false; Inkscape::XML::Node *repr = father->document()->createElement("group"); sp_repr_set_attr(repr, "id", child); repr->_setParent(father); return true; }
Another different topic, I need a way to be notified that a setting has been
changed from the toolbox. I such a signal existing somewhere ?
When I needed it, I just added a listener to the repr of the pref setting, and was notified whenever that setting is changed by no matter who. E.g. look into the tool style indicator (at the right end of control bars of object-creating tools).
The problem is that I do not want to be notified when the change comes from the profile, because I want tot change the combo to "No Preset" when the value is changed: If i do it this way, changing the preset will trigger the "change" value and reset the combo to no preset... So unless I mark somewhere (e.g. an ugly static flag) the change comes from the preset combo and check when I come back and do nothing in this case, I need to find another way.
On Wed, Mar 19, 2008 at 5:50 AM, Aubanel MONNIER
repr->_setParent(father);
I think you need to use
parent->appendChild(child);
instead of this
"change" value and reset the combo to no preset... So unless I mark somewhere (e.g. an ugly static flag) the change comes from the preset combo and check when I come back and do nothing in this case, I need to find another way.
Well, all the controls in the bar have their callbacks - so you can just add a call like update_presets_list to each such callback.
By the way, please make sure that presets store not only numeric params but also the boolean state of the buttons such as use pressure sensitivity and trace background. It's an important part of the tool behavior as well.
2008/3/19, bulia byak <buliabyak@...400...>:
On Wed, Mar 19, 2008 at 5:50 AM, Aubanel MONNIER
repr->_setParent(father);I think you need to use
parent->appendChild(child);
instead of this
Yes, it works ! Where should I look for sample popup code ?
"change" value and reset the combo to no preset... So unless I mark
somewhere (e.g. an ugly static flag) the change comes from the preset
combo
and check when I come back and do nothing in this case, I need to find another way.
Well, all the controls in the bar have their callbacks - so you can just add a call like update_presets_list to each such callback.
Mmmh, I should have guessed that, thanks.
By the way, please make sure that presets store not only numeric
params but also the boolean state of the buttons such as use pressure sensitivity and trace background. It's an important part of the tool behavior as well.
At first I was against that, but a second thought makes me feel you are right, so I'll do it.
I just committed more of this stuff. Feel free to test and give some feedback. I need some help on the todos:
+Added a No Preset entry +Made save button and save functionality +Changing settings switches back the preset combo to No Preset
Internals: +added several functions in pref-utils: add child-pref, get list of children, number of children +added a function to retrieve the model from egeActionSelectOne
Todos: +when a profile is selected, the save button should be a delete button that deletes the current profile (is it possible to toggle between two actions ? or should I manually change the icon, the tool-tips and the callback ?) +find a way to (re)name new profiles (is there a popup dialog sample somewhere? Sorry, I'm a GTK newbie) +find a way to get unique ids (are ids mandatory in preferences anyway ?)
On Wed, Mar 19, 2008 at 12:49 PM, Aubanel MONNIER <aubanel@...400...> wrote:
+Added a No Preset entry +Made save button and save functionality +Changing settings switches back the preset combo to No Preset
That all works great, thanks!
+when a profile is selected, the save button should be a delete button that deletes the current profile (is it possible to toggle between two actions ?
I'm not sure it's good usability to switch a button. If you don't want to make them two menu items in the menu, let's have two buttons.
+find a way to (re)name new profiles (is there a popup dialog sample somewhere? Sorry, I'm a GTK newbie)
No need to provide a rename function I think; instead, when you create a new preset, ask for a name. You can use a dialog similar to that which asks for the name of a new layer.
+find a way to get unique ids (are ids mandatory in preferences anyway ?)
Not sure about this one, at least in SVG repr tree you don't need to set an id yourself, it will be added automatically - maybe it's the same in prefs?
+when a profile is selected, the save button should be a delete button
that
deletes the current profile (is it possible to toggle between two
actions ?
I'm not sure it's good usability to switch a button. If you don't want to make them two menu items in the menu, let's have two buttons.
Which menu are you talking about ? I tried to implement a contextual menu on the selector but the rigth click event is eaten by the selector, so I reverted that. I am not a fan of 2 "exclusive" buttons, it just eats space for nothing. And I dont like the save icon being present really close from the standard menu either. Any idea on how to solve this GUI issue is welcome.
+find a way to (re)name new profiles (is there a popup dialog sample
somewhere? Sorry, I'm a GTK newbie)
No need to provide a rename function I think; instead, when you create a new preset, ask for a name. You can use a dialog similar to that which asks for the name of a new layer.
Done and committed. Please test.
+find a way to get unique ids (are ids mandatory in preferences anyway ?)
Not sure about this one, at least in SVG repr tree you don't need to set an id yourself, it will be added automatically - maybe it's the same in prefs?
OK, I forget about that.
Aubanel.
On Fri, Mar 21, 2008 at 11:51 AM, Aubanel MONNIER <aubanel@...400...> wrote:
I'm not sure it's good usability to switch a button. If you don't want to make them two menu items in the menu, let's have two buttons.
Which menu are you talking about ?
Why, the same menu which lists the presets, of course. Just add a separator at the end and after it, the save and delete commands.
I am not a fan of 2 "exclusive" buttons, it just eats space for nothing. And I dont like the save icon being present really close from the standard menu either.
Sure, that's why I'm proposing to reuse the menu for that.
On Mar 19, 2008, at 8:49 AM, Aubanel MONNIER wrote:
+find a way to get unique ids (are ids mandatory in preferences anyway ?)
In the preferences, those 'id' attributes aren't really Id's, unlike in SVG itself.
Basically id attributes in prefs are not required to be unique in the whole document, but to be able to access things they probably need to be unique within a given parent.
participants (4)
-
Alexandre Prokoudine -
Aubanel MONNIER -
bulia byak -
Jon A. Cruz