[Libreoffice-ux-advise] [Bug 156804] Text inserted from autotext doesn't show the set number of paragraph
https://bugs.documentfoundation.org/show_bug.cgi?id=156804 --- Comment #10 from Mike Kaganski --- (In reply to Davide from comment #0) > From release 5.4 on. I didn't try to repro yet, but this piece caught me: so was it different in am earlier version? If so, the first thing to do is to bisect which change made the difference. It might describe why. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 156804] Text inserted from autotext doesn't show the set number of paragraph
https://bugs.documentfoundation.org/show_bug.cgi?id=156804 --- Comment #11 from Davide --- I confirm the issue also in 5.4. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157036] libreoffice portable V7.6 calc program can not achieve the following function insert->filed(date, sheet name, document_title)
https://bugs.documentfoundation.org/show_bug.cgi?id=157036 --- Comment #5 from Heiko Tietze --- For me (Linux/KDE, tested with gen,gtk3,kf5) the "Fields" menu item is always enabled but the submenu items are disabled until the edit mode. And actually I doubt showing (or not) the disabled submenu items makes the situation more clear. The context menu has a Fields entry when in edit mode, not in view mode (Cell Edit vs. Cell in the customization). So we could remove Fields from the main menu (or show it only when in edit mode, although that's no a good solution). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157105] Support tracking changes to style choices
https://bugs.documentfoundation.org/show_bug.cgi?id=157105 Heiko Tietze changed: What|Removed |Added CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | --- Comment #5 from Heiko Tietze --- (In reply to Eyal Rozenberg from comment #4) > Actually, I'm getting inconsistent behavior! If I select the entire > paragraph and apply the style change, I don't get a tracked change... Me always gets TC. Anyway, apparently not a question for UX. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157098] No visual indication of non-character paragraph-style direct formatting
https://bugs.documentfoundation.org/show_bug.cgi?id=157098 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org Keywords|needsUXEval | --- Comment #3 from Heiko Tietze --- I think the expectation is reasonable and making a paragraph centered, for example, should be taken into TC. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 156598] Custom list numbering from DOCX import is not available in UI
https://bugs.documentfoundation.org/show_bug.cgi?id=156598
--- Comment #5 from Heiko Tietze ---
Created attachment 189389
--> https://bugs.documentfoundation.org/attachment.cgi?id=189389&action=edit
Mockup
The mockup follows the current dialog workflow at
(1) and allows to set a string before and after the current level number;
effectively this generates % depending on the chosen level. It
requires (or allows) to define the string for every single level, which might
be tedious. So with
(2) "All" (being some kind of replacement for 1-10) one creates
%1%2%3 During the design
session we pondered over a "Apply to all" button at the before/after fields
that allows more fine-grained copying but simplicity first.
In contrast to the current list of levels at the left-most column, the design
puts the selection into a dropdown and introduces at
(3) a list of schemes with a couple of predefined options to cover most use
cases and to illustrate the capabilities but also allowing to extend with
user-defined setups.
We also discussed how to achieve the current separators. This should be
possible by adding a "before" string for the first level and something for
"after" at the last. "Last" needs to be fix, however. And if more flexibility
is needed, the start/end labels could be made available in the dialog too.
Last but not least we should consider some advanced definition like to
"%1{.%2}[2-]{.%3}[3-]{.%4}[4-]{.%5}[5-]{.%6}[6-]{.%7}[7-]{.%8}[8-]{.%9}[9-]{.%10}[10-]".
--
You are receiving this mail because:
You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 156598] Custom list numbering from DOCX import is not available in UI
https://bugs.documentfoundation.org/show_bug.cgi?id=156598 Heiko Tietze changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157036] libreoffice portable V7.6 calc program can not achieve the following function insert->filed(date, sheet name, document_title)
https://bugs.documentfoundation.org/show_bug.cgi?id=157036 --- Comment #6 from ady --- (In reply to Heiko Tietze from comment #5) > For me (Linux/KDE, tested with gen,gtk3,kf5) the "Fields" menu item is > always enabled but the submenu items are disabled until the edit mode. Not under MS Windows in recent LO Dev 24.2 (but yes in 7.6.0.3); the sub-entries are not shown when the Field entry is grayed out. Showing the sub-entries (in gray when adequate, as in LO 7.6.0.3) is more clear for (new) users. IOW, keep "Field" grayed out when relevant, but also show the sub-entries (also in gray when relevant). > So we could > remove Fields from the main menu (or show it only when in edit mode, > although that's no a good solution). It would make the entry harder to discover and to learn about it, as this report shows. The feature is already not immediately understood (or at least how to use it, requiring edit mode); let's not make it harder. In the meantime, we have now shown a regression in UX in LO Dev 24.2 vs 7.6. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 156598] Custom list numbering from DOCX import is not available in UI
https://bugs.documentfoundation.org/show_bug.cgi?id=156598 BogdanB changed: What|Removed |Added CC||buzea.bog...@libreoffice.or ||g Blocks||107832 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=107832 [Bug 107832] [META] Writer list style bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 149625] FORMATTING: Pasting a table cell, pastes the source cell in the upper/actual cell as an inner table cell
https://bugs.documentfoundation.org/show_bug.cgi?id=149625 Dieter changed: What|Removed |Added Resolution|--- |NOTABUG Status|NEW |RESOLVED --- Comment #23 from Dieter --- (In reply to Mike Kaganski from comment #19) > (In reply to LeroyG from comment #18) > > I couldn't repro *that* piece using 7.6.0.3. Mike, you've changed bug status from RESOLVED NOTABUG to NEW, but I can't understand why. So I will change back to RESOLVED NOTABUG. Please explain why you think, we should chenge it to NEW => RESOLVED NOTABUG -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 156896] ENHANCEMENT: allow "numering followed by new line" for all list styles
https://bugs.documentfoundation.org/show_bug.cgi?id=156896 Dieter changed: What|Removed |Added CC||dgp-m...@gmx.de, ||libreoffice-ux-advise@lists ||.freedesktop.org Keywords||needsUXEval --- Comment #1 from Dieter --- I disagree. I know there is a lot of chaoter numbering with a format like Chapter 1 This is just a dummy text But I'm not sure, that I've ever seen a list in this way. But I think it's up to design team to decide -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157116] Pre-calculating formulae as they are entered
https://bugs.documentfoundation.org/show_bug.cgi?id=157116 V Stuart Foote changed: What|Removed |Added Keywords||needsDevAdvice CC||er...@redhat.com, ||libreoffice-ux-advise@lists ||.freedesktop.org --- Comment #5 from V Stuart Foote --- before going too far down this rabbit hole would like dev input as to amount of effort (i.e. would incremental value results during formula input even be available). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 156926] Ability to Delete all images in Writer
https://bugs.documentfoundation.org/show_bug.cgi?id=156926 Dieter changed: What|Removed |Added CC||dgp-m...@gmx.de, ||libreoffice-ux-advise@lists ||.freedesktop.org, ||rayk...@gmail.com Blocks||103152 Keywords||needsUXEval --- Comment #2 from Dieter --- Jim, what do you think? Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=103152 [Bug 103152] [META] Writer image bugs and enhancements -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157116] Pre-calculating formulae as they are entered
https://bugs.documentfoundation.org/show_bug.cgi?id=157116 --- Comment #6 from Colin --- (In reply to ady from comment #4) > While typing-in a function, we (users) already have a tooltip (on the input > box bar) Which is often a yard away from the cell I'm working with > After the opening parenthesis, the > tooltip helps with the arguments. IIRC, these tooltips can be configured > (ON/OFF). I need to find and evaluate that facility but if it's in the input box bar then it's still potentially a yard away > Adding yet another tooltip could be a plus to some users, but unwanted for > others, depending on the combination of tooltips and location of them (e.g. > input bar; near the cell,...). The Google one as - can be seen from the screen image - is directly in the line of sight which is what makes it so user-centric. We always run into the scenario where we are editing or inputing a formula and it obscures adjacent cells - sometimes we want to click the obscured cell as an input reference but just have to live with the fact that we can't always have everything we desire. > OTOH, showing the (future) result while > typing-in a function/formula would require to introduce (at least) the > non-optional arguments, so in some cases the tooltips would not be presented > simultaneously. As identified - Google only presents results when it's possible to provide them > > Beware: the location of the newly-suggested tooltip (in relation to the > cell) is very relevant. Just think about editing a formula in the input box > bar vs. editing a cell by pressing F2 (which shows the current content > spread around or near the cell itself). If the user isn't a "touch typist" they are usually fixated on the keyboard and their target cell - which is conveniently accessible by double clicking that cell. Most users are "touch mouse proficient". If the feture is "switchable" then perhaps the toggle could also define the user's location preference for the tip. Additionally, there already exists a bug report where tips don't always layer on top of everything. That would also need consideration. > In any case, there should be an option to either display it or not. I agree wholeheartedly -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157116] Pre-calculating formulae as they are entered
https://bugs.documentfoundation.org/show_bug.cgi?id=157116 --- Comment #7 from Colin --- (In reply to ady from comment #4) > While typing-in a function, we (users) already have a tooltip (on the input > box bar) suggesting possible functions. After the opening parenthesis, the > tooltip helps with the arguments. IIRC, these tooltips can be configured > (ON/OFF). > I can't seem to find this. I can find extended tool tips but that only seems to cover the mouse hover tips. Could you give me a clue where to look? Thanks -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157116] Pre-calculating formulae as they are entered
https://bugs.documentfoundation.org/show_bug.cgi?id=157116
--- Comment #8 from ady ---
(In reply to Colin from comment #7)
> (In reply to ady from comment #4)
> > While typing-in a function, we (users) already have a tooltip (on the input
> > box bar) suggesting possible functions. After the opening parenthesis, the
> > tooltip helps with the arguments. IIRC, these tooltips can be configured
> > (ON/OFF).
> >
> I can't seem to find this. I can find extended tool tips but that only seems
> to cover the mouse hover tips. Could you give me a clue where to look? Thanks
The answer has at least 3 points.
On a new Calc, (with AutoInput set to ON):
A.1. Click on the input box (formula bar) (or on the "=" symbol on the formula
bar).
A.2. Start typing-in the function "=SUM". You should see a tooltip suggesting
possible functions, located near the *input box*.
A.3. Add the opening parenthesis, "=SUM(". The tooltip suggests arguments.
A.4. Press [ESC] twice (as we don't need to go further here).
Now click on some cell (in order to focus on it) that is more centered on the
screen; cell E10 for instance.
B.1. Press F2 (or double click on the same cell E10), or directly start by
typing-in the "=" symbol, in order to enter into cell's edit mode (and to
introduce a formula).
B.2. Start typing-in the function "=SUM". You should see a tooltip suggesting
possible functions, located near the *cell*.
B.3. Add the opening parenthesis, "=SUM(". The tooltip suggests arguments.
B.4. Press [ESC] twice (as we don't need to go further here).
Now go to menu Tools > AutoInput to set it to OFF. Then repeat the steps above
(A and B); the tooltip should not be displayed this time.
So, again, the precise location of newly-suggested tooltips (or any other
artifact) is relevant, and whether it is displayed should be configurable.
Let's not forget that we (can) have other artifacts near or around each cell
(comments/notes; formula indicator and hints; tooltips; trace arrows…) and
editing "in-cell" is already a problem for some users.
(In reply to V Stuart Foote from comment #5)
> before going too far down this rabbit hole would like dev input as to amount
> of effort (i.e. would incremental value results during formula input even be
> available).
I agree; let's wait for some very relevant feedback/comments.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 157116] Pre-calculating formulae as they are entered
https://bugs.documentfoundation.org/show_bug.cgi?id=157116 --- Comment #9 from Colin --- (In reply to ady from comment #8) > (In reply to Colin from comment #7) > > I can't seem to find this. I can find extended tool tips but that only seems > > to cover the mouse hover tips. Could you give me a clue where to look? > > Thanks > > The answer has at least 3 points. > > On a new Calc, (with AutoInput set to ON): > Neat - I guess you can teach old dogs new tricks. Do you do "touch typing" lessons as well? Thansk, Thakns - You know what I mean;) -- You are receiving this mail because: You are on the CC list for the bug.
