[Libreoffice-ux-advise] [Bug 45789] automatic row height in reports

[bugzilla-daemon at bugs.documentfoundation.org]

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

--- Comment #54 from Howard Johnson <BridgeportContractor at gmail.com> ---
Created attachment 140395
  --> https://bugs.documentfoundation.org/attachment.cgi?id=140395&action=edit
another, larger database to demo this bug

6 years, 16 volunteers, 4 duplicates, tough bug!  (-: My attachment here today
is a more comprehensive Base report to further demo this issue. :-)


1) I think we might be starting with the wrong bug.  

No really, the more important bug I think, is that the LO source code is mostly
too hard to work on.  

I have myself begun to study the source base, but in most places it lacks the
most basic comments to help the unfamiliar figure out how it works, to be able
to read the code to even work on bugs like this.  

(A few years go by and I can't even read my own code without a few comments to
refresh my memory.  And as we all get older, this issue gets worse.)

So what I think is needed _first_, is to work together (or alone) to start to
add sufficient comments to the code base to help new coders find their way
around.  One needs to be able to read the code without going to an extreme
amount of work.  

I am willing to help with such an effort, as I begin to try and read the code
myself.  (Please see more specific question about this below.)


2) As for THIS bug, and having used database report writers (plural) with
CanGrow and CanShrink type features, I am definitely of the opinion that BOTH
of these properties are required, not just AutoGrow, and need to be added to
all controls.

The reason for CanShrink is that if no data is in group, it is often desirable
to fully collapse the group, so as to save paper space where it's not needed. 
But this can only reasonably work if CanShrink is also available.  In this case
you would set the can-shrink on all fields in the group, and also on the group
itself.

Furthermore, I think it would make no sense to fix only half of this problem,
and to miss the other half, especially when it is so hard to do, and these are
so closely related.


3) Finally, and sadly, the Base report writer, as it is, is extremely slow. 
Just try to produce a report with 100 pages sometime.  It takes forever.

So I think any work done on #1 or #2 above should keep a watchful eye on
someday re-writing the slower parts, (or the whole thing) to be faster.  For
one, I can see from the above comments that Java is involved.  At a minimum I
think that it someday needs to get rewritten in some flavor of C, as I have
found java to sometimes be slow.


SUMMARY: So my point #1 above (call for code comments), becomes even more
important in the long haul: It will help fix things now, and make things faster
in the future.


MY QUESTION: Are code comment-only commits (i.e. comments w/o any code changes)
welcome to the powers that be here?

I realize that the people who wrote this are probably long gone, so any
comments will only try to recapture some of what was in their heads, and
comments will definitely be a work in progress, so some tolerance for not
getting them right the first time would be appreciated.

Also my call for comments is not just about this bug.  It appears to me that
there are a whole backlog of Base bugs that are in the category of:  Given the
volunteer time we have available, 'too hard' to fix right now.


Can I get a green light to start to add comments to the code to make it more
readable, AND if yes, is there some community tolerance for how this is to be
done, as any comments might be better than none?  

I have some particular commenting styles I've developed over the years, but
even I don't always stick to my commenting styles.  :-)  For one I never like
processing comments into documentation, so I don't do that.  Comments I think
are to help engineers read the code, period.

Thanks.


____________
I'm so independent that I often won't do what I put on my own to-do list.  :-~

-- 
You are receiving this mail because:
You are on the CC list for the bug.