I just realised that NSLog allows parameters. I’d previously been using
NSLog([NSString stringWithFormat:@"%d",randomVar]) …
But now I realise that the I don’t really need to do this. A simple call to NSLog will work as well.
NSLog(@"%d",randomVar);
It still isn’t as easy as php or even java, but it’s shorter and tidier and so better.
Not much posting recently. But I’ve been working getting SQLEditor ready for release. The big things recently have been bug fixes and developing a serial number system.
It’s extremely annoying to have to spend any time at all working on the serial number system, because really the time would be better spent actually improving the software. But given that I actually want people to buy copies of the thing it is sadly necessary.
I have a simple test program working already and as soon as I develop some kind of key generator system I’ll be able to add it (probably to beta 6).
Beta 5 is complete, so it should be released tomorrow.
With the announcement of Dashboard in Mac OS X 10.4 Apple, like many other companies, seems to have gone for a standards based approach. Dashboard is said to be based on HTML, CSS and javascript. A webpage in all but location. Microsoft tried something similar of course back with windows 98. You could display bits of webpages or activeX controls or java applets on the desktop. It didn’t prove all that popular then, but those pagelets were slow and clumsy. I very much imagine that dashboard is neither slow nor clumsy.
More importantly though, dashboard objects have two interesting features. The first is that they use interpreted, not compiled, languages. The second is that they are essentially cross platform. I know that there doesn’t seem to be any particular other platform that can they can actually be moved to at the moment, but I feel fairly confident that before next year’s release of Mac OS X 10.4 someone will develop a suitable runtime for linux and quite likely windows as well.
The dashboard concept seems to fall very much into the current fashion for application development. You write the interface in html, xml or something like it; then write the code in javascript or some kind of interpreted language. Then you provide libraries written in C or Java that provide the core functionality to the system. Mozilla’s XUL and Microsoft Avalon (windows xp next generation user interface) both use this approach. The Apple iTunes store also uses xml to describe the interface.
It’s easy to see why this approach is popular. Building user interfaces from xml makes it much quicker to produce interesting results than having to change C++ code and rebuild. Multiple tools can be written to access the format and the result can be modified without rebuilding the main application. (Given modern build times always an advantage).
One possibility is that dashboard may be something more than just a widget system. I have no inside knowledge whatsoever, but what if in future you could write whole applications using the dashboard system. What if you could create windows that were written in html/css/javascript and then tied to cocoa applications, much as we currently tie interface builder nib files to cocoa applications?
Alternatively there is this mysterious business with Mozilla, Apple and Opera. The three have decided to work together to improve plugins, but what if they are actually considering a future application development and deployment system to compete against Microsoft’s .net? Combine the open .net implementations with something like dashboard and you have a cross platform development system that might offer developers a good incentive to develop for.
I have no knowledge of the future though, so I guess I’ll have to wait and see
There have been lots of articles today in newspapers because the Oxford English Dictionary publishers have claimed that people are confused and choosing words incorrectly. For example “pouring” instead of “poring”. The problem being that people are basing the word choice on the sound and thus homonyms (or homophones if you prefer) are confused. There are quite a lot of words that sound the same but different meaning, for example caret (a typographical mark and the blinking insertion point in a text editor) and carrot (vegetable).
However I offer a simple solution: Have a brief definition of the word in the spell checker. Visual Studio already does this for programming languages so adding it to word processors is hardly difficult. The only issue really is likely to be disk space. If this is really a concern maybe some kind of online system? But I really don’t think it’s much of an issue given the current size of word processor installations anyway.
It would allow writers to check whether the word that they selected had the correct meaning. Multiple meanings could also be listed, either in a list or with some kind of rotating display.
Possibly it might even improve the quality of written english online? Of course it may be that there is a word processor that already does this. In which case the idea isn’t as original as I thought… but I would definitely like this feature in my word processor and even more so in system wide spell checking. 
[Edited: Because I suggested that Caret and Carrot were spelt the same.]
Well, I feel much better today. I’ve thought about it a bit more and I realise how very lucky I was that I found about the bug before the thing got a public release. I’m already working on some ideas on how to fix it. More on that as I think it up.
This really shows the importance of testing stuff. So thank you to everyone who has tried SQLEditor in its various versions.
Yet again the fact that I’m developing on Mac OS X 10.2.8 is causing problems. Bruce tried out a copy of SQLEditor (Cocoa) on 10.3 (Panther) and it doesn’t seem to work at all. You can’t seem to add objects to the canvas which is the key requirement. Most of the other functionality is based on this particular activity. I’ve looked quite carefully at the code and I really can’t see where the problem is. There isn’t anything odd going on.
This is really bad news, especially after the previous problems that occurred with the java version on 10.3 (which was the reason I wrote a cocoa version in the first place). I’m really not sure what to do.
This has made me a bit depressed because I’ve been working really hard on SQLEditor recently to prepare it for release.
It’s really annoying that there isn’t better compatibility between Mac OS X versions.
I’ll try to write some more about what I’m going to do about this tomorrow.
Punkish made the suggestion in one of the comments (actually the only comment) back on May 29th about adding an actual database to SQLEditor and turning it into a database program. The more I think about this the more I like the idea so it may end up happening. Although it will be a separate program from SQLEditor. SQLEditor will continue as it is because I need it that way for various projects myself.
BTW: The new cocoa version of SQLEditor is about to be released into public beta. Probably either today (Sunday) or tomorrow (Monday).
One thing that is desperately obvious when rewriting a java application to cocoa is overlapping views. In java you can often overlap swing components as long as they are lightweight (not operating system controls for instance). The cocoa documentation says that you shouldn’t overlap view components. This presents something of a problem obviously. How do you make such a significant change?
Currently SQLEditor uses NSViews for it’s onscreen rendering, however since the tables and comments can be freely dragged around there are three possibilities:
I’m still thinking about the best way of doing this. (1) is the current solution, I don’t like (2) and (3) looks like lots of work.
I think the best plan is to find out if (1) works on 10.3 and go from there. One approach that I am seriously considering is to rewrite the container class instead and continue to use NSView subclasses for the subcontainers.
David was commenting that drag and drop from the java version of SQLEditor was handy, so it’s returned!
I implemented a new floating window which allows the user to drag and drop objects onto the main canvas. Which seems to work quite well. It doesn’t replace the existing menu options but it provides an easy and intuitive way to add objects. At least I hope it does…
Thanks to Cocoa Menu Validation I now know how to do dynamic enabling and disabling of menu in a tidy way. Previously everything was less tidy and more confused.
Thank you Chris Hanson!
One of the things I’ve been doing recently is to rewrite SQLEditor to use cocoa instead of java’s swing toolkit. This gives a much better application for people using Macintoshes, but it has meant a file format change. The old format relied on java serialization which isn’t possible under cocoa.
The key question is this: are users willing to swap the superior performance and extra features for the hassle of exporting and reimporting their data?