matplotlib-devel Mailing List for matplotlib

Adam: sorry, I didn't mean to just send that straight to you. gmail
decided its default would be to send to you and not the mailing list.
Everyone else: The message that was supposed to go to the list:
I was looking at setupext.py and I am thinking that we could just
change the add_tk_flags function.
My idea is to remove the elif sys.platform == "darwin" section and
always go to the else.
In the except line after trying query_tcltk() we can add a check for
darwin and have it search the normal framework locations, or even put
an if sys.platform == "darwin" that goes for the frameworks in
hardcoded_tclconfig().
In the else line after that we could do a check to see if the returned
tcl/tk libs and version match any normal system framework paths (in
$HOME/Library/Frameworks, /System/Library and
/System/Library/Frameworks) or even just look at the library name or
some
other method to determine if it is a framework and add the "-framework
Tcl -framework Tk" flags to module.extra_link_args and
module.extra_compile_args if they are.
Also, I was looking and I don't actually see any point around here
where it is explicitly checked if the results of query_tcltk()
correspond to a directory that is in basedir["darwin"].
As an aside, we could add to hardcoded_tclconfig() to surf the
directories returned from add_base_flags / basedir["darwin"] instead
of the directories it has. It would probably be best on all systems
to look in the basedir[os.system] directories for Tk as a last result
rather
than /usr/local
Basically, I am just sharing some of the ideas I have been playing with.
Jayson
On Thu, Feb 12, 2009 at 12:45 PM, Jayson Barr <jb...@nm...> wrote:
> I was looking at setupext.py and I am thinking that we could just
> change the add_tk_flags function.
>
> My idea is to remove the elif sys.platform == "darwin" section and
> always go to the else.
>
> In the except line after trying query_tcltk() we can add a check for
> darwin and have it search the normal framework locations, or even put
> an if sys.platform == "darwin" that goes for the frameworks in
> hardcoded_tclconfig().
>
> In the else line after that we could do a check to see if the returned
> tcl/tk libs and version match any normal system framework paths (in
> $HOME/Library/Frameworks, /System/Library and
> /System/Library/Frameworks) or even just look at the library or some
> other method to determine if it is a framework and add the "-framework
> Tcl -framework Tk" flags to module.extra_link_args and
> module.extra_compile_args if they are.
>
> Also, I was looking and I don't actually see any point around here
> where it is explicitly checked if the results of query_tcltk()
> corrsepond to a directory that is in basedir["darwin"].
>
> As an aside, we could add to hardcoded_tclconfig() to surf the
> directories returned from add_base_flags / basedir["darwin"] instead
> of the directories it has. It would probably be best on all systems
> to look in the basedir[os.system] directories as a last result rather
> than /usr/local
>
> Basically, I am just sharing some of the ideas I have been playing with.
>
> Jayson
>
> On Tue, Feb 10, 2009 at 9:54 AM, Adam Mercer <ram...@gm...> wrote:
>> On Mon, Feb 9, 2009 at 17:08, Jayson Barr <jb...@nm...> wrote:
>>
>>> I agree with JDH.
>>
>> Likewise.
>>
>>> Unfortunately, work has been exceptionally hectic so I haven't begun
>>> the patch (if you don't count the hack job I did to install it for
>>> myself).
>>
>> Same here, I'm really busy with work and don't have much time to look
>> into this at the moment.
>>
>>> Hi Adam,
>>> As noted above, I haven't started a patch yet but I would be up for
>>> working with you on one. It sounds like we can get this tested pretty
>>> well.
>>
>> Its on my todo list, so when I get chance I'm going to investigate a
>> better solution. I'll keep you posted.
>>
>> Cheers
>>
>> Adam
>>
>

Jouni K. Seppänen <jk...@ik...> wrote:
>> Those changes are in the attached patch. It's certainly not a
>> definitive workaround, but it's better than nothing ;-)
>
> Committed; thanks!
My pleasure!

Nicolas Grilly <nic...@ga...>
writes:
> Those changes are in the attached patch. It's certainly not a
> definitive workaround, but it's better than nothing ;-)
Committed; thanks!
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On 02/09/09 11:59, Gael Varoquaux wrote:
> On Sun, Feb 08, 2009 at 04:08:31PM -0800, Brian Granger wrote:
>> * In the current matplotlib backend wx.Yield() is called in a way that
>> is not safe as far as protecting against recursive calls to Yield. I
>> think it should be called in this way:
> 
>> app = wx.GetApp()
>> if app is not None:
>> app.Yield(True)
> 
> The problem I see with this approach is that arbitrary wx programs will
> always be doing this. The matplotlib guys can fix matplotib not to do
> this. I can fix Mayavi not to do this, but there are many more wx
> programs. And anyhow, most of the time, Yield should not be called, as it
> is a hack. Unfortunately, you often end up having to call it. :(
Just nit picking: You'd really have to modify traits and pyface for 
this. Mayavi doesn't start the mainloop.
cheers,
prabhu

On 02/09/09 05:38, Brian Granger wrote:
> IPython and matplotlib devs,
> 
> Over the weekend I have been playing around to see if it is possible
> to do interactive GUI work with wx from IPython *without using
> threads*. The idea here is to use PyOS_InputHook. Currently, recent
> versions of PyQt4 and PyGTK do this and if we can get wx working, we
> can probably get rid of IPython's subtle threaded shells that
> currently allow interactive GUIs to work.
> 
> I am attaching a Cython module that mostly works. Here is a simple
> example that works in IPython (without the -wthread option!)
[...]
> I don't have any more time to work on this right now, but I at least
> wanted to share my findings with both IPython and matplotlib devs. It
> would be great if someone familiar with wx could try to figure out the
> remaining issues. If there are no takers here, I might eventually see
> if wxpython itself is interested in this code (that is probably where
> it really belongs anyway).
This is cool! It works with mayavi, which is a pretty demanding test. 
I did run into problems with pyximport messing up on some imports but 
manually importing the inputhook.so fixed those. The interactive 
response is not snappy but it definitely works without a problem.
One problem I can see with this is that while it does eliminate the 
threading, there are still issues with multiple toolkits. It would be 
neat if there were a system where you could mix toolkits too -- it looks 
like it should be possible to support this though.
cheers,
prabhu