Skip to content

Conversation

@jenshannoschwalm
Copy link
Collaborator

We must do that as for the other dt_dev_process_xx() variants.

@jenshannoschwalm jenshannoschwalm added the bugfix pull request fixing a bug label Jan 11, 2026
@jenshannoschwalm jenshannoschwalm added this to the 5.4.1 milestone Jan 11, 2026
@jenshannoschwalm
Copy link
Collaborator Author

Inspired by #20083

@dterrahe
Copy link
Member

dterrahe commented Jan 11, 2026

These get called from "expose", so after a draw signal is sent for the window widget. It is hard to imagine this happening without a gui being attached. But in any case, the dev used for the 2nd preview is the same as the dev for the central window, which gets initialised in darkroom.init with gui_attached == TRUE.

So yeah, if you want to test for all things true, you should use an assert, rather than just return and pretend all is well with the world.

Creating consistency is a laudable goal, but sometimes that means removing unnecessary code rather than just creating more copies. You know as well as I do that at least 50% of the gui code was created by people copy/pasting code that they weren't exactly sure of but that didn't seem to hurt and that not inconceivably could have been part of the reason the whole thing ended up more or less working in the end.

@jenshannoschwalm
Copy link
Collaborator Author

So yeah, if you want to test for all things true, you should use an assert, rather than just return and pretend all is well with the world.

I would say yes, i want to do that :-)
Of course you are right - it's hard to image being called from somewhere else but as we expose it via -h ... `assert seems good to me.

We should do that for safety as for the other dt_dev_process_xx() variants.
Use asserts() for debug builds
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bugfix pull request fixing a bug

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants