4 ms·

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

by hawski 8y ago

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 8y ago
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 8y ago
  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 8y ago
    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 8y ago
      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.
  - int_19h 8y ago
    Does it emulate Windows behavior, or does it simply wrap it? My understanding is that LCL wraps Win32 API directly on Windows, same as VCL did.
mamcx 8y ago
> But memory handling is something that does not fit my vision I do Delphi a lot of years (still remain as moderator in http://www.clubdelphi.com http://www.clubdelphi.com) and can say that is easy to just. Is much easier than use obj-c and the idioms around the language make things simply. Is the only language I have tried with manual memory management that I found simply to follow P.D: Help a lot strings are refcounted and you can refcount some stuff if desired.
badsectoracula 8y ago
> But memory handling is something that does not fit my vision. Note that in practice memory management is almost never an issue with FreePascal since a lot of things are based on TComponent that provides an ownership-based model and dynamic arrays (at the language level) handle a lot of cases you'd need to worry yourself. Of course if you create raw objects you also need to release them, but this is something you generally do in constructors and destructors. > I would hope for something similar to Swift - automatic reference counting. I'm not sure how i feel about this personally since i think it adds a lot of hidden baggage to the language, but you can use reference counting using "COM" interfaces (the name is just a historic artifact, they work in non-Windows environments too) in current FPC. There is also work to allow any custom type become reference counted by defining some special operators (essentially functions) that the compiler will automatically call to incref/decref/etc (which can also be used to implement RAII). > With ARC I can forgive even the manual UUIDs for components. Is the manual UUIDs you are talking about in Swift? AFAIK you do not need to define any UUID in FreePascal (except for the COM interfaces mentioned above).

by hawski 8y ago

tabtab 8y ago

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 8y ago
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 8y ago
  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 8y ago
    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.
- int_19h 8y ago
  Does it emulate Windows behavior, or does it simply wrap it? My understanding is that LCL wraps Win32 API directly on Windows, same as VCL did.

mamcx 8y ago

> But memory handling is something that does not fit my vision I do Delphi a lot of years (still remain as moderator in http://www.clubdelphi.com http://www.clubdelphi.com) and can say that is easy to just. Is much easier than use obj-c and the idioms around the language make things simply. Is the only language I have tried with manual memory management that I found simply to follow P.D: Help a lot strings are refcounted and you can refcount some stuff if desired.

badsectoracula 8y ago

> But memory handling is something that does not fit my vision. Note that in practice memory management is almost never an issue with FreePascal since a lot of things are based on TComponent that provides an ownership-based model and dynamic arrays (at the language level) handle a lot of cases you'd need to worry yourself. Of course if you create raw objects you also need to release them, but this is something you generally do in constructors and destructors. > I would hope for something similar to Swift - automatic reference counting. I'm not sure how i feel about this personally since i think it adds a lot of hidden baggage to the language, but you can use reference counting using "COM" interfaces (the name is just a historic artifact, they work in non-Windows environments too) in current FPC. There is also work to allow any custom type become reference counted by defining some special operators (essentially functions) that the compiler will automatically call to incref/decref/etc (which can also be used to implement RAII). > With ARC I can forgive even the manual UUIDs for components. Is the manual UUIDs you are talking about in Swift? AFAIK you do not need to define any UUID in FreePascal (except for the COM interfaces mentioned above).