Tuesday, January 31, 2012
Saturday, January 28, 2012
No IDE is mature until it has a TSmiley component.
This week I got a sudden urge to write TSmiley component for Smart Mobile Studio IDE. After all, what is a development environment without a smiley?
My TSmiley is not an enterprise-y solution like latest Nick’s revisit of the old theme ;), oh no, it is a lean and mean component without any special bells and whistles. You can select the smiley’s emotion and it will change the look. And that’s it.
I thought that a story about TSmiley for Smart would be instructive for you, dear reader, as this is almost the simplest component one can write. Read on to see how writing a component for Smart is very similar to writing a component for Delphi and how it is also utterly different.
Friday, January 20, 2012
I mainly started playing with the Smart Mobile Studio because I wanted to write some stuff for my iPad. OK, there’s a small issue of possibly producing client applications for my job and maybe for some freeware/shareware stuff I’m thinking about, but this is not on the horizon yet. Therefore, iPad. (And I don’t have iPhone and I don’t care about writing stuff for my wife’s Android, so – iPad.) And writing for iPad means supporting touch gestures.
[Yes, I know I could use Objective-C but – bleuch, really? – and I could use FireMonkey but I don’t have a Mac and don’t want to buy one just for playing around and I can’t make Platform Assistant run in a Hackintosh, Therefore, Smart.]
Touch is natively supported in Smart. Gestures are not (but that may change before the release). What’s the difference, you ask? Touch subsystem will give you information about separate fingers like – finger has touched – another finger has touched – first finger was moved – both fingers were moved – while gesture subsystem will give you a simple – zoom gesture in progress. But hey, let’s start with touch. Lots and lots of stuff can be written with just the information about the fingers touching the screen.
Tuesday, January 17, 2012
Part of the Zarko’s requirements (see the original post for full text) was a cancellation support.
At any time the "master" thread could be signaled to terminate (from the app's main thread) all child threads (and itself).
When I was originally implementing this using the Parallel.Pipeline abstraction I had to put some work into the cancellation support. The main reason for this was inappropriate abstraction – Parallel.Pipeline is designed around the data flow processing and supports only a basic cancellation of the “stop everything” type. To be fair, that would comply with the Zarko’s requirements, but I wanted nicer solution where you can stop processing and then continue with a new work item without rebuilding the background thread mechanism. [Pipeline solution inherently supports cancellation but you cannot recover from it – to continue processing one would have to destroy the pipeline and build a new one.]
Tuesday, January 10, 2012
When I wrote OmniThreadLibrary in Practice –Background Worker and List Partitioning in November, I noticed that OmniThreadLibrary needed another high-level abstraction, a background worker. I published some ideas on how the background worker interface could look. Those ideas were later developed in a full-fledged high-level solution.
Background worker is designed around the concept of a work unit. You create a worker, which spawns one or more background threads, and then schedule work units to it. When they are processed, background worker notifies you so you can process the result. Work items are queued so you can schedule many work items at once and background thread will then process them one by one. [Actually, Parallel.Pipeline is used as a base for the implementation.]
After I finished my very first Smart program, I wanted to enhance it with some interactivity. I wanted the user to be able to navigate through the Mandelbrot set by using mouse and touch. For now, I have only implemented the mouse part, touch events will be handled later (soon, I hope).
I wanted to achieve few different ways of navigation:
- Click & drag with the left mouse button shows a rectangle on the screen. When the mouse button is released, program zooms in to display the selected rectangle.
- Double-clicking zooms in around the point of click.
- Right-clicking zooms out around the center of the image.
- Right-click & drag shows a line on the screen. When the mouse button is released, program moves the current view (point of first click is moved to the point of release).
- If a drag operation is in progress, user can click and release the other mouse button (left if right-drag is in progress, right if left-drag is in progress) to cancel the drag operation.
You can see the navigation in action in this (very low quality, sorry) YouTube video.
Saturday, January 07, 2012
Wednesday, January 04, 2012
[original author unknown]