As Draw is supposed to be drawing application, its UI should look similar to applications like Dia, Calligra Flow, Krita, Inkscape and GIMP. UI Features In These Apps: 1) Single row top toolbar 2) Left column toolbar of drawing tools 3) Right sidebar with properties With this basic UI, i've rearranged Draw's UI to look similar to this ( http://i.imgur.com/M1k9DHT.png ). In order to fully implement this redesign, the sidebar needs a new Pages tab to take the place of the current right side Pages pane.
(In reply to Jay Philips from comment #0) > As Draw is supposed to be drawing application, its UI should look similar to > applications like Dia, Calligra Flow, Krita, Inkscape and GIMP. One word: fallacy. > 2) Left column toolbar of drawing tools Ack. > […] the sidebar needs a new Pages tab to take the place of the current > right side Pages pane. The sidebar is meant to contain contextual properties, not main navigation. Any page selector must be on the left. See also https://techbase.kde.org/Projects/Usability/HIG/Patterns/NavigationPatterns#Patterns_for_a_flat_content_structure
Created attachment 114180 [details] what the new UI is intended to look like So i went through the OOo stats to see what buttons are highly used have finalized on the currently attached UI. So with this UI, the toolbars have been stripped from formatting options and those options will be exclusively accessible in the sidebar, like what was done for impress.
@Kendy: Seems i need code pointers on how to set the width of the page pane, as well as setting it to be hidden.
Mock up is fine, but beleive we should also attempt to establish additional unimplemented drawing controls (brushes, pattern fills, erasure, masking, stamps, .etc) in the "drawing tools" pane. As I've mentioned, Draw should have a Page tab in the Sidebar for doing layout and design. But moving PDF and other "page previews" into a Sidebar "Pages" content panel on the *Right* would not necessarily be the best UX. Draw and filter import to .ODG is the primary module for handling PDF--the current *Left* Side pages pane provides the navigation of PDF documents. Position on the *Left* in that role is what most users/programs are familiar with. Beleive the Pages preview pane in Draw uses the same Slides pane from Impress--could be that both will have to be reworked--either as Sidebar components, or as now as but as optional panes.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c5e012fc65403e960d7f7ab5a3da50f6a2d1c53a tdf#90090 - rearrange Draw's UI by moving around its toolbars It will be available in 4.5.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.
@Jay, first brush with tonight's build Version: 4.5.0.0.alpha0+ Build ID: 181feb38d95e25980b96c2f6802cc906410abb13 TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-03-19_23:38:28 Locale: en_US Vertical toolbar attached left is not that awkward, retaining the Pages view pane left and inboard feels comfortable. Will ask a few folks to test drive the new layout. A bit more of a jolt with the Breeze icons that somehow landed on the Start Center--despite default of Automatic--Tango.
(In reply to V Stuart Foote from comment #4) > Mock up is fine, but beleive we should also attempt to establish additional > unimplemented drawing controls (brushes, pattern fills, erasure, masking, > stamps, .etc) in the "drawing tools" pane. Yes it would be good to have as many vector drawing controls that are found in similar apps. > As I've mentioned, Draw should have a Page tab in the Sidebar for doing > layout and design. But moving PDF and other "page previews" into a Sidebar > "Pages" content panel on the *Right* would not necessarily be the best UX. My suggestion of having a pages tab in the sidebar relates to other similar apps having a layers section within the right sidebar. The only similar apps that have a pages pane/section in its left area is Calligra Flow and MS Publisher. http://upload.wikimedia.org/wikipedia/en/a/ad/Microsoft_Publisher_screenshot.png > Draw and filter import to .ODG is the primary module for handling PDF--the > current *Left* Side pages pane provides the navigation of PDF documents. > Position on the *Left* in that role is what most users/programs are familiar > with. Yes it is best to keep it on the left so that it is possible to navigate between pages and also work with properties of the sidebar at the same time. The pane just needs to be reduced to its smallest size, so there is more document area room, especially if the document is in landscape view. I would consider that having the pane in its enabled but hidden state is likely the best default view, as there isnt a need to see the pane when a document only has a single page in it. https://twitter.com/MrExcluded/status/560954394909241344 https://twitter.com/irnan9/status/573061569329827840 > Beleive the Pages preview pane in Draw uses the same Slides pane from > Impress--could be that both will have to be reworked--either as Sidebar > components, or as now as but as optional panes. Yes draw and impress share the same code, so the pane is the same between the two. It would be useful to have the right sidebar expanded by default. (In reply to V Stuart Foote from comment #6) > Vertical toolbar attached left is not that awkward, retaining the Pages view > pane left and inboard feels comfortable. Will ask a few folks to test drive > the new layout. Look forward to hear more feedback. :D Any code pointers on how to reduce the size of the pane?
(In reply to Jay Philips from comment #7) > ... I would > consider that having the pane in its enabled but hidden state is likely the > best default view, as there isnt a need to see the pane when a document only > has a single page in it. Agree, auto-toggle visible when document has more than one page/graphic would be reasonable handling of the Pages pane. Default page layout for new blank Draw documents should default to landscape. Import filters should still honor the image/graphic or document page structure of the incoming object of course. But with this major UI rework, now would be the time to shift to correct orientation for a default. And for Draw to be a more functional illustration tool, it does need additional vector and bitmap tools, as well as the ability to identify and manipulate the layers that make up an illustration, or document. But scope of that work would require considerable refactoring and development of additional widgets (beyond existing straight lines, bezier curves, and predefined shapes) within LO. Display and manipulation of current Layers and OLE might be possible sooner, and stacking/grouping/and visibility would be good candidate to display in a new Sidebar content panel. Also, near term, page/graphic layout for drawing (the current Page setup context menu dialog) would be a good set of controls to include in a a Content panel--the now empty/suppressed Properties perhaps--for the Sidebar in Draw.
(In reply to V Stuart Foote from comment #8) > Agree, auto-toggle visible when document has more than one page/graphic > would be reasonable handling of the Pages pane. Yep that sounds good. > Default page layout for new blank Draw documents should default to > landscape. Import filters should still honor the image/graphic or document > page structure of the incoming object of course. But with this major UI > rework, now would be the time to shift to correct orientation for a default. Yes if the default page orientation isnt the most suitable one then it should be changed but i dont see other related apps go for landscape over portrait. > And for Draw to be a more functional illustration tool, it does need > additional vector and bitmap tools, as well as the ability to identify and > manipulate the layers that make up an illustration, or document. But scope > of that work would require considerable refactoring and development of > additional widgets (beyond existing straight lines, bezier curves, and > predefined shapes) within LO. > > Display and manipulation of current Layers and OLE might be possible sooner, > and stacking/grouping/and visibility would be good candidate to display in a > new Sidebar content panel. Yes it would be good if LO had more of this functionality. Totally agree that the most important would likely be layers, so users dont have to deal with object arrangement through the toolbar or context menu and would be able to do simple manipulation (e.g. hiding a layer). > Also, near term, page/graphic layout for drawing (the current Page setup > context menu dialog) would be a good set of controls to include in a a > Content panel--the now empty/suppressed Properties perhaps--for the Sidebar > in Draw. Yes it would be good to have sections of the pages tab i suggested in bug 83830 (attachment 106594 [details]) to be shown in the properties pane for Draw, similar to the suggested background section for impress (bug 89466).
(In reply to Jay Philips from comment #9) > > Default page layout for new blank Draw documents should default to > > landscape. Import filters should still honor the image/graphic or document > > page structure of the incoming object of course. But with this major UI > > rework, now would be the time to shift to correct orientation for a default. > > Yes if the default page orientation isnt the most suitable one then it > should be changed but i dont see other related apps go for landscape over > portrait. > If we think of using Draw to prepare illustrations/graphics for use in other ODF documents, the Portrait orientation of the page/graphic is not optimal. It is made worse as the default size opens at Letter/A4 size. Practical truth is that most illustrations/graphics being prepared in Draw would benefit from a smaller default page/graphic size--either square as an Icon, or in Landscape mode. Proportioned to better place onto a document page as an OLE. Likewise for a illustration/graphic being prepared to place into an Impress presentation--Landscape graphics are more often needed than Portrait. Providing a cleaner UI (Sidebar content panel, and maybe tweak the context menu) to resize and orient the page/graphic size will help with that. Defaulting to Landscape would provide better UX by requiring less fuss at the start of the drawing session.
(In reply to V Stuart Foote from comment #10) > If we think of using Draw to prepare illustrations/graphics for use in other > ODF documents, the Portrait orientation of the page/graphic is not optimal. I'm of the opinion that each app/module is an independent piece and documents created in one can be placed in others, but i'd assume we dont make changes based on this possibility. It is possible for me to create the same illustrations in Impress that can be created in Draw because they are from the same code base. It is also possible for me to create similar illustrations in Writer and Calc, with the exception of not being able to have connectors. > Practical truth is that most illustrations/graphics being prepared in Draw > would benefit from a smaller default page/graphic size--either square as an > Icon, or in Landscape mode. Proportioned to better place onto a document > page as an OLE. Likewise for a illustration/graphic being prepared to place > into an Impress presentation--Landscape graphics are more often needed than > Portrait. With a square or landscape mode, how would turn out on a print out. > Providing a cleaner UI (Sidebar content panel, and maybe tweak the context > menu) to resize and orient the page/graphic size will help with that. Yes the most ideal thing is to have the sidebar page tab accessible so users can make the necessary changes they need. > Defaulting to Landscape would provide better UX by requiring less fuss at > the start of the drawing session. There will always be fuss at the starting of any drawing session (this happens to me in inkscape or gimp) to set the most optimal page size for whatever one is working on. @Heiko, Cor: What is your take on this.
Jay: It seems to me that the state of the panel is not saved. The implementation is in sd/source/ui/dlg/PaneChildWindows.cxx, it is the LeftPaneDrawChildWindow. The command to toggle that is .uno:LeftPaneDraw, which corresponds to SID_LEFT_PANE_DRAW git grep SID_LEFT_PANE_DRAW for the uses of that. PaneDockingWindow is the actual implementation of the page view I think, and is located in sd/source/ui/dlg/PaneDockingWindow.cxx. If we wanted to move it eg. to the sidebar (the 'real' one - the one on the right side), I think that's the class to work with.
Thanks Kendy for the code pointer. Hiding the page pane is out of my league but i was able shrink it. ;D The only thing remaining for this new rearrangement is to have the sidebar fully open, like it is in impress. Without it being fully open, users will wonder where to go to modify object properties.
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9b6b866c350f9900b3399214fcea550f282af2d0 tdf#90090 reduce the size of the right page/slide pane It will be available in 4.5.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.
(In reply to Jay Philips from comment #11) > @Heiko, Cor: What is your take on this. Isn't the default layout for most apps to have navigation left, properties right, and tools on top? And that's what graphic tools do as well with the mode selection at the left sidebar. We have two perspectives here: a) Draw is an independent application and should be compared with other graphic tools, and b) Draw is part of the LO suite mainly with supporting functions. In case of a) your proposal is debatable but for b) we should respect and favor consistency over modules. Whether or not you take the Zonk at option b), Draw is started inline from other LO apps and should work there as well. Personally, I don't like single row toolbar in general. Your toolbar contains of 25 items, many with multiple assignment and not categorized into a few sections. I'd agree when it was mostly on/off items, which makes sense since many settings are duplicated at the right sidebar. To make clear what I mean with categorization of toolbar items: The main menu has 9 top level items, one of them is File. The standard toolbar contains always of a couple of items from this files menu, I do not need to check those for a certain function. This section is followed by Edit functions.
(In reply to Heiko Tietze from comment #15) > Isn't the default layout for most apps to have navigation left, properties > right, and tools on top? And that's what graphic tools do as well with the > mode selection at the left sidebar. Most graphic tools do not have a left sidebar as they do not have multiple pages to a document, but have layers in a document which appears in the right sidebar. These layers can be grouped into folders which can be shown and hidden, so you wouldnt necessarily need multiple pages, especially when they are the exact same page dimension. > We have two perspectives here: a) Draw is an independent application and > should be compared with other graphic tools, and b) Draw is part of the LO > suite mainly with supporting functions. In case of a) your proposal is > debatable but for b) we should respect and favor consistency over modules. > Whether or not you take the Zonk at option b), Draw is started inline from > other LO apps and should work there as well. With LO having a shared codebase, documents created in a module can be added to another module's document. Calc, draw, and formula can all be started inline in writer. Even the unlisted chart app starts inline in writer. > Personally, I don't like single row toolbar in general. Your toolbar > contains of 25 items, many with multiple assignment and not categorized into > a few sections. I'd agree when it was mostly on/off items, which makes sense > since many settings are duplicated at the right sidebar. Yes it is still a work in progress of which buttons will be appearing in the top and left toolbars and once that has been done, it will should be easy to categorize them. > To make clear what I mean with categorization of toolbar items: The main > menu has 9 top level items, one of them is File. The standard toolbar > contains always of a couple of items from this files menu, I do not need to > check those for a certain function. This section is followed by Edit > functions. Didnt fully grasp this paragraph. Was looking around for more apps to see how they deal with multiple pages and corel draw displays pages similar to how calc has pages. https://engineering.case.edu/thinkbox/sites/engineering.case.edu.thinkbox/files/images/coreldraw.jpg One benefit of having it there is that we currently have a bar presently there with Layout, Controls, and Dimension Lines tabs, which i couldnt figure out how to use. :D Also saw that corel draw mixes the pages and layers into an object manager tab. http://www.hizliprogramindir.com/wp-content/uploads/2013/08/corel-draw-2.jpg http://www.cbscreative.com/corel/corel07/ProjectLayers.gif (In reply to Adolfo Jayme from comment #1) > > One word: fallacy. > Please explain why it is a fallacy to think of Draw as a drawing application. On the start center it says 'Draw Drawing'. :D
I asked a libreoffice video tutorial author who i regularly watch his videos as he's been doing them since 3.3 and here are his responses to questions i asked him related to this enhancement. @MichaelTFCG in draw, do you think landscape or portrait is the best default page view? @jphilipz I don’t have a preference, I will have to change it about 50 percent of the time either way. @MichaelTFCG in draw, would you like the option to have the left pages pane inside of the right sidebar @jphilipz Definetly, I think that is a great idea to put the pages pane inside of the sidebar. @jphilipz I would also leave it as its own window, for the anti-sidebar people.
Just noticed that draw/impress has a navigator tab and it does display the list of pages and objects but it doesnt have enough functionality in it to really be useful, but you can double click on a page to jump to that page. Ideally this would be integrated into the properties tab and provide more functionality like show/hiding of a shape, ability to rename a page and object, being sorted by arrangement, etc.
(In reply to Jay Philips from comment #18) > Just noticed that draw/impress has a navigator tab and it does display the > list of pages and objects but it doesnt have enough functionality in it to > really be useful, try it with object that have a name :)
(In reply to Cor Nouws from comment #19) > try it with object that have a name :) objects
(In reply to Cor Nouws from comment #19) > try it with object that have a name :) Objects with names didnt make a difference to the lack of functionality. I'm assuming you thought i didnt see anything objects there, but i did after i turned on Show Shapes > All Shapes. :D
(In reply to Jay Philips from comment #21) > (In reply to Cor Nouws from comment #19) > > try it with object that have a name :) > > Objects with names didnt make a difference to the lack of functionality. I'm > assuming you thought i didnt see anything objects there, but i did after i > turned on Show Shapes > All Shapes. :D In previous versions, the context menu of a shape offered the possibility to give a name and a description to that object. No idea why and where that has gone. If you open the navigator then the objects are visible per slide in the default setting. You can also choose to make all shapes visible (including text boxes) When there are more shapes on one slide, you can drag them to a different position for a different Z-order (tab order)
In LibreOffice 3.3.0 double clicking on a shape with a given name, does select it. Not in Master. Looks as if dragging shapes to change z-order is broken too in master?
(In reply to Cor Nouws from comment #22) > In previous versions, the context menu of a shape offered the possibility to > give a name and a description to that object. > No idea why and where that has gone. > If you open the navigator then the objects are visible per slide in the > default setting. > You can also choose to make all shapes visible (including text boxes) > When there are more shapes on one slide, you can drag them to a different > position for a different Z-order (tab order) Not sure which previous version that was, but when i checked 4.2 and 4.3, it acts the same way (no context menu), unnamed shapes are hidden by default, and no means of dragging them. (In reply to Cor Nouws from comment #23) > In LibreOffice 3.3.0 double clicking on a shape with a given name, does > select it. > Not in Master. > > Looks as if dragging shapes to change z-order is broken too in master? There wasnt a sidebar in Draw until 4.1, or am i missing something I've submitted a number of bugs/enhancements to help improve navigator: Bug 90241 - Objects should automatically be named when inserted Draw/Impress Bug 90242 - Navigator incorrectly naming, numbering and iconifying objects Bug 90244 - Make navigator function as like a layer management control
(In reply to Jay Philips from comment #24) > Not sure which previous version that was, but when i checked 4.2 and 4.3, it > acts the same way (no context menu), unnamed shapes are hidden by default, > and no means of dragging them. Then that functionality has been removed in a previous round of improvements. For easiness, I looked at 3.3.0. > There wasnt a sidebar in Draw until 4.1, or am i missing something I always refer to the stand alone Navigator to check functionality.
(In reply to Cor Nouws from comment #25) > I always refer to the stand alone Navigator to check functionality. Thanks. Totally forgot navigator has always been there. ;D
So Kendy was able to make the sidebar open by default in Draw. http://cgit.freedesktop.org/libreoffice/core/commit/?id=0bdfe0f946042cdd59468d96a756f28db7cac7fe And i've just completed, i'm hoping, the remaining fixes with this commit. https://gerrit.libreoffice.org/#/c/15483/
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ba4191c6986fa9fc5d22fa8203d8a986edfdcdaf tdf#90090 - customizing and positioning additional toolbars It will be available in 5.0.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.
With the patch in, the new basic UI look is complete, though there are some dependent bugs that need to be resolved for it to be fully complete.
This bug fix is mentioned in the release notes of the coming LibreOffice 5.0 (see release notes https://wiki.documentfoundation.org/ReleaseNotes/5.0). Therefore it would be wonderful if this feature really worked well, otherwise it should not be mentioned in the release notes. In the notes it reads: Rearrangement of toolbars in Draw tdf#90090 (Yousuf Philips)
Have just installed version 5 which includes this change. This change is a significant step back in usability since the toolbar, once docked, is not resizable nor does it have anything in it to allow scrolling. The extra tools not shown are available only through the double-arrow "extra" button, but when accessed that way, you cannot select anything but the default use of a tool. You can't, for example, access the different types of callouts in the callout tool.
Hi Kurt, (In reply to Kurt from comment #31) > Have just installed version 5 which includes this change. This change is a > significant step back in usability since the toolbar, once docked, is not > resizable nor does it have anything in it to allow scrolling. The toolbar is docked by default, but if you prefer it to be how it used to be, it is simple to dock it in its old position. > The extra > tools not shown are available only through the double-arrow "extra" button, > but when accessed that way, you cannot select anything but the default use > of a tool. You can't, for example, access the different types of callouts > in the callout tool. What screen resolution are you viewing at as no tools are hidden at my 1280x768 resolution. Would be useful if you provide a screenshot so it is easy to see what you see.
(In reply to Yousuf (Jay) Philips from comment #32) > The toolbar is docked by default, but if you prefer it to be how it used to > be, it is simple to dock it in its old position. I don't mind the new location. Just the lack of ability to scroll or resize it, but I suppose that's not related to this change. I never had cause to try to resize that toolbar before, so I didn't realize it never had been possible to. I thought that was also related to this change, but I see it's not so I apologize for putting here what is best discussed in a help forum. > What screen resolution are you viewing at as no tools are hidden at my > 1280x768 resolution. Would be useful if you provide a screenshot so it is > easy to see what you see. 1366x768 If you can display the entire drawing toolbar on that size of a screen there must be a trick to resizing the tools, which I'd also like to know. There are 30+ available tools.
Created attachment 118858 [details] 1366 x 768 view of toolbar with hidden tools
Created attachment 118863 [details] draw toolbar with no hidden tools (In reply to Kurt from comment #33) > I don't mind the new location. Just the lack of ability to scroll or resize > it, but I suppose that's not related to this change. I never had cause to > try to resize that toolbar before, so I didn't realize it never had been > possible to. I thought that was also related to this change, but I see it's > not so I apologize for putting here what is best discussed in a help forum. Unfortunately toolbars dont have a scrolling or resizing mechanism, so there isnt much that can be done about that. > 1366x768 > > If you can display the entire drawing toolbar on that size of a screen there > must be a trick to resizing the tools, which I'd also like to know. There > are 30+ available tools. Looking at your screenshot, i see that you enabled the insert image button in the drawing toolbar, which does cause additional tools to hide. The insert image button is available in the standard toolbar, so it isnt necessary to have it enabled there. In the default state of the toolbar, the stars and 3d objects buttons are hidden for me, but as i hide the zoom & pan button, as it isnt highly needed for me, all the buttons show up just fine. If i had an auto-hide panel and LO took up the full 768px height, i wouldnt need to hide the zoom & pan button for all the buttons to appear.
(In reply to Kurt from comment #31) > The extra > tools not shown are available only through the double-arrow "extra" button, > but when accessed that way, you cannot select anything but the default use > of a tool. You can't, for example, access the different types of callouts > in the callout tool. Did have that problem too at a certain moment. (In reply to Yousuf (Jay) Philips from comment #35) > Looking at your screenshot, i see that you enabled the insert image button > in the drawing toolbar, which does cause additional tools to hide. The > insert image button is available in the standard toolbar, so it isnt > necessary to have it enabled there. > > In the default state of the toolbar, the stars and 3d objects buttons are > hidden for me, but as i hide the zoom & pan button, as it isnt highly needed > for me, all the buttons show up just fine. If i had an auto-hide panel and > LO took up the full 768px height, i wouldnt need to hide the zoom & pan > button for all the buttons to appear. That is fine as stop gap solution, but wouldn't it be reasonable to expect it just to works in the way Kurt tried?
The issue comes from the LibO way of handling toolbars. The chevrons expand the remaining toolbar icons, and when it contains of a menu button the subordinate items are not shown anymore. That's one of the drawbacks of menu buttons in toolbars. Devs could solve it by adding a submenu- or the OP moves his toolbar to a horizontal dock.
Old bug with a quite generic topic. Furthermore, the assumption of being close to the listed tools is untenable https://design.blog.documentfoundation.org/2016/04/01/the-many-faced-god-part-2-how-libreoffice-draw-is-expected-to-evolve/ and https://design.blog.documentfoundation.org/2016/04/01/the-many-faced-god-part-1-how-libreoffice-draw-is-being-utilized/. Therefore I'll close the issue and recommend to file smaller tickets for small scale changes such as requests to reorder the toolbar(s).