Open sratz opened 1 month ago
Both options sound good to me. I would be in favor of option 2, as it might be good to still have the chance to enable the bar. Two thoughts on that:
setData
) for widgets.Both options sound good to me. I would be in favor of option 2, as it might be good to still have the chance to enable the bar. Two thoughts on that:
- Maybe the feature should be opt-in, i.e., disabled-by-default to be consistent with the other browsers in terms of defaults.
Good idea!
- Is there already a documentation of such (OS-specific) customizations? Would be great to have some central place documenting "non-API" (potentially OS-specific) configuration options (via
setData
) for widgets.
I was wondering the same and also whether the naming scheme with internal.win32
segments makes sense here. After all, this is not an internal API but to be set by the user.
I was wondering the same and also whether the naming scheme with internal.win32 segments makes sense here. After all, this is not an internal API but to be set by the user.
I think this must be something public available on all OSes otherwise it is to cumbersome to use (e.g. I can't reference it but need to copy the string constant or even need platform dependent compile and so on).
The usual pattern here is to mention in the documentation that it is a only a hint and not supported on all platforms.
That way one can express the intend to enable/disable a feature in a platform independent way.
Edge - by default - shows a status bar when hovering a link:
All the other browser implementations (WebKit, IE) do not.
For an embedded use-case in RCP applications showing such a status bar is typically not desired.
The internal WebView2 API is already there:
org.eclipse.swt.internal.ole.win32.ICoreWebView2Settings.put_IsStatusBarEnabled(boolean)
, butEdge
implementation to switch it off by defaultBrowser
API to toggle itI see two options:
Widget#setData(String, String)
, similar to https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=2349244f390a9927eab593ddc499b71cb3f0a70b, to avoid having to add actual new Java API:Option 1 would be trivial.
Option 2 not so hard either:
What do you think?