On Mon, Feb 2, 2009 at 11:00 PM, Brian Zambrano wrote:
> When I do:
>
> bri...@omaha$ ls -F
> dist/plot_in_wx_test.app/Contents/Resources/lib/python2.5/
> config@matplotlib/site-packages.zip
> lib-dynload/ numpy/ site.py@
>
> Yet, when I try to run
> ./dist/w
On 3 Feb, 2009, at 17:49, Bill Janssen wrote:
Ronald Oussoren wrote:
if I understand the
LSUIElement document correctly the setting you propose would make it
impossible to use "python sometkscript.py" to run a simple GUI
script.
Then you misunderstand either LSUIElement, or the discussio
Bill Janssen wrote:
> It would, and that's actually the "long-standing infrastructure of
> Python on the Mac" that you refer to. The Python.app formulation is
> recent, and not yet well-enough debugged.
Though, I should hasten to say, I think removing the distinction between
python and pythonw
Kevin Walzer wrote:
> Bill, the behavior that you experiencing is the expected behavior of
> Python, albeit not what you want in this instance. Rather than re-doing
> the long-standing infractucture of Python on the Mac, wouldn't it be
> better to find the code that is causing the undesired "r
Kevin Walzer wrote:
My development is of GUI apps, and I like being able to double-click on
a Python script and have it do the Right Thing--that is, launch as a
foreground GUI process in Tkinter.
I think it's clear that lot's of us want that. the question is, will the
proposal break that?
O
Looks like this died in cyberspace...
--- Begin Message ---
Bill Janssen wrote:
has wrote:
Annoying, but tweaking
the Python.app bundle's LSBackgroundOnly/LSUIElement flags isn't a
solution, it's a kludge - one that will take us back to the bad old
days where some scripts automatically fail w
Bill Janssen wrote:
has wrote:
Annoying, but tweaking
the Python.app bundle's LSBackgroundOnly/LSUIElement flags isn't a
solution, it's a kludge - one that will take us back to the bad old
days where some scripts automatically fail when run with 'python'.
*Right now*, some scripts fail when
Henning Hraban Ramm wrote:
Hm, what do you mean? Should there be a standalone py2app script anywhere?
nope.
I know only "python setup.py py2app",
right, so you add the -A:
python setup.py py2app -A
> and therefore I'd need to write a
setup.py
which is trivial for the simple case, and y
I've searched around and found some mentions of problems when building apps
with matplotlib, but didn't see any definitive solutions.
I'm trying to build a simple using matplotlib, numpy and wx. My setup.py
looks like this:
from setuptools import setup
APP = ['plot_in_wx_test.py']
DATA_FILES =
Am 2009-02-03 um 18:54 schrieb Christopher Barker:
Most of *my* wxPython-based (actually dabo-based) tools don't even
need to be an app bundle - doubleclicking some .py file is mostly
enough.
Check out "py2app -A". It's perfect for this kind of use.
Hm, what do you mean? Should there be a
On 3 Feb, 2009, at 18:55, Bill Janssen wrote:
Ronald Oussoren wrote:
On 3 Feb, 2009, at 17:54, Bill Janssen wrote:
I'm seriously wondering if having "Python Launcher.app" is a good
idea, and if we shouldn't scrap it entirely. If building full app
bundles using py2app is too much of a bur
Christopher Barker wrote:
> This is a concern -- what if I do need to "Force Quit" my app? I can
> probably find it with ps, and kill it with kill, but that's only
> because I was a Linux geek before I got a Mac.
Then give your app its own Info.plist. There are zillions of processes
running on
Chris, I'm a bit confused, too.
> Could someone (Bill?) summarize what functionally will change if this
> change is applied?
Basically, if you're running /usr/bin/python or Python.app directly, you
still won't get a dock icon even if you're using appscript. The app is
marked as an agent applicat
Ronald Oussoren wrote:
>
> On 3 Feb, 2009, at 17:54, Bill Janssen wrote:
> >
> >> I'm seriously wondering if having "Python Launcher.app" is a good
> >> idea, and if we shouldn't scrap it entirely. If building full app
> >> bundles using py2app is too much of a burden we could look into
> >> pro
Henning Hraban Ramm wrote:
Most of *my* wxPython-based (actually dabo-based) tools don't even need
to be an app bundle - doubleclicking some .py file is mostly enough.
Check out "py2app -A". It's perfect for this kind of use.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Re
Robin Dunn wrote:
I thought Robin said that this default was going to be changed, so
that newbies would have this issue less -- what happened to that?
I didn't think it would be a good idea to change a default like this
between two 2.8.x releases, but it's already changed in the 2.9 source
tr
Ronald Oussoren wrote:
I'm seriously wondering if having "Python Launcher.app" is a good idea,
and if we shouldn't scrap it entirely.
I wonder, too, but if we do keep it, it could have the full-gui
info.plist anyway -- would that work?
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Eme
Bill,
Thanks for making the effort to understand and explain all this. Many of
us remember the many "why won't this work!" posts to the mailing
list so we just want to be careful.
Some concerns:
``LSUIElement (String). If this key is set to '1', Launch Services runs
the application as a
Bill Janssen wrote:
Ronald Oussoren wrote:
The fully standalone bundles that py2app creates are very useful, but
I definitely see the need for very thin .app bundles as well.
Interesting idea. What's the lightest thing that's an app, anyway?
You can run py2app in "Alias" mode ($python setu
First:
I've read this thread, I've read the Apple docs (at least one level deep
-- I really don't "get" this stuff, and I don't have the time to learn
it all!)
I still don't "get" what LSUIElement is supposed to do, and what
functionality will change if it's set.
I did try setting it on my
On 3 Feb, 2009, at 17:54, Bill Janssen wrote:
I'm seriously wondering if having "Python Launcher.app" is a good
idea, and if we shouldn't scrap it entirely. If building full app
bundles using py2app is too much of a burden we could look into
providing an easier and more lightweight way to buil
I have to say, I find the somewhat uninformed resistance to this idea
incredible. It's an *idea*, folks, not a patch. It can't hit OS X in
any form till 10.7, which is well over a year away. Relax -- try it
out, read the docs, and report back. Let's *find out* what the effects
of doing this wou
Ronald Oussoren wrote:
I'm going to Pycon this year and I'm wondering if anyone is interested
in doing a MacPython related sprint afterwards.
There is about a 50% chance that I'll be going.
Possible topics:
* Investigate OSX-integration issues (such as the "rocket icon" that
sometimes appea
has wrote:
> Annoying, but tweaking
> the Python.app bundle's LSBackgroundOnly/LSUIElement flags isn't a
> solution, it's a kludge - one that will take us back to the bad old
> days where some scripts automatically fail when run with 'python'.
*Right now*, some scripts fail when run with "python
Ronald Oussoren wrote:
> > Most of *my* wxPython-based (actually dabo-based) tools don't even
> > need to be an app bundle - doubleclicking some .py file is mostly
> > enough. But I wouldn't like to loose some GUI functionality.
>
> IMHO running the script shouldn't be the default action for .py
Ronald Oussoren wrote:
>
> On 2 Feb, 2009, at 21:53, Bill Janssen wrote:
> >>
> >>
> >> In any case, it does include a info.plist, and it may include a
> >> different launch stub, so setting LSUIElement = 1 may work in either
> >> case.
> >
> > Sounds reasonable, then. Set LSUIElement=1 in the
Ronald Oussoren wrote:
> if I understand the
> LSUIElement document correctly the setting you propose would make it
> impossible to use "python sometkscript.py" to run a simple GUI script.
Then you misunderstand either LSUIElement, or the discussion so far.
What we'd like to do is to retain that
Henning Hraban Ramm wrote:
> But I wouldn't like to loose some GUI functionality.
I'm sure that's true. But I think the change I'm proposing needn't
cause any negative effects.
I've lost the ability to log out, and would like that back!
Bill
___
Pyt
Bill Janssen wrote:
Chris, if you followed the thread, you'll know that what's happening
is
that the Python.app app is being promoted to a "full app", without any
provision for behaving like a "full app". In particular, it doesn't
participate in the various shutdown handshakes, and thus preve
Hi,
I'm going to Pycon this year and I'm wondering if anyone is interested
in doing a MacPython related sprint afterwards. Possible topics:
* Investigate OSX-integration issues (such as the "rocket icon" that
sometimes appears)
* Get Py2app development going again
* Packaging 3th-party e
On 2 Feb, 2009, at 17:58, Bill Janssen wrote:
I'm thinking that the right thing to do about rocket-in-the-dock
should
be to change the Info.plist of Python.app, to include the setting
"LSUIElement: 1". Here's the doc from Apple:
``LSUIElement (String). If this key is set to '1', Launch Serv
On 14 Jan, 2009, at 2:47, s s wrote:
I've been trying to figure out where the _real_ current Py2app is.
AFAIK this is the current home:
http://svn.pythonmac.org/py2app/py2app/trunk
I really need to add some things (compiling xib -> nib, for example)
to build my project and I'd prefer
On 3 Feb, 2009, at 9:10, Henning Hraban Ramm wrote:
Most of *my* wxPython-based (actually dabo-based) tools don't even
need to be an app bundle - doubleclicking some .py file is mostly
enough. But I wouldn't like to loose some GUI functionality.
IMHO running the script shouldn't be the d
IDLE.app goes to some lengths to convince OS X that it is executing
under its own app bundle even though it is running the interpreter
from
the framework Python.app executable (more execve trickery) so the
Python.app Info.plist settings don't apply. BTW, IDLE.app is also
broken in 3.x but I t
On 2 Feb, 2009, at 21:53, Bill Janssen wrote:
In any case, it does include a info.plist, and it may include a
different launch stub, so setting LSUIElement = 1 may work in either
case.
Sounds reasonable, then. Set LSUIElement=1 in the Python.app
Info.plist,
and other apps that use python
On 2 Feb, 2009, at 19:27, Bill Janssen wrote:
Christopher Barker wrote:
Bill Janssen wrote:
It seems to me that this is what we want for the Python interpreter
proper.
could be. It sounds promising.
Applications (like IDLE) that are indeed proper foreground apps
can always call Transfor
Am 2009-02-03 um 03:47 schrieb Bill Janssen:
I'd suggest that promotion to LSUIElement (agent application) by the
toolkit is probably right, but I'd suggest that you only promote to
full
app by actually having an app bundle that overrides the default
Info.plist.
Sorry for chirping in as a n
37 matches
Mail list logo
