[Libreoffice-ux-advise] [Bug 90090] Rearranging the UI of Draw
https://bugs.documentfoundation.org/show_bug.cgi?id=90090 --- Comment #15 from Heiko Tietze heiko.tie...@user-prompt.com --- (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. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90195] Hiding the menu bar
https://bugs.documentfoundation.org/show_bug.cgi?id=90195 V Stuart Foote vstuart.fo...@utsa.edu changed: What|Removed |Added CC||vstuart.fo...@utsa.edu --- Comment #2 from V Stuart Foote vstuart.fo...@utsa.edu --- @Jay, Assume you mean a simple toggle to show or hide the main menu once you have launched the StartCenter or then a module. As distinct from full page mode, Ctrl+Shift+j, where both main menu and toolbars are hidden. It would require a well publicized accelerator be assigned as a toggle, perhaps also something from the Ctrl+Shift block? And, would have to adjust for menu functions on OS X, or other DE that want to control menus. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90194] Make Breeze the new default in Windows and OS X
https://bugs.documentfoundation.org/show_bug.cgi?id=90194 --- Comment #3 from Heiko Tietze heiko.tie...@user-prompt.com --- Sifr: https://user-prompt.com/about-the-performance-of-the-sifr-icon-set/ Breeze: https://user-prompt.com/intermediate-results-of-the-icon-tests-breeze/ Resume: https://user-prompt.com/extracting-the-dna-of-icons/ (At the time of the survey the Breeze icon set was not known. And we didn't ask for the OS.) -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90195] Hiding the menu bar
https://bugs.documentfoundation.org/show_bug.cgi?id=90195 V Stuart Foote vstuart.fo...@utsa.edu changed: What|Removed |Added Status|UNCONFIRMED |NEEDINFO Ever confirmed|0 |1 -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90194] Make Breeze the new default in Windows and OS X
https://bugs.documentfoundation.org/show_bug.cgi?id=90194 V Stuart Foote vstuart.fo...@utsa.edu changed: What|Removed |Added Status|UNCONFIRMED |NEEDINFO CC||vstuart.fo...@utsa.edu Ever confirmed|0 |1 --- Comment #2 from V Stuart Foote vstuart.fo...@utsa.edu --- For OS X, might do to survey that group of users to compare Sifr and Breeze side by side. Agree, there is a case to be made for using Breeze on Windows 10, but so far too few preview users to take any reasonable measure. Tango probably is the less disagreeable for other Windows Desktops. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90195] Hiding the menu bar
https://bugs.documentfoundation.org/show_bug.cgi?id=90195 Jay Philips philip...@hotmail.com changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #3 from Jay Philips philip...@hotmail.com --- (In reply to Heiko Tietze from comment #1) In my opinion it's up to the OS or desktop environment how to handle main menu, window decoration, theming and colors (to make a Chuck Norris roundhouse kick). Yes the OS/DE is the one that decides to show or merge it with an existing panel, but ultimately the user is in control of how LO looks. Dont see this any different then the user being able to show/hide a toolbar or change the document background color to another color. (In reply to V Stuart Foote from comment #2) Assume you mean a simple toggle to show or hide the main menu once you have launched the StartCenter or then a module. As distinct from full page mode, Ctrl+Shift+j, where both main menu and toolbars are hidden. Yes a simple toggle when your in a module that takes the hiding idea from full page mode. It would require a well publicized accelerator be assigned as a toggle, perhaps also something from the Ctrl+Shift block? Ideally we'd have a toolbar button to do this like what is available in MSO and Google Docs, but the menubar should be unhidden if the user does press a menubar shortcut like Alt+F. And, would have to adjust for menu functions on OS X, or other DE that want to control menus. Yes this functionality wouldnt be used on OSs/DEs that hide the menu bar altogether. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90195] Hiding the menu bar
https://bugs.documentfoundation.org/show_bug.cgi?id=90195 --- Comment #1 from Heiko Tietze heiko.tie...@user-prompt.com --- In my opinion it's up to the OS or desktop environment how to handle main menu, window decoration, theming and colors (to make a Chuck Norris roundhouse kick). Run OS X or Gnome 3 if you want to hide or to place the menubar on top (KDE offers this option as well, of course). On the other hand, Firefox shoot forward... -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90194] Make Breeze the new default in Windows and OS X
https://bugs.documentfoundation.org/show_bug.cgi?id=90194 --- Comment #1 from Heiko Tietze heiko.tie...@user-prompt.com --- The Breeze icons are very controversially discussed. IMHO it should be the default for KDE only. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90195] New: Hiding the menu bar
https://bugs.documentfoundation.org/show_bug.cgi?id=90195 Bug ID: 90195 Summary: Hiding the menu bar Product: LibreOffice Version: 4.5.0.0.alpha0+ Master Hardware: Other OS: All Status: UNCONFIRMED Severity: enhancement Priority: medium Component: ux-advise Assignee: libreoffice-b...@lists.freedesktop.org Reporter: philip...@hotmail.com CC: libreoffice-ux-advise@lists.freedesktop.org Blocks: 85811 It would be nice to be able to hide the menu bar, especially for users who never open it, as this provides more vertical space for the document and it would benefit in a touch screen mode. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90187] UNO command to show/hide the track changes toolbar
https://bugs.documentfoundation.org/show_bug.cgi?id=90187 Commit Notification libreoffice-comm...@lists.freedesktop.org changed: What|Removed |Added Whiteboard|| target:4.5.0 -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90090] Rearranging the UI of Draw
https://bugs.documentfoundation.org/show_bug.cgi?id=90090 --- Comment #14 from Commit Notification libreoffice-comm...@lists.freedesktop.org --- 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. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90194] Make Breeze the new default in Windows and OS X
https://bugs.documentfoundation.org/show_bug.cgi?id=90194 Adolfo Jayme f...@libreoffice.org changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=30 ||541 -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90194] New: Make Breeze the new default in Windows and OS X
https://bugs.documentfoundation.org/show_bug.cgi?id=90194 Bug ID: 90194 Summary: Make Breeze the new default in Windows and OS X Product: LibreOffice Version: unspecified Hardware: Other OS: All Status: UNCONFIRMED Severity: normal Priority: medium Component: ux-advise Assignee: libreoffice-b...@lists.freedesktop.org Reporter: f...@libreoffice.org CC: libreoffice-ux-advise@lists.freedesktop.org On one hand, Breeze fits OS X Yosemite’s (and iOS’) aesthetics much better than Sifr (bug 76681 comment 6); on the other, it is more in line with Windows 10 icons. Besides, I love the fact that it doesn’t drop color. So: can we? Please? =) -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 30541] Windows default icons should not be Gnome icons
https://bugs.documentfoundation.org/show_bug.cgi?id=30541 Adolfo Jayme f...@libreoffice.org changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=90 ||194 -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 88742] Using of the Term “Properties” in Sidebar is a Bit Unfortunate
https://bugs.documentfoundation.org/show_bug.cgi?id=88742 --- Comment #2 from Adolfo Jayme f...@libreoffice.org --- Sure, “Formatting” seems more descriptive. +1 -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 88148] Image caption management forces to insert a category and numbering even if you do not need it
https://bugs.documentfoundation.org/show_bug.cgi?id=88148 --- Comment #2 from Piotr frank...@interia.pl --- Confirmed all of the above on Win 8, 8.1, x64. The most surprising is that it worked well in all OO/LO previours versions we used in the company, that is OO 3.2, LO 4.2. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 81475] Meta: enhancing Writer's standard and formatting toolbars
https://bugs.documentfoundation.org/show_bug.cgi?id=81475 --- Comment #50 from Commit Notification libreoffice-comm...@lists.freedesktop.org --- Yousuf Philips committed a patch related to this issue. It has been pushed to master: http://cgit.freedesktop.org/libreoffice/core/commit/?id=ff9fde527ec05a71c27fa3109ef4b57216f785dd tdf#81475 Fix missing space in standard toolbar and rearranged other 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. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90090] Rearranging the UI of Draw
https://bugs.documentfoundation.org/show_bug.cgi?id=90090 --- Comment #16 from Jay Philips philip...@hotmail.com --- (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 -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90090] Rearranging the UI of Draw
https://bugs.documentfoundation.org/show_bug.cgi?id=90090 --- Comment #17 from Jay Philips philip...@hotmail.com --- 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. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90214] New: Rule Should be White When Dark Themes Used
https://bugs.documentfoundation.org/show_bug.cgi?id=90214 Bug ID: 90214 Summary: Rule Should be White When Dark Themes Used Product: LibreOffice Version: 4.4.1.2 rc Hardware: All OS: All Status: UNCONFIRMED Severity: enhancement Priority: medium Component: ux-advise Assignee: libreoffice-b...@lists.freedesktop.org Reporter: jmadero@gmail.com CC: libreoffice-ux-advise@lists.freedesktop.org Created attachment 114320 -- https://bugs.documentfoundation.org/attachment.cgi?id=114320action=edit Ruler Too Dark to Read with Dark Themes When dark themes are used the ruler is really hard to read. I suggest that the numbers, the lines, and the tab placement markers all be made white when dark themes are used. Not sure how possible this is - just a suggestion for UX. Image attached showing what I'm talking about. I'm currently running GnomishDark in Ubuntu 14.10 http://www.noobslab.com/2014/04/gnomishdark-gtk-theme-for-ubuntu-mint.html -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90048] Add Nicer Looking Default Styles
https://bugs.documentfoundation.org/show_bug.cgi?id=90048 --- Comment #2 from Joel Madero jmadero@gmail.com --- Sounds reasonable - but doesn't prevent us adding new styles that are prettier. I suggest something like Header1Gr, TitleGr, etc I know that's a bit overwhelming and it'd be great if we could filter styles somehow but this would enable us to make a nice green set of styles that would be bolder, prettier, and more demonstrative of character/paragraph styles than what we currently have being used. I know that one thing on the table is allowing installing style packages - if we can do that and start hosting tarballs on the template page that has a package of styles that users create, that would be a partial solution (although having a default pretty style seems appropriate to me) Of course if UX disagrees, this can be closed. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90195] Hiding the menu bar
https://bugs.documentfoundation.org/show_bug.cgi?id=90195 --- Comment #4 from Tomaz Vajngerl qui...@gmail.com --- I have experimented with hiding the menu bar similar to how Firefox does it, by press release of alt without any other key. I managed to get it work but then I didn't yet managed to force show the menu when you actually a menu accelerator (alt + registered key). -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90205] Ruler measurement numbers need to be darker
https://bugs.documentfoundation.org/show_bug.cgi?id=90205 A (Andy) stgohi-lob...@yahoo.de changed: What|Removed |Added Priority|medium |low CC||stgohi-lob...@yahoo.de --- Comment #1 from A (Andy) stgohi-lob...@yahoo.de --- From my point of view it could maybe be a little bit darker, but to be sure I would need to see them side by side. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90187] New: UNO command to show/hide the track changes toolbar
https://bugs.documentfoundation.org/show_bug.cgi?id=90187 Bug ID: 90187 Summary: UNO command to show/hide the track changes toolbar Product: LibreOffice Version: 4.5.0.0.alpha0+ Master Hardware: Other OS: All Status: UNCONFIRMED Severity: enhancement Priority: medium Component: ux-advise Assignee: libreoffice-b...@lists.freedesktop.org Reporter: philip...@hotmail.com CC: libreoffice-ux-advise@lists.freedesktop.org Blocks: 83946, 86899 Similar to the toolbar button for showing/hiding the draw toolbar (.uno:InsertDraw), an uno command to do the same for the track changes toolbar would be useful for inclusion in the standard toolbar. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90187] UNO command to show/hide the track changes toolbar
https://bugs.documentfoundation.org/show_bug.cgi?id=90187 Jay Philips philip...@hotmail.com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Jay Philips philip...@hotmail.com --- The uno command should be labelled as TrackChagesBar. I have added an icon for it. https://gerrit.libreoffice.org/14980 -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90090] Rearranging the UI of Draw
https://bugs.documentfoundation.org/show_bug.cgi?id=90090 --- Comment #13 from Jay Philips philip...@hotmail.com --- 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. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 87923] RULER: Hiding only the vertical ruler
https://bugs.documentfoundation.org/show_bug.cgi?id=87923 Adolfo Jayme f...@libreoffice.org changed: What|Removed |Added Status|NEW |RESOLVED CC|libreoffice-ux-advise@lists | |.freedesktop.org| Component|ux-advise |UI Resolution|--- |FIXED Assignee|libreoffice-b...@lists.free |ke...@collabora.com |desktop.org | Whiteboard| target:4.5.0 target:4.4.1 |target:4.5.0 target:4.4.0 |target:4.4.0| --- Comment #8 from Adolfo Jayme f...@libreoffice.org --- No idea why this wasn’t closed before… -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 88417] Dropdown for ruler settings should show radio buttons instead of check boxes
https://bugs.documentfoundation.org/show_bug.cgi?id=88417 Adolfo Jayme f...@libreoffice.org changed: What|Removed |Added CC|libreoffice-ux-advise@lists | |.freedesktop.org| Component|ux-advise |UI Whiteboard| target:4.5.0 target:4.4.1 |target:4.5.0 target:4.4.0 |target:4.4.0| --- Comment #16 from Adolfo Jayme f...@libreoffice.org --- [Housekeeping] -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90203] When only 1 document is open in Writer, closing it also closing Writer
https://bugs.documentfoundation.org/show_bug.cgi?id=90203 Julien Nabet serval2...@yahoo.fr changed: What|Removed |Added CC||libreoffice-ux-advise@lists ||.freedesktop.org, ||serval2...@yahoo.fr Component|LibreOffice |ux-advise --- Comment #2 from Julien Nabet serval2...@yahoo.fr --- Following Andy's suggestion, let's ask to ux-team. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90205] New: Ruler measurement numbers need to be darker
https://bugs.documentfoundation.org/show_bug.cgi?id=90205 Bug ID: 90205 Summary: Ruler measurement numbers need to be darker Product: LibreOffice Version: 4.5.0.0.alpha0+ Master Hardware: Other OS: All Status: UNCONFIRMED Severity: enhancement Priority: medium Component: ux-advise Assignee: libreoffice-b...@lists.freedesktop.org Reporter: philip...@hotmail.com CC: ke...@collabora.com, libreoffice-ux-advise@lists.freedesktop.org In 4.4, kendy reduced the size of the ruler which made it look nicer, but gray color of the measurement numbers which have gotten smaller are now harder to see, so it would be good to darken them. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 90191] New: TOC: Column spacing shouldnt be set to 0.00
https://bugs.documentfoundation.org/show_bug.cgi?id=90191 Bug ID: 90191 Summary: TOC: Column spacing shouldnt be set to 0.00 Product: LibreOffice Version: 4.5.0.0.alpha0+ Master Hardware: Other OS: All Status: UNCONFIRMED Severity: enhancement Priority: medium Component: ux-advise Assignee: libreoffice-b...@lists.freedesktop.org Reporter: philip...@hotmail.com CC: libreoffice-ux-advise@lists.freedesktop.org Blocks: 89606 When you set columns in a TOC or index, the spacing field should be set to a good default value rather than 0.00 so that a user doesnt need to modify this value, unless they want to be specific. -- You are receiving this mail because: You are on the CC list for the bug. ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
Re: [Libreoffice-ux-advise] Discussion about highlighting (MS compatibility issue)
Hi there, So in the end I solved this issue on the following way: - I did not touch toolbar icons. I created a bug report about the ambiguity of character background naming: https://bugs.documentfoundation.org/show_bug.cgi?id=89830 - Both highlighting and shading can be a good candidate to export LO character background to, so I added a compatibility option to Tools - Options - Load/Save - Microsoft Office, where user can select how to save LO character background (as which MSO attribute). - Since the name Highlighting is more accessible than character background in LO and than shading in MSO, I set highlighting as the default for export. LO help also calls character background as Highlighting. So from a user point of view LO character background is closer to MSO highlighting, in spite of that on the implementation level it's closer to MSO shading. - MSO import / export filters preserve both MSO attributes. These two attributes are there at a specific text range until character background is edited by LO. Editing removes markers indicating there we have MSO imported attributes and adds LO specific character background. Best Regards, Tamás 2015-02-11 15:43 GMT+01:00 Zolnai Tamás zolnaitamas2...@gmail.com: 2015-02-10 17:29 GMT+01:00 Michael Stahl mst...@redhat.com: On 10.02.2015 15:12, Zolnai Tamás wrote: Second thing, I compared these three kind of character backgrounds and found that LO's character background is closer to MS shading attribute then to MS highlighting, because: - LO's background color is a general attribute for different objects like text range, paragraph, frame, page, cell and so on, and character background is a specialization of it (like shading). - LO's background color and MS shading both has more color to choose from, while MS highlighting allows only 16 colors. - LO's background color and MS shading has a meaning like fill the selected object's background with a color, while highlight has the meaning like highlight a text range with a highlighter pen. So IMHO LO background color should be exported as shading to MS file formats and not as highlighting. Only similarity between LO's background color and MS highlighting is the Highlighting toolbar button and this is the problem here. Why LO uses an other name for character background on the toolbar and why not use exactly the same name (e.g. as in the menu)? This causes the misconceptions we have here. i agree that having 2 different ways to do almost but not exactly the same thing in the UI is confusing. So my new plan is: - Remove Highlighting toolbar button - Replace it with the existing Background color toolbar button (set it as default) - Extend the functionality of this Background color button to be able to set character background too (By now it is used for setting paragraph, frame and cell background) With that the toolbar icon of LO's character background will be similar to that which is used in Word for setting MS shading attribute (a paintbucket). This also means we don't need to support highlighting in LO to solve this interoperability problem. With respect to RES_CHRATR_HIGHLIGHT attribute it's still useful to store MS highlighting on a separate attribute so an MS file won't loose shading/highlighting information during a round trip. We can solve that on a transparent way, so the users won't know that we have two kind of character backgrounds behind the scenes. actually - why do we need 2 core attributes for this? if you apply both highlight and shading in Word, one should override the other completely in the document view, or how does it work? can't we just in the import filter convert both to the same core item, and if both apply to the same text range, then only apply the higher priority one? then export it again as the attribute that allows more colors :) In Word when both shading and highlighting is set to the same text range, then highlighting covers shading, but when highlighting is removed later then the shading under the highlighting becomes visible. I can imagine this like shading is a static part of the document while highlighting is set temporarily (similar to the comments highlighting). Other difference between these two attributes in Word is that shading has effect on automatic font color (automatic font color is a feature of MS Word which makes the actual font color changing according to the background color, dark/light background - white/black font color), but highlighting has no such interaction with it. So using only one background attribute and so convert both shading and highlighting into one attribute (shading or highlighting) during a round trip can lead also to font color change (opening in Word). So I think it's a good idea to handle both attribute separately. Best Regards, Tamás ___ Libreoffice-ux-advise mailing list Libreoffice-ux-advise@lists.freedesktop.org
