search

kimoa / svg-edit

Automatically exported from code.google.com/p/svg-edit
MIT License
3 stars 0 forks source link

Need Support for custom tool palettes in right hand panel #921

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
We need the ability to include custom tool palettes in svg-edit, see attached 
for a screen shot of the result. We opted to place them below the layers panel 
because this seemed like the obvious spot for this kind of enhancement.

Attached is a patch that includes a simple demo of the features in use. Also, 
this patch included changes to css so I tested it in 17.0.693.66, Firefox 7.0.1 
and IE 9. Everything behaves as expected. I don't have easy access to IE8 but 
could drop my IE version down if necessary.

Original issue reported on code.google.com by adamben...@gmail.com on 6 Mar 2012 at 10:58

Attachments:

GoogleCodeExporter commented 8 years ago 
It is also worth asking the question if these palettes should use some other 
mechanism other than addExtension to register themselves. I played with the 
idea of dom injection etc. but that can make using things like jquery a little 
unhappy because large chunks of the dom potentially aren't present at init 
time. At the moment putting your palette into the svg-editor directly and then 
using addExtension to hook relevant events seems to work well enough for my 
purposes but want to hear someone else's opinion.

Original comment by adamben...@gmail.com on 7 Mar 2012 at 12:44

GoogleCodeExporter commented 8 years ago 
The way I do it now is pretty much the same -- by appending my custom "panel" 
(what I call them) below Layer panel. It'd be cool to have official support for 
this instead of injecting them which is pretty hackish.

My wish is that we can make use of jQ UI dialogs to undock these panels.

Original comment by asyazwan on 7 Mar 2012 at 3:08

Attachments:

GoogleCodeExporter commented 8 years ago 
Hi Adam,

Thanks for this idea.  I merged your patch to see how it works and had some 
questions.

1) I guess this is just a demo and not something you intentionally want me to 
merge? :)

2) You have two lines above the "Layers" line.  Can you get rid of those?

3) what is a palette in this context?  I'm familiar with color palettes, but 
you seem to be talking about generic panels of tools maybe?

4) by renaming the handle to "P a l e t t e s" what do we do about "L a y e r 
s"?  Do you think "Layers/Tools" would be better?

5) I don't think this will scale beyond adding one panel into the right-pane 
below Layers because scrolling is pretty annoying.  What about a tabbed pane in 
the right tray in which Layers is the starter tab?  That won't scale very far 
either but maybe would allow a couple more custom panels of tools...  I imagine 
we could have a sidetray.js module that handles this, with extension points 
(addTab()?) to add in the custom tools...

Making use of jQuery-UI sounds good too...

Original comment by codedr...@gmail.com on 17 Mar 2012 at 8:31

GoogleCodeExporter commented 8 years ago 
Thanks for taking a look at the patch my thoughts are inline.

Adam

Yes this is just a demo to make sure the new functionality is clear, that is 
unless you like the idea of a random alphabetic list of animals as a feature :)

No problem

Flint and I talked about this and, while I borrowed the term from photoshop I'm 
fine changing it back to 'panels'.

Well I'm thinking that ideally there will be several tools of which layers will 
be only one. For example in our app we will have 5-10 tool panels. So I'm not 
sure if layers needs top billing in this way, after all it is just another 
panel, albeit a quite complex one. So I guess my vote would be something 
slightly more generic, perhaps just tools?

I was thinking something more like an accordion layout that would allow more 
than one panel to be open at once or collapsed to save space. The CSS I put in 
should allow arbitrarily many of these each to expand t whatever height they 
need to and to dynamically add scrollbars as needed. Also, at some point it 
would be nice to have the concept of 'undocking' the panel to allow it to float 
out on the main canvas much like photoshop.

Jquery UI is quite nice, though lately like many I am enamored with bootstrap 
which uses Jquery underneath but has some nice properties when it comes to 
widget design. Either way should work well.

Original comment by adamben...@gmail.com on 18 Mar 2012 at 4:51

GoogleCodeExporter commented 8 years ago 
Here is a patch that renames toolpalette to just tool, I will follow with one 
that removes the line above layers.

Original comment by adamben...@gmail.com on 19 Mar 2012 at 11:06

Attachments:

GoogleCodeExporter commented 8 years ago 
Here is patch to remove tool divider from first tool in list.

Original comment by adamben...@gmail.com on 19 Mar 2012 at 11:12

Attachments:

GoogleCodeExporter commented 8 years ago 
It appears that I missed an important rename in the previous patch - namely the 
open/close handle so here is an appropriate patch to fix that as well.

Original comment by adamben...@gmail.com on 19 Mar 2012 at 11:14

Attachments:

GoogleCodeExporter commented 8 years ago 
The layers panel itself is really nice. Whoever designed it did a fantastic job 
with the UX, icons, etc. For our application, we're not very layer-centric. We 
do need a number of other tools/property panels to be more prominent. We'd like 
the layers panel to be one of many. Perhaps others have similar needs.

The current vertical "Layers" button that overlays the scroll bar is 
non-standard, so it's use is pretty confusing to people we've tested the UI on. 
Once it's open, it's beautiful!

In the context of multiple panels, it probably doesn't make sense for the 
tool/property panels on the right to say "Layers."

REQUIREMENTS:

1. Actions for each panel:
  Open
  Minimize
  Restore
  Resize
  Close

In the current svg-edit, there are two panels, layers on the right and the 
object properties on the top. The Layers button handles three of the actions 
mentioned above (no open or close actions). The object properties "panel" is 
always "open" depending on the current selection.

I think svg-edit should allow for flexibility in the open action. It could be a 
button up top, an item in the main svg-edit menu, a context menu, or something 
else. In the context of multiple panels, what would make sense for opening the 
layers panel? A good design should also work if the layers panel is the only 
panel. One idea for layers open action is to have a button on top (next to the 
SVG button).

Minimize, close, and resize should be standardized based on the container 
system.

2. Standard container system for panels

There are lots of current applications to look at for this.

Photoshop and Illustrator have the most flexible container system with their 
floating panels that have tabs and can "stack" panels. Tabs can be dragged and 
dropped from one floating panel to another. See:
http://4.bp.blogspot.com/-isUiId7AT0U/TmuRWwrXFzI/AAAAAAAAAWM/ghs-9PPsmcU/s1600/
photoshop+interface.jpg

Inkscape has a right panel that, when minimized, presents a vertical list of 
buttons. Click on a button to restore one panel. I'm not a big fan of this, but 
it does the job. Inkscape uses a standard split-bar to resize the panels. I do 
like this because it's standard behavior that most people expect.

I'll do a search on jQuery container systems and see what I can find. I'm 
hoping there's something easy and intuitive.

3. Resize all panels
We recommend a standard split bar of some kind with a standard "grab" knurling 
or open/close icons and no label.

Original comment by FlintOBr...@gmail.com on 20 Mar 2012 at 3:30

GoogleCodeExporter commented 8 years ago 
Flint/Adam - I'm totally behind making the right tray/panel completely 
configurable and agree with most of your suggestions, including over-hauling 
the button/handle/mechanism for opening it.  

I'm willing to accept any patches that start on this work.  However, since it's 
not a small project, I would like to have 2.6 officially released before 
bringing patches into the trunk.

Can we get 2.6 released (as in make it official, make a download package for it 
and do the branching described here: 
http://code.google.com/p/svg-edit/wiki/DevelopmentProcess) first?  I don't 
think releasing is a lot of work, but we do have to identify any remaining 
issues before doing it.  Maybe asyazwan has some time to work on this?

Original comment by codedr...@gmail.com on 20 Mar 2012 at 3:59

GoogleCodeExporter commented 8 years ago 
We'd like to see 2.6 released also. The right tray/panels should be post 2.6.

Original comment by FlintOBr...@gmail.com on 20 Mar 2012 at 4:11

GoogleCodeExporter commented 8 years ago 
I am also for 2.6 getting released, is there a checklist of things that is 
outstanding? Flint and I are on the clock for our employer most of the time we 
are working with svgedit. But I may have some spare time and if there was a 
well defined list of things we wanted rolled into 2.6 it would make it easier 
to get it all done.

Original comment by adamben...@gmail.com on 20 Mar 2012 at 4:41

GoogleCodeExporter commented 8 years ago 
Hello folks,

go to main issue page and type "Need" in the search box, an autocomplete will 
popup. Select 2.6. Or here is the link that I hope is working: 
http://code.google.com/p/svg-edit/issues/list?can=2&q=NeededFor%3D2.6+

I'll go through unlabeled issues if there are still anything urgent enough to 
warrant 2.6 label. Otherwise that's the final list and we should aim to get 
them fixed or change them to 2.7. My proposal is to set the dateline to end of 
this month.

--

As for this issue, I'm excited! I admit it took me a while to figure out the 
layer panel when I first started using SE. But let's focus our energy on 
shipping out 2.6, then branch off the stable version.

Original comment by asyazwan on 20 Mar 2012 at 5:56

GoogleCodeExporter commented 8 years ago

Original comment by bret...@gmail.com on 7 Apr 2014 at 3:38

GoogleCodeExporter commented 8 years ago

Original comment by bret...@gmail.com on 7 Apr 2014 at 3:45