Community
Participate
Working Groups
Now that we have to contend with Cocoa and WPF SWT ports our platform-specific story is getting complicated. We have duplicate conditional logic peppered throughout our codebase and we should address this in 3.5.
Eclipse-on-Cocoa is now being built nightly, and will be an early-access platform for 3.5M2.
I had a look through our uses of SWT.getPlatform() and Platform.getOS()/Platform.getWS(). We use it firstly for "platform specific" setup (sizes that are different on windows/gtk/mac) and secondly for gtk event differences :-) JFace restricts itself ot SWT.getPlatform() but at the workbench level we try both options. Themes makes use of Platform because it tries to take into account both OS and WS. One option that I'm considering is to write a JFace utility class that gathers our common questions (we shouldn't have "win32".equals(*) throughout our code). For those that aren't tied to a specific windowing system (most of my gtk ones are) I think providing isWindows() and isMac() might generalize those 2 questions to what JFace and the workbench need. PW
That being said, should I push through at least the cocoa change for M2? That would align most of the carbon changes to also be supported, but may introduce some problems on cocoa as the org.eclipse.ui.cocoa fragment has not been completed yet (i.e. no preferences menu entry :-) PW
I was going to say yes until you gave the example of the missing preferences menu. For now it's more important to be stable/more complete than to be Mac-like, so if this could introduce strangeness then I'd suggest pushing it to a future milestone.
Created attachment 112555 [details] Centralize window system platform queries Start off by centralizing the platform queries. It looks like all of the carbon queries really are "mac" queries, so I think they can all be replaced with isMac() for now (M3) and we'll keep our eye out for any that need to be changed back. PW
And a reminder to look at SWTKeyLookup before this goes in. PW
And native key formatter PW
Created attachment 113584 [details] take 2 work in progress PW
Created attachment 113622 [details] Cocoa support v03 This implements the helper methods on org.eclipse.jface.util.Util, and I've replaced all SWT.getPlatform() related occurrences of win32, carbon, cocoa, gtk, motif, and photon in the Platform UI and JFace. For carbon|cocoa, I changed them to call Util.isMac(). That's in most places that involve keybindings. For carbon that I found by itself: I changed it to Util.isMac() for items like "on mac use 4 pixels, on gtk use 8 pixels". I changed it to Util.isCarbon() for event related work arounds. For win32 that I found by itself: I changed it to Util.isWindows() for items like "on windows use *.exe, *.com" or pixel widths. I changed it to Util.isWin32() for paint related events and event workarounds. I have added an Util.isMacNow() method for use in the WorkbenchActionBuilder, that can be replaced when the cocoa fragment (or equivalent) is available. PW
Released >20081001 PW
Why hasn't this API been pushed down to the SWT layer. Don't the String constants come from SWT anyway?
(In reply to comment #11) > Why hasn't this API been pushed down to the SWT layer. Don't the String > constants come from SWT anyway? > Sorta ... it looks like the fragment defines this: org.eclipse.swt.internal.Platform.PLATFORM = "gtk"; //$NON-NLS-1$ So SWT is not currently providing a list of known platforms. We could make an API request for constants for all known platforms, although that wouldn't cover other ports that don't come from SWT. SWT wouldn't be providing the convenience methods, those are for UI. org.eclipse.core.runtime.Platform.getWS() also defines constants for the windowing system ... but JFace can't see the runtime, and the runtime can't see the UI. PW
In I20081027-1800 PW
