| 01:32.51 | *** join/#qi-hardware sandeepkr_ (~Sandeepkr@103.49.155.114) |
| 03:39.14 | *** join/#qi-hardware _whitelogger (~whitelogg@uruz.whitequark.org) |
| 03:39.14 | *** mode/#qi-hardware [+v _whitelogger] by ChanServ |
| 05:08.11 | *** join/#qi-hardware DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 18:27.00 | *** join/#qi-hardware infobot (ibot@rikers.org) |
| 18:27.00 | *** topic/#qi-hardware is Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben/atusb 802.15.4 wireless, anelok and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs and http://irclog.whitequark.org/qi-hardware |
| 18:27.00 | *** mode/#qi-hardware [+v infobot] by ChanServ |
| 18:36.25 | whitequark | wpwrak: *grumble* you people and your crufty distros |
| 18:39.01 | whitequark | wpwrak: actually, no, scratch that. |
| 18:39.05 | whitequark | (solvespace:916): Gdk-WARNING **: gdk_gl_context_set_required_version - GL context versions less than 3.2 are not supported. |
| 18:39.12 | whitequark | you'll just have to deal with it |
| 18:39.40 | wpwrak | 3.2(0) is fine for me ;-) |
| 18:39.56 | whitequark | no, you don't get it |
| 18:40.12 | whitequark | GTK prior to 3.22 *requires* the use of an OpenGL 3.2+ core profile |
| 18:40.28 | whitequark | this would require me to rework everything to use VBOs/VAOs, which ANGLE doesn't support |
| 18:40.49 | whitequark | this is totally a fuckup on the part of GTK that shows a complete lack of awareness of real-world software |
| 18:42.50 | wpwrak | #103 hmm, any good work-around ? .slvs looks a bit like a slightly pretty-printed memory dump |
| 18:43.37 | wpwrak | ah, i see. library dependency hell. |
| 18:44.45 | whitequark | kinda. |
| 18:44.48 | wpwrak | (naming) yeah, i mean as the next level, when you can't quite figure out what is what. basically a way to leave breadcrumbs, to find your way out of the maze of interrelated objects |
| 18:45.03 | whitequark | this is *also* a fuckup on the part of OpenGL, which are even more divorced from the needs of developers |
| 18:45.11 | whitequark | basically, I hate everyone involved |
| 18:45.39 | wpwrak | (sluggish) just seems odd that dragging a line on an otherwise empty backgruond would already be very slow. i could imagine that happening with some major model in the background. |
| 18:45.47 | wpwrak | ;-)) |
| 18:46.07 | wpwrak | split 2D editing and 3D rendering ? :) |
| 18:46.13 | whitequark | hm? |
| 18:46.14 | whitequark | no |
| 18:46.23 | whitequark | this has nothing to do with geometry itself |
| 18:46.42 | whitequark | the latency is constant and the result of me having to manually flip framebuffers through X11 |
| 18:46.52 | whitequark | this is /literally the thing the newer gtkglarea is fixing/ |
| 18:47.37 | wpwrak | (flipping) i see. |
| 18:48.30 | whitequark | do you have huge monitors too? |
| 18:48.37 | whitequark | and perhaps not that high-end CPU? |
| 18:50.01 | wpwrak | monitors are just 1920x1080. cpu is q6600. new ones still have about the same clock speed and number of cores ;) |
| 18:50.07 | whitequark | mhm, weird |
| 18:50.34 | wpwrak | (thogh they probably now execute a dozen instructions per cycle :) |
| 18:50.39 | whitequark | I also have full-hd and probably a less-powerful CPU |
| 18:50.44 | whitequark | nah |
| 18:50.51 | whitequark | newer ones have lower TDP primarily |
| 18:52.12 | whitequark | and wider SIMD registers |
| 18:52.55 | wpwrak | line dragging is just strangely slow. about 1 s latency. |
| 18:53.44 | whitequark | whaaaat? |
| 18:53.47 | wpwrak | (that's move mouse, wait until the line moves, then repeat. so system latency is maybe half that) |
| 18:53.51 | whitequark | that makes no sense at all |
| 18:54.03 | wpwrak | toldya :) it's SLOW. |
| 18:54.04 | whitequark | there's absolutely no way it should or even can take 1s |
| 18:54.11 | whitequark | well try it on 3.22 first. |
| 18:54.29 | whitequark | I am absolutely not supporting the horrible framebuffer flipping hack anymore in any way, shape or form |
| 18:54.30 | wpwrak | wish i had that :) |
| 18:54.36 | whitequark | hm |
| 18:54.44 | whitequark | does 2.3 also have the roblem? |
| 18:55.02 | wpwrak | how would i test that ? |
| 18:55.18 | whitequark | uhm, build solvespace 2.3? or install it from debian, assuming it's there already |
| 18:56.28 | wpwrak | tag v2.3 is good ? |
| 18:56.46 | whitequark | yup, exactly what you need |
| 18:57.44 | wpwrak | whee. cmake doesn't hate me for trying that :) |
| 18:59.27 | whitequark | I can't in good faith call cmake "decent" but it does handle many basic cases |
| 18:59.41 | whitequark | which is more than can be said about most other build systems |
| 19:00.55 | wpwrak | 2.3 is much faster. still lags a little, but maybe 100 ms at most. |
| 19:09.06 | whitequark | hm, interesting |
| 19:09.16 | whitequark | does 3.0 consume 100% of CPU? |
| 19:09.56 | whitequark | it's "interesting" because I'm pretty sure my system is slower than yours |
| 19:11.25 | wpwrak | solvespace about 50%, X11 about 85% (quad core) |
| 19:11.34 | whitequark | riiiiight |
| 19:11.40 | whitequark | I know what happens, ok |
| 19:11.46 | whitequark | wpwrak: ok so a shot in the dark |
| 19:11.59 | wpwrak | the lag also depends on distance |
| 19:12.01 | whitequark | can you check out master and replace set_use_es(true) with set_required_version(4, 0) in both cases |
| 19:12.09 | wpwrak | lemme upload two videos. just a sec ... |
| 19:14.35 | whitequark | yeah I'm pretty sure that "fix" will work |
| 19:18.14 | wpwrak | v2.3, small lag: http://downloads.qi-hardware.com/people/werner/slvs/line-lag-v23.mp4 |
| 19:18.38 | wpwrak | "v3.0" using gtkmm 3.20, massive lag: http://downloads.qi-hardware.com/people/werner/slvs/line-lag-v30.mp4 |
| 19:19.59 | whitequark | yeah, that's an event queueing issue |
| 19:28.35 | whitequark | wpwrak: so, have you tried set_required_version on your hw? |
| 19:31.40 | wpwrak | lemme try ... |
| 19:34.30 | wpwrak | there's no set_use_es in the version i use |
| 19:34.44 | wpwrak | and if i try master, it fails the >= 3.22 dependency check |
| 19:35.24 | whitequark | > can you check out master and replace set_use_es(true) with set_required_version(4, 0) in both cases |
| 19:35.29 | whitequark | oh |
| 19:35.30 | whitequark | sorry |
| 19:35.34 | whitequark | just remove the dependency check |
| 19:35.46 | whitequark | cmake tells you on which line it is |
| 19:36.50 | wpwrak | compiling ... |
| 19:37.11 | wpwrak | (changed the check to >= 3.20) |
| 19:40.06 | wpwrak | mmh. crashes on start. lemme find a pastebin ... |
| 19:41.03 | wpwrak | https://0bin.net/paste/C4BYHLVLdYvHtAeZ#f3oz8EhYctF+cTURz1KHTMXCcu48QCb8LPz6dNkWzph |
| 19:41.34 | whitequark | hmm |
| 19:42.20 | whitequark | wpwrak: please rerun with G_DEBUG=fatal_warnings |
| 19:42.34 | whitequark | it will crash earlier and in a more informative way |
| 19:43.28 | wpwrak | hmm. https://0bin.net/paste/odCswYryWvfVrKf7#w+L9UTk-7DDzmSRhfwIEZYmIStLYY0BNrX8fTQoTb12 |
| 19:44.02 | wpwrak | stack trace: https://0bin.net/paste/462bVQgGXqVkHNZW#pjzgTr0HvQk1SWNcqzNBP9iaUSl-luAgGbYyMLNz6pk |
| 19:44.17 | whitequark | wpwrak: btw to get debug symbols use cmake . -DCMAKE_BUILD_TYPE=Debug |
| 19:44.26 | whitequark | (you don't need to rm the build dir, just rerun make then) |
| 19:44.39 | whitequark | aha |
| 19:44.59 | whitequark | wpwrak: please rerun with LIBGL_DEBUG=1 MESA_DEBUG=1 |
| 19:45.14 | whitequark | ... I should add that in README somewhere. |
| 19:47.30 | wpwrak | btw, you may find the little trick i used in eeshow useful: eeshow gdb args... is like eeshow args... but runs everything under gdb: call to run_under_gdb in https://neo900.org/git/eeshow/tree/main/eeshow.c |
| 19:47.37 | wpwrak | and https://neo900.org/git/eeshow/tree/main/common.c |
| 19:47.48 | whitequark | wpwrak: you don't need that |
| 19:47.53 | whitequark | gdb --args eeshow ... |
| 19:47.59 | whitequark | has the exact same behavior |
| 19:48.27 | wpwrak | yes, that's what i use :) |
| 19:48.30 | DocScrutinizer05 | (([2017-01-13 Fri 18:51:48] <whitequark> (sluggish) why exactly do you think I bumped the requirement to gtk 3.22? :D)) maybe rate-limit redraws to 20/s? |
| 19:48.53 | whitequark | DocScrutinizer05: ugh |
| 19:49.00 | whitequark | let's make experience worse for *everyone* instead |
| 19:49.48 | wpwrak | whitequark: https://0bin.net/paste/+IgnQCsuQy1REN-C#SHTN2Oj-bEZ76i2S7pokiVlKko9oKTBL+xsaqSpm3LQ |
| 19:50.47 | wpwrak | a redraw limit could help if it was an issue of an excessively long queue. i've seen such things. but, apparently that's not the issue here. |
| 19:50.57 | whitequark | wpwrak: oh wait, are you using nvidia? |
| 19:51.24 | DocScrutinizer05 | whitequark: maybe I'm wrong about what it does, but it seems pretty insane to redrew for every dot of change of mouse position, of a mouse with possibly 1200dpi |
| 19:51.47 | whitequark | DocScrutinizer05: it doesn't do a redraw for *every* change |
| 19:51.55 | whitequark | it's locked to vsync of your monitor, as it should be |
| 19:51.55 | wpwrak | whitequark: glxinfo -> OpenGL renderer string: Gallium 0.4 on AMD RV610 (DRM 2.46.0 / 4.8.0-30-generic, LLVM 3.8.1) |
| 19:52.01 | whitequark | wpwrak: ohhhhh |
| 19:52.04 | DocScrutinizer05 | reducing redraw to a sane rate limit makes sense |
| 19:52.31 | DocScrutinizer05 | aah vsync *is* a sane rate limit |
| 19:52.39 | DocScrutinizer05 | :-) |
| 19:52.43 | whitequark | yup |
| 19:52.52 | wpwrak | it's either a Radeon HD 6450 or Radeon HD 2400 |
| 19:52.52 | whitequark | no point to ever render at rate more than vsync |
| 19:53.03 | wpwrak | i have both, but don't remember which is on which monitor |
| 19:53.05 | whitequark | well in a CAD application, in games there are a few niche cases |
| 19:54.01 | wpwrak | e.g., benchmarks ;-) |
| 19:54.42 | whitequark | no, I mean stuff like trying to smoothe movement |
| 19:54.54 | whitequark | it makes sense to render too many frames then blur fast-moving parts |
| 19:55.45 | wpwrak | heh, deluxe mode ;-) |
| 19:56.24 | DocScrutinizer05 | smart |
| 19:56.39 | whitequark | yeah, that's a very rare technique and not even necessarily the best way to imlement this |
| 19:58.21 | whitequark | wpwrak: can you show me the complete glxinfo outupt |
| 19:58.24 | DocScrutinizer05 | well, it sort of emulates the shutter-open time of conventional (film) cameras |
| 19:58.48 | DocScrutinizer05 | a real camera always integrates over a time window |
| 20:00.03 | wpwrak | whitequark: https://0bin.net/paste/V7+cJZhK2ZHamls9#kSbIyJ0xgSQjhHOFm6lxqQJWKWnUTYGnHUoHcnKYY4Q |
| 20:00.08 | DocScrutinizer05 | admittedly very smart cameras (and electronic cameras) can adjust the otherwise fixed ratio of 50% open 50% shut per each frame of the 24 frames of a movie |
| 20:01.00 | whitequark | wpwrak: that actually looks like it ought to work |
| 20:01.02 | whitequark | hmm |
| 20:01.08 | whitequark | maybe the bug is something else |
| 20:04.02 | DocScrutinizer05 | funny fact: film projectors interrupt each frame and make it two flashes of light, to get from 24Hz to 48Hz while framerate is still 24fps |
| 20:05.13 | DocScrutinizer05 | TV interlaced has basically same reason |
| 20:07.36 | DocScrutinizer05 | all obsolete in time of LCD monitors |
| 20:08.34 | DocScrutinizer05 | Plasma displays however... ;-D |
| 20:12.51 | DocScrutinizer05 | haha 0bin is a smart concept |
| 20:13.04 | whitequark | wpwrak: basically can you try commenting stuff out until you get an interesting crash? |
| 20:13.14 | whitequark | the body of RefreshRecentMenus is a good 1st candidate |
| 20:13.28 | whitequark | theres something fucky going on with the GTK widget initialization order but I don't understand what it is |
| 20:16.21 | whitequark | wpwrak: hang on. |
| 20:17.01 | whitequark | does that use your DISPLAY_TEXTWND hack? |
| 20:17.27 | whitequark | is it enabled during the crash, that is? |
| 20:17.34 | wpwrak | no, it's plain "master" |
| 20:17.37 | whitequark | ok |
| 20:17.53 | whitequark | does it crash somewhere else oncey ou comment out the body of RefreshRecentMenus |
| 20:17.56 | whitequark | ? |
| 20:19.14 | wpwrak | commented out body of RefreshRecentMenus: https://0bin.net/paste/gdOResU6L5XvmmlJ#XoUrqETi7+1jx8gtsg2k2bgHf4Q59YEucreXq3pL+mZ |
| 20:19.54 | whitequark | why... why does it break with menus specifically |
| 20:21.12 | wpwrak | if you s/set_use_es(true);/set_required_version(4, 0);/ locally, it works ? |
| 20:21.35 | whitequark | yes |
| 20:21.45 | whitequark | the question is whether your mesa will support it |
| 20:21.55 | whitequark | but I'm getting some really bizarre crashes |
| 20:21.59 | wpwrak | apparently not without a fight :) |
| 20:22.06 | whitequark | can you do `export LANG=en_US.UTF-8` |
| 20:22.31 | wpwrak | i currently have LANG=C |
| 20:22.48 | whitequark | really? |
| 20:22.54 | whitequark | $ LANG=C ./bin/solvespace |
| 20:22.54 | whitequark | Sorry, only UTF-8 locales are supported. |
| 20:24.09 | wpwrak | interesting. LANG=en_US.UTF-8 did something ... white canvas (with menu bar on top) with "OpenGL context creation failed" |
| 20:25.00 | whitequark | ok. two separate bugs, then. |
| 20:25.30 | wpwrak | (LANG=C works here. maybe it's some interactino with LC_CTYPE=en_US.UTF-8 that makes it work. or such. that i18n stuff is confusing.) |
| 20:25.52 | wpwrak | btw, the above is still with RefreshRecentMenus body commented out |
| 20:26.30 | whitequark | the POSIX locales are a disaster |
| 20:26.42 | whitequark | Windows locales work (it's a single LCID number more or less) |
| 20:26.46 | wpwrak | enabling the body produces the same result |
| 20:26.48 | whitequark | macOS locales work (it's a single ISO locale name) |
| 20:26.57 | whitequark | POSIX locales... just give me some rope |
| 20:27.30 | wpwrak | i saw that you also take extensive precautions to keep . from becoming , and such :) |
| 20:27.40 | whitequark | indeed |
| 20:28.29 | whitequark | wpwrak: can you show me the output of `locale` on your system, so I could fix the other bug |
| 20:28.51 | whitequark | I haven't managed to coerce solvespace into crashing like that, even though I know in principle which code path it takes on your machine |
| 20:33.56 | wpwrak | locale: https://0bin.net/paste/Sepco-kIow1yY8iU#S4lhyiwDYFNgRasrWNpiTYDnTte-ioyDgkgJRPJQTaj |
| 20:34.19 | wpwrak | in C i trust :) |
| 20:43.21 | whitequark | wpwrak: I had to do: export LANG=C LC_CTYPE=en_US.UTF-8 LANGUAGE= |
| 20:43.32 | whitequark | you have to specifically set LANGUAGE= to an empty string. apparently. |
| 20:46.21 | wpwrak | export LANGUAGE= without anything else (i.e., still LANG=C) has no effect here (except for putting LANGUAGE in the environment) |
| 20:47.21 | whitequark | wpwrak: then I just have no idea how you've managed to achieve this |
| 20:47.24 | whitequark | anyway I fixed it |
| 20:49.00 | wpwrak | (no idea) there are some avenues of knowledge that may be better left unexplored, and i have a strong feeling than i18n/l10n are of that kind :) |
| 20:49.10 | whitequark | wat? |
| 20:49.22 | whitequark | have you considered that not everyone speaks English |
| 20:49.42 | wpwrak | oh, do it in the application if you must |
| 20:49.46 | whitequark | anyway, the only reason POSIX i18n is so bad is because it was written by people with this attitude |
| 20:49.52 | wpwrak | or use pretty icons ;-) |
| 20:50.18 | whitequark | using solid engineering practices almost entirely eliminates the pain in i18n |
| 20:50.28 | whitequark | I know this because *SolveSpace has i18n* |
| 20:50.40 | wpwrak | as i said, do it in the application, not libc |
| 20:50.45 | whitequark | oh |
| 20:50.57 | whitequark | yeah, I agree entirely |
| 20:51.27 | whitequark | personally I would prefer libc to be split into "libposix", something that has malloc, open, socket, etc |
| 20:51.39 | whitequark | and then libc proper, which has all the rest of the junk like string manipulation |
| 20:51.58 | whitequark | for one this would let sane people, i.e. those not using C, to avoid having to link to libc and drag in all the junk |
| 20:52.26 | whitequark | ... there's also an argument to be made about glibc |
| 20:52.35 | whitequark | for example, did you know glibc actually *has a copy of gettext*? |
| 20:52.52 | whitequark | it doesn't just implement all the garbage POSIX requires, it goes above and beyond! |
| 20:53.22 | whitequark | naturally, this also means the source of gettext has all kinds of hairy stuff to make it e.g. threadsafe, but only when a part of libc... |
| 20:53.45 | DocScrutinizer05 | what's wrong with POSIX locales? |
| 20:53.47 | whitequark | ... and this is why I've the gettext runtime reimplemented from scratch in SolveSpace |
| 20:54.20 | whitequark | DocScrutinizer05: 1) people rely on printf/scanf as a general-purpose string-formatting and string-parsing functions |
| 20:54.26 | wpwrak | glibc is a bit like how they did early GMOs: set up a field with test plants, put a radiation source, wait, see what happened, if the result looks sellable, multiply and prosper |
| 20:54.41 | whitequark | this is wrong, but it is a fact of life and a result of C not providing decent parsing facilities |
| 20:54.50 | whitequark | 2) look at the locales themselves |
| 20:55.04 | whitequark | it's insane that there are so many different knobs to turn |
| 20:55.11 | whitequark | why are LC_* individually settable? |
| 20:55.42 | whitequark | why is there no variant of e.g. isdigit that is *not* affected by locale? |
| 20:55.43 | wpwrak | why does the dominatrix have different types of whips in the dungeon ? ;-) |
| 20:55.49 | whitequark | lol wpwrak |
| 20:55.50 | DocScrutinizer05 | hmm i'm pretty happy with using e.g. english text but ISO dates |
| 20:56.03 | whitequark | DocScrutinizer05: there's no argument this should be possible |
| 20:56.31 | whitequark | the way it should be possible is by writing a file that says how your en_US-DocScrutinizer locale works |
| 20:56.39 | whitequark | it's unambiguous and simple |
| 20:56.49 | whitequark | instead you have this Lovecraftian horror |
| 20:57.47 | DocScrutinizer05 | there's actually also no sane argument for american date format |
| 20:58.12 | whitequark | well, yes, but we unfortunately can't wish americans out of existence, so... |
| 20:58.16 | DocScrutinizer05 | I agree on the horror aspect though |
| 20:58.45 | whitequark | I would also prefer no human being used an ideographic writing system |
| 20:59.04 | DocScrutinizer05 | hm? |
| 20:59.28 | DocScrutinizer05 | example please |
| 20:59.51 | whitequark | high-quality support for hanzi and kanji is really hard to do |
| 21:00.02 | DocScrutinizer05 | aaah that, yeah |
| 21:00.21 | whitequark | like for example, input methods are primarily why solvespace bothers with GTK |
| 21:00.25 | DocScrutinizer05 | what *really* sucks is coma vs dot for decimal |
| 21:00.27 | whitequark | GTK input boxes integrate with the system IME |
| 21:00.36 | DocScrutinizer05 | comma* |
| 21:00.43 | whitequark | so you can input Chinese if you want using the same tool you usually use |
| 21:00.58 | whitequark | yeah, that's nasty |
| 21:01.14 | whitequark | I've recently made the numpad dot always enter a dot in solvespace |
| 21:01.20 | whitequark | even if it's set to comma on your keyboard layout |
| 21:01.25 | DocScrutinizer05 | cooooool |
| 21:02.15 | DocScrutinizer05 | still searches for a decent generic versatile keyboard handler that can even do macros |
| 21:02.38 | DocScrutinizer05 | redefine keys "on the fly" |
| 21:02.50 | DocScrutinizer05 | record and playback macros |
| 21:03.58 | DocScrutinizer05 | just define ONE special "escape key" to switch to keyboard handler communication |
| 21:04.14 | DocScrutinizer05 | capslock comes to mind |
| 21:04.32 | whitequark | heh |
| 21:04.46 | DocScrutinizer05 | or numlock |
| 21:05.09 | whitequark | wpwrak: I figured out why setting version to 4.0 works on my machine. |
| 21:05.09 | wpwrak | before the "Windows" key was added, Caps Lock had the crown of most useless key ever for ages |
| 21:05.24 | whitequark | that's because setting version to 4.0 through gtk actually sets it to *2.0* in the request to glX |
| 21:05.35 | wpwrak | heh :) |
| 21:05.45 | whitequark | what the actual fuck? |
| 21:05.55 | DocScrutinizer05 | LOL |
| 21:06.09 | wpwrak | well, it preserved the .0 part pretty accurately |
| 21:06.56 | DocScrutinizer05 | btw s/keyboard handler/input handler/ |
| 21:07.09 | whitequark | wpwrak: if I ask for 4.1 I still get 2.0 |
| 21:07.15 | DocScrutinizer05 | glares at his MX500 12 button mouse |
| 21:07.22 | whitequark | this is extremely stupid because I CANNOT request a 2.0 context from GTK |
| 21:07.51 | whitequark | the ONLY reason this works is a bug in gtk 3.22, which I presume is not present in 3.20, or it would have worked on your system |
| 21:08.34 | whitequark | wpwrak: *sigh* let's try one more thing |
| 21:08.52 | DocScrutinizer05 | oh and when you complain about locale horror, never look into input driver layers horror! |
| 21:10.24 | DocScrutinizer05 | I never managed so far to start reading about what's been sent via e.g. USB to PC from mouse/kbd and then read "upward" through layers til X-Event to an X11 program and still remember about the first layer and how it worked |
| 21:12.29 | whitequark | wpwrak: you have gtk 3.20, right? |
| 21:12.32 | whitequark | not 3.18 even? |
| 21:15.56 | wpwrak | yes, 3.20: https://0bin.net/paste/-3j6+gnDxCvzUpDX#CvQbuVB6uKJpGA7oD6XHQCs1Ol98yG2cAV11oQTvylb |
| 21:16.59 | DocScrutinizer05 | sorry for OT, but for fun about kbd and how it works, refer to http://homepages.cwi.nl/~aeb/linux/kbd/scancodes-8.html |
| 21:32.14 | DocScrutinizer05 | >>bit 1 A20 0: A20 line is forced 0, 1: A20 enabled << LOL |
| 21:32.47 | whitequark | wpwrak: so I WANTED to use https://github.com/GNOME/gtk/blob/master/gdk/gdkglcontext.c#L1030 |
| 21:33.01 | whitequark | but that would be too easy right? turns out it's a private, totally inaccessible API |
| 21:33.59 | wpwrak | can't you just call it ? |
| 21:35.14 | whitequark | nope. |
| 21:35.16 | whitequark | it's not exported. |
| 21:35.26 | whitequark | it's not even present in the symbol table. |
| 21:35.39 | wpwrak | oh, crafty |
| 21:39.07 | whitequark | wpwrak: https://github.com/GNOME/gtk/blob/gtk-3-20/gdk/x11/gdkglcontext-x11.c#L640 |
| 21:39.22 | whitequark | unless you can coerce it into setting legacy_bit=TRUE it is a total loss. |
| 21:41.52 | wpwrak | probably not a good idea to depend on locally hacked libraries ... |
| 21:42.11 | whitequark | exactly |
| 21:42.56 | wpwrak | so it gtkmm >= 3.22 still the way forward, eventually ? or will doom await there, too ? you mentioned that the magic translation that makes things work is a "bug" ... |
| 21:43.12 | whitequark | nah, gtk>=3.22 is fine |
| 21:43.27 | whitequark | they allow me to request a GL ES context, which is the proper way to do what I want |
| 21:43.38 | whitequark | and I think even NVidia supports it these days |
| 21:44.18 | whitequark | wpwrak: oooh, so I have an evil ide |
| 21:44.20 | whitequark | (idea |
| 21:50.11 | DocScrutinizer05 | >>Thio Yu Jin <jin@singmail.com> complains that on his Toshiba 4010CDS the Ctrl-Alt-Shift-T key combination brings up the Toshiba user manual. (04 Mar 1999 - not April 1.)<< |
| 21:52.41 | DocScrutinizer05 | epic shit in http://homepages.cwi.nl/~aeb/linux/kbd/scancodes-1.html |
| 21:56.02 | *** join/#qi-hardware sb0 (~lekernel@201.103.3.197) |
| 22:27.55 | whitequark | wpwrak: good news. I have it working on gtk 3.16+. however, the text in the text window is replaced by rectangles. |
| 22:31.00 | wpwrak | all hail the new universal simplified character set ! ;-) |
| 22:34.40 | DocScrutinizer05 | path to font |
| 22:35.59 | whitequark | huh? |
| 22:41.29 | DocScrutinizer05 | I've seen this effect frequently when the dir with fonts wasn't available thanks to a failed mount. Probably other path mismatches have a similar effect as result |
| 22:42.13 | DocScrutinizer05 | where iirc path_to_font even includes stuff like 11PT and intalic, sometimes |
| 22:46.25 | whitequark | I do not use the crappy X font system |
| 23:26.01 | DocScrutinizer05 | well, no idea. rectangles instead chars usually means the char is unknown aka cannot be found in system |
| 23:27.51 | whitequark | I know what happened exactly, I wrote that font renderer... |
| 23:28.54 | DocScrutinizer05 | :-) |