Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/globalfunctions.php on line 779
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/BLOG.php on line 170
And Time Marches On
Warning: Parameter 1 to NP_Geshi::event_PreItem() expected to be a reference, value given in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/MANAGER.php on line 331
Been working hard on BuildFactory, pushing out the 1.0.6 update today which includes support for email reporting.
Oh yeah, Colin Devore interviewed me about BuildFactory. I'm so interesting, I warrant explaination :-p (yeah right).
Besides that, been looking into the various alternatives for writing cross-platform applications. So far the options are:
Basically, the options all suck, every single one of them.
Qt: When looking into Qt, the development tools are fantastic, and the concept of signals and slots is vert similar to Interface Builder's concept of actions and outlets. The downsides however is that it costs for commercial use (65% discount for small businesses), and it looks slightly off in some of it's widgets on Mac OS X, like with the QToolbar.
wxWidgets: wxWidgets is similarly good alternative, see: completely free. It does however severly lack decent development tools, which makes it a very difficult choice. It doesn't look too bad either. But the question of development time, versus cost is a big one, a very big one.
Mono: Being a former .NET monkey, Mono is a good choice, I'm familiar with it, but there's a couple of problems. Mono on intel Macs...sucks. That, and the Dumbarton framework, which is supposed to make using a C# core set of code in Cocoa applications is almost perfect for the job, because of general intel-Mac-monosuck, it's still a no go.
Java: If anybody thinks that Java based applications, even with SWT, looks like anything native on any platform, they're completely freaking wrong. Java sucks, AWT sucks, Swing sucks, SWT sucks far less, and is almost there, but in my opinion, java is great in the enterprise realm, but I'd rather it stay away from my desktop.
FLTK: I really threw FLTK in there for sake of a long list :). We used FLTK for a project in Stroustrop's C++ class, and it's not half bad at all, but a bit limited, so most likely not really suited for commercial applications, since things like Cocoa, .NET, and Qt (via signals and slots) allow for "bindings" in some sense of another from the UI to the code.
GTK+: GTK+ is in the list just because I like to bash it :). GTK+ looks horrid on the Mac platform, decent on Windows, and still kind of ugly on X11-oriented platforms. Despite the work of the GTK+ OSX project. Ew.
Dual code bases: Most of the contracts I've been looking at lately are for companies that maintain dual code bases, and need to bring their Mac product up to par feature-wise with their Windows client. It's really the last possible, shittiest option in my opinion, double the work, half the fun.
It's like being between a rock, and a hard place, and a somewhat hard place, and a really hard place, and a harder place, etc, etc. As much as I love Cocoa, I wish it was cross-platform right now, because the project cannot be Mac-only, bummer.
[tags: qt, wxwidgets, cocoa, mono, gtk, fltk, java, cross-platform]
Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/globalfunctions.php on line 779
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/ITEM.php on line 61
Replies
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
Warning: strtotime() [function.strtotime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 101
http://www.mono-project.com...
But now that i'm starting on the main application itself, i'm torn between maintaining a dual code base or taking the wxWidget route (QT is out for me too because of cost). I don't know about the rest of the world, but IMHO I think all the screenshots on the wxWidget page look terrible, not as bad as GTK, but for Mac users, its easy to tell that its not built using Interface Builder.
I'm now considering going the PyObjC route to solve this problem. Using Python for the backend stuff and interfacing with Cocoa and MFC for the UI portion. You have to sacrifice launch time performance, but the actual runtime performance is actually pretty ok. But most importantly, the app will look native.
Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/COMMENTS.php on line 391
08:59PM,
Warning: date() [function.date]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/globalfunctions.php on line 1112
Warning: strftime() [function.strftime]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PDT/-7.0/DST' instead in /home/greenp4/public_html/bleepsoft/tyler/nucleus/libs/globalfunctions.php on line 1132
04/07/06