BKeeney Briefs

One of the problems that I have is that when I’m done ‘browsing’ I always quit.  I know, I don’t have to.  My Mac has more than enough RAM and processing power to leave multiple applications open.  But since my task of ‘browsing’ is done I quit which then subsequently closes The Sixty One running in another tab or window.  It’s not hard to get back to where I was, but it’s irritating.

I ran across Fluid yesterday and started playing with it.  Fluid is an app that lets you make a double-clickable application for a particular URL.  You can assign your own icon to it and put the resulting application where ever you want.  I particularly like the subheading on the website describing Fluid:  Your web browser is for web browsing.  It’s a Site Specific Browser.

This app makes perfect sense!  My problems are solved.  After a little tweaking it’s done exactly what I needed.  So now I have a single icon in my dock that is ‘separate’ from my browser.  It’s a neat way to mentally separate my regular business apps from my news sites and so on.  I can see having myself having separate dock icons for my bug tracking website, my project tracking website and maybe something like the REALbasic forums.  Less clicks is better in my opinion with something I do multiple times a day..

It also gets me to thinking a bit about SproutCore.  If I can create a shell application (Fluid), what can’t my web app learn to take advantage of application stuff like the app menu?  It’s the best of both worlds, in my opinion.  It will be interesting to see how far this marriage of desktop application (i.e. Site Specific Browsers) to the new generation of web apps (like SproutCore) goes.

Thoughts?

I installed everything on Mac OS X (Leopard) using the standard Mac installer.  I didn’t have any issues.  There are two other parts of the installation package, a startup item installer allowing the db server to start at startup and, a prefpane that allows you to start/stop the server from System Preferences.

MySQL has an optional package that installed the MySQL Administrator and MySQL Query Browser applications.  It’s obvious from both of these tools that they’ve spent a lot of time and effort in making these tools usable and for the most part I was happy with their smoothness in Mac OS X.  They definitely don’t feel like a port of Windows apps to Mac OS X.  (Without using them in Windows I can’t tell you that the opposite is true or not, however.)

The REALbasic MySQL Plugin now available from Alacatia Labs at http://alacatialabs.com/products/realbasic-mysql-plugin/ and works with the Community and Enterprise Edition.  I had absolutely no problems connecting to my newly installed database (after adding a new db and user using the Administrator tool).

If it weren’t for the stupid licensing issues that accompany MySQL I’d recommend it for everyday use.  Alas, the licensing issues make that problematic.  From the Alactia Labs website:

It allows access to community installations of MySQL database servers using REALbasic’s built-in database API. While we are not lawyers, our interpretation of the GPL is that it is viral, and any applications that are distributed publicly must also contain the source code of the application and plugin. If you are in doubt about how the GPL applies to you, please consult your attorney.

Emphasis added by me.
That sucks because I think they’ve got some things going for it.  I know a lot of RB developers have stopped using MySQL due to the GPL licensing rules and I can’t say that I blame them.  Oh well, I guess it’s time to look at PostgreSQL or maybe MS SQL Server.

A couple of weeks back I started a new series called Dread Empire’s Fall:  The Praxis by Walter Jon Williams.  I sometimes dread starting a new series so I never buy more than the first book just in case it’s not to my liking.  I loved it and wanted to start the next book in the series NOW!

But alas, since it was a Sunday evening after the book stored closed I started thinking about the new electronic books.  In the past I pooh-poohed them for a variety of reasons but it starts to make sense.  I hate moving books and my wife hates my ‘library’ the consumes a large portion of storage.  Rarely do I re-read a book, or if I do it’s a decade later.  In today’s conservation kick it makes sense not to cut down trees if I don’t have to.  Perhaps the biggest reason that sold me is that the ebooks are a couple of dollars cheaper so you read enough and it’ll eventually pay for itself.

So I did some research on my options by calling my cousin.  Everyone needs to have a cousin like mine.  He KNOWS gadgets.  So not only did his wife have a Kindle, but he had a Sony e-Reader and he had an opinion (he always does).  He swore by the e-Reader and he swore AT the Kindle for their interfaces.  Then he said to go check out the authors I wanted to read on both the Sony site and the Kindle site and see which one was better.  For me, Sony won.

So now I have a Sony e-Reader.  It’s not the newest model (same cousin sold his existing one for a new one with a bit better display and interface) but it does the job well.  I’m impressed.  Very impressed and I don’t say that very often.

It takes a little while to get used to the delay on the E-INK screen but after a while you live with it.  The book I’m currently reading has large white text on black background chapter headers and switching to the next page always leaves an afterimage of the block, but again it’s not a big deal.

The e-Reader lets you switch from vertical to horizontal reading and also lets you adjust the size of the typeface.  After playing with the settings I prefer vertical at a large size.  You can view the screen at all angles and there’s not much glare to contend with.

The controls are minimal.  There’s a size button that let’s you change the size of the text on the screen, two separate sets of dedicated page up/down buttons that don’t seem to be in the right spot for me, a mark page button, a menu joystick and allows you to navigate on the screen and a set of 1 through 0 buttons that let you quickly navigate items on the menu’s.  The controls are a little sluggish but I don’t know if it’s from the screen or an underpowered processor.

Compared to the Kindle, the e-Reader seems sparse on the controls, but I think a book reader SHOULD be simple.  You’re replacing a paperback, not a laptop.

The Sony e-Reader plays MP3’s.  I have an iPhone and don’t travel much anymore so this isn’t a selling point and I honestly have no idea on how well it works.

The Sony unit requires a computer to transfer books unlike the Kindle that can do this wirelessly.  Again, since I don’t travel and when I do I generally have my laptop.

What is a problem however is the stupid Windows only software.  Come on, Sony!  Wake up and smell those Mac users you’re pissing off by forcing us to boot up into Parallels or VMWare.  The Windows only software works well enough for me to purchase, download and transfer books but I don’t have to like doing it that way.  (Sony, call me, I’m a developer.)  Books are transferred via a USB cable which is also how you recharge the unit.

I also found http://www.webscription.net/.  There you can find an excellent selection of science fiction authors with a large selection of free books.  Did I say free?

If you read a lot I’d recommend it.  If you travel a lot I’d recommend it.  If you read and travel a lot then you should definitely look into it.  I would have saved a lot of money in airports if I had had this device.

Comments?

SproutCore is essentially (I’m sure I’ll get some of the details wrong so don’t flog me, okay?) a porting of the Cocoa frameworks for use in web apps using JavaScript.  SproutCore is what Apple’s new MobileMe is/will be since the author of SproutCore is now an Apple employee.

If you take a look at this blog post from April, the developer does a great job of explaining the current state of web apps and how Ajax minimizes the inherit lag time of the web.  His take is that Client-Server applications will become the new way of doing things (at least for the next 15 years or so).  Build two applications – one for the client and one for the server – sharing data as needed.  It’s a ‘thick client’.

He also says that writing an application is JavaScript is like writing a desktop app in C.  This is where the port of a framework like Cocoa to JavaScript makes a lot of sense because the framework has had decades of work to make it fast and efficient, however, doing a straight port isn’t practical simply because of the decades of ‘cruft’ in the frameworks.  In other words, if Cocoa were written from scratch today, it would be leaner and meaner and wouldn’t have to support all that legacy stuff.  But wait, isn’t that what Apple’s doing with the iPhone?

Why JavaScript?  For the simple reason that it’s in every web browser on the planet!  In another blog post he suggests using a conversion tool to deploy your SproutCore application as a, wait for it, a static HTML web page.  Yikes that seems pretty darn simple.

Daniel Eran Dilger at Roughly Drafted Magazine speculates that this is Apple’s first foray into web apps and a way to kill Flash, Air and Sliverlight.  True or not it’ll be interesting to see if Apple ‘got it’ early this time.

I still have my doubts about web apps being more like desktop apps.  It still seems that you’re limited to the browser and implementing multi-step undo will be difficult.  Things like being in the middle of a form and accidently quitting the browser and losing your edits (because the app can’t stop and ask if you want to save your changes before closing) are significant features that will have to be overcome.

But, perhaps the solution isn’t a true web browser experience.  Perhaps it’s using a web browser control in a thin desktop client application.  If the controls act and work the same as a desktop application would the user ever know the difference?  Interesting times I think.

While HTMLViewer isn’t totally evil, I would say that developers looking for web browser-like capabilities should look elsewhere.  But therin lies the real kicker since there are NO alternatives to the HTMLViewer in REALbasic that I’m aware of.

So I’m asking the question.  Why is that?  Is it that no one’s really looked at the problem?  Are we assuming that RS will fix HTMLViewer?  If so, I wouldn’t hold my breath.  They’ll ‘fix’ the HTMLViewer right after they fix RTF support in StyledText.

From my own investigations into the matter, I think there are two possible alternatives to HTMLViewer.  One uses Webkit and one uses Gecko.  Both are cross platform but other than that I have no idea on the issues involved or the complexity of such a project.

I’m ‘motivated’ to help finance a web browser control for a host of reasons.  I’d like to help foster a web browser for REALbasic because I think it will help the RB community in addition to solving a very specific need of mine in a very big project I’m working on.

How big would a webkit or gecko plugin weigh in at?  Is that too big for RB apps that are rather large to begin with?  Could it be done in pure RB code using declares or is this strictly a plugin affair?

If it cost $500 would you be willing to buy it?  If you could get source code with it, would that change your opinion on the cost?

The floor is open for discussion.

Let me first say that I don’t do enough presentations to consider myself a subject matter expert.  Back in the day, I made my way through college by being an Aldus Persuasion expert.  I’d get the phone call on a Friday night for 300 slides to be done for a Tuesday meeting.  Myself and a couple of other college students would slave the weekend getting them done.  So I guess I have some knowledge, just not recent knowledge.

So is 280 Slides a great web app?  Seems to work exactly as described and it looks a lot like Keynote.  But there are a few things that just wouldn’t be acceptable in a desktop app.  For example, if you click on an object it becomes selected.  A selected object is outlined and has selection handles.  But when the mouse gets to the handles the cursor doesn’t change state.

Does that make it unworkable?  No, but it’s not what users of a desktop app would expect.  And maybe that’s where my biggest beef with web apps are.  People absolutely rave about how well such-and-such web app works, but taking the exact same thing and putting it in a desktop app would make it ‘unacceptable’ to everyone.

280 Slides has gotten drag and drop to work.  Super.  But I couldn’t seem to find keyboard shortcuts and their help system was non-existent.  All things that desktop users expect.

As to whether or not it’s useful, in college I had to travel 20 miles to the near sububs to the company where they had the data, Mac’s and most of all the software.  Web apps eliminate the need to have installed software in a specific location so that’s a huge advantage.  However, I lose my web connection enough to be lost when it’s not there so is it really an advantage?

I’m not railing against 280 Slides in particular because I think it has some awesome capabilities.  I’m just wonder if we’ve lowered our expectations so much for web apps that anything approaching desktop app functionality is ‘awesome’?  Until web apps no longer need the browser I think that’s going to be the case.

Your thoughts?

I know it sounds crazy, but the author makes the argument that since a lot of low level type people know enough java now to make this feasible.  Meh.  I don’t necessarily agree with him, but I’ll go with the flow for a second.  If you can get javascript to work like (or better than) Applescript then I’d say it’s a no brainer.

I’m sure the AppleScript folks at Apple would disagree with that but everytime I look at AppleScript all I get is confused and then mad.  Confused because it doesn’t seem to follow logical assumptions.  After a few hours of fruitless searching on the internet I end up giving up mad.  This is why I’ve never actually implemented AppleScript in any REALbasic application even though it’s been on my list of things to do for years.

My opinion is that since AppleScript has so few resources on the web it’s a failed scripting language.  Without a thousand examples of how to do something most people will give up and since I’m not an average user I’d say that most people just give up.  People not using AppleScript is probably the biggest reason why Apple came up with Automator.  They needed to dumb it down because people didn’t get it.

Since I’m a REALbasic developer I think using RBScript or some variant thereof could be just as valuable.  I would argue that part of the popularity of VB6 was that all the people that could use VBA (Visual Basic For Applications) to create some additional GUI goodies for Excel or Word and even the dreadded Access could switch over to VB6 and create ‘real’ applications.  So with a little scripting knowledge one could start off doing insanely simple stuff and move to more complicated stuff.  BASIC is, well, basic and easy to understand.

Call VBA the gateway drug of programming languages.

So why not REALbasic as a scripting language?  Well, Apple would have to license or buy it from Real Software.  I don’t see that happening.  Apple wants everyone to use Cocoa and it strikes me as a long time Apple user as an ‘admission of failure’ from the folks in Cupertino.  I don’t see it happening anytime soon but then I’d love to be wrong.  It would make REALbasic an awesome choice for beginners which is a sweet spot for RS anyway.

Thoughts?

More than a few people have emailed me about when are we going to release information about ARBP. The answer is soon and that’s about all I can say.

What I will say however, is that the board members have lined up a sizeable list of free and discounted software for members.  No details as of yet, but we think that alone will make ARBP worthwhile to join.

More on this soon through the official ARBP website.