Comment by ridiculous_fish
4 years ago
I understand the backwards compatibility case for APIs, but not for OS dialogs. Is there a compatibility reason why the folder properties dialog is crufty (unresizable, etc)? I always just assumed there was no engineering appetite or business case to work on it.
Non-resizable dialogs are one of the top reasons why I cannot stand Windows and find it a huge pain to work with as a non-regular user.
Now, while I can understand the sibling's point about third-party overlays [0] which may break when the windows suddenly become resizable, what I find absolutely infuriating is that even what seem like recent features still inherit this stupid behavior.
The thing that I'm reminded of is "Windows Defender Exceptions" (or similar, don't have a Windows box at hand). Those are configured through a new, Settings App-looking window.
Now I understand this is somehow different, because even though the window vaguely looks like the Settings App (huge icons, tons and tons of whitespace), it behaves very differently.
This "exceptions" panel shows a list of the folders that is fixed, although the outer window can be resized. So if you've got a big high-res screen and maximize it, you'll get 90% of blank space and will still have to scroll around to see the contents. Bonus points for the list being so skinny that I'm only able to see "C:\Users\vlad\..." and have to click on each entry to see it in full.
I sometimes jokingly say that it shows MS has a mouse business, and having to click a thousand times for the simplest of things is by design.
---
[0] Not sure what those are. Do random third-parties "augment" system dialogs by drawing random stuff on top of them? I find that thought horrendous.
>[0] Not sure what those are. Do random third-parties "augment" system dialogs by drawing random stuff on top of them? I find that thought horrendous.
The common example would be Dell/Synaptics adding their own tabs to the old Mouse system dialog.
I think the idea was quite sensible. Keeping the configuration in one place while supporting whatever features the manufacturers might have added e.g. touch pad gestures.
The only reason it's unfortunate is that the new dialogs don't support the old extension mechanism, forcing the old dialogs to be kept around.
> I think the idea was quite sensible. Keeping the configuration in one place while supporting whatever features the manufacturers might have added e.g. touch pad gestures.
I agree, but I thought that there was some sort of extension functionality, along the lines of "this is a mouse configuration panel, register it to [something] so that it's added to the mouse settings".
If any program tweaks a dialog, say by floating a title-barless window with a new control on top of some empty space (possibly after slightly resizing the window or a control in the window to make space), you can’t resize any window control, can’t change tab order, can’t add controls, can’t change background color, etc.
Detecting whether that is being done is challenging. Typical workaround is that, if any callback is registered with a dialoog, to keep things ‘as is’.
Wow! There really are programs which plug into dialogs in this way? Well, that's a new level of compatibility hell. Thanks for the answer.
In the days before heavy security it was quite possible for programs to monkey around with other programs' UI in all sorts of way. A lot of that is still possible from an administrator or SYSTEM-privileged context. Some 15 years ago I wrote an Internet Explorer addon that added stuff to the statusbar by hooking into the IE window's message pump and intercepting winforms calls. Shit was wild.
Growing up in the 90s, I remember an article in Visual Basic Programmer's Journal teaching subclassing in VB by hooking into Notepad and adding a font picker (via a new menu entry that opens the font dialog) to change the text control's typeface. (This was long before MS added that same feature)
Yes, Windows is a kind of OOP based OS at its "kernel" (not to mix with OS kernel).
So one way to extend UI components, since its inception, is to request the Windowsclass structure of an existing control, replace its event handler function and then call the "base class" handler for the built in behavior.
Look at Autohotkey for a starter down the rabbit hole of "we don't need APIs, we have a GUI!" and the fallout of people desperately working around it.
2 replies →
A typical scenario is saving as jpg, where you really want to provide the user the option to select compression level.
That typically is for a single program, though, and by that program. System-wide changes, for example for a product that can compress files on the fly, affect every program using open dialogs.
You say that, but that's standard operating procedure for plugins on web pages.
A node you create could be arbitrarily changed or removed.
> If any program tweaks a dialog, say ...
Yes. They should not have allowed this at all in hindsight. Well, too late. :-)