Reisga244 has quit [Quit: Ping timeout (120 seconds)]
Reisga244 has joined #openscad
ToAruShiroiNeko has joined #openscad
Guest56 has joined #openscad
J24k76 has quit [Quit: Client closed]
J24k76 has joined #openscad
Guest56 has quit [Quit: Client closed]
Guest12 has joined #openscad
Guest12 has quit [Client Quit]
mmu_man has quit [Ping timeout: 260 seconds]
LordOfBikes has quit [Ping timeout: 276 seconds]
LordOfBikes has joined #openscad
mtm has joined #openscad
peepsalot has quit [Quit: Connection reset by peep]
peepsalot has joined #openscad
J24k68 has joined #openscad
J24k76 has quit [Ping timeout: 256 seconds]
JordanBrown has joined #openscad
<JordanBrown>
Has anybody noticed problems getting some of the "new" windows (animate, error log, viewpoint) to hide and stay hidden?
<JordanBrown>
I've had trouble getting them to hide using the menus (but works when I explicitly close them), but they come back when I restart the application.
<JordanBrown>
Right now, even in 2021.01, with Error Log undocked, if I Window/Hide Error Log it sort of flashes and does not hide.
<JordanBrown>
All of that is Windows 11.
<InPhase>
JordanBrown: Have you checked the config file's [view] section between runs?
<InPhase>
JordanBrown: It's a different problem if it's not getting updated, or if it's not getting read in right.
<JordanBrown>
We don't have no steenking config files :-)
<InPhase>
JordanBrown: The undocking though... I think that ends up embedded into that binary crap under [window]. I do recall some completely unrelated bugs where that got into some wacky states on Windows, from some time back. An option could be purging the contents of that section. But as a dev, save a copy first in case there are secret bug hints. ;)
<JordanBrown>
But the first problem is that the window won't go away with Window/Hide.
<InPhase>
Oh, you mean it doesn't even go away within the same run?
<InPhase>
Is it only the normally docked ones that are doing this?
<JordanBrown>
I run all-undocked so I don't have as much experience with docked.
<JordanBrown>
But for instance, I just tried to Window/Hide the animation pane, and it didn't go away.
<JordanBrown>
When I hit its close box it went away, but the Window menu does not have a check next to hiding it.
<InPhase>
Disappeared for me, while docked, Oct 20 build.
<JordanBrown>
and when I look at the registry, hideAnimate remains false.
<InPhase>
(Linux, if it ends up mattering)
<InPhase>
JordanBrown: Does it work to close and manually change that config file entry? Or does it go back to false?
<InPhase>
i.e. forced open vs failure to close
<JordanBrown>
I docked it, and then Window/Hide, and it went away and updated the Registry. But I have had other times when it doesn't go away, or only half goes away. (Like the content portion goes white and the rest goes unresponsive.)
<InPhase>
Well that sounds weird.
<InPhase>
You built yourself?
<JordanBrown>
Yeah, it hasn't really been predictable enough to characterize.
<JordanBrown>
No, this is 2024.10.28.
<InPhase>
From the site?
<JordanBrown>
Yes.
<InPhase>
Do you also have your own build? I'm fishing for a dependency difference, such as a Qt difference.
<JordanBrown>
To the extent that I've been able to narrow it down, it seems like it's the same for my own build.
<InPhase>
These are intermittent failures hard to trigger?
<JordanBrown>
And the same for 2021.01 and Error Log.
<InPhase>
Oh, well that's weird to go back that far.
<InPhase>
You've been encountering it only recently though?
<InPhase>
Not like, 3.8 years?
<JordanBrown>
Hard to say. I think it's a modal thing, that stuff like this happens when it gets into a bad state, and not when it's not.
* InPhase
nods.
<InPhase>
Do you have two monitors?
<JordanBrown>
I think I've run into it on and off for a while, but when it was only Error Log it wasn't as big a deal.
<JordanBrown>
Yes.
<InPhase>
Does it happen when everything is on monitor 1?
<JordanBrown>
(Three, actually, but one isn't connected to this computer.
<JordanBrown>
)
<JordanBrown>
yes
<JordanBrown>
I have lots of glass. I love my glass.
<InPhase>
Would it be too much of a pain in the rear to unplug down to one and try again?
<JordanBrown>
I can trivially power one off.
<InPhase>
The last Windows window state bug was multi-monitor related. :)
<InPhase>
This is heuristics fishing.
<InPhase>
But I'm about out of thoughts.
<JordanBrown>
Though, hmm. Windows didn't seem to notice when I powered it off; the KVM switch might be faking it.
<JordanBrown>
I can try unplugging down to 1. I just have to figure out which cable that is...
<InPhase>
Oh. It probably matters what Windows thinks.
<JordanBrown>
yes, of course.
<JordanBrown>
But if I unplug on the computer side of the KVM...
<JordanBrown>
I think it's all strongly tied to being undocked.
<JordanBrown>
If Error Log is docked, hide/unhide works as expected.
<JordanBrown>
If I undock it and Hide, it blinks and goes sort of inactive.
<JordanBrown>
It is not marked as hidden.
<JordanBrown>
and it comes back docked on restart.
<JordanBrown>
It seems to have most or all of the bad behaviors with only one monitor, so I'm going to plug the other back in.
<JordanBrown>
OK, so I seem to have a workaround: make sure I hide them from docked.
<JordanBrown>
I'll see if I can find some time to chase it down.
<JordanBrown>
BTW, thanks again for the tips on TPU. I've been doing a fair amount with it recently, and I like it a lot.
<JordanBrown>
It seems a little more squirrely than PLA, and a little slower, but not too bad once I got it dialed in.
<JordanBrown>
And the results are just nicer to handle than PLA.
<kintel>
teepee When you're online, see PM about gpg key
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dottork has quit [Quit: Client closed]
kintel has joined #openscad
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<teepee>
kintel, sorry forgot that one. I'll have a look if that has still some reasonable lifetime left. I think you can't even have that. I believe I had to replace that around the time of the 2021.01 release due to the older one being expired.
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
Virindi has quit [Ping timeout: 252 seconds]
Virindi has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 260 seconds]
teepee_ is now known as teepee
ali12341 has joined #openscad
ali1234 has quit [Remote host closed the connection]
<JordanBrown>
Now that other people are awake... has anybody encountered the problems I described above, where Window/Hide XXX doesn't hide undocked panes and where closing an undocked pane doesn't set its "hide" flag?
<JordanBrown>
To be clear: it's entirely possible that this behavior is not new. I dimly remember Error Log appearing when I didn't want it. I may have eventually stumbled upon the right combination to get hiding it to stick, and then not thought about it again. It's become more noticeable recently as the number of panes has increased dramatically.
<teepee>
ah, I see, yes, sounds like the correct order to me
* teepee
reads docu for weekly_canonical again
<teepee>
ahem, weakly ;-)
<teepee>
I think that's the one from boost due to CTL or whatever that magic was called
<teepee>
program_location is documented to: return full path and name of the currently running program (the one which contains the main() function)
<kintel>
Actually, we could move this to std::filesystem I think
<kintel>
I think peepsalot must have forgotten to port that one
<peepsalot>
never heard of it before. that is under boost::dll i only replaced boost::filesystem
<teepee>
no, program_location() is dll, weekly_canonical() is in both std and boost filesystem
<kintel>
right, but we use the weakly_canonical from boost::filesystem
<teepee>
I don't think program_location() is available in std though
<kintel>
right, that didn't make it into C++ yet..
<teepee>
yep, it should select boost due to the parameter coming from boost filesystem
<teepee>
ah, ADL, Argument-dependent lookup
<teepee>
that's what I meant
<kintel>
I do wonder how C++ managed to find weekly_canonical without a namespace though
<teepee>
program_location() returns boost::filesystem::path, so ADL includes that namespace
<teepee>
otherwise known as incomprehensible magic ;-)
<teepee>
I don't claim to understand ADL fully, but I think that's why it can find the unqualified function name
<kintel>
right, I didn't actually know that - I guess I don't usually use naked function names : /
<kintel>
Not sure why we use weakly_canonical, as it only seems to differ from canonical() in the case where a path doesn't exist.
<kintel>
..and since we're looking up the location of the currently running executable, I would think it has to exist..
<teepee>
not a requirement on linux, but I suppose just canonical() would work too, all those preconditions sounded a bit scary so I used weakly_canonical
<gbruno>
[github] kintel pushed 6 modifications (Get canonical location before asking for parent path (#5448) * Get canonical location before asking for parent path to correctly resolve a possible symlink of the openscad executable itself * Make boost::dll use std::filesystem, remove boost::filesystem from OpenSCAD dependencies) https://github.com/openscad/openscad/commit/50ca97a0b812fdf185b57a04da442a6f6a4ed6c7