00:02 <whitequark> wpwrak: pushed

00:02 <whitequark> also now clean wrt -Wall -Wextra, at least over here

00:03 <wpwrak> ah, just did the full build :) let's see ...

00:05 <wpwrak> i don't see a push ? it's here, right ? https://github.com/solvespace/solvespace.git

00:05 <whitequark> nono, whitequark/solvespace

00:05 <whitequark> nightlies are still there

00:05 <whitequark> since i force-push a lot and doing this to the main repo is hostile

00:06 <wpwrak> you should unlearn that force-push pattern :)

00:06 <whitequark> no

00:06 <whitequark> this is very deliberate

00:07 <whitequark> i want history to be clean, and i don't want to build everything on three systems manually

00:07 <wpwrak> btw, here are the warnings i got before. just two more: https://neo900.org/stuff/paste/Aegee5qu

00:07 <whitequark> so if something comes up on the OS X buildbot? I fix it and force-push

00:07 <whitequark> git submodule update too

00:10 <wpwrak> i guess yuo could just use a push-to-build-test repo. then fix things locally before pushing to the public repo.

00:12 <wpwrak> let's see how the new build goes ...

00:12 <whitequark> i also edit history when i forget something

00:12 <whitequark> which is like every other commit

00:12 <whitequark> and no, "forget less" is not an option. so deal with it, i guess, or never use the nightly repo

00:12 <wpwrak> sure. rebase -i is fun :)

00:12 <whitequark> i mean edit published (to whitequark/solvespace) history

00:13 <whitequark> rebase -i locally is harmless

00:13 <wpwrak> exactly. that's what i mean: i also often forget something when committing, so i let things rest for a bit before pushing

00:14 <wpwrak> build it noticeably cleaner now :) just the auto_ptr complaint left now

00:15 <whitequark> yeah. can't do anything about that.

00:15 <wpwrak> btw, my ubuntu didn't like the libgtkmm-2.4-dev libpangomm-1.4-dev dependency. had to use aptitude to find a solution at all, and it involved downgrades. but i'm not sure if this isn't a result of having a slightly odd setup here (accidently upgraded once into a testing release, and haven't been able to completely shake off the consequences yet)

00:17 <whitequark> what did you use before?

00:18 <wpwrak> back to raising ... seems that a gtk dialog doesn't have to make the main window raise. so there's another quirk somewhere in solvespace.

00:19 <wpwrak> i think it was some 14.xx, then jumped to xenial a few months ago. so far the installer hasn't recognized my right to upgrade to release 16.04

00:20 <whitequark> no, which *mm-dev packages

00:20 <whitequark> or what did they cause to downgrade

00:20 <wpwrak> lemme see if it's still in the scroll buffer ...

00:22 <wpwrak> this is the negotiation with aptitude: https://neo900.org/stuff/paste/ra6Ver5e

00:24 <wpwrak> to test the window raising on dialogs, you can use fped: just run fped, put something over its window, then select File > Save as. the dialog pops up, on top, but the main window stays at its original position

00:24 <wpwrak> the same experiment with solvespace makes GW jump to the front as well

00:27 <whitequark> re -dev packages: no idea. the dependency looks right to me. no clue why apt wants to downgrade

00:32 <whitequark> wpwrak: regarding dialogs, you set parent window to NULL in fped

00:32 <whitequark> and I set it to *GW

00:33 <whitequark> i'm not going to change that because your behavior is, in fact, incorrect

00:34 <whitequark> (specifically, a dialog should be a modal window placed where the graphics window is)

02:11 <wpwrak> (parent) ah, interesting. quirky stuff :)

15:20 <wpwrak> whitequark: about the constraint markers: what i meant is more about exploration, e.g., when trying to see what constraints you've put. example: a rectangular U-shape. let's call the sides A, B, C. you'd have a perpendicular constraint for (A, B) and for (B, C).

15:23 <wpwrak> there will then be an inverted T indicating the constraints on A, B, and C. on B, it seems that you may have one or two inverted Ts. let's assume it's one. so when you hover over any of the Ts of A or C, also the one in B is highlighted.

15:24 <wpwrak> but if you hover over the one on B, only A or C is highlighted, so you don't see that there is a second one.

15:28 <wpwrak> so that's a little inconsistent. not sure if it matters in the greater scheme of things, though, since i don't know yet the overall workflow for doing things in solvespace

15:30 <wpwrak> by the way, regarding variables: in fped, i found it very useful to have tables as means of iteration. each column represents a variable, and each row is an iteration step. so if i want three variants of the same structure, i make three rows and fill in the corresponding values. then fped iterates over the table and creates three different "instances".

15:32 <wpwrak> and of course, every value can be an expression. and expressions are stored as expressions and only evaluated when anything has changed (i just rebuild the whole drawing each time any change has happened - modern computers are more than fast enough for this ;)

21:49 <whitequark> wpwrak: yes, what you're suggesting is clearly very valuable, and it's been on my roadmap for months

21:49 <whitequark> unfortunately, some serious refactoring needs to be done before that's implemented

22:45 <wpwrak> refactoring, the joy of OO - at least you have a word for it ;-)