[bbxstudio]

Just curious as to any of you experienced and wisened theme designers can help me out with a quick question...

--- the hack ---

I've designed this theme that looks absolutely gorgeous in the finder and all carbon applications - the document titlebar is 2-pixels taller than the standard Aqua height of 22-pixels... carbon applications and the finder seem to take this in stride and accomodate the hack very nicely (offsetting the widgets up by 2-pixels within their masks plunks them dead centre and all is well).

--- the problem ---

However, cocoa applications (themepark, demetalfized iCal and iChat, etc.) simply ignore the very top and very bottom row of pixels in the extended pixm (which looks okay, but not as good as the carbon interpretation) and the offset widgets of course draw 2-pixels up in cocoa... Grrrrrrrrrr...

--- the question ---

I suppose this is to be expected with the 2-pixel extension, but is there any way to get the system to recognize those extra 2-pixels when drawing cocoa windows - a layo hack or resource I can tweak to make the system think that standard window titelbar height is 24- instead of 22-pixels? (apologies - the theme spec is new to me, I'm an old-skool Kaleidoscope guy trying to make the move, dig?)...

--- the alternatives ---

My only alternative seems to be designing the widgets so they sing with the Apple brushed-metal thing and recommend users install Unsanity Metalfizer (which is supposed to make all cocoa windows draw in the QuickTime brushed metal appearance - problem solved unless like me you dislike the brushed thing), or trim down the hacked pixm and destroy the delicate proportional balance the hack was designed to produce in the first place.

Any insight | suggestions | info | revelations | wisdom | helpfulness would be greatly appreciated

BillyB

[swiz]

Originally posted by bbxstudio:
Just curious as to any of you experienced and wisened theme designers can help me out with a quick question...

--- the hack ---

I've designed this theme that looks absolutely gorgeous in the finder and all carbon applications - the document titlebar is 2-pixels taller than the standard Aqua height of 22-pixels... carbon applications and the finder seem to take this in stride and accomodate the hack very nicely (offsetting the widgets up by 2-pixels within their masks plunks them dead centre and all is well).

--- the problem ---

However, cocoa applications (themepark, demetalfized iCal and iChat, etc.) simply ignore the very top and very bottom row of pixels in the extended pixm (which looks okay, but not as good as the carbon interpretation) and the offset widgets of course draw 2-pixels up in cocoa... Grrrrrrrrrr...

--- the question ---

I suppose this is to be expected with the 2-pixel extension, but is there any way to get the system to recognize those extra 2-pixels when drawing cocoa windows - a layo hack or resource I can tweak to make the system think that standard window titelbar height is 24- instead of 22-pixels? (apologies - the theme spec is new to me, I'm an old-skool Kaleidoscope guy trying to make the move, dig?)...

--- the alternatives ---

My only alternative seems to be designing the widgets so they sing with the Apple brushed-metal thing and recommend users install Unsanity Metalfizer (which is supposed to make all cocoa windows draw in the QuickTime brushed metal appearance - problem solved unless like me you dislike the brushed thing), or trim down the hacked pixm and destroy the delicate proportional balance the hack was designed to produce in the first place.

Any insight | suggestions | info | revelations | wisdom | helpfulness would be greatly appreciated

BillyB

You are correct that tit could be rectified with a layo hack, unfortunately no one has figured out how to do this yet. You may just be forced to run your hack-fix until this is figured out. Yes, this is a bummer in the realm of true theme uniquity.

[kupan787]

Originally posted by swiz:


You are correct that tit could be rectified with a layo hack, unfortunately no one has figured out how to do this yet. You may just be forced to run your hack-fix until this is figured out. Yes, this is a bummer in the realm of true theme uniquity.

Actually no. I had a llittle talk with someone from Apple who let me know that all the cocoa values are hardcoded in. We can't change them. The layo (which was mostly hacked out for 10.1), only effects carbon apps.

I can pass along the email to anyone that wants to see it, kust email me at [email protected]

This seems like bad news for themers that wanted to find out how to change the cocoa gui dimensions. Looks like it wont be possible until Apple allows themes.

Ben

[bbxstudio]

D'oh! I was afraid of that... Aqua's dimensions are fine for Aqua, but seem forced for just about anything else.

Oh well, these are the pioneering days I guess - I'm sure that given time, somebody will figure out a Kaleidoscope-style approach to patching the system with or without Apple's help eventually. I expect to be much happier in a couple of years

There must be a way to do it - even if it means having an overlying app that does a real-time scan-and-replace with an overlay composite scenario a la Kineticon in OS9 (use a generic theme with visual triggers that activate the compositor app or intercept window-refresh signals/instructions or something)...

C'mon Apple, give us the tools here - tap that bottomless invaluable resource of eager (and free) talent and let third-party exciting interface designs work for you in driving enthusiasm and visibility for the platform... even Microsoft understands this with regards to XP and WMP (they're even hiring up the top Mac guys - who'd much rather be designing for their own platform for FREE - to do it). Aqua's an amazing default sure, but it's hardly the be-all and end-all. Just think of the possibilities... sure, there will always be hideous themes floating around - but also some real gems that will only make OSX seem that much cooler! Customization should be a key selling feature, not a dirty word. People crave novelty and variety, by gum. Who uses themes, anyways? It's the young and enthusiastic pro-users, the one in the family/kid down the street everybody turns to for purchasing advice... so give them some ammo and ispiration... it's all about infectious platform enthusiasm and that undeniable 'cool' factor. Yo' Steve, wake the hell up and smell the coffee!

Arrrrggghhh... it's all so infuriating.

[Millennium]

According to some rumors, Carbon and Cocoa are moving towards the point where they will merge in some future release. That is, Cocoa will be built completely on top of Carbon. In that system, Cocoa becomes a high-level API for building apps, where Carbon becomes more low-level, for when you need to really get down into the system.

This would be good for both API's, I think. Apple would be forced to extend to Carbon the current system-integration advantages Cocoa has, while Cocoa would have to be given access to the richer varieties of controls and such that Carbon currently has. In the context of themeing, it also means that the two API's will finally draw from the same set of resources, probably the Carbon ones.

The thing is, this rumor actually makes a lot of sense. If you look at the developer release notes for Jaguar, you'll find that certain aspects of Carbon are moving to a new -and distinctly more Cocoa-like- set of underpinnings. In fact, it's now possible to use "Cocoa windows" from Carbon, though to be honest I'm not entirely sure I understand the difference between a Carbon window and a Cocoa window yet.

These are things which don't affect the user at all, but they have important ramifications for the programmer. And for the themer, because it means far less duplication of effort, eventually. And, as I said before, although it's just a rumor there's real evidence to support it, and it makes a great deal of sense for Apple to do this because it could help decrease bloat, make bugs easier to fix, and make the UI more consistent.

I doubt we'll see a complete merging of Carbon and Cocoa anytime soon. At the absolute earliest, it would be the release after Panther, and it's more likely to be the release after that one. But once it comes, I think you may find that themeing becomes a lot easier.

[smeger]

Originally posted by Millennium:
According to some rumors, Carbon and Cocoa are moving towards the point where they will merge in some future release. That is, Cocoa will be built completely on top of Carbon. In that system, Cocoa becomes a high-level API for building apps, where Carbon becomes more low-level, for when you need to really get down into the system.

This would be good for both API's, I think. Apple would be forced to extend to Carbon the current system-integration advantages Cocoa has, while Cocoa would have to be given access to the richer varieties of controls and such that Carbon currently has. In the context of themeing, it also means that the two API's will finally draw from the same set of resources, probably the Carbon ones.

The thing is, this rumor actually makes a lot of sense. If you look at the developer release notes for Jaguar, you'll find that certain aspects of Carbon are moving to a new -and distinctly more Cocoa-like- set of underpinnings. In fact, it's now possible to use "Cocoa windows" from Carbon, though to be honest I'm not entirely sure I understand the difference between a Carbon window and a Cocoa window yet.

These are things which don't affect the user at all, but they have important ramifications for the programmer. And for the themer, because it means far less duplication of effort, eventually. And, as I said before, although it's just a rumor there's real evidence to support it, and it makes a great deal of sense for Apple to do this because it could help decrease bloat, make bugs easier to fix, and make the UI more consistent.

I doubt we'll see a complete merging of Carbon and Cocoa anytime soon. At the absolute earliest, it would be the release after Panther, and it's more likely to be the release after that one. But once it comes, I think you may find that themeing becomes a lot easier.

I agree totally. A lot of the underpinnings of Carbon are already procedural versions of Cocoa constructs (basically all of Core Services).

The up'n'coming HIView stuff uses a procedural version of something that looks a lot like an NSView as the basis for all Carbon controls. Information on whether HIViews and NSViews are "toll-free-bridgeable" is totally absent from the docs, though.