Community
Participate
Working Groups
I20090331-0901. See bug 19825 for a longer discussion. We now agree that this should be a user preference. While we can implement this on top of StyledText it would be beneficial if SWT would offer a global switch for this, so that this behaves consistent in the whole workbench. Otherwise it will work in editors but e.g. not in the Console (until they also react and adopt a new preference). If a global switch is rejected then at least API on StyledText to control this would be beneficial.
I think you should implement it on top of StyledText. The global switch can not work 100% of the time. All it needs to break is one plugin that has one editor that is not based on StyledText, or one plugin that has a styledtext based editor, but forgets to set the option on it...
The right place for the API is in SWT, on a per-StyledText basis. The argument that says "... all it takes is one ..." applies equally, whether the functionality is implemented on top or withing SWT. We are past API freeze and this bug looks low priority to me. Post 3.5?
>bug looks low priority to me. Post 3.5? Sure, I wasn't assuming to get new API after the freeze. >but forgets to set the option on it... Right, that's why my preferred solution is a global option. Look at it like e.g. OS settings for colors or time formatting that we take over and apply. Another reason why I would like to see this in SWT is that this behavior is quite low level and if we do it on top of SWT as you suggest, then all clients that do not or cannot use the editor framework will have to copy the code and I hate to see copied code.
> Right, that's why my preferred solution is a global option. We would never add a global option without allow an instance to override the behaviot. > editor framework will have to copy the code It depends on the application. Only those frameworks that want this non-standard native text editor behavior would "have" to copy the code.
>non-standard native text editor behavior What standard? Different editors on different OSs handle the right-click case differently. From example on Linux gedit does set the caret on right-click but StyledText does not.
... and that is the correct behavior. For fun, I tried it out on Windows, GTK and Mac carbon and no native text editor moves the caret. On my system, gedit doesn't do it either. Perhaps we are talking about something different? My point: The attitude that says "applications will have to copy the code" is flawed. If Eclipse decides to enforce a policy that "right click will move the caret", then this is an Eclipse policy, not an operating system or SWT policy. Those applications that want "Eclipse style right clicking" would have to "copy the code", if they insisted on having this policy and we don't provide support for them (which we will).
>My point: The attitude that says "applications will have to copy the code" is >flawed. Right, but I didn't think of other applications but e.g. the Console view in Eclipse or the Commit dialog, or.... essentially all parts that use StyledText but aren't an editor. If we add a preference and a user chooses that he likes to move the caret on right-click, he'd probably also want this in those places. >On my system, gedit doesn't do it either. That's funny. I didn't touch that Linux box and it's quite old, so not sure whether this is a setting that someone tweaked.
Is there a conclusion on what we want to do here? A global API(per-Shell?), or per-StyledText? I'm assuming we're still interested in this.
(In reply to Abhishek Kishore from comment #8) > Is there a conclusion on what we want to do here? A global API(per-Shell?), > or per-StyledText? Just a state per StyledText instance. > I'm assuming we're still interested in this. This is low priority.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the stalebug whiteboard tag.
