Lazarus 1.9 trunk Qt4 and Qt5 interface (screenshots)

Can haiku_loader pass to the kernel that the offset should be corrected somehow?

Yes, or maybe we should add a Walter logo thatā€™s the same size as the Haiku logo there and then no one would notice :stuck_out_tongue: (thatā€™s a too visible Walter logo Iā€™d say)

Itā€™s not something I see as high priority, since it happens only when you build Haiku yourself.

3 Likes

Well, how about a invisible distro, for machines? A lot of equipment outthere runs on an OS that is not visible to the client: you only see a company logo and the company software :wink:

I guess though it would be cool to keep a small ā€˜tokenā€™ visible, like the leaf or something in that case :slight_smile:
And maybe have small hints to the load stage (i.e. text) in some corner of the screen (below the leaf i.e.).

Would be quite professional looking I think.

BTW We get actual questions from our clients to better ā€˜shieldā€™ our applicationā€™s OS since it is quite important our software runs 24/7/365, without people doing other things on the machine (like i.e. games), while virus protection and teamviewer capabilities are quite important.

A nice fact about our machines is probably also that there are even 20 year old machines in the field: which we still keep upto date. The software covers -all- machines.

Our machines even regulate industrial processes sometimesā€¦ I probably donā€™t have to tell you what it costs if the machine goes offline thereā€¦ (complete factory shutdown and restart!)

Itā€™s not too hard to put your company or product logo there if you are doing your own distro. as for ā€œshieldingā€, currently itā€™s less easy to do. How I would approach it is split apart the Haiku package and move at least Tracker and Deskbar to a separate haiku_desktop package, which you could then remove from the machine (and have your app started directly by launch_daemon).

Not sure if I would trust Haiku for this without extensive testing however :slight_smile:

1 Like

Iā€™m aware Haiku is ā€˜onlyā€™ at Beta 2 stage :wink:
Still, itā€™s quite stable as it is already. So in theory it would be useable soon, but not for all situations indeed. And of course Iā€™d need to have hardware watchdog support since for non-industrial useage a restart every now and then is not really a big problem.

That being said, I think something like a service-stick would be interesting to show on one of our tech trainings maybe, and see how people respond to that. I remember BTW back in 2000 we were thinking about switching to BeOS, I was already testing and demonstrating with it in-house. When asked, I decided to vote against it back then because of the issues Be had keeping ā€˜afloatā€™ in this world.

Since this does not apply now, and itā€™s opensource, I am again showing this (Haiku) every now and then: this time with our software already running succesfully on it (pending some updates ;-))

In the end itā€™s not my decision to make, but we are a very flexible company :slight_smile:

1 Like

First problem, downloaded the 3.3.1 unstable from @s40in, needed to create some links to the binaries in non-packaged/bin to find out the build needs ā€œ3.2.0ā€ :wink:
PS, this is for x86 (gcc2h)
Actually first one is where to find the updated ones :slight_smile: In fpc/rtl/haiku/ replace termios.inc and termiosproc.inc with updated versions.

So the patch file is in de FPC bugreport, here:
https://bugs.freepascal.org/file_download.php?file_id=32816&type=bug

You need to patch the files mentioned, located in:
fpcsrc\rtl\haiku

After that you can create a source package, and then compile fpc, and create a bin package.
Indeed, if you try to create a bin package to s40inā€™s example, youā€™ll find links to 320 like folders: these shortcuts need to be updated to point relatively into the new 331 folders.

Hope this helps?

Pulkomandy,

Is there anything I can do to help to get the tty flush patch done? Just let me knowā€¦ Thanks!

A new version has been updated that implements the actual flushing for the pc_serial driver and fixes the mistakes pointed in code review about the handling of the flags: https://review.haiku-os.org/c/haiku/+/2516

I can look into adding support to the usb_serial driver too. My questions about locking and if itā€™s needed to somehow signal the next writer after flushing the tx buffer remain open. I hope someone who knows the tty layer or wants to dig into it can answer them, but otherwise we can merge this and wait for someone to complain that it doesnā€™t work.

I should probably have SerialConnect flush the port when opening it, too?

Hmm, makes me want to finish my conversion of Vortex Tracker II from Delphiā€¦

Good morning!
Nice, I will test this later on this week. And it would be super if also USB will have this working (since at least we use this more and more often).
In the meantime I am poking around in VideoProducer/consumer and ffmpeg to fix some (smaller) problems there. i.e. thereā€™s a fault in the colorspaces list :wink:
I need to finish-up on this before I revert to a normal working system for the serial testsā€¦

My apologies if im missing it, this thread is kind of long and winding.

Iā€™ve had something of an interest in FreePascal + Lazarus lately. And I find myself wondering what is left to get done, in order to get this in HaikuDepot?

It reads like its already quite usable, even if there are a few bugs still to be ironed out.

You can add my repo with Lazarus and fpc (unofficial build).

Haiku 64bit
pkgman add-repo http://repo.hakilo.ru/x86_64

Or Haiku 32bit
pkgman add-repo http://repo.hakilo.ru/x86_gcc2

Ah ok cool.

What is keeping it out of the ā€œmainā€ repo right now so to speak?

Using hpkg for Lazarus is not a good idea. Lazarus should be able to recompile itself. This is the only way to add new components to Lazarus.

Lazarus in the hpkg package turns into a toy or demo.

Itā€™s the same on Linux, too. Lazarus installed from apt to /usr as other application and use a .lazarus folder on the user home directory to store additional data, including the lazarus binary when it recompile itself. Why donā€™t you follow the same principle as Linux? There is fpcupdeluxe that allow us to have Lazarus installed to an unprivileged folder under the user home dir, but I didnā€™t test it yet.

1 Like

I kind of concur with @giahung.1997tn. Itā€™s widely available in linux package managers; and there is certainly a lot that can be done with it short of rebuilding it with fpcupdate. lazarus-ide.org points end users to .deb and .rpm packages after all.

I had asked about its status, mainly to see if there was a technical reason for keeping it out of the main repository. Ive had a little experience packaging things for systems like pkgsrc.

I thought perhaps I could leand a hand, though I doubt it is the easiest thing to package, and Iā€™d have to learn the ins and outs of hpkg.

I have tried to install Lazarus with fpcupdeluxe, both in 32 & 64 bits modes and with QT5 but everytimes it finished with errors.
Freepascal Beta RC1 works but fp IDE is not functional, you can use nano or vim to edit code and compile from command line with fpc:
ftp://ftp.freepascal.org/pub/fpc/beta/3.2.0-rc1/
It install in non packaged so it not need additional privileges.

So Lazarus and the LCL are not building at all right now? Is that the issue?

I havent enough skills to make run lazarus, i have tried with Freepascal 3.2 beta and latest lazarus sources, with libqt5pas, and with options like BIGIDE or compile allā€¦