Just wondering what the view is on replacing the current GUI code in the Haiku base with Qt. This would of course require a complete rewrite of the desktop environment but i think the initial investment will be worth the effort.
The reason i suggest this is, the Qt framework offers a wealth of resources (developers, users, application and documentation) and it will be near impossible for the Haiku community to offer develeopers anything close to what Qt has.
It would also mean that the Haiku desktop environment would be directly compatible and integrate well with existing Qt applications (that is, drag and drop functionality etc). And most importantly it would save Haiku developers alot of time and effort, as they can rely on the Qt community for future framework improvements and support.
You will never convince the developers to switch the GUI to Qt. All not lost because you can run Qt on top of Haiku and worked pretty well when I ran it. Haven’t tested in awhile.
Well running Qt applications is not really my point. I’m suggesting that the Qt framework becomes a foundation block in the Haiku technology stack.
I am also thinking of this not as just a nice thing to do, but also for strategic reasons that will dictate if Haiku will become a serious competitor with Linux + Xorg + [insert desktop environment here].
One of the reasons Linux distributions are still dragging their feet in user uptake is because of the technologies and the non-standard desktop/user enviornments. That is, Xorg is bloated and built around an architecture no one uses anymore (Teletype terminals and alike) and several other major problems. Thus why Ubuntu announced they will be moving to Wayland to replace X. Also due to there being two major desktop environments (KDE+Qt vs Gnome+GTK) its difficult for consistent user experience. To get a constent feel between applications and also integration betweent those applications (drag and drop etc) is near impossible.
One reason Ubuntu has been so popular is because people can go from one Ubuntu system to the next and not have to worry about learning how to do simple tasks all over again. Also books and learning material can be written for novice users.
The Ubuntu transition from Xorg to Wayland will be less then smooth and will create opportunity for disgruntled users to move to Haiku…if its ready. Haiku has the potential to not only provide a good technological stack but also provide a consistent user experience.
Its also the case that in view of Gnomes noble efforts that KDE will end up prevaling simply because they have the better technology and community support. As Ubuntu is dropping Gnome in favour of their new desktop environment (Unity) is likely that distributions like Chakra that offer everything Ubuntu does but with KDE will spell disaster for Gnome.
Nokia are also funding full time employees for future development of the Qt framework. Its also the case that Nokia are ramping up Qt to to be used in its new phone operating environment (Meego). So that means even greater doors to be opened for the Haiku community in the future.
Your reasons do not matter. Developers choose what they like. They want to create system that is comparable to BeOS. Haiku was meant to be different from Linux and that’s what developers want to create. They will not change over to Qt. They know it exists but prefer Haiku’s GUI.
Developers make decisions on what is best for Haiku. They do the work and make the choices. Their aim is to make a different and better OS and are happy with what they have now.
Fair enough. But i think its a bit irrational. Educated decisions and thoughtful planning is more important than sticking to conceptual ideals. And as a developer i think Haiku would be much more appealing and more furfilling for the user if Qt was apart of the core technology stack.
You can always pitch it to the developers but don’t expect a warm embrace to switching over to Qt. You can get their reasons but mainly that it’s supposed to be better design and unique how it presently is. I don’t make the decisions but I have a strong feeling they’d be against doing that. It is same with other hobby OSes. Why don’t they use Linux kernel or Qt GUI? That’d really help them out. Android went this way by using Linux kernel. Apparently everyone coding hobby OSes wants to be different and do the OS their way.
Just use the QT framework as provided on the Qt-haiku.ru site.
It actually looks and feels native. One of the things you don’t seem to be grasping is how the desktop it built. this isn’t a linux kernel, this is a wholly different kernel “based heavily on New OS and BEOS” which is way different from Linux and Windows NT. The Dekstop GUI and windowing system are built into the system. Its all integrated together with a really nice API for pretty much anything you could want to build.
Its really a great os its just no feature complete yet, adding QT and ripping it all apart to ad QT in its place would be a huge waste of time.
But all is not lost. The QT port works Great and is improving all the time.
If you have questions about using the QT available for haiku, check with the developer.
I can see your point, but it will void all the current applications available, and there may well be performance issues. There would be no harm in replacing it and releasing it as a new distro.
at worst they need recompiling, replacing the gui in haiku won’t be like a liux affair at all, you really don’t seem to be understanding just how integrated Haiku is. The gui is built into it, its not sitting on top of the kernel.
Contact the QT maitainer. I am sure he can help you overcome any hurdles you might face bringing a QT application over.
It brings alot of HARM, Haiku doesn’t need fragmented distros like linux. Put your effort into porting to the current 4.8qt gui.
As for performance, the Qt port is very very fast and suffer no performance anaolmlys I am aware of. I have used QT on both linux and windows and the haiku version actually runs faster by user interaction analysis.
I don’t agree with using the Linux kernel as that would not be BeOS/Haiku then. It would just be another Linux distribution (yuck!). I’m just talking about the Desktop Environment. Also Qt does not equal Linux. So i don’t know why people have that stigma associated with Qt. Its a cross platform framework written in C++. That simple. Cheers.
Its not as simple as replacing the gui, you’d be breaking the OS by doing or even attempting this. I have no issue with QT, I find it rather useful. I take exception to putting in the effort to rip out the GUI “and alot of the systems functionality” just to change the gui. There literally no point in doing so.
Yes i have looked it over. But haven’t developed anything from Haiku as its not yet stable enough for my needs. Coming from linux i know the integration problems that exist between applications and the desktop environments. I just hope Qt applications in Haiku will be more integrated as it is in Mac OS X.
You could also try grabbing the BeBook and read Darkwyms intros to programming with Haiku. You will find the native API very full featured a bit QT like and very easy to a great may things with, if you know c++
It’s wrong. Haiku kernel doesn’t implement GUI suppport like in windows(win32k). GUI implemented in independent application app_server. app_server process vector graphics, window management etc. Haiku GUI API and all controls are implemented in libbe.so. libbe.so communicate with app_server by ports.
Theoretically can be more than 1 native interface libraries. Qt, WinApi, Gtk etc can work with app_server directly.
The BeOS API was designed to support a multi CPU box from day one (eg. the BeInc motto at the time was that “one CPU is not enough”). Every GUI application at a minimum runs with at least 4 threads (one for BApplication, one for BWindows, and the application server will also match a thread per BLooper). Since the BeAPI was designed to be multithreaded from day one, it has achieved a greater level of concurrancy than API’s that have been refactored over the years to be more multithreaded. Yes, the updated API’s run in multiple threads, but at their core this is more a hack than a planned design. It’s like sticking lipstick and a dress onto a pig, no matter how you look at it, it’s still a pig. Qt at the end of the day is restricted to have a single list of subscribers for each observed signal, and the core implementation must work around this design. The Qt framework will never change to support messages instead of using the observer pattern. With modern computing moving to many core CPU’s, the BeOS design (and designs based on similar requirements) will end up dominant in the 21st century.
BTW, Benoitt Schilling (spelling?), the original BeAPI framework designer, has been hired to be the Qt chief technology officer.
Interresting. I am not familiar with the BeAPI. I did a checkout of Haiku last night to have a look. Does anyone know of information relating to the Haiku equivalent of Xorg (app_server?) and the underlying OS design.