
Lazarus 2.0 RC3 – Delphi-compatible cross-platform IDE - mariuz
http://forum.lazarus-ide.org/index.php/topic,43665.0.html
======
AnIdiotOnTheNet
I love the idea of a WYSIWYG IDE that's integrated with the language like
this, or like VB used to be, but personally I just can't stomach the whole
"have to learn yet another language to use it" problem. From what little I've
played with Lazarus and FPC it seems really nice though, and I might make use
of it for some smaller projects at work in the near future. I'm sick of trying
to make web apps and all the ridiculous nonsense with that process.

One wonders why we don't have a more generic form of this sort of thing. And
no, I don't mean the various "GUI builders" that are out there that produce
code you then have to merge with your program, or an XML descriptor that you
have to parse with your program, because those are still specific to having
bindings for your chosen language.

There really isn't a reason I can think of that I shouldn't be able to throw
together a GUI in a WYSIWYG editor and maybe define some basic behavior, then
give it one or more programs it should run in the background and pass messages
back and forth. Or even let me just tie events to a command pipeline and dump
the result into another widget, basically just letting a GUI be part of the
composable toolset following the UNIX philosophy.

~~~
dragonwriter
> There really isn't a reason I can think of that I shouldn't be able to throw
> together a GUI in a WYSIWYG editor and maybe define some basic behavior,
> then give it one or more programs it should run in the background and pass
> messages back and forth. Or even let me just tie events to a command
> pipeline and dump the result into another widget, basically just letting a
> GUI be part of the composable toolset following the UNIX philosophy.

Sure, you can do that, but you need a protocol/interface/API between the GUI
and the program(s) it interacts with, and then you need to either manually
consume that in the language those programs are in or have a library that
handles the interaction, and the problem ends up being essentially equivalent
to language bindings directly to the API.

~~~
tabtab
As I view the problem, what's lacking is a _GUI markup standard_ roughly
comparable to HTML. HTML browsers were not originally meant to build full-on
GUI's in, but the industry has accepted the habit of forcing them to "do"
GUI's using convoluted tricks and giant JavaScript libraries.

By the way, the "GUI markup language" doesn't necessarily have to be XML-only.
Maybe JSON or CSV versions can be defined also. However, XML is a good start:
learn to walk before you run.

As far as how interaction and screen changes could be handled, see:
[http://wiki.c2.com/?GuiMarkupProposal](http://wiki.c2.com/?GuiMarkupProposal)

I particularly dig the 3-type "update" technique that uses "Attribute", "Tag",
and "Delete" scope. (It's about half way down in the document.)

~~~
whitten
Weren't XAML and XUL supposed to be user interface markup languages ?
Wikipedia thinks so:

[https://en.wikipedia.org/wiki/XUL](https://en.wikipedia.org/wiki/XUL)

[https://en.wikipedia.org/wiki/Extensible_Application_Markup_...](https://en.wikipedia.org/wiki/Extensible_Application_Markup_Language)

~~~
tabtab
If the "industry" adopts them as a standard, then they could take off (and if
not encumbered by intellectual property lawsuit risk). XUL also looked "too
Webby" to me, closer aligned to HTML than desktop-like GUI's.

~~~
tomc1985
I'd beg to differ, XUL produced very clean native UI yet accepted styling with
CSS years before I'd seen anything else like it. At the time I was writing
Firefox addons and I was blown away but what I could do with it vs. WinForms
or somesuch

RIP XUL, you died too early

~~~
amyjess
FYI, XUL is being kept alive by the Pale Moon/Basilisk team, who has created a
next-generation platform based on XUL called UXP (Unified XUL Platform).

[https://github.com/MoonchildProductions/UXP](https://github.com/MoonchildProductions/UXP)

------
zoom6628
Its funnt how people will not want to use Pascal of any flavor because its
perceived as old/obsolete and yet the same people have no problem firing up
AWK to solve a text processing problem.

LAzarus provides a great way to address the perception. Fast, free, rich
language underneath. Im about to start using in my hobby IOT stuff, but as
other posters have pointed out, it works great for Enterprise level stuff as
well. Single exe executable is, in my books, a huge advantage.

FTR have started looking at nim as well which seems so far to be bit of a
pascal 'reborn' and it also compiles down to single executable. I recommend
people look at both if you are needing to distrbute software without the
normal installer drama.

Bottom line i believe there is no software silver bullet. Each language has
pros and cons and the biggest challenge these days is choosing the appropriate
one to use.

~~~
floatboth
It's the aesthetic ("program", "procedure", "begin" and "<>") and the
association with proprietary software (Borland) that make Pascal feel
"uncool".

While Awk, like C, Is Unix™. Timeless, classic, already there, and _cool_.
This is absolutely just subjective crap, but this is how most of us unix-heads
feel :)

------
mwexler
Wikipedia provided this simple description, which would be nice to see on the
RC post (but perhaps they assumed the only folks interested in an RC post
would be folks familiar with the tool already):

Lazarus is a free cross-platform visual integrated development environment
(IDE) for rapid application development (RAD) using the Free Pascal compiler.

~~~
tabtab
I miss WYSIWYG IDE's like Delphi, VB-classic, and Lazarus. Dealing with HTML
"autoflow" and Bootstrap is a royal pain. You sketch a draft GUI that seems a
good fit for the application and users, and then realize you have to jump
through hoops backward on a unicycle while chewing gum blindfolded to get it
right on web browsers. Jetsons WYSIWYG technology yanked from my happy fingers
by an LSD "standard". (I'm assuming "office" applications here, not those
needing smart-phone UI's.)

~~~
meredydd
Can I interest you in a very Delphi-like IDE for building web apps with
nothing but Python?

[https://anvil.works](https://anvil.works) has a WYSIWYG visual designer, with
Python for in-browser code as well as server-side. (We compile it to JS.) It's
even got a built-in DB if you want it (Postgres-backed). Everything in one
language, full front-to-back autocompletion...all the things we missed about
Delphi!

~~~
pkphilip
Nice product but it may have been better to release this as a opensource
product because there will always be a fear that if your company goes bottoms-
up, those companies who used your platform will be left high and dry.

~~~
meredydd
The thing is, making Anvil open source now would virtually guarantee that
outcome.

The market has spent the last few years demonstrating that the sustainable
number of large companies whose main product is open source is...One. (Red
Hat, if you were wondering.) Even _trying_ to become that kind of company
requires a highly speculative VC-fuelled trajectory, which is famous for
turning sustainable 100m-scale companies into 1% unicorns and 99% rubble.

Even Docker, which _utterly transformed_ its target market, is barely making
any revenue ($25m/year on a $1.3bn valuation). All its value is busily being
subsumed into Kubernetes, itself a loss-leader from a company (Google) that
makes all its money from something else.

Anvil-the-company is sustainable, profitable, and growing, and Anvil-the-
product is getting better all the time, because we charge for what we produce.
We would _love_ to be able to give it away and keep doing that - but
basically, we can't.

~~~
pkphilip
What about releasing it like how Node.js was released? that is a full web
platform but one which uses Python instead of Javascript? and with a
repository for packages which people can download and use or even contribute
to?

Ultimately unless there is an active and vibrant ecosystem, there is very
little reason to consider your platform - especially when there are
alternatives like Node.js, Django etc.

Also, for me I will be concerned about how I will integrate Anvil with third-
party libraries needed for things like reporting,
authentication/authorization, E-commerce etc.

Sure, the GUI wizard is not there for Django but what if someone were to
develop such a wizard for Django? or what if someone were to say that it is
best to stick with Django / Vaadin/Ketura/.NET/Go/Rocket.rs even if it takes
another 25% more time to develop in because the ecosystem is much bigger and
we can predict with more confidence that Django /
Vaadin/Ketura/.NET/Go/Rocket.rs is going to be around?

HOWEVER, if your product was available open source, is a lot easier to setup
and use than Django/Ketura/... (you could provide it as a docker image) and
you had a business model where you provide hosting for that solution (similar
to Heroku) and/or paid support, you may end up making more money because a lot
more people would use your platform - lot more than your current model which
very few companies will risk purchasing.

------
analognoise
Hi everyone, I just want to encourage anyone who is on the fence to give
Lazarus/FPC a shot.

It's LGPL, there's no company that can take it away, and it generates native
binaries without the bloat and garbage of Qt or the mental gymnastics of C++.
It's cross-platform native and really wonderful. Give it a try. The community
is awesome.

------
hawski
I was eyeing Lazarus, because it is close to my particular crossplatform
toolkit ideal. I think that UI toolkit should use native widgets and near zero
cost FFI. So any toolkit that draws for itself is not within my ideal. The
most problematic platform for my ideal is Android as the toolkit should run
without NDK. C++ does not cut it. Java would work for Android, but on other
platforms there's FFI.

FreePascal does compile to Java bytecode. It is an experimental feature as far
as know, but it's promising.

There is lots to like about FreePascal, even if I dislike the syntax a bit.
See the Modern Object Pascal Introduction¹ for reference. But memory handling
is something that does not fit my vision. I would hope for something similar
to Swift - automatic reference counting. I like that the compiler is not LLVM
or GCC based. With ARC I can forgive even the manual UUIDs for components.

That's how I saw it from quite a big height so excuse me if I'm misguided.

At the moment Swift looks promising for me without possible transpilation to
Kotlin as seen in one project ². Or D, as it should be easier to fit Java. But
I have my eye on Lazarus. It certainly is much more mature a project.

¹ [https://castle-engine.io/modern_pascal_introduction.html](https://castle-
engine.io/modern_pascal_introduction.html)

²
[https://github.com/angelolloqui/SwiftKotlin](https://github.com/angelolloqui/SwiftKotlin)

~~~
tabtab
Re: _I think that UI toolkit should use native widgets and near zero cost
FFI._

If the target audience is cross-platform, that's hard to pull off. Each OS's
native GUI engine is too different. Emulating a common target behavior is
usually better (until a good general GUI standard comes along). Maybe your
particular need is not cross-platform, but Lazarus's goal is.

~~~
badsectoracula
FWIW LCL (Lazarus' framework) emulates the Windows behavior (there are even
some reimplementations of Windows functions in non-Windows platforms to assist
with that) since the API "descends" from Delphi's VCL which is Windows-only
(and IMO it makes perfect sense that if you need to emulate some OS's behavior
to focus on the most popular one).

The end result is obviously that under Windows things work great, under
X11/Linux with the Qt (i think both 4 and 5 are supported nowadays) and Gtk2
being generally fine as they mostly behave like Windows (especially Qt) and
the worst being Mac support since it is so different from Windows (that and
the Mac backend was originally written using Carbon as that was easier to
interface with FreePascal and still to this day is the most robust backend for
Mac, although in reality both the Carbon and Cocoa backends aren't that
great). And of course the programs despite using native widgets, still look
like Windows programs on a Mac dress ([0] is an old screenshot from my 3D
world editor compiled under Mac, the Windows-isms are clear). You can
obviously try to make things look more Mac-y (and i did try a bit) but you
need to do so much (and in a different branch since some changes can be very
invasive) that IMO isn't worth the effort unless you really want to get that
"Mac look" (but be prepared for a lot of custom code and changes to bypass
LCL).

[0] [https://i.imgur.com/CMaKlZg.png](https://i.imgur.com/CMaKlZg.png)

~~~
tabtab
Making it fit every OS well is indeed a tricky task. Perhaps the _option_ of
using native widgets can be given. Actually, ideally there'd be 3 choices for
developers: 1) A default single uniform style for a given widget(s), 2)
Emulation of OS-specific styles, 3) Native widgets. But providing all 3
without making a mess or bloatware is easier said than done.

~~~
zapzupnz
The tricky thing about cross-platform UI dev, when considering macOS, isn't
just about the widgets and so on. It's things like placement, hierarchies,
etc. Like you said, easier said than done. To demonstrate for those who aren't
sure:

Say Joe Bloggs wants to make an alert window to confirm if the user wants to
save the document, but needs to add custom text and graphics so can't rely on
a default implementation on each platform. So he makes an alert window, looks
great.

Except his design is utterly confusing for macOS users. See, on Windows (and
plenty of Linux environments), the Save and Cancel buttons would be centred on
the window, and Save would be at the left. On macOS, Save and Cancel would be
aligned to the right, and Save would be the right-most button.

Okay, so that's a pretty easy thing to solve with a cross-platform toolkit.
Instead of defining the placement of buttons, you just define the text and
action for the default button, the text and action for the cancel button, and
they'll be put in the right place for every platform. Easy.

But that's such a small example. Try scaling that to the way macOS and
Windows/Linux differ in the use of view hierarchies. Windows-style tab
controls vs NSTabView; Windows/Linux-style tabbed, left-aligned settings
windows vs standard macOS-style centre-aligned preference windows with
NSToolbar at the top; each window/section of an app having its own menu bar as
opposed to macOS having a static menu bar whose items enable/disable depending
on context; MDI vs document-based apps; the fact that macOS apps can still be
running even with no windows open, meaning that certain parts of the UI can
still be opened, and your UI must account for this despite another window that
you would expect to be open (on Windows or Linux) not being in memory at all.

To an engineer, these might seem trivial or not that big a deal. To a user,
that's potential data loss.

------
saganus
Has anyone used a recent Lazarus version to create apps that can connect
easily to an HTTP API?

Some months ago I had a need to create a "quick and dirty" API utility for
internal use and I remembered about Lazarus.

However I couldn't find an HTTP client component that I could use. I just
wanted to do the equivalent of a curl GET/POST call.

I'm not sure if maybe I'm not familiar enough with the wiki structure so I
missed it, but I remember I searched for about an hour before I gave up.

I'd really like to start using a Delphi-like IDE again as I think it is a very
useful and productive tool, especially for ad-hoc stuff.

Any pointers in the right direction would be greatly appreciated!

~~~
DisownedWheat
I made one that consumed the HN API a little while ago (maybe a year?) using
the fphttpclient library bundled with Lazarus. It was pretty simple to use and
all the documentation is on the wiki[1]. It is a lot more low level than I am
used to personally but it was fun nonetheless.

[1][http://wiki.lazarus.freepascal.org/fphttpclient](http://wiki.lazarus.freepascal.org/fphttpclient)

~~~
saganus
Ah!

I do remember I clicked on that briefly but I thought it was too low level
like you said, and I thought there would be something else so I kept looking.

I guess I was wrong, but it's good to know there is something that works.

It also doesn't look that bad anyway, so I might as well give it a try.

Thanks!

------
geff82
I just recently loaded it to make a simple prototype application with it and
it was a smooth and easy process. I still hesitate to fully do a big project
with it in almost 2020 (I was proficient with Delphi 20 years ago). But if you
leave the tech-coolness factor aside, Lazarus is a powerful tool.

------
jchw
Free Pascal has come a long way. When I first messed with it, it lacked
generics even though Delphi supported them. Nowadays I can compile Delphi code
with generics just fine.

I don't think I personally would want to use Delphi in this day and age, but
there's still a lot of useful Delphi/Pascal code out there and it's great to
be able to use it on Linux.

~~~
_red
>I don't think I personally would want to use Delphi in this day and age

I totally understand where you are coming from, however I must say having
everything compiled into a static-binary is a powerful thing that we often
overlook today.

Case-in-point: Around 2007 I was consulting for a manufacturing facility,
basically doing accounting system programming. Their warehouse department
needed a small app that basic did two things (a) Check to see if a invoice was
marked paid so they could ship, and (b) Record the Fedex / UPS tracking number
back into the accounting system.

This was something that was meant to be added into the main accounting
application and installed into the warehouse, but there were the usual
practical issues (the PC that existed in the warehouse was an under-powered
Win XP machine that couldn't actually run the accounting system, so a new
machine needed to be purchased...basically weeks of time were required to
solve it, but we needed a solution ASAP).

On a whim, I whipped up a simple single-dialog box "utility" in Lazarus /
Pascal that would check if accounting had released the invoice and then record
the tracking number. Literally took me maybe 3 hours to download, program,
test, and deploy.

A few months ago I ran into the product owner from that consulting gig so many
years ago....after catching up a bit, asking what had changed...he sheepishly
added "I've still never got around to incorporating your warehouse 'utility'
into the main program yet". I said 'surely its still not that old WinXP box?'
and he said no they had upgraded a few times and just copied the .exe over
each time and it continued to work.

Obviously such a simple 'utility' app is not a great example of why you would
choose to use a language / platform, but it is a testament that what it does
well, it does well. My 3 hours of billable time amortized out over 12 years
now was a really good ROI.

~~~
jchw
Oh yeah, single static binaries are awesome. I think it's one of those things
that helped make Go super successful as well.

If Go had a RAD, well, it'd be very enticing to me. Sadly they have only
touched on UI a little. If you want to write something with Win32 API it's not
too hard and there's plenty of good libraries, but sadly there's no VCL
equivalent. I'd like that.

I guess in that sense Lazarus is still useful. But, I don't find myself
needing a RAD too much. What I would've used a RAD for I find Python + Qt to
be usable enough for.

~~~
jungler
I feel like Go sits in a very similar space to FPC. Go has a bigger runtime
but does a good job of polishing the overall language semantics to be GC-
favorable without being GC-centric. FPC is more mature, though, when you
consider the large number of Delphi libraries, generics support, etc. Both of
them have a much less complex build story than a C++ project since they have
actual module support.

------
int_19h
Something I always wondered about - what's the current state of affairs wrt
Gtk and Qt support? Both are available (different versions, even!), but which
one is preferred, so to speak?

I've noticed that e.g. Debian installs the Gtk version of Lazarus by default,
if you use the virtual package. But it's not clear whether this is a conscious
choice, or it just dates back to when they only had Gtk.

~~~
badsectoracula
Gtk2 is the most mature one, Qt4 follows next (and AFAIK you can build it for
Qt5 too but never tried it myself) and Gtk3 is in very early stages. Gtk1
might still work too, but the only distro i know that ships Gtk1 is Slackware.

AFAIK Gtk2 is the preferred one for shipping since it is still widely
available and you can simply give a binary (Lazarus uses a rather old version
of the Gtk2 API by design so that it is compatible with almost every Gtk2
distro out there, including some that are a few years old). Qt4 and Qt5
require an intermediate shared library that provides a C API and Pascal
bindings for it and in addition Qt4 is removed from some distros.

------
dejv
Lazarus is great, I just hope they create full support for MacOS. Curent state
is more or less broken and not really usable.

~~~
rcarmo
I installed it a year or so back for testing, and I find it especially telling
that you still have to download three independent disk images (compiler, GUI,
extras).

Even sadder is the fact that instead of having a regular Mac app bundle, the
installers spray things all over the filesystem. It’s defensible for the CLI
tools, but hardly native.

Still, I look forward to final release - I just hope it has a better native
look and feel than 1.8.

~~~
edwinyzh
try
[http://wiki.freepascal.org/fpcupdeluxe](http://wiki.freepascal.org/fpcupdeluxe)
to install the complete tool-char with several clicks.

~~~
rcarmo
Doesn’t fix the single bundle issue...

------
ontologiae
Some years ago, I had to write program that extract a foot pressure platform
for an orthopedist, and I had to do it with a closed-source Delphi API. Delphi
was already old at that time and difficult to find. I though about Lazarus and
it works perfectly with the Delphi blob file. It's a very great tool.

------
ablekh
Ah, good ol' Delphi ... Sweet memories ... (A former user of Turbo Pascal,
Delphi and C++ Builder here.) For some desktop applications, using Lazarus is
most likely fine. For a wider adoption, it needs a rich(er) set of VCLs and a
seamlessly integrated way to build modern Web applications. Just my 2c.

------
rosstex
I was really hoping this was Lazarus Form Recovery making a comeback, but this
is still nice!

~~~
kurtschwanda
Another Lazarus comes back from the dead.

------
frbaroni
Just advertising, you can use Lazarus to build WebApps nicely using Brook
Framework:

[https://github.com/silvioprog/brookframework](https://github.com/silvioprog/brookframework)

~~~
TomMarius
No screenshots :-/

~~~
Hasknewbie
...And no doc. On the FreePascal wiki, the Brook page points to a 404 on
GitHub.

------
dang
From 2017:
[https://news.ycombinator.com/item?id=14973706](https://news.ycombinator.com/item?id=14973706)

------
boznz
Thanks guys. Getting better all the time..

------
zerr
Adding C++ support will really make this project much more popular and viable
option.

~~~
badsectoracula
It is viable just fine as it is, i'm not sure what you have in mind.

In any case C++ support for Lazarus is almost impossible due to the work
needed and the projects that will need to cooperate - i go into details here:
[https://news.ycombinator.com/item?id=15893362](https://news.ycombinator.com/item?id=15893362)

~~~
zerr
I meant, unless you have some very specific reasons, Pascal is not the first
language to pick for a new project nowadays.

~~~
Roboprog
I think most people, certainly me, who would be looking for a Pascal compiler
are trying to avoid C++ like the plague.

It’s funny when you read about languages like Rust and Go basically trying to
undo decades of C-induced damage, reinventing (albeit also exceeding) thangs
that Pascal/Modula/Eiffel already had.

~~~
zerr
Yet, it would be good to have an open source alternative to C++Builder. In
other words, besides Pascal, to also have an option for a mainstream [native]
language.

