Community
Participate
Working Groups
Created attachment 205627 [details] Shot of menu missing border If you have a folder and press the "more..." to pop up the menu on that folder the Safari rendering of that menu is missing the right and bottom borders for the menu. Also, if you choose the "Import from Zip..." menu item, and choose the "Browse..." button in the resulting dialog the rightmost border is not present. I confirmed the same behaviour is in Chrome (wrong borders) but seems fine in FireFox 7.0
On IE9 only the right border shows on menus. Whereas on Chrome and Safari, only the left/top border show. I didn't see the missing dialog border problem, though.
http://bugs.dojotoolkit.org/ticket/11749 Can reproduce easily in http://download.dojotoolkit.org/release-1.5.0/dojo-release-1.5.0/dijit/themes/themeTester.html?theme=nihilo
Created attachment 205847 [details] screenshot showing how to reproduce in theme tester need to update dojo bug with additional browser/theme info, investigating...
better link for theme tester (from nightly builds, to get latest) http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/themes/themeTester.html?theme=nihilo
anton expressed an interest in looking at the css. Anton, you can decide if it fits into an RCx milestone or should be deferred. It's also possible that dojo 1.7 fixes this?
Interesting news from the dojo bug. ---------------------- Changed 4 days ago by neonstalwart Status changed from new to open fyi - this is not a problem with the claro theme Changed 43 hours ago by bill Status changed from open to closed Resolution set to wontfix OK, then I'll close. It will be fixed eventually in the sense that for 2.0 the other themes will either be dropped or recreated as variations on claro. ---------------------- When I was looking at this problem on the latest theme tester, I was thinking "should we switch to claro to fix this bug?" and then i thought that was too drastic. But if claro represents the future of theming, maybe it is worth switching early in 0.5 and seeing how that theme plays in light of our dojo styling overrides.
we should revisit this when we are safely on dojo 1.7
I started playing with this a bit yesterday out of curiosity, so I went ahead and fixed it. Given that claro is the future for dijit themes (at least for now), I changed from nihilo to claro. The interesting changes are here: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=5f3eac4b9656e03afe001af2f86417e792f27837 (there is another commit with the global replace from "nihilo" to "claro") I removed all of our nihilo overrides and started from scratch. There are two ways to go about overriding a dojo theme. One way is to use the LESS files and change some of the default variables, and build a complete new theme. If we were honestly basing a new theme on claro, this would have been a good way to get global changes. However, our overrides are pretty isolated to menus, buttons, margins, and it didn't seem of great benefit to muddy the waters about what the differences are by rebuilding the entire theme and then maintaining it as claro evolves. So...I stayed with the strategy of including theme overrides in ide.css and commands.css. The ide.css overrides are to remove padding in content panes, override the blue splitter hover, override the blue dialog title bar. The commands.css overrides involve changing buttons, dropdowns, menu items, hovers, tooltips from light blue and gradients to white/transparent/gray per Linda's mockups. I made a few "free" changes while here: - removed the outline from the navigator pane so that we don't have that honking focus rectangle when you cursor into the navigator (just the light blue row shows) - skinnied up the splitter and changed to default thumb visuals. Linda's mockups have prescribed a very thin line that hovers to a thicker representation. This is pretty close to what claro was doing for free. It makes the splitter transparent until you pull on it. But having no left hand "border" for the editor made the annotations and ruler look odd/floaty. So a compromise for now was to skinny up the splitter and simplify/skinny up the thumb representation. I think we'll want to refine this as part of the normal process of having Linda polish details.
