rantingrick wrote:
> On Jul 7, 8:25 pm, Steven D'Aprano +comp.lang.pyt...@pearwood.info> wrote:
>> rantingrick wrote:
>> > On Jul 7, 12:34 am, Gregory Ewing wrote:
>> >> The important thing is that it's okay for an app to stay
>> >> alive until its *last* top level window is closed.
>>
>> I part
On Jul 7, 8:25 pm, Steven D'Aprano wrote:
> rantingrick wrote:
> > On Jul 7, 12:34 am, Gregory Ewing wrote:
> >> The important thing is that it's okay for an app to stay
> >> alive until its *last* top level window is closed.
>
> I partially disagree with Greg on this. This is not the only model:
On 2011.07.07 12:29 PM, rantingrick wrote:
> So you prefer to close a gazillion windows one by one? If so, why not
> just code the GUI correctly from the start; by creating separate
> transactions? Thereby reducing the number of windows a user must
> juggle? FYI: You know the user complexity of a G
rantingrick wrote:
So you prefer to close a gazillion windows one by one?
If I want to close all the windows, I can use the application's
"Quit" or "Exit" command, or whatever the platform calls it.
(Note that if there is a separate instance of the application
for each window -- as was sugges
rantingrick wrote:
> On Jul 7, 12:34 am, Gregory Ewing wrote:
>> The important thing is that it's okay for an app to stay
>> alive until its *last* top level window is closed.
I partially disagree with Greg on this. This is not the only model: on the
Apple Mac, or any system with a similar GUI
On Fri, Jul 8, 2011 at 3:29 AM, rantingrick wrote:
> So your argument is:
> """ A window hierarchy is bad because if your application requires
> a user to open a gazillion windows (read as: designed poorly) --each
> representing completely different transactions-- and if you close the
> origina
On Jul 7, 12:34 am, Gregory Ewing wrote:
> rantingrick wrote:
> > Yes but what benefit does that gain over say, Tkinter's design
> > (because that has been your argument).
>
> Like I said, it's a tangential issue.
Agreed.
> The important thing is that it's okay for an app to stay
> alive until i
rantingrick wrote:
Yes but what benefit does that gain over say, Tkinter's design
(because that has been your argument).
Like I said, it's a tangential issue.
The important thing is that it's okay for an app to stay
alive until its *last* top level window is closed. There
doesn't have to be a
On Thu, Jul 7, 2011 at 5:15 AM, Ian Kelly wrote:
> On Wed, Jul 6, 2011 at 12:36 PM, Andrew Berg
> wrote:
>> On 2011.07.06 01:19 PM, rantingrick wrote:
>>> ##
>>> The Roman Stawman Sketch
>>> ##
>> Nice try, but you have to use a Monty Python sketc
On 06/07/2011 20:15, Ian Kelly wrote:
On Wed, Jul 6, 2011 at 12:36 PM, Andrew Berg wrote:
On 2011.07.06 01:19 PM, rantingrick wrote:
##
The Roman Stawman Sketch
##
Nice try, but you have to use a Monty Python sketch (and you have to
spell corr
On Wed, Jul 6, 2011 at 12:36 PM, Andrew Berg wrote:
> On 2011.07.06 01:19 PM, rantingrick wrote:
>> ##
>> The Roman Stawman Sketch
>> ##
> Nice try, but you have to use a Monty Python sketch (and you have to
> spell correctly :-P ).
Seriously. The
On 2011.07.06 01:19 PM, rantingrick wrote:
> ##
> The Roman Stawman Sketch
> ##
Nice try, but you have to use a Monty Python sketch (and you have to
spell correctly :-P ).
--
http://mail.python.org/mailman/listinfo/python-list
On Jul 6, 11:11 am, Steven D'Aprano wrote:
> The Dead Window Sketch
> ==
>
> [snip]
##
The Roman Stawman Sketch
##
[cmp.lang.python]:
(The trolls are gathered and a righteous man speaks.)
GRACCHUS: For your guidance TrollCae
Five more good entries (though I think #8 and #9 are mostly covered
already). But hey, we have at least an octagon to work in.
On Thu, Jul 7, 2011 at 3:37 AM, Tim Chase wrote:
> I think there are sufficiently many edge cases this formerly-square room is
> starting to look round...
The room is st
Andrew Berg wrote:
> On 2011.07.06 11:11 AM, Steven D'Aprano wrote:
>> The Dead Window Sketch
>> ==
> As much as I hate it when people feed trolls, that was pretty funny.
Thanks.
Re the troll-feeding, every few months I get a strange seizure in my brain
that compels me to int
On 07/06/2011 11:24 AM, Chris Angelico wrote:
On Thu, Jul 7, 2011 at 1:10 AM, rantingrick wrote:
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 ca
Dnia Wed, 6 Jul 2011 08:10:27 -0700 (PDT), rantingrick napisał(a):
>> 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 cas
On 2011.07.06 11:11 AM, Steven D'Aprano wrote:
> The Dead Window Sketch
> ==
As much as I hate it when people feed trolls, that was pretty funny.
--
http://mail.python.org/mailman/listinfo/python-list
On Thu, Jul 7, 2011 at 1:10 AM, rantingrick wrote:
> On Jul 6, 9:32 am, Steven D'Aprano +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 graphic
rantingrick wrote:
>> 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
On Jul 6, 9:32 am, Steven D'Aprano wrote:
> rantingrick wrote:
> > If you design a GRAPHICAL user interface, then once the GRAPHICAL part
> > is removed (window), why do need the main code to stick around?
>
> Open your mind to ideas that go beyond your simple window-centric paradigm!
Correction:
rantingrick wrote:
> If you design a GRAPHICAL user interface, then once the GRAPHICAL part
> is removed (window), why do need the main code to stick around?
Open your mind to ideas that go beyond your simple window-centric paradigm!
There is more to graphical user interfaces than windows!
In t
On Jul 6, 1:12 am, Gregory Ewing wrote:
> rantingrick wrote:
> >>What he means is that On Mac, if you close "all" windows, the application is
> >>still running.
>
> > Then that is NOT closing windows that is only ICONIFIYING/HIDING them.
>
> No, the windows really are closed. They no longer exist
rantingrick wrote:
And how do you EXPLICITY quit the application?
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 mai
rantingrick wrote:
What he means is that On Mac, if you close "all" windows, the application is
still running.
Then that is NOT closing windows that is only ICONIFIYING/HIDING them.
No, the windows really are closed. They no longer exist
in any way. The application is still running, though,
On Jul 5, 7:34 pm, Chris Angelico wrote:
> 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'
On Wed, Jul 6, 2011 at 10:15 AM, rantingrick wrote:
> On Jul 5, 6:54 pm, Chris Angelico wrote:
>
>> To do what for me? Close windows? Reclaim memory? Terminate
>> applications? I don't understand your bogglement.
>
> ClaimA: I made claim that Tkinter's window hierarchy is not only
> normal, but j
On Jul 5, 6:54 pm, Chris Angelico wrote:
> To do what for me? Close windows? Reclaim memory? Terminate
> applications? I don't understand your bogglement.
ClaimA: I made claim that Tkinter's window hierarchy is not only
normal, but justified in modern GUI programming.
ClaimB: You made a claim (
On Wed, Jul 6, 2011 at 9:47 AM, rantingrick wrote:
>> > Then that is NOT closing windows that is only ICONIFIYING/HIDING them.
>> > Let's use the correct lingo people!
>>
>> Actually, it IS closing those windows. Why wouldn't it be?
>> [...]
>> The memory used by that window can be reclaimed. Hand
On Jul 5, 6:20 pm, Chris Angelico wrote:
> On Wed, Jul 6, 2011 at 8:42 AM, rantingrick wrote:
> [...]
> > On Jul 5, 11:00 am, Web Dreamer wrote:
> >> What he means is that On Mac, if you close "all" windows, the application
> >> is
> >> still running.
>
> > Then that is NOT closing windows that
On Wed, Jul 6, 2011 at 8:42 AM, rantingrick wrote:
> 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 cho
On Jul 5, 6:14 am, Gregory Ewing wrote:
> rantingrick wrote:
> > Most applications consist of one main window
> > (a Tkinter.Tk instance).
>
> You've obviously never used a Macintosh. On the Mac, it's
> perfectly normal for an application to open multiple
> documents, each in its own window, with
On Jul 5, 11:00 am, Web Dreamer wrote:
> What he means is that On Mac, if you close "all" windows, the application is
> still running.
Then that is NOT closing windows that is only ICONIFIYING/HIDING them.
Let's use the correct lingo people!
--
http://mail.python.org/mailman/listinfo/python-li
On Jul 5, 10:17 am, Chris Angelico wrote:
> It's actually quite easy to implement this, even if you _are_ forced
> to have one primary window. You just have an invisible primary whose
> sole purpose is to "be the application", and then everything else is
> secondary windows. Kinda defeats the pur
On 05/07/2011 16:33, nn wrote:
..
Ah, I see we have a mainframe programmer among us ... :-)
so long since I manipulated the switches of that old pdp-8
-anciently yrs-
Robin Becker
--
http://mail.python.org/mailman/listinfo/python-list
On Jul 4, 11:35 am, Robin Becker wrote:
> On 03/07/2011 23:21, Chris Angelico wrote:
> .
>
> > var(0x14205359) x # Don't forget to provide an address where the
> > object will be located
> > x=42
>
>
> did you forget to specify the memory bank and computer (and presumably planet
On Wed, Jul 6, 2011 at 12:25 AM, Steven D'Aprano
wrote:
> Gregory Ewing wrote:
>
>> You've obviously never used a Macintosh. On the Mac, it's
>> perfectly normal for an application to open multiple
>> documents, each in its own window, with no one window
>> being the "main" window. Any of them can
Gregory Ewing wrote:
> rantingrick wrote:
>> Most applications consist of one main window
>> (a Tkinter.Tk instance).
>
> You've obviously never used a Macintosh. On the Mac, it's
> perfectly normal for an application to open multiple
> documents, each in its own window, with no one window
> bein
rantingrick wrote:
Most applications consist of one main window
(a Tkinter.Tk instance).
You've obviously never used a Macintosh. On the Mac, it's
perfectly normal for an application to open multiple
documents, each in its own window, with no one window
being the "main" window. Any of them can
rantingrick wrote:
You say "root" windows are bad however any parent-child relationship
has to BEGIN somewhere.
There's no need for *toplevel* windows to be children
of anything, though.
HOWEVER any of the windows ARE in fact
instances of Tk.Toplevel[1]. So they ARE all equal because they al
On 03/07/2011 23:21, Chris Angelico wrote:
.
var(0x14205359) x # Don't forget to provide an address where the
object will be located
x=42
did you forget to specify the memory bank and computer (and presumably planet
etc etc)
-molly-coddled-ly yrs-
Robin Becker
--
http:/
On Tue, Jul 5, 2011 at 5:30 AM, rantingrick wrote:
> Umm, if you want to see where things are "going" you should learn
> about the inner workings of chrome which actually spawns a new process
> for every tab created; which has the benefit of avoiding application
> lock up when one page decides to
On Jul 4, 12:41 pm, Chris Angelico wrote:
> For another example, look at where web browsers are going. By your
> description, one instance of a browser should work with precisely one
> "document" (which in this case would be a web page). That's how
> browsers were in the early days, but by the ea
On Tue, Jul 5, 2011 at 3:09 AM, rantingrick wrote:
> On Jul 4, 11:01 am, Chris Angelico wrote:
>> This is not
>> a modal dialog; it's not even a modeless dialog - it's a completely
>> stand-alone window that can be moved around the Z order independently
>> of the parent.
>
> You can do the exact
On Jul 4, 11:01 am, Chris Angelico wrote:
> On Tue, Jul 5, 2011 at 1:46 AM, rantingrick wrote:
> > On Jul 4, 10:40 am, Chris Angelico wrote:
>
> >> Uhh, sorry. No. There are plenty of good reasons for one application
> >> to make multiple top-level windows, and if I ever find myself using a
> >>
On Tue, Jul 5, 2011 at 1:46 AM, rantingrick wrote:
> On Jul 4, 10:40 am, Chris Angelico wrote:
>
>> Uhh, sorry. No. There are plenty of good reasons for one application
>> to make multiple top-level windows, and if I ever find myself using a
>> toolkit that makes this difficult, I'll either be ha
oops. should have used symmetric_difference!
>>> a.symmetric_difference(b)
set(['_w', '_setup', 'report_callback_exception', '_do',
'__getattr__', 'loadtk', '_loadtk', 'readprofile'])
--
http://mail.python.org/mailman/listinfo/python-list
On Jul 4, 10:40 am, Chris Angelico wrote:
> Uhh, sorry. No. There are plenty of good reasons for one application
> to make multiple top-level windows, and if I ever find myself using a
> toolkit that makes this difficult, I'll either be hacking the toolkit
> or using a different one. I've been bu
On Tue, Jul 5, 2011 at 1:19 AM, rantingrick wrote:
> But let's dig a little deeper here. Your comment suggests that you
> "personally" need to create multiple windows for your applications. Is
> this correct? If so i pity any users of such application as they would
> be thoroughly confused. Most a
On Jul 4, 3:44 am, Chris Angelico wrote:
> I don't know Tkinter, but from the look of the example code, he's
> creating a Label that's not attached to a window, and then packing it
> into nothing. The toolkit kindly creates him a window. Is that the
> "root GUI window" that he means? A basic top-
On Jul 4, 3:33 am, Gregory Ewing wrote:
> IMO the real problem here is the existence of a privileged
> "root" window at all. No GUI platform I know of has any
> such concept (except for a "desktop" window that represents
> the whole screen, which is not the same thing). All top-level
> windows sh
On Mon, Jul 4, 2011 at 6:33 PM, Gregory Ewing
wrote:
> rantingrick wrote:
>
>> Unlike most GUI libraries the Tkinter developers thought is would
>> "just wonderful" if the root GUI window just sprang into existence if
>> the programmer "somehow" forgot to create one.
>
> IMO the real problem here
rantingrick wrote:
Unlike most GUI libraries the Tkinter developers thought is would
"just wonderful" if the root GUI window just sprang into existence if
the programmer "somehow" forgot to create one.
IMO the real problem here is the existence of a privileged
"root" window at all. No GUI plat
In article ,
Chris Angelico wrote:
> var(0x14205359) x # Don't forget to provide an address where the
> object will be located
> x=42
>
> After all, everyone's gotta learn about segfaults some day!
0x14205359 is more likely to give a bus error (odd address) than a
segfault :-)
--
http://ma
On Mon, Jul 4, 2011 at 8:11 AM, rantingrick wrote:
> A new user should learn from day one the hierarchy of a GUI.
>
> -root window
> -optional widgets
> --optional sub windows
> ---optional widgets
> ---and on and on
You're forgetting all the other crucial parts of the hierarchy. A new
user shoul
Tkinter has a major flaw and this flaw has been with us for many many
years. What is the flaw? Well the title says it all folks... IMPLICIT
INITIALIZATION IS EVIL. Still confused, well let me explain.
Unlike most GUI libraries the Tkinter developers thought is would
"just wonderful" i
56 matches
Mail list logo
