#qi-hardware IRC log for Sunday, 2016-05-08

whitequarkwpwrak: pushed00:02
whitequarkalso now clean wrt -Wall -Wextra, at least over here00:02
wpwrakah, just did the full build :) let's see ...00:03
wpwraki don't see a push ? it's here, right ? https://github.com/solvespace/solvespace.git00:05
whitequarknono, whitequark/solvespace00:05
whitequarknightlies are still there00:05
whitequarksince i force-push a lot and doing this to the main repo is hostile00:05
wpwrakyou should unlearn that force-push pattern :)00:06
whitequarkno00:06
whitequarkthis is very deliberate00:06
whitequarki want history to be clean, and i don't want to build everything on three systems manually00:07
wpwrakbtw, here are the warnings i got before. just two more: https://neo900.org/stuff/paste/Aegee5qu00:07
whitequarkso if something comes up on the OS X buildbot? I fix it and force-push00:07
whitequarkgit submodule update too00:07
wpwraki guess yuo could just use a push-to-build-test repo. then fix things locally before pushing to the public repo.00:10
wpwraklet's see how the new build goes ...00:12
whitequarki also edit history when i forget something00:12
whitequarkwhich is like every other commit00:12
whitequarkand no, "forget less" is not an option. so deal with it, i guess, or never use the nightly repo00:12
wpwraksure. rebase -i is fun :)00:12
whitequarki mean edit published (to whitequark/solvespace) history00:12
whitequarkrebase -i locally is harmless00:13
wpwrakexactly. that's what i mean: i also often forget something when committing, so i let things rest for a bit before pushing00:13
wpwrakbuild it noticeably cleaner now :) just the auto_ptr complaint left now00:14
whitequarkyeah. can't do anything about that.00:15
wpwrakbtw, 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:15
whitequarkwhat did you use before?00:17
wpwrakback 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:18
wpwraki 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.0400:19
whitequarkno, which *mm-dev packages00:20
whitequarkor what did they cause to downgrade00:20
wpwraklemme see if it's still in the scroll buffer ...00:20
wpwrakthis is the negotiation with aptitude: https://neo900.org/stuff/paste/ra6Ver5e00:22
wpwrakto 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 position00:24
wpwrakthe same experiment with solvespace makes GW jump to the front as well00:24
whitequarkre -dev packages: no idea. the dependency looks right to me. no clue why apt wants to downgrade00:27
whitequarkwpwrak: regarding dialogs, you set parent window to NULL in fped00:32
whitequarkand I set it to *GW00:32
whitequarki'm not going to change that because your behavior is, in fact, incorrect00:33
whitequark(specifically, a dialog should be a modal window placed where the graphics window is)00:34
wpwrak(parent) ah, interesting. quirky stuff :)02:11
wpwrakwhitequark: 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:20
wpwrakthere 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:23
wpwrakbut 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:24
wpwrakso 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 solvespace15:28
wpwrakby 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:30
wpwrakand 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 ;)15:32
whitequarkwpwrak: yes, what you're suggesting is clearly very valuable, and it's been on my roadmap for months21:49
whitequarkunfortunately, some serious refactoring needs to be done before that's implemented21:49
wpwrakrefactoring, the joy of OO - at least you have a word for it ;-)22:45
--- Mon May 9 201600:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!