Community
Participate
Working Groups
Toolbars on Mac OS X Leopard now have a unified appearance with the titlebar - ie there's no visual distinction between the toolbar and the titlebar. The Toolbar section of this doc shows exactly what I'm referring to: http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGWindows/chapter_18_section_4.html#//apple_ref/doc/uid/20000961-BABIFCFJ Correcting this would make SWT apps look so much more 'native' on the Mac. Next step would be to allow coolbar/toolbar placement of buttons instead of default Windows style stacking each side by side. (perhaps that bit is just an RCP issue?)
Those are native tool bars and are part of the window trim on the Mac. Currently, to support tool bars anywhere in a window, we don't use native tool bars (the buttons are native). We need new API to do this. Something like: Shell.setToolBar(ToolBar); Shell.getToolBar(); On the Mac, this would use native tool bars and get the correct look and feel. On Windows and elsewhere, you would get the tool bar that you have today.
Created attachment 97896 [details] A snapshot of my eclipse with a silly native toolbar This is a snapshot of 3.4M6a with a native leopard toolbar
I made many additions to OS.java to support this. I was also trying to fold in support for Actions (to make the creation of these new menu items easier) but I ran into some issues. I am also missing a closer mapping of the current MenuItem styles to my MToolbarItem (MToolbar being the main class that wraps it all). I you have more ideas on how you would like it, I'll keep writing some of the code.
I know that the technical aspect of this one is nothing. when you have a moment, can you define how you want this to work? If you don't mind, also define how you want it for bottom bars. and I will change my code accordingly. At the moment I built everything as a MToolbar and MToolItem, because I did not think you would want any changes made to Toolbar. But if you accepted the creating of a SWT.NATIVE_LOOK or the like, then this generic style could be used in other widgets where there is a choice between native and not but where both have to be supported. alternatively..... the sky is the limit. cheers.
The Mac toolbar has restrictions. It doesn't resize like a cool bar. If it has too many items, what happens? These are the sorts of issues that we need to investigate. Certainly keeping the code in MToolBar makes it easier to see what is happening, debug the code etc.
yes, the mac toolbar has restrictions. but fortunately Apple has a style guide that already provides some of these answers: the toolbar is not to be used for the type of things that would be problematic if we did use in these scenarios. so using the Mac toolbar to do it all would be as wrong as not using it at all... I don't have a strong opinion about what it should be... so like I said: think it, I will code it..
I'm no Mac expert I'm afraid and don't have strong opinions on this other that wanting to be able to create an app that looks as native as is possible and not like a fish out of water. So I guess whatever the style guidelines say should be thing to follow as far as behaviour is concerned. I'm sure I've never yet seen a dynamic Mac toolbar although the iWork apps have a sub-toolbar I don't think buttons come and go as they please. I think it should be 'caveat emptor' for anyone using tightly platform bound APIs really, no? Also very interested in the LaF. Keep it up! Have you maybe thought about bottom bars too?
Created attachment 99000 [details] Moved the perspective changer to the native mac toolbar I changed the workbench code and was able to create a custom presentation that moves the switcher in the native toolbar. the interesting part is that this code is entirely compatible with the previous version: if I use the normal presentation, the usual perspective switcher shows where you'd expect it.
Created attachment 99485 [details] Patch to org.eclipse.swt.internal.carbon.OS.properties This patch contains the native declarations for my additions to OS.class required to support the native Mac OS toolbar (it is against 129 - the latest Ixxx build at the moment)
Created attachment 99492 [details] matching patch to OS.java
Created attachment 99494 [details] New carbon classes Adds the missing classes required by my changes to OS.java FINAL NOTE: - the changes are only additions to OS.class - the changes include basic support for segmented views in the toolbar (complete support will require a few more APIs to be added) - the patches are against the latest 3.4.44 () - when some constants where part of a series (semantically related) the new declarations in OS.java are also grouped together. when some individual definitions already existed, the original one is just commented out to show that 1) it was replaced 2) it is part of a series (the point is to simplify the job of someone reviewing this). I hope these would be able to go in considering they have zero side effects on the rest of eclipse. I will be sharing the rest of the code here soon.
+1 for this as a separate presentation, default on Mac. What you could do with the Shell#setToolBar(ToolBar) thingy is use the unified toolbar on Mac, and on all other platforms override the shell layout manager and force the toolbar to be at the top. Conceivably, developers could use setToolBar and then have a layout manager which moves the toolbar to some arbitrary location in the shell. On Mac, it would be on top, but on all other platforms it would be somewhere else. This sort of inconsistency would be rather confusing. Since presumably the developer is aware of the distinct behavior of setToolBar, this would be more sane. There are other questions though related to this: what about Composite#getChildren()? Will a "Shell ToolBar" show up in that list? If so, then how will layout managers deal with a control which absolutely refuses to be moved on a given platform? Perhaps this should be something closer to the way that Tray works, functioning as an alternative way to construct a ToolBar that isn't parented by any Composite. This sort of API would naturally require a fallback behavior like the one illustrated above.
Created attachment 100753 [details] updated working custom eclipse Presentation This presentation is Mac OS specific, but the same eclipse instance looks normal when the presentation is switched back to 'default'
-1 What you show in your images robs me of valuable vertical screen space. The entire left-hand side of the upper grey part is empty -- wasted. It adds NOTHING to the usability of the software. Please don't make this the default, regardless of what the Apple guidelines say for Leopard. If you do make it an option, don't tie to other "default" look and feel aspects whatever they may be. The option should control just this toolbar behavior. I really don't like the looks of this. I don't want to give up all that space.
Paul, 1) like you I hate not to have the choice... this is not a default even within the installable Presentation I use it in: I never showed it, but I added an option to the normal "General > Appearance > Perspective Switcher positions" preference named "Title Bar". When this is selected (only available on Macos), then the switcher is moved to the native toolbar, otherwise it remains in its normal current position. 2) considering the amount of space reclaimed by the rest of the Presentation (gone is the hard-coded 2 inside TrimArea - see a bug I created for the workbench to add support for variable trim spacing), the addition of the toolbar is not as bad as it would otherwise be. 3) the left side of the integrated toolbar is not completely wasted, as it can also contain additional icons (remember... this is the real Mac toolbar, config screen and all). Contributions could be flagged as 'stable' and only these would be candidates for inclusion in the top bar, the rest would remain as candidates for the current Coolbar. 4) my main idea in creating this (aside from preparing a quick thing for a job interview) was to create the enabling technology in RCP/SWT for custom apps to look like real Mac Apps WHEN DEVELOPERS WANT IT. I found it entertaining to see if I could make Eclipse itself use it, just to see if in a couple days I would get enough understanding of the Workbench source code to do it. at the moment, I am satisfied that the SWT low level code finally supports segmented views (like the back/forward or multiple views choices in Finder), and that Ganymede looks better on my mac (granted this is a purely personal opinion). Unless the SWT team decides to integrate my (or their own version of the same) additions to OS.class (pretty free of side effects), none of this is going to go anywhere, so no space will be vanishing unexpectedly :) In the meantime, people who do want more Mac-like Java applications can always use good'ol trusted Swing: http://explodingpixels.wordpress.com/2008/05/02/sexy-swing-app-the-unified-toolbar/ cheers
another enhancement request for some related work (better support for Mac OS idiosyncrasies) https://bugs.eclipse.org/bugs/show_bug.cgi?id=233608
A minor code change to make the current presentation more in control of the workbench layout (the 2 pixels gap between stacks is actually a hard coded final static constant). https://bugs.eclipse.org/bugs/show_bug.cgi?id=229840
+1.
(In reply to comment #14) > -1 > > What you show in your images robs me of valuable vertical screen space. The > entire left-hand side of the upper grey part is empty -- wasted. It adds > NOTHING to the usability of the software. Please don't make this the default, > regardless of what the Apple guidelines say for Leopard. If you do make it an > option, don't tie to other "default" look and feel aspects whatever they may > be. The option should control just this toolbar behavior. I really don't like > the looks of this. I don't want to give up all that space. > I find astounding that you do not seem to be making a difference between the availability of a functionality in a low level library (in this case the fact that SWT would support the Mac OS unified toolbar) and what people do with it (for example the eclipse prototype I built for my own benefit only where I used the unified toolbar as a task switcher as an ILLUSTRATION). where has 'use your imagination to see what else someone else could do in their own applications with this low level capability' gone ? in case it was not clear, this bug entry IS NOT about modifying eclipse itself, but about building an enabler...... but at the moment we are all safe and nobody can do anything at all (well except me and the handful of other people who might have done the same before me) because so far the SWT team has not judged that the even the enabler is worth having at all.
per Steve's suggestion: "ping" ..
I don't have a problem with adding the low level support for you to call.
does that mean pushing the attached patch in 3.5 some time soon?
I don't own this bug report.
LOL... I have to say... this one got me... I am still laughing... LOL :)
it was actually easier to implement alpha composition in SWT which does not support per pixel transparency in pictures and build a new GC than to get any form of commitment from you guys (not talking about doing things, but just about informing people)... which is what i was referring to in past posts when I was suggesting that anyone wondering about SWT should spend the time to read hundreds of past posts to get the true feel (as opposed to what is being advertised) for how the group operates: namely that you guys operate in your ivory tower with little or no concerns for what happens outside of it (I am not referring to this post in particular, but to a large number of similar situations).
altogether I am not attached to having the official SWT distribution support native mac toolbars, and I understand that you have a lot of things on your hands. I won't tease you anymore. cheers.
Laurent, I think you were also going to add your patch to Mike Schrag's Maclipse rollup, right? Will that be happening at some point? (or has it already?!)
I thought I had removed myself from the CC on this bug... does not seem to be working either .. :)... I did not plan on doing that. I was thinking of making another fork of SWT or simply forget about the whole thing.. after all, they are working on Cocoa, right?!... it will be interesting to see which version of Cocoa versus Dojo comes first.. care to bet on the final outcome... I think they said it all here: --------------------------- Hi Laurent, Firstly, thanks for your efforts! I would suggest concentrating on making them work in swt's in-progress Cocoa port (see http://www.eclipse.org/swt/cocoaport.php ). It's too late for changes like this to go in for 3.4, and the hope is that by 3.5 the Cocoa port will become the real one. The best way to submit changes is with patches attached to bug reports. It's difficult to prescribe an exact shape for the changes to take because any change that has the potential to affect api (eg.- do all tool items automatically go up there or only client-specified ones?) is not taken lightly. It's not likely that a change of this size would be merged as-is anyways, but if 90% of it is then a huge effort has been saved on this end. The biggest contribution is seeing the new OS calls working; massaging the code shape afterwards is straightforward. Regarding future changes like this, I would suggest first logging bug reports with SWT, setting the OS to "Mac OSX - Cocoa", and putting some words like "I can investigate this, would this feature be desirable?". I suggest this just because I would not want work to be done that never had a chance of going in. Decisions regarding enhancements like this are often made by multiple people, so I don't want to unilaterally state here what would or wouldn't be taken. Grant --------------------------- I think I just have a better appreciation for why SWT is so behind Swing in capabilities. it is really quite fortunate for the SWT team that Sun was also acting so dogmatically about the whole l&f of Java apps... I guess it is going to be time to migrate to mono.
L, If you don't plan on doing anything here, other that crap on us, why on earth did you ping the bug report? I'm closing this as WONTFIX because you indicated that you don't care.
Aww crap. Can I offer a Star Wars quote? "I care..."
LOL... this would be cure if we were in 10th grade, but considering were we are, I find the whole situation quite sad... like any body's thoughts, except yours, have ever made any difference in what happens with SWT... Isn't it after all "Steve's Widget Toolkit".. considering the vast sums of money invested in eclipse technology by many companies worldwide, my hope is that someone at IBM is carefully reviewing wether you are still an asset to move the technology forward or have the wrong personality for the responsibilities now resting on your shoulders. Reflecting back on the hundreds of past posts I read, I cannot imagine that I am the only one finding it incredibly immature for someone with your responsibilities to decide on the fate of some technical choices in this manner. there was an excellent article in the Harvard Business Review a few years ago about super stars and teams...
LOL ... sorry Justin!!! looks like Steve did not pay attention to the fact that you opened the bug and not me. I built my own solution because I thought it would be interesting to try, and shared it because of steve's own mantra that 'this is a community effort'. at this point he may actually do something out of bruised ego... we'll see
I think this is a pretty good example of how rhetoric and continuous taunting can cloud judgment on a technical issue. I saw the ping, asked whether we should release the patch, was taunted and came to the conclusion that releasing the patch wouldn't help and closed the bug, then was taunted some more. I have retitled the bug to reflect the actual problem and reopened it. Supporting a native Mac toolbar requires API for the Mac and on the other platforms (as described by comment #1) or a special Mac specific packaged (like the OLE support). We could also release the natives, but this would not be API. Given that we are moving to cocoa, releasing the natives for carbon doesn't help anyone (even L. Mihalkovic). L. Mihalkovic, the abuse that you dish out is phenominal and very personal, to the point of a personal attack. To say that it is unhelpful is an understatement. I will ask you once again to stick to technical issues in this and other bug reports.
I do understand where you come from, and even probably why you see things the way you do. however whether or not you and I as individuals do see eye to eye, or even simply have a compatible work ethics, does not change a certain number of facts that I have openly talked about. chief among my complaints was the lack of communication from the SWT team for what, when or even simply if something will or will not show up. which btw you did again in this post where you talk about the cocoa port to be the answer everyone has to look for, without giving us a sense of when this might happen - to you it is nothing, but to companies who write commercial software, with the constraints that go with scheduling a launch or advising clients when the functionalities they would like might be available, this is a whole different story. I have to say, I sincerely hope that this is just an artifact of the public side of the project and that the rest of IBM, or the more important business members of the Eclipse consortium are being treated differently than people like me (I fully expect that as an individual - notwithstanding the fact that my employer is a 100,000+ $30B company - I absolutely should be treated with the least amount of priority). because if they don't, then I think you are missing something as a project leader, and as undeniable as your technical skills might be, I am doubtful that these are the most important aspect of the position of lead of the SWT or Platform project. even though you most certainly think differently, reading back my posts there is nothing in there that I would qualify as a personal attack, and therefore would have regrets about. however, I can also appreciate that being on top of a hill like you are and for as long as you have been, it might feel like an attack to have your behavior described back at you. as for the status of this request, it is "open, but will not resolve". Cocoa will (or not - it is not totally clear to me) address the issue whenever it comes. correct? the summary is that it took 4 MONTHS to finally get a clear no. and that is more than many enhancement requests I have seen in bugzilla...
(In reply to comment #34) > ... > > I have to say, I sincerely hope that this is just an artifact of the public > side of the project and that the rest of IBM, or the more important business > members of the Eclipse consortium are being treated differently ... > > even though you most certainly think differently, reading back my posts there > is nothing in there that I would qualify as a personal attack,... > But herein lies the problem, L., you *are* making personal attacks. Clearly, in the lines above you are saying "Steve is not acting professionally", and he has every right to feel insulted by that; Steve Northover is the single most dedicated and professional person that *you* have ever met. Here is the situation as I see it: You have been given an unprecedented level of access to the development team for a piece of software that you care about. They take regular time out from their actual development work to help you personally, both in your immediate concerns and in educating you on how to best interact with them. And your response has been to waste everyone's time using your finely honed oration skills to attempt to attempt to skew their process in ways that appeal to you personally. You need to understand: THIS IS NEVER GOING TO BE A SUCCESSFUL STRATEGY. Your role, if you choose to have one, is to work *with* the SWT team, learning *their* ways, and *CONTRIBUTING* within that framework. As a result of that, when you have earned your commit rights, are a functioning member of the team, and actually understand the constraints that they work under, you will be in a position to have the conversations that you seem to love so much with them. Until then, I'm sorry, but you sound like a not-yet-had-their-first-child couple, explaining what parenting will be like -- you just don't get it. Steve: Please give L. another chance. I do believe he is trying to contribute.
(In reply to comment #35) > (In reply to comment #34) > > ... > > > > I have to say, I sincerely hope that this is just an artifact of the public > > side of the project and that the rest of IBM, or the more important business > > members of the Eclipse consortium are being treated differently ... > > > > even though you most certainly think differently, reading back my posts there > > is nothing in there that I would qualify as a personal attack,... > > > But herein lies the problem, L., you *are* making personal attacks. Clearly, in > the lines above you are saying "Steve is not acting professionally", and he has > every right to feel insulted by that; So let me see if I follow you: it is acceptable for a member of the team to act unprofessionally, but it is unacceptable for anyone to point out that this is happening. > Steve Northover is the single most > dedicated and professional person that *you* have ever met. no-one is disputing that, which has nothing to do with the previous statement. I hope for your own sake that, even if you'd probably die before you'd admit it in public, you can actually see how the two are not incompatible. > Here is the situation as I see it: You have been given an unprecedented level > of access to the development team for a piece of software that you care about. > They take regular time out from their actual development work to help you > personally, both in your immediate concerns and in educating you on how to best > interact with them. And your response has been to waste everyone's time using > your finely honed oration skills to attempt to attempt to skew their process in > ways that appeal to you personally. You need to understand: THIS IS NEVER GOING > TO BE A SUCCESSFUL STRATEGY. > > Your role, if you choose to have one, is to work *with* the SWT team, learning > *their* ways, and *CONTRIBUTING* within that framework. As a result of that, > when you have earned your commit rights, are a functioning member of the team, > and actually understand the constraints that they work under, you will be in a > position to have the conversations that you seem to love so much with them. > Until then, I'm sorry, but you sound like a not-yet-had-their-first-child > couple, explaining what parenting will be like -- you just don't get it. > > Steve: Please give L. another chance. I do believe he is trying to contribute. > mike, I cannot help but notice that you are just focussing all your attention on how I have been saying things, rather than on what I was saying. which reminds me of a recent situation where I was trying to attract your attention to the impression someone would get by reading quickly a large number of past postings for the purpose of understanding the dynamic of the team, how it interacts with the general public, and how it makes technical choices so that it became possible to get a sense of what has a chance or not to make it into SWT as a future feature. instead of responding about any of the latter, your answer at the time was about how comical in a sense (not your exact word, but a depiction of their content) it was to ask you if you had read older posting considering how you had been in charge of triage... my point was that when it comes to where you are taking all of us with this technology that you are building, you guys function in an ivory tower (as demonstrated by several years of past posts) which I hope is not the way the more important part of the eclipse ecosystem (the multi-$B dollar businesses that are committed to the it) get treated. I am not the first one to make that statement, I might be one of the least flowery about it.
> > Please go to the bug reports you entered and add a comment that asks why the patch has > not been applied. Thanks! > this is what steve wrote about this bug in the dev mailing list... you may have the time to run around between the various lists and newsgroups and whatnots, but no kidding, I don't...
(In reply to comment #36) > (In reply to comment #35) > > (In reply to comment #34) > > > ... > > > > ... > I hope for your own sake that, even if you'd probably die before you'd admit it > in public, you can actually see how the two are not incompatible... > My god, you're *still* doing it! Are you actually claiming that you believe my previous comment was knowingly deceitful? Bah, maybe I am wasting my time. > mike, I cannot help but notice that you are just focussing all your attention > on how I have been saying things, rather than on what I was saying. > Exactly. I'm hugely glad that you are starting to understand. The fact is, you have been making comments in the wrong places, using denigrating language, and generally been unnecessarily argumentative. As a result, you've raised the ire of every person on the SWT team, many of the other Platform developers, and me personally. I really do hope that you are trying to achieve something useful here, but you've literally poisoned your ability to do so. Your only chance at this point is to prove you are actually making a sufficiently valuable contribution that you are worth talking to again. > my point was that when it comes to where you are taking all of us with this > technology that you are building, you guys function in an ivory tower (as > demonstrated by several years of past posts) which I hope is not the way the > more important part of the eclipse ecosystem (the multi-$B dollar businesses > that are committed to the it) get treated. I am not the first one to make that > statement, I might be one of the least flowery about it. > So, is this really the crux of the argument? If so, then the answer is simple: There's no ivory tower here. What you are seeing is a just team of developers, implementing features and fixing bugs that they have been asked to fix by the people who pay their salaries[*]. Now, out of their fundamental respect for the Eclipse community, they are doing their work in a way that takes the widest possible view of how it will be consumed, but they are NOT working for that community. Honestly, I can't imagine where you got the idea that we were somehow supporting the "multi-$B dollar businesses" -- we aren't. We are simply working in a way that those businesses (and anyone else who wants to) can, because of enlightened self-interest, support *us* by contributing to the effort, and as a result ensure that the features/bug fixes/direction is useful to them. [* to be clear: This is *not* just IBM. Adobe, for example, has a committer on the SWT team who is working on the Cocoa port, since that has business value for Adobe.] So, I'm not sure about you, L., but I really am not having fun by prolonging this conversation. I've tried to be civil. I've done what I can to explain the situation. The rest is up to you. If you can figure out how to contribute in a positive way, we'd love to have your help. Otherwise, we simply can't afford the drain on our energy that your comments are costing us.
lol... you really are a work of art. draping yourself in some offended dignity stance does not change anything to how things have been and, judging from this, will probably keep going on. >Exactly. I'm hugely glad that you are starting to understand. The fact is, you >have been making comments in the wrong places, using denigrating language, and >generally been unnecessarily argumentative. As a result, you've raised the ire >of every person on the SWT team, many of the other Platform developers, and me >personally. I really do hope that you are trying to achieve something useful >here, but you've literally poisoned your ability to do so. Your only chance at >this point is to prove you are actually making a sufficiently valuable >contribution that you are worth talking to again. I said it somewhere else very clearly to steve. I don't care what you do with the things I point out. by the time I raise them, I usually have a fix, workaround, or more generally an implementation. like the latest thing I found in the Image.java implementation which does duplicate memory allocation on at least platforms when you call getImageData(). you fix it, good. you don't fix it, equally good. the software I am paid to build will work the same. I needed a custom perspective switcher for an RCP app, I fixed up the internals of the workbench and built what I needed. you care good, you don't.. all the same to me. you are interested in listening good, lets talk. but in order to make things better, the first thing is to be able to recognize when there is a problem without blushing and loosing one's composure. we are professionals who do what we have to do, not kids with bleeding hearts arguing endlessly about who's lunch box has the prettier color.
This is crazy. I want the unified toolbar as much as the next guy, but these personal slights against the SWT team aren't helping anyone. I've been following SWT for a long time, and in all that time I've only known the members of the SWT team (both in and out of IBM) as consummate professionals and brilliant developers. As a fellow outsider, I can sometimes understand your frustration with the review process which is necessarily associated with a large scale OSS project like SWT, but that doesn't mean I lash out at those responsible for carrying out those processes. We all appreciate the work you've done in trying to get this bug successfully resolved, but have a little respect for those who have been working on this project for *years* longer than either of us.
everyone I met who had direct contacts with some of the prominent members of the SWT team have shared some comments, sometimes harsh in my mind, about how the SWT/Platform team operates in comparison to some of the other groups. I guess I am guilty of bringing the topic in the open rather than keep it between the closed doors where it has been so far. but the bright side is that, as in dysfunctional families, anytime a stranger comes and voices criticism, it has the effect of rallying the troops together. Daniel, smell it like it is.. there is no chance that this will show up anywhere in SWT. it does not matter if you write the code yourself. it does not matter if you get someone else to write it. it does not matter how the code is written. there are dozens more issues like this one that are dormant in bugzilla, some of them for years. wether or not you believe that Comment #29 has something to do with it is a matter of personal opinion. some of these entries do not have code attached to them so it is easier, then to reply something along the lines of "step up, come help, this is your project too". if stating WHAT IS is now "insulting", then I am again guilty as charged.
Would anyone know what is the status or at least decision of including a native toolbar class in the upcoming Cocoa build of SWT? Having a native toolbar in eclipse proper would obviously be very nice, but I am more concerned about the application (just SWT, no RCP) we are developing looking native on OSX. If the answer is no (there will be no native toolbar capability in SWT Cocoa), then would it be better to dig into SWT itself and build a custom version of the SWT jar/jnilib or build a new separate jar/jnilib?
+1 for native toolbar support in SWT Carbon and/or Cocoa
Any news on this now that Galileo is motoring along?? I would really love this one to be available in 3.5... 8)
The Mac toolbar was scheduled for 3.5 M5. What's the current projected availability date for it?
Comment 45 is incorrect. This was not scheduled for 3.5 M5. We're busy implementing the existing feature set on Cocoa and not had time to enhancements.
I think this was on the swt plan for 3.5M5, but is deferred because completing the port's implementation to match other platforms is higher priority. It's possible that this won't be done for 3.5, depending on how the other cocoa work goes.
So it is. I expected this item to be one of the "Mac cocoa..." items. Sorry.
Anything the community/we can help? No promises as our schedule is as packed as anyone else's, but if we can, we'll try. I know that making this functionality available might seem as an item or personal or cosmetic-value, but it's actually very important to projects like ours. We've received countless feedback from users saying that our UI (it's and RCP app) doesn't look native, citing the Mac-unusual toolbar as the main reason. Many thanks in advance.
I imagine everyone's consumed with this week's M6 milestone, yet I wanted to check if there's any reason for optimism that there'll be support for Mac OS X native toolbar in the final 3.5?
*** Bug 251495 has been marked as a duplicate of this bug. ***
I am working on a Cocoa version of the code I wrote a year ago for the Carbon version of SWT. Support for the Sheets is working the toolbar is more code to write.
Good news, thank you L. I, for one, am looking forward to your new code. Steve, earlier you wrote you wouldn't have a problem "adding the low level support" for this; is that still the case? Will this happen for 3.5? I posted several comments/questions here, some going back a month and a half ago...no answer yet, not even an acknowledgment. The bug is open, has an owner and going by the cc: list more than one person has interest in its resolution. Has it become acceptable for questions go unanswered/unacknowledged for months?
No, it is not acceptable and I appologize. We will add the low level support right away.
Thanks, Steve!
Aren't we in feature-freeze for 3.5? I thought that started as of M6.
> Aren't we in feature-freeze for 3.5? The low level support is not API so it is not subject to the freeze.
> Thanks, Steve! I feel really terrible about this. Kevin is looking into this now.
Is the source for MToolbar and MToolbarItem available anywhere? I'm reviewing the patches on this bug report. There are a lot of functions and constants added to OS.java and I want to be sure that we're only adding the necessary functionality and that we are not missing anything that is necessary.
Laurent, could you provide the source for MToolbar and MToolbarItem? I also assumed that it's part of one the attachments, but that's not the case. Thanks!
the code attached was for the Carbon-SWT. If I recall, I had centralized here all the low level additions I needed, which also covered supporting sheets and split views (or whatever the name apple gives to the capsule shaped buttons). I had also made another patch somewhere else to be able to customize the gap between views in a perspective (there was a screen-shot of my eclipse with 0 gaps, like typical Mac apps). As for feature freezes, I believe I heard those words last year (too bad considering how straight forward extending OS.java is). I am making a Cocoa version because (no offense) I still find eclipse to be an eye sore on Mac OS. I'm not trying to get any of it in this version, as I imagine you are plenty busy without having to deal with additional external code. note: once you wrap your head around it, the object-java/cocoa contraption you came up with is actually fun to write
That's all good, thanks. Note however that the opportunity at the moment is to get the low-level support for the Mac toolbar be a part of the 3.5 release. This may be less than what you and I would've liked, but it's a considerable help especially if one hasn't invested the time to wrap his head around these issues like you have. Therefore knowing the exact changes required for the Mac toolbar support, as opposed to all changes incl. those for sheets and split views, can only be of help. > I am making a Cocoa version... Were you considering to share your code with anyone who might be interested? Btw, Steve, I assumed that all along the discussion was about adding this support to Cocoa, not Carbon SWT. Did you also have Cocoa in mind, or both?
Kevin, Steve: at the absence of MToolbar and MToobarItem what is the information specifically needed in order to provide the low-level support for them? Is it knowing exactly which functions and constants present in OS.java patch are required for creating Mac OS X native toolbars? Please let me know - I expect to be able to spend some time towards the end of this week to help, should help be needed. Wrt introducing this support to both the Carbon and the Cocoa SWT distros - is that a possibility or is the additional effort considerable?
Created attachment 129651 [details] toolbar & sheets based on the latest swt build. haven't tested the code in 64bits yet. in the absence of written doc, the harder it to try to guess where you would place the code, rather than write it (still puzzled by the SWTxxx vs the NSxxx and the rule for when to implement the delegate where... accessibility seems to be the only place where the delegate is inlined in the SWTxxx class, rather built via the display callbacks). anyhow.
Picture looks good, Laurent. Where's the code that goes with it? :)
private void toolbar() { MToolBar bar = new MToolBar(shell, SWT.NONE); MToolItem item = new MToolItem(bar, MToolItem.PRINT); item = new MToolItem(bar, MToolItem.COLORS); item = new MToolItem(bar, MToolItem.FLEXIBLE_SPACE); item = new MToolItem(bar, MToolItem.FONTS); item = new MToolItem(bar, MToolItem.SPACE); item = new MToolItem(bar, MToolItem.CUSTOMIZE); } :)
Laurent, Does this means that you are not willing to contribute the code to MToolBar and MToolBarItem? Your screen shot is very nice, but what exactly are you asking us to review here?
kevin, last night I started fresh with the knowledge from the prototype. it work fine so far as the picture shows, but is very incomplete. I wouldn't mind some indications about what the role of SWTxxx is in your design. at the moment I have a SWTToolBar, SWTToolItem, and SWTToolBarDelegate (not made a SWTToolItemDelegate yet, which should be enough for you to infer without seeing it what my code can and cannot support). at the moment, I am not using SWTToolbar as I am not sure what role it should play. a few weeks ago I spent several hours reading the cocoa/swt source and there was pretty much an example of every possible combination (I am referring to how UIEnhancer vs Display vs Safari vs Accessibility vs most widgets work). so my main issue is not to get things to work, but to follow the right pattern. for example * should the toolbar be registered with Display or is it acceptable to deal locally with JNIref) * another un-answered question in my mind is wether or not I have to do a xxx_addProtocol(NSToolbarDelegate) (yes, I know this is not the exact syntax) on the delegate. it seems to work without, but I have seen some around in display * also, I haven't decided if I want to follow the apple 'Toolbar' or the SWT 'ToolBar' naming convention * should I put the class-pair declaration code in MToolBar (where it is now, to follow the safari pattern) or add it to display, which leads to where should I write the pair declaration code for the toolitem (mtoolbar or mtoolbaritem). like i said, none of that is really technical, but these are my challenges: how to make it fit (not knowing cocoa or objective-c does not seem to be a pb at the moment as your code is pretty straightforward to learn from). as for the Carbon version, I ditched it when I saw how much of a pain it was to simply get the low level included in swt.
Laurent, I also have been playing around with NSToolbar and NSToolbarItem. I implemented it the following way: - I registered both SWTToolbar and SWTToolbarItem in Display, because all common widgets (NSOutlineView, NSTableView, NSButton, ...) seem to be registered in that class. - I haven't implemented SWTToolbarDelegate (nor xxx_addProtocol) because the events get fired without this protocol. I did add "toolbarDidRemoveItem, toolbarWillAddItem and toolbar_itemForIdentifier_willBeInsertedIntoToolbar) to Widget (to which I referred in Display), so it would become possible to implement custom behavior in the native toolbar. I also have no clear idea if this is the right approach, but so far it does the trick. I'll share my patch once my code is more or less maintainable.
yep, none of it is difficult, it's more about finding out where to put the code. I kept the SWTxxxx pair code in MToolBar the same way they did for safari because I saw this as a one off (unlike all the mainstream widgets). I made a separate delegate because it seems to be cleaner than to do it all in one place (like the do for most case). I didn't want to touch Display because I wanted to avoid a debate on what, how, why, indentations, font color, ... I don't like the chicken and egg situation with defaultItemIdentifiers. I guess conceptually it works better if you have a nib.
Created attachment 129697 [details] Screenshot of improved SWT Cocoa widgets I attached a screenshot of my work so far. I'll share a patch soon, once I have the code centralized so it won't touch too many SWT classes.
Laurent, We use SWTxxx classes whenever we need to subclass an NSxxx class. Subclasses of Control generally use register and deregister to manage their JNI reference. This is mainly for code consistency. All platforms use some form of register/deregister. Where you declare your class pair for MToolbar is up to you. In the future, if we introduce a new class to SWT, we'd use Display.initClasses to register the class pair.
Created attachment 129893 [details] Custom button and configuration sheet aside from the standard OSX items, you can create your own.
Created attachment 129894 [details] handling selection via SelectionListener the Mxxxx.yyy constants are mapped to existing ones when possible and the others are defined locally. DEFAULT means that it is in the 'default toolbar' at the bottom of the sheet. HIDDEN means that it is showing up on the customization sheet as being available, but not selected on the current toolbar (this is because I don't want the print/fonts/... standard icons to show up at all when I update my plugin to replace the perspective switcher with MToolbar like I did with carbon) ----------- MToolBar bar = new MToolBar(shell, SWT.NONE); MToolItem item; item = new MToolItem(bar, MToolItem.PUSH); item.setText("Save"); item.setImage(Display.getCurrent().getSystemImage(SWT.ICON_INFORMATION)); item.setToolTipText("Save the world!!!"); item.setEnabled(true); item.addSelectionListener(new SelectionAdapter(){ public void widgetSelected(SelectionEvent e) { MessageBox mb = new MessageBox(shell, SWT.OK | SWT.CANCEL | SWT.ICON_INFORMATION | SWT.PRIMARY_MODAL); mb.setMessage("'Save' toolbar button clicked!!"); mb.setText("Blah blah blah"); int res = mb.open(); System.out.println("res:" + (res == SWT.OK ? "OK" : res == SWT.CANCEL ? "CANCEL" : Integer.toString(res))); } }); item = new MToolItem(bar, MToolItem.COLORS | MToolItem.DEFAULT); item = new MToolItem(bar, MToolItem.PRINT | MToolItem.DEFAULT); item = new MToolItem(bar, MToolItem.FLEXIBLE_SPACE | MToolItem.DEFAULT); item = new MToolItem(bar, MToolItem.FONTS | MToolItem.DEFAULT); item = new MToolItem(bar, MToolItem.SPACE | MToolItem.HIDDEN); item = new MToolItem(bar, MToolItem.CUSTOMIZE | MToolItem.HIDDEN); item = new MToolItem(bar, MToolItem.SEPARATOR | MToolItem.HIDDEN); --------- so... the million dollar question is: will you consider including the necessary mappings in the JNI layer? (I can make a patch now, but I am still playing with the segmented buttons)
Laurent, we'll look any patch you submit.
Created attachment 129909 [details] my generator config (merged from 3538 a few minutes ago) kevin, I just merged with 3538, based on the latest generator config, it looks like I am supporting more toolbar features than you are planning for. I put my version in a tarball as the diff view is useless (shows that it is all new - do you use some specific settings to make the diff view more useful?). would you consider adding the reminder? (for eg, I use the config sheet, and am working on testing my code for preference pages - all selectable, only one at a time, remains selected until another one is selected) cheers
MessageBox line 187: title = NSString.stringWith(this.title != null ? this.title : ""); new NSWindow(alert.window().id).setTitle(title); NSString message = NSString.stringWith(this.message != null ? this.message : ""); + alert.setMessageText(message); + NSString info = NSString.stringWith(this.getText() != null ? this.getText() : ""); alert.setInformativeText(info); int response = (int)/*64*/alert.runModal(); alert.release(); ------------- is it possible to add the second line of text?
Created attachment 129973 [details] patch I created a patch from LM's attached files. Haven't had a chance to review it yet.
Created attachment 130031 [details] segmented controls this afternoon I added support for segmented controls which means adding NSSegmentedControl class + NSSegmentedStyleXXX and NSSegmentedSwitchXXX enums.
Created attachment 130057 [details] search field in toolbar while adding support for search buttons to MToolbar, I found out that some of the subclassing done for SWTSearchField is incompatible with displaying one in the toolbar. it works when I directly create an instance of NSSearchField though. I still have to figure some of the details for connecting the various cells to external event listeners.
released patch to HEAD.
Created attachment 147838 [details] Toolbar patch This patch should be considered a proof of concept (it's really just hacked together). This will not be the API that we choose to go with, but you can use the native toolbar by creating an SWT ToolBar with the SWT.SMOOTH style bit. Not all type of SWT tool bar items are supported by the native tool bar, and the tool bar offers additional functionality (ie customize) that SWT tool bars don't typically give you. This patch offers minimal functionality.
Is there any chance at all this will progress & make it into 3.6 Helios?
I have, what I believe is, a fairly complete, functionality-wise implementation based on a version of the patch from Kevin that Scott shared with me awhile back. It has support for dropdown menu button, search box, flex spacers, etc. and addresses a leak/crash in the original patch. Obviously it'll need to be reviewed and ensured that it fits well with the rest; if there's interest and a chance that this will make it in 3.6 I can submit a patch with my changes.
(In reply to comment #84) > [I[f there's interest and a > chance that this will make it in 3.6 I can submit a patch with my changes. I think there's still interest, but from where I sit I'm not in a position to promise it would make it into 3.6, as it would introduce new API. In a previous life, I used to say "the answer to 'should I file a bug' is always 'yes'". I think the equivalent Eclipse mantra is "the answer to 'should I submit a patch' is always 'yes'".
OK, will do, gladly. If this is not time sensitive, allow me ~couple weeks as I'm wrapping up a release.
Any news on this Yolian?! Helios RC1 is due very shortly so presumably too late to squeeze this into 3.6? Does that mean we'll have to wait another year for this, in 3.7? :( Short of creating a 3.6 patched "fork" in our own repositories!
It's not lack of desire, Justin... I'll try to submit a patch by the end of the week. I looked into it ~a month ago - it turned out to be more than just creating a patch as we have other modifications to those files that need to be taken out first. My understanding is that this change wouldn't have made it in 3.6 even if I had submitted it back in February.
Created attachment 170610 [details] OSX Unified Toolbar
At last - a patch that I hope captures all toolbar-related modifications, and only them, together with a screenshot to illustrate the way it's currently used in DeltaWalker - the product we make. If you want to see it in action you can always grab a download (http://www.deltopia.com). Note that in addition to the changes found in the patch, we had to make other changes to Workbench code so that the regular Eclipse toolbar could coexist with the unified one. If you are writing a strictly SWT application you the attached patch should be sufficient. We've been shipping with this code for several months so no known issues... but does one really ever know. Once again, thanks to Scott for giving me a good place to start from!
Created attachment 170611 [details] OSX Unified Toolbar screenshot
The screen shot looks good! I'll have a longer look at the patch in the next few weeks, but a quick glance indicates this will have to wait for 3.7. No new API introduced but new SWT constants were added. For 3.7 we'll have to take a hard look at the toolbar API in general so we can try to determine if we can make API or patterns that will work on all platforms. As an implementation it looks very promising, though. Thanks for submitting it!
> I'll have a longer look at the patch in the next few weeks, but a quick glance indicates this will have to wait for 3.7. No new API introduced but new SWT constants were added. Oh, don't say there was ever a chance for this to make it in 3.6 :-) I would've tried harder, sooner... it's no fun to reapply these changes to new SWT releases. The new SWT constants were added, if memory serves me well, only for the sake of transparent programming against both the current SWT toolbar and the new, unified one when working at a higher level in eclipse (ToolBarManager etc.). I don't think they were a must if one were to use this toolbar directly from SWT. In any case, glad to be of help. Don't hesitate if I can further clarify things...
(In reply to comment #92) > The screen shot looks good! I'll have a longer look at the patch in the next > few weeks, but a quick glance indicates this will have to wait for 3.7. No new > API introduced but new SWT constants were added. > > For 3.7 we'll have to take a hard look at the toolbar API in general so we can > try to determine if we can make API or patterns that will work on all > platforms. As an implementation it looks very promising, though. > > Thanks for submitting it! Any updates on this for 3.7? Thanks!
(In reply to comment #94) > Any updates on this for 3.7? > > Thanks! The Mac toolbar is on the plan as 'time permitting'. See <http://www.eclipse.org/swt/R3_7/plan.html>. I don't have anything more specific as to when we will be able to discuss the compatibility with non-Cocoa platforms.
It's been 5 years since Tiger showed up with the unified toolbar, and year after year passes by without SWT supporting it. At what point should we give up the pretense that SWT is supposed to "look native"?
What's wrong with implementing the patch that is attached? If the user wants a uniform look and feel for the toolbar then the user can use the CoolBar.
(In reply to comment #97) > What's wrong with implementing the patch that is attached? If the user wants a > uniform look and feel for the toolbar then the user can use the CoolBar. So far, nothing. It still looks good, and I'm reviewing it today and bringing it up to date with the 3.7 codebase. Because it's introducing new API (in the form of new flags in SWT.java) it needs to be reviewed before I can check it in. We will need to get an IP review done as well, as it's an outside contribution, but that won't block the technical work. Folks, I'm a Mac guy too, so I'd like to see this done as much as anyone else. Please believe me when I say it's not for lack of interest or the fact that this came from a third party that kept this from getting done sooner.
(In reply to comment #98) > We will need to get an IP review done as well, as it's an outside contribution, > but that won't block the technical work. Scott, as far as I'm concerned you have all the rights necessary to make my contribution a part of the SWT codebase. One thing that was not addressed then and is not addressed now is handling the case when the toolbar is too narrow to fit all of its buttons... hopefully it's something you can look into.
(In reply to comment #99) > Scott, as far as I'm concerned you have all the rights necessary to make my > contribution a part of the SWT codebase. That's good, since you added the patches to the bug already. :-) There is a bit of bureaucracy that has to happen before we ship, and I'll let you know when that happens. > One thing that was not addressed then and is not addressed now is handling the > case when the toolbar is too narrow to fit all of its buttons... hopefully it's > something you can look into. There are a couple of things I've noticed so far. The basics of your changes are working correctly, but there are some things I want to add to make it more of an SWT class. Namely, no mouse events are generated when you mouse over or click on a ToolItem or a Toolbar, and hot images don't work. I'm making a lot of progress and will attach an updated patch later today.
Created attachment 180221 [details] Updated patch -- 10/4/10 This patch is the latest revision based on top-of-tree as of 10/3/10. Some notable changes since the last time this was updated: -- hot images will work in unified toolbar ToolItems -- all mouse and paint events delivered to ToolBar and ToolItems -- no need to override Combo for DROP_DOWN buttons. -- feedback is correct when clicking on the icon portion of a DROP_DOWN button -- one native toolbar per window is enforced with style bits. If the Shell already has a SMOOTH toolbar and dev tries to add another one, the SMOOTH bit is cleared and it behaves like a plain SWT toolbar. -- Controls can be parented to the ToolBar and appear in the right place. Parent/child relationships are maintained. -- Toolbar is configured for text-only or icon-only, depending on the state of the items in the toolbar. If there is an item with text and another with an icon, or one with both, the toolbar is set to icon + text mode. -- If the window is too narrow to display all of the items, the spillover items appear in a popup menu at the right end of the toolbar. Remaining issues, which may or may not be fixed, time and review permitting: -- The native toolbar is a fixed width, so calling pack() on the Shell won't change the width of the window. -- SWT.CHECK ToolItems should appear highlighted, like toggle buttons, but for now they draw with the old-style gray background. This patch is missing SWTToolbar.java due to what looks like a bug in the patch generator, but here it is: =============== package org.eclipse.swt.internal.cocoa; public class SWTToolbar extends NSToolbar { } =============== If you are so inclined, please give it a shot.
Scott, will try it at first opportunity, but the list of improvements is impressive! Thanks!!!
After talking to Silenio this morning we're thinking about modifying the API into this so we can potentially add this into Windows 7 as well. Basically, we would add a new method on Shell that looks like this: ToolBar getShellToolbar(); that will return an NSToolbar-based ToolBar on Cocoa or a Windows 7-style ToolBar on Windows. This is because the current ToolBar API assumes that you can make multiple ToolBars in a Shell, and the current implementation simply falls back to the in-content ToolBar if a native toolbar has been created. A new API makes it more explicit, and also lets you know if it's supported on the current platform. In other words, it would return null on GTK, Carbon, etc. because there's no implementation there. If your application has a single toolbar in a Shell the code would look like this: =========== Shell s; ToolBar tb = s.getShellToolbar(); if (tb == null) tb = new ToolBar(s, SWT.NONE); ToolItem tbItem = new ToolItem(tb, SWT.PUSH); ..... =========== Let me know what you think in the comments. Once we get the API settled I can check this in.
(In reply to comment #103) > After talking to Silenio this morning we're thinking about modifying the API > into this so we can potentially add this into Windows 7 as well. Basically, we > would add a new method on Shell that looks like this: > > ToolBar getShellToolbar(); Hmm.. I see now this is what Steve N. proposed way back at comment #2, but I'm adding the additional semantics of returning null when the platform doesn't support it. In any event, I think this is the way to go. I would still like to add the SPACER and FLEX_SPACER, though I don't know if that's available on Windows.
It's nice to see that this gets attention, I've been waiting for this a long time. I've looked briefly at the API and it looks good but why is the method called "getShellToolbar" and not "getToolbar"?
(In reply to comment #105) > why is the method > called "getShellToolbar" and not "getToolbar"? Good point. It's already in Shell, so getShellToolbar is redundant. I guess I was thinking that since you can put any number of toolbars in a shell (or any other Composite) this made it clear you were getting the toolbar that's part of the window trim and not any of the ones that may have been added to the content area.
(In reply to comment #103) > that will return an NSToolbar-based ToolBar on Cocoa or a Windows 7-style > ToolBar on Windows. To be clear, we are not going to be making a ribbon-based toolbar due to bug 293637. I'm not sure what we would do in its place, however.
(In reply to comment #107) > (In reply to comment #103) > > that will return an NSToolbar-based ToolBar on Cocoa or a Windows 7-style > > ToolBar on Windows. > > To be clear, we are not going to be making a ribbon-based toolbar due to bug > 293637. I'm not sure what we would do in its place, however. First, I don't see how bug 293637 could be a problem if you implement your own version. Just look at wine, they're basically reimplementing the whole win32 API. Second, about what to do in its place. I'm not entirely sure what counts as a ribbon-based toolbar but how about implementing something that looks like the toolbar in Explorer, the file manager (does it have a name)?
Thanks for addressing this bug - I really am looking forward to getting this functionality. I really like the getToolbar() API that is being talked about but I hope the Mac native toolbar does not get put on a shelf until a Windows implementation for the new API is created. I would really like to see the new API with a Mac implementation in an upcoming M build and if the Windows users really want something then address that as a separate issue.
(In reply to comment #106) > Good point. It's already in Shell, so getShellToolbar is redundant. I guess I > was thinking that since you can put any number of toolbars in a shell (or any > other Composite) this made it clear you were getting the toolbar that's part of > the window trim and not any of the ones that may have been added to the content > area. Interestingly that was my first association/thought as well when I saw the name getShellToolbar(). The case about getToolbar() is also valid, so it's a close call. My preference would still be getShellToolbar() for the above reasons and because it's likely that existing code/clients might already have getToolbar() in which case getShellToolbar() has smaller chance of breaking things/forcing changes in them.
(In reply to comment #109) > I really like the getToolbar() API that is being talked about but I hope the > Mac native toolbar does not get put on a shelf until a Windows implementation > for the new API is created. I would really like to see the new API with a Mac > implementation in an upcoming M build and if the Windows users really want > something then address that as a separate issue. If we nail down the API and can commit to something that will work on Windows I think this can be checked in without a Win32 implementation in place. Bug 325795 is the way I think we will go for Windows, even though it will only be on Vista and higher. It does look like I can implement that with the same API.
Created attachment 180379 [details] Newer patch Unfortunately I can't use label-only mode when there's no icon. If there's a separator item with a control set you can't set aside space for the control. Also fixed some layout issues with separator items.
(In reply to comment #110) > Interestingly that was my first association/thought as well when I saw the name > getShellToolbar(). The case about getToolbar() is also valid, so it's a close > call. > My preference would still be getShellToolbar() for the above reasons and > because it's likely that existing code/clients might already have getToolbar() > in which case getShellToolbar() has smaller chance of breaking things/forcing > changes in them. How will adding a getToolbar method to the Shell class break existing code? As far as I can see there are no existing methods in the Shell class that have anything to do with toolbars.
How about getPrimaryToolbar()? This does indicates that that there could be many other toolbars, but the returned one is the main one on the Shell.
(In reply to comment #113) > (In reply to comment #110) > > Interestingly that was my first association/thought as well when I saw the name > > getShellToolbar(). The case about getToolbar() is also valid, so it's a close > > call. > > My preference would still be getShellToolbar() for the above reasons and > > because it's likely that existing code/clients might already have getToolbar() > > in which case getShellToolbar() has smaller chance of breaking things/forcing > > changes in them. > > How will adding a getToolbar method to the Shell class break existing code? As > far as I can see there are no existing methods in the Shell class that have > anything to do with toolbars. Well it would if people would have been allowed to subclass it but because the JavaDoc clearly states: -----------8<----------- IMPORTANT: This class is not intended to be subclassed. -----------8<----------- We should be free to name it like it want to.
(In reply to comment #115) > Well it would if people would have been allowed to subclass it but because the > JavaDoc clearly states: That's what I had in mind. If I had a toolbar in a window that I wanted to make accessible, I'd most likely would've called the accessor getToolbar(). > -----------8<----------- > IMPORTANT: This class is not intended to be subclassed. > -----------8<----------- > > We should be free to name it like it want to. True. I'll throw in yet another possible name: getMainToolbar(), much in the way of getPrimaryToolbar() just a little shorter and perhaps more common. As I said it's very much a tossup so whichever name we choose we can't be too wrong. The wrong thing would be to get too hung up on the name. A minor point - the SWT toolbar class is actually ToolBar (capital B) and that name is maintained elsewhere in eclipse e.g. ApplicationWindow#getToolBarManager(). With that in mind and in the name of consistency, whatever name we choose it should have ToolBar spelled with capital B.
(In reply to comment #116) > (In reply to comment #115) > > > Well it would if people would have been allowed to subclass it but because the > > JavaDoc clearly states: > > > That's what I had in mind. If I had a toolbar in a window that I wanted to make > accessible, I'd most likely would've called the accessor getToolbar(). > > > -----------8<----------- > > IMPORTANT: This class is not intended to be subclassed. > > -----------8<----------- > > > > We should be free to name it like it want to. > > True. > > I'll throw in yet another possible name: getMainToolbar(), much in the way of > getPrimaryToolbar() just a little shorter and perhaps more common. > > As I said it's very much a tossup so whichever name we choose we can't be too > wrong. The wrong thing would be to get too hung up on the name. Looking at most of the applications, they seem to only have one toolbar and it's also what I would expect in most of the cases. Though I can't be sure if some of the more complex toolbars are implemented with multiple toolbars under the hood. > A minor point - the SWT toolbar class is actually ToolBar (capital B) and that > name is maintained elsewhere in eclipse e.g. > ApplicationWindow#getToolBarManager(). With that in mind and in the name of > consistency, whatever name we choose it should have ToolBar spelled with > capital B. That's a little strange, isn't "toolbar" a correct word (without a space)? All the spellcheckers I tried approves it.
Created attachment 180532 [details] Latest update Latest rev. Silenio will review early next week and I hope to check it in Tuesday or Wednesday. -- Better drawing of text-only labels -- SWT.CHECK ToolItem images now draw darkened when selected -- cleanup of generated code. -- Fixed disabled tool item drawing. -- Shell.getToolbar() is the final name. Shell is not subclass-able, so there shouldn't be any conflicts. -- Constant name/behavior changes: Removed style bits for separator types and instead, setWidth(SWT.DEFAULT) sets a fixed-size spacer, setWidth(SWT.SEPARATOR_FILL) uses a flexible-width spacer, and setWidth(0) sets the standard vertical line spacer. Shell.getToolbar() should be considered experimental and potentially subject to change. Silenio and Bogdan have been working on something similar for Windows Vista & later; Silenio will add some comments about this soon. We're considering adding a 'getTrimComposite()' or some similarly-named thing that gives you a Composite that will appear in the window trim for Aero-style windows. getToolbar() doesn't make sense on Windows because you can put any Composite in the shell trim area, not just a ToolBar. In theory you could do that on the Mac as well, but this would not be a replacement for a standard NSToolbar-based ToolBar implementation; an NSToolbar was meant to hold NSToolbarItems, and is expected to look a certain way. Keep watching this bug for future developments.
Some comments: 1) The comment in ToolItem.setWidth() will be lost when we do the javadoc bash (just before the release), since the bashing tool uses windows as the most complete javadoc. We need to move the comment to windows and determine if we are going to support SWT.SEPARATOR_FILL on the other platforms. 2) The const SEPARATOR_FILL in SWT needs to mention it is used in ToolItem.setWidth() (instead of TooItem). 3) ToolBar.getStyle() and ToolItem.getStyle() will include SWT.SMOOTH which is not API. We should consider changing all the places we check for: (style & SWT.SMOOTH) != 0 with nsToolbar != null (or parent.nsToolbar != 0) And clear the bit in Toolbar.createHandle() after the nsToolbar is created. Or at least reimplement getStyle() and clear the bit. 4) I noticed that when the chevron (overflow arrow) is shown, the menu items are aways disabled. 5) Add this warning to the top of the java doc of Shell.getToolbar() and add the same method to the other platforms (return null). We will investigate further what it means to support the Aero Glass on Windows 7 and if it makes sense to tie these two features together. The current idea is to provide "Composite getTitleBar()" (or getTrimBar()) which returns a ToolBar on mac and a Composite on Windows (Vista and 7). On Mac, app code would have to down cast the return value to ToolBar. /** * WARNING: API UNDER COSTRUCTION 6) Need to change the "width < 0" check in ToolItem.setWidth() 7) Change getToolbar() to getToolBar() to be consistent with getMenuBar() and the name of the class (ToolBar).
(In reply to comment #119) > 1) > 2) Done. > 3) ToolBar.getStyle() and ToolItem.getStyle() will include SWT.SMOOTH which is > not API. We should consider changing all the places we check for: > > (style & SWT.SMOOTH) != 0 > > with > > nsToolbar != null (or parent.nsToolbar != 0) I went with the comparison against nsToolbar and cleared the bit. I agree, we don't need to expose that the bar is NSToolbar-based. > 4) I noticed that when the chevron (overflow arrow) is shown, the menu items > are aways disabled. I forgot to set a target for the menu representation. I also noticed disabled items were still selectable from the clipped indicator, so I added a validateMenuItem: override. > 5) > 6) > 7) All done. Thanks for the review -- I'll check it in shortly.
Fixed > 20101013, but let's all remember that the API might change. Please try it out and let us know what you think.
(In reply to comment #119) > 5) We will investigate > further what it means to support the Aero Glass on Windows 7 and if it makes > sense to tie these two features together. The current idea is to provide > "Composite getTitleBar()" (or getTrimBar()) which returns a ToolBar on mac and > a Composite on Windows (Vista and 7). On Mac, app code would have to down cast > the return value to ToolBar. If we look at Chrome (the web browser) they seem to have components in the "unified area" also. Chrome pulls this off in linux, windows, and Mac. I am not a Cocoa programmer so I am not sure what is going on under the covers but I would hate if Mac had trouble getting this functionality in the future because of an overloaded method that meant different things on different platforms. Also, since we are talking about platform specific API I don't see the difference in: if (Platform.getOS() == Platform.OS_WIN32) { Composite composite = getShell().getComposite(); } else if (Platform.getOS() == Platform.OS_MACOSX) { ToolBar toolbar = getShell().getToolBar(); } and: Composite composite = getShell().getComposite(); if (Platform.getOS() == Platform.OS_WIN32) { } else if (Platform.getOS() == Platform.OS_MACOSX) { ToolBar toolbar = (ToolBar) composite; } Both take five lines of code, but the first example shows an example of not overloading getToolBar(). This allows SWT to provide a getComposite() implementation on the Mac in the future if needs be. I think having two methods would make the API much clearer also.
Yes, I agree with you. If SWT cannot provide more common behavior between mac and windows (and other platforms). It does not make sense to overload the getToolBar() method. One way of adding more common behavior is by making getTrimBar() on Mac return a Composite as well. This would give the ability to create multiple toolbars on the Mac, but only one of them would be visible at a given time. I am not sure this extra functionality is worth it.
(In reply to comment #123) > One way of adding more common behavior is by making getTrimBar() on Mac return > a Composite as well. This would give the ability to create multiple toolbars on > the Mac, but only one of them would be visible at a given time. I am not sure > this extra functionality is worth it. NSToolbars have a very specific set of functionality that maps well to ToolBar and ToolItem, so I think it makes sense to have a specialized call to support that. That said, I think it would also be useful to have a general-purpose area where you could throw arbitrary components to make a more customized toolbar area. This can be done with a single custom-view item in an NSToolbar that reacts to the size of the window as Controls are added to the Composite. Here's a very fast implementation that looks like it's working well for me. It works with plain ToolBars; I want to keep testing with other controls before I do anything with it. ========================= public Composite getTrimBar() { checkWidget(); if (toolBar == null) toolBar = new ToolBar(this, SWT.HORIZONTAL | SWT.SMOOTH, true); final ToolItem tbItem = new ToolItem(toolBar, SWT.SEPARATOR); final Composite trimArea = new Composite(toolBar, SWT.NO_BACKGROUND); tbItem.setControl(trimArea); tbItem.setWidth(1); // So we don't get a plain separator item. this.addControlListener(new ControlAdapter() { public void controlResized(ControlEvent e) { tbItem.setWidth(Shell.this.getSize().x); } }); trimArea.addControlListener(new ControlAdapter() { public void controlResized(ControlEvent e) { NSSize newSize = new NSSize(); newSize.height = trimArea.view.frame().height; newSize.width = trimArea.view.frame().width; tbItem.nsItem.setMaxSize(newSize); tbItem.nsItem.setMinSize(newSize); } }); return trimArea; } ===============================
Created attachment 180977 [details] getTrimBar patch This diff returns a general purpose Composite that is in the toolbar area. As the size of the Composite changes, the toolbar area will resize to match. I'm able to attach a classic-style ToolBar and other controls to it. It works fine, but there are issues to work out so it can co-exist with getToolBar().
(In reply to comment #125) > Created an attachment (id=180977) [details] > getTrimBar patch > > This diff returns a general purpose Composite that is in the toolbar area. As > the size of the Composite changes, the toolbar area will resize to match. I'm > able to attach a classic-style ToolBar and other controls to it. It works fine, > but there are issues to work out so it can co-exist with getToolBar(). Two issues with this patch. One is that the toolbar looks different, based on whether getToolBar() has been called earlier or not before calling getTrimBar(). The second is that I occasionally get an NPE (trace is below). Also I would like to know how a CoolBars are integrated with this native toolbar, as the dragging and repositioning is not allowed on native toolbar (unless you do a Cmd+Click). The L&F of cool bars on the native toolbar is also odd. java.lang.NullPointerException at org.eclipse.swt.widgets.Shell.mouseDownCanMoveWindow(Shell.java:1300) at org.eclipse.swt.widgets.Display.windowProc(Display.java:5152) at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method) at org.eclipse.swt.widgets.Widget.callSuper(Widget.java:220) at org.eclipse.swt.widgets.Widget.windowSendEvent(Widget.java:2023) at org.eclipse.swt.widgets.Shell.windowSendEvent(Shell.java:2285) at org.eclipse.swt.widgets.Display.windowProc(Display.java:5308) at org.eclipse.swt.internal.cocoa.OS.objc_msgSendSuper(Native Method) at org.eclipse.swt.widgets.Display.applicationSendEvent(Display.java:4804) at org.eclipse.swt.widgets.Display.applicationProc(Display.java:4911) at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method) at org.eclipse.swt.internal.cocoa.NSApplication.sendEvent(NSApplication.java:123) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3450) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2629) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2593) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2427) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:670) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:663) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:621) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:576) at org.eclipse.equinox.launcher.Main.run(Main.java:1409) at org.eclipse.equinox.launcher.Main.main(Main.java:1385)
(In reply to comment #126) > Two issues with this patch. One is that the toolbar looks different, based > on whether getToolBar() has been called earlier or not before calling > getTrimBar(). The second is that I occasionally get an NPE (trace is below). If getToolBar has been called first I return the shell ToolBar when you call getTrimBar(). I don't like that, but you can't have more than one NSToolbar in a window -- they have to be mutually exclusive. The ToolBar returned by Shell.getToolBar() isn't as versatile as a standard ToolBar because we don't have a lot of control over the contents of that view. > Also I would like to know how a CoolBars are integrated with this native > toolbar, as the dragging and repositioning is not allowed on native toolbar > (unless you do a Cmd+Click). The L&F of cool bars on the native toolbar is also > odd. Typically a click anywhere in the trim area starts a window drag, so that's probably what you are seeing. That's why I have an override of mouseDownCanMoveWindow. You're hitting the little details that are going to make this a difficult API to provide. But, we'll see what we can do. > java.lang.NullPointerException > at org.eclipse.swt.widgets.Shell.mouseDownCanMoveWindow(Shell.java:1300) > at org.eclipse.swt.widgets.Display.windowProc(Display.java:5152) I'll look at this. I think I see how it can happen.
(In reply to comment #127) > You're hitting the little details that are going to make this a difficult API > to provide. But, we'll see what we can do. I'm just trying to use the native toolbar for the IDE and hitting the wall :-)
I think Windows Vista and 7 support this features as well, right ? so, will this applied to Windows as well ?
(In reply to comment #129) > I think Windows Vista and 7 support this features as well, right ? Yes and no. Vista and 7 allow you to put any control in the trim area, which is more general than what can be done on the Mac. Silenio and Bogdan were working on a Windows version, but last I heard they were running into a lot of issues with it. > so, will this applied to Windows as well ? I won't make any promises about Windows right now -- they are both busy with other work and I'm not a Windows or GTK dev. I can try to pester one of them to attach a patch and a motivated individual can keep going on it.
Just ignore this. duplicated (In reply to comment #131) > I think Windows Vista and 7 support this features as well, right ? so, will > this applied to Windows as well ?
Mac status bars show similar gradients. Are they supported as well with 3.7?
Nice!!
We are playing with different ideas around this area. Basically we want to be able to place controls on the window trim. This style of UI can be seen on cocoa and windows seven applications. Please see bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=325795 It is possible that we will remove this Shell#getToolbar() in favor of the API described in bug above ( comment 30)
Created attachment 189297 [details] Testcase comparing getToolbar() vs TRIM_FILL
Created attachment 189299 [details] Screenshot comparing getToolbar() vs TRIM_FILL
(In reply to comment #137) > Created attachment 189299 [details] > Screenshot comparing getToolbar() vs TRIM_FILL Notes: getToolbar() pros - uses the native control - has the blue bottom [top right] - has the nice animation to hide/show the toolbar (when the blue button is clicked) cons - only supports controls on top of the window - not ideal for placing other controls on it (it can be done using item#setControl() but it hard to control the position, spacing, alignment, etc - cocoa centric, very hard to implement on other platforms - The toolbar is not part of the SWT traverse group (maybe can be fixed) - The client area seems off (note how the button is a few pixels down, maybe can be fixed) TRIM_FILL pros - user can place controls anywhere in the trim: top, left, right, bottom, anywhere - can be implemented on other platforms (windows 7) - does not have problem with traverse order and client area - the code is simple - if the support is not available on a platform, and the application does not do anything special to handle this case, the user stills gets a fully functional UI. cons: - no blue button to animate the hide and show for the toolbar (if this is really a problem, we can force the button to show, and add a new event to represent action of the button - but the app would have to provide the animation).
Just to be clear, the reason we are even considering revisiting this bug is to come up with a common, multi-platform API that will allow users to place controls in the trim areas.
(In reply to comment #138) On Mac OS X using the non-native implementation, what's the behavior of the toolbar? Can I drag the window only on the title bar or anywhere on the toolbar like on native applications?
(In reply to comment #140) > (In reply to comment #138) > On Mac OS X using the non-native implementation, what's the behavior of the > toolbar? Can I drag the window only on the title bar or anywhere on the toolbar > like on native applications? anywhere on the toolbar like a native apps. or more precisely, anywhere that is dark gray you can click and drag the window. We get this from using this bit: NSTexturedBackgroundWindowMask The window displays with a metal-textured background. Additionally, the window may be moved by clicking and dragging anywhere in the window background. A bordered window with this mask gets rounded bottom corners. http://developer.apple.com/library/mac/documentation/cocoa/reference/ApplicationKit/Classes/NSWindow_Class/Reference/Reference.html#//apple_ref/doc/c_ref/NSTexturedBackgroundWindowMask
(In reply to comment #138) > cons: > - no blue button to animate the hide and show for the toolbar > > (if this is really a problem, we can force the button to show, and add a new > event to represent action of the button - but the app would have to provide the > animation). Apple removed the blue button for Mac OS Lion - I am sure that you have noticed if you are running Lion - and so it is maybe not a big problem if it is not visible on Mac OS Snow Leopard.
