Well, blog topics just keep piling up, so I'll knock them all down in one fell swoop with another (probably long) tidbits entry. :)

First off, HTML frames. Arg, they annoy me *SO* much. I have this love/hate relationship with them: they're exceedingly useful since they don't require you to copy and paste code into a number of pages, but they're also horrid in the sense that you can't directly link someone to a framed page and be able to set what pages show in all the frames, unless you create a dedicated frame page for each combination of pages on the screen. There's always been a big debate about whether to use frames on web pages: some people say yes because of their usefulness, and some people stay away from them at all costs because they create so many user problems.

So I'm going to propose an alternative to HTML frames, for the benefit of all my ones of readers. It's basically frames without frames. Here's how it works: on an HTML page, you specify some sort of link to include the content from a totally different page (say, for example, you'd use the syntax <INCLUDE href="navbar.html">). The page that you link to would already be created in HTML format, and basically the INCLUDE tag simply replaces the INCLUDE tag with the content at the specified URL. You could easily customize how the frame appears by using CSS and HTML -- the HTML from the INCLUDE tag would have to obey the surrounding HTML. You can use as many INCLUDE tags as you want, to essentially import the HTML from another page.

This method has all the benefits of frames without the drawbacks:

-- You can't specify a link to go into a specific frame, since there ARE no frames. The page is just compositing itself by replacing the INCLUDE tag with the HTML of the linked page. Even though it seems like a drawback, it's actually a benefit, because whenever you link to a specific page, it'll always have all the elements you want in that page: you don't have to worry about whether you need to display the navbar for the associated page or not, because its simply linking to another page which already has all the stuff it needs. So if a page about Macs requires a computer left navbar and a general Macintosh top navbar, you needn't worry about whether the computer and/or Macintosh navbars need to be created in frames, since the page you link to already has all that information in it.

-- You'd be able to specify a specific URL to a set of "frames", which includes all associated navbars. Since it's simply importing other pages to use in the HTML content, it doesn't have the annoying aspect of frames where there's no URL to a specific frameset: you're simply linking to a page.

-- You have all the benefits of frames: if you include a simple <INCLUDE href="navbar.html"> in all your pages, you simply need to update the page navbar.html, and all your other pages will automatically get the new navbar, since they're all just linking to the navbar.html page!

-- You have no more user confusion, because you can't possibly bring another page into a specific frame, and then somehow come back to your original page, resulting in duplicated navbars for the same page.

Does that make sense? Do you think that would work in successfully providing a great alternative to HTML frames? Has it already been implemented? Let me know in the comments. :)

-----------------

Ugh, the California recall just got uglier. The "Governator" (a.k.a. Arnold Schwarzenegger) is officially running, and the other G.O.P. candidates have dropped out of the race. Bustamante (the current Lt. Governor) is also running, so now Democrats have an incentive to support the recall. And there are all the little people trying to run for governor, too.

You know what's maddening about all this? 10% of the voters in California can successfully manipulate the will of the California constituents through the recall. That's because the recall law requires that the recall petition requires only 10% of the number of people who voted in the last California election to sign it, and it doesn't require that those people actually voted. That means that as long as a governor doesn't have 90% approval rating (which is highly unusual and highly improbable), a recall can be initiated.

Furthermore, once a recall has been initiated, it's exceedingly biased against the current governor. Because there are two questions on the ballot: one for whether the recall should happen and one for the candidate to replace the current governor should the recall happen. But, inexplicably, the current governor is not allowed to be on the replacement candidate list?

Putting the existing governor on the replacement governor list may sound ridiculous at first, but it's actually fair. As it is, the current governor has to get 50% of the vote to keep his job. But the replacement candidates have it considerably easy: they just have to garner more votes than any of the other replacement candidates. That means that while Gray Davis (our current California governor) has to get 50% of the vote, while a replacement candidate could get only 10% of the vote and become governor! This problem is exacerbated because anybody with a 10,000-signature petition or $3,500 and a 65-signature petition can get on the ballot; already 400 people have taken out papers to run for governor (it doesn't necessarily mean they will, but they are considering). In a normal election, there is only one candidate from each party, for a maximum of around 10 or so candidates, depending on how many political parties there are.

Essentially, a minority of California constituents can overthrow an OFFICIALLY ELECTED governor as long as the existing governor doesn't have over a 50% of the vote! Even THAT is highly unusual for a governor -- Gray Davis won with a 47% majority in the official election. Given that there's a democratic alternative to Gray Davis now (Bustamante), Davis has no chance in hell of defeating this recall, except through the California courts!

Since Davis has no chance, this is what I suggest to him: wait out the recall until 11:59 PM on October 6, the day before the election. Then he should resign. Because the recall only applies to the governor that was in office when the recall petition was signed, Bustamante will, by default, take over the governorship, and the recall will be derailed, pissing off all those nitwits who signed the recall petition. Ooh, that would show them. Sweet revenge!

Of course, if Davis doesn't do that and ends up losing the special election, we could always just initiate another recall..... :rolleyes:

-----------------

Ahh, free software. Everywhere you see some sort of mention of Linux, the GPL, and how free software is going to be the greatest alternative to Windows.

See, free software is all about free CODE, not free PRICE. The GPL (GNU Public License) basically means that any software released under this license will also have the source code of that very same software freely available. Anybody can modify it and submit the changes back to the maintainer of the software so that bug fixes and other patches can be applied to the software and created by anyone. Seems like a great idea, right? It basically ensures that you can do whatever you want with the code.

Well, there are alternative free software licenses. One is from Apple. When Apple disclosed its roadmap to Mac OS X back in 1999 when Mac OS X Server was first released, it was a great day. Apple is probably the king of proprietary software, because of the ease of use and the novel ideas that they took in creating their software. But here they were, opening up the source code to their software!

But, of course, Apple's first foray into open sourcing their software was not met with open arms. Many people had reservations (that were not unfounded) about the Apple Public Source License. Apple updated its license to version 1.1, and then to version 1.2, but the Free Software Foundation still wasn't satisfied. Three specific problems were mentioned: 1) you had to notify Apple of changes, 2) you couldn't use the code for your own personal purposes, and 3) Apple could terminate the license at any time.

Well, Apple addressed these three problems with version 2.0 of the APSL on August 6, which was on Wednesday. The Free Software Foundation now certifies the APSL as a true free software license.

But the FSF still has gripes with the APSL! First, they claim that it is not a "true copyleft", because you can link the code released under this license with other code that is completely proprietary. It seems to me that if software is truly "free", then anyone can do whatever they want with that code, which includes augmenting its features with potentially proprietary software. Why is that so bad?

Second, the FSF complains about how Apple "retains all rights, title and interest in and to the Original Code and any Modifications made by or on behalf of Apple". But why the complaints? Apple originally created the code that is being released under the APSL, so it seems to me that its only right that they be able to retain the rights to the original code and/or any modified code made on behalf of the company. From my understanding, if I, personally, were to modify code licensed by Apple under the APSL, this would NOT be "by or on behalf of Apple", and therefore Apple would not be able to retain the rights for the modified code. It's also my understanding that retaining the rights of the original code does not preclude a person's ability to modify or distribute the code, provided that that person adheres to the rest of the license.

But the last gripe takes the cake. The FSF simply says that the APSL "is incompatible with the GPL." Oh, how convenient. So since the GPL is widely used for most free software, the FSF feels that all "free" software should be licensed under the GPL just because its the GPL. That reminds me of a certain company I don't care to name.

It seems to me that the FSF is just bitter that Apple wants to keep some of its code proprietary. Apple's actions seem rational and well-intentioned to me.

-----------------

And lastly we come to a topic that is near and dear to my heart: the battle between Carbon and Cocoa on Mac OS X. John Gruber over at Daring Fireball, a guy who writes exquisitely perfected blog entries about leading-edge Mac issues, has a bone to pick with Andrew Stone of Stone Design. Actually, he has three (one, two, and three). Please note that while they are extremely long blog entries, they are EXTREMELY informative and sometimes entertaining entries. I highly recommend reading all three entries on this topic (and bookmarking the blog for future entries).

Basically, what it comes down to is that John Gruber is completely fed up with Andrew Stone's insistence that only Cocoa apps are "truly" Mac OS X native. Cocoa applications are applications created with Apple's free developer tools, designed specifically for Mac OS X. Andrew Stone believes that Carbon applications, applications created using the traditional Mac Toolbox (I believe that's what they call it -- the set of APIs that interface with all different parts of the Macintosh operating system) that can be made to run on both Mac OS X and Mac OS 9 or exclusively Mac OS X, are not "truly" Mac OS X native.

In his latest rant on the subject (and I mean that as a compliment, John), John successfully proves his point that Carbon on Mac OS X is not going anywhere. It is not merely a "stopgap" measure for Macintosh developers to use to step into Cocoa. Carbon will be in Mac OS X for the forseeable future. He argues that Carbon applications are just as native as Cocoa applications, since they don't require the Classic environment to run, and they even have a few advantages over Cocoa applications: the foremost of which is speed.

Go on, read the latest entry. John argues his point exceedingly well.

But I still have a problem with his argument. It's the fact that Cocoa can effortlessly take advantage of technologies that are available in Mac OS X. Examples of this are the standard Cocoa font panel and color picker, services, customizable Cocoa toolbars, the close box notification of whether a document has been changed after the last save, spell checking, and many other cool little things.

This is the crux of the problem, and John trips up when he makes this statement: "Carbon and Cocoa are developer APIs; they are of no interest whatsoever to normal Mac users." That would be true, if they couldn't notice the difference. But you can almost always tell immediately upon launch whether an application is Carbon or Cocoa -- Cocoa apps just have that spit and polish that befits a Mac OS X application, precisely because Cocoa applications get so many things "for free"; the developer (like me) doesn't have to write a line of code to take advantage of some Cocoa technologies.

So it ends up that Carbon and Cocoa ARE actually of interest to normal Mac users, and which is why this has become a hot topic for debate in many Mac forums. Cocoa applications are easier to use because they use standard implementations that are also used in all other Cocoa applications! Standardization of things like command sequences have always been a hallmark of Mac applications -- Cocoa just extends this standardization.

As a user of a Mac, I can almost instantly see whether a Mac application is Carbon or Cocoa. A Carbon application just doesn't "feel right" -- you don't get all the benefits of a Cocoa customizable toolbar (shame on you, Safari) if the app uses a toolbar, and you don't get to see the standard About box or the standard font panel or color picker. I feel at home with Cocoa applications, whereas I feel a bit uneasy using Carbon applications.

Now, don't get me wrong, Carbon is a perfectly acceptable programming API. I have no doubt that almost all of the little touches of Cocoa applications can be implemented in a Carbon one; but the fact remains that it takes some TIME for a Carbon developer to implement these features, whereas a Cocoa developer wastes exactly 0 seconds, 0 minutes, and 0 hours on stuff like that. It just comes with Cocoa -- that's why so many freelance developers like myself have downloaded Apple's free developer tools and started programming; it's just so easy!

I have the utmost respect for John Gruber's laborious arguments, because I agree with just about all of them. But it seems odd that he'd overlook such an obvious point -- Cocoa applications are just better (forgive me for passing judgement, John) overall, in most cases. It's just a case of whether its worth it for Carbon developers to implement Cocoa features; because I don't program in Carbon, I have no knowledge of how difficult it is to implement said features.

As Mac OS X continues to mature into an awesome operating system, I'm sure there is no doubt in anyone's mind (well, maybe in Andrew Stone's) that Carbon and Cocoa will begin to intermix -- Cocoa will begin to gain the benefits of Carbon (speed, mainly), and Carbon will begin to gain the features of Cocoa. Eventually, the only difference between the two will be the ease of coding, which I don't know if Apple can bring to Carbon or not.

But the fact remains that Cocoa and Carbon have a big effect on software usability, which, in the end, is very important to the normal Mac user.