<waddlesplash>
the first task is getting GTK to even attempt to fetch the correct X11 property, which I don't think it does, there's some kind of magic needed for that
<waddlesplash>
the spec will probably give an idea
<waddlesplash>
once you get it to invoke XGetWindowProperty with the ...XSETTINGS... atom as the requested property, then you can construct a property appropriately
<waddlesplash>
probably make a new Settings.cpp file, and have the XGetWindowProperty implementation in Xlibe call that when the XSETTINGS property is the requested one
<waddlesplash>
nephele: make sense so far?
<waddlesplash>
or is this too intimidating? :)
<nephele>
It makes sense so far
<waddlesplash>
well, once you get the XSETTINGS property fetch, you "just" have to construct a valid settings datastructure according to what the spec specifies
<nephele>
I see there are quite a few settings we could expose to gtk
<waddlesplash>
indeed there are
Diver has joined #haiku-3rdparty
<waddlesplash>
I think Gtk/FontName is only font name not size, however
<waddlesplash>
not sure if we can specify size
<waddlesplash>
also, I would avoid specifying anything DPI related in here, just yet
<waddlesplash>
there's actually a way to specify DPI related things in the X11 Display information, much higher up
<nephele>
Say, why doesn't gtk do this with fontconfig?
<waddlesplash>
no idea? or maybe it does and we don't configure fontconfig correctly?
<nephele>
it can specify stuff which fonts to try first and such
<waddlesplash>
I at one point traced the whole path for how it picks fonts and that's how I found this
<waddlesplash>
I think this is the best way to do it, because we can implement it right in Xlibe
<waddlesplash>
and there's even a way to notify property changes and then GTK appears to actually reload settings
<waddlesplash>
so live font changes might even work?
<nephele>
Yes, but this won't match our fallback behaviou
<nephele>
say, i set noto sans thai as my default font, this will then if i read latin fall back to noto sans because of our fallback
<waddlesplash>
no, but, well, first steps
<waddlesplash>
oh
<nephele>
Yeah but this interface can't support this
<waddlesplash>
yes, it uses fontconfig internally, so as long as Thai is set to fall back to Sans it may work
<waddlesplash>
and that may be exactly how Thai is configured, being a Noto font
<waddlesplash>
so, let's try this first and worry about that later
<nephele>
we basically go for every font "else use noto sans else use noto emoji else noto symbols else noto symbols2 " :)
<nephele>
I guess first step is cloning gtk3 and libbe and building them?
<nephele>
xlibbe
<waddlesplash>
no, you shouldn't need to even edit gtk3
<nephele>
ah okay
<waddlesplash>
you can probably just install the package and use LD_PRELOAD to pick up your custom xlibe
<waddlesplash>
when starting gtk3-demo
<waddlesplash>
that's the point, this facility is already used on real X11, so we should be able to do exactly the same
<nephele>
ugh, that demo integrated badly .-.
<waddlesplash>
?
<waddlesplash>
oh, client side decorators? yeah, not fun
<nephele>
no dark mode is more annoying to me
<nephele>
We should have a "Haiku" and "Haiku-dark" gtk theme
<waddlesplash>
I think that's what Gtk/ColorPalette is for
<waddlesplash>
so, you can specify the setting :)
<nephele>
(because apparently substring matching for "-dark" is how gtk determines dark mode)
<nephele>
We need to make gtk themes or atleast add local settings for stuff like scrollbar hiding
<waddlesplash>
here, this page explains the X11 clipboard in considerable detail
<waddlesplash>
between that page and the existing code you should be able to get a sense of how I mapped one to the other
jadedctrl has quit [synthon.oftc.net larich.oftc.net]
<waddlesplash>
most of the stuff that page talks about like event handling I already took care of and turned it into hook functions like you see in the file already
<waddlesplash>
heh I just noticed _x_handle_get_clipboard doesn't really behave correctly if there's no text on the clipboard
<waddlesplash>
or at least I suspect it doesn't
<waddlesplash>
nephele: another even simpler thing you can look at is why custom cursors look so wrong
<waddlesplash>
I'm just using B_GRAY1 to import 1-bit-per-pixel bitmaps, but I suspect this isn't really correct one way or another
<nephele>
huh? isn't our cursor a HVIF?
<waddlesplash>
no, I mean custom x11 cursors
<waddlesplash>
apps can specify their own of course
<nephele>
yeah but, is there no way to give it to x11 apps as a vector graphic?
<waddlesplash>
they can chose from an "enum" of course
<waddlesplash>
but some things like GIMP have custom icons for tools, right?