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.
2 Likes
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.
13 Likes
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:
rm -rf /boot/system/non-packaged/data/mime
rm -rf /boot/home/config/non-packaged/data/mime
gdk-pixbuf-query-loaders > /boot/system/settings/gdk-pixbuf-2.0/loaders.cache
4 Likes
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
I think we need to patch gdk_pixbuf to use find_paths to look for loaders instead of using hard-coded paths passed to ./configure.
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.
6 Likes
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.
2 Likes
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.
Client-side decorations are pretty standard outside of Unix, and they are also mandated by the Wayland spec. What problem does this create?
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.
2 Likes
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).
5 Likes
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.
WinAmp is a poor example. A window decorator for a classic application is not the same as a full skin for the entire window content.
1 Like
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.
Can we apply the entirety of the gtk-classic patches, instead of just that one, perhaps?
Oh, I see theyāre actually downloaded in the recipe and applied that way. Very nice. I suppose we can close that ticket then. 
5 Likes
Not really, because the code is compiled with different compiler options and configuration in each case. So we would have to agree with the gtk webkit team on how to compile it in a way that works in all cases.
WebKit is already shared as much as it can be, so there is nothing more to do here.
But in other cases, you would run into more of the same problems. Want to show an image? If youāre a Linux app you will probably use libpng and allow only PNG files. But if youāre on Haiku you want to use the translation kit and support any image format. And so on for media, network, ā¦
So, in the end, you end up rewriting pretty much the whole app. At that point, why even start from an existing app? Just write a new one from scratch? It will be less work.
Itās where this all started, still. One single app, and then everyone went āwow this looks coolā, and then companies all said āwe will do our own decorations with our own branding instead of using the standard onesā, and then there is no uniformity of look at all. On Windows this is quite bad and Linux seems to be headed the same way now.
4 Likes
My point is that letting applications draw their own window controls ia not a problem since many of them rely on this ability, the actual problem being enforcing toolkit-driven decorations (GtkHeaderBar)