Hi All,

Yep, Beyond Compare 4 for OS X uses Lazarus with the Carbon backend.  Thank you 
to all of the hard working Lazarus and Free Pascal developers that helped make 
it possible.  

While I did mention some things in that post that I didn't like about 
Lazarus/Free Pascal, I think you've done excellent work.  I was really 
impressed with how much worked out of the box and how compatible everything 
was, both in the LCL and the compiler.  The Objective Pascal extensions are 
really well done.  Not having the IDE go brain dead while debugging was a 
welcome change too. :)

We actually got the core product up and running fairly quickly; the last two 
years have been spent making it more at home on OS X.  We've submitted most of 
our changes back to the team, and will get the remaining ones out soon.  
Unfortunately a number of the enhancements, like per-window sheet support, rely 
on a lot of our application level behavior, so they can't be incorporated into 
the LCL easily, but I am happy to answer any questions or share the relevant 
code snippets for anyone who wants them.

We will definitely be looking into LCL/Qt for our Linux version once we get v4 
released. Seeing the Qt5 bindings has made me very happy.

On Dec 25, 2013, at 11:51 AM, Marco van de Voort <mar...@stack.nl> wrote:

> On Tue, Dec 24, 2013 at 04:44:37PM +0000, Graeme Geldenhuys wrote:
> Which hopefully makes clear that Delphi compat unicode is needed by some :-)

As long as "string" supports Unicode, and AnsiString/UTF8String casts do 
appropriate conversions, I don't really care whether it's UTF-8 or UTF-16.  One 
of the things that made code sharing easier is that OS X and modern Linux both 
use UTF-8 for C strings, so we were able to use string/TStringList/etc on all 
three platforms, with all three compilers, and know that it was always Unicode. 
 AnsiString was used in places on Windows where we needed it, but that was 
about it.  There were cases where we had to use UTF-16 on OS X to minimize 
conversions during drawing, and there were cases on Windows where we had to use 
UTF-8 to reduce memory usage.

Delphi compatibility in general has been very important, though, and I 
appreciate all the efforts in that direction.  BC's source code needed it, of 
course, but we also rely on some large third party libraries, like Indy and 
SecureBlackBox, and have had to port several others ourselves (ZipForge, 
Abbrevia, chsdet, some bits of the JCL). I'm quite confident that if there had 
been a significantly higher barrier to bringing our code over we would have 
switched to a non-Pascal environment instead.

In any case, thanks again.  We really couldn't have done it without this 
community.

-- 
Craig Peterson
Scooter Software

--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Reply via email to