Created attachment 111225 [details] shapes sidebar pane in wps presentation It would be useful to integrate the entire collection of drawing functions from the drawing toolbar into a sidebar pane. This would be most useful in impress, as it would free up the space taken at the bottom of the UI by the toolbar.
Hi Jay, The tool bar will stay? It has the possibility to draw toolbars out of it, so have a separate floating toolbar for e.g. lines, shapes, .. Cheers, Cor
(In reply to Jay Philips from comment #0) > It would be useful to integrate the entire collection of drawing functions > from the drawing toolbar into a sidebar pane... @Jay, hate to harp on the semantics of it, but you are asking for a new Sidebar Tab and associated Content panel(s) holding buttons from the drawing toolbar (and associated .uno actions) to place in the Sidebar Deck... Otherwise though, this is a logical addition to the Sidebar (In reply to Cor Nouws from comment #1) > The tool bar will stay? It has the possibility to draw toolbars out of it, > so have a separate floating toolbar for e.g. lines, shapes, .. Yes, toolbar would have to remain, but probably not in view by default. That is until work on bug 85905, and similar, to allow multiple sidebar "content panels" to be undocked and active. Currently with content panels for only a single tab active in the sidebar deck we have to retain toolbars. If multiple sidebar content panels could be undocked and active--we reduce the need for toolbars.
@Cor, yes the drawing toolbar would be hidden by default if the shapes tab was available in the toolbar. @Stuart, yep thats the idea, shapes tab with shape type/group content panels. :D Reading through the various comments that came in through the recent survey done by me and Heiko for impress, many users want a less cluttered UI. One user had expressed the reduction in the number of toolbars and i felt that if we could eliminate the second top toolbar row and drawing toolbar, there would be alot more room for the slide and sidebars and less clutter. From my testing so far, i believe we could easily eliminate the second top toolbar, as all its features are in the sidebar and in the context menu, but the only way to eliminate the drawing toolbar is to get its features into the sidebar.
Hello, IMHO a sidebar is too overkill Just an idea inspired by basic shape dropdown in standard toolbar, how if instead of just basic shape it changed to show all available shape preferably grouped and have recently used. this is how MSWord insert toolbar is. this way drawing toolbar can be hidden and user doesnt need to change sidebar pane back and fort between properties and shape if they want to draw and change properties
Created attachment 113016 [details] MS word insert shape
(In reply to Viko Adi Rahmawan from comment #4) > Just an idea inspired by basic shape dropdown in standard toolbar, > how if instead of just basic shape it changed to show all available shape > preferably grouped and have recently used. > this is how MSWord insert toolbar is. The creation of a split/drop down button for shapes has been suggested in bug 84350. > this way drawing toolbar can be hidden and user doesnt need to change > sidebar pane back and fort between properties and shape if they want to draw > and change properties This argument was discussed in bug 84350 as well and having a constantly visible toolbar or sidebar when you need to add multiple different shapes has an advantage over a split/drop-down button. The design team discussed last week about this sidebar panel and Kendy suggested that the sidebar tab also have the ability to set the shape's area and border colors from the sidebar, which is possible to set in the line and filling toolbar before a shape is drawn. So it would be useful to copy the 'fill' entry from the area properties section and the 'width' and 'color' entries from the line properties section, and these entries would only effect newly drawn shapes.
(In reply to V Stuart Foote from comment #2) > Yes, toolbar would have to remain, but probably not in view by default. That > is until work on bug 85905, and similar, to allow multiple sidebar "content > panels" to be undocked and active. Currently with content panels for only a > single tab active in the sidebar deck we have to retain toolbars. If > multiple sidebar content panels could be undocked and active--we reduce the > need for toolbars. Maybe. Let's again look at then when the side bar issues are implemented and used for some time. An advantage of the toolbar and panels is that you can drag the two/three that you need and float them where needed. really makes working faster an reduces mouse movement.
Created attachment 113059 [details] calligra flow's stensil box I've attached a screenshot of how Calligra's flowchart app has its shapes and in its other sidebar, you can see the settings for the shape fill and border. Another flowchart app, Dia, also has a sidebar section for shapes, and also has a shape fill and border section below it which has a foreground and background color section which resembles gimp. http://dia-installer.de/screenshots/highslide/images/large/diagerman.jpg You can also see in this video tutorial of Draw, that the author takes out the shape drop down menus, so that he doesnt have to reopen the drop down menus each time he needs to grab another shape, which is a similar benefit of having it in its own sidebar tab. https://www.youtube.com/watch?v=BdJOq63FiAA&list=PL47827064C2B32CCA&index=3
Hi Jay, thanks for the examples. I guess I've already indicated that IMO an advantage of the floating toolbars is the flexibility in positioning of the relatively tiny elements. Apart from that: when implementing them in the side bar, pls don't forget the functionality with Ctrl and double click. Then when we are that far it's fine for me how happy we are with possibly removing current tool bar. Ciao,
Created attachment 113725 [details] inkscape symbols tab
Created attachment 114363 [details] insert shapes properties tab section Seems that there used to be a 'insert shapes' section in LibO 4.2 which was likely removed.
It is impossible to drag the toolbar Drawing to a new position in master? Version: 4.5.0.0.alpha0+ Build ID: c3087d969671e62182eb049850479e77190ccff4 TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2015-03-22_02:33:12 Locale: nl_NL
(In reply to Cor Nouws from comment #12) > It is impossible to drag the toolbar Drawing to a new position in master? I had set it to be locked in bug 90244, so you'll have to right-click > Lock Toolbar Position to be able to drag it.
We had a design session today and the result can be found at https://docs.google.com/document/d/1Sv3Q-XdnHElYGXX2m8OLbRAy1zyodcU231Gn2SkVRV0/edit?usp=sharing
Kendy pointed out that the 'insert shapes' section was removed from the properties tab because it doesnt below to properties (bug 73070), but it can be used as a basis for a shapes tab. http://cgit.freedesktop.org/libreoffice/core/commit/?id=7cd90162f1c4a1d763e40c8f9972fd59e219ccd1
Update of component -> Draw and keyword -> needsUXEval.
I've started to work on this, and would like a few more details. 1. The sidebar layout - talked to bubli and she suggested that accordion would take up too much time to code (rest of the summer). So any decision on which layout to be finally used would be appreciated. 2. Does this involve adding new native shapes to Draw? (not talking about user defined ones) 3. As for user adding shapes, does it involve drag & drop or just the Add button on the top right? More question to follow as I progress.
(In reply to Susobhan Ghosh from comment #17) > 1. The sidebar layout - talked to bubli and she suggested that accordion > would take up too much time to code (rest of the summer). So any decision on > which layout to be finally used would be appreciated. The file & folder layout similar to the gallery. > 2. Does this involve adding new native shapes to Draw? (not talking about > user defined ones) No new natives shapes. > 3. As for user adding shapes, does it involve drag & drop or just the Add > button on the top right? Drag and drop would be good, its works for the gallery, and would allow users to create something in LO and easily export it to the shapes deck. > More question to follow as I progress. Look forward to them at the design meetings.
(In reply to Yousuf (Jay) Philips from comment #18) > (In reply to Susobhan Ghosh from comment #17) > > 1. The sidebar layout - talked to bubli and she suggested that accordion > > would take up too much time to code (rest of the summer). So any decision on > > which layout to be finally used would be appreciated. > > The file & folder layout similar to the gallery. The folder/file interaction hides options behind a selection, and that's not what we defined in the HIG. So how about an "ascordion" with fix sections? Im mean a panel with caption without the additonal features to expand/collapse. Isn't this easy to achieve? (In reply to Susobhan Ghosh from comment #17) > 2. Does this involve adding new native shapes to Draw? (not talking about > user defined ones) > > 3. As for user adding shapes, does it involve drag & drop or just the Add > button on the top right? You can easily drag'n drop drawings to the gallery (start on long press on the shape(s)/group). No need to do the same for basic shapes. We could also ignore the user-defined shapes.
How is the search functionality supposed to work out in the file/folder layout? The categories are hidden accordingly as per the results and the results are spread across categories? Or the categories remain static, and the results show up in the shapes pane below (all results)?
(In reply to Heiko Tietze from comment #19) > The folder/file interaction hides options behind a selection, and that's not > what we defined in the HIG. So how about an "ascordion" with fix sections? > Im mean a panel with caption without the additonal features to > expand/collapse. Isn't this easy to achieve? Not sure how that was defined in the HIG, but would disagree with it as we have various things that are hidden behind an initial selection everywhere in the UI. The "ascordion" wouldnt be a good option as it would be a huge list of open sections that a user would have to scroll through. (In reply to Susobhan Ghosh from comment #20) > How is the search functionality supposed to work out in the file/folder > layout? The categories are hidden accordingly as per the results and the > results are spread across categories? Or the categories remain static, and > the results show up in the shapes pane below (all results)? I would assume a search results category would appear in the folder list and the resulting files would be listed in there.
(In reply to Yousuf (Jay) Philips from comment #21) > The "accordion" wouldnt be a good option as it would be a huge > list of open sections that a user would have to scroll through. Check out the examples you put into the whitepaper. Most competitors do so and keep sections open.
Created attachment 125949 [details] Mockup for basic shapes in the sidebar Susobhan's idea is to add a tab to the sidebar which holds the basic shapes only. The advantage is to get rid of the drawing toolbar in Draw, and the lengthy menu in Writer > Insert > Shape would have a redundant interaction. According the design session from comment 14 we have two options: 1) the shape categories (Lines & Arrows, Curve, Connector, Basic Shapes, Symbol Shapes...) are shown as content panels with the actual shapes as content; 2) the category is being selected first from a list and the shapes are shown in respect to this selection. My preference is #1 because of the clean layout and the one-click interaction. Advantage of #2 is the conformity with the current gallery (that should be reworked according #1, though). The search is not easy to implement. While collapsing panels and hiding items that do not match the search/filter criteria would be nice, this code is very difficult. Therefore the mockup just disable (dim) the non-fitting shapes. Anyway, the number of shapes is not that high and this filter would rather be the prototype for the gallery.
(In reply to Heiko Tietze from comment #22) > Check out the examples you put into the whitepaper. Most competitors do so > and keep sections open. Yes calligra, visio 2007, yEd and lucidchart have accordians with contractible sections, but none have them always open, which is what you were proposing in comment 19. Inkscape, dia, and visio 2010 use the folder/file approach. (In reply to Heiko Tietze from comment #23) > Susobhan's idea is to add a tab to the sidebar which holds the basic shapes > only. The advantage is to get rid of the drawing toolbar in Draw, and the > lengthy menu in Writer > Insert > Shape would have a redundant interaction. The main benefit that this sidebar deck is intended to have would be to contain non-basic shapes that arent in the drawing toolbar for use in Draw, so that Draw can be more useful. Having the basic shapes as a separate content panel in the deck would make useful for those who dont want to use the drawing toolbar in modules where shapes arent a primary part of the functionality (i.e. writer, excel). Even with basic shapes in the deck, that wouldnt eliminate the reason to have them in the Insert > Shape menu. We maybe misunderstand each other when it comes to the design because we might be talking about different content panels of the deck. My approach to the design of the deck is the programmably viable style with a 'default' content panel of basic shapes which would be scrollable to fit all the shapes (similar to wps's shapes sidebar) and a folder/file design for the 'more' content panel, with or without a search capability.
(In reply to Yousuf (Jay) Philips from comment #24) > The main benefit that this sidebar deck is intended to have would be to > contain non-basic shapes that arent in the drawing toolbar for use in Draw, > so that Draw can be more useful. Having the basic shapes as a separate > content panel in the deck would make useful for those who dont want to use > the drawing toolbar in modules where shapes arent a primary part of the > functionality (i.e. writer, excel). Even with basic shapes in the deck, that > wouldnt eliminate the reason to have them in the Insert > Shape menu. > > We maybe misunderstand each other when it comes to the design because we > might be talking about different content panels of the deck. My approach to > the design of the deck is the programmably viable style with a 'default' > content panel of basic shapes which would be scrollable to fit all the > shapes (similar to wps's shapes sidebar) and a folder/file design for the > 'more' content panel, with or without a search capability. Yes, I guess we do misunderstand each other. This is what I understood from what you clarified: 2 panels - one with basic shapes (without search, just like WPS), and an 'more' panel with a file/folder layout (with/without Search). Am I correct? If I am, can you clarify what is the purpose of the 'more' content panel?
(In reply to Heiko Tietze from comment #23) > Susobhan's idea is to add a tab to the sidebar which holds the basic shapes > only. The advantage is to get rid of the drawing toolbar in Draw, and the "basic shapes only" here means all the ones from the tool bar?
(In reply to Cor Nouws from comment #26) > "basic shapes only" here means all the ones from the tool bar? Yes, the sidebar would be an alternative to the drawing toolbar (talking Draw).
(In reply to Susobhan Ghosh from comment #25) > Yes, I guess we do misunderstand each other. This is what I understood from > what you clarified: 2 panels - one with basic shapes (without search, just > like WPS), and an 'more' panel with a file/folder layout (with/without > Search). Am I correct? Yes correct. > If I am, can you clarify what is the purpose of the 'more' content panel? It is to provide non-builtin shapes that are common in diagram apps. These shapes will be stored in files, similar to how we have it for the gallery.
Susobhan Ghosh committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ab9708e179762f97bd1a0ee4c0d4b439f1dabfd5 tdf#87643: Default Shapes Panel for Shapes Deck It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Susobhan Ghosh committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=44216ddbc620a1c05e98dda1f63ed6df0eae5275 tdf#87643: Make Shapes Deck experimental It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Setting Assignee back to default. Please change it back if you're still working on this issue
A polite ping to Susobhan Ghosh: is this bug fixed? if so, could you please close it as RESOLVED FIXED ? Thanks
(In reply to Yousuf Philips (jay) from comment #14) > We had a design session today and the result can be found at > > https://docs.google.com/document/d/1Sv3Q- > XdnHElYGXX2m8OLbRAy1zyodcU231Gn2SkVRV0/edit?usp=sharing Just for reference, the published version of this design session is here, https://user-prompt.com/libreoffice-design-session-shapes/ and which shapes/stencils are most important to users can be seen on that page by clicking the 'View Results' link, as well as here. https://design.blog.documentfoundation.org/2016/04/01/the-many-faced-god-part-2-how-libreoffice-draw-is-expected-to-evolve/
Let's close as fixed. There might be follow-up issues but we do have a shapes deck now.
It is fixed. Verified in Version: 7.1.3.2 / LibreOffice Community Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1 CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded