From saimadhavheblikar at gmail.com  Sun Jun  8 15:55:44 2014
From: saimadhavheblikar at gmail.com (Saimadhav Heblikar)
Date: Sun, 8 Jun 2014 19:25:44 +0530
Subject: [Tkinter-discuss] About making Text.tag_*range methods more
	consistent
Message-ID: <CAO3PiBgWAkM6eUnpJjZoS3a9FjamFMPjw5q+zy_4Y_JudSUm-g@mail.gmail.com>

Some code,

>>> from tkinter import Text
>>> text = Text()
>>> text.pack()
>>> text.insert('insert', 'ab cd ef')
>>> text.tag_add('red', '1.0','1.2')
>>> text.tag_add('red', '1.6', '1.8')
>>> text.tag_prevrange('red', 'end')
('1.6', '1.8')
>>> text.tag_ranges('red')
(<textindex object: '1.0'>, <textindex object: '1.2'>, <textindex object:
'1.6'>, <textindex object: '1.8'>)
>>> text.tag_nextrange('red', '1.0')
('1.0', '1.2')

I propose that Text.tag_ranges(tag) return a list of tuples (start index,
end index), instead of a list like [start index1, endindex1, startindex2,
endindex2....etc]

To be more even more consistent, tag_ranges tuples should contain indexes
similar to the ones returned by tag_prevrange/tag_nextrange i.e. strings
instead of textindex objects.

So, the above output would have been
>>> text.tag_ranges('red')
(('1.0', '1.2'), ('1.6', '1.8'))

If there is a reason for current behavior, can you link me to it?
-- 
Regards
Saimadhav Heblikar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20140608/e2c16a71/attachment.html>

From saimadhavheblikar at gmail.com  Sun Jun  8 16:30:06 2014
From: saimadhavheblikar at gmail.com (Saimadhav Heblikar)
Date: Sun, 8 Jun 2014 20:00:06 +0530
Subject: [Tkinter-discuss] About making Text.tag_*range methods more
	consistent
Message-ID: <CAO3PiBhLC4EDHXa_2CA8CagafUTS1rWyD9MBmBVmovAPTDKBZQ@mail.gmail.com>

Some code,

>>> from tkinter import Text
>>> text = Text()
>>> text.pack()
>>> text.insert('insert', 'ab cd ef')
>>> text.tag_add('red', '1.0','1.2')
>>> text.tag_add('red', '1.6', '1.8')
>>> text.tag_prevrange('red', 'end')
('1.6', '1.8')
>>> text.tag_ranges('red')
(<textindex object: '1.0'>, <textindex object: '1.2'>, <textindex object:
'1.6'>, <textindex object: '1.8'>)
>>> text.tag_nextrange('red', '1.0')
('1.0', '1.2')

I propose that Text.tag_ranges(tag) return a list of tuples (start index,
end index), instead of a list like [start index1, endindex1, startindex2,
endindex2....etc]

To be more even more consistent, tag_ranges tuples should contain indexes
similar to the ones returned by tag_prevrange/tag_nextrange i.e. strings
instead of textindex objects.

So, the above output would have been
>>> text.tag_ranges('red')
(('1.0', '1.2'), ('1.6', '1.8'))

If there is a reason for current behavior, can you link me to it?

-- 
Regards
Saimadhav Heblikar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20140608/faebe2af/attachment.html>

From klappnase at web.de  Mon Jun  9 08:36:25 2014
From: klappnase at web.de (Michael Lange)
Date: Mon, 9 Jun 2014 08:36:25 +0200
Subject: [Tkinter-discuss] About making Text.tag_*range methods more
 consistent
In-Reply-To: <CAO3PiBgWAkM6eUnpJjZoS3a9FjamFMPjw5q+zy_4Y_JudSUm-g@mail.gmail.com>
References: <CAO3PiBgWAkM6eUnpJjZoS3a9FjamFMPjw5q+zy_4Y_JudSUm-g@mail.gmail.com>
Message-ID: <20140609083625.32e1fb8fd4c5d5f345d35192@web.de>

Hi,

On Sun, 8 Jun 2014 19:25:44 +0530
Saimadhav Heblikar <saimadhavheblikar at gmail.com> wrote:

> Some code,
> 
> >>> from tkinter import Text
> >>> text = Text()
> >>> text.pack()
> >>> text.insert('insert', 'ab cd ef')
> >>> text.tag_add('red', '1.0','1.2')
> >>> text.tag_add('red', '1.6', '1.8')
> >>> text.tag_prevrange('red', 'end')
> ('1.6', '1.8')
> >>> text.tag_ranges('red')
> (<textindex object: '1.0'>, <textindex object: '1.2'>, <textindex
> object: '1.6'>, <textindex object: '1.8'>)
> >>> text.tag_nextrange('red', '1.0')
> ('1.0', '1.2')
> 
> I propose that Text.tag_ranges(tag) return a list of tuples (start
> index, end index), instead of a list like [start index1, endindex1,
> startindex2, endindex2....etc]
> 
> To be more even more consistent, tag_ranges tuples should contain
> indexes similar to the ones returned by tag_prevrange/tag_nextrange
> i.e. strings instead of textindex objects.

I don't think that these textindex objects are intentional, they might be
worth a bug report. I have encountered similar objects instead of the
expected return values from tk methods at what appears to me as "random"
places from time to time with hevery new version for years since the
Tkinter developers invented the "object layer" (sorry, no idea how they
actually call it) in Python-2.4 or so. In Python2 you can disable
it altogether by setting Tkinter.wantobjects = False early in your code
to restore the "classic" behavior, unfortunately this does not seem to
work in Python3 anymore (at least the last time I tried). Probably these
objects can easily be converted into strings if you know where they
appear.

> 
> So, the above output would have been
> >>> text.tag_ranges('red')
> (('1.0', '1.2'), ('1.6', '1.8'))

I don't know if there is a special reason why they did not use "nested"
tuples, maybe it is simply because in the early development of Tkinter
they tended to keep as close to the original Tk behavior as possible.
Otherwise they might have even turned the index strings, as "1.6" into
tuples; I don't feel this is a big issue, though, once you get used to it.

Best regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

	"It's hard to believe that something which is neither seen nor
felt can do so much harm."
	"That's true.  But an idea can't be seen or felt.  And that's
what kept the Troglytes in the mines all these centuries.  A mistaken
idea."
		-- Vanna and Kirk, "The Cloud Minders", stardate 5819.0

From tpadilha84 at gmail.com  Tue Jun 10 23:59:40 2014
From: tpadilha84 at gmail.com (Thiago Padilha)
Date: Tue, 10 Jun 2014 18:59:40 -0300
Subject: [Tkinter-discuss] Text widget "lags" when doing fast updates with
	increased window heights
Message-ID: <CAAq2XdqdAEu7bqLxsFUdU9feGkwcZaL5977UaAoaXkvpLs6K7g@mail.gmail.com>

I'm currently implementing a sample UI for neovim(http://neovim.org/),
and decided to use Tkinter/python due to the popularity/simplicity of
the platforms. The problem I'm having is that tkinter seems to "stack"
UI updates when the window height crosses a certain threshold.

Here is a video that shows the problem: http://youtu.be/sgE2C9lLqQQ

The right window is a terminal emulator running neovim, and the left
window is the Tkinter UI program connected to neovim. The idea is that
the tkinter UI should mirror neovim terminal screen, including
dimensions. Notice that in this video I don't take focus away from the
terminal window, so the only events Tk has to process come from the
connection to neovim(virtual <<nvim>> events which describe screen
updates)

The first part of the video shows that everything works nicely when
the window height is small, but starts to lag updates when I increase
the height.

I think what I'm trying to implement is close to a terminal
emulator(must handle large bursts of text updates efficiently) but I'm
very inexperienced in GUI programming. Is Tkinter a wise choice for
this task? If yes, then what am I doing wrong?(

The code for the Tkinter program is here: http://pastebin.com/0c8cjsmR
and my OS is ubuntu 12.04(running as a VM under windows 7)

Thanks in advance

Thiago.

From storchaka at gmail.com  Mon Jun 16 22:36:45 2014
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Mon, 16 Jun 2014 23:36:45 +0300
Subject: [Tkinter-discuss] About making Text.tag_*range methods more
	consistent
In-Reply-To: <20140609083625.32e1fb8fd4c5d5f345d35192@web.de>
References: <CAO3PiBgWAkM6eUnpJjZoS3a9FjamFMPjw5q+zy_4Y_JudSUm-g@mail.gmail.com>
 <20140609083625.32e1fb8fd4c5d5f345d35192@web.de>
Message-ID: <lnnkfr$i8i$1@ger.gmane.org>

09.06.14 09:36, Michael Lange ???????(??):
> I have encountered similar objects instead of the
> expected return values from tk methods at what appears to me as "random"
> places from time to time with hevery new version for years since the
> Tkinter developers invented the "object layer" (sorry, no idea how they
> actually call it) in Python-2.4 or so. In Python2 you can disable
> it altogether by setting Tkinter.wantobjects = False early in your code
> to restore the "classic" behavior, unfortunately this does not seem to
> work in Python3 anymore (at least the last time I tried). Probably these
> objects can easily be converted into strings if you know where they
> appear.

Setting Tkinter.wantobjects = False should work in Python 3 now (at 
least in 3.3+). If this doesn't work, please report a bug.



From storchaka at gmail.com  Mon Jun 16 22:42:29 2014
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Mon, 16 Jun 2014 23:42:29 +0300
Subject: [Tkinter-discuss] About making Text.tag_*range methods more
	consistent
In-Reply-To: <CAO3PiBgWAkM6eUnpJjZoS3a9FjamFMPjw5q+zy_4Y_JudSUm-g@mail.gmail.com>
References: <CAO3PiBgWAkM6eUnpJjZoS3a9FjamFMPjw5q+zy_4Y_JudSUm-g@mail.gmail.com>
Message-ID: <lnnkqi$mp7$1@ger.gmane.org>

08.06.14 16:55, Saimadhav Heblikar ???????(??):
> I propose that Text.tag_ranges(tag) return a list of tuples (start
> index, end index), instead of a list like [start index1, endindex1,
> startindex2, endindex2....etc]
>
> To be more even more consistent, tag_ranges tuples should contain
> indexes similar to the ones returned by tag_prevrange/tag_nextrange i.e.
> strings instead of textindex objects.
>
> So, the above output would have been
>  >>> text.tag_ranges('red')
> (('1.0', '1.2'), ('1.6', '1.8'))
>
> If there is a reason for current behavior, can you link me to it?

Tk command returns a list, not a list of pairs.


From klappnase at web.de  Tue Jun 17 07:46:17 2014
From: klappnase at web.de (Michael Lange)
Date: Tue, 17 Jun 2014 07:46:17 +0200
Subject: [Tkinter-discuss] About making Text.tag_*range methods more
 consistent
In-Reply-To: <lnnkfr$i8i$1@ger.gmane.org>
References: <CAO3PiBgWAkM6eUnpJjZoS3a9FjamFMPjw5q+zy_4Y_JudSUm-g@mail.gmail.com>
 <20140609083625.32e1fb8fd4c5d5f345d35192@web.de>
 <lnnkfr$i8i$1@ger.gmane.org>
Message-ID: <20140617074617.2b3727b132543c437d9e168e@web.de>

On Mon, 16 Jun 2014 23:36:45 +0300
Serhiy Storchaka <storchaka at gmail.com> wrote:

> Setting Tkinter.wantobjects = False should work in Python 3 now (at 
> least in 3.3+). If this doesn't work, please report a bug.

Thanks for the information, glad to hear that.

Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

To live is always desirable.
		-- Eleen the Capellan, "Friday's Child", stardate 3498.9

From alan.gauld at btinternet.com  Mon Jun 23 00:18:31 2014
From: alan.gauld at btinternet.com (Alan Gauld)
Date: Sun, 22 Jun 2014 23:18:31 +0100
Subject: [Tkinter-discuss] divergent behaviour
Message-ID: <lo7knn$dqg$1@ger.gmane.org>

I've observed a strange difference in the behaviour of
one of my event handlers, I'm wondering if anyone knows
the explanation.

I have a form with a list box and a set of buttons.
When you highlight a list item you can press the
Edit button and it calls evEdit() which opens an
edit dialog in the centre of the parent window.

However I also bound the double click event to evEdit and
if you double click the same item it opebns the dialog
in the centre of the screen.

Does anyone know why double-click and button versions
of the same method result in different locations? I'm
assuming that somehow the dialog (TopLevel widget) sees
the screen as its parent in one version but the
original window as parent in the other - maybe...?

PS.
If necessary I'll try to produce a short example to
illustrate, but the existing code is over 500 lines
so a tad too long to post.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.flickr.com/photos/alangauldphotos


From klappnase at web.de  Mon Jun 23 11:00:00 2014
From: klappnase at web.de (Michael Lange)
Date: Mon, 23 Jun 2014 11:00:00 +0200
Subject: [Tkinter-discuss] divergent behaviour
In-Reply-To: <lo7knn$dqg$1@ger.gmane.org>
References: <lo7knn$dqg$1@ger.gmane.org>
Message-ID: <20140623110000.86425a5599131ae62745016f@web.de>

Hi Alan,

On Sun, 22 Jun 2014 23:18:31 +0100
Alan Gauld <alan.gauld at btinternet.com> wrote:

(...)
> I have a form with a list box and a set of buttons.
> When you highlight a list item you can press the
> Edit button and it calls evEdit() which opens an
> edit dialog in the centre of the parent window.
> 
> However I also bound the double click event to evEdit and
> if you double click the same item it opebns the dialog
> in the centre of the screen.
> 
> Does anyone know why double-click and button versions
> of the same method result in different locations? I'm
> assuming that somehow the dialog (TopLevel widget) sees
> the screen as its parent in one version but the
> original window as parent in the other - maybe...?
> 
> PS.
> If necessary I'll try to produce a short example to
> illustrate, but the existing code is over 500 lines
> so a tad too long to post.

is it possible to post only the evEdit() function? Without that I can only
guess, maybe the use of event.widget there causes confusion? Is the
parent window the Tk() window or another Toplevel()?

Regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

I'm frequently appalled by the low regard you Earthmen have for life.
		-- Spock, "The Galileo Seven", stardate 2822.3

From alan.gauld at btinternet.com  Mon Jun 23 12:15:43 2014
From: alan.gauld at btinternet.com (Alan Gauld)
Date: Mon, 23 Jun 2014 11:15:43 +0100
Subject: [Tkinter-discuss] divergent behaviour
In-Reply-To: <20140623110000.86425a5599131ae62745016f@web.de>
References: <lo7knn$dqg$1@ger.gmane.org>
 <20140623110000.86425a5599131ae62745016f@web.de>
Message-ID: <lo8uof$os9$1@ger.gmane.org>

On 23/06/14 10:00, Michael Lange wrote:

> is it possible to post only the evEdit() function? Without that I can only
> guess, maybe the use of event.widget there causes confusion? Is the
> parent window the Tk() window or another Toplevel()?

The parent is the main Tk window.
The evEdit doesn't use the event in any way.

Here are the construction lines and the event function...

class TerritoryWindow(tk.Frame):
     def __init__(self, parent):
        tk.Frame.__init__(self,parent)
...

        self.eventlist = tk.Listbox(self.history,
                                    width=45, font=('mono','10', ''))
        self.eventlist.bind('<ButtonRelease-1>', self.eventSelect)
        self.eventlist.bind('<Double-1>',self.doEdit)
...
        self.editEvent = tk.Button(self.eventbuttons, text="Edit",
                                   command=self.doEdit)


     def doEdit(self, ev=None):
        event = self.eventlist.get(self.eventlist.curselection()).split()
        me = MapEntry(self, event)
        data.updateEvent((self.eventID,) + me.result)
        self.showEvents()


MapEntry is the editing dialog box.


-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.flickr.com/photos/alangauldphotos


From klappnase at web.de  Mon Jun 23 20:36:33 2014
From: klappnase at web.de (Michael Lange)
Date: Mon, 23 Jun 2014 20:36:33 +0200
Subject: [Tkinter-discuss] divergent behaviour
In-Reply-To: <lo8uof$os9$1@ger.gmane.org>
References: <lo7knn$dqg$1@ger.gmane.org>
 <20140623110000.86425a5599131ae62745016f@web.de>
 <lo8uof$os9$1@ger.gmane.org>
Message-ID: <20140623203633.249950021febce2add58c5cf@web.de>

On Mon, 23 Jun 2014 11:15:43 +0100
Alan Gauld <alan.gauld at btinternet.com> wrote:

> The parent is the main Tk window.
> The evEdit doesn't use the event in any way.
> 
> Here are the construction lines and the event function...
> 
> class TerritoryWindow(tk.Frame):
>      def __init__(self, parent):
>         tk.Frame.__init__(self,parent)
> ...
> 
>         self.eventlist = tk.Listbox(self.history,
>                                     width=45, font=('mono','10', ''))
>         self.eventlist.bind('<ButtonRelease-1>', self.eventSelect)
>         self.eventlist.bind('<Double-1>',self.doEdit)
> ...
>         self.editEvent = tk.Button(self.eventbuttons, text="Edit",
>                                    command=self.doEdit)
> 
> 
>      def doEdit(self, ev=None):
>         event = self.eventlist.get(self.eventlist.curselection()).split
> () me = MapEntry(self, event)
>         data.updateEvent((self.eventID,) + me.result)
>         self.showEvents()
> 
> 
> MapEntry is the editing dialog box.

I cannot see anything that looks critical here, how do you calculate the
Toplevel's coords in the MapEntry class?


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Many Myths are based on truth
		-- Spock, "The Way to Eden",  stardate 5832.3

From alan.gauld at btinternet.com  Tue Jun 24 01:27:07 2014
From: alan.gauld at btinternet.com (Alan Gauld)
Date: Tue, 24 Jun 2014 00:27:07 +0100
Subject: [Tkinter-discuss] divergent behaviour
In-Reply-To: <20140623203633.249950021febce2add58c5cf@web.de>
References: <lo7knn$dqg$1@ger.gmane.org>
 <20140623110000.86425a5599131ae62745016f@web.de> <lo8uof$os9$1@ger.gmane.org>
 <20140623203633.249950021febce2add58c5cf@web.de>
Message-ID: <load4b$tih$1@ger.gmane.org>

On 23/06/14 19:36, Michael Lange wrote:

>>          self.eventlist = tk.Listbox(self.history,
>>                                      width=45, font=('mono','10', ''))
>>          self.eventlist.bind('<ButtonRelease-1>', self.eventSelect)
>>          self.eventlist.bind('<Double-1>',self.doEdit)
>> ...
>>          self.editEvent = tk.Button(self.eventbuttons, text="Edit",
>>                                     command=self.doEdit)
>>
>>
>>       def doEdit(self, ev=None):
>>          event = self.eventlist.get(self.eventlist.curselection()).split
>> () me = MapEntry(self, event)
>>          data.updateEvent((self.eventID,) + me.result)
>>          self.showEvents()
>>
>>
>> MapEntry is the editing dialog box.
>
> I cannot see anything that looks critical here, how do you calculate the
> Toplevel's coords in the MapEntry class?

I don't, I just leave Tk to do its thing. Its a subclass of Fred's 
standard Dialog class with the body and apply methods overridden to
populate the form with the original data and return the values of the 
fields when closed. Nothing clever there at all. It doesn't even use 
StrVars!

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.flickr.com/photos/alangauldphotos


From alan.gauld at btinternet.com  Tue Jun 24 01:51:51 2014
From: alan.gauld at btinternet.com (Alan Gauld)
Date: Tue, 24 Jun 2014 00:51:51 +0100
Subject: [Tkinter-discuss] divergent behaviour
In-Reply-To: <load4b$tih$1@ger.gmane.org>
References: <lo7knn$dqg$1@ger.gmane.org>
 <20140623110000.86425a5599131ae62745016f@web.de> <lo8uof$os9$1@ger.gmane.org>
 <20140623203633.249950021febce2add58c5cf@web.de> <load4b$tih$1@ger.gmane.org>
Message-ID: <loaein$ctb$1@ger.gmane.org>

On 24/06/14 00:27, Alan Gauld wrote:

>> I cannot see anything that looks critical here, how do you calculate the
>> Toplevel's coords in the MapEntry class?
>
> I don't, I just leave Tk to do its thing. Its a subclass of Fred's
> standard Dialog class with the body and apply methods overridden to
> populate the form with the original data and return the values

Here it is in its entirety.

class MapEntry(Dialog):
    def __init__(self, parent, data):
       self.data = data
       Dialog.__init__(self, parent, title="History Editor")

    def body(self, parent):
       tk.Label(parent,
                text="Map: %s" % self.data[0]).grid(row=0, sticky="W")
       tk.Label(parent, text="Publisher: ").grid(row=1, sticky="W")
       self.ePub = tk.Entry(parent)
       self.ePub.insert(tk.END, self.data[1].strip() + ' '
                               +self.data[2].strip()) # initial & name
       self.ePub.grid(row=1, column=1)
       tk.Label(parent, text="Date Out: ").grid(row=2, sticky="W")
       self.eDO = tk.Entry(parent)
       self.eDO.insert(tk.END,  self.data[3].strip())
       self.eDO.grid(row=2, column=1)
       tk.Label(parent, text="Date In: ").grid(row=3, sticky="W")
       self.eDI = tk.Entry(parent)
       self.eDI.insert(tk.END, self.data[4].strip())
       self.eDI.grid(row=3, column=1)
       return self.ePub

    def apply(self):
       self.result = (self.data[0],self.ePub.get(),
                      self.eDO.get(),self.eDI.get())

One thing to add is that I'm using tix, not standard Tk widgets,
but I don't think that should affect anything...

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.flickr.com/photos/alangauldphotos


From klappnase at web.de  Tue Jun 24 17:34:56 2014
From: klappnase at web.de (Michael Lange)
Date: Tue, 24 Jun 2014 17:34:56 +0200
Subject: [Tkinter-discuss] divergent behaviour
In-Reply-To: <loaein$ctb$1@ger.gmane.org>
References: <lo7knn$dqg$1@ger.gmane.org>
 <20140623110000.86425a5599131ae62745016f@web.de>
 <lo8uof$os9$1@ger.gmane.org>
 <20140623203633.249950021febce2add58c5cf@web.de>
 <load4b$tih$1@ger.gmane.org> <loaein$ctb$1@ger.gmane.org>
Message-ID: <20140624173456.dd3a4134a1299fd74f723812@web.de>

On Tue, 24 Jun 2014 00:51:51 +0100
Alan Gauld <alan.gauld at btinternet.com> wrote:

> On 24/06/14 00:27, Alan Gauld wrote:
(...)
> > I don't, I just leave Tk to do its thing. Its a subclass of Fred's
> > standard Dialog class with the body and apply methods overridden to
> > populate the form with the original data and return the values
> 
> Here it is in its entirety.
> 
> class MapEntry(Dialog):
>     def __init__(self, parent, data):
>        self.data = data
>        Dialog.__init__(self, parent, title="History Editor")
> 
>     def body(self, parent):
>        tk.Label(parent,
>                 text="Map: %s" % self.data[0]).grid(row=0, sticky="W")
>        tk.Label(parent, text="Publisher: ").grid(row=1, sticky="W")
>        self.ePub = tk.Entry(parent)
>        self.ePub.insert(tk.END, self.data[1].strip() + ' '
>                                +self.data[2].strip()) # initial & name
>        self.ePub.grid(row=1, column=1)
>        tk.Label(parent, text="Date Out: ").grid(row=2, sticky="W")
>        self.eDO = tk.Entry(parent)
>        self.eDO.insert(tk.END,  self.data[3].strip())
>        self.eDO.grid(row=2, column=1)
>        tk.Label(parent, text="Date In: ").grid(row=3, sticky="W")
>        self.eDI = tk.Entry(parent)
>        self.eDI.insert(tk.END, self.data[4].strip())
>        self.eDI.grid(row=3, column=1)
>        return self.ePub
> 
>     def apply(self):
>        self.result = (self.data[0],self.ePub.get(),
>                       self.eDO.get(),self.eDI.get())
> 
> One thing to add is that I'm using tix, not standard Tk widgets,
> but I don't think that should affect anything...

Hmm, so the dialog toplevel window is a child of the Frame... I don't
think that this should be a problem, but maybe you could try to make it a
child of the Tk window? 

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

First study the enemy.  Seek weakness.
		-- Romulan Commander, "Balance of Terror", stardate 1709.2

From michael.odonnell at uam.es  Tue Jun 24 18:56:23 2014
From: michael.odonnell at uam.es (Michael O'Donnell)
Date: Tue, 24 Jun 2014 18:56:23 +0200
Subject: [Tkinter-discuss] divergent behaviour
In-Reply-To: <20140623110000.86425a5599131ae62745016f@web.de>
References: <lo7knn$dqg$1@ger.gmane.org>
 <20140623110000.86425a5599131ae62745016f@web.de>
Message-ID: <CABaQFFHrvQYRjg_bc4rhWGvJo4tE+CijGA=z=aXKp+eHTpLm2A@mail.gmail.com>

Hi Alan,

  Without seeing the code, are you aware that both
single-click and double-click events are called when
you double-click an item. Would it be possible that
the single-click event (self.eventSelect) somehow affects
the result?

Mick

On 23 June 2014 11:00, Michael Lange <klappnase at web.de> wrote:
> Hi Alan,
>
> On Sun, 22 Jun 2014 23:18:31 +0100
> Alan Gauld <alan.gauld at btinternet.com> wrote:
>
> (...)
>> I have a form with a list box and a set of buttons.
>> When you highlight a list item you can press the
>> Edit button and it calls evEdit() which opens an
>> edit dialog in the centre of the parent window.
>>
>> However I also bound the double click event to evEdit and
>> if you double click the same item it opebns the dialog
>> in the centre of the screen.
>>
>> Does anyone know why double-click and button versions
>> of the same method result in different locations? I'm
>> assuming that somehow the dialog (TopLevel widget) sees
>> the screen as its parent in one version but the
>> original window as parent in the other - maybe...?
>>
>> PS.
>> If necessary I'll try to produce a short example to
>> illustrate, but the existing code is over 500 lines
>> so a tad too long to post.
>
> is it possible to post only the evEdit() function? Without that I can only
> guess, maybe the use of event.widget there causes confusion? Is the
> parent window the Tk() window or another Toplevel()?
>
> Regards
>
> Michael
>
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> I'm frequently appalled by the low regard you Earthmen have for life.
>                 -- Spock, "The Galileo Seven", stardate 2822.3
> _______________________________________________
> Tkinter-discuss mailing list
> Tkinter-discuss at python.org
> https://mail.python.org/mailman/listinfo/tkinter-discuss

From alan.gauld at btinternet.com  Tue Jun 24 19:20:43 2014
From: alan.gauld at btinternet.com (Alan Gauld)
Date: Tue, 24 Jun 2014 18:20:43 +0100
Subject: [Tkinter-discuss] divergent behaviour
In-Reply-To: <CABaQFFHrvQYRjg_bc4rhWGvJo4tE+CijGA=z=aXKp+eHTpLm2A@mail.gmail.com>
References: <lo7knn$dqg$1@ger.gmane.org>
 <20140623110000.86425a5599131ae62745016f@web.de>
 <CABaQFFHrvQYRjg_bc4rhWGvJo4tE+CijGA=z=aXKp+eHTpLm2A@mail.gmail.com>
Message-ID: <locc1c$mjf$1@ger.gmane.org>

On 24/06/14 17:56, Michael O'Donnell wrote:
> Hi Alan,
>
>    Without seeing the code,

Most of the related stuff is now posted under
the thread with Michael Lange.

are you aware that both
> single-click and double-click events are called when
> you double-click an item.

No, that's good to know. But since the single click
(actually button release - is that the same?) only
selects the item in the list I don't think that should
be changing anything.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.flickr.com/photos/alangauldphotos


From alan.gauld at btinternet.com  Tue Jun 24 19:41:01 2014
From: alan.gauld at btinternet.com (Alan Gauld)
Date: Tue, 24 Jun 2014 18:41:01 +0100
Subject: [Tkinter-discuss] divergent behaviour(complete example code)
In-Reply-To: <20140624173456.dd3a4134a1299fd74f723812@web.de>
References: <lo7knn$dqg$1@ger.gmane.org>
 <20140623110000.86425a5599131ae62745016f@web.de> <lo8uof$os9$1@ger.gmane.org>
 <20140623203633.249950021febce2add58c5cf@web.de> <load4b$tih$1@ger.gmane.org>
 <loaein$ctb$1@ger.gmane.org> <20140624173456.dd3a4134a1299fd74f723812@web.de>
Message-ID: <locd7d$5mn$1@ger.gmane.org>

On 24/06/14 16:34, Michael Lange wrote:

> Hmm, so the dialog toplevel window is a child of the Frame... I don't
> think that this should be a problem, but maybe you could try to make it a
> child of the Tk window?

Tried it, no difference :-(
Thanks for the suggestion though.

PS.
I'm about to post a minimal example that does the same.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.flickr.com/photos/alangauldphotos


From alan.gauld at btinternet.com  Tue Jun 24 19:45:00 2014
From: alan.gauld at btinternet.com (Alan Gauld)
Date: Tue, 24 Jun 2014 18:45:00 +0100
Subject: [Tkinter-discuss] divergent behaviour(complete code)
In-Reply-To: <lo7knn$dqg$1@ger.gmane.org>
References: <lo7knn$dqg$1@ger.gmane.org>
Message-ID: <locdet$8oe$1@ger.gmane.org>

On 22/06/14 23:18, Alan Gauld wrote:

> Does anyone know why double-click and button versions
> of the same method result in different locations? I'm
> assuming that somehow the dialog (TopLevel widget) sees
> the screen as its parent in one version but the
> original window as parent in the other - maybe...?

Here is a complete example that shows the same behaviour...

import Tix as tk
#this uses a local copy of Fred Lundh's Dialog class from his web site
# not the standard library version which is very similar...

import tkDialog

class MainWin(tk.Frame):
    def __init__(self,parent):
       tk.Frame.__init__(self,parent)
       L = tk.Label(self,text='double click me')
       L.pack()
       L.bind('<Double-1>',self.show)
       tk.Button(self,width=30,text='push me', command=self.show).pack()
       self.pack()

    def show(self,ev=None):
       testD(self)

class testD(tkDialog.Dialog):
    def body(self,parent):
        tk.Label(self,text="How'd I do?").pack()

top = tk.Tk()
app = MainWin(top)
top.mainloop()



-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.flickr.com/photos/alangauldphotos


From klappnase at web.de  Tue Jun 24 20:17:59 2014
From: klappnase at web.de (Michael Lange)
Date: Tue, 24 Jun 2014 20:17:59 +0200
Subject: [Tkinter-discuss] divergent behaviour(complete code)
In-Reply-To: <locdet$8oe$1@ger.gmane.org>
References: <lo7knn$dqg$1@ger.gmane.org>
	<locdet$8oe$1@ger.gmane.org>
Message-ID: <20140624201759.3e9367cb554f0cd31285e754@web.de>

On Tue, 24 Jun 2014 18:45:00 +0100
Alan Gauld <alan.gauld at btinternet.com> wrote:

> Here is a complete example that shows the same behaviour...

(...)

There is no difference in the position of the dialog window when I
double-click the Label or push the button here on Debian wheezy, I tried
with icewm, xfce, gnome3, lxde and awesome, maybe it is some oddity with
your WM or the particular Tk version you use (here: 8.5.11) ?


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

In the strict scientific sense we all feed on death -- even vegetarians.
		-- Spock, "Wolf in the Fold", stardate 3615.4

From alan.gauld at btinternet.com  Wed Jun 25 00:21:54 2014
From: alan.gauld at btinternet.com (Alan Gauld)
Date: Tue, 24 Jun 2014 23:21:54 +0100
Subject: [Tkinter-discuss] divergent behaviour(complete code)
In-Reply-To: <20140624201759.3e9367cb554f0cd31285e754@web.de>
References: <lo7knn$dqg$1@ger.gmane.org>	<locdet$8oe$1@ger.gmane.org>
 <20140624201759.3e9367cb554f0cd31285e754@web.de>
Message-ID: <loctm2$lmk$1@ger.gmane.org>

On 24/06/14 19:17, Michael Lange wrote:

> There is no difference in the position of the dialog window when I
> double-click the Label or push the button here on Debian wheezy, I tried
> with icewm, xfce, gnome3, lxde and awesome, maybe it is some oddity with
> your WM or the particular Tk version you use (here: 8.5.11) ?

Weird, I definitely consistently get two different positions.

I'm using Python 2.7 on Ubuntu 14 LTS with xfce.
Not sure about the Tk/Tix versions.

I'll try it on Windoze 8.1... Yep, it works consistently there.

I also tried it on X running under cygwin with twm... It acts 
differently there, but this time the dialog appears at the
extreme top left of the root window for a double click.

So presumably it must be some weird WM related thing.
How odd. I don't think I'll chase any further, its still
usable and looks like it's not a fault in my code per se.

Thanks for all your help, and patience.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.flickr.com/photos/alangauldphotos


From klappnase at web.de  Wed Jun 25 09:35:50 2014
From: klappnase at web.de (Michael Lange)
Date: Wed, 25 Jun 2014 09:35:50 +0200
Subject: [Tkinter-discuss] divergent behaviour(complete code)
In-Reply-To: <loctm2$lmk$1@ger.gmane.org>
References: <lo7knn$dqg$1@ger.gmane.org> <locdet$8oe$1@ger.gmane.org>
 <20140624201759.3e9367cb554f0cd31285e754@web.de>
 <loctm2$lmk$1@ger.gmane.org>
Message-ID: <20140625093550.37b610d65e00207e262d46ab@web.de>

On Tue, 24 Jun 2014 23:21:54 +0100
Alan Gauld <alan.gauld at btinternet.com> wrote:

(...)
> So presumably it must be some weird WM related thing.
> How odd. I don't think I'll chase any further, its still
> usable and looks like it's not a fault in my code per se.

Maybe you could work around this by calling update_idletasks() (or
update()) before calling doEdit() and/or opening the dialog slightly
delayed with self.after(50, doEdit) ?


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

... bacteriological warfare ... hard to believe we were once foolish
enough to play around with that.
		-- McCoy, "The Omega Glory", stardate unknown