Selection and Symbols
Dear Devs,
I'm still working on this UI update for symbols. It's mostly working now, with the exception of the UNSYMBOL verb which as originally implemented required a use element be selection which referenced the right symbol.
To fix this weirdness, I wanted to try out an idea. What if selecting a symbol in the TreeView on the right changed the currentDesktop->selection too. Then the verb could act on the selected item directly and as an added bonus, there's a conceptual way to select defs and maybe act on them in the future functionality or plugins (imagine a plugin that acted on a symbol, cool).
Only problem is, it also creates a bounding box on the canvas of where the group used to be, with transform handles and everything (which was fun to poke to see what would happen). Before I go down a rabbit hole, I wanted to check in with the team about what the best way to select items would be and if defs should or should not ever be selected in this manner (I'm looking at you xml-tree-editor).
Thanks for the advice,
Best Regards, Martin Owens
Hi Martin, im not a expert, but i made a experiment.
i open a svg file of simbols, center all to the page -could be a postproces to retain files for editing- Now all symbols can change whithout reposition, only changing his xlink:href. And this value of a selected symbol can be used to mark it in the symbol widget and if the user want chanche.
Im not sure if is related about your problem, and again sorry for my english. for now still in step 2lingo.
Hi, Jabier.
El jue, 13-06-2013 a las 01:33 -0400, Martin Owens escribió:
Dear Devs,
I'm still working on this UI update for symbols. It's mostly working now, with the exception of the UNSYMBOL verb which as originally implemented required a use element be selection which referenced the right symbol.
To fix this weirdness, I wanted to try out an idea. What if selecting a symbol in the TreeView on the right changed the currentDesktop->selection too. Then the verb could act on the selected item directly and as an added bonus, there's a conceptual way to select defs and maybe act on them in the future functionality or plugins (imagine a plugin that acted on a symbol, cool).
Only problem is, it also creates a bounding box on the canvas of where the group used to be, with transform handles and everything (which was fun to poke to see what would happen). Before I go down a rabbit hole, I wanted to check in with the team about what the best way to select items would be and if defs should or should not ever be selected in this manner (I'm looking at you xml-tree-editor).
Thanks for the advice,
Best Regards, Martin Owens
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Another cuestion could be good is strore in the Id of the symbol the category to switch window widget when selecting a use:symbol. Hi, Jabier.
El vie, 14-06-2013 a las 21:07 +0200, Jabiertxo Arraiza Cenoz escribió:
Hi Martin, im not a expert, but i made a experiment.
i open a svg file of simbols, center all to the page -could be a postproces to retain files for editing- Now all symbols can change whithout reposition, only changing his xlink:href. And this value of a selected symbol can be used to mark it in the symbol widget and if the user want chanche.
Im not sure if is related about your problem, and again sorry for my english. for now still in step 2lingo.
Hi, Jabier.
El jue, 13-06-2013 a las 01:33 -0400, Martin Owens escribió:
Dear Devs,
I'm still working on this UI update for symbols. It's mostly working now, with the exception of the UNSYMBOL verb which as originally implemented required a use element be selection which referenced the right symbol.
To fix this weirdness, I wanted to try out an idea. What if selecting a symbol in the TreeView on the right changed the currentDesktop->selection too. Then the verb could act on the selected item directly and as an added bonus, there's a conceptual way to select defs and maybe act on them in the future functionality or plugins (imagine a plugin that acted on a symbol, cool).
Only problem is, it also creates a bounding box on the canvas of where the group used to be, with transform handles and everything (which was fun to poke to see what would happen). Before I go down a rabbit hole, I wanted to check in with the team about what the best way to select items would be and if defs should or should not ever be selected in this manner (I'm looking at you xml-tree-editor).
Thanks for the advice,
Best Regards, Martin Owens
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sat, 2013-06-15 at 10:47 +0200, Jabiertxo Arraiza Cenoz wrote:
Another cuestion could be good is strore in the Id of the symbol the category to switch window widget when selecting a use:symbol.
I had a look at what extras selection provides. The ability to edit the Id/Name/Description of symbols, delete them, etc. Very interesting.
I think this is what you're saying.
Martin,
OK,
So I've just pushed all my changes for the symbols. Adding and removing symbols are now buttons in the symbols dialog. They still work from verbs, but I've removed the menu entries.
I think the replacement of the drop down options for size and fit with three buttons to 'zoom-in' 'zoom-out' and 'fit-toggle' should be reviewed by others here for ease of use and make sure they fit use cases.
The selection chemistry now means selecting symbols will dis-select your existing selection. But ti does mean you can operate on a symbol using any of the existing canvas functions.
Martin,
On Thu, 2013-06-13 at 01:33 -0400, Martin Owens wrote:
Dear Devs,
I'm still working on this UI update for symbols. It's mostly working now, with the exception of the UNSYMBOL verb which as originally implemented required a use element be selection which referenced the right symbol.
To fix this weirdness, I wanted to try out an idea. What if selecting a symbol in the TreeView on the right changed the currentDesktop->selection too. Then the verb could act on the selected item directly and as an added bonus, there's a conceptual way to select defs and maybe act on them in the future functionality or plugins (imagine a plugin that acted on a symbol, cool).
Only problem is, it also creates a bounding box on the canvas of where the group used to be, with transform handles and everything (which was fun to poke to see what would happen). Before I go down a rabbit hole, I wanted to check in with the team about what the best way to select items would be and if defs should or should not ever be selected in this manner (I'm looking at you xml-tree-editor).
Thanks for the advice,
Best Regards, Martin Owens
Hello Martin.
I attach too a svg of symbols all centered to the page, to see if is more easy switch a symbol whith this disposition.
My current branch give me this error when selecting a symbol.
** Message: need to add dynamic switch
Program received signal SIGSEGV, Segmentation fault. SPObject::label (this=0x0) at ../../simple-sketch/src/sp-object.cpp:432 432 return _label; (gdb) bt #0 SPObject::label (this=0x0) at ../../simple-sketch/src/sp-object.cpp:432 #1 0x000000000096ccea in Inkscape::SelectionDescriber::_updateMessageFromSelection (this=0x3110e60, selection=0x1e8db40) at ../../simple-sketch/src/selection-describer.cpp:157 #2 0x00000000004c25a5 in sigc::internal::signal_emit1<void, Inkscape::Selection*, sigc::nil>::emit (impl=0x3119fe0, _A_a1=@...2998...: 0x1e8db40) at /usr/include/sigc++-2.0/sigc++/signal.h:1010 #3 0x00000000004c12f2 in emit (_A_a1=@...2998...: 0x1e8db40, this=<optimized out>) at /usr/include/sigc++-2.0/sigc ++/signal.h:2781 #4 Inkscape::Selection::_emitChanged (this=0x1e8db40, persist_selection_context=<optimized out>) at ../../simple-sketch/src/selection.cpp:108 #5 0x000000000082022c in Inkscape::UI::Dialog::SymbolsDialog::iconChanged ( this=0x6c51a00) at ../../simple-sketch/src/ui/dialog/symbols.cpp:413 #6 0x00007ffff5212748 in Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) () from /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1 #7 0x00007ffff04ef6e0 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #8 0x00007ffff0500966 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #9 0x00007ffff05086bc in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #10 0x00007ffff0508852 in g_signal_emit () ---Type <return> to continue, or q <return> to quit--- from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #11 0x00007ffff6965a8a in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #12 0x00007ffff6988099 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #13 0x00007ffff04ef6e0 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #14 0x00007ffff05004d0 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #15 0x00007ffff05082db in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #16 0x00007ffff0508852 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #17 0x00007ffff6a9f93e in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #18 0x00007ffff6986434 in gtk_propagate_event () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #19 0x00007ffff698678b in gtk_main_do_event () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #20 0x00007ffff65f37ac in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 #21 0x00007fffeff37355 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 ---Type <return> to continue, or q <return> to quit--- #22 0x00007fffeff37688 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #23 0x00007fffeff37a82 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #24 0x00007ffff6985797 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #25 0x000000000046f6bb in sp_main_gui (argc=1, argv=0x7fffffffe438) at ../../simple-sketch/src/main.cpp:1022 #26 0x00007fffef1c6ead in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #27 0x000000000046c631 in _start ()
El sáb, 15-06-2013 a las 09:34 -0400, Martin Owens escribió:
OK,
So I've just pushed all my changes for the symbols. Adding and removing symbols are now buttons in the symbols dialog. They still work from verbs, but I've removed the menu entries.
I think the replacement of the drop down options for size and fit with three buttons to 'zoom-in' 'zoom-out' and 'fit-toggle' should be reviewed by others here for ease of use and make sure they fit use cases.
The selection chemistry now means selecting symbols will dis-select your existing selection. But ti does mean you can operate on a symbol using any of the existing canvas functions.
Martin,
On Thu, 2013-06-13 at 01:33 -0400, Martin Owens wrote:
Dear Devs,
I'm still working on this UI update for symbols. It's mostly working now, with the exception of the UNSYMBOL verb which as originally implemented required a use element be selection which referenced the right symbol.
To fix this weirdness, I wanted to try out an idea. What if selecting a symbol in the TreeView on the right changed the currentDesktop->selection too. Then the verb could act on the selected item directly and as an added bonus, there's a conceptual way to select defs and maybe act on them in the future functionality or plugins (imagine a plugin that acted on a symbol, cool).
Only problem is, it also creates a bounding box on the canvas of where the group used to be, with transform handles and everything (which was fun to poke to see what would happen). Before I go down a rabbit hole, I wanted to check in with the team about what the best way to select items would be and if defs should or should not ever be selected in this manner (I'm looking at you xml-tree-editor).
Thanks for the advice,
Best Regards, Martin Owens
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sat, 2013-06-15 at 23:10 +0200, Jabiertxo Arraiza Cenoz wrote:
My current branch give me this error when selecting a symbol.
I found this error too, thanks for reporting I've committed the right fix. Please test again and let me know if it works for you.
Martin,
Sorry Martinn I see a fix. compile and test again.
El sáb, 15-06-2013 a las 09:34 -0400, Martin Owens escribió:
OK,
So I've just pushed all my changes for the symbols. Adding and removing symbols are now buttons in the symbols dialog. They still work from verbs, but I've removed the menu entries.
I think the replacement of the drop down options for size and fit with three buttons to 'zoom-in' 'zoom-out' and 'fit-toggle' should be reviewed by others here for ease of use and make sure they fit use cases.
The selection chemistry now means selecting symbols will dis-select your existing selection. But ti does mean you can operate on a symbol using any of the existing canvas functions.
Martin,
On Thu, 2013-06-13 at 01:33 -0400, Martin Owens wrote:
Dear Devs,
I'm still working on this UI update for symbols. It's mostly working now, with the exception of the UNSYMBOL verb which as originally implemented required a use element be selection which referenced the right symbol.
To fix this weirdness, I wanted to try out an idea. What if selecting a symbol in the TreeView on the right changed the currentDesktop->selection too. Then the verb could act on the selected item directly and as an added bonus, there's a conceptual way to select defs and maybe act on them in the future functionality or plugins (imagine a plugin that acted on a symbol, cool).
Only problem is, it also creates a bounding box on the canvas of where the group used to be, with transform handles and everything (which was fun to poke to see what would happen). Before I go down a rabbit hole, I wanted to check in with the team about what the best way to select items would be and if defs should or should not ever be selected in this manner (I'm looking at you xml-tree-editor).
Thanks for the advice,
Best Regards, Martin Owens
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 2013-06-15 15:34 +0100, Martin Owens wrote:
The selection chemistry now means selecting symbols will dis-select your existing selection. But ti does mean you can operate on a symbol using any of the existing canvas functions.
Testing r12378:
- Ignores document structure
Selecting a symbol in the symbol dialog ('Current Document') not only deselects everything, it also switches the current drawing level to 'root'. Any symbol dropped on the canvas will be forced to go into 'root', too. This makes the dialog to manage symbols of the current document impractical to use with any decently structured document (layers + (nested) groups).
- How to edit/update an existing symbol?
It used to be possible to select an instantiated symbol (aka clone) on-canvas (IMvHO there's nothing "wierd" about that), convert it into a group, edit the contents with regular tools on-canvas (e.g. unset certain attributes of child elements carefully to be able to style instances individually, node-edit objects or add new ones to the group), and then convert the group back to a symbol. The result was that other instances of the original symbol got updated immediately, even while editing the group (the instances aka clones referencing the group container instead of the <symbol> definition).
Now (r12378), one only has the option to "remove" a symbol which is selected in the dialog itself. As a result, all existing instances disappear from the canvas (they get converted into empty <g> objects, without a method to clean them up either). A copy of the original symbol is appended to document root as group which then can be edited with regular tools on-canvas.
Adding the modified group back as symbol to the current document does not restore the references in prior instances of the original symbol: they are simply gone (turned into empty group containers in document root).
Thanks for the great testing suv,
...
On Sun, 2013-06-16 at 11:29 +0200, ~suv wrote:
- Ignores document structure
I've just pushed r12379. Which should fix the layer/group problem described, it's possible to drag or paste the symbol into which ever layer or group was last selected. The dis-selection is intentional.
I also updated the info text while I was there so it doesn't say symbols are in root and instead says they're "hidden in definitions" (not sure about the text, but we can always change it).
- How to edit/update an existing symbol?
What was weird about the previous workflow was just the menu and out-of-context of it. The workflow for editing would be the same, if only those bugs you so rightly point out were fixed. There's an odd race-type condition when it makes the new group and re-assigns the id, struggling between unlinking all the use elements and keeping them linked to the new group element.
The difference is that now you select the symbol, remove that from defs and back onto the canvas for editing and you don't need any use elements in order to do so.
I'll get this race-bug fixed ASAP.
Thanks again!
Martin,
participants (3)
-
Jabiertxo Arraiza Cenoz -
Martin Owens -
~suv