Readit NewsThis is the model most Anglophone countries adopt. However, what most miss in this model is that the cost of doing so is much greater than they realize. The most obvious extra cost is the interest paid on mortgages, which can amount to 2-3 times the value of the property by the time the mortgage is fully paid.
A further cost is politically imposed, in that governmental policies will avoid making homes more affordable, as this is perceived as a "loss" by many mortgage-holders and home owners.
I thought this is actually one of those “myths people believe about owning real estate”. In most markets, it is a depreciating asset that takes considerable time and money to maintain at the original capital value. This is why the cost is much higher, like you said, but not exactly for the reason you said. The net present value of that added interest payment is typically very low. It is a competitive market. It is uncertain whether I’d come out ahead or behind if I pay off the mortgage on day 1 or put that equivalent lump sum in the market and use that asset to pay off the mortgage instead. The political cost isn’t merely perceived loss, that is a real loss as it should cause the sale price to reflect the actual depreciation of the asset of an pre-owned house instead of being able to claim the added value of getting ownership.
> Can you speculate on why this problem was only happening with these embedded buttons? Is this a flaw in Qt, or is this application trying to do something unusual?
Why this problem occurred: This is a Qt design issue, not a flaw per se. Qt's item delegate editing model assumes editors are simple widgets (line edits, spin boxes, combo boxes) that don't spawn modal dialogs. When a modal dialog opens:
1. The modal dialog steals focus from the editor button
2. Qt's QAbstractItemView sees the FocusOut event and assumes editing is complete
3. It calls QStyledItemDelegate::destroyEditor() to clean up the editor
4. The button gets deleted while the color dialog is still running
5. When the color dialog closes, it tries to interact with the deleted button
This application is doing something unusual - using a button that spawns a modal dialog as a table cell editor. Most Qt delegates use immediate editing widgets (text fields, dropdowns) that don't require modal interactions.
The eventFilter solution works by intercepting the FocusOut event that triggers editor destruction, essentially telling Qt "I'm still editing, don't destroy me yet."
Yes, that's a valid concern. By blocking FocusOut events, we're preventing Qt's normal editor cleanup mechanism. However, the risk is likely minimal because:
1. Qt still cleans up eventually - The editor will be destroyed when the table view itself is destroyed or when editing truly ends (e.g., clicking elsewhere, pressing Enter/Escape)
2. Short-lived editors - These editor widgets are typically very short-lived (created when editing starts, destroyed when editing ends)
3. Parent widget cleanup - Since the button has a parent widget, Qt's parent-child ownership will clean it up when the parent is destroyed
To be completely safe, we could add a more targeted approach - only block FocusOut events while a color dialog is actively open, rather than blocking all FocusOut events. We could track when the modal dialog is shown/hidden and only filter during that window.
But for this use case, the current solution should be fine since:
- Color picking is infrequent
- The editor lifetime is still bounded by the table view's normal lifecycle
- Qt's parent-child cleanup provides a safety net
The memory usage impact should be negligible compared to the complexity of implementing more sophisticated tracking.
I've definitely had less-satisfying discussions over bugs with actual human senior software engineers than this.
Ughh, this brings bad memories of the days I spent trying to diagnose why glibc often would give wrong answers for some users and not other users (they’ve since mitigated this problem slightly by combining pthreads and libdl into the same library). I wish they would get rid of this, since even the comment on it notes that the optimization is unsound (the ability to make syscalls directly, as used by go and others, makes this optimization potentially dangerous). It also upsets static analysis tools, since they see that glibc doesn’t appear to have the synchronization the library promises.
With that in mind, housing associations or co-ops and the like take the place of banks, that is, they possess the capital and rent the property to the residents, but keep a portion of the revenue for future renting, as a bank does for future lending.
The difference between the two is that the housing association is typically not-for-profit, and that in a housing association the resident does not accumulate capital, which allows for a reduction in costs compared to a mortgage.
Which makes me wonder: how many permutations of this rule could be conceived (and needed) that on the one hand would keep the point clear to the receiver, but on the other hand prevent such attacks?
In any case the best option is to not have (to repeat) this rule inside messages.
It can be, but it doesn't have to be. DisplayPort is mostly a superset of HDMI, with different voltage levels. Going from HDMI to DisplayPort is much harder than going from DisplayPort to HDMI, though the hardware to do this is apparently much cheaper than it used to be, which is nice to see.
DisplayPort to HDMI only requires level shifting, as I understand it. I'm sure someone will correct me if they see this and I'm wrong.
But also yes, most display port implementations also speak hdmi and can get away with simple converters