[Libreoffice-ux-advise] [Bug 89154] EDITING: Ctrl+Right key - cursor doesn't stop at the end of the line, jumps to next paragraph
https://bugs.documentfoundation.org/show_bug.cgi?id=89154 --- Comment #38 from Tomaz Vajngerl --- https://gerrit.libreoffice.org/17484 I would like some Writer expert to look at the patch if it doesn't do something "dangerous". -- 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 89154] EDITING: Ctrl+Right key - cursor doesn't stop at the end of the line, jumps to next paragraph
https://bugs.documentfoundation.org/show_bug.cgi?id=89154 --- Comment #37 from Tomaz Vajngerl --- I have a fix for this ready if we agree this is indeed a bug. :) -- 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 91820] Reorganization of the menu bar for Calc
https://bugs.documentfoundation.org/show_bug.cgi?id=91820 Yousuf (Jay) Philips changed: What|Removed |Added CC||gautier.sop...@gmail.com --- Comment #15 from Yousuf (Jay) Philips --- (In reply to Eike Rathke from comment #13) > > > Yes it would be a change for users who have already know where things have > > > been, but that is the case with any change. Better organized menus help > > > both > > > old and new users. > > I don't consider this situation to be better organized though.. I guess we'll agree to disagree about this. > > > So is it better for a user to find protect sheet under Tools > Protect > > > Document > Sheet or Sheet > Protect Sheet? Of course i would assume most > > > users would simply use the sheet tab context menu for this rather than > > > digging into menus. > > You would be surprised how many users don't use context menus at all or > don't even know/recall it does exist and offers different choices for > different, well, contexts.. About 80 percent of users use context menus in general, as it is easier to access contextual entries than going into the toolbar or menubar, and if they are aware that the tabs have a context menu, they are less likely to open the menubar to access those entries, especially when they are all scattered through the menubar. Inserting a sheet was in the insert menu, copying and deleting a sheet was in the Edit menu, hiding and renaming a sheet was in the Format menu and protecting a sheet was in the Tools menu. > > > Should protecting the contents of a spreadsheet from being changed be > > > considered a tool or simply an edit function similar to tracking the > > > changes > > > being make to a spreadsheet? The tools menu has been known to be a dumping > > > ground for functions that didnt seem to go into other menus rather than > > > them > > > truly being tools. > > > > The big disadvantage, mentioned by Eike too, is that now protecting is split > > over Sheet and Edit. > > That's my point. It's not only a disadvantage, it makes working with the > UI a bad experience. The point here is that we find the most suitable place for entries and the most suitable place to protect a sheet is in the Sheet menu, not in the Tools menu, as all other sheet type functions are in the Sheet menu. > > For such a situation, using Tools makes sense maybe? > > Similar with Pivot Tables... > > Now we have Insert > Pivot Table and Data > Pivot Table > .. > > Shrug. > > Maybe it's better to have that in Data, where it is now. With the way the menus are structured, we dont always have the ability to always put related things together. When you insert an image you goto the Insert menu, but when you want to modify that image, you go to the Format menu. So if a user was told to insert a pivot table into their spreadsheet, they would likely go into the Insert menu to do so, similar to how they open that menu to insert a image or chart. > And also move all Protect actions there. At the end you want to protect > your data. So if the Data menu is to be used for do things with data, should hiding that data also go under that menu? Meaning should we have Data > Hide Sheet. (In reply to Eike Rathke from comment #14) > (In reply to Yousuf (Jay) Philips from comment #10) > > > * Cell Comment > > > * Has an unselectable blank first submenu entry that probably should > > > read "Insert Comment". > > > > It was named as 'Edit Comment' in my June 11th patch. > > And is displayed now, but ... now we have Edit, Show, Hide and Delete, > all greyed out if there is no comment at the current position, but no > entry to insert a comment from that menu. I know it is in the Insert > menu and in the context menu, but not having it in the menu there > together with all other comment related actions is odd. As stated above, we cant always have all related entries together. If Insert > Comment wasnt the default location in all other apps, i would have considered moving it there. -- 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 33223] Sidebar: as container for toolbars, ability to add functions missing from Sidebar
https://bugs.documentfoundation.org/show_bug.cgi?id=33223 Maxim Monastirsky changed: What|Removed |Added CC||momonas...@gmail.com --- Comment #16 from Maxim Monastirsky --- (In reply to Yousuf (Jay) Philips from comment #15) > but believe it wont ever be possible > without a major overhaul of how controls are placed in the sidebar. Well, if: 1) Some panel contains only toolbar buttons (i.e. no comboboxes, checkboxes etc. - except for those that have such thing in the toolbar). 2) All buttons are placed continuously in one container. 3) Nothing is hard-coded inside that panel's code (like the SidebarToolBox class we have now) In other words, you have a single toolbar inside a sidebar panel. In this case (in theory) it should be possible to let the user customize this panel, just like any toolbar. So while it would be impossible to customize predefined panels, one could add custom ones, and put there whatever commands he wants. -- 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 89103] START CENTER: Right-click context menu needed in Templates section
https://bugs.documentfoundation.org/show_bug.cgi?id=89103 --- Comment #2 from Yousuf (Jay) Philips --- @Stuart: The only things that come to mind are a button toolbar and context menu, as those are always the primary mouse usage used in LO. -- 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 33223] Sidebar: as container for toolbars, ability to add functions missing from Sidebar
https://bugs.documentfoundation.org/show_bug.cgi?id=33223 Yousuf (Jay) Philips changed: What|Removed |Added CC||bu...@bubli.org, ||ke...@collabora.com, ||kris.kr...@gmail.com --- Comment #15 from Yousuf (Jay) Philips --- (In reply to orion from comment #14) > I think this comes down to design philosophy, to a degree. As soon as I saw > the sidebar, I thought "LO is allowing me to set it up like Pages. Sweet!" > It meant I could *remove* all the toolbars, save for just a few functions, > and then use bring up or dismiss the sidebar as I please. My goal is a > minimum amount of visual clutter while still retaining the ability to bring > up those functions I want (i.e., get as far away from MS Word as humanly > possible). The sidebar seems to be the only option to do that, so being able > to customize it would be ideal. Yes i consider LO's sidebar the same as the sidebar in Calligra, iWork Pages, and IBM Symphony and want users who prefer to use it to have a similar UI layout of one toolbar at the top for file and input functions and the sidebar for properties. Calligra, Pages, and Symphony dont permit a user to modify the sidebar and according to the GSoC student developer who is working on the sidebar, he stated that it wouldnt be possible to allow a user to reorganize content on an existing tab. > And with the sidebar, you have several horizontal rows, so individual > buttons could be loaded until there's no more room, and there's no problem > with drop-down menus. From a visual standpoint, this isn't hard. (I have no > idea what kind of programming goes into doing, so I won't presume.) The sidebar has button, labels, textboxes, drop down lists, and many other controls and these controls are not placed in a grid like fashion where it would be easy to move them around. They are placed in their places using the glade UI editor and being able to expose such an ability for users to do the same would likely be impossible and quite complicated for regular users to use if it was possible. > Personally, I'd like a fluid space such that if you drop a button into it, > that button is centred. If you drop a second button, they pop to an equal > distance to each other. There would be a maximum number of > buttons/drop-downs you could put on a row, and there would be a default set > at load-up. Not unlike a toolbar. Yes if that functionality could be achieved, that would be great, but i dont believe that would ever be possible. > You can dismiss the sidebar with a key combo *without* visually disturbing > the document you're looking at, unlike toolbars which push the window when > they appear. That's the benefit, at least to my mind. Ultimately, I want > something that slides *out* of the window rather than pushing my document > *in*, but a floating toolbar kinda sorta does that job, so that's what I'm > working with. You can move a toolbar into a docked position where it wont disrupt the document window. > And a lot of us see the sidebar as the potential to not have to use the > toolbars at all. That's the difference in philosophy, as far as I can tell. > If you make the sidebar customizable, then we can both have what we want, I > think. If it can be achieved, i'm all for it, but believe it wont ever be possible without a major overhaul of how controls are placed in the sidebar. It would be great to here from some of the devs in the design team on how possible this is, so CCing Rishabh, Kendy and Bubli. -- 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 91588] UI: Drawing toolbar doesn't show Select button by default
https://bugs.documentfoundation.org/show_bug.cgi?id=91588 Yousuf (Jay) Philips changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Hardware|x86 (IA32) |All Assignee|libreoffice-b...@lists.free |philip...@hotmail.com |desktop.org | Ever confirmed|0 |1 OS|Linux (All) |All --- Comment #8 from Yousuf (Jay) Philips --- I had re-enabled select in impress and draw and thought i re-enabled it in writer and excel, where it really is needs to be able to drag select, but for some strange reason it seems to have slipped past the commits i had made, so it has been done. https://gerrit.libreoffice.org/17475 -- 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 93061] About dialog needs minimum size
https://bugs.documentfoundation.org/show_bug.cgi?id=93061 --- Comment #6 from Adolfo Jayme --- (In reply to Cor Nouws from comment #5) > If I understand Jay correct, he says with a small width dialog, the new > splash screen based logo, becomes too small (height). And that does not look > nice. > > I think he is correct and see no problem in a minimum width. Then fix the graphic element (which is the one that has a problem) and do not mess with the auto-width calculation (which, again, would be introducing an unrelated behavior bug to fix another). -- 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 93060] Start Center: 'Use the sidebar to open or create a file'
https://bugs.documentfoundation.org/show_bug.cgi?id=93060 --- Comment #4 from Adolfo Jayme --- I would change the text to avoid referring to the button bar of the Start Center. That is what I did when I translated it into Spanish (as I have never liked its wording in the first place). -- 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 93066] Start Center non-app accelerators
https://bugs.documentfoundation.org/show_bug.cgi?id=93066 Adolfo Jayme changed: What|Removed |Added CC|libreoffice-ux-advise@lists | |.freedesktop.org| Component|ux-advise |UI --- Comment #2 from Adolfo Jayme --- (In reply to Yousuf (Jay) Philips from comment #0) > Now that the app accelerators were changed in bug 91776, it would be useful > to change the non-app accelerators as well. You have not provided any rationales for arbitraringly change the working accelerators we have currently. > O_pen File > O_pen Remote File > R_ecent Files > Te_mplates > Hel_p > Ex_tensions Never, EVER, use lowercase “p” as accelerators (nor g, j, q, y). The descenders conflict with the underline. (In reply to V Stuart Foote from comment #1) > No the only one that should be changed is the new "_Open Remote File" which > conflicts with "_Open File" Not really, actually, since “Open Remote File” should not exist in the first place; that button should be merged with “Open File” by using a drop-down menu. > Notice that in your suggestion you would be duplicating accelerators for > Templates and Help, as well as Open File and Open Remote File. That is not > good UI/UX, and bug 91776 was mainly to fix the duplicate use of "r" as an > accelerator. +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
