I’m usually in favour of ported software, but most (if not all) of the GTK apps on Haiku are rather atrocious with system integration. Their core design language does not match with the rest of the system at all. At least most of the Qt apps blended in quite well with native Haiku applications, so those are fine (with a couple exceptions).
Even with a Haiku-esque theme, GTK apps still don’t look like they fit in (especially those that have thick headerbars). To be fair, there are also some Qt apps like NeoChat and Telegram that similarly don’t integrate well. The difference though is that they’re exceptions of not integrating well, in contrast to being the general trend with GTK applications.
When it comes to making applications with Haiku in mind, native is still preferred. But if a developer also wants cross-platform, at least use a toolkit that actually tries to integrate with the system (like Qt).
The level of integration of a ported application depends on the effort involved. A lot of work went into the Qt integration, so it looks as authentic as possible.
Telegram looks that way on all operating systems, because it doesn’t use the standard Qt widgets, but rather its own set of elements.
Integrations for GTK such as drag-n-drop, styling, color schemes, and so on are feasible, it just takes a little work.
Agreeing with many of your points, however it is much harder to integrate GTK3+ apps unless running with GNOME. This is a struggle even on Linux. Issues with system integration outside of GNOME started with GTK3 and only got significantly worse afterwards.
Realistically, only GTK3 applications which go out of their way to not follow the GNOME HIG could be made to closely integrate with the rest of the system in full. The only onnes that come to mind are GIMP and Inkscape.
Part of this is prolly due to the focus on client-side decorations in GTK3 onwards. Haiku in contrast uses server-side decorations.
I agree that polishing up the GTK compatibility to take better advantage of Haiku APIs is at least a more centralized solution. If there were as many Haiku-native applications out there as GTK apps, it might be a different story.
Very close here in finishing a full compilation. I have haikuwebkit’s WebKit1 614.x working on x86_gcc2 for YouTube, so I may restart the WebKit2 compilation review (with the newer patches) and update the ticket.
Just installed Gnome Web to see what the fuss is all about. It crashes directly on startup on my freshly updated nightly system (hrev56632). The Debugger reports the stop reason as “abort() called”.
Do I need a Beta4 test candidate system or is something else wrong here?
Saying that nothing is working is not enough. What does it say if you run it from the terminal? Most likely, again for some unknown reason the package manager did not execute the post-install scripts.
Run these commands and try again:
Thanks @3dEyes , that did the job. Web is starting up normally now.
If it is still of interest, here is the commandline output when starting Web (before I executed the commands that you gave me):
(Web:784): GLib-GIO-WARNING **: 23:06:40.440: Failed to create file monitor for /boot/home/config/settings/glib-2.0/settings/keyfile: Vorgegebener ?berwachungstyp f?r lokale Dateien konnte nicht gefunden werden
(epiphany:784): GLib-GIO-WARNING **: 23:06:40.464: Failed to create file monitor for /boot/home/config/non-packaged/data/epiphany/permissions.ini: Vorgegebener ?berwachungstyp f?r lokale Dateien konnte nicht gefunden werden
wl_ips_client_connected
display: 0x1048f09dfc60
client: 0x1048f0a14e00
(epiphany:784): epiphany-WARNING **: 23:07:20.917: Could not open history database at /boot/home/config/non-packaged/data/epiphany/ephy-history.db: locking protocol
(epiphany:784): Gtk-WARNING **: 23:07:20.985: Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.
**
Gtk:ERROR:…/gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /boot/system/data/icons/haiku/status/16/image-missing.svg: Bildlader-Modul konnte nicht geladen werden: /packages/gdk_pixbuf-2.42.2-8/.self/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: No such file or directory (gdk-pixbuf-error-quark, 5)
Bail out! Gtk:ERROR:…/gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /boot/system/data/icons/haiku/status/16/image-missing.svg: Bildlader-Modul konnte nicht geladen werden: /packages/gdk_pixbuf-2.42.2-8/.self/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: No such file or directory (gdk-pixbuf-error-quark, 5)
Abort
Kill Thread
This is not the case, but the loaders.cache file, which must be rebuilt when any change in the list of format plugins (e.g. installing librsvg adds its own plugin). I want to add in gdk_pixbuf_init check for changes in plugins directory (checksum of file names for example) and rebuild this loaders.cache when this checksum changes.
But this is only part of the problem - we also need to do glib schemas compilation (glib-compile-schemas), when installing many gnome programs. A post-install script is the best solution for this, but for some reason it is not always run by the package manager.
This is the way, realistically the forces on HAIKU at the moment are few, so personally I would say, let’s evolve as we can, cleverly, it’s true the original project was replace entirely Beos in its clone entirely opensource and free, but over the years (and now there are starting to be many) HAIKU has acquired its own function which has become physiologically natural, and that is to take the existing open source out there and place it in a more coherent and orderly context. For example the QTs but also other portings seem more beautiful and integrated than on linux… Haiku is having the natural role of taking the best from the chaos and reassembling it in a more coherent and improved context possible… once GTK will be made coherent with the aesthetics and philosophy of functioning of HAIKU, they will be better than ever, they will be beautiful and functional as they have never been on linux, just like it happened with QT. The undoubted advantage is that the portings will multiply but everything will be in an environment that is as coherent as possible. What about native apps? … I don’t know, I think they will always be few, because writing demanding apps from scratch or nearly so will always be too complex, and no group or even company will ever do such a thing, as it has the purpose of having its app on which it has invested very compatible with as many different os as possible. So, pragmatically, I’d say that native apps will either be very small apps, or apps that will enhance the overall functionality of the OS.
I don’t think it’s necessary to have a certain integration of the gnome environment, the porting of single apps is enough, which are the biggest and most useful… in case an interaction could be created through the environment and the way it works haiku with its API when needed…
Exactly, they will be the most beautiful GTK ever, by the very nature that haiku has assumed, to eliminate chaos, ugliness and useless or superfluous things.
The statement you were replying to meant that GTK applications do not integrate well with a system, unless it is running GNOME. It’s not about integrating GNOME into Haiku.
serverside decoration is needed in haiku for the tabbed layout (and easily switching the rendering with a decorator). one could do this with clientside decoratin and lots of ipc likely but the serverside part is easier and the way app_server does it.
CSD is one of the dumbest things that is really annoying because they break the integrity of the system. Appearance, behavior for different applications becomes not obvious and different. CSD is currently disabled in GTK3 for Haiku (gtk-classic patches applied).
What would Winamp be without CSD? The problem actually lies on Red Hat throwing decades of well-defined UI conventions out the window for some excuse of better use of screen estate. This sorta made sense when the original bug for it was filled, but in this age of 4k monitors? Give us a break.
my take on all of the porting efforts. start 1 by 1 modularizing applications into core components and then set them up so that be native portable c libraries, and use haiku specific gui’s.
far to often these app are tied to low quality bastardized gui tool kits. I’m not sure how feasible that is, but it’s probably worth considering.
So you want to factor out the JavaScript JIT that both WebKit_GTK and HaikuWebKit depend upon into a separate package? Great! That would shrink the code base in half between the GTK port and Haiku port. Would it make the API switch from GTK to Haiku any less painful? Not at all! It would only allow both ports to share some overlapping code via a shared library and potentially allow the JIT compiler to be reusable. Making a Node clone based on that shared library might be possible but only if someone wants to sink major time into it.
The idea has potential but needs more time than just solving today’s problems today and increasing the manpower requirements just to make both GUIs share some code. The real problem is that you still have to port the GUIs by hand and therefore the really big problem is not solved by your plan.
