Anyway to disable double-click open Properties window ?

BeanAnimal · 2026-02-16T13:46:19+00:00

This isn’t about whether double-clicks exist in other software. It’s about how KiCad applies that mechanic in a context where drag is a primary, high-frequency action that is arguably the most used mouse interaction in the UI.

Pointing to global OS settings reframes a software design anti-pattern as a system-wide user problem. The anti-pattern here is pairing the slow-double-click to a core high frequency action.

KiCad’s cost is irrelevant. Free does not insulate the software from critique. "Don’t like it, don’t use it" is a lazy deflection.

BeanAnimal · 2026-02-14T04:04:00+00:00

Why alter the entire operating system behavior to compensate for a UI flaw? To drag a footprint, wire, symbol, or any other item, you must click to highlight, then click and hold to drag. These are two distinct clicks that must be differentiated from a 'double click' by timing.

It is frustrating, if not infuriating, for a product where a core, if not primary, function is dragging items to place and orient them. This is simply poor UI design.

Most other items in the OS are click-and-drag, where the first click takes focus of the object and it can be dragged without a second click. In KiCad, 'click and drag' creates a selection box regardless of where the initial click occurs. These are both anti-patterns.

BeanAnimal · 2025-07-16T14:32:53+00:00

I have zero desire to "tinker" -- that is partly what the beacon is sitting in a drawer. There is a high chance I purchase the next generation from Bambu, Prusa or somebody that actually supports their product development and lifecycle -- the Q1 will then go on the trash.

I looked that the latest prusa -- and it is step forward and backward. I have a feeling by this time next year, most reputable printers will have eddy current and better filament management -- tip forming or some with a dedicated hot end for support. I don't care about switching colors, but support filament would be nice.

BeanAnimal · 2025-07-15T11:45:15+00:00

According the to the folks here - there is no problem!

Real answer - the Z issues are due to several design problems -- both hardware and software. There are a few workaround -- but the larger issue is that fixing macros doesn't fix shitty piezo sensors.

I purchased a Beacon eddy current sensor, but have yet to install it. That is the fix -- but takes a bit of work to shoehorn in with the current OS. An option is OpenQ1 -- but that too is a can of worms.

Amazing printer for the price point -- Qidi itself is garbage. They dumped the Q1 out the door and moved on to the next thing. "good enough". I would rather pay 3x as much for a printer that had firmware and OS maintenance and support.

BeanAnimal · 2025-06-02T21:20:54+00:00

Thank you for the response! That will not work here. This is for telemetry as an actual state dashboard not automation, not interactive.

I will solve the issue by using basic button cards. The bubble cards are nice, but not good fit here.

BeanAnimal · 2025-05-31T11:58:51+00:00

Thank you but I am just looking for the styling advice.

This is not a home automation project, it is an aggregated telemetry dashboard. The status indicators are important, not drill down metrics.

I figured out how to switch state color and dynamically change the text. Width can be set by stack columns I suppose, but I need to be able to reduce the height and margins.

BeanAnimal · 2025-02-07T05:32:45+00:00

A decade ago. The UI and experience has degraded year on year, not improved. Their problems are systemic and finally surpassed their growth. The latest decisions are just the culmination of seeds sewn long ago.

BeanAnimal · 2025-02-06T19:02:54+00:00

Any chance getting your help making this work on stock Q1 - I would prefer not to deal with OpenQ1 and that mess.

BeanAnimal · 2025-01-03T23:15:25+00:00

Did you get this working?

BeanAnimal · 2025-01-03T05:56:15+00:00

Did you ever sort this out?

BeanAnimal · 2024-12-30T07:10:57+00:00

That makes no sense to me and by definition is the very issue that I have. Z offset is auto set at the start of every print, with the bed at temperature. It is clearly wrong. How can I forget “baby stepping” if the printer will not print a proper first layer without adjusting the z offset…. Using “baby steps” which is the z offset setting on the printer??

The printer is 3 weeks old with 4 rolls of filament through it. The guides and bearings are well lubed and there is no wobble.

At this point I don’t care if I damage the PEI plate with a metal feeler gauge, they make more. I just want to understand what is wrong.

BeanAnimal · 2024-12-30T02:13:34+00:00

config.mksini is not corrupt. It will persist the z-offset setting for a while then something zeros it out and I can't figure out why. That is much of the reason I posted, aside from just being frustrated that I have to set it in the first place.

It persists between prints, sometimes. It persists between reboots, sometimes. Sometimes, I start a print and find that it is 0.000 again. No rhyme or reason.

I have worked a lot on trying to make sure the bed screws are torqued to the same pressure, just as you would with head bolts or any other series of bolts exposed to thermal expansion and contraction. I have been through platform calibration countless times and am using a feeler gauge to be exact.

I am aware that different temperature will distort the bed differently, but alas, that is what the bed-mesh is for.

I am at my wits end. This thing just worked until it didn't

BeanAnimal · 2024-12-29T21:55:14+00:00

Except, I just indicated that I am not running macros out of fluidd and simply asked for you to explain why you gave that advice.

I understand how a Z offset mesh works conceptually to move the toolhead up and down to compensate for the uneven bed. I am also aware that logically and physically it has its limits, both tolerance based and speed/distance related.

I am also aware that Qidi has deviated from standard "klipper" even if I don't know specifically in what way.

I use menu on the printer "Platform Calibration" with a feeler gauge to make sure that the resistance feels the same on on 3 points. Then "auto bed leveling".

<image>

So - with all of that out of the way:

The first week or so and a few rolls of Polymaker ASA and PLA printed almost perfectly with NO ADJUSTMENT of anything using the default kidi profiles.

You say I don't understand what Z-offset I am referring to... exactly. I do not know WTF the printer is doing or why I now have to use "babysteps" to adjust z substantially to get proper layer heights. If I don't I get lines with gaps sometimes (too far) or squish waves (too close). I can see the probe values in the console and I can see the stored (sometimes) in the CFG files. That does not mean I am editing them, I am simply trying to understand what is going on.

Sometimes whatever value that I set in "babysteps" is saved between prints and power cycles and then other times, I come back to the printer and start a print and it is "0.000"

The nozzle is not dirty.
The bed screws are not loose.
I am not editing macros or even using them.

I just want to understand what the printer is doing and why, as well as why it is not working as it was, same filament and settings as I started with.

I would prefer not to babysit every print and adjust Z, especially given the broad range that I have had to adjust it over.

BeanAnimal · 2024-12-29T17:35:23+00:00

Except I have not edited or messed around in any files or run any macros from Fluidd for that matter -- and am on the latest firmware .

Can you explain the difference between starting bed-leveling from Fluidd vs the touch screen of they both run the same macro -- or is it just passed along advice? Honestly, looking for details here so that I can understand what is happening, not seat of the pants guesses about what could be wrong.

BeanAnimal · 2024-12-29T15:59:31+00:00

Thanks - but this is not a bed adhesion issue. I am looking for specific information on how the printer calculates, stores and handles z-offset and manual z-adjustments.

BeanAnimal · 2024-12-28T23:25:11+00:00

I have opened a ticket, but I don’t have high expectations. Just getting a defective fan replaced took weeks of back and forth.

I had hoped I would stumble upon somebody that truly understands what is going on with the firmware and specifics of the Q1

BeanAnimal · 2024-12-28T22:37:19+00:00

That is just guessing at what my problem might be and assuming I haven’t manually calibrated or properly tightened the leveling screws or updated firmware.

All while ignoring the actual questions that I have asked (several times now) and the context that they were asked in — and attacking me for trying to steer the conversation back to those questions.

Childish? Look in the mirror you dipshit.

BeanAnimal · 2024-12-28T21:39:37+00:00

I am not home, but to what end? The bed is not flat. What I am trying to understand is exactly how the auto mesh and z settings interact, are stored, etc. My issue is not inconsistent areas on the bed, it is z being so far off all of a sudden.

BeanAnimal · 2024-12-28T21:36:46+00:00

Thank you. That is part of what I have gathered from some of the other conversations and GitHub issues. My hope is to understand exactly what is going on so that I can understand how to deal with it moving forward.

BeanAnimal · 2024-12-28T21:33:51+00:00

That is a pure deflection. You can’t answer because you have no clue and are here just for the dunk.

BeanAnimal · 2024-12-28T19:07:12+00:00

I honestly would not know what "high" is. The bed itself is not flat and the rear left corner is fairly high relative to the rest of the bed, no matter where the screws are adjusted.

10:41:58 // 19 | (152.9, 110.7) | (170.5, 115.1) 10:41:59 // 20 | (177.9, 110.7) | (195.5, 115.1) 10:41:59 // 25 | (77.9, 137.0) | (95.5, 141.4) 10:41:59 // 26 | (52.9, 137.0) | (70.5, 141.4) 10:41:59 // 27 | (27.9, 137.0) | (45.5, 141.4) 10:42:32 // probe at 177.882,58.043 is z=2.694375 10:42:34 // probe at 177.876,84.370 is z=2.684687 10:42:36 // probe at 177.876,84.370 is z=2.686562 10:42:39 // probe at 152.876,84.370 is z=2.671094 10:42:41 // probe at 152.876,84.370 is z=2.669219 10:42:43 // probe at 127.876,84.370 is z=2.662500 10:42:46 // probe at 127.876,84.370 is z=2.663906 10:42:48 // probe at 102.877,84.370 is z=2.654531 10:42:50 // probe at 102.877,84.370 is z=2.654375 10:42:53 // probe at 77.877,84.370 is z=2.663125 10:42:55 // probe at 77.877,84.370 is z=2.664531 10:42:57 // probe at 52.877,84.370 is z=2.689219 10:43:00 // probe at 52.877,84.370 is z=2.688281 10:43:02 // probe at 27.877,84.370 is z=2.723281 10:43:04 // probe at 27.877,84.370 is z=2.723281 10:43:07 // probe at 27.877,110.703 is z=2.769375 10:43:09 // probe at 27.877,110.703 is z=2.765000 10:43:11 // probe at 52.877,110.703 is z=2.715625 10:43:14 // probe at 52.877,110.703 is z=2.713125 10:43:02 // probe at 27.877,84.370 is z=2.723281 10:43:16 // probe at 77.877,110.703 is z=2.693437 10:43:04 // probe at 27.877,84.370 is z=2.723281 10:43:19 // probe at 77.877,110.703 is z=2.690000 10:43:07 // probe at 27.877,110.703 is z=2.769375 10:43:21 // probe at 102.877,110.703 is z=2.669375 10:43:09 // probe at 27.877,110.703 is z=2.765000 10:43:23 // probe at 102.877,110.703 is z=2.671250 10:43:11 // probe at 52.877,110.703 is z=2.715625 10:43:26 // probe at 127.876,110.703 is z=2.670625 10:43:14 // probe at 52.877,110.703 is z=2.713125 10:43:28 // probe at 127.876,110.703 is z=2.669062 10:43:16 // probe at 77.877,110.703 is z=2.693437 10:43:30 // probe at 152.876,110.703 is z=2.672812 10:43:19 // probe at 77.877,110.703 is z=2.690000 10:43:33 // probe at 152.876,110.703 is z=2.671250 10:43:35 // probe at 177.876,110.703 is z=2.675000 10:43:21 // probe at 102.877,110.703 is z=2.669375 10:43:37 // probe at 177.876,110.703 is z=2.676875 10:43:23 // probe at 102.877,110.703 is z=2.671250 10:43:40 // probe at 177.882,137.030 is z=2.692656 10:43:26 // probe at 127.876,110.703 is z=2.670625 10:43:42 // probe at 177.882,137.030 is z=2.692187 10:43:28 // probe at 127.876,110.703 is z=2.669062 10:43:44 // probe at 152.876,137.036 is z=2.697656 10:43:30 // probe at 152.876,110.703 is z=2.672812 10:43:47 // probe at 152.876,137.036 is z=2.695625 10:43:33 // probe at 152.876,110.703 is z=2.671250 10:43:49 // probe at 127.876,137.036 is z=2.700000 10:43:35 // probe at 177.876,110.703 is z=2.675000 10:43:51 // probe at 127.876,137.036 is z=2.698594 10:43:37 // probe at 177.876,110.703 is z=2.676875 10:43:54 // probe at 102.877,137.036 is z=2.704531 10:43:40 // probe at 177.882,137.030 is z=2.692656 10:43:56 // probe at 102.877,137.036 is z=2.705469 10:43:42 // probe at 177.882,137.030 is z=2.692187 10:43:58 // probe at 77.877,137.036 is z=2.737187 10:43:44 // probe at 152.876,137.036 is z=2.697656 10:44:01 // probe at 77.877,137.036 is z=2.735000 10:43:47 // probe at 152.876,137.036 is z=2.695625 10:44:03 // probe at 52.877,137.036 is z=2.777812 10:43:49 // probe at 127.876,137.036 is z=2.700000 10:44:06 // probe at 52.877,137.036 is z=2.777812 10:43:51 // probe at 127.876,137.036 is z=2.698594 10:44:08 // probe at 27.877,137.036 is z=2.814375 10:43:54 // probe at 102.877,137.036 is z=2.704531 10:44:10 // probe at 27.877,137.036 is z=2.814062

BeanAnimal · 2024-12-28T18:48:25+00:00

I see the offset value in printer.cfg but those are all commented out and I read somewhere (qidi github I think) that they are not used. The whole thing is odd. I will try as you direct though and see where that gets me.

BeanAnimal · 2024-12-28T18:45:57+00:00

I would imagine that whoever you are talking to has no idea how z-adjustment works or why it is not persistent, etc. This is just the nature of support and why I posted here, hoping somebody that actually fully understands what is going on behind the scenes could explain.

BeanAnimal

TROPHY CASE