Source only release. I didn't bother re-spinning the various other platform builds just to bump the version number.
Previously, previously, previously, previously, previously, previously.
Dali Clock 2.45 released
I basically hadn't touched the X11 version since the Twentieth Century, so it was looking pretty threadbare compared to other platforms. I replaced the 1991-vintage Xlib version with a backport of the macOS OpenGL version to GTK 3. Let me know how it works on your incomprehensibly powerful hundred dollar supercomputer.
Tags: computers, daliclock, firstperson, linux, mac, retrocomputing, toys
Current Music: The KLF -- 3 A.M. Eternal ♬
50 Responses:
This is not going well for me on Slackware 14.2, OpenGL 3.1, gtk+3-3.18.9, which is all kinda old. So if the answer is "that's too old for me to care about", that's fine.
The Makefile wants to run update-icon-caches, which is not a command I have. There is /usr/bin/gtk-update-icon-cache, but it also needs the --ignore-theme-index option.
The first error I get on running it is: "xdaliclock: GL error in glTexImage2D #0 2048x512: invalid valuexdaliclock: GL error in glTexImage2D #1 1024x256: invalid valuexdaliclock: GL error in glTexImage2D #2 512x128: invalid valuexdaliclock: GL error in glTexImage2D #3 256x64: invalid valueAborted". It doesn't seem to like the GL_LUMINANCE_ALPHA enum. https://docs.gl/gl3/glTexImage2D doesn't list that as a valid value, and https://stackoverflow.com/questions/20076814/ says it's gone in OpenGL 3.1. Replacing the uses of that enum with GL_RG in the glTexImage2D() call gets me past that. I have no idea if that's even a sane thing to do.
The next error is actually from "glEnable (GL_TEXTURE_2D)" which I found by adding more check_gl_error() calls when "xdaliclock: GL error in gOrtho: invalid enum" didn't make any sense. https://docs.gl/gl3/glEnable doesn't list that as a valid enum, but other OpenGL code I find does use that, so IDEK. Some people say it isn't needed, so I commented it out just to see what happened.
The next error is "glMatrixMode(GL_PROJECTION)" giving "invalid operation". Given that things have been messy up to this point, I don't know that it's worth trying to figure that out.
Well, my Raspberry Pi has GTK 3.24.24 and it's working fine, so... beats me. libGL.so comes from libgl1 1.3.2.
Are you running on a Pi 4 by any chance? What does "glinfo | head -1" show?
Pi 4 seems to run OpenGL 2.1 by default. If I run "MESA_GL_VERSION_OVERRIDE=2.1 ./xdaliclock" then it gets much further, and creates an XDaliClock window which just says "Unable to create a GL context". I will poke more at it later.
1.8GHz Pi 4b r1.4 4GB Debian 11.4. I do not have "glinfo" and "eglinfo" doesn't seem to say anything useful.
Just in case this helps someone else stumbling upon it: some more searching leads me to believe that since this code is using GtkGLArea with older OpenGL versions, it means that GTK+ 3.20 or later is needed.
What leads you to believe that? I can make the configure script demand that version if we're sure it's true. But since you said "older GL versions" probably the right answer is to slightly update my GL code. There's almost none of it and all it does is "load this texture and paint it on an unprojected quad".
Things like https://mail.gnome.org/archives/gtk-list/2016-December/msg00046.html and https://stackoverflow.com/questions/37909072/ and other search results for 'GtkGLArea "unable to create a gl context"' made me think that.
If using a later OpenGL API is not too hard, then that'd probably work. But I am far from an expert in these matters.
As one of the world's foremost experts on OpenGL compatibility issues, I can assure you that nobody has any fucking idea!
> The Makefile wants to run update-icon-caches, which is not a command I have. There is /usr/bin/gtk-update-icon-cache, but it also needs the --ignore-theme-index option.
FWIW, Slackware 15, which is somewhat newer, also doesn't have "update-icon-caches" and does have "gtk-update-icon-cache". This is "gtk+3-3.24.31".
Slackware 15.0, gtk+3 3.24.31, mesa 21.3.5, Intel video driver
"make install" in "X11" bombs out:
Once I make that directory, it installs fine, although I get ignored errors on the icon-cache thing.
I get the same errors reported elsewhere by andy:
Also as reported by andy, "MESA_GL_VERSION_OVERRIDE=3.1 xdaliclock" works.
My bad, the MESA_GL_VERSION_OVERRIDE is suggested by chipaca.
If you didn't have that "schemas" directory, that suggests that you had zero programs installed that use GSettings, which sounds unpossible. This makes me think that the directory is wrong, but if so, it shouldn't launch at all. Is there some other directory on your system that contains files like "gschemas.compiled" and "org.gtk.Settings.FileChooser.gschema.xml"?
I had such a directory in /usr/share/glib-2.0 but not in /usr/local/share.
I did mkdir -p glib-2.0/schemas in /usr/local/share and then both make install and xdaliclock were happier (but not actually happy, as per above).
So are you saying that /usr/share/glib-2.0/gschemas.compiled existed, and that dir also contained a bunch of XML files?
I'm pretty sure that yes, he is saying that, and I'm saying that too.
FreeBSD:
[/usr/local/share/glib-2.0/schemas]:core{229}% uname -a FreeBSD core 13.1-RELEASE FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC amd64 [/usr/local/share/glib-2.0/schemas]:core{230}% ls -l gschemas.compiled -rw-r--r-- 1 root wheel 45588 Jul 11 16:15 gschemas.compiledLeenoox (my office machine):
The Linux world seems to have developed a peculiar idea of what "/usr/local" means.
For FreeBSD (and other flavors), anything which is not part of the OS goes in /usr/local.
For Linux, anything that you compiled yourself (i.e. your own "locally built software) goes in /usr/local.
With FreeBSD, the OS is defined by what you get if you do "cd /usr/src; make world" . That includes just the FreeBSD kernel and userland.
It does _not_ include X11, Wayland, GL, Mesa, GNOME, KDE, GLIB, GTK, Qt, Perl, or even Python. Those are all packages you can install _after_ you install FreeBSD itself.
With Linux, all those things are considered part of the "the distro" along with everything else. They're still broken up into eparate packages, but everything goes under /usr.
So yeah: Linux has /usr/share, not /usr/local/share. Sorry. :/
Note that I'm accustomed to the idea of being able to do "configure --prefix=/some/other/install/path" with all the things I compile separately, because sometimes I build newer versions of software from source that I also already have installed as a package. If for example I already have the existing FreeBSD xdaliclock package installed, there will already be a /usr/local/bin/xdaliclock binary. This binary is also managed by the FreeBSD package system, and the only way I would expect to replace it would be via "pkg upgrade."
That being the case, I would prefer keep any locally-built version rooted in a separate path, created under my own user ID, rather than clobber things in /usr/local/bin, like an *animal*.
That said, it sounds doesn't sound like GTK expects there to only be one schemas directory, so this strategy probably wouldn't work, even if the configure script did handle the --prefix flag correctly (which it currently doesn't).
Dumpster fire indeed.
Well, having read that I still don't have the slightest clue how I should portably set $gsettingsschemadir to something that will work. I am open to suggestions.
$datadir is $prefix/share, and $GTK_DATADIR comes from "pkg-config --variable=prefix gtk+-3.0" plus "share".
If I pick a directory that is not already on the system's search path for such things, the app won't launch. And I don't know how to tell what that search path is.
On Debian 11, including Raspbian, /usr/share/glib-2.0/schemas/ pre-exists, and it is the only directory named "schemas" on the system. Likewise it is the only place that a gschemas.compiled file exists.
I tweaked configure.ac which seemed inordinately complex. Note the schemasdir, which I tweaked Makefile.am to use.
Thanks, I didn't realize that PKG_CHECK_MODULES existed.
But "inordinately complex" is the current Linux party line that the proper way to build things is autoreconf Makefile.am → automake Makefile.in → make Makefile, emitting a thousand lines of code so obtuse that it might as well be minimized.
No wonder everyone's like:
Sure, Martha.
That manually-maintained X11/Makefile.in is a long-haired wombat with dreadlocks and doesn't create nonexistent directories when installing and doesn't even respect DESTDIR. I'm no autotools fan, but come on. Modern autotools allows you to just go "autoreconf --install; ./configure; make" and completely ignore the existence of eldrich horrors like aclocal and automake and autoconf burbling below.
Sure, if being able to read the generated Makefile to figure out what went wrong is a non-goal for you.
In 5 years there will be yet another layer on top of this that generates .am files, mark my words.
I survived IMake, I know how this story goes.
JWZ, you have been found guilty of seventeen individual crimes against human dignity, of the desecration of all that our society finds wholesome, and of the most foul of debaucheries. This court hereby sentences you to read a generated Makefile.in!
Well, it doesn't appear to be documented anywhere, but on Raspbian, Debian and MacPorts, /usr/share/glib-2.0/schemas, /usr/local/share/glib-2.0/schemas and $HOME/.local/share/glib-2.0/schemas seem to be on the default search path. And on MacPorts, /opt/local/share/glib-2.0/schemas is as well. So I guess I can just use $prefix.
I haven't tested whether this also follows for /usr/share/pixmaps and /usr/share/applications, but I'm just gonna assume yes.
/usr/share/glib-2.0/gschemas.compiled doesn't exist.
/usr/share/glib-2.0/schemas/gschemas.compiled does, and /usr/share/glib-2.0/ also contains a bunch of XML files.
mkdir -p /usr/local/share/glib-2.0/schemas allowed make install to complete and xdaliclock to run, although both had errors, as reported above.
To clarify, before you did "make install" for xdaliclock,
I apologize for the typo.
In re: your comment on you're not sure what you can do about the search path for schemas, when xdaliclock got its XML put into /usr/local/share/glib-2.0/schemas/, that was apparently on the search path, because it ran. It then crashed, but it ran, which, as you well know and explained in the program, it wouldn't do without the make install.
Does adding this to xdaliclock_app_window_init fix it?
gtk_gl_area_set_use_es (priv->glarea, TRUE);
That API call is only in gtk 3.22+, so I can't test it.
So, it works fine for me without that on both macOS XQuartz and on Raspbian 11.4 on a Pi 4b; but it was failing for me on a Debian 11.3 x86 under Virtualbox. On that system, adding that call fixed it. I added this to gl_realize_cb (a bunch of API calls that you also do not have):
gtk_gl_area_make_current (area); GdkGLContext *ctx = gtk_gl_area_get_context (area); gboolean fwd = gdk_gl_context_get_forward_compatible (ctx); gboolean es = gdk_gl_context_get_use_es (ctx); gboolean leg = gdk_gl_context_is_legacy (ctx); int maj = -1, min = -1, rmaj = -1, rmin = -1; gdk_gl_context_get_version (ctx, &maj, &min); gdk_gl_context_get_required_version (ctx, &rmaj, &rmin); fprintf (stderr, "%s: fwd=%d es=%d leg=%d v=%d.%d req=%d.%dn", progname, fwd, es, leg, maj, min, rmaj, rmin);Mac and Pi: use_es has no effect on any of those flags:
xdaliclock: fwd=0 es=0 leg=1 v=2.1 req=3.2
Debian without use_es shows this, and fails:
xdaliclock: fwd=0 es=0 leg=0 v=4.5 req=3.2
Doing use_es changes version (but not es) and makes things work:
xdaliclock: fwd=0 es=0 leg=1 v=3.1 req=3.2
Also -- fun -- on Debian, calling gdk_gl_context_set_required_version (ctx, 3, 1) (or 2, 1) right after creating the GdkGLContext does not change v from 4.5. Only use_es does that.
That fixes the crash for me on Debian testing.
I'll put a prelim packaging (since I'm not the actual maintainer) on salsa, including reworked configure.ac and Makefile.am to make DESTDIR work and stuff like that.
Confirmed on Debian 11.4 - it stops the crashing and the app works as expected (except for xscreensaver as noted in release notes).
I'm getting:
That might just be my setup though.
I'm getting the same (without the newlines). However
works. I don't know what it does but somebody else mentioned it and I tried it and hey.
Trying to be a little more helpful,
setting
makes it work (glxinfo says “OpenGL version string: 4.6”; whether that version and this environment variable are the same thing I don't know).
Some of those glTexImage2D errors might be expected, because one of the things it tries to do is back off the texture size if it fails. However, probably all of them are failing.
And I wouldn't bet on whether it is trying to say "GL_LUMINANCE_ALPHA is no good" or "the texture is too big".
Configures and compiles find without warnings on Debian 11.4, but chokes on execution with :
xdaliclock: GL error in glTexImage2D #0 2048x512: invalid valuexdaliclock: GL error in glTexImage2D #1 1024x256: invalid valuexdaliclock: GL error in glTexImage2D #2 512x128: invalid valuexdaliclock: GL error in glTexImage2D #3 256x64: invalid valueAborted (core dumped)
My web-search-fu is usually pretty good - but I'm not seening anything usefull yet. My guy reaction is it's something to do with the NVIDIA binary drivers I'm using - but xscreensaver doesn't seem to have an issue with them, so IDKWTFBBQ.
s/find/fine/g; s/guy/gut/g;
Apparently didn't scroll the thread far enough - mea culpa.
However, setting MESA_GL_VERSION_OVERRIDE to any value doesn't help
I pushed a fix to salsa.debian.org/bap/xdaliclock
Can't use the debian package bundling since "Autoconf version 2.71 or higher is required" (a testing update I don't have in stable) - but the 0002-gl-crash-fix.patch as applied to the original source works fine.
I didn't test, but I'd imagine it will work with earlier versions of autoconf. The automatic updating scripts put that version there; just remove it.
It works - replacing AC_PREREQ([2.71]) with AC_PREREQ([2.69]) lets the package build process run through to completion.
For those of you having trouble with this: I wonder if GtkGLArea works on your system at all?
Maybe try installing the package "gtk-3-examples" and selecting the "OpenGL Area" sub-program. On my Pi, it runs and displays a triangle, but the sliders don't do anything, and sometimes the window goes black. I don't know what to make of that. Maybe it means that GL is basically functional but there's some problem with shaders.
If there are any other apps (or even demos) that use GtkGLArea, I don't know about them.
Wouldn't it be typical if I was the first person to ever try to use this widget?
The main gtk-3-examples program seems to be "gtk3-demo". On my system, running the "OpenGL Area" demo works and shows a yellow triangle seemingly lit from the bottom of the window, and all 3 axis sliders rotate it in sane-seeming ways. I haven't had the window go black.
Well, that's puzzling.
So I tried this out on my X230 ThinkPad running Arch.
First problem, the `make install` didn't create the parents for the "/usr/local/share/glib-2.0/schemas".
After I ran `mkdir -p /usr/local/share/glib-2.0/schemas/` then re-ran `make install` I could at least run xdaliclock without the gsettings complaint and abort.
The Makefile probably just needs to add -d to the install command for that schemas file to handle systems without any glibc-2.0/schemas under /usr/local.
But then I got this error:
$ /usr/local/bin/xdaliclock
xdaliclock: GL error in glTexImage2D #0 2048x512: invalid valuexdaliclock: GL error in glTexImage2D #1 1024x256: invalid valuexdaliclock: GL error in glTexImage2D #2 512x128: invalid valuexdaliclock: GL error in glTexImage2D #3 256x64: invalid valueAborted (core dumped)
And I haven't spent any time digging into the code to work around this yet. My system runs OpenGL stuff just fine however, but I haven't done any explicit testing of GTK3's GL widget stuff yet.
`install -D` that is, so it creates the parents if missing.
I'm no OpenGL expert, but at a glance window.c seems to be written in using the old-fashioned fixed-function API. I'd probably be targeting OpenGL 2.1 with this code as-is not 3.x or newer.
As chipaca noted, running with the 2.1 override overcomes the GL errors:
`$ MESA_GL_VERSION_OVERRIDE=2.1 ./xdaliclock`
Is confirmed to make it work here on Arch.
Just get the schemas directory created when missing and it's mostly fine. There's probably something to be done in the code to say it's targeting OpenGL 2.1 so the manual override isn't needed.
I've only ever programming OpenGL via SDL, and there you specify the OpenGL version desired via calls like:
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 2);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 1);
Before creating the GL context.
Presumably there's something similar for whatever's creating the window/GL context in xdaliclock, GTK+ perhaps?
As far as I can tell, there is not.
Keep the speculation to a minimum, please.
https://docs.gtk.org/gtk3/method.GLArea.set_required_version.html
You're welcome.
Hey guess what, I tried that, it does nothing.
Aaaaaand when actually added to the code, this is the runtime error it produces:
(xdaliclock:217846): Gdk-WARNING **: 19:58:32.425: gdk_gl_context_set_required_version - GL context versions less than 3.2 are not supported.
Looks like either modernize the GL code or rely on the MESA override are the two paths forward :/.