Editing 1479: Troubleshooting
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 8: | Line 8: | ||
==Explanation== | ==Explanation== | ||
− | + | {{incomplete|The explanation of the title text is missing.}} | |
− | + | The humor of this comic revolves around the fact that due to complexity and somewhat low quality of the modern software, the reasons for many problems that users experience (and possible solutions) are not obvious and straightforward and methods for repairing the problem often rely on invoking certain seemingly irrelevant actions that happen to cause a desired side-effect. As the author points out, knowing these non-obvious ways to repair the problems requires memorization of lots of "stupid computer knowledge" rather than relying on logic and understanding of general principles of software. By "stupid", of course, he means "seemingly irrelevant". | |
− | + | In many cases, Randall (or Cueball as his avatar) loves to help people using his specific knowledge (see [[208: Regular Expressions]]). But when the trick is "stupid", he would prefer the programmers to fix the problem definitively so he never has to rely on this trick anymore. | |
− | + | One particular example of an illogical fix to a software problem is depicted in the comic. Here, [[Cueball]] is trying to help [[Hairy]] resolve the problem of lack of response from the software application to any mouse clicks. A suggestion is made that this is not due to abnormal behavior of the software ("freezing"), but rather because either the user or the software itself has opened a {{w|Modal dialog|modal dialog window}} with coordinates outside of the main screen area, where it can not be seen. Modal dialog windows in desktop operating systems by design get the sole focus of the user input when launched, blocking access to the rest of the application window. They are valid {{w|GUI}} tools and are used when the software needs user's input before it can proceed further. However, opening such window and placing it outside of the visible screen area ("off-screen") will make the window both inaccessible and invisible to the user, precluding him/her from closing it and re-gaining access to the software. | |
− | + | One non-obvious way to repair such problem is to switch the screen resolution outside of the program experiencing the problem (using operating system configuration tools) to some other resolution and then switch the resolution back to normal. Switching the resolution in itself does not fix the problem (as often the highest resolution is being used so one can rarely switch to higher resolution to gain access to the modal dialog stuck in "off-screen" area), instead the fix relies on the fact the in many desktop operating systems the resolution switch also forces the operating system to redraw all windows on the desktop (which in itself is a logical and normal action) and, while doing so, some operating systems will also reevaluate the appropriateness of the coordinates of all windows and adjust these coordinates so that the windows do not end up in off-screen area after the resolution change. The latter is also a logical and prudent action by the operating system, however, in our scenario it is used as a side-effect to fix the problem. This is due to the fact that the operating systems rarely provide other, more obvious ways to bring the off-screen windows back to the visible area. | |
− | |||
− | |||
− | |||
− | |||
− | + | By saying "Why is it even possible?", Hairy is quite correct in pointing out that the best way to address this problem at its root would be for the operating system developers to implement a mechanism that prevents the creation of modal dialog windows in off-screen area to begin with. Such mechanism could perform the coordinate adjustment of such windows during the time of their creation, thus making sure that the modal dialog window would always be accessible and visible. | |
− | In | + | In general, one can sort the possible solutions to the problem being discussed in the following order of preference, from best to worst: |
+ | * (Best): Have OS programmers implement automatic coordinate adjustment during window creation | ||
+ | * Have OS programmers provide easily accessible and visible control to invoke coordinate adjustment for all windows | ||
+ | * Have OS programmers provide a shortcut to invoke coordinate adjustment for all windows | ||
+ | * (Worst, depicted in comic): Have users rely on side-effect of properly implemented screen resolution change mechanism to fix the problem counter-intuitively. | ||
==Transcript== | ==Transcript== | ||
Line 34: | Line 34: | ||
:Hairy: ''Seriously?'' | :Hairy: ''Seriously?'' | ||
:Cueball: I know, I know... | :Cueball: I know, I know... | ||
− | |||
− | |||
{{comic discussion}} | {{comic discussion}} | ||
− | |||
− | |||
− |