[Libreoffice-bugs] [Bug 135871] Highlighting no fill is not the same as no fill; there is still direct formatting present according to paragraph style

Mon Sep 21 14:15:06 UTC 2020

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

--- Comment #45 from Telesto <telesto at surfxs.nl> ---
(In reply to Mike Kaganski from comment #43)
> (In reply to Telesto from comment #42)
> > 1) ...
> 
> tl;dr - but anyway: *if* you see current implementation of a feature
> targeted at Benjamin to already create problems to Benjamin, this is *not* a
> permissions to create other problems to Benjamin, but to fix existing
> problems in a way that is, again, targeted at Benjamin, not at you.

No, this of course not intended argument for a change. And yes, I know people
can twist and turn arguments around, to get something 'through' for their own
preference for (very) wrong reasons. 

However, I'm attempting to put you're argument in perspective. You have a very
strong argument if it would work perfectly without a change.. and be broken
afterwards.

However this isn't the case. I'm only stating the the issue is already present,
so to objection 'Benjamin' getting some formatting problem isn't saying that
much. This is inherit to the whole DF/PS/CS system. 
So my target is it must at minimum not become worse for Benjamin, compared to
the current situation.. in the overall outcome. Not on single cases basis.
Their could be some 'drawbacks'. If they overall count is positive (in the most
common cases) I call it an overall improvement.

So yes, if any 'regression' is an objection.. development would come to an
halt. 
Replacing problems isn't desired. However in this case they general outcome is
for the better.. So the solution isn't perfect. But the whole PS/CS/DF system
isn't perfect. As long as Benjamin isn't worse off in overall experience (and
common cases); it's acceptable to me. So opting for the "Utilitarianism" view.
The 'great good'. However I don't think it's that binary (lose-win). Benjamin
will profit from this too.

Using styles with DF everywhere makes using styles pretty useless. And it's
simply confusing. I'm still having issues with wrapping my mind to it. 

I currently don't see an major case, where the behavior substantial different.
I tried to follow you're steps, but I don't notice the issue. 

So for the record:  I'm not trying to get my wishes implemented of the back of
others. And making others worse of. I actually don't care that much (and Office
suite is an commodity, there are alternatives). I'm only pointing out a topic,
which I have struggled with a long long time. And I simply don't get.  Luke
made it even more clear to me why this is simply not working. 

I'm not a heavy user. I'm only give my opinion based on what I have noticed.
However, you should ask people who actually are correcting formatting and how
often they need to do that. And if this a cumbersome job etc. 

I'm more they type of experiments.. Worse what can happen is a 'revert' (and
some wasted time/ money developing it). However we get feedback/ and data/
experiences. Not that ever idea has to become an experiment.. arguments are
fine.. but some point 'experiences' matter. 

So main question is what are the 'cost' / (expected) benefits. This look like a
'small' change to me. However the simple things are mostly more complex :-(.

Without change their is no progress :-). Again not invitation to 'change
everything all the time'. However also not a fan of long term doing nothing
strategy. They Ribbon is more or less a success after all. Similar to they
Windows 8.0 start menu debacle (which worked fine on tables/phones). It
implemented differently now day's but has still reminiscence of that time. 

For the record, I love a large audience. To get so more insights/ perspectives/
visions etc.  

(In reply to Mike Kaganski from comment #44)
> (In reply to Telesto from comment #42)
> 
> And now, that I have checked your steps: again, no. You are comparing
> oranges to apples.
> 
> You are writing about problems that Benjamin sees when working (a) with data
> coming from others - using styles; (b) using styles (we assume that Benjamin
> does that cluelessly). And those problems are absolutely unavoidable. You
> can't make Benjamin not have those in one way or in another.
> 
> What I was talking about is consistency of Benjamin's work when he *uses the
> tools designed for him* - i.e., using DF. He might have someone other's
> document, and see something unexpected/unexplainable to him there; he might
> use styles (tools not designed for him) and see something
> unexpected/unexplainable; but he needs a set of tools (DF) that *he*
> applies, and *then* he sees consistent results.

Please give one or two concrete STR examples which you have in mind where this
would occur; instead of general notion "He might have someone other's document,
and see something unexpected/ unexplainable to him there". 

Not because I want to be annoying or keep you busy. I simply not able to come
up with a clear cut case where this is obviously be problem. A case where
Benjamin would struggle more compared to the current implementation. There
might be; and my thinking might be flawed... however I simply don't see it. 

I only read about 'concerns'. That they Benjamin should be able to do is job
with DF is a of course valid argument. However need some 'proof' of actual
cases where they issue is actually demonstrated. Based on your statement this
is pretty obvious problem (and I'm feel pretty stupid not noticing it). So
please help me understand me with one or more examples.. 

More effective compared to say i'm comparing apples with oranges.. except
explaining the difference between them. I'm might be that I'm one on those
blind men: https://en.wikipedia.org/wiki/Blind_men_and_an_elephant

For the record: I don't propose 'merging' formatting if DF and PS/ CS are the
same. So If I apply bold to some text and set PS style to bold, the DF bold
stays. If I apply DF bold, Change the PS to Bold.. and UNBOLD a certain area..
The Unbold formatting; stays.

If in the case where PS style is bold, CS style normal, and DF bold nothing
changes

This in different in the case where BOLD DF is present, and overruled by CS
including bold (but that's not different from today).

-- 
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/20200921/3609cdb8/attachment-0001.htm>