Community
Participate
Working Groups
3.3 M6 There is currently no way to get at the active and inactive hyperlink colors used by the Link widget. JFace has the concept of inactive and active hyperlink colours which were added before the Link widget was created. We would like to remove these entries from the theme and deprecate the methods in favour of an SWT solution that matched the Link widget.
On Windows, there is no concept of active and inactive for the native link control. We can return COLOR_HOTLIGHT (the color for a hyperlink or hot-tracked item). Need to investigate the other platforms. Fixing this would require new API for 3.3.
We should not do this for 3.3. There isn't obvious operating system support for both states (on Windows for sure). There might be a hack we could do to somehow get the values but I'd be afraid of introducing API that we could not implement.
Mylyn needs this in order to get the nice OS-specific hyperlink color that appears on Preference page Links into other widgets (i.e. Task List active task switcher, bug 194098). The JFace hyperlink color is way off from the lighter hyperlink color that matches the lighter widget color on Vista. For now we are using the best lowest-common denominator shade that we could find.
Any plans to fix this in 3.4?
Steve?
We could add API to get a single Link color (but not the color for active and inactive) but we are past the API freeze. Is one color good enough?
I'm not sure. So presumably, this would mean that in high contrast mode (see bug 163335) the color that is returned would be visible (which would be better than the current situation), but in either case, we'd still have to compute some variation of that color to use as the inactive color. Yes?
I think it isn't that easy - I don't think we can ever say that the inactive color is based on the active one. Computing a variant would likely not be helpful for a low vision person as they may not be able to differentiate subtleties like that. I think computed colors are rarely if ever a good option for low vision. Having said that there is no reason why we couldn't just make active and inactive the same for the reduced palette. The user could change one if they preferred. This is a much better solution than have Eclipse startup with unreadable text as it stands now. I think Steves solution is a good compromise that we could work with.
In GTK we can use gtk_widget_style_get (GTK_WIDGET(link_button),"link-color", &link_color, NULL); But that only works if "link-color" is defined in the RC file. When "link-color" is not defined in the RC file (which is normal case), Gtk uses hardcode color values in GtkLinkButton.c Gtk also defines "visited-link-color", it doesn't have a "disable-link-color". One idea is to use to use the same color of disable text for disable/inactive link.
Is this targetted for 3.4?
(In reply to comment #10) > Is this targetted for 3.4? I don't think so. We tried, but GTK and Carbon don't offered API for this.
Given that Windows is the OS most used by people with disabilities would a Windows only solution be an option? We could write our code to check for the platform.
We won't fix this for 3.4. It requires new API, we are past API freeze and there is still some question where we would get these colors from.
Any plans to fix this for M4?
>Any plans to fix this for M4? No longer a must have for me at this time (see comment in bug 83408).
Your bug has been moved to triage, visit http://www.eclipse.org/swt/triage.php for more info.
Any plans to fix this for 3.7? The inconsistency between parts of Eclipse using SWT's Link widget (light blue on Windows 7) and other parts using Hyperlink and FormText (dark blue) has been flagged during a UI review.
(In reply to comment #17) > Any plans to fix this for 3.7? Probably not, see comment 11
Isn't that a common theme in SWT? Some UI toolkit offer more capabilities than others, but you don't cater to the lowest common denominator. The API is either backed by native capabilities if available or simulated if not available.
We have added SWT.COLOR_LINK_FOREGROUND and implemented on all platforms (cocoa, win32 and gtk). Code has been release to master (4.3 branch). Note that no platform has the concept of two colors for links (active and inactive). So only one color has been added. There is still work to be done in Jface to start using this color. http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=7c92d5ff0643958336782e2069edc7bbe8f71d49 http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=40f0666725aa9b62387fe88a595b4779150ca9e9 http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=6d3d38cb0da75c6fb82119f8ae008e1e6eae0d4f
Thanks! I verified on Windows 7 that the color is the same as the one used for links in StyledText, IE and Windows dialogs (0, 102, 204).
Fixed @since tag as told by API tooling: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=114654733d23d3bfdbf0907418ef59037365ff3d
Marking as 4.2.2+ as part of flagged accessibility work. John A, need PMC approval for new API to be backported...
All changes have been backported to 4.2.2+. The @since needed to be 3.100.
(In reply to comment #24) > All changes have been backported to 4.2.2+. > The @since needed to be 3.100. No, that is wrong. When you backport an API to a + branch, then you should use the original version and add an API filter.
If SWT in 4.2.2 is 3.100.2 and in 4.3 it is 3.102.0, what should it be in 4.2.2+? 3.100.3 with an API filter? PW
(In reply to comment #26) > If SWT in 4.2.2 is 3.100.2 and in 4.3 it is 3.102.0, what should it be in > 4.2.2+? 3.100.3 with an API filter? > > PW My comment was regarding the since tag only, where one should just copy/backport the code together with the same tags. Now to the bundle version: Unfortunately, SWT forgot to update it for 4.2.2 and it is still 3.100.1 as in 4.2.1. Therefore, we can now use 3.100.2 for 4.2.2+. And for those who wonder why it is 3.102.0 in 4.3, see bug 401797. The version in the pom.xml also needs to become 3.100.2.
Bundle version changes, in HEAD: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=d656184dd6a99bf5e254797877b60c9f3390841b and in 4.2.2+: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R4_2_maintenance&id=dd72e17e6a786e006871fd868a98e644c49739cd and in 3.8.2+: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R3_8_maintenance&id=5127a66382957624f2207d05786f17678a9b3a76
The 4.2.2+ code changes (forgot to list them in comment 24) were: Win32: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R4_2_maintenance&id=02c17f1c8d4074b0e087c0d57dfc9c89349ca556 Cocoa: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R4_2_maintenance&id=dd8fe47b118a07ff4c152abde91668af6402b14b GTK: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R4_2_maintenance&id=eccb7e5f60fc58262d44b4aa3c5e8db2db1b2d08 Fixed @since in master (changed to 3.102 to match comment 28 bundle changes). Fixed @since and added API filters in 4.2.2+: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R4_2_maintenance&id=10ea7fc04dbbd7b17fe87ea708ebab916928535b http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R4_2_maintenance&id=e083d14927cb0e072ee3b3a03078b7b525de8686 Backported code and fixed @since and API filters in 3.8.2+: Win32: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R3_8_maintenance&id=b2af863631ea604a1b66c934012588a42a887494 Fixed @since and filters: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R3_8_maintenance&id=fe0d79b8ef1cf2840c6a674133367c6daf932a14 http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R3_8_maintenance&id=b55403b0a42ca5a7d4b33ebef7a385841f8466de Cocoa: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R3_8_maintenance&id=7dcdc397b40cfcf0534058d5dff81a8c594ddcec Gtk: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R3_8_maintenance&id=55d5d306b797562168d170020df67157cb631400
*** Bug 130444 has been marked as a duplicate of this bug. ***
