N
nn
Ah, I see we have a mainframe programmer among us ...
Ah, I see we have a mainframe programmer among us ...
W
Web Dreamer
Steven D'Aprano a écrit ce mardi 5 juillet 2011 16:25 dans
What he means is that On Mac, if you close "all" windows, the application is
still running.
If you have closed all windows and want to quit an app, you need to click
it's icon (in the dock) or access it via <alt-tab> and explicitly quit it
(in the application's menu, or <cmd-Q>).
Of coarse, for this to work, on Macs, the menu is not in the windows
themselves. The menu is displayed in a menu-bar at the top of the screen,
and changes to match the focussed application.
- Good point about it : If you closed all windows of a heavy application,
you don't need to "relaunch" it to reopen a file (much faster).
- Bad point about it : Most Windows/Linux people I've seen trying a mac for
the first time have lots of apps running, not knowing they didn't close them
(until they ask why their dock is cluttered, or why apps usually in their
dock stay with a "bleu dot" (meaning the app is running)).
Like for every thing else, their are pros and cons.
What he means is that On Mac, if you close "all" windows, the application is
still running.
If you have closed all windows and want to quit an app, you need to click
it's icon (in the dock) or access it via <alt-tab> and explicitly quit it
(in the application's menu, or <cmd-Q>).
Of coarse, for this to work, on Macs, the menu is not in the windows
themselves. The menu is displayed in a menu-bar at the top of the screen,
and changes to match the focussed application.
- Good point about it : If you closed all windows of a heavy application,
you don't need to "relaunch" it to reopen a file (much faster).
- Bad point about it : Most Windows/Linux people I've seen trying a mac for
the first time have lots of apps running, not knowing they didn't close them
(until they ask why their dock is cluttered, or why apps usually in their
dock stay with a "bleu dot" (meaning the app is running)).
Like for every thing else, their are pros and cons.
R
Robin Becker
On 05/07/2011 16:33, nn wrote:
.......
-anciently yrs-
Robin Becker
.......
so long since I manipulated the switches of that old pdp-8Ah, I see we have a mainframe programmer among us ...
-anciently yrs-
Robin Becker
R
rantingrick
Chris are you playing devils advocate (for my team). I am confused?
R
rantingrick
Then that is NOT closing windows that is only ICONIFIYING/HIDING them.
Let's use the correct lingo people!
R
rantingrick
And how do you EXPLICITY quit the application? Because the interface
for window management(on windows box) is three buttons "minimize",
"maximize", and "destroy". If closing the window only "hides" the
window then you are just "managing" a window's "visibility". We are
talking about destroying GUI processes here.
C
Chris Angelico
Chris are you playing devils advocate (for my team). I am confused?
I say whatever I choose to say. Don't pigeon-hole me into "on your
team" or "not on your team" or "devil's advocate" or whatever. And at
two in the morning, "whatever I choose to say" can be quite random.
Actually, it IS closing those windows. Why wouldn't it be?
1) User presses Alt-F4, or clicks the X, or opens the system menu and
chooses 'Close Window'.
2) Windowing manager sends a message to the appropriate thread's queue
(on MS Windows, that's WM_CLOSE; not sure how on Linux as I haven't
bothered to dig that deep - interface layers like Tkinter and GTK
don't count).
2a) Toolkit passes message to application code, if applicable.
3) Application destroys this window, leaving the other windows alive.
The memory used by that window can be reclaimed. Handles to its
objects are no longer valid. The window really is closed. The
application might not have terminated, but that window has not been
minimized - the *window* is closed.
Presumably you would right-click it and choose "Exit" or something. Up
to the application. If all else fails, kill -9 it.
The interface for window management does not actually have "destroy",
it has "close". The normal handling of a close message is to destroy
the window; and in many applications, once all windows have been
destroyed, the process terminates. These are three quite separate
concepts. The separation of "close" and "destroy" is most easily seen
in "Are you sure" prompts - you send a Close signal to the window, but
the application queries you before going through with the destruction.
And even once the last window has been destroyed, that has nothing to
do with process termination.
I could conceivably write a program that sits invisibly in the
background until a network message arrives. Upon receipt of such a
message, the program initializes the GUI subsystem and opens a window.
When the user closes the window, the program flushes all GUI code out
of memory and waits for the next message. While it's waiting, is there
any "main window" that exists but has just been hidden? No. But is the
application still running? Of course! Completely separate.
ChrisA
R
rantingrick
And you need the OS to that for you!?!? Are you joking?
And so could i using Tkinter and it's "supposedly" flawed window
hierarchy. Remind me again why we are discussing this?
C
Chris Angelico
To do what for me? Close windows? Reclaim memory? Terminate
applications? I don't understand your bogglement.
ChrisA
R
rantingrick
ClaimA: I made claim that Tkinter's window hierarchy is not only
normal, but justified in modern GUI programming.
ClaimB: You made a claim ( or supported a rebuttal claim) that Mac's
system of window management was superior and did not need such a
"window hierarchy" simply because;
1. You can create a program that twiddles it's thumbs (using very
little memory) until a message is received.
2. Upon receiving a message the program can open a GUI window.
3. When the user closes the GUI window (definition of "close" is not
nailed down yet!) the program will free the GUI memory and start
twiddling it's thumbs again until the next message arrives.
4. rinse and repeat until you are happy.
It's obvious that yours and my claims are contradicting. So with that
said, at what point does Tkinter or Windows fail in this example you
provide? Because, i can recreate the exact same functionality on a
windows box without need of the underlying window manager's help.
1. What is your point?
2. And how does it prove my position incorrect?
C
Chris Angelico
I never said "better". I just said that it's possible to create an
application that *to the user* has no main window, even though *to the
system* it does. And I'm also pointing out that in most good toolkits,
there's no "main window", but instead a "main thread".
Again, pointing out that it's possible, not that it's good. (Most
messenger programs will have a means of *sending* messages too, which
makes a good basis for a main window.) It's not efficient to keep
loading up GUI libraries and discarding them again. But it's possible,
and it would mean that you genuinely have multiple equal main windows.
Actually, everything you do requires the underlying window manager,
otherwise you're just painting your own pixels on the screen. And I
never said that this model was possible in some and not others.
(Although it's a bit harder with Windows; there's no explicit call to
finalize windowing, so most likely the application will hold GUI
memory until termination.)
ChrisA
R
rantingrick
Ah ha. I think we are getting somewhere now. Everything up to this
point has been mostly exposition
G
Gregory Ewing
rantingrick said:
No, the windows really are closed. They no longer exist
in any way. The application is still running, though, and
its menu bar will appear if you bring it to the front
(in MacOSX this is done by clicking on its dock icon;
in classic MacOS it was done by selecting from the menu
of running applications that was available in the top right
corner of the screen).
G
Gregory Ewing
rantingrick said:
Using its "Quit" menu command.
But that's Mac-specific, and not central to the discussion.
On Linux and Windows, an application will usually exit when
its last window is closed. Either way, there is no need for
a privileged main window.
R
rantingrick
Yes but what benefit does that gain over say, Tkinter's design
(because that has been your argument). I see no benefit at all. I can
destroy a GUI and still have a script run, but what's the point?
If you design a GRAPHICAL user interface, then once the GRAPHICAL part
is removed (window), why do need the main code to stick around? And if
you do, that fact has nothing to do with Tkinter and window hierarchy.
I think we've gone completely off topic here.
Is this another community strawman contest?
Are we mass producing these things now?
S
Steven D'Aprano
rantingrick said:
Open your mind to ideas that go beyond your simple window-centric paradigm!
There is more to graphical user interfaces than windows!
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.
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.
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.
R
rantingrick
Correction: Window-Centric GUI paradigm! BIG DIFFERENCE.
OMG, you mean like, widgets? Whoa! Tell me more, Tell me more!
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.
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.
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. 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!
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)
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. Next you'll suggest
that root windows are really just a great eye, lidless, and wreathed
in flame and that i am Saruman building an army of Orc followers hell
bent on destroying the freedom to believe self serving fantasies.
S
Steven D'Aprano
rantingrick said:
If all the windows are destroyed, and the application still is running and
active, where is your window hierarchy?
The Dead Window Sketch
======================
(with apologies to Monty Python)
Customer enters a pet shop.
Customer: 'Ello, I wish to register a complaint.
Owner: We're closin' for lunch.
Customer: Never mind that, my lad. I wish to complain about this GUI
window what I purchased not half an hour ago from this very
boutique.
Owner: Oh yes, the Norwegian Blue. What's wrong with it?
Customer: I'll tell you what's wrong with it, my lad. It's deleted,
that's what's wrong with it!
Owner: No, no, it's resting!
Customer: Look, matey, I know a deleted window when I see one, and I'm
looking at one right now.
Owner: No no it's not deleted, it's restin'! Remarkable window, the
Norwegian Blue. Beautiful widgets!
Customer: The widgets don't enter into it. It's completely destroyed.
Owner: Nononono, no, no! It's resting!
Customer: All right then, if it's restin', I'll wake it up!
(shouting at the screen) 'Ello, Mister Wally Window! I've got
a lovely fresh icon for you if you show...
(owner hits the screen)
Owner: There, it refreshed!
Customer: No, it didn't, that was you hitting the screen!
Owner: I never!!
Customer: Yes, you did!
Owner: I never, never did anything...
Customer: (yelling and hitting the screen repeatedly) 'ELLO WINDOW!!!
WAKEY WAKEY! This is your notification signal!!!
(takes the window out of the screen and thumps its title bar
on the counter. Throws it up in the air and watches it plummet
to the floor.)
Customer: Now that's what I call a dead window.
Owner: No, no... No, it's stunned!
Customer: STUNNED?!?
Owner: Yeah! You stunned it, just as it was maximising! Norwegian
Blues stun easily.
Customer: Now look, mate, I've definitely 'ad enough of this! That
window is definitely deleted, and when I purchased it not
'alf an hour ago, you assured me that its lack of an entry
in the task bar was due to it bein' tired and shagged out
following a long refresh!
Owner: Well, it's... probably pining for the fjords.
Customer: PININ' for the FJORDS?!?!?!? What kind of talk is that? Look,
why did it fall flat on its back the moment I got it home?
Owner: The Norwegian Blue prefers being minimised on its back!
Remarkable bird, i'nit, squire? Lovely scroll bars!
Customer: Look, I took the liberty of examining that window when I
got it home, and I discovered the only reason that the
window was still visible in the first place was that it
had been NAILED there.
(pause)
Owner: Well, o'course it was nailed there! If I hadn't nailed that
window down, it would have nuzzled up to those pixels, bent
'em apart with its cursor, and VOOM! Feeweeweewee!
Customer: "VOOM"?!? Mate, this window wouldn't "voom" if you put four
million volts through it! Its bleedin' memory is reclaimed!
Owner: No no! It's pining!
Customer: It's not pinin'! It's purged! This window is no more! It's
pointer has ceased to be! It's expired and gone to meet the
memory manager! Bereft of bytes, it rests in peace! If you
hadn't nailed it to the screen it'd be a Flash animation in
a browser by now! It's callbacks are now 'istory! Its ref
count is zero! It's called the garbage collector, its blocks
have been cleared, shuffled off this mortal coil, run down
the curtain and joined the bleedin' choir invisibile!! THIS
IS AN EX-WINDOW!!
(pause)
Owner: Well, I'd better replace it, then.
(he takes a quick peek behind the counter)
Owner: Sorry squire, I've had a look 'round the back of the shop, and
uh, we're right out of windows.
Customer: I see. I see, I get the picture.
Owner: I got a DOS batch file.
(pause)
Customer: (sweet as sugar) Pray, does it talk?
Owner: Yes.
Customer: Right, I'll have that one then.
C
Chris Angelico
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.
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?
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.
*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.
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.)
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.
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
A
Andrew Berg
As much as I hate it when people feed trolls, that was pretty funny.