<Neil> just our luck it's a dup :-(
(Note: Please don't spam the bug with comments, or extra cc's. Spam here. Otherwise, bmo admins are not going to be happy.)
A little over a year ago, I submitted a story to the Strange New Worlds VIII contest. Apparently Dean Wesley Smith, one of the three judges and the editor for the contest, liked it, but it didn't quite make the final cuts. Other times I've written amateur sci-fi or fan-fics, and generally, they were well-received. Unfortunately, I've not done very much in that field since.
It's a trade-off. I've been a software engineer professionally for a while now, and I've not spent any time writing science fiction. Certainly I haven't studied it as a field enough to see what others have done. One regret is that over the last several years my knowledge of sci-fi has been mostly limited to the classics, a few interesting novels and authors, and Star Trek.
Still, I sort of miss it.
One of the cardinal rules for writers is that you must write. It's true for blogging, it's certainly true for programming, and it's true for science-fiction writing. Having a non-fiction book under my belt is quite an achievement, but I never want to lose my appetite to be an artist. I never want to stagnate.
In terms of literature, I've stagnated. Just today, I asked myself two questions I'd want to base stories on. The first is, "What if a military grew so large that no officers could live long enough to learn how to command it?" I remember reading in a book by Tom Clancy and Gen. Fred Franks, Jr., (ret), "Into The Storm", that it takes twenty years to develop a senior army commander. Suppose the military got so big that no one man could gain the experience he needed to direct it? What would the military do to get the most bang for the buck? (Pun not intended.)
The second question is, "What uses can a naval force be put to in a war against a space force?" I don't believe I've ever read a sci-fi story that tried to answer that question. My first thought is, "Very little." But that almost certainly ignores what centuries of naval history have taught us. My own understanding of naval warfare is somewhat limited, but I do know that I didn't need a space suit in my two years in the U.S. Navy. The closest glimpse I got of this was from Harry Turtledove's Worldwar series, and naval technology had not nearly advanced to the point we have now.
I'm not stating my opinion on war here, but science fiction combat is one of the biggest fields for sci-fi. Nor am I trying to actively capitalize on my talents in sci-fi. I write fiction as a hobby, when I feel like it. If I spent several years at it, I could probably become a decent professional writer. First, though, I'd need to do my homework -- both in what's been written and in what's plausible. Finally, I always try to remember in sci-fi writing that it's not about the gadgets and the gizmos, but about the people in the stories.
I would really love to make friends with a retired military strategist. Just to poke his (or her) brain about both history and tactics. No one can write about anything they don't understand the basics of. Anyone who tries inevitably fails, as I've learned time and time again.
Also, if I was ever to go to college, this would be a big reason: to learn more about the world (and universe) we live in, to express it to people. Assuming, of course, that I ever budgeted the time for the writing. Because ultimately, I determine my schedule aside from work hours.
In designing Verbosio, I made an assumption that said ID attributes were going to be troublesome. Simply put, every ID attribute must be unique to the document. But when you include fifty or more overlays, somewhere an ID attribute being not-so-unique is a distinct possibility.
To solve this, I introduced a concept of scope and local id combinations. But this alone was not enough. What about XUL's command and key attributes, which are inherently tied to ID? These were IDREF-type attributes for all intents and purposes, and I could not support them.
Until today.
I conducted an experiment where I set ID attributes after the XUL document had finished loading. I also set command attributes. This mimics how Verbosio would work to a great deal. Surprisingly, it worked perfectly. One of my biggest fears about Verbosio development has evaporated.
A demonstration of scope and local id, with local id refs, combining for ID and IDREF attributes. It apparently doesn't work in Firefox 1.0.7, but does work in a SeaMonkey trunk and 1.8 branch SeaMonkey. So Firefox 1.5 users should see it too.
Once upon a time, I filed a bug to support external context menus for textboxes. My goal then (and now) was to allow me to create new context menu items which would include the default context menu items, fully functional. Unfortunately, today when I tried to do that, it just didn't work. For some reason, my new code couldn't call on the controller with the right arguments.
So, I went back to the drawing board.
textbox.xml (xpfe version) is somewhat convoluted. You have the master textbox bindings (id="textbox", "textarea"), which contain a <xul:hbox/> that has its own special binding (id="input-box") on it, and a <html:input/> element as a child of the hbox. The hbox's binding includes the <xbl:children/> and a context menupopup designed for it.
Unfortunately, there doesn't appear to be a very direct way to add menu items to this special context menu. You can't just include a <xul:menuitem/> or <xul:menuseparator/> as a real child element of the textbox. In fact, any child elements of the textbox at all seem to break the textbox quite badly.
What's the solution?
Well, the <xbl:implementation/> and <xbl:handlers/> of the textbox primary bindings, and of its hbox, are pretty reliable. So I create two new bindings for <xbl:content/>, one for the textbox, and one for the textbox's special context-menu hbox. These bindings otherwise extend the primary bindings of the textbox. A little CSS and a new type attribute for the modified textbox, plus a modified oncommand event handler for the context-menu hbox (to allow for my new commands), and remarkably enough, everything works.
That said, it's still a very convoluted path. I'm doing a lot of work for a very tiny effect, and I spent hours chasing down other ratholes before realizing this solution. I wish the textbox.xml bindings actually let me insert menuitems and menuseparators directly as child elements of the textbox, to become additional, homegrown commands for the textbox or parent application. But I'm not quite sure how to modify the textbox.xml bindings to pull this off. Maybe a couple <xbl:children includes='menuitem,menuseparator'/> elements strategically placed are all I need to add to the textbox.xml bindings, along with the modified oncommand event handler... but I don't know.
Opinions, anyone? If I'm going to file a bug to fix this, I should know how to do the fix. We also have to consider editable menulists.
P.S. Source code for the new bindings is available upon request. Yes, it's for Verbosio. No, it's not finished.
UPDATE: My guess above turned out to be right! I'll be filing a bug shortly to add this functionality.
I'm looking for a reliable web hosting company that will let me upload and maintain my website's files via a version control system such as SVN or CVS, for mostly personal usage without branding.
Please, do NOT debate what version control systems are better. Any such comments will be deleted. I just want a website that won't carry any branding or content I don't control.
I only have a few other requirements:
Whether I need services such as MySQL or Perl, I don't know yet. I may also ask for FTP access, but primarily for a staging area (so I don't have fifteen billion commits while I debug things).
In case you're wondering, yes, whatever website I develop with such a host will very likely carry a good volume of technical articles. It may even replace this blog (and don't get me wrong, mozillaZine, I love this blog you've provided me for free). But at times there will also be articles which have nothing to do with Mozilla and will be oriented for a different audience entirely.
I just want complete freedom to do what I want on the web, with an audit trail, and without hosting the website myself.
Mozilla-related hosts will get preferential treatment. XULPlanet? MozDevGroup? Are you listening? :-)
UPDATE: Wow, I feel like I'm on the receiving end of one of those "When banks compete, you win" commercials. :-)
A few people have suggested the requirements I list are a bit onerous. Typically with .htaccess the first one is dead-on simple, a one-line change. I know because I've done it many times. The second is probably just as easy, and I think .htaccess can help with that too. The third is a pretty standard practice even with FTP-based hosts, and the fourth is non-technical.
As for setup and maintenance: I'm sorry, folks, that is one thing I specifically do not want to do. Honestly, I could run my website on my own machine if I wanted to do that. That's why the fourth item is there.
Some of JSLib's features, especially its File handling routines, are so darned useful I can't imagine why it's not part of the mainstream Mozilla trunk. Yes, there's calendar's use of JSLib, but let's face it, that's not mainstream. (Sorry, Sunbird guys.)
Really, I'd like to see some of this code (again, mainly the File stuff) start getting checked in under mozilla/extensions/jslib (or somewhere else in the Mozilla trunk which everyone could use, like toolkit). So I'm wondering what it would take to land a subset of JSLib there. JSLib can continue to maintain independent development of a more complete JSLib toolset, but some basic stuff such as Calendar already uses would fit fine as an extension. You wouldn't have to build the JSLib extension by default, either.
UPDATE: Oops. Little did I know that JSLib isn't used by Calendar either...