That's because it's a new option that was not available in Win7.
Is it possible to run windows 7 apps on windows 8 ?
Yes, so long as it's not ARM (and hence running Windows RT).
.Is there an easy means to click on a file and tell it to install it as if it was running on windows 7?
Yes, but only for desktop apps. It doesn't work for the new-style Store apps - the latter can only be installed from the Store (though there are some options for sideloading if you get a free-but-registration-required developer license).
. I installed a virtual machine in windows 7, only to find that my video card didn't have an XP driver other than the default windows one
This doesn't make sense. Your physical video card is not exposed directly to the VM, the VM gets some sort of emulated one, the performance of which depends on which VM software you are using.
I really like the people at Good Old Games that figured out a way to make a large selection games run on a modern
Most of GOG stuff is just the original game packaged together with DOSBox. You can do it yourself for many other titles if you can obtain the original binaries.
The point of vsync is to prevent tearing because rendering framerate does not match the monitor refresh rate. It doesn't matter how slow or fast something goes, it's the disparity that gives tearing, and makes vsync useful.
Too bad that this one is actually made up (since control panel didn't change in any significant way since Win7).
And you can "open" any folder on the system like that - including, say, C:\
Transformers are actually exactly the device category where Win8 makes sense - the original concept was severely hampered by the limitations of Android itself, and apps for it, running on a device with full-fledged keyboard and mouse/trackpad, whereas Win8 is designed for that as much as a touchscreen.
It's because of this.
If the user can bring up the main app window such that it overlaps and covers the dialog, but remains in a modal state where it's inactive until the dialog is closed, that can lead to severe user confusion. Basically, for this to work, you need a cooperative WM that understands the notion of window relationships across process boundaries.
It's not language-level, just as there are no language-level functions methods. But you can always make an explicit vtable in C, and write some macros to hide the virtual dispatch.
Enforcing modality would be a bit tricky for a dialog created by a different process. And if it's non-modal, then what should be the expected behavior if user switches back to the main app and navigates away from wherever it is that he was when he caused the dialog to appear, then switches to the dialog again and opens a file?
If by "anything C++" you mean "anything that forces everyone else to use C++", he'd have very good reasons to be against it.
Qt has bindings to half a dozen different languages, from C# to Python.
FWIW, it's fairly easy to take a C++ library and wrap it in C.
The Chrome tab ordering is better. most-recently-used sucks when you have 20 tabs and have bounced around between them somewhat randomly (as is normal). It makes ctrl-tab completely unpredictable unless you're just jumping back one or two levels. The Chrome way is better.
The point is that Alt+Tab is most-recently-used-app pretty much everywhere, and Ctrl+Tab is most-recently-used-tab (or document) in all multitab apps. This actually makes a lot of sense when you have many tabs open, but are going back and forth between a few of them, e.g. copy pasting text or some such - as GP rightly notes, this is especially common once your tabs run "web apps" rather than just websites.
If you just want to switch to next/prev tab, there's already a shortcut for that, Ctrl+PageUp/Down. Ctrl+Tab is really meant to be the "switch to whatever I was using before" shortcut, fulfilling a different but also very common need.
Don't forget high DPI issues on Windows. It seems like Chrome is still the only app that I actually use that's not high-DPI-aware and so gets bitmap upscaling.
This has nothing to do with the original point of the thread, since you're showing a dependencies of a Gtk 2.x app (and doesn't involve anything from Gnome). OP was claiming that Gtk 3.x introduced dependencies on Gnome.
Which it does.