[libreoffice-design] Re: Minutes from the UX/design meeting 2020-Sep-24
Am 24.09.20 um 15:26 schrieb Heiko Tietze: > Present: Sascha, Rohan, Rivan, Heiko > Comments: Regina, Telesto, Maxim, Thomas, Maxim > > Tickets/Topic * StartCenter is inconsistent with dark theme(s) + https://bugs.documentfoundation.org/show_bug.cgi?id=136555 IMHO it's stuck ATM, so I thoght you would bring it up in the meeting. Also with regard to the patch fixing: https://bugs.documentfoundation.org/show_bug.cgi?id=134708 which should probably use the default anyway: else if (IsControlForeground()) aColor = GetControlForeground(); There are two different patches currently proposed: - https://gerrit.libreoffice.org/c/core/+/103041 - https://gerrit.libreoffice.org/c/core/+/103079 Not sure if there is solution, working in all cases on all platforms. Jan-Marek -- To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/design/ Privacy Policy: https://www.documentfoundation.org/privacy
[libreoffice-design] Fwd: Rework of Writer comments "button"
Please CC libreoffice-des...@lists.freedesktop.org on replies. I didn't check the mail address. Originalnachricht Betreff: Rework of Writer comments "button" Datum: 11.07.2019 17:21 Von: Jan-Marek Glogowski An: libreoff...@lists.freedesktop.org, libreoffice-des...@lists.freedesktop.org Hi everybody, an other query for a different problem :-) While fixing tdf#126333 (https://bugs.documentfoundation.org/show_bug.cgi?id=126333) I found the current behavior of that pseudo button quite annoying. Not only forces it a repositioning of the displayed document, which probably can't be avoided, but it also moves the text and arrow of the button around. So now there is as WIP / RfC: https://gerrit.libreoffice.org/#/c/75421/ * cleanup code * handle the arrow like a tree view * > = collapsed, v = expanded * keeping the position of the arrow in front of the text * no more shifting of the text and arrow in the button * replace many static values with (correct?) dynamic ones * use highlight colors for mouse over I tried to use the DecorationView::DrawButton, but that didn't work. I'm not sure this is even the right interface. But there is still one major problem left: positioning of the button text in RTL. If you start LO with LANG=ar, the button text and arrow aren't visible, because they are outside of the view. As a workaround I left-aligned them together in case of collapsed comments in RTL in the patch. But the problem would go away, if Writer would mirror the position of the comments too and would also show the button on the left side in RTL. * How do other programs display comments when in RTL mode? * Do you think moving the comments to the right is a good idea for RTL? * I hope moving the "button" and comments wouldn't be that hard. Anyone knows that code and can comment on that? * Is there a better way to draw this "button"? * Any other opinions on the patch? * Any option on the changed behavior? Thanks Jan-Marek -- To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/design/ Privacy Policy: https://www.documentfoundation.org/privacy
[libreoffice-design] Fwd: How do various apps and DEs handle the primary selection?
Forgot to CC design. Please reply also on the dev list. Weitergeleitete Nachricht Betreff: How do various apps and DEs handle the primary selection? Datum: Mon, 8 Jul 2019 01:07:38 +0200 Von: Jan-Marek Glogowski An: libreoffice-dev Hi I'm trying to gather information how various apps handle the primary selection, so I can fix tdf#104717 [1]. There is already a patch for that in Gerrit[2]. The KDE applications I tested keep the primary alive, while they are running and just clear it when they close. So I can select some text in kate and it'll stay in the primary even, if I close the document containing the selected text. AFAIK at least Writer, Calc and Draw use TransferableHelper::ClearSelection to clear the selection. Writer clears the selection in many more places then either Calc or Draw. See $ git grep -B 5 -A 5 SwTransferable::ClearSelection sw And Writer clears it when a Shell closes, while Calc (~ScTabView) and Draw (:~View) clear it when the view is closed. But I'm a bit confused by the terms Shell and View and then there is even a ViewShell... IMHO we shouldn't handle the primary selection lifetime different from the clipboard lifetime. When selecting stuff, the primary should stay alive, even if I close the document or module, just like the normal clipboard. I don't see a point of clearing the selection at all, except on application shutdown, when the application won't be able to serve it anymore. How do other applications you know handle the primary selection? Jan-Marek P.S. I use $ watch -n 1 "xclip -selection clipboard -out; echo; xclip -selection primary -out" to monitor the clibboard status. And if you want to test stuff, be sure to disable clipboard managers, as these often copy stuff between the different clipboards, also resulting in tdf#104717. [1] https://bugs.documentfoundation.org/show_bug.cgi?id=104717 [2] https://gerrit.libreoffice.org/#/c/73906/ ___ LibreOffice mailing list libreoff...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice -- To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/design/ Privacy Policy: https://www.documentfoundation.org/privacy
[libreoffice-design] Re: LibreOffice ESC call, Thur - 16:00 central European (local) time
Am October 30, 2018 9:29:57 AM UTC schrieb Michael Meeks : >* Release Engineering update (Christian, Xisco) >+ 6.0.7 rc3 status I was told yesterday that 6.0.7 final is already tagged and out. If not, I ask to include the fix for tdf#119020 "Icons are corrupted on Windows when scaling UI / OpenGL" https://gerrit.libreoffice.org/#/c/62686/ It's actually not Windows specific and the fix is simple IMHO. I have two additional bugs / patches for icon handling, where I would like to get input. Would appreciate some input from design and marketing. /me hopes for not much bike-shedding, so I added some proposals, which are hopefully acceptable. 1. Change the icon scaling algorithm quality from ::Fast to ::Default or ::Best quality in https://bugs.documentfoundation.org/show_bug.cgi?id=121082 * Proposal: just try ::BestQuality in 6.2 and eventually revert, if it turns out to be too slow? * Is a slow first start acceptable, like comments in tdf#119020 suggest? 2. Deliver SVG icon sets * SVG icons supported since 5.3, but we don't ship the icon sets ** https://bugs.documentfoundation.org/show_bug.cgi?id=51733 * Initial WIP patch: https://gerrit.libreoffice.org/#/c/62706/ ** See long commit message and additional comments * Proposal for 6.2: ship extra SVG variants, so a user can select them manually but still switch to PNGs on problems? ** Defaults to pixelated PNG scaling, as status quo * Current patch provides zips for the SVG directories and automates links.txt creation for them ** Should a user explicitly select SVG themes? ** Should SVG be the default, so we can get rid of the PNG icon sets, if SVGs exist? ** Or automatic fallback, when we need to scale, so we combine both types in a zip? Icon may change when scaling. ** Are the PNG variants actually pre-created from SVG? ** For OpenGL scaling is actually done in HW with shaders. I won't make it to ESC today. Jan-Marek -- To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/design/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [libreoffice-design] Survey about Libreoffice Draw
Hi, just as an other data point I want to give you some information, why we (as City of Munich) added Calligra Flow to edit flowcharts / ODG based flow diagrams. We originally used Kivio in KDE3 and 1 1/2 years ago we were faced with the problem, that users had a lot of Kivio files, which weren't readable by any other program then Kivio, As Kivio was part of KOffice, it wasn't available for KDE4 and long dead. In the end we wrote a converter to convert kivio to odg. This works great for us, but we saw two main problems with Draw: 1. Bug 83360, which effected the result of our converted output 2. A much larger standard symbol set in Flow for technical diagrams From my personal POV, which is of a non-user of these tool, LO probably just needs an additional interface preset for Flow charts, and a new "new filetype", just like the special wizards for labels, business cards etc., and save this custom setting in the odg file. Just defaulting to an open gallery side bar and enabling the grid makes Draw look much like known Flow charting programs like MS Visio or Kivio, which people feel already familiar with. I didn't check the licenses of dia and calligra flow clip art galleries. That even may be a good collaboration point and is probably easily fixable. HTH Jan-Marek P.S. I don't see the online searchable, extension based openclipart gallery as an alternative to a well defined, integrated flowchart gallery set. -- To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/design/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-design] Re: Am alternative print range selection algorithm
Just to make this more clear: 1. The print preview (Ctrl + Shift + o) is just a other view of the document, and doesn't open a dialog 2. The print dialog (Ctrl + p), which contains a little preview too. Am 02.02.2016 um 20:38 schrieb V Stuart Foote: > @jmux, * > > Jan-Marek Glogowski wrote >> Now there is the nit-pick, that the page number isn't adjusted, if the >> user changes the "print empty pages" setting. We also don't adapt the >> page range when toggling the "print empty pages setting". I guess that >> would be much more work. > > As displayed on the Status bar while in Normal view, and in the Print > Preview mode--right? No. I was just talking about the print dialog, where you can select the range of printed documents. As I read your bug, it was about the print dialog. > But we also have another "nit-pick" related issue with the Navigator, and > its linked "Jump to Specific Page" box in the Print Preview dialog. When > Navigating/jumping to one of the blank pages, it gets lost and ends up on > the first page. That's also not a new problem from the patch, but when I looked for the crash I originally thought it was related. And I actually can't use the scroll wheel correctly - just load the odt from https://bugs.documentfoundation.org/attachment.cgi?id=122351 The scroll bar says it scrolls to page 83, but it actually stops at page 41. This also happens in LO 4.1. >> A question that came to my mind: Should we place the "print empty pages" >> setting more prominently on the general page near the range selection >> like the reverse order checkbox, as it directly affects the print range >> selection? > > Where? (1) on the Print dialog--where the range selection, reverse order are > located, and *exposed for selection to every print job*; or (2) more > generically as a setting in the Tools -> Options -> Print panel? Could be > either of those as opposed to the Tools -> Options -> Writer -> Print: Other > section, where it resides now and is a Writer only configuration. > > But, not the Tools -> Options General tab. Yup (1). It's already in the print dialog on the "LibreOffice Writer" page. I just want to move it to the general page in the "range and copies" area. I'm not referring to any settings here. Obviously we would have to hide it for non-writer documents, as the general page is AFAIK also used in all other LO programs, which don't have an "hidden empty page problem". >> OTOH this is a Writer only setting. We can still show and hide it on the >> general page, depending on the calling document / application. But >> probably it's also not needed? > > Yes. But again, you mean for the Print dialog and not one of the Tools -> > Options panels? Yup (1) Jan-Marek -- To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/design/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-design] Am alternative print range selection algorithm
Hi *, so the patch has landed in master. I fixed a resulting crash and a little inconvenience it caused (AKA bug 97505). Now there is the nit-pick, that the page number isn't adjusted, if the user changes the "print empty pages" setting. We also don't adapt the page range when toggling the "print empty pages setting". I guess that would be much more work. A question that came to my mind: Should we place the "print empty pages" setting more prominently on the general page near the range selection like the reverse order checkbox, as it directly affects the print range selection? OTOH this is a Writer only setting. We can still show and hide it on the general page, depending on the calling document / application. But probably it's also not needed? Comments? Jan-Marek -- To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/design/ All messages sent to this list will be publicly archived and cannot be deleted
[libreoffice-design] Am alternative print range selection algorithm
Hi everybody, I would like to get some UX input on tdf#89708 - or a different implementation of the requested feature. MAILMERGE: Add option to prevent inserting extra blank pages https://bugs.documentfoundation.org/show_bug.cgi?id=89708 The implementation is at: https://gerrit.libreoffice.org/#/c/18420/ tdf#89708 Adjust print page range for unprinted blank pages by Eilidh McAdam for master [NEW] (I just fixed the patch for all those renames) The origin of the patch is a tender of the OSB Alliance (Open Source Business Alliance e.V.) from 2014. The patch matches "use case 1, part 3": > In the printer dialog the number of pages to be printed should correspond to > the number of generated pages from the mail merge function. See: http://osb-alliance.de/fileadmin/Working_Groups/OfficeInteroperability/Project2/SpecificationMajorFeatureImprovements_final.pdf And just quoting my comment from the bug report: https://bugs.documentfoundation.org/show_bug.cgi?id=89708#c2 > There is no way to prevent the blank pages. > > But we already don't display blank pages in the LO print dialog, as you can > see in the image (no pages previewed AKA 0/0, because "print empty pages" is > not selected). > > So the print range selector needs to evaluate the range according to the > "print blank pages" setting. This is doable. > > Now we get the "problem", that the preview range doesn't match with the > displayed page numbers in the document window - not sure which is worse. > > All this can become - in any way - frustrating for the user. The primary source of the problem is the mail merge origin. You have a single letter document, do a full mail merge and now want to select some of the generated documents of the dataset for print. You know you want to print datasets 15 and 18. So any suggestion how to solve this problem in a consistent way? Maybe we want a configuration option, which probably also ignores empty pages in "normal" page count? Thanks for your input Jan-Marek P.S. Cors suggestion (teach the users) also helps, but the actual user experience is still bad IMHO. P.P.S the inconsistent different ways to run a mail merge also don't help improving the experience. -- To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/design/ All messages sent to this list will be publicly archived and cannot be deleted
