[Libreoffice-ux-advise] [Bug 122696] Page settings missing a few paper sizes
https://bugs.documentfoundation.org/show_bug.cgi?id=122696 V Stuart Foote changed: What|Removed |Added Blocks||99525 CC||vstuart.fo...@utsa.edu --- Comment #7 from V Stuart Foote --- Hmm, looking at the vast mix of standards based and extended paper specifications [1] that could require internal LO support shows our current droplist of 31 entries is really inadequate. But then as currently positioned--LibreOffice project scope is really not in the DTP arena. Especially since we can not produce proper Bleed and Printers marks [2], and our VCL canvas layout is limited to what ODF can support. How relevant really are the majority of the larger paper sizes: 4A0, 2A0, A0, A1 even A2; or the corresponding C or B series sizes in those ranges. Likewise the larger DIN 476-1/476-2, SIS, JIS or American ANSI E, D, or C sizes? When even being able to print most requires access to large format plotter or offset press--specialized equipment that is out of scope for our office project! In fact having no DTP capability for Bleeds, Slugs and Cut lines currently eliminates _any_ utility to supporting the oversize "raw" ISO 217 RA & RSA page sizes. The extra "raw" size intended only to be trimmed away. The smaller sizes are equally questionable--most can not be handled in personal or home office printers. Why would we support those page layout formats at the expense of a cluttered UI? So I agree there is room to fix content of the drop listing for reasonably useful paper sizes--especially where we have gaps in localized support. And it looks like some of the envelope sizes are suspect (e.g. ISO 269 is "withdrawn") yet we list those envelop sizes available? M But while LO continues to be lacking DTP support, project should not feel obliged to support what are essentially "exotic" page sizes. The existing drop list UI is functional. But if a dev is motivated to pick up Jonathan's rework it looks feasible in general, but short of that nothing to be gained. IMHO => WF =-ref-= [1] https://en.wikipedia.org/wiki/Paper_size [2] bug 76629, bug 93166, bug 103396, bug 103683 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=99525 [Bug 99525] [META] Enhance Draw's DTP capabilities -- 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 https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 122696] Page settings missing a few paper sizes
https://bugs.documentfoundation.org/show_bug.cgi?id=122696 --- Comment #6 from Heiko Tietze --- (In reply to jonathon from comment #5) > ... > This presents a drop down list of page size groups... Interesting. A modification of your idea could be to have the checkboxes of page format types under tools > options and we could pre-check it depending on the locale. But simple solution is always preferred. So if Pablo can suggest a subset of RA/SRA... -- 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 https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 122696] Page settings missing a few paper sizes
https://bugs.documentfoundation.org/show_bug.cgi?id=122696 --- Comment #5 from jonathon --- I'm going to make a radical proposal here. I don't know how difficult it would be to implement this solution. The primary virtue is that it provides users the ability to add groups of paper sizes that they use, whilst keeping the number of sizes down to the minimum necessary for users. It is a three part solution: a) Replace "Styles and Formatting > Page Styles >Page >Format" with ""Styles and Formatting > Page Styles >Page >Standard" This presents a drop down list of page size groups, that can be edited, deleted, added to, or otherwise modified by the user. Standard groups to be included are: * ISO A sizes; * ISO B sizes; * ISO C sizes; * Customary Japanese sizes; * Customary US sizes; * Imperial British sizes; * User; Users have the ability to add additional groups here. Upon selecting a group, the drop menu lists the appropriate paper sizes. The User group contains one page size --- "user", whose attributes, including name and group, must be defined by the user. b) Page "User" This page is basically the same as the current format "User". The major differences are that: * The user must select a group for the page; * The user must give the page a name; * The page attributes are saved and reusable elsewhere; c) Write an extension for the "missing" groups of page styles. For this specific issue, that would be the RA & SRA series of page sizes. For a11y organisations, that would be Braille Paper sizes, or Moon Page sizes. -- 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 https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 121593] Multi-selection should be selection of objects, even if clicked inside the text area
https://bugs.documentfoundation.org/show_bug.cgi?id=121593 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |tietze.he...@gmail.com, |.freedesktop.org|xiscofa...@libreoffice.org Severity|enhancement |normal --- Comment #6 from Heiko Tietze --- Yes, changing properties should apply to all selected objects. But I cannot confirm the issue in 6.1, shape color, paragraph (left align), character (red font, font name, italic) all are applied to all shapes. -- 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 https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 125282] UX: The Find bar should search in “Current selection only” if a cell range is selected
https://bugs.documentfoundation.org/show_bug.cgi?id=125282 --- Comment #3 from Heiko Tietze --- I disagree here. The find bar is overloaded options right now and adding another option makes this UI control even more heavy. In my opinion it's just two different ways to search with a more straightforward option for the find bar that just has "Find All". And I'm definitely against assuming the user wants always to search in the current selection. More opinions 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 https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 125217] Replace Mozilla themes with a proprietary tool reusing the existing
https://bugs.documentfoundation.org/show_bug.cgi?id=125217 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval |easyHack, needsDevEval CC|libreoffice-ux-advise@lists |tietze.he...@gmail.com |.freedesktop.org| --- Comment #5 from Heiko Tietze --- Muhammet, please provide some code pointers to make this an easyhack. -- 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 https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 125280] Footer can not be made to appear only on the first page after it has been filled with content
https://bugs.documentfoundation.org/show_bug.cgi?id=125280 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |tietze.he...@gmail.com |.freedesktop.org| --- Comment #3 from Heiko Tietze --- Obviously users, at least one, struggle with the option. The hierarchically organized checkboxes are not depending on each other, ie. if the children are disabled the parent has to reflect this. But OTOH disabling all footnotes "magically" wouldn't solve the issue and rather produce more trouble for most users. Actually we have five options: off, on with the same on all pages, on with different on first page, on with different on left/right, on with different on first as well as left/right pages. Are radiobuttons better suited? Don't think so. Let's keep it a NAB. -- 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 https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 125227] duplicate assignment of accelerators on a single menu disrupts keyboard use, eliminate duplicate accelerators
https://bugs.documentfoundation.org/show_bug.cgi?id=125227 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |tietze.he...@gmail.com |.freedesktop.org| Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #7 from Heiko Tietze --- We do care about duplicate shortcuts and try to avoid. You cannot use shift for the accelerator (would be a shortcut then). So based on c4 and c3 I close the issue as WF. But please don't hesitate to report issues - and potential solutions. Your contribution is very welcome. -- 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 https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 122696] Page settings missing a few paper sizes
https://bugs.documentfoundation.org/show_bug.cgi?id=122696 Heiko Tietze changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #4 from Heiko Tietze --- While Cor has no issues with a large dropdown list it's bad usability when this kind of control is used for a large number of items. In this case it would be better realized as list with a connected search field. Secondly, 14 new types clutter the list of well know sizes. So what I would agree with is a small number of <5 items. Pablo, do you think RA4 and RA5 is enough as defaults? You can always define the size manually and store a template. -- 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 https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 124477] Provide an option to hide the animation effect
https://bugs.documentfoundation.org/show_bug.cgi?id=124477 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |mentoring@documentfoundatio |.freedesktop.org|n.org, ||tietze.he...@gmail.com Keywords|needsUXEval |difficultyInteresting, ||easyHack, needsDevEval, ||topicUI --- Comment #5 from Heiko Tietze --- We discussed the idea in the design meeting and agree with "[x] Show animation type" (default = on) in the context menu of the animations. -- 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 https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 45778] [RFE] Insert image not in a new paragraph but in the current position or as character
https://bugs.documentfoundation.org/show_bug.cgi?id=45778 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval |difficultyInteresting, ||easyHack, needsDevEval, ||topicUI CC|libreoffice-ux-advise@lists |tietze.he...@gmail.com |.freedesktop.org| --- Comment #13 from Heiko Tietze --- Quick poll on Twitter revealed no clear picture how users anchor 31% To Page, 39% To Paragraph, 7% To Character, 23% As Character (some comments "it depends"). Another option might clutter but would be the correct reaction to this result. And such an option is easy to understand compared to some magic function that combines the recently applied properties and takes it into the next operation (comment 8). It might be not too difficult to add the option, so easyhack. -- 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 https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 98193] Save icon breaks icon customization
https://bugs.documentfoundation.org/show_bug.cgi?id=98193 Heiko Tietze changed: What|Removed |Added Resolution|--- |WONTFIX CC|libreoffice-ux-advise@lists |tietze.he...@gmail.com |.freedesktop.org| Keywords|needsUXEval | Status|NEW |RESOLVED --- Comment #16 from Heiko Tietze --- We discussed the issue in the design meeting. Possible solutions are: a) combine two/some icons in one with a proprietary format, b) split the UNO command into uno:SAVEEMPTY and uno:SAVEMODIFIED, c1) draw the decoration programmatically, c2) combine/overlay two icons None of these are good solutions. And actually it's not common to change single icons so taking the effort of any patch into account it's not worth to do. => WF -- 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 https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
[Libreoffice-ux-advise] [Bug 125227] duplicate assignment of accelerators on a single menu disrupts keyboard use, eliminate duplicate accelerators
https://bugs.documentfoundation.org/show_bug.cgi?id=125227 --- Comment #6 from tor...@yahoo.com --- No 'need to remember if the mnemonic is upper or just…', one can SEE if the underlined character is 'a' or 'A'. And hitting shift-a is less gymnastic than a twice and Enter. Besides, the second choice marked 'A' could respond to a 2nd 'a' hit if the user did not Shift — for whatever reason, including not being used to the new procedure. -- 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 https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
