Community
Participate
Working Groups
Follow-up from splitting bug 8521: As a counterpart to the StyledText::getSelectionRanges API (bug 250171), clients also need to be able to set the block selection to the widget. Therefore, I request the following API: void setSelectionRanges(int[])
This is a blocking requirement for bug 19771, because there are many places where the text editors store the widget's selection in order to restore it later (e.g. after a compound operation).
Not sure how this API will work. Is very unlikely that all start/length pairs will form a rectangle. What to do when one start offset and the next are not in the same column ? the only solution i can think of is: block lead edge = minimum lead of all start offsets block trail edge = maximum trail of all end offsets is that what you expected ? ------ Why do you need this API ? is to restore the state when eclipse restart ?
(In reply to comment #2) > Is very unlikely that all start/length pairs will form a rectangle. What to do > when one start offset and the next are not in the same column ? Hm, I understand. My request does not make sense.... Does the normal setSelectionRange(int,int) call work during block selection (i.e. select the rectangle between the start and end point)? In that case, I could use it to restore the selection. > Why do you need this API ? is to restore the state when eclipse restart ? Not just on restart. There are numerous places where the current selection is remembered, then some more or less complex operation occurs (as an example, consider "Organize Imports"), then the selection gets restored. The goal is that the user does not perceive any selection change, even though the character range(s) covered by the selection may differ from the situation before the operation. In order to really maintain the exact same selection, I would need get/setBlockSelectionRectangle which would work pixel based.
(In reply to comment #3) > Does the normal setSelectionRange(int,int) call work during block selection > (i.e. select the rectangle between the start and end point)? Yes. the selection rectangle is defined by the left-top corner of the character at start offset and right-bottom corner of the character at end offset. > In that case, I could use it to restore the selection. Let me know if it works. > > Why do you need this API ? is to restore the state when eclipse restart ? > Not just on restart. There are numerous places where the current selection is > remembered, then some more or less complex operation occurs (as an example, > consider "Organize Imports"), then the selection gets restored. The goal is > that the user does not perceive any selection change, even though the character > range(s) covered by the selection may differ from the situation before the > operation. > In order to really maintain the exact same selection, I would need > get/setBlockSelectionRectangle which would work pixel based. Yes, but if the text under the selection rectangle changes during these operations the actual selected text will change.
(In reply to comment #4) > > In that case, I could use it to restore the selection. > Let me know if it works. Will do. I removed the blocking flag. > Yes, but if the text under the selection rectangle changes during these > operations the actual selected text will change. Yes - but that is typically ok from a user's perspective. We try to keep the "logical selection" stable, even if the actual range differs. Imagine you have a method or a couple of statements selected, then press Ctrl+Shift+O to organize the imports - you certainly don't expect the selection to be somewhere completely different. What we do is we compute the logical start and endpoints of the selection before the operation, then track the content modification and the set the selection accordingly. In block selection mode, it will not be enough to just track the start and end offsets of the block selection, but also the pixel offsets relative to these offsets.
Tom, should I close this problem report ? I hope you can do all you need with setSelectionRange(int,int). If not, we could look into adding getBlockSelectionRectangle/setBlockSelectionRectangle().
Access to the pixel-based block selection would be good in order to fix bug 19771 properly and transparently. I changed the summary accordingly.
(In reply to comment #7) > Access to the pixel-based block selection would be good in order to fix bug > 19771 properly and transparently. I changed the summary accordingly. is this a blocker for 19771 ?
(In reply to comment #8) > is this a blocker for 19771 ? Hard to say for sure at the moment, as I haven't looked at how to convert the previous setBlockSelection calls to the new calls. I don't think it is a hard blocker.
This is still an issue surfacing at various places in the text editors. It is now possible that the user creates a selection that cannot be reproduced programmatically. It is also possible that the same selection ranges are answered for two selections that look very obviously different from each other. Look at bug 262625 for an illustrated example. There is a strong need for platform-text to determine and restore the exact selection as it is displayed by the widget. This includes selection over the end of line.
What getBlockSelectionRectangle returns when the block selection is not up ? a) null b) emtpy rect c) the rectangle of the regular selection, ----what if regular selection is empty (start==end) ? c.1) caret bounds What setBlockSelectionRectangle does if block selection mode == false ? a) ignore b) set block selection mode = true, and set the block selection Will it need to scroll to show the new block selection (when it isn't in within the client area) ? Steve: I have these APIs internally already, it is just a matter of deciding a few questions. We have very little time to add new APIs.
> What getBlockSelectionRectangle returns when the block selection is not up ? > a) null > b) emtpy rect > c) the rectangle of the regular selection, > ----what if regular selection is empty (start==end) ? > c.1) caret bounds No strong opinion, you could even throw the SWT complement of IllegalStateException or alike. c) does not really make sense, since a linear selection is not a rectangle. I would prefer b) over a) as null is always problematic. The API could state that the returned rectangle is not well defined if the widget is not in block selection mode. > What setBlockSelectionRectangle does if block selection mode == false ? > a) ignore > b) set block selection mode = true, and set the block selection Again, using this API in non-block mode seems an error to me. b) seems dangerous, so I would prefer a) or an exception. > Will it need to scroll to show the new block selection (when it isn't in > within the client area) ? No - I would expect the API to behave similar to setSelectionRange, which does not reveal the selection. Clients can always call showSelection to achieve the same.
Created attachment 129626 [details] patch (incomplete)
Missed M6, we will need PMC approval for new API.
Definitely major for text land: without this, using block selection mode in editors is a pain in many situations (see blocking list).
Steve, I have the code ready. Are you okay with me sending the request to PMC ?
Yes, the API is needed. Please request on the PMC list.
Created attachment 132128 [details] patch
Thanks guys!
Fixed in HEAD > 20090417 (sorry it took so long)
> Fixed in HEAD > 20090417 Cool! ... although now I probably have to come up with fixes for those other bugs... grrr. :-)
