Community
Participate
Working Groups
The main goal of SWT is A) to provide a portable widget set using native widgets on all the platforms it supports. Over the years, it has demonstrated that this was a do-able do. This enhancement request is to try to add a twist to the mix: B) also provide support for non-portable platform idiosyncrasies, when this does not compromise the previous goal. A good example is the notion of Sheets on Mac OS X. This behavior does not have an equivalent on any of the other platforms supported by SWT. As such it is natural to want to eliminate it from SWT's feature set. However it is also a trivial feature to support (no API changes required), that adds tremendously to the feel of a native Mac app. To support the seemingly contradictory goal of remaining familiar and portable across all the supported platform while supporting on each one a limited subset of non-portable unique features seems like an oxymoron, however I believe it is actually remarkably simple. To demonstrate the feasibility of this idea, I have explored two ideas: 1) the creation of a global SWT level flag to trigger the activation of platform specific idiosyncrasies 2) the creation of a new SWT.NATIVE_LOOK style constant 1) is trivial to implement and consequence free, however my choice goes to 2) as it allows a finer grained control over what is activated for each application. The meaning is simple because in the worst case scenario nothing happens, nothing gets changed, and the application looks and behaves the same. Anything else is left to the implementer to respect the two SWT goals (A & B). I tested the concept by adding support for Sheets to the PrintDialog and MessageBox classes (see screen captures). NOTE: I also considered a third alternative based on some kind of a SWT widget factory that would work based on voluntary registration by the widgets. This approach has the advantage of addressing another goal: to be able to transparently replace a widget implementation with a functionally equivalent but different one (I played with that to try to create an MToolbar that would be a placeholder for the current Toolbar). This would not brake any code that does not use the factory for instantiation.
Created attachment 101688 [details] PrintDialog as a Sheet on Mac OS
Created attachment 101689 [details] PrintDialog as a Sheet on Mac OS (part 2)
Created attachment 101690 [details] MessageBox as a Sheet on Mac OS
+1 for this. There are a fair number of Windows idiosyncrasies that are supported (Vista progressbar styles, etc), I don't see any reason not to support this. With regards to the API, I don't really like the idea of a generic SWT.NATIVE_LOOK flag. What would be nicer is to have specific flags for each custom style. For example, the Dialog class would accept a flag (e.g. SWT.SHEET) which would only affect the LAF on Mac. This sort of thing isn't unprecedented (SWT.SEARCH). Of course, this idea could be extended to other platforms, improving support for platform-specific functionality on Linux and Windows as well. I personally think this would be a big win for SWT in general and probably improve the Eclipse experience as well.
The normal way of supporting platform specific features is to use hints. Sometimes they are expressed as style bits. For example, it might make sense to have SWT.SHEET to support sheets on the Mac. This would do nothing on Windows or the other platforms. Another alternative is to add API that will fail on platforms that don't support it (ex. shell.setSheet(boolean)). *** This bug has been marked as a duplicate of bug 121420 ***
I am not sure how you can come with the conclusion that this is a duplicate of 121420... the point of this enhancement is NOT to resolve 121420, but to talk about a different way to address what is a general shortcoming of SWT: it is close to the metal, but not quite close to the metal enough. Like Swing before, SWT suffers from the lowest common denominator syndrome. I think this is partially due to the fact that you look at each of these instances as unique problems. I am aware that in SWT, "the normal way of supporting platform specific features is to use hints". but I am not sure this is working considering the number of problems like 121420 that remain opened for a long time... granted the SWT team is small and there are a lot of things to do. Considering it took me 2 hours to add that the the current PrintDialog(), with no experience of Mac programing, I can't imagine technology was really the show stopper for 121420. So I started to think that it is the approach that is a problem, because it forces the scope to be extended to all the platforms before any move can be made on either of them, even in situations where it is not necessary... hence this enhancement request... I was even thinking that in a sense there could be a generic SWT level flag set by the developer that would enable/disable platform specific idioms. The reason being that it would be possible for companies like IBM to privilege the cross platform similarities (like for Notes .. it MUST behave like Notes everywhere), versus others who might want a more local feel. But for that, you guys have to accept to rethink some of your current thinking... the good news is it's got nothing to do with what I think/believe.. Swing has made a huge comeback, and it is not excluded that Swing will soon do a much better job at giving great performance/local-feel than SWT does.
Created attachment 102297 [details] PrintDialog patch the code to use a Mac OS native Sheet
Created attachment 102402 [details] FileDialog displaying as a native Sheet (SWT.SAVE only)
Created attachment 102404 [details] FileDialog (result)
Created attachment 102410 [details] PringDialog() patch posted the wrong version...
I don't understand what SWT.NATIVE_LOOK does or how it differs from a style bit hint. Is the idea to have a single bit that turns any combination of native features on? If so, the bit should always be set. If SWT.NATIVE_LOOK really just toggles sheet behavior, then we should just have SWT.SHEET or setSheet(boolean). Specifically, what should we do to absorb your patch, other than implement SWT.SHEET? If this bug report is a placeholder for discussions about "hinting" and various ideas about how this can be done, that's fine too.
Look, in the end you guys own SWT and know better than anyone else where you want to take it. but here is what I noticed (my comments will be prepended with a number) SWT PREMISE: to create a Java cross platform widget toolkit using the platform resources (this is my translation of what I have seen SWT do on the platforms it supports) 1) This premise is in my mind ambiguous because it is not specific enough about some features that are really idiosyncratic to each of the platforms it supports. GUI toolkits are such that at this point in time they share 90% of the feature sets, and even how these features are presented to users. but what happens with the remaining percentage. Over the years, the sophistication of the programers and users evolves, and what was acceptable yesterday sometimes is not longer acceptable tomorrow Coming back to the SWT.SHEET: Bug 121420 has been around since 2005... when I looked at supporting Mac sheets, not in general, but for the print dialog only, it took me 2 hours, most of it being research in Apple's doc to implement it (never wrote a Carbon app). transposed to you guys who have much more experience, it would have taken even less time. So came thought #2 2) technology is not the issue that has stopped 121420 from being resolved since 2005. Aside from the team being small and pulled into many fires, I noticed that part of the problem could simply be that the feature is so idiosyncratic that there is no universal way to integrate it 'cleanly' into SWT. I drew this conclusion from steve's comments on 121420: If we start using ShowSheetWindow(), I'm afraid that Eclipse tool tips and other shells without trim will start opening in the wrong place. and also One possibility is to use ShowSheetWindow() for modal shells only, however, dialogs without trim on Windows look out of place so application code would need to do a platform test and use the appropriate trim. 3) creating SWT.SHEET is not a problem in itself. This is how the rest of SWT is built, which has proven to resist the test of time. However in my mind it becomes a problem when it is the first of many more to come for all the other platforms. Today there is a perfect example: SWT.SEARCH. I noticed that some people already pointed that it "does not work on Linux and Windows". I see it as if it already happened: people asking left, right and center why this or that flag does not work on such or such platform. So unless you want to spend the time explaining, I started to wonder if there was any alternative that would remain in line with the SWT philosophy and avoid this problem. Then I got to think about another possible requirement... what about IBM itself and Lotus Notes (I know at least about his one product, but you know better than I can how many more exist). How would the Notes product manager like to have to pay for some extra documentation for each of the platforms, or how would they like to have the product behave differently on all the platforms (if you take SWT closer to the metal than the happy compromise it sits at right now, it will undoubtedly happen). So, if this is a real requirement put on the SWT toolkit, then the idea of SWT.SHEET, SWT.ssss, SWT.CCCC, ..... and all the variations in behavior does not strike me the right answer. So my goal is to try to find a solution that would = remain in line with the SWT gaol of cross platform support for the happy 90% of common features = not introduce many platform specific jargons (flags and stub APIs) on the way to bridge closer to 100% = retain the ability for cross platform products vendors to not become sucked into local platform idiosyncrasies if they do not want to incur the extra cost for documenting their products Now, on to SWT.NATIVE_LOOK I know that SWT.NATIVE_LOOK is not good. First off, it is a deplorable name: because as you pointed out, native look is the core goal of SWT, and not an option. A better name might be SWT.NATIVE_BEHAVIOR or SWT.IDIOSYNCRASIES (boy this one is even worse for other reasons). It is also bad because it forces control to be exercised by the programmer, when I think it might be a runtime configuration item. At the moment, I also used SWT.NATIVE_LOOK to drive configuration of the native Mac toolbar (but I am not married to it). What I want to avoid is to find myself boxed in a corner when I move on to other idiosyncratic behaviors, on the Mac or other platforms, and end up slapping my forehead "darn... if only I had spent 5 minutes thinking about this one before..." On the question of absorbing my patch, at the moment I changed the code to use the existing SWT.WINDOWMODAL (versus SWT.APPLICATIONMODAL). So it looks like the Sheet problem can be entirely solved with what it already in SWT. Ultimately, SWT is yours, and I know it. I started this enhancement because I think that the current SWT.xxxxx hint philosophy has carried SWT until now, but if SWT is to go closer to the metal in the future, I believe this philosophy needs to be extended with a different mechanism (we did not talk here about the fact that you may soon run out of bits for some of these styles. or the fact that people have complained about how confusing the current SWT.xxxxx constants set has become over the years). ------------- How about something like this: static void SWT.enable(FEATURE.NATIVE_BEHAVIOR); static boolean SWT.isEnabled(); to be used to control this and possibly other intangible platform wide characteristics (for example, a hypothetical FEATURE.WINDOW_TRANSITIONS where some kind of animation behaviors would be devised accross the board for fading windows in or out - another bad example because this is now becoming a standard feature of many of the native widget sets). Don't get me wrong... when all is said and done, you tell me how you want it. Give me a value for SWT.SHEET and I will change the code to match.
hmm... I was thinking about this again. SWT.enable()... is about as atrocious as SWT.NATIVE_LOOK The question I am really trying to address is this: how can I enable some options, how can I change eclipse's behavior without having to program much for it. And more importantly, how can I make this future proof so that the mechanism would survive even if the behavior ends-up different. I think this is why the Mac has all these xxxxxGetDefaultYYYYY() APIs where the default values for a structure are initialized by the implementor, not the user. This allows them to control behaviors from behind the curtain and make the platform evolve. I had started working on the idea of a SWTFactory class that would allow this type of situation. So maybe this factory should be placed in charge of creating the default style set for each of the widgets. int SWTFactory getDefaults(WIDGET.XXXXXX) And this should be behind the scene configurable so that it is still possible for some apps to opt out of idiosyncratic behaviors in the same of cross platform uniformity of the user experience. The platform could also be a place to instantiate widgets, allowing some on the fly replacement of the implementation based on some configuration: for example my native Mac OS toolbar versus the current Toolbar/Coolbar. Or something similar to control which browser should be instantiated in cases where 2 are available on the platform. makes any sense ? sorry I missed Steve's E4 presentation at eclipse con... maybe these topics have already been addressed and the solutions devised.. cheers
Part of the major reasoning behind the flags in the first place is to allow just such platform-specific functionality. This is the mechanism which has been determined to be the most "in-line" with the SWT design and the one which has worked quite well for other things (such as SEARCH and ProgressBar(..., SWT.ERROR)). Granted, there are always going to be people who get confused by the fact that SEARCH is just a platform-specific hint, but at the end of the day, this can't be helped. Creating a single, global flag for "platform idiosyncrasies" I think will cause a lot of problems. For example, does that mean we use sheets *and* unified toolbars on Mac? Just sheets? How do we choose one or the other? What sort of idiosyncracies will be supported? By having such broad-brush control, it's hard to define what the behavior is going to be, much less explain such definition to end-developers. I would push for the use of *specific* flags enabling or disabling the specific functionality. (e.g. SWT.SEARCH, SWT.SHEET, SWT.UNIFIED_TOOLBAR(?), etc) As for a value, you should be able to look at the hints available to Shell and their respective values in SWT. Find a bit offset which hasn't been used yet (e.g. `2 << n` where `n` is the offset) and use it. The offset doesn't have to be unique among *all* SWT constants, just unique within the shell hints.
yes. SWT.NATIVE_LOOK is stupid. I was wondering if the hypothetical getDefaultStyle() API I described should not in the end just be a JFace construct... Then all the higher level JFace GUI classes would be able to call this in order to maintain consistency. So in the end, SWT keeps its flury of styles and hints (glad I am not going to be the one responding the questions about what works where and why), and the higher layer has a single place where the application level behavior can be decided. I really think something is missing at the moment, especially after digging for 2 days straight into the platform code for creating the ability to switch between the current perspective switch and one based on the Mac unified toolbar (as i wrote somewhere else, I added a "Title bar" option to the "perspective switch positions" preference) so... what do you want? a new SWT.SHEET or using to use the existing SWT.PRIMARY_MODAL (ooops... I previously referred to it as SWT.WINDOWMODAL) At the moment, my latest version is using SWT.PRIMARY_MODAL/SWT.APPLICATION_MODAL I fixed FileDialog, PrintDialog, and MessageBox, but my goal is to fix eclipse. .. so you can imagine why I want to find some more thoughtful way to go about it.
Wouldn't be suitable to make PRIMARY_MODAL shells have sheet style? According to the Apple HIG[1], sheets should be used when PRIMARY_MODAL is used. Sheets are not used when non-modal behaviour is required, or APPLICATION_MODAL is used. Although, this doesn't resolve all of the problems, it should be a solution which can replace all of the SWT.SHEET usage so far. The problem may arise with multiple PRIMARY_MODAL dialogs in single window hierarchy. Another issue is possible breakage of current applications - they may use PRIMARY_MODAL, although they should be using APPLICATION_MODAL.
Forgot the reference: [1] http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGWindows/chapter_18_section_7.html
The problem is that sheets can't be moved. If the popup and block some critical information in the application, then that's bad. Only the application can know what the right thing to do is. Can we move the sheet discussion over to the sheet bug (bug 121420)?
"Specifically, what should we do to absorb your patch, other than implement SWT.SHEET?" I take it as a somewhat rhetorical question considering the number of times the API freeze has been mentioned in the last month (code requires some changes to OS.class). "Can we move the sheet discussion over to the sheet bug (bug 121420)?" I have no vested interest in holding a sheet discussion. My interest lies in what I think is a larger problem, of which sheets are just the tip of the iceberg (I found more bug reports that have stalled for a number of years for what I perceive to be the same fundamental reason). As for sheets in particular, I explained why I think there is the need for something more thoughtful than a simple flag (I want to them everywhere where they belong in eclipse to make it a great Mac app). In the short term, I fixed what I needed fixed, and now you do what you want with what I have posted. if other people grow impatient like I did, they'll either do what I did, use what I posted, or any combination thereof. Like I said, there is no doubts whatsoever in my mind that you guys own SWT, so like I asked about the Native Mac toolbar, SAY WHAT YOU WANT and I will code it (Cocoa and Carbon). To me, SWT is a tool to help me do my real job: if I need something I ask the tool owner, if it does not come fast enough I do it myself, and when the tool no longer suits my purpose I use another tool (I used to do a lot of Swing before I moved to SWT a few years back) cheers, LM/ note: as far as I can tell, SWT has not evolved a lot over the last 5/6 years. in technology terms that is even considered quite old. I hope that this was at the center of the SWT 4.0 talks.
Danail, can we move the sheet discussion over to the sheet bug (bug 121420)? This bug is tracking the "larger problem", not the specifics of sheets and modal windows. L. Mihalkovic, I also would like sheets to be part of Eclipse but the current thinking is that sheets can't be created for free. In any case, the discussion about how, when and where sheets should be implemented belongs in the bug that is tracking the feature request for sheets, not here.
> I have no vested interest in holding a sheet discussion. If you are providing code that implements sheets, you need to take part in that discussion.
"I also would like sheets to be part of Eclipse but the current thinking is that sheets can't be created for free." I see at least two different questions mixed in this statement 1) sheets and eclipse 2) sheets and SWT ( the last one being the personal opinion of Steve N) 2) --> a 15 minutes no-brainer task for you guys, 2 hours for me (granted that this only buys enablement and nothing else - too bad for the people waiting for these and other similar simple gimmicks to make their Java apps look less like java apps and more like real apps) 1) --> hmmm... an open ended question, subject to a lot of debate in maaaaaany places I find it sad that because 1) could not be solved within the proper philosophical framework that 2) had to be sacrificed (like I said, I found a number of other simple problems that has been postponed for 1, 2 or 3 years because they could not be placed into the "larger philosophical" context). this is really quite funny.. for years Swing was bogged down because the standard L&Fs were stiff about looking the same everywhere rather than fitting everywhere. Then came SWT that decided it would fit. But now SWT is stuck the same way (only a little further along the path of 100% fitting)... for exactly the same reason that stuck Swing for years... It seems Swing is finally getting unstuck.. how long before SWT follows suit.
>"I also would like sheets to be part of Eclipse but the current thinking is >that sheets can't be created for free." > >I see at least two different questions mixed in this statement 1) sheets and >eclipse 2) sheets and SWT ( the last one being the personal opinion of Steve N) my point about 3) is that I am glad that Steve agrees in principles as it at least gives me hope that you guys might decide to address 2) even without having entirely cleared the way for 1)
Please refrain from SWT vs. Swing discussions. It just doesn't add anything of value to the discussion (which is supposed to be about how to expose operating system functionality in a portable manner). To enable sheets for SWT, we need to decide on how we plan to do this (ie. the SWT.SHEET bit, API, do it automatically somehow based on modality ... you got any more?). Once we do this, then the rest of Eclipse needs to decide where sheet behavior makes sense and set the bit (or whatever). But wait ... here I am discussing sheets in this bug report. It's not the right place.
Sheets support was added in 3.5, so I'm marking this as fixed.
