<wpwrak>
whitequark: i like the tangent arc feature. makes all these rounded corners of real-life design so much easier (even if i didn't do them perfectly)
<wpwrak>
whitequark: there's still no way to have a table with "global" variables, to use for dimensions and such, is there ?
<wpwrak>
whitequark: also, how would i do (straight-line) chamfers instead of (rounded) fillets ? it seems that i could accomplish them with "split lines", but not as nicely as tangent arcs
<wpwrak>
whitequark: just drawing a line across a corner doesn't seem to make solvespace consider it a chamfer
<wpwrak>
intersting ... chromium (resolver ?) now looks up CNAME records through /etc/hosts. and of course, i had an old name that was only used as alias "target" and that has changed in DNS but not in my local /etc/hosts ...
wildlander has quit [Quit: Saliendo]
<whitequark>
wpwrak: nope not implemented yet
<whitequark>
wpwrak: as for chamfers can you show me a sketch tht doesn't work for you?
sandeepkr has joined #qi-hardware
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #qi-hardware
<wpwrak>
whitequark: maybe i should ask what would be the best way to do chamfers. is there something like the tangent arcs ? or do i have to turn the lines leading to the corner into "construction" lines, then put together the chamfer piece by piece ?
<wpwrak>
whitequark: with the tangents (for fillets), i'm basically placing a modifier on the straight lines, without destroying them. but i don't see a comparable operation for chamfers.
<wpwrak>
hmm no, the tangent arc actually changes things, too. thought it didn't, but now i tried to delete one, and the corner it had modified was damaged
<whitequark>
wpwrak: there's an issue where the constraints do not preserve chirality
<whitequark>
so you can flip the sketch across discontiguities
<whitequark>
this is the usual cause of such 'damage'
<whitequark>
as for chamfers, no, not really, I would just sketch them by hand since you don't need as much construction geometry as for tangent arcs
<whitequark>
oh, hm
<whitequark>
you want to constrain the non-chamfered dimension, right?
<whitequark>
I see why that would call for a chamfer tool...
erichvk has joined #qi-hardware
sb0 has joined #qi-hardware
dandon has joined #qi-hardware
<wpwrak>
whitequark: yes, i'd want to start with the basic geometry, then refine it with fillets and chamfers
<wpwrak>
i first made the basic thingie without cut-out or smoothing of corners, then added the cut-out (nice and easy, since i had clearly defined edges to keep a distance from), and rounded most of the corners.
<wpwrak>
the use of the 32.0 constraint on the large diagonal at the bottom to control the width of the large vertical element is sub-optimal. i did it that way because things kept on flipping when i specified the width of that vertical element directly. but i may have been able to find a better dimension.
<wpwrak>
and yes, that problem was chirality. the left and right side of the vertical element would invert when making unrelated changes. i tried to use a negative width, but that didn't convince solvespace.
<wpwrak>
is there some way to give solvespace "hints" how to resolve such issues ? there's "show degrees of freedom", but that just gives me lots of points without too clear an idea of what to do with them.
<whitequark>
this is however blocked on the new file format, as the existing one is really hostile to any kind of evolution
<whitequark>
mind filing a bug about the chamfer tool?
<whitequark>
wpwrak: also let me download your models...
<whitequark>
wpwrak: is there a reason you've assembled your entire thing totally unhinged from origin?
<whitequark>
s/assembled/drawn/
<qi-bot>
whitequark meant: "wpwrak: is there a reason you've drawn your entire thing totally unhinged from origin?"
<whitequark>
hehe, I forgot about this feature
<whitequark>
wpwrak: this usually results in annoyance during assembly
<whitequark>
wpwrak: further. why are you using so much distance constraints?
<wpwrak>
oh, i hadn't decided on a good origin at the beginning. and when i tried to anchor it, solvespace didn't like the idea. i think it complained about conflicting constraints or such.
<whitequark>
e.g. I would use a radius equality constraint every time you have a symmetric rounded edge
<wpwrak>
ah yes, i could have used equality in a few cases
<whitequark>
you're losing out on much of the parametricity
<wpwrak>
though many radii are slightly different
<whitequark>
is this why you wanted global parameter tables?
<wpwrak>
yup :)
<whitequark>
(those are also blocked on the new file format)
<whitequark>
ok, about the origin: the lack of chirality preserving constraints strikes again
<whitequark>
select all, then move it about where you want it
<whitequark>
then constrain it
<whitequark>
I just put the top right circle center at origin and constrained it there, that worked
<whitequark>
the chirality issue is really troublesome.
<whitequark>
wpwrak: negative width generally flips the constraint
<wpwrak>
i just get a red screen if i try that
<wpwrak>
(that = center the center of the circle)
<whitequark>
wpwrak: how close did you move that point near the origin first?
<whitequark>
it has to be well within the circle
<wpwrak>
i selected both, then constrained them to be the same
<wpwrak>
ah, moving it close does indeed help ;-))
<whitequark>
yes. that's not enough, because solvespace tried to move the circle way out of the rest of the sketch, inverted a few things then promptly got into a numeric instbility
<whitequark>
like I said, I know how annoying it is:)
<whitequark>
that's very high on my list of things to do
<wpwrak>
btw, with the recent requirement for gtkmm >= 3.22 (or such), you cut out even ubuntu users who update frequently. let's hope the distro moves this along soonish, too.
<whitequark>
wpwrak: yes, I understand that, and that's why it was done only in the 3.0 branch and quite late
<whitequark>
I do not expect a 3.0 stable release until the end of 2017
<whitequark>
there's a lot of work to be done to justify it
<wpwrak>
yes, i appreciated that i could find the version to go back to fairly easily :)
<whitequark>
the benefits of gtkmm>=3.22 are rather significant as the old rendering pipeline is awful in so many ways
<whitequark>
opengl immediate mode rendered to an offscreen buffer and then flipped onto the screen using X primitives
<whitequark>
this is slow in more than one way, it has tearing, it really likes to glitch out, it doesn't play nice with compositing and doesn't work on wayland at all
<whitequark>
wpwrak: that said I *thiiink* I might be able to lower the gtkmm requirement a bit
<whitequark>
to 3.18 perhaps if that helps?
<whitequark>
I'm not sure if it's worth the effort given how buggy early gtk3 is
<whitequark>
wpwrak: hm, scratch that, gtkmm 3.22 is in stretch right now, so it will be in the next debian stable
<whitequark>
I think that qualifies as widely supported enough, and I'll stay on it for rather a while then
<whitequark>
that should be quite easy to do, I think it could get done in a few days once I empty my merge queue
<wpwrak>
gtkmm ... my ubuntu 16.10 now has 3.20.1
<whitequark>
mhmm, that *is* quite recent
<whitequark>
I am certain 17.04 will include 3.22+ though
* whitequark
grumbles
<whitequark>
gtk includes glarea for quite a while but gtkmm only exposes it since 3.18 and the function to request a GL ES context since 3.22
<whitequark>
we use GL ES in SolveSpace exclusively because that's the least painful cross-platform solution
<whitequark>
the only sane way to get GL >1 to reliably work on Windows is to pipe it through ANGLE, which emulates GL ES 2
<whitequark>
on Linux and macOS that involves asking for either a GL ES context or a GL core 4.0+ context due to a sequence of idiotic decisions by khronos
<wpwrak>
meh. just defenestrate :)
<whitequark>
despite the fact that we only actually use functions from the common subset of gl *2* and gl es *2*
<whitequark>
nope.
<whitequark>
most users of solvespace are on windows.
<whitequark>
if I had to leave one platform it would be windows.
<wpwrak>
sucks
* whitequark
shrugs
<whitequark>
it's not particularly bad?
<whitequark>
actually the most frustrating platform to support was GTK without any doubt
<wpwrak>
heh :)
<whitequark>
anyway, now that the new rendering pipeline is in, you'll find that solvespace handles millions of triangles without much trouble
<whitequark>
and lots of entities too
<wpwrak>
ah, what would be nice is if the text window could be launched from a separate process. that way, one could just have it on another screen, without having to worry about how windowing system and window manager manage things. (e.g., my multihead is :0, :0.1, not one large "merged" screen)
<whitequark>
that is really not going to happen
<wpwrak>
i will find that, once ubuntu has caught up with your build requirements ;-)
<wpwrak>
too tight integration needed ?
<whitequark>
dealing with multiprocessing on multiple platforms is nasty.
<whitequark>
and I would also like to have e.g. android and webgl ports, eventually
<wpwrak>
hmm, getting tricky :)
<whitequark>
but I think this is an XY problem.
<whitequark>
why not ask for proper multi-monitor support?
<whitequark>
that's implemented on Windows.
<wpwrak>
right now, i send the text window to another virtual screen. so i can flip back and forth relatively quickly. but it would be nicer if i could have have both visible at the same time.
<whitequark>
I take it your issue is that the window position is not restored correctly?
<wpwrak>
yes, if you can do that, why not
<whitequark>
or something else?
<wpwrak>
not sure if it's not harder in the end
<whitequark>
oh, wait, I think I realize now
<whitequark>
you don't use xrandr/xinerama?
<wpwrak>
i just have 1920x1080 screens. so already the real estate is kinda tight.
<wpwrak>
i just use separate screens. without things (except for the window manager itself) moving between them.
<whitequark>
you have to use different DISPLAY variables, right?
<wpwrak>
that prevents all sort of things from misbehaving. but the downside is that i can't just drag a window to another screen.
<wpwrak>
yes
<whitequark>
well, in my opinion that kind of setup is horrifying
<whitequark>
but let me see if something can be done about it.
<wpwrak>
works pretty well for most things :)
<whitequark>
as far as I know X11 is the only relatively common platform to use this
<whitequark>
... and in general I make no effort to accomodate the specialness of X11
<wpwrak>
e.g., i can have my usual 4x3 array of virtual screens on each physical screen, and select them independently. also, if an application wants to go full-screen, it will never go full-all-screens
<whitequark>
that seems like purely a window manager issue
<whitequark>
wpwrak: anyway, i will accept a patch that implements this functionality
<whitequark>
I have no idea whether this will work and I won't have a setup where I can verify that it works even any time soon, I don't think
<whitequark>
since in my laptop the nvidia card isn't connected to any actual outputs
<whitequark>
wpwrak: indeed
<whitequark>
that *also* has to wait until the new file format :)
<whitequark>
the existing file format doesn't really have any hierarchy in the assembly tree
<whitequark>
wpwrak: overall, do you feel solvespace is saving your time? or is it not there yet?
<wpwrak>
is there any non-hierarchical list of items ?
<whitequark>
well, there's the list of imported groups
<wpwrak>
this "hook" was the first design where i thought my very basic understanding of solvespace would be sufficient to get the thing done, and i wasn't disappointed.
<wpwrak>
and i especially liked how easy it was to add those pesky fillets. with my usual workflow (python-script freecad) that sort of thing is a nightmare
<wpwrak>
my biggest problem are the chirality surprises (and perhaps some other effects of under-defined sketches). especially when you don't have a clear idea from the beginning, it can get pretty messy to do a partial cleanup and try something else.
<wpwrak>
but with the possibility of having multiple viewports (in separate windows)
<wpwrak>
kinda pitaish to implement, i'd guess, though
<wpwrak>
oh, and it the dialog that tells me that deleting this will also delete a bunch of other things (usually constraints) meant to be anything more than to instill a vague feeling of fear and uncertainty ? :) i.e., at that point, some sort of way to explore what exactly if being deleted may be useful. that it, unless one is expected to accept whatever the outcome on good faith
<wpwrak>
(imported groups) yeah, i still have to wrap my head around these. once i leave the 2D plane, my understanding of solvespace gets increasingly cargo-cultish :)
<wpwrak>
my hope is that some day i'll be able to do things like the anelok case with solvespace. with freecad, i manage, but every little quirk and wrinkle i add makes the design more obscure. i.e., that scripted design process doesn't scale nicely.
<whitequark>
wpwrak: the unified window is in my queue, in fact there is a partial implementation
<whitequark>
the good news is the gtk3 migration made that much easier in some ways
<whitequark>
but I'll have to rework quite a bit of the platform code to make that elegant
<whitequark>
wpwrak: (dialog) well uh... you could say "no" :)
<whitequark>
there isn't really anything better that can be done at that point because leaving the entities in the sketch would cause a crash
<whitequark>
it could give you the names of the entities that are removed but those aren't super informative
<whitequark>
in general its purpose is to tell you that there were 'some' dependent entities or constraints
pcercuei has joined #qi-hardware
<whitequark>
(imported groups) those are conceptually very simple. when you import a group you get a 'snapshot' of the geometry in that file, as a single 'thing'
<wpwrak>
a list of them, with the option to highlighting them would be neat
<wpwrak>
of course, wildly incompatible with a modal dialog ;-)
<whitequark>
nothing in that snapshot can be modified anymore. the mesh won't get regenerated, the entities won't budge
<whitequark>
you can rotate it though
<whitequark>
also, when you update the file you've imported and reload, the imported geometry automatically updates.
<whitequark>
(highlighting) how? they're dead.
<wpwrak>
i mean before deletion, while you're still trying to make up you mind about whether to say yes or no
<whitequark>
that's not really how the UI is structured, solvespace never asks you if you really want to do something
<whitequark>
instead it implements reliable undo
<whitequark>
mhm
<whitequark>
I have an idea
<wpwrak>
yes, reliable undo is very good to have
<whitequark>
ok, so the idea
<whitequark>
the 1st time you delete something you get a screen in a text window showing dependents
<whitequark>
that will highlight them as usual
<whitequark>
the 2nd time you hit delete after that does the deletion
<whitequark>
can you file a bug requesting for this improvement?