Dry Nostrils

The time has come yet again to begin designing new features at work… This is my favorite time, because I get to come up with crazy ideas for new functionality and have people stare at me like I am an alien… I also get to say “The way we do this, it sucks, lets fix it” and get away with it (although I get away with it all the time, but people are a bit more receptive now)…

4 thoughts on “Dry Nostrils

  1. If most of your code is C++ then you should consider reimplementing your Macintosh version with the Carbon API next time around. This would allow native functionality in OSX, not to mention that from my (violently narrow) perception the Carbon API doesn’t suck as much as some others- seeing as it was designed as an interrim option so that companies wouldn’t have to maintain two trees to support both operating systems. It would probably also be a fairly relevant contribution to the XUL using community and anyone producing (future) products using it.

    This would also be a move in the direction of planning for the future- assuming your company isn’t too antsy to consider its life expectancy :)

    1. Sorry to disappoint, but we don’t have a “Macintosh Version” nor do we use any Mac specific APIs, we just compile our application on MacOS. Once Mozilla starts using Carbon, we will too.

      BTW, that focus (needing to click on the titlebar to use the application) bug you mentioned isn’t OSX specific, it exists on OS9 as well.

      This would also be a move in the direction of planning for the future- assuming your company isn’t too antsy to consider its life expectancy :)

      No offense to the mac community, but you aren’t large enough to affect the direction of our company. It is great that our application works under OSX, that is a unexpected side-effect, but we targetted OS9 because that is what people asked for. We have no interest whatsoever in reengineering all of the Mac specific parts of Mozilla just to eek out a bit more performance under OSX, especially considering our Mac development team consists of 1 engineer who doesn’t really like Macs to begin with. :)

      I don’t really see any advantage “Native functionality in OSX” would bring us considering we don’t use any native OS widgets.

      1. I was mostly referencing the fact that OS9 will (probably) cease to be the norm in 3 or four years- at which point (assuming you wanted to continue to support Macintosh computers) you’d need to rework your code. At that point, however, it’s safe to assume that the Mozilla project will have come through in some fashion- if they haven’t already.

        I misunderstood how your code ran on MacOS- i thought you had to write some stuff that acted as an interface between XUL and MacOS’s display- not realizing it already did because of the Mozilla project.

        I’m going to go play with Photoshop now :)

        1. I was mostly referencing the fact that OS9 will (probably) cease to be the norm in 3 or four years- at which point (assuming you wanted to continue to support Macintosh computers) you’d need to rework your code.

          That’s a big assumption to make, based on Apple’s prior track record… They aren’t exactly prone to throwing things away.

          I misunderstood how your code ran on MacOS- i thought you had to write some stuff that acted as an interface between XUL and MacOS’s display- not realizing it already did because of the Mozilla project.

          We create a window and insert the Mozilla embedding engine into it…
          Most of our porting involved our protocols we added to mozilla…

Leave a Reply