For OSX (and Windows, and maybe Linux down the road), the Australis project moves the tabs into the titlebar, and brings the window buttons / fullscreen button down a few pixels. smichaud and JosiahOne tell me that a tree-side build variable would make things easier for them to get this going, since drawing in the titlebar in Firefox is not a thing that will be user-toggleable. It makes sense then to make this decision at build-time with a define, since non-Firefox XUL apps may or may not want to take advantage of tabs in the titlebar. I think I've more or less summed that up correctly. Are there any restrictions to getting a build var put into core? Is this a thing that should be batted about in a mailing-list somewhere? 1: http://people.mozilla.com/~shorlander/files/australis-designSpecs/australis-designSpecs-osx-mainWindow.html
The main thing from my perspective is that, without a tree-wide Australis define, all patches containing any Australis-specific code would have to be landed on trunk at once. Cocoa widget code will need a number of changes to support Australis, and it would be terribly inconvenient if they all had to be landed at once. Having a tree-wide Australis define allows us to land patches on trunk whenever we choose, with the Australis-specific stuff deffed off.
> with the Australis-specific stuff deffed off Deffed off until Australis lands, that is.
Steven - I think we're fine to do this. It's easier to ask forgiveness than permission. Let's just dive in and add the define.
Thanks! Which (of those you mentioned) do you suggest using? I personally favor AUSTRALIS. Whichever you choose, I'll start adding it to my patches. I'll limit its use to situations where the code would break non-Australis builds in some way unless it was ifdefed off. I won't use it with code that stands on its own (that works whether or not we're building with Australis support). > It's easier to ask forgiveness than permission. :-)
(In reply to Steven Michaud from comment #4) > Thanks! > > Which (of those you mentioned) do you suggest using? I personally favor > AUSTRALIS. AUSTRALIS is fine by me. It's not a long-term define, so I guess so long as its clear on its purpose, it's OK. :) > > Whichever you choose, I'll start adding it to my patches. I'll limit its > use to situations where the code would break non-Australis builds in some > way unless it was ifdefed off. I won't use it with code that stands on its > own (that works whether or not we're building with Australis support). > Sounds good to me!
This is mostly an implementation detail so marking as M- as we won't block Australis on this.
Whiteboard: [Australis:M-] → [Australis:M-][Australis:P?]
Whiteboard: [Australis:M-][Australis:P?] → [Australis:M-]
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.