I know we need this apps atm…
But not for ever!
HaikuWebKit is a port, if oyu want, but WebPositive is a native application.
I don’t think banning things is a good idea. There is potential for making better native apps and we should encourage that. Not by preventing the ported apps from working better, that’s cheating 
It’s more a matter of where we all decide to put our efforts and which compromises we are willing to make. Sure, the ported apps will allow some people to run Haiku full time instead of in a virtual machine. They probably will even allow me to stop running a second computer with another OS, and that’s great.
Possibly it allows us to focus on the apps where there are a lot of opportunities for making good use of the native features. Personally I think it would be nice to not forget the boring, “everyday” apps and it turns out these are quite challenging too: web browser, office suite, …
What even are our plans for these? For the web browser it’s a lot of little things, like the bookmarks being stored in files with xattrs that can be used and distributed by other apps (it was common in BeOS days for apps to include a link to their webpage in a zip archive that way). It’s the storage of the origin URL in an xattr of downloaded files and saved webpages, so you know where your files came from. It’s the use of native looking controls in web forms, including date pickers, buttons, checkboxes, … It’s the ablity to display any image format (even very obscure ones) directly, as long as you have a translator for it. It should also be the display of a progress bar over the icon in Tracker during download. It should be generating thumbnails for downloaded pages and files automatically in a format that Tracker (and other apps, if they want to) can use. And so on.
All of this of course is also possible with “ported” software by adding a bit of Haiku specific code. Probably not the easiest thing. And when writing software from scratch, getting to the level where you can even care about all these details is also a lot of work.
In some of my other projects I also use ported code and completely rewrite the GUI around it, and I can usually go as far as I want into full native integration. But that’s also months, if not years, of work.
5 Likes
I’m a nobody, and I haven’t gotten much sleep, so I figure it’s a good time to chime in.
While I appreciate Web and Libre Office, I would prefer native apps over ports. By “native” I mean doesn’t rely on a ton of libraries. Like GTK and Qt. Again, I understand that, right now, ported apps that use those libraries are important to fill gaps that either don’t exist on Haiku or don’t quite work right, yet.
I appreciate all the work that goes into WebPositive, for example, but it still doesn’t quite work for me for a lot of sites. But I would be very happy for the day when I could use it full time, though.
We need things that work now, to keep people’s interest.
I have programmed in the past, but I’m not a developer. That being said, I wonder if there are people who would like to write programs for Haiku, but don’t because the only viable language is C++. And Yab, sure. People I know generally use C# or Swift. Even if I could get some of them interested in Haiku, I’m not convinced they would give up their language of choice to pick up C++.
Then that leads us back to GTK and Qt; if those are the toolkits people are used to using and comfortable with, that’s probably what they’re going to try and use first, even if it’s a Haiku-only program.
Now I have rambled and accomplished not much at all. Carry on, folks.
2 Likes
What outsider developer would write a platform-only app when they could do more with a portable one? Let’s face it, most developers will always try to diversify. This makes it difficult to motivate someone to write something for haiku, even if it is only supposed to and will work there.
Another problem is, if someone changes a haiku prot to be too haiku-only, everything has to be adapted to the changed environment each time. Therefore, if the programming interfaces (QT, KDE…) run stably on Haiku, it makes sense for most people to write their native apps on it.
The whole thing is a very difficult topic and you can’t even say where it begins and where it ends.
I wish there were more people who love haiku enough to write their apps directly for haiku like it was with GobeProductive, InsideCreator and many others back in the day.
I’ll be honest here and say that I hope, one day, that 64-bit Haiku will be able to run 32-bit programs, because the first thing I would do is ditch Libre Office and use GobeProductive. Unless someone develops something else sort of like it. Really, I’d like something like Scrivener, but not if it’s Java.
For all native lovers, please uninstall all ported software then take a breath and feel better. Enjoy! Thanks!
3 Likes
I agree, no ban or confinement! I personally welcome ports as they let me do what I need on Haiku.
On the other hand I wish we all do some effort creating/fixing/improving native apps (=apps which extensively use Haiku API).
I too would prefer to have native haiku apps, it is no coincidence that I wrote a few comments above that I would like epiphany to have a way of creating tabs that is coherent with haiku functioning…
But hey, the situation is what it is, and up until very recently we had great difficulty in having a browser worthy of supporting modern web needs, that’s a fact, I too would prefer to have a webpositive that worked optimally, but so it is not, and unfortunately the resources are what they are, so I understand the skepticism and the spirit of conservation, but we also need to face reality and not complain too much about what is available today, always with the proposition that tomorrow situation is better… Come on guys, we’re in our 20s, adolescence is over, this OS needs to become an adult.
that’s exactly what I think, many more users is an advantage, among them there will be some new developers, because more or less we are all geeks, someone else will contribute with donations, and someone else with reporting bugs, and sharing the enthusiasm about Haiku to other people. There is only to be gained with more users approaching HAIKU, and this is the time, because at least you can now surf the web decently, we can use HAIKU almost as a primary os, it’s a big game changing.
1 Like
You are a little too skeptical, you have no idea how many people are looking at the opensource world but are tired of the chaos of linux.
Can not imagine such flame about some other mediocre port. If you don’t need it, just don’t install it. What’s wrong with Epiphany? People feel that Haiku goes away from their ideal and ideas? People feel that development goes in wrong direction? No, it does not. Haiku stays where it is. There just appeared software people actually needed, but does not have Haiku’s look and feel.
We should realistically estimate what our community can do and what doesn’t. Plenty of native programs can be developed by enthusiasts, but, honestly, is there someone who have ambitions to develop native replacement of GIMP or Inkscape? @3dEyes fills this gap by Qt and even more now by GTK ported software. In that respect Haiku can be kind of MacOS: native if there are native apps, not really native if there is no. New native programs will displace previously ported ones. What about Epiphany I personally believe that it is just temporary solution until HaikuWebKit polished and bugfixed. One day Web+ became good enough. And this flame became totally unimportant.
1 Like
Without porting, the software world of haiku would be very empty, we should be aware of that. I am grateful that we have an office today, that we have painting programs that offer more than others before… So thank you for the porting and the upgrading of haiku as a result.
We’re probably getting agitated here, since the porting ones are announcing more info and new releases than those building the native ones. As an example, I would like to mention Wonderbrush 3.0, which I saw live at the BeGeister 2018 in Hamburg/Germany, which has great approaches and improved/new functions. Unfortunately, you don’t hear anything about their progress.
I think communication needs to increase in this direction.
Maybe we should split this post, because it casts a bad image on the browser that was actually discussed here?
1 Like
Not to be critical to web positive here, which is a fantastic project that I love, but I think lack of a fully stable and truly useable browser is what stops the vast majority of people from switching to haiku as their main OS. Either we accept that haiku will not see much adoption until web positive is more complete, or we plug the gap with a ported browser while web positive waits in the wings. In the latter case the browser port is almost a special case of ported software. In either case progressing web positive is vital.
1 Like
Maybe add a badge or similar to HaikuDepot to distinguish native from non-native apps. Some criteria to determine what qualifies as native must be decided on. It would also be good to be able to filter for native apps in HaikuDepot.
3 Likes
And who should enter this title? Who decides what is native? You can’t make it dependent on the frameworks used, because a newly written program that only appears on haiku and uses qt, so it’s also native.
In the end it is decisive what the user needs, that’s what they’re looking for. Don’t always assume you are enthusiasts, that’s the wrong way.
1 Like
if you’re interested in machine kit or LCnC, there’s a big market out there for a easier to work with version, with a good gui stack.
and mostly it appears that the gui stack and some thread utilities for rtos are really the only thing locking either to Linux. Particularly debian, and the use ability of debian is ridiculously poor.
I’ll setup the repo, but I’m not making much progress on my own truth be told. i don’t have much free time at the moment. i can free up funds however. early next year
having something that’s useful for production, would bring development.
Also, Autodesk now has a browser version of fusion360, so that’s a bit of a game changer. I’ll try it with epiphany over the next few days.
Web browser is a special software and I am not sure that native web browser even needed. Modern web browsers are basically virtual machines and not native by definition. It use JavaScript/WASM as executable code and tends to prefer custom control styling over OS native control look.
When some big web browser like Chromium or Firefox will be ported, WebPositive may be treated like Internet Explorer 6 in Windows and used only to download some other browser.
Even on MacOS I see cases where users install Chrome and don’t use native Safari browser.
Web browser is too big thing that current small Haiku development team can’t handle.
14 Likes
Problems With the Web
I’d love to see web browsers rendered obsolete overnight. I know it won’t happen overnight because there are too many frameworks and server-side apps that depend on having a web browser on the destination machine so it can behave like a glorified thin-client. Native apps can access the internet without a browser. Look at the Vision IRC client. IRC probably predated the HTTP protocol anyway.
Web apps that are installed on top of a browser engine aren’t much better. They may compile on a WebAssembly client and use only WebGPU or WebGL as their graphics framework but browser clients can’t exclude the unnecessary parts that the app doesn’t need.
Solutions
Taking the GTK and Qt library dependencies away from the browser is just the start, as I see it. Taking HTML and CSS away from the GUI is a better solution. Making the JavaScript JIT an implementation of WebAssembly so that separation of them becomes unnecessary is something that’s already being attempted elsewhere in the industry.
Following existing trends isn’t enough to be advanced. The PopOS Linux has rejected GTK in its GUI because the half-written Rust-based Iced GUI, based on the Elm browser app language, can be implemented as easily and more quickly than GTK can be updated. The fact that Iced is based on the wGPU Rust crate (a Vulkan wrapper) and full of thread pools may actually allow it to outperform the traditional GUIs more quickly than they can be updated and implemented in traditional programming languages.
Conclusion
Having a “native” GUI is nice. Having software that performs well and doesn’t go obsolete because of its adherence to an obsolete style-guide is far, far better. Please don’t get stuck in the past so much that you refuse to see the future. If software is flexible and performs well, API wrappers can be written. The Wayland wrapper for the Haiku compositor is an example of this.
If the native GUI is fast and offers features that GTK doesn’t, a GTK to Haiku wrapper can be written to automate the porting process. Rewriting a framework to hand-port it to Haiku’s frameworks may just be a mis-use of time.
I’ll leave it there for now and see what the rest of you make of this.
1 Like
If nobody knows what native applications are, then we can just drop the whole discussion. Please inform @pulkomandy that he has wasted time on WebPositive, an application that he thought were native and distinguished from ported (whatever that is, nobody knows!) applications.
Probably just some random characters not making up coherent language that should be ignored.