DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #qi-hardware
infobot has quit [Ping timeout: 255 seconds]
pcercuei has joined #qi-hardware
erichvk has joined #qi-hardware
erichvk has quit [Remote host closed the connection]
erichvk has joined #qi-hardware
sandeepkr has joined #qi-hardware
sandeepkr_ has quit [Read error: Connection reset by peer]
sandeepkr_ has joined #qi-hardware
sandeepkr has quit [Ping timeout: 245 seconds]
<wpwrak>
whitequark: btw, is it a known issue that H/V constraints shown while dragging a line (during its construction) don't always match what is taken when you click/hit Esc ?
<wpwrak>
whitequark: and is there a way to get a list of constraints on an item, e.g., a point ? (where it's sometimes nearly impossible to see thruogh the thicket of things attached to it)
<wpwrak>
oh, and why is line dragging to sluggish ? even after "New" the lag feels as if i was dragging around the titanic :)
dandon has joined #qi-hardware
<wpwrak>
and the biggest question of all: if i attached a workplane to the wrong point, but realize that only later, is here a way to move it ? i.e., is there a dialog that lets me manipulate the workplane parameters, such as orientation, and placement ?
<wpwrak>
in complex cases, i guess it may also be useful to be able to name items (lines, points, etc.), such that they could be identified in constraints. i.e., a constraint could say c123-eq-length\n\tline segment "foo"\n\tline segment "bar"
<wpwrak>
would that sound like a reasonable feature request ?
planasb has quit [Ping timeout: 258 seconds]
tumdedum has quit [Ping timeout: 245 seconds]
tumdedum has joined #qi-hardware
<whitequark>
(don't always match what's taken) well, that *should* have been fixed, but yes. I plan to retire that entire feature.
<whitequark>
in favor of a different UI workflow entirely, a more generic one at that
<whitequark>
(list of constraints on an item) nope. easy to add. file an issue.
<whitequark>
(sluggish) why exactly do you think I bumped the requirement to gtk 3.22? :D
<whitequark>
(naming items) it seems far more useful to link to the entities from the constraint, in the text window
pcercuei has quit [Quit: bbl]
infobot has joined #qi-hardware
<whitequark>
wpwrak: *grumble* you people and your crufty distros
<whitequark>
wpwrak: actually, no, scratch that.
<whitequark>
(solvespace:916): Gdk-WARNING **: gdk_gl_context_set_required_version - GL context versions less than 3.2 are not supported.
<whitequark>
you'll just have to deal with it
<wpwrak>
3.2(0) is fine for me ;-)
<whitequark>
no, you don't get it
<whitequark>
GTK prior to 3.22 *requires* the use of an OpenGL 3.2+ core profile
<whitequark>
this would require me to rework everything to use VBOs/VAOs, which ANGLE doesn't support
<whitequark>
this is totally a fuckup on the part of GTK that shows a complete lack of awareness of real-world software
<wpwrak>
#103 hmm, any good work-around ? .slvs looks a bit like a slightly pretty-printed memory dump
<wpwrak>
ah, i see. library dependency hell.
<whitequark>
kinda.
<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
<whitequark>
this is *also* a fuckup on the part of OpenGL, which are even more divorced from the needs of developers
<whitequark>
basically, I hate everyone involved
<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.
<wpwrak>
;-))
<wpwrak>
split 2D editing and 3D rendering ? :)
<whitequark>
hm?
<whitequark>
no
<whitequark>
this has nothing to do with geometry itself
<whitequark>
the latency is constant and the result of me having to manually flip framebuffers through X11
<whitequark>
this is /literally the thing the newer gtkglarea is fixing/
<wpwrak>
(flipping) i see.
<whitequark>
do you have huge monitors too?
<whitequark>
and perhaps not that high-end CPU?
<wpwrak>
monitors are just 1920x1080. cpu is q6600. new ones still have about the same clock speed and number of cores ;)
<whitequark>
mhm, weird
<wpwrak>
(thogh they probably now execute a dozen instructions per cycle :)
<whitequark>
I also have full-hd and probably a less-powerful CPU
erichvk has quit [Ping timeout: 240 seconds]
<whitequark>
nah
<whitequark>
newer ones have lower TDP primarily
<whitequark>
and wider SIMD registers
<wpwrak>
line dragging is just strangely slow. about 1 s latency.
<whitequark>
whaaaat?
<wpwrak>
(that's move mouse, wait until the line moves, then repeat. so system latency is maybe half that)
<whitequark>
that makes no sense at all
<wpwrak>
toldya :) it's SLOW.
<whitequark>
there's absolutely no way it should or even can take 1s
<whitequark>
well try it on 3.22 first.
<whitequark>
I am absolutely not supporting the horrible framebuffer flipping hack anymore in any way, shape or form
<wpwrak>
wish i had that :)
<whitequark>
hm
<whitequark>
does 2.3 also have the roblem?
<wpwrak>
how would i test that ?
<whitequark>
uhm, build solvespace 2.3? or install it from debian, assuming it's there already
<wpwrak>
tag v2.3 is good ?
<whitequark>
yup, exactly what you need
<wpwrak>
whee. cmake doesn't hate me for trying that :)
<whitequark>
I can't in good faith call cmake "decent" but it does handle many basic cases
<whitequark>
which is more than can be said about most other build systems
<wpwrak>
2.3 is much faster. still lags a little, but maybe 100 ms at most.
sb0 has quit [Ping timeout: 255 seconds]
<whitequark>
hm, interesting
<whitequark>
does 3.0 consume 100% of CPU?
<whitequark>
it's "interesting" because I'm pretty sure my system is slower than yours
<wpwrak>
solvespace about 50%, X11 about 85% (quad core)
<whitequark>
riiiiight
<whitequark>
I know what happens, ok
<whitequark>
wpwrak: ok so a shot in the dark
<wpwrak>
the lag also depends on distance
<whitequark>
can you check out master and replace set_use_es(true) with set_required_version(4, 0) in both cases
<wpwrak>
lemme upload two videos. just a sec ...
<whitequark>
yeah I'm pretty sure that "fix" will work
<whitequark>
wpwrak: btw to get debug symbols use cmake . -DCMAKE_BUILD_TYPE=Debug
<whitequark>
(you don't need to rm the build dir, just rerun make then)
<whitequark>
aha
<whitequark>
wpwrak: please rerun with LIBGL_DEBUG=1 MESA_DEBUG=1
<whitequark>
... I should add that in README somewhere.
<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
<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?
<whitequark>
DocScrutinizer05: ugh
<whitequark>
let's make experience worse for *everyone* instead
<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.
<whitequark>
wpwrak: oh wait, are you using nvidia?
<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
<whitequark>
DocScrutinizer05: it doesn't do a redraw for *every* change
<whitequark>
it's locked to vsync of your monitor, as it should be
<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
<whitequark>
wpwrak: that actually looks like it ought to work
<whitequark>
hmm
<whitequark>
maybe the bug is something else
<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
<DocScrutinizer05>
TV interlaced has basically same reason
<DocScrutinizer05>
all obsolete in time of LCD monitors
<DocScrutinizer05>
Plasma displays however... ;-D
<DocScrutinizer05>
haha 0bin is a smart concept
<whitequark>
wpwrak: basically can you try commenting stuff out until you get an interesting crash?
<whitequark>
the body of RefreshRecentMenus is a good 1st candidate
<whitequark>
theres something fucky going on with the GTK widget initialization order but I don't understand what it is
<whitequark>
wpwrak: hang on.
<whitequark>
does that use your DISPLAY_TEXTWND hack?
<whitequark>
is it enabled during the crash, that is?
<wpwrak>
no, it's plain "master"
<whitequark>
ok
<whitequark>
does it crash somewhere else oncey ou comment out the body of RefreshRecentMenus
<whitequark>
wpwrak: I had to do: export LANG=C LC_CTYPE=en_US.UTF-8 LANGUAGE=
<whitequark>
you have to specifically set LANGUAGE= to an empty string. apparently.
<wpwrak>
export LANGUAGE= without anything else (i.e., still LANG=C) has no effect here (except for putting LANGUAGE in the environment)
<whitequark>
wpwrak: then I just have no idea how you've managed to achieve this
<whitequark>
anyway I fixed it
<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 :)
<whitequark>
wat?
<whitequark>
have you considered that not everyone speaks English
<wpwrak>
oh, do it in the application if you must
<whitequark>
anyway, the only reason POSIX i18n is so bad is because it was written by people with this attitude
<wpwrak>
or use pretty icons ;-)
<whitequark>
using solid engineering practices almost entirely eliminates the pain in i18n
<whitequark>
I know this because *SolveSpace has i18n*
<wpwrak>
as i said, do it in the application, not libc
<whitequark>
oh
<whitequark>
yeah, I agree entirely
<whitequark>
personally I would prefer libc to be split into "libposix", something that has malloc, open, socket, etc
<whitequark>
and then libc proper, which has all the rest of the junk like string manipulation
<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
<whitequark>
... there's also an argument to be made about glibc
<whitequark>
for example, did you know glibc actually *has a copy of gettext*?
<whitequark>
it doesn't just implement all the garbage POSIX requires, it goes above and beyond!
<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...
<DocScrutinizer05>
what's wrong with POSIX locales?
<whitequark>
... and this is why I've the gettext runtime reimplemented from scratch in SolveSpace
<whitequark>
DocScrutinizer05: 1) people rely on printf/scanf as a general-purpose string-formatting and string-parsing functions
<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
<whitequark>
this is wrong, but it is a fact of life and a result of C not providing decent parsing facilities
<whitequark>
2) look at the locales themselves
<whitequark>
it's insane that there are so many different knobs to turn
<whitequark>
why are LC_* individually settable?
<whitequark>
why is there no variant of e.g. isdigit that is *not* affected by locale?
<wpwrak>
why does the dominatrix have different types of whips in the dungeon ? ;-)
<whitequark>
lol wpwrak
<DocScrutinizer05>
hmm i'm pretty happy with using e.g. english text but ISO dates
<whitequark>
DocScrutinizer05: there's no argument this should be possible
<whitequark>
the way it should be possible is by writing a file that says how your en_US-DocScrutinizer locale works
<whitequark>
it's unambiguous and simple
<whitequark>
instead you have this Lovecraftian horror
<DocScrutinizer05>
there's actually also no sane argument for american date format
<whitequark>
well, yes, but we unfortunately can't wish americans out of existence, so...
<DocScrutinizer05>
I agree on the horror aspect though
<whitequark>
I would also prefer no human being used an ideographic writing system
<DocScrutinizer05>
hm?
<DocScrutinizer05>
example please
<whitequark>
high-quality support for hanzi and kanji is really hard to do
<DocScrutinizer05>
aaah that, yeah
<whitequark>
like for example, input methods are primarily why solvespace bothers with GTK
<DocScrutinizer05>
what *really* sucks is coma vs dot for decimal
<whitequark>
GTK input boxes integrate with the system IME
<DocScrutinizer05>
comma*
<whitequark>
so you can input Chinese if you want using the same tool you usually use
<whitequark>
yeah, that's nasty
<whitequark>
I've recently made the numpad dot always enter a dot in solvespace
<whitequark>
even if it's set to comma on your keyboard layout
<DocScrutinizer05>
cooooool
* DocScrutinizer05
still searches for a decent generic versatile keyboard handler that can even do macros
<DocScrutinizer05>
redefine keys "on the fly"
<DocScrutinizer05>
record and playback macros
<DocScrutinizer05>
just define ONE special "escape key" to switch to keyboard handler communication
<DocScrutinizer05>
capslock comes to mind
<whitequark>
heh
<DocScrutinizer05>
or numlock
<whitequark>
wpwrak: I figured out why setting version to 4.0 works on my machine.
<wpwrak>
before the "Windows" key was added, Caps Lock had the crown of most useless key ever for ages
<whitequark>
that's because setting version to 4.0 through gtk actually sets it to *2.0* in the request to glX
<wpwrak>
heh :)
<whitequark>
what the actual fuck?
<DocScrutinizer05>
LOL
<wpwrak>
well, it preserved the .0 part pretty accurately
<whitequark>
wpwrak: if I ask for 4.1 I still get 2.0
* DocScrutinizer05
glares at his MX500 12 button mouse
<whitequark>
this is extremely stupid because I CANNOT request a 2.0 context from GTK
<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
<whitequark>
wpwrak: *sigh* let's try one more thing
<DocScrutinizer05>
oh and when you complain about locale horror, never look into input driver layers horror!
<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
<whitequark>
unless you can coerce it into setting legacy_bit=TRUE it is a total loss.
<wpwrak>
probably not a good idea to depend on locally hacked libraries ...
<whitequark>
exactly
<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" ...
<whitequark>
nah, gtk>=3.22 is fine
<whitequark>
they allow me to request a GL ES context, which is the proper way to do what I want
<whitequark>
and I think even NVidia supports it these days
<whitequark>
wpwrak: oooh, so I have an evil ide
<whitequark>
(idea
<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.)<<
<whitequark>
wpwrak: good news. I have it working on gtk 3.16+. however, the text in the text window is replaced by rectangles.
<wpwrak>
all hail the new universal simplified character set ! ;-)
<DocScrutinizer05>
path to font
<whitequark>
huh?
<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
<DocScrutinizer05>
where iirc path_to_font even includes stuff like 11PT and intalic, sometimes
<whitequark>
I do not use the crappy X font system
<DocScrutinizer05>
well, no idea. rectangles instead chars usually means the char is unknown aka cannot be found in system
<whitequark>
I know what happened exactly, I wrote that font renderer...