I just complied atk, because I decided to see what it takes to get Gtk2 compiled. Atk compiles nicely in x86 mode. However, I didnt specify any install directories. Where can I find, which parameters must be passed to configure so make install will install them at the right place?
Did you built it with haikuporter?
Because there is already an ATK recipe in git: https://github.com/haikuports/haikuports/tree/master/dev-libs/atk
No package in Depot hovewer.
I would say: just compile it with Haikuporter, everything will found his place.
As somebody mentioned earlier, porting GTK2 will need plenty source code changes, one needs to implement the whole thing from the ground.
GTK using X as graphical backend, and there is no X on Haiku yet (AFAIK). One could port an X-server to get X based programs to run on Haiku, but X is a different universe, so it will make a big mess, and as X will draw the Desktop, there would be no seamless integration with the Haiku Deskbar.
Other way would be to have a rootless X server, it wonât draw any desktop, yust the program windows (AFAIK). It would be better, but not ideal.
The best would be to get eliminate the X dependency from GTK, and reimplement the GTK widgets with Haiku widgets. Then any GTK app would get the standard Haiku look and feel, drag-and-drop compatibility with Haiku, and everything.
Required work to be done:
Normal X < Rootless X < Haiku native backend for GTK2.
There is already some X supporting libs in HaikuPorts, you could look into it.
MAybe it could help: iâve seen somewhere an SDL based X-server fork. It isnât ported to Haiku yet, but i suppose it would be the easiest way to get things work.
That X dependency is an issue. Agreed.
With Wayland coming along, would building an X server even be relevant?
I strongly agree with @PulkoMandy - Haikuâs strangth is the native applications and toolkit.
Do we really want to port another UI technology to Haiku and splinter it a little more?
It isnât about if it makes sense or not for the Haiku community. If a user needs something, nobody should stop him. If he needs GTK2, then he needs it, thats all.
Wayland does not change much things: we still need to port âsomethingâ to get GTK running. Either we port GTK to our native backend, or we port one of the backends it supports, as a wrapper on top of our graphics stack.
TiltOS is probably where this was pushed the most, eventually they got GTK running (GIMP and everything) inside an X server under Haiku. But that was not really well integrated with the native apps, so it stayed mostly a curiosity.
That being said, an X server for Haiku would still be quite useful to me, if I could ssh -X to my Linux box and run some apps there with display on Haiku.
TiltOS used an SDL based X-Server if i remember correctly. If their repo still online, i can chack the patches at the weekend.
Miqlas, thanks for your help!
I am watching this closely because I would like GTK to build the veejay app. There is a lib X dev in HaikuDepot which allows some apps to build. Havenât looked at whatâs in it though.
Writing a Wayland wrapper server around the Be API shouldnât actually be all that difficult, from looking into it. Iâve been meaning to take a stab at it, but Iâve not had the time yetâŚ
Just a thought, do we need another toolkit on the Haiku platform?
The reason I ask this is that all these various kits require - as well as initial development - constant maintenance to bring them up to the latest version, etc. One only has to look at the page containing the GTK bindings (https://en.wikipedia.org/wiki/List_of_language_bindings_for_GTK%2B) to see how fractured everything is right now!
My question is, with the limited skillset and resources available to the Haiku project, shouldnât we just spend time working on the core OS and the app kit?
If you really, really want to run GTK apps, is the solution not to VNC to a remote/local Linux installation and run your app inside there?
Note - this is just my thoughts - Iâm not meaning to offend anyone.
Of course, everyone should do that, IMO. 
But since we have no influence whatsoever on what people spend their time on, itâs kinda moot to dwell on it.
Also, the skills to port software donât really overlap with whatâs needed to work on the OS or native apps. Much can be accomplished with no or minimal knowledge of programming.
More tools means more possibilities, more possibilities means more users, more users means more developers, and again, more developers means more tools and so on, this is life. GTK is good thing.
And also it is simpler and more comfortable to run apps on one OS.
Fair point, this is an open-source project, people are free to do what they want to.
I understand @damoklasâ comment as well - it does make sense - but if we have Haiku running GTK and QT apps with different UI themes, what actually separates us from Linux? Arenât we polluting what makes Haiku Haiku?
I suppose itâs a pointless debate - we can probably close it down.
People are welcome to their opinions on this matter. However, Roland wants Mono on Haiku, and I want veejay on Haiku. Those are our reasons for getting GTK running. Some of us are also working on native applications as well. Native apps are best, but any app is a good app.
Could we not create a Haiku renderer for the Windows.Forms Mono port then?
Iâd not mind helping out on that, Iâm a C# developer by trade.
1 Like
As I mentionned above, the Haiku project itself does not endorse any of the UI toolkit ports currently. They are all the work of 3rd-party users/devs (some also happen to be Haiku contributors, but still).
Certainly the Haiku project shouldnât discourage such efforts. After all, people were running a non-native Firefox 2 on BeOS back in the days, and it filled its gap quite well.
I think macOS has a good compromise there: Qt and GTK apps are possible, but people prefer native ones whenever possible. We should achieve this, not by turning down any Qt or GTK efforts, but by accepting them as competition and striving to make the native apps and kits better than them.
(and as a concrete example, I should mention that the availability of Qupzilla was a motivation for me to keep WebPositive more up to date and support more HTML5 features so it could have more points at the html5test!)
2 Likes
Yup, its about the kit and how programmer friendly it is. C(++) logic is portable, but managing the system, windows and events, that usually generates a lot of code (even more than the part that does the work). Make it programmer friendly, and there will be a minimal need for alternative UI components.
1 Like
When Mono first started, it seemed to me to be a crazy idea. Really crazy. Microsoft wanted to create a managed software platform that was open design in name only. But in reality, it would be very difficult to port to non-Windows system. You want to write a program in C#? Sure, no problem, You want all the classes to make your program run? Much harder! Microsoft wrote the portable code in such a way that it seriously mimics Windows, not Linux. Well, over time the guys working on Mono did a lot of work. A whole lot of coding. It was a real inspiration. There are many, many really nice .NET programs. My favorite is Paint.NET which is like PhotoShop. So now Mono is part programming language, part virtual machine, part operating system. And I am guessing it has a lot of Linux flavor.
My hat goes off to Roland and the other people who are working on this port. I knew it could not be easy. And Haiku is not as mature a platform as Linux. It is a work in progress. Every week I bump into issues in Haiku that make me reach for a bottle of whiskey 
Half the time when I complain, someone tells me there is a solution. âDidnât you know we fixed that in X package, or Y recipe, or Z daily release?â So thanks for your patience. Thanks for every bug fix, every updated package with a fix, every new took kit that helps build a new app.
Itâs cool watching Haiku grow in this organic way.
2 Likes
To be perfectly clear: I do not remember asking for Mono. Someone made a typo about that. Neither am I porting Mono. I am currently playing with QT, design the stuff under linux, compile on Haiku. Thats easier because QtCreator is a one stop shop: design the gui, write the code and build.
Just as any widget system, there are many things to look after.
OK, my mistake. There is another fellow on #Haiku chat that is working on the Mono port, and cussing up a storm. The port has some issues
1 Like