Lazarus 1.9 trunk Qt4 and Qt5 interface (screenshots)

BTW: ( @PulkoMandy ) Yesterday I created new patches for Termios in FPC and uploaded them to the bugreport. I am assuming it’s OK for now, though (as stated as comment in one of the files) I see a discrepancy between two implementations of a routine (leaving old one there for now).

I tested it, compiling our company’s app on Windows 7 with FPC 3.2.2 and LazarusIDE 2.0.12, for both 32 and 64bit. The linker these days works a big lot better than on the older FPC. Also I can compile 32bit, which (I think I remember) did not work before.

I installed the apps on both a 32bit and 64bit Haiku (around beta3). On 64bit, serial ports work OK, still apart from the flush command: would be nice if we can figure that out someday; I have it disabled still in Synaser therefore).

On 32bit, the serial ports just don’t work. With Haiku’s serialconnect app it’s OK, but not with lazarus. Though I -did- get correct reception into Haiku on one (random) test occasion (tx remained a problem).

On both systems usb_serial is complaining about not being able to set some interrupt or so. Don’t know how that was before, I did not check the syslog back then.

About the patches, since noone responded to my request for help, I decided to just go forward as good as I can. :slight_smile:

Oh EDIT: the flush: at least I am wondering if it’s good practice to abort the flush if there’s no ‘other side’ available. One could have also decided to just abort trying to flush the ‘other side;’ but -still- go ahead and clear ‘this’ side, when IOFLUSH is requested that is. On OFLUSH only, an error is OK of course…

EDIT2: Oh yes, I saw that message indeed. Unfortunately getting the recipe to compile is already not something I can pull off apparantly, so I am not spending time on this atm. (Still I would love it if gdb would work… :wink: )

3 Likes

Hi, if anyone is developing with Lazarus and encounters a message upon ending a program:
‘QObject::~QObject: Timers cannot be stopped from another thread’

Chances are you are using a TBitBtn somewhere. This causes this message. It is linked to the ‘Kind’ property: Only if you set Kind to BKCustom will this message disappear.

This problem does not exist on Linux or Windows while using Qt, so it must be a Haiku specific error.
If anyone knows howto fix it, that would be cool :slight_smile:

EDIT: I would expect it to be in our QT5 library somewhere… (?)

2 Likes

I think the problem is in my QPA code - qthaikuplugins/platforms/qhaikuplatform/haiku at master · threedeyes/qthaikuplugins · GitHub.
Apparently in the BApplication wrapper (or not).

3 Likes

http://befpc.sourceforge.net/docs/language.html
https://sourceforge.net/p/befpc/mailman/befpc-discussion/
https://sourceforge.net/p/befpc/wiki/BePascal/

In some entry of this site they show how to make a wrapper to c from freepascal.

Part of the implemented code works with latest commits for Haiku that modify path to writable space in Haiku that before was writable under BeOS but not in Haiku, i dont remember exactly where.
With recent FreePascal compiler (and with Haiku 32 bits) because when the last time they compile it was with an old versión.
This way they were able to show forms and components calling Haiku API.
In Lazarus LCL is independent from supported widgets as qt, win32,…so it can use new aditions and compile for everyone with minimal changes.
Sorry for my english.

Found the solution for ‘Open with’ using the proposal from @phw and the example from @roiredxsoto work on CudaText.

When using QT as backend you can add attributes so that it behaves as normal commandline parameters:

When setting the QT:QPA_FLAGS attribute to Q_REF_TO_ARGV Qt will attempt to convert the initial RefsReceived message into command line arguments.

The only thing that is needed is adding the resource to application using xres

1 Like

Good day @zittergie ,

This links to your question here CudaText 64bit: Text/Code Editor: RC. Please report issues - #42 by zittergie

Apologies for taking so long in replying. Glad you found the way. To sum up, there are a series of steps that need to be done [real devs, correct me if I got this wrong]:
[never touched pascal code, all this is done outside of the executable]

1- Create the RDEF file and [using the one I created for CudaText]:

resource app_flags B_SINGLE_LAUNCH;
resource("QT:QPA_FLAGS") "Q_REF_TO_ARGV|Q_REF_TO_FORK";

This is where the QT flags are set in the RDEF according to explanations by @phw and @3dEyes. [I used NotepadQQ recipe from Haikuports as a reference]

then I set inside the RDEF file:

resource file_types message {
"types" = "text/plain",
"types" = "text/x-source-code",
"types" = "text",
"types" = "text/x-makefile",
"types" = "text/x-rez",
"types" = "text/x-jamfile",
"types" = "application/xhtml+xml"
};

AFAIK, this is important as tells the app the kind of files that it’s going to deal with.

2- compile the RDEF into RSRC and add it to the executable with XRES [xres -o appname appname.rsrc]

3- Then need to register the app in the MIME database [mimeset -f appname] as pointed out by @Lrrr

With these, if I understood it correctly, the Qt app will work fine on Haiku, even with the Open With. If not, devs please correct me so I can improve the process.

I should have added some comments to the RDEF file, in fact I was going to. The plan was to complete the CudaText port before August 1st. Wasn’t possible, and now my Haiku time has dropped dramatically from few to barely none. So I didn’t update the RDEF and hadn’t have much time to improve the CudaText port.

I wrote down these notes, and others, so when I can get back on track I don’t need to start all over again.

Nonetheless, if you have any question [not on Pascal, haven’t touched it since 1990 :joy:] and I can help, I’ll be glad to. You may have to wait some time for a reply though :wink:

Regards,
RR

2 Likes

Would it be an idea and would you be willing to check on that if I send you the compiled app in a debug version? As long as you don’t distribute it that would be ok I think…

Just a thought that crossed my mind yesterday :grin:

1 Like

Next Coding Sprint 2021 would be an oportunity to enhance Lazarus for Haiku joining interested people in it.

2 Likes

I can’t tell you how excited I am about Lazarus for Haiku. I used to play around with Turbo Pascal, way back… like way, way, way back. I never did software development professionally. But, always did enjoy the challenge. I have not touched programming in decades. Probably between 25 and 30 years ago now. I recently took a stab at YAB, but it isn’t my cup of tea. After seeing this a week or so ago. I downloaded Lazarus for windows and got a beginner book and I am so enjoying myself. I can’t wait to play around with this on Haiku. Thanks for this.

Donald

3 Likes

I am in a very similar boat to you. Programmed in my youth for pleasure and utility with school projects etc, learned C then C++ ant Uni, but haven’t actually programmed in ~25 years and remember BASIC better than C (ie - a little bit vs virtually nothing). I have just today started in on YAB… Watching the “Lazarus on Haiku” development with interest. The more languages and IDEs for friendly utility programming on Haiku the better! \o/

3 Likes

I also stared programming in BASIC in 1987, then with TurboPascal my favourite compiler.
The next step was FreePascal/Lazarus that is more advanced.
And now that i am using Haiku id like to have it working with the most recent stable version.
I have a working unstable beta versión but it crash when i add some new packages.
I hope someday Haiku will be another target supported in every new release they will publish.

4 Likes

I started a while back to write a recipe for Lazarus, but didn’t succeed, maybe something for the coding sprint? :wink:

Where?
Do you have asome Lazarus version working?
I think there are most people interested in FreePascal/Lazarus into unofficial Telegram group.

I was able to build and run it on x86_64 (Lazarus), some have been succesfull also with the latest fpc packages (that are available at the depot for install)

Lazaus-2-0-12-x86-64

10 Likes

Will be then a Lazarus hpkg ?

When someone beats me to it for writing a “working” recipe for it :slight_smile:

5 Likes

Ok, thankyou.

If I run my script from Terminal it works fine, when I try to do this inside a recipe I’m running into this also (either 32bit and 64bit), maybe it doesn’t pick up the /etc (eg fpc.cfg) part?

Today I tried out FPCUPdeluxe to build fpc and lazarus (on 32bit), worked fine! :ok_hand:

FPCUPdeluxe

Lazarus-fpcupdeluxe

16 Likes

Wonderful! good news.

1 Like