[Libreoffice-bugs] [Bug 151840] API: Text Table Cursor has no notion of row and columns, and no sane way to loop through the selection
https://bugs.documentfoundation.org/show_bug.cgi?id=151840 BogdanB changed: What|Removed |Added CC||buzea.bog...@libreoffice.or ||g Blocks||107200 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=107200 [Bug 107200] [META] Writer table and cell selection issues -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 151840] API: Text Table Cursor has no notion of row and columns, and no sane way to loop through the selection
https://bugs.documentfoundation.org/show_bug.cgi?id=151840 --- Comment #15 from Lionel Elie Mamane --- (In reply to Mike Kaganski from comment #14) > (In reply to Lionel Elie Mamane from comment #13) > > No. getRangeName()/gotoCellByName means ... > > Please! :) I meant "oSel.TextTable.getCellRangeByName(oSel.getRangeName())", > "getCellRangeByName" being already mentioned here in the discussion, without > any manual parsing. OK, sorry, I missed that. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 151840] API: Text Table Cursor has no notion of row and columns, and no sane way to loop through the selection
https://bugs.documentfoundation.org/show_bug.cgi?id=151840 --- Comment #14 from Mike Kaganski --- (In reply to Lionel Elie Mamane from comment #13) > No. getRangeName()/gotoCellByName means ... Please! :) I meant "oSel.TextTable.getCellRangeByName(oSel.getRangeName())", "getCellRangeByName" being already mentioned here in the discussion, without any manual parsing. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 151840] API: Text Table Cursor has no notion of row and columns, and no sane way to loop through the selection
https://bugs.documentfoundation.org/show_bug.cgi?id=151840 --- Comment #13 from Lionel Elie Mamane --- (In reply to Mike Kaganski from comment #12) > (In reply to Lionel Elie Mamane from comment #8) > > For all that, simple introduction of TextTable property is enough, together > with existing getRangeName. No. getRangeName()/gotoCellByName means the macro writer must parse the range name, a string, manually. This is not a sane, usable API. Something like css:table:XCellRange is much better. Clearly, the designer of the idl files intended that to be provided for text tables, since css:text:CellRange provides that interface. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 151840] API: Text Table Cursor has no notion of row and columns, and no sane way to loop through the selection
https://bugs.documentfoundation.org/show_bug.cgi?id=151840 --- Comment #12 from Mike Kaganski --- (In reply to Lionel Elie Mamane from comment #8) For all that, simple introduction of TextTable property is enough, together with existing getRangeName. If one wants to treat something as "generalised rectangle", constructing that explicitly is IMO OK. Additionally that has benefit of not requiring that all future implementations only allow contiguous cell selection. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 151840] API: Text Table Cursor has no notion of row and columns, and no sane way to loop through the selection
https://bugs.documentfoundation.org/show_bug.cgi?id=151840 --- Comment #11 from Lionel Elie Mamane --- Created attachment 183362 --> https://bugs.documentfoundation.org/attachment.cgi?id=183362&action=edit example 3 of B1:D3 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 151840] API: Text Table Cursor has no notion of row and columns, and no sane way to loop through the selection
https://bugs.documentfoundation.org/show_bug.cgi?id=151840 --- Comment #10 from Lionel Elie Mamane --- Created attachment 183361 --> https://bugs.documentfoundation.org/attachment.cgi?id=183361&action=edit example 2 of B1:D3 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 151840] API: Text Table Cursor has no notion of row and columns, and no sane way to loop through the selection
https://bugs.documentfoundation.org/show_bug.cgi?id=151840 --- Comment #9 from Lionel Elie Mamane --- Created attachment 183360 --> https://bugs.documentfoundation.org/attachment.cgi?id=183360&action=edit example 1 of B1:D3 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 151840] API: Text Table Cursor has no notion of row and columns, and no sane way to loop through the selection
https://bugs.documentfoundation.org/show_bug.cgi?id=151840
--- Comment #8 from Lionel Elie Mamane ---
(In reply to Mike Kaganski from comment #7)
> First of all, cursor is not a table. Implementing XTextTable in the cursor
> would be a wrong mix of concepts.
I technically agree with the narrow statement above, but I see no "wrong mix of
concept" in that the TextTableCursor can give access to the table it is a
cursor in. Which you also propose, through a TextTable property or a
getTextTable() method (which Basic would "present" as a read-only TextTable
pseudo-property).
However, I must stress that, as far as I can observe, css:text:TextTableCursor
is returned by ThisComponent.getCurrentSelection() only when a range of cells
is selected. In that case, it seems css:text:CellRange is the service that was
thought out for this case, and makes sense. Whether the object returned by
getCurrentSelection() implements that service, or has a property containing an
object that implements that service, I can be live with either.
> Then, in the context of *writer's* (in general case) non-rectangular tables,
> "number of selected columns" makes no sense at all, and pretending that it
> makes sense by providing respective API would be wrong.
Consider this code:
dim rngName as String
rngName = oSel.getRangeName()
dim rngPoints(2) As String
rngPoints = split(rngName, ":")
dim frstCol, lastCol as Long
frstCol = convert_letters_to_number(rngPoints(0))
lastCol = convert_letters_to_number(rngPoints(1))
MsgBox(lastCol - frstCol + 1)
That is _currently_ the notion of "number of columns selected" that the cursor
_already_ has. One would just provide saner/easier access to the same
information. Some of the cells may be split and thus some rows in the range
have more columns that the calculated value? That's just the nature of text
tables, which the programmer will have to deal with.
The LibreOffice UI presents the user with a notion of column and a notion of
row. *Something* happens when one right-clicks on a cell and chooses "Delete /
Delete Columns". Similarly, the cursor on the edge of a table becomes an arrow,
and then clicking selects what is identified, in the UI, as a row or a column.
> Then, the TextTable property would not represent the selection, but the
> whole table (that has *some* of its cells selected). In that view, it's
> unclear how much this code makes sense:
> oCellRange = oSel.TextTable.getCellRangeByName(oSel.getRangeName())
> because, say, oSel.TextTable could be a 3-row table with first and third
> rows having 5 cells, and second row having 2 cells; and oSel.getRangeName()
> could be "B1:D3" - what is there in 2nd row selected?
I believe that _is_ well-defined within LibreOffice, at least at the UI level.
The definition might not be straightforward, it might not be easy to understand
or immediately intuitive, but it is there. The UI doesn't let one select any
set of rows, only "generalised rectangles", which can be expressed as "LD:LD"
where L is letters and D is a digits. The selection is shown in this syntax in
the status bar (along with the name of the table).
So to get the answer to your example, just put the mouse pointer in the B1
cell, press the mouse button, go to the D3 cell and release the mouse button.
That's the "B1:D3" selection and getCellRangeByName("B1:D3") should (and I
expect already does) refer to the same range.
Answering your question cannot be done, because it is underspecified, it
depends on the fine structure of the table.
> Does getCellRangeByName do the same as mouse selection?
Yes, we have to be consistent. Mouse selection calls that "B1:D3", why have a
different understanding of the same string?
> In that case, enumeration access makes the most sense.
It can make sense, but people will need to access the 2D structure of the
table. Since text tables are "weird", they _will_ get weird corner cases if
they expect to operate on arbitrary text tables. We _should_ provide them the
API access to be consistent with the UI behaviour, with the same notion of
column of "generalised rectangle", etc.
--
You are receiving this mail because:
You are the assignee for the bug.
[Libreoffice-bugs] [Bug 151840] API: Text Table Cursor has no notion of row and columns, and no sane way to loop through the selection
https://bugs.documentfoundation.org/show_bug.cgi?id=151840 --- Comment #7 from Mike Kaganski --- (In reply to Rafael Lima from comment #6) First of all, cursor is not a table. Implementing XTextTable in the cursor would be a wrong mix of concepts. Then, in the context of *writer's* (in general case) non-rectangular tables, "number of selected columns" makes no sense at all, and pretending that it makes sense by providing respective API would be wrong. Then, the TextTable property would not represent the selection, but the whole table (that has *some* of its cells selected). In that view, it's unclear how much this code makes sense: oCellRange = oSel.TextTable.getCellRangeByName(oSel.getRangeName()) because, say, oSel.TextTable could be a 3-row table with first and third rows having 5 cells, and second row having 2 cells; and oSel.getRangeName() could be "B1:D3" - what is there in 2nd row selected? Does getCellRangeByName do the same as mouse selection? In that case, enumeration access makes the most sense. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 151840] API: Text Table Cursor has no notion of row and columns, and no sane way to loop through the selection
https://bugs.documentfoundation.org/show_bug.cgi?id=151840 --- Comment #6 from Rafael Lima --- (In reply to Mike Kaganski from comment #5) > So if you think there should be something new implemented, there should > appear some specific discussion which scenario is simplified (or even > becomes possible) with the new stuff, and why it is relevant. To be honest, I'm not an expert in API design, so my arguments are from a end-user perspective only. Initially I wish it were possible to run the following code in a Writer document with a table selected (assuming that the selection implemented XTextTable): oSel = ThisComponent.CurrentSelection If HasUnoInterfaces(oSel, "com.sun.star.text.XTextTable") Then ' For the sake of an example, print the number of rows selected MsgBox oSel.getRows().getCount() End If But maybe the code above is a bit naive. >From your suggestion, if the CurrentSelection had a TextTable property, the same could be written as: oSel = ThisComponent.CurrentSelection oTab = oSel.TextTable MsgBox oTab.getRows().getCount() Is this what you're proposing? -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 151840] API: Text Table Cursor has no notion of row and columns, and no sane way to loop through the selection
https://bugs.documentfoundation.org/show_bug.cgi?id=151840 --- Comment #5 from Mike Kaganski --- (In reply to Lionel Elie Mamane from comment #3) > This is a table, it has a 2D structure. That structure should be accessible > as such in the API. ... (In reply to Rafael Lima from comment #4) > I would also support the implementation of XCellRange, since it provides > access by row/column. ... No, it doesn't work that way ;) It's not OK to implement whatever interfaces *could* be nice to have; there should be a reason to add anything. For example: why do I need a TextTable property, or XEnumerationAccess. Consider the code: oSel = ThisComponent.CurrentSelection If (HasUnoInterfaces(oSel, "com.sun.star.text.XTextTableCursor")) Then ' I want to get the table object where oSel is in; I can only do that ' using a workaround now: oViewCursor = ThisComponent.CurrentController.getViewCursor() oTab=oViewCursor.TextTable ' I need to iterate the selected cells, without any specific order; ' say, I need to format the paragraph inside... oCellRange = oTab.getCellRangeByName(oSel.getRangeName()) ' ... End If If I had either of the things I mentioned, the task would become easier; and additionally, the XTextTableCursor could arrive not only from selection, but also from some programmatic way, without having corresponding view cursor, which would make the task impossible. So if you think there should be something new implemented, there should appear some specific discussion which scenario is simplified (or even becomes possible) with the new stuff, and why it is relevant. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 151840] API: Text Table Cursor has no notion of row and columns, and no sane way to loop through the selection
https://bugs.documentfoundation.org/show_bug.cgi?id=151840 --- Comment #4 from Rafael Lima --- I would also support the implementation of XCellRange, since it provides access by row/column. Also, the current selection should allow to access the selected TextTable object, which is currently not possible. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 151840] API: Text Table Cursor has no notion of row and columns, and no sane way to loop through the selection
https://bugs.documentfoundation.org/show_bug.cgi?id=151840 --- Comment #3 from Lionel Elie Mamane --- (In reply to Mike Kaganski from comment #2) > I'd say - having a TextTable property, and implementing > com::sun::star::container::XEnumerationAccess to > iterate cells, would possibly cover the majority of problems? This is a table, it has a 2D structure. That structure should be accessible as such in the API. From the general cursor point of view, I'd say the bare minimum is to get the current position, and "jump" to a position, with two integers being row number and column number. Plus, since cells can be merged, need some way to know which (row, column) pairs are valid cells and which are not (because they have been merged and they not the "first" (top/left-most) cell in the merge). The API seems to be already defined in our idl files, but not actually exposed? css:Text:TableRows, which exposes the same css:table:XTableRows that the service css:table:TableRows exposes (but no XEnurmerationAccess, while css:table:TableRows does, so your idea to add that makes sense there at least). css:text:CellRange exposes css:table:XCellRange, like css:table:CellRange does. One might believe this may be an API design error, since css:table:XCellRange:getCellByPosition() returns a css:table:XCell (and one might believe a text table cell cannot necessarily provide that interface), but actually the css:text:Cell service provides the css:table:XCell interface, so at least it is consistent. To me, it looks like the API is there, we "just" need to implement it (if that is not already done?), and provide the objects that implement it where reasonable. For example, for my initial use case which prompted me to start this discussion, it looks like if ThisComponent.getCurrentSelection() returned an object that implements css:text:CellRange I would be (mostly?) happy. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 151840] API: Text Table Cursor has no notion of row and columns, and no sane way to loop through the selection
https://bugs.documentfoundation.org/show_bug.cgi?id=151840 Mike Kaganski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Mike Kaganski --- (In reply to Rafael Lima from comment #1) > What do you think of this? Should this be a NEW or a WF ? As I mentioned there, I share the frustration about the object. > Are the necessary changes in the API too complex? No. The question is - what is necessary? I'd say - having a TextTable property, and implementing com::sun::star::container::XEnumerationAccess to iterate cells, would possibly cover the majority of problems? -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 151840] API: Text Table Cursor has no notion of row and columns, and no sane way to loop through the selection
https://bugs.documentfoundation.org/show_bug.cgi?id=151840 Rafael Lima changed: What|Removed |Added CC||mikekagan...@hotmail.com, ||rafael.palma.l...@gmail.com --- Comment #1 from Rafael Lima --- Apparently, there's no easy way to do this. See: https://ask.libreoffice.org/t/modifying-selected-cells-in-writer-table-through-a-macro/48076/2 @Mike, I'm CC'ing you since you are one of the respondents in the link above. What do you think of this? Should this be a NEW or a WF ? Are the necessary changes in the API too complex? -- You are receiving this mail because: You are the assignee for the bug.
