On Thu, Jul 7, 2011 at 1:10 AM, rantingrick <rantingr...@gmail.com> wrote: > On Jul 6, 9:32 am, Steven D'Aprano <steve > +comp.lang.pyt...@pearwood.info> wrote: >> Open your mind to ideas that go beyond your simple window-centric paradigm! > > Correction: Window-Centric GUI paradigm! BIG DIFFERENCE. > >> There is more to graphical user interfaces than windows! > > OMG, you mean like, widgets? Whoa! Tell me more, Tell me more!
Okay, Window-Centric GUI Paradigm. There's still more to it than windows and widgets and mouse cursors and so on. Underneath it all is CODE. In some graphical applications, the code is relatively trivial. A desktop calculator is just there to get input graphically and give output graphically. In those, once you destroy the window, you may as well terminate the application. But in others the code drastically outweighs the windowing work. I don't have a good example handy, but I have a bad example; our (antique) accounting package has an hours-long year end process that we do at the beginning of each July, and it chugs through its database work while painting a pretty animation of a hand scribing a book. It would be far more efficient to simply close the window and proceed with the work; but the window was necessary for collecting certain parameters from the user, prior to the start of the long job. There's more to a windowed program than its window. >> In the Mac OS GUI, an application can have a menubar and no windows. Windows >> come and go as needed, but the menubar stays until the users quits the >> application. > > That's just window visibility (whether by hiding or destroying) under > the veil of a detached UI window manager bar and has nothing to do > with window hierarchy. Your half stuffed straw men are leaking like a > sieve Steven. It can be implemented with window visibility. That's not the same thing. If I want to be in Sydney tomorrow, I want to cease existing here and begin existing there. That can be implemented by burning petrol in an internal combustion engine and turning some rubber wheels. If I turn up in Sydney tomorrow, and argue vehemently that I did not drive, are you going to insist that I did, or would you accept that perhaps I took a train instead? >> In the Unix/Linux world, there is a graphical application called xkill which >> has no menus and no windows, all it has is a mouse cursor! No, it does not >> run in the background: it is a foreground app. > > Wow nice corner case. Can you come up with at least five of them > though? You and I both know that the vast majority of GUI's require > visible windows. Five corner cases. Okay. One is xkill; if I can find four more, we run out of corners and they're not corner cases any more - is that it? 1) See above. 2) Win2VNC. Doesn't actually paint a window on the screen, it just watches where the mouse goes - move the mouse off the edge of the screen, and it wraps and hides it. Very cool. 3) Firewall software with a graphical config notebook. I think ZoneAlarm actually just hides its window, but that's not strictly necessary. (My preferred firewall setup, though, has no GUI at all - iptables etc is all I need.) 4) Clipboard Converter. An old app that I wrote a while ago that, whenever you copy anything to the clipboard, runs it through a script and puts the result back on the clipboard. Handier than you might think. 5) Hotkey manager. It watches for keystrokes and replaces them with other actions. Implemented as an input hook with injection facilities. Enjoy. > But wait! What is a GUI WINDOW exactly? > > I'll tell you in the simplest terms i can muster... GUI "windows" are > an abstraction and nothing more. *Everything* in a computer is an abstraction. People are fond of saying that computers only work with 1s and 0s - that's not strictly true, those numbers represent electrical signals. And those electrical signals represent data which usually carries information. It's turtles all the way down. > A GUI window is nothing more than an > imaginary area of the screen that can be drawn to. This area has > borders that define it. No not visible borders but two dimensional > spacial borders. THAT'S IT! The area could be 1x1 pixels OR the entire > screen space, OR even larger! Leaving off the "imaginary", all you're saying is that a window is a rectangular area of screen. That's not quite true; not all windows/widgets have a painting area. A window is an object - and that object can choose to request certain resources, including a portion of its parent window's painting area if desired. (A top-level window's parent is either a Screen or a Desktop, depending on your implementation.) > Most time you want the user to see the boundaries of this abstraction > (window) space and so the GUI library draws borders that represent > this boundary. Your "supposedly" windowless xkill application is not > windowless at all; THE WINDOW BOUNDARIES ARE JUST NOT DRAWN! The > window is the entire screen space OR IS JUST THE DESKTOP SPACE (same > thing) Boundaries have nothing to do with it being a window or not. The windowless xkill does NOT HAVE a window. If it had a borderless window that covered the entire desktop, you would not be able to click on any other window, thus making xkill ... somewhat useless. >> An extreme case, but telling. There is no absolute need for any windows at >> all, let alone for one privileged window to rule all the others. > > Again your fear of losing "imaginary" freedoms is acting out again. > And your veiled attempts to link root GUI windows and Sauron (the > great antagonist of LOTH) is quite entertaining. What, the One Ring is the only entity that ever wished to rule over all of something? *boggle* I regret that I am now in the position of following an awesome post with a somewhat mediocre one. Steven, the Dead Window Sketch is awesome! ChrisA -- http://mail.python.org/mailman/listinfo/python-list
