Implicit initialization is EVIL!

[Chris Angelico]

On Thu, Jul 7, 2011 at 1:10 AM, rantingrick <rantingrick at gmail.com> wrote:
> On Jul 6, 9:32 am, Steven D'Aprano <steve
> +comp.lang.pyt... at 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