To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=4032
------- Additional comments from [EMAIL PROTECTED] Wed Apr 9 10:26:25 +0000 2008 ------- ama->jkaufmann: > Again: Looking over the bug reports, two things seem clear: > (a) The behavior problems that users (still) experience with OO tables are > not > about *my* expectations; those expectations seem to be almost universal. It's hard to argue against "almost universal expectations", but I have a question: which bug report, which behavior do you refer to? I've checked a lot of duplicates to this issue (4032) but these duplicates are real duplicates and fixed within our new table model. Please point me to other issues which you recognized as caused by the table model. At the moment I'm only aware of these 5 issues I mentioned earlier, which do not request a change of the table model IMHO. > (b) The new table model has moved in the right direction, but has not > arrived. Why? If I interpret you right, you are thinking, that our internal data structure does not reflect the table structure in an appropriate way. You think that the column span is not represented well. And you seem to believe that a other way to reflect the column span will solve any issue? Which one? > It is sad to see OO, with respect to tables, so far behind > modern data structure.] Sorry, but that's a statement but I'm missing any proof, I'm mathematician no philosopher. > And yet the bug reports on OO tables, all seem to be that users either > can't > achieve the structure they intend, or have seen their intended data structure > violated. So it's hardly surprising that the new model, which seeks only to > tweak the representation without considering the structure, is only partly > successful at responding to those bug reports. Again: which bugs do you mean? > [I'm afraid it is not coincidental that you have not responded to any of my > points about data structure, which I find the common theme of the bug > reports.] In my view, our old table model was not able to represent some tables with certain row/column spans. Our new table model solves that problem. Or could me describe me a table with row/col spans which cannot be achieved with our new model? > Similarly, the cursor travel anomalies are, I submit, artifacts of the basic > fact that the cursor is not traveling a data structure, so I really don't > think > it's useful to discuss the cursor travel without the underlying table model. At the moment I'm aware of the one anomaly you described earlier. I think cursor traveling in a table with row/col spans is worth a new bug report. There we could discuss, which movement is unexpected. If we agree on some improvement of the behavior I will not hesitate to change any code which is necessary. I have no problem to change any data structure or any algorithm. > In conclusion: I don't think it's useful to go around and around on your > points > about "cursor traveling" (1), "splitting cells" (2,3), "naming conventions" > (4), > and "merging cells" (5), as long as you proceed from the premise that "Every > issue is worth to be submitted and discussed separately." [I use examples to > illustrate an underlying problem, not to say that the examples are themselves > individual problems.] Until we at least *look* at the table model in terms of > semantic significance (data structure), it is probably a waste of everyone's > time to talk about "implementation details". But that's what I did, for every of your examples I "looked" into our code to detect if data structure or algorithm or both needs to be changed. There was no issue which has to be fixed by a change of the data structure. (1) cursor traveling: Your mentioned anomaly is caused by a row span, so a more "column spanned" cannot be a solution. (2) splitting cells: Could be solved by a simple algorithm, no structure change needed. (3) splitting cells: Only a string changed, a model change is not needed and will not be helpful (4) naming convention: like (2) (5) merging cells: Like (1), row span causes trouble, a change of column span representation cannot be a solution for this problem. > Once the underlying structure is fixed, those representation anomalies will > go away. Which one? Maybe (2) and (4) can be touched by a structure change, but surely a little bit algorithm change will needed, too. > But until that happens, this most troublesome of OO issues will not be > fixed, and for most users OO will not be a complete (and thus viable) > alternative to Word or other apps. Why? (1), (3) and (5) are not caused by a missed column-span-model. (2) is a nice feature, but I just tried another word processor, it behaves like OOo. (4) I tried another word processor but it does not show the names of the cells in the status bar, so I could not decide which naming scheme it uses. > If we can address the basic issue, I will be > happy to help in whatever way possible. Until then, I remain stunned that > this > issue is marked "CLOSED". This issue was about a problem to merge cells. This problem has been solved. The issue is fixed. (Implementation detail: to fix this issue, we had to do some changes in the underlying data structure, the table model.) If you want to help us to improve our product, you have e.g. the following opportunities: - submit issues for improvable behavior (bugs, better behavior, feature, new options or whatever) - for features you could help to write a specification - if you are a software developer you could submit patches or make proposals how to improve the code --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
