[Libreoffice-bugs] [Bug 137125] DF Formatting moving around in unexpected way with copy/paste

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=137125

--- Comment #6 from Telesto <telesto at surfxs.nl> ---
(In reply to Heiko Tietze from comment #5)
> (In reply to Telesto from comment #4)
> > So would love to now you're opinion.
> 
> The described issue is clear and I would also expect the original layout
> after pasting. However, since this boils down how DF is handled I disagree
> (we discussed whether or not to continue the formatting to the left or right
> somewhere else).

That 'left/right' is indeed true. However, the whole topic isn't debated
properly. Mostly ending in the introduction of the faceless, anonymous user (or
group of users; the angry mob) who will hunt you the rest of you're live. 

The 'other reports' are all 'encountering'. hopefully not duplicates.. where
it's the same thing (that's what it looks like).

> 
> > Related to this specific bug. Fix could be limited to cut/paste...
> 
> Doubt that. We must avoid (obvious) special situations where users cannot
> grasp the underlying mechanism. And introducing special behavior has always
> the danger of ignoring other corner cases.

Those are my lines :-). I'm indeed disliking resolving special cases (or doing
it case by case basis). Problem is I don't oversee the variables at work.
Nor if this can be solved at one place in the code. The anchoring selecting
behavior is still not totally in line with the model M. Stahl described. Keep
finding flaws here an there (and there are already numerous solved).

Currently I would still opt for set formatting to begin of the line (cut paste
& backspace). Instead of using the formatting at the end. Which would mean b*b*
backspace.. would end up in non-bold (current bold) too.

I don't think this specific 'example' being an acceptable loss (it's a change
in behavior; that for sure). 
--

However I'm really dislike going to the impasse situation which obviously never
will be 'resolved' by itself. I'm more a proponent of the "Utilitarianism"
view. 

So if we (a certain audience; not we both) agree this would be in general a
better solution, this should in principle be implemented. 

Of course starting with an impact assessment. If we would want a change here..
How would the problem is (is this practical limited to cut/paste). Or should
different scenario's taken into account.

So the first question is where see the developer the opportunity to make the
change to get the desired result (while being consistent in usage over the
line). Or at minimum feeling naturally (so it might be some theoretical
difference.. but pragmatically/practically no issue)

---
Next step would be getting some feedback from the public. So blog post. We see
problem A from our perspective. We see solution X from our perspective. Which
would also result XYZ. What do you think. So we are as open as possible. We
don't get full user base. We never will.. but say we tried to be open (not an
obscure bug tracker thingy). We could throw it at local community's to
discuss.. (and lets see what those people think)

--
If that's cleared the next step would be building a proof of concept (so build
with the change implemented). Separate build (or master build; with bunch of
room to test; what I call the Justin L approach). Assuming that this not being
a $ 100.000,- topic.

Lets try , lets see if this would be workable. Or if we encounter major blow
backs. Which needs fixing again.. or causing to reconsider the original idea
(as it won't work as predicted/expected). So got becoming worse 

This ideally again with blog/ throw it at local community (as we discussed
earlier bla.. now we have proof of concept. Please try and let us know what you
think.

---
If that's going well too. we getting to the point of Release Notes. After
careful and long deliberation we decided to make a change in DF logic.
This to deal with XYZ. This will cause changes in cases like DEF. We think it's
overall for the better.

Comments, bugs reports etc are still welcome. (Re)evaluation of the change will
take place after 4 months (after final release) at UX with the feedback
received.

If you have issues with new behavior, please report, hold on to LibreOffice
stable and wait for the re-evaluation.. 

This more transparent compared MS will ever be. And give expression to be open
of users (community). And not being kept hostage by the (mental present)
faceless anonymous user who might object against the change.

Dislike gridlocks.. Of course if developers say - objectively - this isn't
realistic because or desired code-wise because of XYZ.. we now also more 

And yes, I do see that such a change might introduce some regressions; however
not really new (see my regression fixed list). So let's not pretend this never
happens on other occasions :-)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200930/4d2092b7/attachment-0001.htm>