FileSuite, Delphi Core and the Cross-Platform Quest

Well, we have a new release of FileSuite featuring a fine-grained multi-threaded file engine which can execute any (oh, well…) custom action, exe file or script on a file or host event (yes, you can have a centralized backup control for any host from the network immediately when it will be online – no need to install any software client) enough bug fixes, mirroring enhancements aso. You can see some from the enhancements in the screenshots page. Also we found a new payment processing company which has much more features thing which allowed us to reduce the price. So, we must be happy… And yes we are. Almost.

This because working on FileSuite we found some things which I think that needs fixing. And the very first thing which needs fixing is something related to Delphi’s core: The naturalism of Delphi environment. And here I have in mind firstly the Delphi language and the library (ie. VCL + RTL).

Let us not forget that this is one of the main advantages of Delphi: The natural way in which the things are flowing, thing which started to show its lack of recapitulation. Because I think that together with the continue innovation cycles, a product must have quality (recapitulation) cycles to enhance its usability. And by quality cycle I don’t mean necessarily bugfixing.

Let’s take two examples:

Because TThread.FreeOnTerminate doesn’t give you the possibility to see if the thread is actually finished – in other words it doesn’t set the thread’s variable to nil because it uses Thread.Free and not FreeAndNil(Thread) (@Embarcadero: Guys, how many times we discussed about FreeAndNil vs Free?), forces you to have an entire lifetime management of your thread (which can be a very ‘nice’ task if we are in a parallel environment and ever nicer if the thread in discussion should be created only in certain circumstances) instead of a simple check if Thread=nil then begin..., which at least for me, it would be the natural way to use it. For the hackers, the guilty code is located in Classes.pas in the ThreadProc function:

  finally
    FreeThread := Thread.FFreeOnTerminate;
    Result := Thread.FReturnValue;
    Thread.DoTerminate;
    Thread.FFinished := True;
    SignalSyncEvent;
    if FreeThread then Thread.Free; //<--- Here!
{$IFDEF MSWINDOWS}
    EndThread(Result);
{$ENDIF}
{$IFDEF LINUX}
...

So in short, watch out if you want to use FreeOnTerminate because you cannot test for its state (nil or not) and you’ll get some very nice ‘random’ Access Violations from ‘nowhere’, if you aren’t careful.

The second example about naturalism is tied about a GUI experiment which we did related to…

Cross-platform quest

First, a small preamble: There were enough speculations about what the cross-platform will bring to us as programmers. But one thing is for sure:

Embarcadero is now in a much worse position than it was in Kylix and .NET campaigns. In the Kylix campaign there were no other commercial vendor to fight with. They were alone in the market. Entirely alone. In the case of .NET there were Delphi 7 against Visual Basic 6 – and we all know that D7 was much more superior than VB6 even than .NET 1.0, even than .NET 1.1, but…

But now the things are changed: Apple is king on his own platform. Mac OSX framework (Cocoa) has a good design and Apple provide free tools which we can regard at least as ‘entirely usable’. At least, if not more. Much more. Their tools support (of course) the entire Mac OSX functionality, including the 64-bit ‘problem’. Delphi will be a newcomer on that platform with (still) a dubious past (not to blame Embarcadero here), capable to compile (most probably) only 32-bit executables (which even if on Mac this doesn’t matter so much, except the memory barrier, it still remains at least an important psychological argument against Delphi). Also, let us not forget the documentation problem and, of course, the quality. Oh, quality. How many bugs will be? …and how many bugs will be compared with Apple’s toolchain?

So what could Delphi offer in order to justify its tag price?

I think that their only chance to succeed there is productivity, power and flexibility. And for this the naturalism is a core component.

So, we tried to see how productive we are with the present Delphi (Delphi 2010 – for conformity). Because besides the standard GUI artifacts there are other widgets which one must build more or less from scratch.

So, the second example about decay of Delphi’s naturalism is a UI ‘component’ which we used in the custom actions engine (see in the left-top area of the screenshot):

You can add many custom actions to any file event. Powerful multi-threaded engine to help you out.

That tab set ‘control’ from the left-top corner was built in approx. 10-15 minutes of coding. Yes, we know that there are better tab controls (also we have a certain library which has a similar component) but I wanted to see how quick we can build from scratch a new one and what hurdles one can found.

The good: Canvas’s properties were good enough to allow us shaping the component in few lines of code (code available upon request, btw).

The bad: The underlying control which we used as ‘layout’ engine (it is a simple TListBox 🙂 ) even if we say ‘OwnerDraw’ our ListBox says ‘No, you won’t have the entire control of the Canvas. I will draw the selected item like I want with the color which I want and you will not change that’ Pretty rude, eh? In fact, once again you must look at the underlying code to see what’s happening because the ‘OwnerDraw‘ has lost a little the meaning of Canvas full control (Owner + Draw).

In fact, I do think that burning in such important things related to program look and feel can be regarded (at least) as a ‘curious’ design decision…

In my humble opinion, the rule of thumb is: If a feature is closer to the user’s human nature (artistic feelings etc.) then that feature is more volatile than a feature which is closer to the technical part of the problem (eg. something which deals with data storage, for example). Hence the said feature must be provided with the according customization engine.

Ok, in this concrete case we could take a grid and do our job. But then another problems arise. Or a simple TPaintBox, TImage etc. Or even to build a ‘real’ component derived from TCustomControl. But we wanted to see how much the framework helps us. It is ok for our needs here but it could be better. Much better.

What are your opinions on this?

PS: As always, we expect feedback on FileSuite also especially now when we added enough interesting things there. Download and see.