Inside Lazarus, go to the 'help' menu and select 'help'.
There's quite a lot of documentation!
There's also context sensitive help. Put the text cursor over a type name, like 'TForm' in the default code that's there when you start Lazarus. Press F1 to see the documentation for that type.
I just checked. Help shows documentation on FreePascal and what the different options are for Lazarus as an IDE, but I don't see any more documentation on how the GUI system works, which is supposed to be what makes this system so special in the first place.
That's what the community has been missing all these years. Writing documentations are boring activity, so contributors tend to give only demos, examples and sometimes unit tests. How the system works is actually documented in a simplified diagram here: http://wiki.lazarus.freepascal.org/Overview_of_Free_Pascal_a...
>but I don't see any more documentation on how the GUI system works
What exactly do you mean by that? At a shallow level, it should be fairly obvious - it would be like any other event-driven GUI development environment - create and place widgets on a window, set their properties, write routines that respond to (keyboard and mouse) events, build and start the app, the event loop takes over, your routines get triggered by events and do stuff, etc. Are you looking for more depth, maybe on the internals? Asking out of interest in the question and answer myself.
But I'm not sure you need a lot of that depth to start using it. Just looking at some basic code examples, and using the online help as a nearby comment said, should give enough information on Free Pascal and Lazarus widgets, their inheritance hierarchy, their properties and events to which you can respond, etc. I know this because I have followed such an approach in other GUI environments, e.g. wxPython, after learning the basics of event-driven GUI programming, from my first such GUI env, and managed to get some work done.
I mean docs that assume I've never looked at any other GUI system and don't know what an event even is, much less how to register one.
What if I'm a first-time programmer or have only ever programmed in MIT Scratch? What if I'm a PHP programmer? Do the Lazarus components work like Swing? Do you register event handling the same way?
I want tons of examples for every component--examples that start simple and work up in terms of complexity with comprehensive explanation along the way and I want it all linked under "Documentation" off the front page.
Now that's a lot. I recognize that. But I don't care. There are whole books available for Swing, JavaFX, Windows Forms, and WPF, not to mention Web Design. That's the standard today. Book scale documentation...
I'll say it again: I'd like to use Lazarus. I spent the morning programming a desktop application that could have been done in Lazarus, but it wasn't because I'd rather build programs than decipher an undocumented system, and I suspect I'm not alone.
>I mean docs that assume I've never looked at any other GUI system and don't know what an event even is, much less how to register one.
Got it now. From your initial comment in the thread (you used words like 'Threw a few gui components onto the blank form and hit compile.', I thought that you were a programmer with knowledge of at least the basic concepts and some practical experience of GUI development in at least some other GUI dev env. And my answer was based on that assumption. I now see that, whether you are an experienced programmer or not, you are looking for docs that start from the beginner level and are very comprehensive.
I have to say I sympathize with that viewpoint. It would be great if all software products were documented as well as that. However, going by real-life experience, I am not sure that many are.
>What if I'm a first-time programmer or have only ever programmed in MIT Scratch? What if I'm a PHP programmer? Do the Lazarus components work like Swing? Do you register event handling the same way?
Got it. But see my answer to your next point below.
>I want tons of examples for every component--examples that start simple and work up in terms of complexity with comprehensive explanation along the way and I want it all linked under "Documentation" off the front page.
Now that's a lot. I recognize that. But I don't care. There are whole books available for Swing, JavaFX, Windows Forms, and WPF, not to mention Web Design. That's the standard today. Book scale documentation...
Yes, there are books - and there were, years ago too, for earlier products of those times. (In fact, see my other comment in this thread, in reply to teraflop's comment about door-stoppers - https://news.ycombinator.com/item?id=12045536 :) Again, though, going by my own experience, there are not many software products that have that level of documentation in the product or online help. (Microsoft MSDN and Borland earlier come to mind as some that did.) I am not saying this is a good thing. As you say, I've also found, that one often has to resort to books on the subject of that software (if they are available - since they are not available for some less popular subjects). I've learned many different software technologies that way - via in-depth books on the subject, that I bought, or borrowed from company libraries.
>I'll say it again: I'd like to use Lazarus. I spent the morning programming a desktop application that could have been done in Lazarus, but it wasn't because I'd rather build programs than decipher an undocumented system, and I suspect I'm not alone.
Out of interest, what technology did you program it in?
No, you're definitely not alone.
However, in the kind of doc scenario that you describe (e.g. for Lazarus), there are still ways, though somewhat less efficient, of getting the learning and work done. Like this: read what docs are available (thoroughly, over time), read the sample programs, run them (correlating the code with the docs available for the code in the sample), step through them in a debugger to see what happens to program state (i.e. variables) internally as the program runs, read a lot of posts on the mailing list for the software, ask relevant questions on the mailing list as needed, to help you learn, share your own learnings on the same list, google for other online info on the topic, such as blogs, free online tutorials, etc. etc. A lot of people, me included, have learned those techniques over time and use them to overcome somewhat the disadvantages of less than perfect documentation. I realize that you may know all this already, but thought of posting it for the benefit of some readers who might not. As a trainer, I often find that beginners are not aware of many of these learning techniques - which are pretty effective, over some time. The main thing many of them know is how to use Google and StackOverflow, and if they don't find the answer there (and quickly), some of them give up overly soon (and thereby not meet their goal).
You're right...it's still doable. I could if I wanted, but the cost/benefit analysis of my time vs the payoff of using Lazarus just doesn't make it worth the time.
Interestingly, here's a new link on HackerNews for the new haskell website: https://haskell-lang.org/
>I could if I wanted, but the cost/benefit analysis of my time vs the payoff of using Lazarus just doesn't make it worth the time.
I guess that partly depends on how much work you plan to do with it, the expected benefits of that work, a few other factors, and also partly it is "each to their own".
There's also context sensitive help. Put the text cursor over a type name, like 'TForm' in the default code that's there when you start Lazarus. Press F1 to see the documentation for that type.