Programming with Laz/FP lazarus / 21-General ---------------------------------------------------------------------- Ten_Mile_Hike · 2024-10-16 17:27 I'm curious how this community uses Laz/FP. Specifically; what is the percentage of applications written by us nowadays with Laz/FP are: 1. Non-GUI (almost exclusively) 2. GUI (almost exclusively) 3. Both (regularly) Speaking for myself, I have written exclusively only Windows apps for at least a decade. ***I'm NOT arguing*** the utility, efficiency, or necessity of non-GUI apps- I'm only wondering about the day to day practice of the members of this community. Thoughts??? ---------------------------------------------------------------------- jamie · 2024-10-16 18:42 I do 75% GUI / Where I come from, I run many small non-GUI apps and use the GUI to host them. These little apps get in volved in reading and writing data between hardware devices and I use pipe IO streams threaded to control or view their data in the GUI stuff.  It works out better in my case because I can quickly bring down a device via killing a thread, do what I need with mini app and restart that one device without disrupting the whole GUI process.  In the old days, windows was a little cranking with threaded IO, these days it seems to work much better. ---------------------------------------------------------------------- 440bx · 2024-10-16 19:49 Quote from: Ten_Mile_Hike on October 16, 2024, 07:27:23 pmThoughts??? It depends on the program's objective. In general, highly interactive programs are best implemented with a GUI interface.  Programs that simply present information to its user are, more often than not, best implemented as non-GUI (CLI) ---------------------------------------------------------------------- marcov · 2024-10-16 19:49 Quote from: Ten_Mile_Hike on October 16, 2024, 07:27:23 pmI'm curious how this community uses Laz/FP. Specifically; what is the percentage of applications written by us nowadays with Laz/FP are: 1. Non-GUI (almost exclusively) 2. GUI (almost exclusively) 3. Both (regularly) Main apps (delivered to customers) are gui apps in Delphi, embedded software in C, internal company apps and utils in FPC (some exclusively compilable FPC/Lazarus but often compiling shared units that are Delphi- FPC/Lazarus ) . Percentage for applications that are large than a 10000 SLOC will be 50:50 for the Lazarus apps.  Delphi apps are nearly all GUI and vastly larger. (the non GUI ones have been converted to FPC/Lazarus generally) ---------------------------------------------------------------------- Warfley · 2024-10-16 19:50 Generally I try to avoid writing GUI apps as much as possible, because creating a good GUI is hard, and requires a lot of tedious work that you just do not have with console applications. A straight control flow just makes it easier to focus on the algorithmic things the program should do rather than having to deal with asynchronous events, sanatizing free form user input and making everything look nice. If I need a GUI it's usually for some custom tools I only use for myself, so I spend as little time as possible on making a nice GUI. That said, I don't program for a living, so I can decide what I want to build and most things I build are either experimentation or creating libraries, so fully fledged applications is something I rarely do by now ---------------------------------------------------------------------- Curt Carpenter · 2024-10-16 22:30 My non-GUI use of FPC/Lazarus is maybe once or twice a year just to remember how.  Good displays + point and click are just too helpful and convenient for the stuff I do on my PC with all that operating system at hand.   I fire up Turbo Pascal every few years just for old time's sake. ---------------------------------------------------------------------- Bogen85 · 2024-10-17 01:46 Quote from: Ten_Mile_Hike on October 16, 2024, 07:27:23 pmI'm curious how this community uses Laz/FP. Specifically; what is the percentage of applications written by us nowadays with Laz/FP are: 1. Non-GUI (almost exclusively) 2. GUI (almost exclusively) 3. Both (regularly) 1. Non-GUI (almost exclusively) When I do use it for GUI app development, it is with libqt6pas directly (bypassing LCL) And I don't use the Lazarus GUI for app development. It does the fit the way I do development. ---------------------------------------------------------------------- Thaddy · 2024-10-17 04:03 3. But I do not consider GUI work in Lazarus or Delphi as programming, more like designing. You all know my examples are usually non-GUI, but could be used with a GUI if required: the logic should be user interface agnostic. Writing code by starting with a user interface can easily clutter up your code. ---------------------------------------------------------------------- DragoRosso · 2024-10-17 07:26 3) ... But I do write a lot of "agnostic" code, which can be compared to "making non-GUI applications". Time spent writing GUI-independent code 75%, time spent on GUI functions and interface 25%. The tools I use the most are Delphi and C++. ---------------------------------------------------------------------- 440bx · 2024-10-17 07:37 I'm going to throw a thought in here... I believe all programs at or above medium complexity should start their "life" as a console program because this allows the programmer to focus on getting the algorithm(s) implemented correctly and tested easily. Once the algorithms are known to be correct then they can be used in a GUI. ---------------------------------------------------------------------- MarkMLl · 2024-10-17 08:31 Depends on the context. If it's something interactive for internal use, then the lack of a realistic design tool for FreeVision etc. more or less mandates Lazarus+LCL. I've tried using DialEdit in the past, and while the result was functional there was no inherent support for handling unix-style WINCH ("window size changed") signals and such things have never (AFAIK) been supported on Windows (or OS/2, FWIW). If it's something where I want to get the message out in public, i.e. "this is how you support a particular type of hardware device" then I try to provide /both/ GUI and console-style with proper helptext etc. e.g. https://github.com/MarkMLl/Contec_cms50dplus I also try to be conservative in my language dialect, since I feel that it is important to recognise that a lot of people have not touched Pascal since the Turbo Pascal days, and there is more benefit in demonstrating that it is still useful than in waving constructs around that might not be immediately recognisable, and that particularly applies if they are poorly documented. For a similar reason I also provide a makefile. MarkMLl ---------------------------------------------------------------------- Joanna · 2024-10-17 11:06 Quote from: 440bx on October 17, 2024, 09:37:12 amI'm going to throw a thought in here... I believe all programs at or above medium complexity should start their "life" as a console program because this allows the programmer to focus on getting the algorithm(s) implemented correctly and tested easily. Once the algorithms are known to be correct then they can be used in a GUI. Your the approach is the opposite of mine, I think of the perspective of users using the gui interface and then how to make all the code happen. For purpose of survey.. all gui applications except non interactive console programs for generating data. ---------------------------------------------------------------------- Bogen85 · 2024-10-17 11:29 Quote from: Joanna from IRC on October 17, 2024, 01:06:51 pmQuote from: 440bx on October 17, 2024, 09:37:12 amI'm going to throw a thought in here... I believe all programs at or above medium complexity should start their "life" as a console program because this allows the programmer to focus on getting the algorithm(s) implemented correctly and tested easily. Once the algorithms are known to be correct then they can be used in a GUI. Your the approach is the opposite of mine, I think of the perspective of users using the gui interface and then how to make all the code happen. Joanna from IRC, your approach is top down, and while that can have some merit in the initial design stages. When used in the actual building of solid applications, it has flaws when you are building up the code base that actual gets the job done. With that style, when all the code that actually does something useful is that put in place here and there where needed, it typically lacks any sort of decent organization, and is hard to reuse anywhere else, and instead you just end up with a continual spreading of subtle bugs everywhere via the copy/paste/modify coding style. Core functionality should also be separate from the UI (What interfaces with humans) and the communications interfaces (what interfaces with other programs or devices). When all that is always done in a GUI (user and machine interfaces with the core functionality always hung off that and not built and made useful separately), that core functionality of every code layer below the UI inevitably becomes a buggy hard to maintain mess of loosely associated code fragments. It matters more to users that the applications does what it supposed to do well, than to just look pretty to the one designing the UI for the end users. Focusing on end users means delivering applications that solve their problems, and solves those problems well. Top down everywhere is not a design methodology I've seen achieve that. It can be useful for mock ups and demos, but never for sustainable applications. ---------------------------------------------------------------------- Joanna · 2024-10-17 11:47 Maybe the top down part is true, I use a lot of inheritance. I definitely don’t copy paste or have duplicate code if I can avoid it. I’d say I’ve spent a lot of time trying to reverse engineer gui interfaces and I’ve discovered that they are quite different than how they look with many different controls being combined together. I’ve learned a lot since I first started so who knows what I might do in future. I’m currently replacing all my frames with custom controls.. ---------------------------------------------------------------------- Warfley · 2024-10-17 12:10 Quote from: Bogen85 on October 17, 2024, 01:29:02 pmWith that style, when all the code that actually does something useful is that put in place here and there where needed, it typically lacks any sort of decent organization, and is hard to reuse anywhere else, and instead you just end up with a continual spreading of subtle bugs everywhere via the copy/paste/modify coding style. I think it's less about bugs but generally testing GUI applications is a complete nightmare. Because if you rely on certain GUI flow you cannot simply test without having to load up the whole GUI and performing all the steps. So I find it much easier to build all the small functions first, and test them in individual programs. I personally have one small command line program which just performs the test. Once I'm done with a feature, i take that command line test program, make a copy of it and start for the next feature with a blank slate. This makes writing tests very easy as they develop naturally. Only when the features are finished I incorporate them into the GUI. It also makes the portability much easier. For example a few years ago I needed a command line buildsystem for my lazarus applications. I wanted to use the OPM to download and manage the dependencies. But the OPM was completely build from the ground up to be a Lazarus package and is so intertwined with lazarus internal functionalities, that turning this package into a command line tool was basically impossible, and instead I just spend a few days to write down a new custom script which would do that instead. PS: Thats not the only problem with the OPM code, it is not very good to begin with, e.g. it relies on the order of elements in a JSON object, wich is undefined, and just happens to be in order in the Lazarus implementation because the Lazarus JSON implementation is very inefficient using a linear search list for mapping objects, so even if it wasn't so deeply embedded into lazarus I would probably have rewritten it anyway ---------------------------------------------------------------------- Bogen85 · 2024-10-17 22:59 Quote from: Warfley on October 17, 2024, 02:10:25 pmQuote from: Bogen85 on October 17, 2024, 01:29:02 pmWith that style, when all the code that actually does something useful is that put in place here and there where needed, it typically lacks any sort of decent organization, and is hard to reuse anywhere else, and instead you just end up with a continual spreading of subtle bugs everywhere via the copy/paste/modify coding style. I think it's less about bugs but generally testing GUI applications is a complete nightmare. Yes, agreed. And I should have clarified some things, because I described a "GUI" app development in that way does not make sense. If I'm not using a RAD tool to write a GUI then the UI components are just another set of units edited in a text editor like every other unit, and I can think in terms a an application that does a certain thing, or set of things, and it happens to present certain things to the user in a certain way. In an application built like that I can clearly distinguish between the functionality of the program and the interconnected interfaces as separate units. So a program developed that way I can test and develop independently of focusing on the UI (or other external facing interfaces. However, with RAD tool I lose focus on the application functionality due to the way most are RAD tools work and my focus tends to be from the UI down. As such it is hard (for me in how I think) to develop the application units that have the core functionality independently of their association with the UI. While I've used tools like C++ Builder and Delphi in the past, I had a hard time focusing on complex application development and everything I did with them ended up being single focus with very little reusable components, and it was difficult for me to reuse components because they were always to tied to the UI they were originally developed for. When I have tried Lazarus, it felt the same way, so I do not use the Lazarus IDE to for any type of application development, GUI or otherwise. Which is why I focus on CLI, server, and client type applications, that generally don't have a GUI (or even interactive TUI) component to them. If I need to have GUI (or TUI) I for an existing app, I add one (in code programmatically, or through an interface description file written by hand). If I need to have a app that is simple with a singular focus only makes sense with a GUI or TUI, then I do that, but not with RAD tool, because that is contrary to the way I develop applications. So me using a RAD tool is not good, because it is too hard for me to write reusable testable components developed in isolation. So I don't use RAD tools, because I want my code to be testable and maintainable, and reusable when necessary. I'm not saying these types of can't be used productively to write testable, maintainable, and reusable code. I'm just saying I never developed those skills because the barriers to entry for me were too high, and I did not have compelling reason to get over those barriers. So my personal objection to GUI development as the primary go to, is largely related to RAD style GUI development. ---------------------------------------------------------------------- Joanna · 2024-10-17 23:40 I Create most controls at runtime because it’s easier to modify things later. I do strongly believe that Lazarus ide is a good way to introduce beginners to gui development because they can understand how it works easily by putting some controls on form and seeing what they do. The gui also does helpful things like creating events in the object inspector so how the parameters needed for certain types of events can be learned. Once there is familiarity with different types of controls you can move on to creating custom controls. Which only require a .pas file. It doesn’t really matter how different people do things inside of their programs as long as the programs work well. My biggest problem is not knowing how to do things right to begin with due to lack of experience. Or not being ready to do things correctly because I need to work my way towards higher skill levels with practice. I was not ready to program what I do now several years ago because I didn’t understand it. Yes gui programming can get complicated.. ---------------------------------------------------------------------- cpicanco · 2024-10-26 20:05 I am using Lazarus+Free Pascal for everything (mostly gui and data gathering from peripherals). I prefer scripting with python for pre- processing and plots, or R for statistics (Although I heard about TChart, I have no clue how to do plots with pascal). ---------------------------------------------------------------------- n7800 · 2024-10-27 00:04 95% GUI / 5% CLI. I usually write GUI even for "background programs", since they can be hidden in the tray, instead of keeping them in an open terminal (or writing a service). Another reasons for writing GUI instead of CLI for me is that parsing parameters (even when using ready-made classes/methods) is more complicated than just adding a button/field/switch on form. This is especially important in "one-off" programs that are launched only to test something. Now I came up with the idea of ​​writing some utilities that simply improve the output and functionality of some program (when it is too complicated for a script). For example, I wrote a utility "gb.exe", which replaces the "git branch" command. It calls "git" itself, but displays a list of branches with information about them (draft/ready, published/merged, description) and effectively uses colors for this. By default, it omits upstream branches, and sorts them by update date... In general, except for git, I almost never use anything in the terminal )) ---------------------------------------------------------------------- Curt Carpenter · 2024-10-27 00:56 Quote from: cpicanco on October 26, 2024, 10:05:47 pmI am using Lazarus+Free Pascal for everything (mostly gui and data gathering from peripherals). I prefer scripting with python for pre-processing and plots, or R for statistics (Although I heard about TChart, I have no clue how to do plots with pascal). Like so many things I think, TChart takes an investment -- but once you've made that you'll never look back.