| [news.eclipse.platform.swt] Re: Closer native OS idiosyncrasies support / SWT Style constant |
|
Emil Crumhorn wrote: I have been working on getting Carbon SWT & Eclipse itself to look more like a real native Mac app. In doing that, I bumped into the lack of abstraction in the SWT implementation (most things are classes rather than codified behaviors and their implementation 1) is quite bound to the org.eclipse.swt package 2) makes it difficult at times to extend them ). When looking inside the Workbench itself, the situation gets even more complicated (i bumped into the 'work in progress' trail that deals with decoupling some of the ContributionManager derived classes from their supporting widgets. another example was the refactoring I had to do in order to make the PerspectiveSwitcher behave more like other conceptually equivalent sections of the code. none of these are difficult problems to solve, but they do exist (at least in my mind). At the moment, the SWT widget set implementation (but more so the workbench itself) reflects a "line-in-the-sand" approach to supporting the native platforms. My exploration has shown me that this line can be brought closer to the native Mac OS without compromising the other SWT goals. What I am looking for is a "marker" style value that could be used to move that line on a case per case basis: using that marker style would mean that "for the cases where the SWT behavior significantly differs from what the OS offers, using this style would guarantee that a less SWT-ish and more native implementation would be activated". the idea behind this is 1) break nothing / change nothing 2) opportunistically (possible / doable / desirable) fly closer to the metal, granted that the application will then potentially behave differently on the different platforms (like in the case of what I did MessageBox and PrintDialog which are using Sheets on Mac OS when SWT.NATIVE_LOOK is used). You can immediately see that a single flag might not be enough... and it might be soon time to add an EXTENDED STYLE 32 bits mask for new optional styles I'm not quite sure what you're asking for, but somehow magically making widgets behave natively via a flag would probably be every IBM SWT developer's dream, but that's not reality. I know this argument, and it is the best way to do nothing because there is no perfect solution. If you remember, this is the exact kind of arguments that people used to justify the way Swing behaved and if you recall, it led to ... oh .. that's right. it led nowhere and Java missed the biggest opportunity to be relevant on the desktop. But hey... what more could we have wanted: Swing was very consistant. Because it could do nothing that stood out on any platforms, it succeeded in been equally ugly and boring on all the platforms it supported.There's a hundered things Windows has that other OS's cannot do, and vice versa for every OS. How do you imagine custom features working just via a flag? What if windows supports combo boxes with images in them, how would one flag work to tell the combo to use an image? That's the whole thing, you can't have a bunch of method calls that do nothing on some platforms and nothing on other platforms, or the whole community would either be in uproar or complete confusion. I find it quite interesting to see that SWT is now bogged down in the same quicksand pit. Because I am not a real programmer I don't see the world in terms of absolutes... I think everything is about compromising. And I think that there is another comprise that to only address ugly (I contend that at the moment SWT has addressed only "ugly", and I find it unfortunate that so many people seem quite content to keep it "boring"). Furthermore, if you read my post, you'll see that I am not talking about supporting everything everywhere as the alternative to the current 'lowest common deminator approach'. I am merely talking about loosening the current status-quo. My own opinion is that SWT is aging... th I happen to be quite familiar with SWTThere area already a select few SWT flags that may do nothing on other platforms, but as far as I know there's a lot of discussion before one of those is added. Now, SWT is native already, that's the whole idea, I suggest reading up on the history of it on wikipedia http://en.wikipedia.org/wiki/Standard_Widget_Toolkit to give you an idea of the reason why it was developed and why it is being developed the way it is. I disagree with you... I believe that the world is made of shades of gray, not black or white exclusively. I invite you to look at whichever bug I opened where I tracked my changes to use the native toolbar on Mac OS. All the changes I made bring Eclipse closer to native Mac OS behaviors without introducing weird APIs or braking the cross platform compatibility (the same workbench works on the other platforms, and actually looks like the other platforms if you do not install my custom presentation.On OS X thanks to different API's on Mac's side.. Cocoa and so on.. and changes in in the newer OS X versions, it's not exactly easy for the SWT team to just make everything suddenly native on a whole new OS API. They're working on it, do some searches (for example Steve Northover's blog http://inside-swt.blogspot.com/ or more specifically http://inside-swt.blogspot.com/2007/11/hacking-at-apple.html ), but it's not an overnight thing. If you truly wish to override the code to make your UI appear more native than it currently is, you'll have to extend classes that will make your code non-cross platform (such as classes in SWT that are marked as "not intended to be extended"), and most likely cause a whole bunch of new issues. Another options is that you write code in native Cocoa or such and create JNI bindings that connect to actual platform code. All of that will make your app Mac-only of course. Like I said to other people on this list.. if none of that goes anywhere, I still have the pleasure of running a visually unique Ganymede on my Mac (sorry, but quite frankly after many years seeing the same look on all platforms, I have grown quite bored with it). At the moment I defined SWT.NATIVE_LOOK as 1<<24... cheers, LM/ Regards, Emil -- Nebula Committer http://www.hexapixel.com "L. Mihalkovic" <totolaricot@xxxxxxx> wrote in message news:g1433l$k6o$1@xxxxxxxxxxxxxxxxx... -- Laurent Mihalkovic, co-author SWT/JFace in Action (www.manning.com/scarpino) |