I wish a big bundle

General discussion for topics related to the FreeBASIC project or its community.
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: I wish a big bundle

Post by marcov »

caseih wrote:
marcov wrote:A flattened procedural api already exists (search for QTpas). Usually that is fairly stable, needing only major work with major versions.

The missing bit however is an abstraction between widgetsets. So something that you can use from an application that uses winapi on Windows (thus having no dependencies, and easy deployment), and QT/GTK (preferably QT) on *nix. (and maybe Cocoa for Mac if you still care for that, otherwise also QT)

But I think it is better to keep that abstraction layer native FB, just like LCL is native FPC. While LCL is quite complex, and hard to emulate, it would be nice to have at least something in FB.
I was under the impression that Qtpas interfaced with just enough of Qt to power LCL widgets. It wasn't a full binding when last I looked.
True, but as I said my target would be a native FB class lib that would abstract over widgetsets, like LCL does. To start, qtpas would be enough, and in time, when necessary, calls could be added

Yes, FB misses some dialect options, but so did FPC in the early days, and we came pretty far.
A full OOP binding for GTK in FB would be great. GTKmm is an amazing binding for C++. It leverages the full power of C++ (STL types, etc) while wrapping gobject in a nice C++-idiomatic way with no moc required. I prefer it to Qt in this regard. Unfortunately FB lacks features that C++ has that make GTKmm nice to work with, including templates for doing type-safe signals and callbacks, and reference-counting smart pointers.
Why would you need generics/templates for callbacks? And don't try to make the first tries to fancy.

But maybe that's more the IDE/designer centric approach of Delphi/Lazarus. You rarely manually set/define a callback anyway, just double click the handler spot.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: I wish a big bundle

Post by caseih »

marcov wrote:Why would you need generics/templates for callbacks? And don't try to make the first tries to fancy.
Templates simply make for completely type-safe signals and callbacks. Many people don't realize that Qt's signalling mechanism is not type safe (not completely checked at compile time) and actually relies on run-time string comparisons which can sometimes lead to really weird problems (can't remember what those problems are right now, but I've encountered them several times and each time, I think, "oh yeah! Forgot about that"). See the section "String based verse Templates" at http://libsigc.sourceforge.net/benchmark.shtml.

Qt's way of doing things was really the only possibly way back then when C++ had no templates. And it would work fine in FB of course. As long as we realize there can be subtle issues. I just like how flexible and powerful the C++ implementation is in GTKmm. If such a thing were possible in FB, I'd highly recommend that course. And Libsigc++ can be used outside of GTK or Glib. I've used it to add a flexible signal and callback mechanism to a stand-alone C++ app in the past.

Templates are also required to create type-safe smart pointers (or smart references) that can automatically destroy an object that was allocated on the heap when it goes out of scope. GTKmm (well, Glibmm) uses a reference-counting smart pointer.
marcov wrote:But maybe that's more the IDE/designer centric approach of Delphi/Lazarus. You rarely manually set/define a callback anyway, just double click the handler spot.
Understood, but I've always found in the past that at some point you may need to do a manual callback. For example there are many non-GUI events that you may want to follow, sometimes in response to a GUI event. For example, a button that when clicked starts a timer. The clicked callback would create a one-shot timer in the GUI framework and connect another callback to it. Or maybe you might want to do some asynchronous I/O in response to a GUI event. Again you'd have to set that up in the callback, and then configure another callback to handle the final result. At least for me this sort of things happens all the time. So I like the ability to do both. Hook up things in the GUI designer (QtDesigner or Glade at present), and then do what I need to in code and have the flexibility to use either.

EDIT: I read that Qt5 has introduced a new method for specifying signals and slots that relies on C++ templates (under the hood) so it's type safe at compile time. I've not had experience with Qt5 as of yet.
BeginnerST
Posts: 26
Joined: Jun 26, 2016 21:59
Location: Italy

Re: I wish a big bundle

Post by BeginnerST »

Hi, all
I do not even know much, being a programmer for hobby, and I wrote programs especially in TP7 and VB6, it would be nice to be possible to reuse the work done by the Lazarus team for FBC without rewriting everything from scratch. I would be happy to replace VB6 RAD IDE with new FBC RAD IDE.
I think it is a desire shared by many users FBC.
Lothar Schirm
Posts: 436
Joined: Sep 28, 2013 15:08
Location: Germany

Re: I wish a big bundle

Post by Lothar Schirm »

BeginnerST wrote:I would be happy to replace VB6 RAD IDE with new FBC RAD IDE.
What do you think about FireFly?
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: I wish a big bundle

Post by marcov »

caseih wrote:
marcov wrote:Why would you need generics/templates for callbacks? And don't try to make the first tries to fancy.
Templates simply make for completely type-safe signals and callbacks.
Yes. Specially if your signals MUST be multicast, most of your event info must be in parameters, and then you want something like that, so that the multicast code can be instantiated as a template.

LCL avoids that trap (since Delphi didn't have generics in the old days too) by not doing multicast GUI events. Which I actually didn't mind that much to be honest. Parameters to most GUI events are simply an instance reference to the sender of the event.

There are minor inconveniences, but in general it is quite workable. Multicast isn't needed that much.
Qt's way of doing things was really the only possibly way back then when C++ had no templates. And it would work fine in FB of course. As long as we realize there can be subtle issues. I just like how flexible and powerful the C++ implementation is in GTKmm. If such a thing were possible in FB, I'd highly recommend that course. And Libsigc++ can be used outside of GTK or Glib. I've used it to add a flexible signal and callback mechanism to a stand-alone C++ app in the past.
Personally I would rather avoid needing that, then implement half of C++ in FB just to make that possible.
Templates are also required to create type-safe smart pointers (or smart references) that can automatically destroy an object that was allocated on the heap when it goes out of scope.
Afaik only in combination with RAII. Templates alone are not enough, you must have something that forces prologue and epilogue code to run, in C++'s case that is RAII, in Delphi's case automated types (like interfaces)
marcov wrote:But maybe that's more the IDE/designer centric approach of Delphi/Lazarus. You rarely manually set/define a callback anyway, just double click the handler spot.
Understood, but I've always found in the past that at some point you may need to do a manual callback.
The callbacks in Delphi are still code. You generally just don't type them by hand, but select the event of the control in the designer.

They are simple method pointers (one ptr proc address, one ptr instance) though, with a signature with a single untyped class reference parameter. Much more doable.
For example there are many non-GUI events that you may want to follow, sometimes in response to a GUI event. For example, a button that when clicked starts a timer. The clicked callback would create a one-shot timer in the GUI framework and connect another callback to it. Or maybe you might want to do some asynchronous I/O in response to a GUI event. Again you'd have to set that up in the callback, and then configure another callback to handle the final result. At least for me this sort of things happens all the time. So I like the ability to do both. Hook up things in the GUI designer (QtDesigner or Glade at present), and then do what I need to in code and have the flexibility to use either.
There are people that use a lot of non-visual components just to hook them up. Complete http servers etc. With the exception of simple timers in simpler programs, I usually don't, but instantiate them in code.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: I wish a big bundle

Post by caseih »

Good points.

A bit off-topic, but in Lazarus with the LCL can you do more dynamic form layouts where things adjust size and spacing as a window changes size? I know in win32 this can be done with special anchor, but I never did learn how to use them. GTK and Qt's layout managing systems were so flexible and easy to use that I never looked back.
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: I wish a big bundle

Post by marcov »

caseih wrote:
A bit off-topic, but in Lazarus with the LCL can you do more dynamic form layouts where things adjust size and spacing as a window changes size? I know in win32 this can be done with special anchor, but I never did learn how to use them. GTK and Qt's layout managing systems were so flexible and easy to use that I never looked back.
Yes, you can, in several ways. It is not programmable though (as in that you can control the size other than saying rubber length or fixed, and side it "sticks" too). There are on resize events though, so you can change the content/layout within a control depending on the size, basically these are just handlers where you can insert extra code for the relevant windows message. (and e.g. decide not to call the default LCL routine)

It probably closely matches win32, as with most things VCL/LCL.

P.s. now that I have thought one day more about it, another way of doing multicast would use a smart pointer to a record that contains the parameters for multicast. The advantage to that is that with a bit of compiler magic, all events can use the same dispatch routine, and it is still typesafe

So at the caller side all arguments are boxed to a record, and the called event gets the (typed) pointer to the record. The multicast dispatch code just calls all functions in the list with a single pointer argument. Short and universal. The list is a generic based on a ref type, so can also share a lot of code (like in C#). Requires some magic for the boxing and maybe to handle the dispatch, but a lot simpler and leaner.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: I wish a big bundle

Post by caseih »

It's quite common when binding signals to callbacks in GTK or Qt to pass additional data along to the callback (but not necessarily to all the callbacks for that signal). This is where things get a bit more tricky in the type-safe department.
Post Reply