date:20060419

Bill Janssen wrote:

>1) We should no longer point people to Jack's site, we point them to
>   the python.org Mac download page instead.

Agree. Having links to the old MacPython site in places where folk expect to 
find up-to-date information doesn't help.

Also, if there's somewhere to provide a list of highly respected Python 
contributors, make sure Jack's name is up there accompanied by his site link 
for posterity. Wouldn't want the removal of obsolete links from the main body 
of documentation to look like a writing out of history of the Jack and his 
terrific contribution to Mac Python over the years.

>Just looking at the docs, I'm trying to figure out what's good and
>what's bad.
>
>2) references to PythonIDE and PackageManager should go.

Sounds fine to me. They're related products, not part of the core Python 
distribution, so shouldn't be any problem eliminating mention of those from the 
documentation. Might need to put in a short page about IDLE to replace the old 
Python IDE section.

In addition, all mentions of OS 9 should either be expunged (e.g. the 'using 
Python on Mac OS 9' chapter) or changed to 'not supported' (should they still 
need to be documented for any reason).

>3) What about the following:
>
>   2. MacPython Modules

Well, it feels tempting at times just do a straight delete on this too. 

However: these modules are all part of the official distribution, so I would 
imagine that any to be dropped needs to go through the full deprecation 
procedure first.

>2.1 macpath -- MacOS path manipulation functions

Deprecate. Also note that the 2.4.3 documentation now says "It can be used to 
manipulate old-style Macintosh pathnames on Mac OS X (or any other platform)." 
which is incorrect (it uses POSIX-style paths), so delete that sentence.

>2.2 macfs -- Various file system services

Already deprecated as of 2.3.  Delete yet?

>2.3 ic -- Access to Internet Config

No idea about this. Anyone else know if this is still working/relevant?

>2.4 MacOS -- Access to Mac OS interpreter features

Get/SetCreatorAndType should really be fixed or deprecated as they don't appear 
to work for bundle-based files.

>2.5 macostools -- Convenience routines for file manipulation

Not sure about this. It's pretty ancient and crusty though, so I'd be inclined 
to deprecate.

>2.6 findertools -- The finder's Apple Events interface

Deprecate.

>2.7 EasyDialogs -- Basic Macintosh dialogs

It's ancient and very crusty, but until there's an up-to-date replacement I 
guess it has to stay as-is for now, alas. Might be a good idea to check 
functions for unicode compatibility, long string support, etc. and add notes on 
any limitations found.

>2.8 FrameWork -- Interactive application framework

Deprecate.

>2.9 autoGIL -- Global Interpreter Lock handling in event loops

No idea. Anyone?

>3. MacPython OSA Modules

Deprecate.

>4. MacOS Toolbox Modules

These are just wrappers around the existing Carbon APIs. So as long as those 
APIs are themselves relevant, so are the wrappers. You can get background info, 
including a list of which APIs are legacy-only at:

>4.1 Carbon.AE -- Apple Events

Ronald's been thinking it might be best to deprecate both Carbon.AE and 
Carbon.OSA and keep all the AE/OSA/appscript stuff together. Dunno if he's got 
any further on that yet; you could ask.

>4.2 Carbon.AH -- Apple Help

Do nothing.

>4.3 Carbon.App -- Appearance Manager

Apple's docs describe AM as 'the older QuickDraw-centric version of HITheme', 
but don't note it as being superceded/deprecated so I guess it should stay 
as-is.

>4.4 Carbon.CF -- Core Foundation
>4.5 Carbon.CG -- Core Graphics
>4.6 Carbon.CarbonEvt -- Carbon Event Manager

Do nothing.

>4.7 Carbon.Cm -- Component Manager

According to Apple's docs CM is largely historical; modern apps should use Core 
Foundation's Plug-in Services. Other Carbon APIs still rely on it though, so do 
nothing.

>4.8 Carbon.Ctl -- Control Manager

According to Apple's docs, HIView is superseding the older Control Manager. For 
now though, do nothing.

>4.9 Carbon.Dlg -- Dialog Manager

According to Apple's docs, Interface Builder and Carbon event handlers mostly 
supersede the Dialog Manager, except in the cases where you want to put up a 
standard alert dialog box or sheet. For now though, do nothing.

>4.10 Carbon.Evt -- Event Manager

Deprecate, or at least add note to use modern alternative. Superceded by 
CarbonEvt.

>4.11 Carbon.Fm -- Font Manager
>4.12 Carbon.Folder -- Folder Manager
>4.13 Carbon.Help -- Help Manager

Do nothing.

>4.14 Carbon.List -- List Manager

Deprecate, or at least add note to use modern alternative. Superceded by 
Control

Re: [Pythonmac-SIG] py2app = newbie path confusion

2006-04-19 Thread corporate user

Many thanks to you Bob.
You're a community treasure.


> Also note that the Image module probably isn't broken (don't have  
> PIL installed at the moment, can't check).  Constants don't  
> automagically just insert themselves into your script.  You should  
> be able to reference it with Image.BICUBIC.

yes, referencing Image.BICUBIC works correctly.

As usual my problems lie with the scope. I'm forming the opinion that  
"from XXX import *" should be banned from all introduction, tutorial  
and example materials. It encourages naive assumptions about things  
automagically inserting themselves into your namespace. Everything  
seems simple when following the examples. But when you try  
paraphrasing them for your own work, it blows up in your face.

It would be better to provide beginners an understanding of  
namespaces from the start.




___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac Python is DEAD

Bill Janssen wrote:

> In my opinion, the problem is the term "MacPython".  Python is Python,
> period, and we should just call it that, even if it's running on the Mac
> platform.  Perhaps this was different in the pre-OSX days, but not now.

On OS X I think of the 'MacPython' name more as a way to identify the 
particular distribution: MacPython, Fink Python, ActiveState Python, etc. It'd 
probably make more sense in that respect if it was 'Mac Python' rather than 
'MacPython', but that's just an artifact of how it's evolved.

Personally I have no problem dropping the 'Mac' prefix if it proves to be 
causing more confusion than it solves. Might need to think of a new 
distribution name though.

has
-- 
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] py2app = newbie path confusion

2006-04-19 Thread corporate user

Thank you Bob.


>> Very simple beginner script. Not sure why it doesn't write files  
>> after py2appletizing.
>> Seems to work just fine from the command line. What am I missing?
>
> You're missing the fact that the current directory in a py2app- 
> generated applet is inside the Resources folder of the applet itself.

I made the assumption that since py2app automagically created an  
Apple application without my having to know anything about a bundle  
or its structure, that it would also create path emulation as well.

Naively, I start with a script in my ~/src folder and I end with an  
application in my ~/src folder. Like a typical Apple user, I treat  
the bundle as the code itself and don't bother to dwell on its  
content or structure.

I now understand what the --alias (-A) option to py2app is for.  
Otherwise you have to start planning for the Bundle tree structure  
from the start.

Am I the first to make this assumption, or is this a tip that should  
be added to the wiki py2app example page?


___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] py2app = newbie path confusion

2006-04-19 Thread Charles Hartman

On Apr 19, 2006, at 10:23 AM, corporate user wrote:Naively, I start with a script in my ~/src folder and I end with an   application in my ~/src folder. Like a typical Apple user, I treat   the bundle as the code itself and don't bother to dwell on its   content or structure.  I now understand what the --alias (-A) option to py2app is for.   Otherwise you have to start planning for the Bundle tree structure   from the start.  Am I the first to make this assumption, or is this a tip that should   be added to the wiki py2app example page? Absolutely this needs to be addressed. Anybody who comes to Python programming from the Mac OS rather than from Unix falls into this mess -- what, my app is a folder?? -- at some point.___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fixing the documentation...

2006-04-19 Thread Nir Soffer

On 19/04/2006, at 03:23, Bill Janssen wrote:

> 3) What about the following:
>
> 2. MacPython Modules
> 2.1 macpath -- MacOS path manipulation functions
> 2.2 macfs -- Various file system services
> 2.2.1 FSSpec Objects
> 2.2.2 Alias Objects
> 2.2.3 FInfo Objects
> 2.3 ic -- Access to Internet Config
> 2.3.1 IC Objects
> 2.4 MacOS -- Access to Mac OS interpreter features
> 2.5 macostools -- Convenience routines for file manipulation
> 2.6 findertools -- The finder's Apple Events interface
> 2.7 EasyDialogs -- Basic Macintosh dialogs
> 2.7.1 ProgressBar Objects
> 2.8 FrameWork -- Interactive application framework
> 2.8.1 Application Objects
> 2.8.2 Window Objects
> 2.8.3 ControlsWindow Object
> 2.8.4 ScrolledWindow Object
> 2.8.5 DialogWindow Objects
> 2.9 autoGIL -- Global Interpreter Lock handling in event loops
> 3. MacPython OSA Modules
> 3.1 gensuitemodule -- Generate OSA stub packages
> 3.2 aetools -- OSA client support
> 3.3 aepack -- Conversion between Python variables and 
> AppleEvent data containers
> 3.4 aetypes -- AppleEvent objects
> 3.5 MiniAEFrame -- Open Scripting Architecture server support
> 3.5.1 AEServer Objects
> 4. MacOS Toolbox Modules
> 4.1 Carbon.AE -- Apple Events
> 4.2 Carbon.AH -- Apple Help
> 4.3 Carbon.App -- Appearance Manager
> 4.4 Carbon.CF -- Core Foundation
> 4.5 Carbon.CG -- Core Graphics
> 4.6 Carbon.CarbonEvt -- Carbon Event Manager
> 4.7 Carbon.Cm -- Component Manager
> 4.8 Carbon.Ctl -- Control Manager
> 4.9 Carbon.Dlg -- Dialog Manager
> 4.10 Carbon.Evt -- Event Manager
> 4.11 Carbon.Fm -- Font Manager
> 4.12 Carbon.Folder -- Folder Manager
> 4.13 Carbon.Help -- Help Manager
> 4.14 Carbon.List -- List Manager
> 4.15 Carbon.Menu -- Menu Manager
> 4.16 Carbon.Mlte -- MultiLingual Text Editor
> 4.17 Carbon.Qd -- QuickDraw
> 4.18 Carbon.Qdoffs -- QuickDraw Offscreen
> 4.19 Carbon.Qt -- QuickTime
> 4.20 Carbon.Res -- Resource Manager and Handles
> 4.21 Carbon.Scrap -- Scrap Manager
> 4.22 Carbon.Snd -- Sound Manager
> 4.23 Carbon.TE -- TextEdit
> 4.24 Carbon.Win -- Window Manager
> 4.25 ColorPicker -- Color selection dialog
> 5. Undocumented Modules
> 5.1 applesingle -- AppleSingle decoder
> 5.2 buildtools -- Helper module for BuildApplet and Friends
> 5.3 cfmfile -- Code Fragment Resource module
> 5.4 icopen -- Internet Config replacement for open()
> 5.5 macerrors -- Mac OS Errors
> 5.6 macresource -- Locate script resources
> 5.7 Nav -- NavServices calls
> 5.8 PixMapWrapper -- Wrapper for PixMap objects
> 5.9 videoreader -- Read QuickTime movies
> 5.10 W -- Widgets built on FrameWork
> 5.11 waste -- non-Apple TextEdit replacement
>
> My inclination is to delete them all :-).  Except for ones where
> someone pipes up and tells me it still works.  Let folks use the Wiki
> to find modules.

Don't delete anything, some if not all these modules do work and are 
useful. Some of the docs are quite useless, and the only way is to use 
help(modulename), maybe the html can be generated from the module 
docstrings?

Modules I used:
  * Carbon.File - to get the real case of a file name
  * MacOS - to get file type and creator code
  * plistlib - to read and write plist files


Best Regards,

Nir Soffer

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] py2app = newbie path confusion

On Apr 19, 2006, at 6:38, corporate user wrote:

> Many thanks to you Bob.
> You're a community treasure.
>
>
>> Also note that the Image module probably isn't broken (don't have
>> PIL installed at the moment, can't check).  Constants don't
>> automagically just insert themselves into your script.  You should
>> be able to reference it with Image.BICUBIC.
>
> yes, referencing Image.BICUBIC works correctly.
>
> As usual my problems lie with the scope. I'm forming the opinion that
> "from XXX import *" should be banned from all introduction, tutorial
> and example materials. It encourages naive assumptions about things
> automagically inserting themselves into your namespace. Everything
> seems simple when following the examples. But when you try
> paraphrasing them for your own work, it blows up in your face.
>
> It would be better to provide beginners an understanding of
> namespaces from the start.

Most Python books do cover namespaces in the early chapters (at least  
the ones I read ;-). But 'from xxx import *' makes it too easy to  
forget them since it mashes the namespaces together. I've rarely  
encountered collisions but I try not to be that lazy. I try to use  
'import ' and prefix the module name as often as practical fro  
that reason. Of course the downside is that if the module name or  
path structure internally change one has a lot of string subs to do  
in the source. TANSTAAFL. 
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] py2app = newbie path confusion

2006-04-19 Thread Charles Hartman

I think one frequent reason people fall back on 'from xxx import *' is simply that typing the whole module name over and over gets tedious and makes the code sprawl. I find 'import xxx as yyy' very useful for this, since it can give you a nice short alias, still readable if you're careful about naming, to sprinkle through the code.Charles HartmanOn Apr 19, 2006, at 11:18 AM, Daniel Lord wrote:But 'from xxx import *' makes it too easy to   forget them since it mashes the namespaces together. I've rarely   encountered collisions but I try not to be that lazy. I try to use   'import ' and prefix the module name as often as practical fro   that reason.  ___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fixing the documentation...

> >4.2 Carbon.AH -- Apple Help
> 
> Do nothing.

Much like Apple Help itself :-).

Bill
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fixing the documentation...

2006-04-19 Thread Nicholas Riley

On Wed, Apr 19, 2006 at 02:38:22PM +0100, has wrote:
> >2.3 ic -- Access to Internet Config
> 
> No idea about this. Anyone else know if this is still working/relevant?

It is basically deprecated for LaunchServices now.  It would be really
good if we could get a decent LaunchServices binding - as of now,
there are several, all of which have some problems (?).

> >4.1 Carbon.AE -- Apple Events
> 
> Ronald's been thinking it might be best to deprecate both Carbon.AE
> and Carbon.OSA and keep all the AE/OSA/appscript stuff
> together. Dunno if he's got any further on that yet; you could ask.

How far do you think your stuff is from being able to be incorporated
in the standard library?  It'd be much nicer to just replace it rather
than removing it.

> >4.7 Carbon.Cm -- Component Manager
> 
> According to Apple's docs CM is largely historical; modern apps should use 
> Core Foundation's Plug-in Services. Other Carbon APIs still rely on it 
> though, so do nothing.

Not to mention QuickTime and CoreAudio, which aren't going away any time soon.

> >4.20 Carbon.Res -- Resource Manager and Handles
> 
> According to Apple's docs, RM is historical, but I'm not sure about 
> alternatives; need to check out Bundle Services. For now, probably do nothing.

Resources are still used quite a bit by OS X; don't think it's worth
deprecating.

> >5. Undocumented Modules
> >5.1 applesingle -- AppleSingle decoder
> 
> No idea. Anyone?

Dunno, but it'd sure be nice if there were a programmatic interface to
Bom.framework (which does AppleDouble, zips and cpio files with Mac
metadata).  This is Apple's problem, not ours, though.

> >5.4 icopen -- Internet Config replacement for open()
> 
> Presumably in the same boat as '2.3 ic'. Anyone?

Yeah, deprecate for LaunchServices.

-- 
Nicholas Riley <[EMAIL PROTECTED]> | 
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fixing the documentation...

Thanks, Has.

I was hoping someone would go through that list bit-by-bit.

I'm still in favor of simply removing outdated and dangerous docs, but
perhaps there's some effective way of thoroughly marking them as bad,
instead.

Bill
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Psycho & 2.4.3 universal

Jacob Rus wrote:
> Argh, never mind that message.  I see now that psyco is clearly labeled 
> as only working on i386.  Nothing to see here, move along.

It'd be nice to know how/if it works on an Intel Mac, however. Anyone?

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening

Bob Ippolito wrote:
> *ALWAYS* prefer convenience over space.  Never make separate 
> distributions for i386 and PPC.  Simplicity is key.

Absolutely.

> I will no longer accept single-architecture packages for 
> pythonmac.org/packages except under special circumstances

However... Right now, we don't have Universal packages for most things. 
This creates a difficult situation for folks, particularly those on 
Intel Macs. It is a serious challenge to build Universal packages, at 
least for those packages that rely on third party libs (PIL, Matplotlib, 
wxPython)

Until those folks with the skills to do it find the time to build some 
of the most common ones, I'm not sure it's such a bad idea to have a 
repository for i386 and PPC-only packages.

About those libs:

As it is a challenge to build universal libs, and a bunch of common 
python packages require the same libs, I'd love to see a repository of 
Universal libs for use with Python packages.

My suggestion:

A ExtraLibs.mpkg, right there with the packages on pythonmac.org that 
includes Universal shared libs required by some common packages. They 
could perhaps be installed in the Python Framework, so they won't 
interfere with anything else.

a) is this possible?
b) is this a good idea?

I suggest the following libs:

libfreetype
libpng
libjpeg

Other common ones?

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] py2app = newbie path confusion

corporate user wrote:
> I'm forming the opinion that  
> "from XXX import *" should be banned from all introduction, tutorial  
> and example materials.

Actually, it should be banned from virtually ALL user code! But tutorial 
and examples are a start!

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] py2app = newbie path confusion

corporate user wrote:
> I made the assumption that since py2app automagically created an  
> Apple application without my having to know anything about a bundle  
> or its structure, that it would also create path emulation as well.

I'm not sure that's your problem. I think your problem is really with 
the concept of a "working directory" when you start a python script from 
the command line, the working directory is the one that you're in when 
you start it up. When you double click and App, who knows what it is? 
(I'm sure it's defined, but I wouldn't ever count on it being useful, 
and it's definably not the same across platforms). So you need to either 
use full paths everywhere, or set the working directory yourself. I'd do 
the former.

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] py2app = newbie path confusion

2006-04-19 Thread Zachery Bir

On Apr 19, 2006, at 12:53 PM, Christopher Barker wrote:

> corporate user wrote:
>> I'm forming the opinion that
>> "from XXX import *" should be banned from all introduction, tutorial
>> and example materials.
>
> Actually, it should be banned from virtually ALL user code! But  
> tutorial
> and examples are a start!

It has a strong place in PyObjC, where we're putting our natural  
inclination for multi-layered namespaces aside to fit in with the  
conventions of ObjC's single namespace. At least there (in PyObjC's  
context), it's a natural fit, and I'd much rather it continue to be  
presented as the convention.

I know you said "virtually", but given the fact this is the pythonmac  
mailing list, and PyObjC plays (at least for me) a very big part of  
the Python on Mac landscape, I'd hate to see a ban on what is  
arguably a harmless (and very timesaving!) use of "from x import *".

Zac

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening

On Apr 19, 2006, at 9:49, Christopher Barker wrote:
> My suggestion:
>
> A ExtraLibs.mpkg, right there with the packages on pythonmac.org that
> includes Universal shared libs required by some common packages. They
> could perhaps be installed in the Python Framework, so they won't
> interfere with anything else.
>
> a) is this possible?
> b) is this a good idea?
>
> I suggest the following libs:
>
> libfreetype
> libpng
> libjpeg
>
> Other common ones?

I built Universal jpeg-6b, freetype2, and zlib for my current project  
of Universal PIL. I can add libpng in easily so I'll do it.
So that makes jpeg, png, freetype, and zlib. What else?

On the other topic...
I have successfully packaged up a Universal PIL for 2.4 (thanks for  
the tips Bob;-). Packaged--not tested yet on PPC and Intel so I am  
closer to releasing it.
However, it isn't including the libs so I am studying py2app and  
bdist_mpkg nuances to figure out how to package them all in one  
installer.

Once I get this done, I'll post it the instructions for hand building  
in the wiki and the all-in-one plus a separate Universal libs package  
on my iDisk.
I am also trying to see if I can make a quick and dirty shell script  
using curl, sed, and toehr tools to create a one-button build and  
install but that is after the above.

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fixing the documentation...

On Apr 19, 2006, at 9:14, Bill Janssen wrote:

> I'm still in favor of simply removing outdated and dangerous docs, but
> perhaps there's some effective way of thoroughly marking them as bad,
> instead.

Put in doc sections entitled Deprecated and Obsolete and do the same  
for the web and wiki.
I'll help at some point but I am busy with this PIL/Lib thing right  
now ;-)
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fixing the documentation...

Bill Janssen wrote:

>Thanks, Has.
>
>I was hoping someone would go through that list bit-by-bit.

See also NR's post and my reply to it; anything Internet Config-related looks 
reasonable to add to the 'deprecate' list. Hopefully there'll be a few more 
yeas/nays on it from other folks; like I say there's still a few I'm not sure 
about.

>I'm still in favor of simply removing outdated and dangerous docs, but
>perhaps there's some effective way of thoroughly marking them as bad,
>instead.

I dunno if there's anything actually "dangerous" in there; it's more just a 
case of "bloody awful-looking", "a complete waste of readers' time to trawl 
through" and "a rotten first impression for newcomers". Which still matters, of 
course; it just takes longer to drum up the motivation to deal with it. :)

I'd agree that chapter 1's content should all be deleted as the stuff it refers 
to no longer exists. Replace it with a placeholder page (for now) that 
describes what's currently available: python/pythonw in Terminal.app, IDLE, 
PythonLauncher and BuildApplet (BA should probably be marked deprecated). Could 
also mention that OS X's system-wide scripts menu can - permissions willing - 
be used to run .py (and other) shell scripts.

For deprecating individual modules, best to follow the standard procedure 
though. For documentation it seems to mean adding a bold "Deprecated since 
release 2.x" line at the top of the page for a whole module, or to the end of a 
individual function's description. (Pretty weak, if you ask me, but if that's 
the official policy then that's the official policy.) But you really need to 
check with the proper sources before doing anything.

HTH

has
-- 
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

> There's the flat logo, but the logo I was pointing to was a version
> that's shaded a bit to look slightly raised and rounded.

Were you looking for something more like [this][1]?

-Jacob

[1]: http://hcs.harvard.edu/~jrus/python/Glassy-Icon.png

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Pythonmac-SIG] Fixing the documentation...

Nicholas Riley wrote:

> > >2.3 ic -- Access to Internet Config
> >
> > No idea about this. Anyone else know if this is still working/relevant?
>
>It is basically deprecated for LaunchServices now.

Righto, add it to the 'deprecate' list then.

> It would be really good if we could get a decent LaunchServices binding - as 
> of now, there are several, all of which have some problems (?).

Bob did an LS wrapper early on, but it's long been superceded by the one in 
Python 2.4's standard library,  which is the only one that counts. If there's 
deficiencies in that then bug reports, feature requests, patches, etc. should 
be filed on that.  But this is a topic for a different thread.

> > >4.1 Carbon.AE -- Apple Events
> >
> > Ronald's been thinking it might be best to deprecate both Carbon.AE
> > and Carbon.OSA and keep all the AE/OSA/appscript stuff
> > together.
>
>How far do you think your stuff is from being able to be incorporated
>in the standard library?

Like PyObjC, I'm in no rush. Keeping things outside of the stdlib has its 
advantages too. Personally I think Win32All has the right idea: put all the 
platform-specific extensions in a separate all-in-one collection. Then they're 
not at the mercy of Python proper's development cycle. But this is also a topic 
for another thread. :)

>It'd be much nicer to just replace it rather than removing it.

Mind that deprecating Carbon.AE != removing it. It'll be a couple more Python 
revisions before the possibility of removal even arises, and there's no 
requirement to drop it even then.

I suspect Ronald's reasoning is that it'd be more hassle to merge CarbonX.AE 
and CarbonX.OSA back into the standard library than leave them where they are. 
There's precious few parties using these extensions anyway - appscript and co. 
are the major ones - so reincorporating them doesn't really gain you anything 
beyond a warm-n-fuzzy sense of "completeness". Nice; but why make extra work 
for oneself?

Anyway... I'll be using my own copies of AE.so and OSA.so for the forseeable 
future anyhow (backwards' compatibility), so I couldn't care less either way 
what happens to Carbon.AE and Carbon.OSA.

> > >4.20 Carbon.Res -- Resource Manager and Handles
> >
> > According to Apple's docs, RM is historical, but I'm not sure about 
> > alternatives; need to check out Bundle Services. For now, probably do 
> > nothing.
>
>Resources are still used quite a bit by OS X; don't think it's worth
>deprecating.

Resources are still in use, but the crusty old Resource Manager API itself has 
been superceded by the modern Bundle Services API which is what folks should be 
using nowadays. But since Carbon.CF doesn't seem to include Bundle Services, 
it's probably preferable to leave RM as-is on account of something is better 
than nothing. (Unless it's actually broken, of course.)

> > Presumably in the same boat as '2.3 ic'. Anyone?
>
>Yeah, deprecate for LaunchServices.

Yep, agree with that.

Cheers,

has
-- 
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] py2app = newbie path confusion

On Apr 19, 2006, at 10:03, Zachery Bir wrote:

> On Apr 19, 2006, at 12:53 PM, Christopher Barker wrote:
>
>> corporate user wrote:
>>> I'm forming the opinion that
>>> "from XXX import *" should be banned from all introduction, tutorial
>>> and example materials.
>>
>> Actually, it should be banned from virtually ALL user code! But
>> tutorial
>> and examples are a start!
>
> It has a strong place in PyObjC, where we're putting our natural
> inclination for multi-layered namespaces aside to fit in with the
> conventions of ObjC's single namespace. At least there (in PyObjC's
> context), it's a natural fit, and I'd much rather it continue to be
> presented as the convention.
>
> I know you said "virtually", but given the fact this is the pythonmac
> mailing list, and PyObjC plays (at least for me) a very big part of
> the Python on Mac landscape, I'd hate to see a ban on what is
> arguably a harmless (and very timesaving!) use of "from x import *".

It is fine in modules where the scoping and namespaces are  
thoughtfully implemented.
Banning is too strong a word. It kind like a hand grenade--really  
dangerous for the unskilled, but man when you need one, you really  
need one ;-)

Beginner's should be cautioned and receive qualified instruction  
before using: i.e. it should be documented ;-)
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fixing the documentation...

Bob Ippolito wrote:

>>In addition, all mentions of OS 9 should either be expunged (e.g. the 'using 
>>Python on Mac OS 9' chapter) or changed to 'not supported' (should they still 
>>need to be documented for any reason).
>
>Mac OS 9 is definitely no longer supported at all.  The *final* release for OS 
>9 is 2.3.3.  There are no plans of there ever being a current version for that 
>platform again.

OK, expunge all mentions of 'OS 9' then. Agree with the rest too, apart from a 
couple things I'm not sure about:

>>>   2.7 EasyDialogs -- Basic Macintosh dialogs
>>[...]
>
>Remove, it depends on waste.

Didn't see a waste dependency in the module; you sure about that? I've tried it 
and it still seems to be working okay (as well as it ever did, anyway), in 
which case immediate removal is not necessary. I wouldn't be averse to 
deprecating it just on general principle though. :)

>>>   4.4 Carbon.CF -- Core Foundation
>
>This one is kinda broken and is irrelevant when PyObjC is installed.  
>It might have some minimal usage somewhere though.  I'd deprecate it.

How about putting a warning note on it for now saying it's buggy, and if nobody 
loves it enough to submit patches in the next year then deprecate it for 2.6? 
Inasmuch as the standard library includes any Mac-specific extensions in the 
first place you'd kinda expect it to include this one, so maybe give it a last 
opportunity before completely writing it off.

>>>4)  Should we document some of the newer stuff?
>>[...]
>>plistlib probably ought to be mentioned. I suspect it's evil, as it's not 
>>using the Property List Services API, but am not familiar enough with it to 
>>really say anything more with confidence.
>
>plistlib works ok.  It used to be horribly broken, but the current version 
>should be spec compliant.

Including binary plists and all that? I've not tried it recently so wouldn't 
know.

Cheers,

has
-- 
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

On Apr 19, 2006, at 10:33, Jacob Rus wrote:

>> There's the flat logo, but the logo I was pointing to was a version
>> that's shaded a bit to look slightly raised and rounded.
>
> Were you looking for something more like [this][1]?
>
> -Jacob
>
> [1]: http://hcs.harvard.edu/~jrus/python/Glassy-Icon.png

Much better. In fact a great deal better--its looks worthy of the Mac.
I could even say this is great. But, pushing the envelope a bit if  
you don't think I am being too demanding...
Can you 'aqua-fy it' little-- give it that slightly transparent look  
that is the Apple trademark?
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] py2app includes all python documentation in the app

2006-04-19 Thread Frank Niessink

Bob Ippolito:

> It does just copy Resources.  You'll have to use the latest py2app 0.2 
> maintenance branch from svn.
> 
> http://svn.red-bean.com/bob/py2app/branches/py2app-0.2-maint/

Thanks Bob,

I checked out py2app from the URL given, ran setup.py as instructed. 
When I run python setup.py py2app, I get the following exception:

copying /Library/Frameworks/Python.framework/Versions/2.4/bin/python -> 
/Users/frank/taskcoach/build/TaskCoach.app/Contents/Frameworks/Python.framework/Versions/2.4/bin
Traceback (most recent call last):
   File "make.py", line 125, in ?
 setup(**setupOptions)
   File 
"/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/core.py",
 
line 149, in setup
 dist.run_commands()
   File 
"/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/dist.py",
 
line 946, in run_commands
 self.run_command(cmd)
   File 
"/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/dist.py",
 
line 966, in run_command
 cmd_obj.run()
   File 
"/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/py2app/build_app.py",
 
line 373, in run
 self._run()
   File 
"/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/py2app/build_app.py",
 
line 494, in _run
 self.run_normal()
   File 
"/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/py2app/build_app.py",
 
line 554, in run_normal
 self.create_binaries(py_files, pkgdirs, extensions, loader_files)
   File 
"/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/py2app/build_app.py",
 
line 644, in create_binaries
 mm.run_file(runtime)
   File 
"/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/macholib/MachOStandalone.py",
 
line 87, in run_file
 mm.run_file(fn)
   File 
"/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/macholib/MachOGraph.py",
 
line 65, in run_file
 raise ValueError, '%r does not contain architecture %s' % 
(pathname, self.arch)
ValueError: '/Library/Frameworks/Python.framework/Versions/2.4/Python' 
does not contain architecture i386

This makes sense, somewhat, because I use the PPC version of Python 
2.4.1 on a Intel Mac Mini. The reason for this is that there is no 
universal build of wxpython available yet.

Apparently, py2app is expecting a i386 python version? Why? How can I 
tell it to expect and use the PPC version?

Thanks, Frank
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] readline: where and how installed?


On 18-apr-2006, at 23:48, Christopher Barker wrote:

> Ronald Oussoren wrote:
>> On 13-apr-2006, at 18:47, Zachary Pincus wrote:
>>> Also, a related query: Is there somewhere in the Python Framework
>>> structure that is appropriate for placing dynamic libraries that
>>> Python would link to?
>
>> I don't see what this would buy us. It is possible to do this, but
>> IMHO not really worth the trouble.
>
> I don't think it would buy anything for readline, but it would for  
> libs
> that are used by multiple python extensions, like libpng and
> libfreetype, for instance.

Why? I'd prefer to have fully self contained packages, and preferably
eggs at that. Having a shared libary makes it *harder* to independendly
update extensions using libpng or libfreetype.

I'll have to package up my package build script one of these days ;-)

Ronald

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

Jacob Rus wrote:

> > There's the flat logo, but the logo I was pointing to was a version
> > that's shaded a bit to look slightly raised and rounded.
>
>Were you looking for something more like [this][1]?
>[1]: http://hcs.harvard.edu/~jrus/python/Glassy-Icon.png

The snake logo you've used there is an earlier, boxier attempt that's not as 
pleasing to the eye, and not the final version used on python.org.

The version Bill means (I couldn't get his link to work) is this:

http://www.fastmirrors.org/python/pub/beta.python.org/resources/design/newlogo/python-logo-master-v3-trans.png

Each snake has a slight linear colour gradient running diagonally, and the 
outer edges are curved.

I posted a list of what seems to be needed earlier (still not got time to do 
them myself though); see:

http://mail.python.org/pipermail/pythonmac-sig/2006-April/016869.html

To which one might also add a Python egg icon - maybe a 3D egg with the Python 
logo on it, or a closed cuboid package-style box, or a standard Lego-cube-like 
plugin icon.

has
-- 
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac Python is DEAD

On 18-apr-2006, at 22:59, Advertising Department wrote:

> (I'm totally confused about the nine versions of python for Mac OS X,
> the defunct or just not updated for 2 years MacPython pages, the
> current state of the macintosh specific library modules, etc.)
>
> To give my 2 cents...
> It doesn't really matter about a logo, icon, or universal build. If
> there is no recent info on the OFFICIAL python.org linked web pages,
> most new users will think it's become defunct, and look no further.
> NEWS

Sorry? There is a link to a python installer for macosx on python.org.
We can't help that google points users that search for MacPython to  
Jack's
site who has basically disappeared and hasn't updated his site for a
long time.

It is annoying that www.python.org/download/mac doesn't mention the
universal installer. Could someone please fix that?

Ronald
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Psycho & 2.4.3 universal

On 19-apr-2006, at 0:11, Jacob Rus wrote:

> I wrote:
>> I couldn't compile [psyco][1] using the 2.4.3 universal version of
>> Python on my 12" powerbook.  I'm wondering if this is just a problem
>> with universal Python, or if psycho doesn't compile in general  
>> under OS X.
>
> Argh, never mind that message.  I see now that psyco is clearly  
> labeled
> as only working on i386.  Nothing to see here, move along.

There is someone to see for those users fortunate enough to own an  
intel mac :-)
It should be possible to compile psyco if you add '-arch i386' to the  
extra_compile_args
and extra_link_args in the setup.py for psyco.

Ronald

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

>> [1]: http://hcs.harvard.edu/~jrus/python/Glassy-Icon.png
> 
> Much better. In fact a great deal better--its looks worthy of the Mac.
> I could even say this is great. But, pushing the envelope a bit if  
> you don't think I am being too demanding...
> Can you 'aqua-fy it' little-- give it that slightly transparent look  
> that is the Apple trademark?

Well, that's what I was going for.  Is [this][2] better? ([Folder][3] 
with icns file)

I'm hardly an expert at drawing aqua icons, so my highlights might not 
be exactly right.  Someone else may want to take a crack at it.

In any case, even if a slightly more polished version of this is usable 
as a python document icon, what do we want to use for the other 
icons--drag-n-drop script runner, Editor/IDE, .pyc/.pyo files?  pyc 
could just be the same but with "PYC" written at the bottom, I guess, 
but it could also have the paper background modified to signify 
"compiled" in some way.

[2]: http://hcs.harvard.edu/~jrus/python/python-doc-icon-glassy.png
[3]: http://hcs.harvard.edu/~jrus/python/python-doc-icon-glassy.zip

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fixing the documentation...

On 19-apr-2006, at 2:23, Bill Janssen wrote:

> Just looking at the docs, I'm trying to figure out what's good and
> what's bad.
>
> 1) We should no longer point people to Jack's site, we point them to
>the python.org Mac download page instead.

Right.

>
> 2) references to PythonIDE and PackageManager should go.

Right again. I want to remove those from python2.5 if I can, or at least
move them somewhere where they cannot do harm.

>
> 3) What about the following:
>
> 2. MacPython Modules
> 2.1 macpath -- MacOS path manipulation functions
> 2.2 macfs -- Various file system services
> 2.2.1 FSSpec Objects
> 2.2.2 Alias Objects
> 2.2.3 FInfo Objects
> 2.3 ic -- Access to Internet Config
> 2.3.1 IC Objects
> 2.4 MacOS -- Access to Mac OS interpreter features
> 2.5 macostools -- Convenience routines for file manipulation
> 2.6 findertools -- The finder's Apple Events interface
> 2.7 EasyDialogs -- Basic Macintosh dialogs
> 2.7.1 ProgressBar Objects
> 2.8 FrameWork -- Interactive application framework
> 2.8.1 Application Objects
> 2.8.2 Window Objects
> 2.8.3 ControlsWindow Object
> 2.8.4 ScrolledWindow Object
> 2.8.5 DialogWindow Objects
> 2.9 autoGIL -- Global Interpreter Lock handling in event loops
> 3. MacPython OSA Modules
> 3.1 gensuitemodule -- Generate OSA stub packages
> 3.2 aetools -- OSA client support
> 3.3 aepack -- Conversion between Python variables and  
> AppleEvent data containers
> 3.4 aetypes -- AppleEvent objects
> 3.5 MiniAEFrame -- Open Scripting Architecture server support
> 3.5.1 AEServer Objects
> 4. MacOS Toolbox Modules
> 4.1 Carbon.AE -- Apple Events
> 4.2 Carbon.AH -- Apple Help
> 4.3 Carbon.App -- Appearance Manager
> 4.4 Carbon.CF -- Core Foundation
> 4.5 Carbon.CG -- Core Graphics
> 4.6 Carbon.CarbonEvt -- Carbon Event Manager
> 4.7 Carbon.Cm -- Component Manager
> 4.8 Carbon.Ctl -- Control Manager
> 4.9 Carbon.Dlg -- Dialog Manager
> 4.10 Carbon.Evt -- Event Manager
> 4.11 Carbon.Fm -- Font Manager
> 4.12 Carbon.Folder -- Folder Manager
> 4.13 Carbon.Help -- Help Manager
> 4.14 Carbon.List -- List Manager
> 4.15 Carbon.Menu -- Menu Manager
> 4.16 Carbon.Mlte -- MultiLingual Text Editor
> 4.17 Carbon.Qd -- QuickDraw
> 4.18 Carbon.Qdoffs -- QuickDraw Offscreen
> 4.19 Carbon.Qt -- QuickTime
> 4.20 Carbon.Res -- Resource Manager and Handles
> 4.21 Carbon.Scrap -- Scrap Manager
> 4.22 Carbon.Snd -- Sound Manager
> 4.23 Carbon.TE -- TextEdit
> 4.24 Carbon.Win -- Window Manager
> 4.25 ColorPicker -- Color selection dialog
> 5. Undocumented Modules
> 5.1 applesingle -- AppleSingle decoder
> 5.2 buildtools -- Helper module for BuildApplet and Friends
> 5.3 cfmfile -- Code Fragment Resource module
> 5.4 icopen -- Internet Config replacement for open()
> 5.5 macerrors -- Mac OS Errors
> 5.6 macresource -- Locate script resources
> 5.7 Nav -- NavServices calls
> 5.8 PixMapWrapper -- Wrapper for PixMap objects
> 5.9 videoreader -- Read QuickTime movies
> 5.10 W -- Widgets built on FrameWork
> 5.11 waste -- non-Apple TextEdit replacement
>
> My inclination is to delete them all :-).  Except for ones where
> someone pipes up and tells me it still works.  Let folks use the Wiki
> to find modules.

I don't think you can remove them. IIRC some of this is generated  
somehow (although I don't know how).

Macpath deals with OS9/Carbon style paths (Volume:directory:file  
instead of /Volume/directory/file). This might be usefull when using  
Carbon API's. The documentation for this module (and several others)  
does need to mention this instead of confusing users by mentioning it  
is for the mac.

Section 4 (MacOS Toolbox Modules) definitely needs some text. At the  
very least it needs a general explanation about how to translate  
between the C interface as described in Apple's documentation and the  
Python interface.

W (5.10) and waste (5.11) should probably go, waste won't work on  
intel systems anyway and W is ancient and not update for Carbon Events.

Gensuitemodule should be deprecated, at the very least in the  
documentation. I don't know if we can point users to software that's  
not in the stdlib, but if we can I'd add a reference to appscript in  
the deprecation message in the documentation. Has can probably  
comment on the usefulness of the rest of section 3.

I don't know enough about the rest to make useful comments about  
them. I do think however that we shouldn't remove all documentation,  
but should instead work on improving both the documentation and  
ac

Re: [Pythonmac-SIG] Fixing the documentation...

Bob Ippolito wrote:

[EasyDialogs]
>>Didn't see a waste dependency in the module; you sure about that? I've tried 
>>it and it still seems to be working okay (as well as it ever did, anyway), in 
>>which case immediate removal is not necessary. I wouldn't be averse to 
>>deprecating it just on general principle though. :)
>
>I thought it depended on W, which I think depends on waste.  Maybe I'm wrong 
>though.  I've steered clear of all that stuff for quite a while.

Nope, just the Carbon extensions from what I can tell.

>A PyObjC-based replacement for EasyDialogs would be convenient though.  The 
>problems with EasyDialogs are mostly just because the implementation is 
>ancient.

Yep. The only catch about doing a set of simple, general-purpose in PyObjC is 
that you'd have PyObjC as a heavyweight dependency, and the main motivations 
for having something like ED are its simplicity and lightweightedness. It fills 
a low-end niche. The Nav module provides file dialogs, so really all that's 
needed is modern message, text entry and progress bar dialog implementations - 
preferably without requiring any new external dependencies.

But anyway... any replacement is some way off. For now it's just a case of 
deciding whether to leave ED and its documentation as-is or deprecate it. I say 
deprecate if other folks agree.

>>>plistlib works ok.  It used to be horribly broken, but the current version 
>>>should be spec compliant.
>>
>>Including binary plists and all that? I've not tried it recently so wouldn't 
>>know.
>
>No, it does not support binary plists or NeXT style plists.  It supports XML 
>plists.  Still useful though.

Sounds like a future reimplementation/replacement that uses the Core Foundation 
API instead of trying to parse things itself would be a wise move.

For now though, I'd say just add a short page to the documentation so folk know 
the plistlib module exists and put a note on it indicating its limitations.

Cheers,

has
-- 
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup


On Apr 19, 2006, at 12:08, Jacob Rus wrote:

>>> [1]: http://hcs.harvard.edu/~jrus/python/Glassy-Icon.png
>>
>> Much better. In fact a great deal better--its looks worthy of the  
>> Mac.
>> I could even say this is great. But, pushing the envelope a bit if
>> you don't think I am being too demanding...
>> Can you 'aqua-fy it' little-- give it that slightly transparent look
>> that is the Apple trademark?
>
> Well, that's what I was going for.  Is [this][2] better? ([Folder][3]
> with icns file)
>
> I'm hardly an expert at drawing aqua icons, so my highlights might not
> be exactly right.  Someone else may want to take a crack at it.
>
> In any case, even if a slightly more polished version of this is  
> usable
> as a python document icon, what do we want to use for the other
> icons--drag-n-drop script runner, Editor/IDE, .pyc/.pyo files?  pyc
> could just be the same but with "PYC" written at the bottom, I guess,
> but it could also have the paper background modified to signify
> "compiled" in some way.
>
> [2]: http://hcs.harvard.edu/~jrus/python/python-doc-icon-glassy.png
> [3]: http://hcs.harvard.edu/~jrus/python/python-doc-icon-glassy.zip

I like it. But HAS is right--the icon on the www.python.org home page  
is more rounded. Now if you could take the new one and make it  
beveled and glassy liek you did the 'blocky' one I'd say we have a  
winner IMHO ;-)
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] py2app includes all python documentation in the app

2006-04-19 Thread Frank Niessink

Bob Ippolito:
>>
>> Apparently, py2app is expecting a i386 python version? Why? How can I
>> tell it to expect and use the PPC version?
> 
> I actually don't know, I didn't write those patches.  I won't have time 
> to look into this for at least a week, but you might want to dig into 
> the source code and see if there's a way to ask it for some particular 
> architecture.

Your suggestion made me indeed read through the source code which made 
me find out there is an 'archs' option you can pass to py2app. archs is 
a comma-separated list of archs (in a string) to include. So I now pass 
"archs='ppc'" to py2app, which gets rid of the previous exception.

However, now I run an error while py2app is copying 
/Library/Frameworks/Python.framework/Versions/2.4/Python to the app 
bundle. It looks like it is copying that file twice which apparently the 
underlying code doesn't like (I think that is one of shutil's methods).
I'll investigate some more.

Thanks for the help, Frank
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fixing the documentation...

On 19-apr-2006, at 15:38, has wrote:

>
>
>>2.1 macpath -- MacOS path manipulation functions
>
> Deprecate. Also note that the 2.4.3 documentation now says "It can  
> be used to manipulate old-style Macintosh pathnames on Mac OS X (or  
> any other platform)." which is incorrect (it uses POSIX-style  
> paths), so delete that sentence.

I'm not a native english speaker, but I read this as "you can use  
this to manipulate OS9 style paths on any platform". Just like you  
can use ntpath to manipulate windows-style paths (c:\foo\bar.txt) on  
any platform. That's actually a useful feature.

As I mentioned in another message this module might be useful to work  
with OS9-style paths as used by some Carbon API's.
>
>>2.4 MacOS -- Access to Mac OS interpreter features
>
> Get/SetCreatorAndType should really be fixed or deprecated as they  
> don't appear to work for bundle-based files.

They should be fixed. Why does everyone want to remove what they  
don't quite understand? One of the strong points of python on the mac  
is that it is one of the *very* few languages that provides bindings  
to most parts of the system APIs. IMHO the bindings to Carbon suck,  
but that doesn't mean we should scrap or completely hide them.

Stuff should be deprecated and removed only if we are absolutely sure  
it is useless, and preferably only if we have a replacement. An  
example of this is application scripting support, everybody seems to  
agree that appscript is miles better than the stuff in the stdlib.

I'd love to deprecate Carbon.CF as well, but we can't do that until  
we have another way to access those APIs. PyObjC is about this > <  
close to doing that, I just haven't gotten around finishing the final  
bits yet.

>
>
>>2.5 macostools -- Convenience routines for file manipulation
>
> Not sure about this. It's pretty ancient and crusty though, so I'd  
> be inclined to deprecate.
>
>
>>2.6 findertools -- The finder's Apple Events interface
>
> Deprecate.
>
>
>>2.7 EasyDialogs -- Basic Macintosh dialogs
>
> It's ancient and very crusty, but until there's an up-to-date  
> replacement I guess it has to stay as-is for now, alas. Might be a  
> good idea to check functions for unicode compatibility, long string  
> support, etc. and add notes on any limitations found.
>
>
>>2.8 FrameWork -- Interactive application framework
>
> Deprecate.
>
>
>>2.9 autoGIL -- Global Interpreter Lock handling in event loops
>
> No idea. Anyone?

I think this can be deprecated. This is a pretty neat trick to give  
up the GIL while an eventloop is waiting for events. That way you can  
easily use multithreaded programs in a GUI. That was useful when  
PyObjC didn't do GIL management itself (in the days when Python 2.3b1  
was bleeding edge), but I don't think we still need this.

>
>
>>3. MacPython OSA Modules
>
> Deprecate.
>
>
>>4. MacOS Toolbox Modules
>
> These are just wrappers around the existing Carbon APIs. So as long  
> as those APIs are themselves relevant, so are the wrappers. You can  
> get background info, including a list of which APIs are legacy-only  
> at:
>
>  newtocarbon/chapter_1_section_1.html>

Right. As I mentioned in another message it would be nice if someone  
described the way API's are mapped from C to Python. That makes it  
easier to use examples and documentation for the C API.

>
>
>>4.1 Carbon.AE -- Apple Events
>
> Ronald's been thinking it might be best to deprecate both Carbon.AE  
> and Carbon.OSA and keep all the AE/OSA/appscript stuff together.  
> Dunno if he's got any further on that yet; you could ask.

I'm slowly moving forwards, like most people these days I'm too busy  
to spend much time on this.  I think it would be better to move all  
application scripting related code to an external package (and  
preferably one such package instead of the bundle of packages you  
need to install right now to get appscript). The rationale for this  
is that has is currently the only person that is working on  
application scripting support for python and that his work doesn't  
seem to be finished enough to freeze it by includeing it in the stdlib.

>
>
>>4.2 Carbon.AH -- Apple Help
>
> Do nothing.

Documentation would be nice :-)

>
>
>>4.3 Carbon.App -- Appearance Manager
>
> Apple's docs describe AM as 'the older QuickDraw-centric version of  
> HITheme', but don't note it as being superceded/deprecated so I  
> guess it should stay as-is.
>
>
>>4.4 Carbon.CF -- Core Foundation
>>4.5 Carbon.CG -- Core Graphics
>>4.6 Carbon.CarbonEvt -- Carbon Event Manager
>
> Do nothing.
>
>
>>4.7 Carbon.Cm -- Component Manager
>
> According to Apple's docs CM is largely historical; modern apps  
> should use Core Foundation's Plug-in Services. Other Carbon APIs  
> still rely on it though, so do nothing.
>
>
>>4.8 C

Re: [Pythonmac-SIG] Fixing the documentation...


On 19-apr-2006, at 18:14, Bill Janssen wrote:

> Thanks, Has.
>
> I was hoping someone would go through that list bit-by-bit.
>
> I'm still in favor of simply removing outdated and dangerous docs, but
> perhaps there's some effective way of thoroughly marking them as bad,
> instead.

I'm in favour of fixing stuff :-)

Ronald

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening


On 19-apr-2006, at 18:49, Christopher Barker wrote:

> Bob Ippolito wrote:
>> *ALWAYS* prefer convenience over space.  Never make separate
>> distributions for i386 and PPC.  Simplicity is key.
>
> Absolutely.
>
>> I will no longer accept single-architecture packages for
>> pythonmac.org/packages except under special circumstances
>
> However... Right now, we don't have Universal packages for most  
> things.
> This creates a difficult situation for folks, particularly those on
> Intel Macs. It is a serious challenge to build Universal packages, at
> least for those packages that rely on third party libs (PIL,  
> Matplotlib,
> wxPython)

I'll post the script I'm using to build universal packages this weekend.
I have recipes for the software I'm using and several other. That  
includes
PIL (including jpeg, tif and freetype support).

> About those libs:
>
> As it is a challenge to build universal libs, and a bunch of common
> python packages require the same libs, I'd love to see a repository of
> Universal libs for use with Python packages.

It is actually not very hard to build univeral libraries for most  
software.
I'd really prefer to ship addon packages as standalone eggs.

>
> My suggestion:
>
> A ExtraLibs.mpkg, right there with the packages on pythonmac.org that
> includes Universal shared libs required by some common packages. They
> could perhaps be installed in the Python Framework, so they won't
> interfere with anything else.
>
> a) is this possible?
yes

> b) is this a good idea?
no.

This is an arbitrary selection of libraries, why these and not others?

Ronald
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac Python is DEAD

> It is annoying that www.python.org/download/mac doesn't mention the
> universal installer. Could someone please fix that?

Will do.  Should this replace the dual-installer procedure that's
mentioned there?  For both 10.3 and 10.4?

Bill
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup


On 19-apr-2006, at 19:33, Jacob Rus wrote:

>> There's the flat logo, but the logo I was pointing to was a version
>> that's shaded a bit to look slightly raised and rounded.
>
> Were you looking for something more like [this][1]?

That one looks nice.

Ronald

>
> -Jacob
>
> [1]: http://hcs.harvard.edu/~jrus/python/Glassy-Icon.png
>
> ___
> Pythonmac-SIG maillist  -  [email protected]
> http://mail.python.org/mailman/listinfo/pythonmac-sig

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fixing the documentation...

2006-04-19 Thread Kevin Walzer

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ronald Oussoren wrote:

>>
>>>4.2 Carbon.AH -- Apple Help
>> Do nothing.
> 
> Documentation would be nice :-)
> 
>>

I might be able to help here. I've actually used this module in
non-Python apps (I used to use in Tcl/Tk apps by exec'ing 'python -c
"from Carbon.AH...") and Aquamacs still loads its help docs this way. A
Tkinter app I'm developing will also use this.

What's the format for documentation? Who should it be sent to?

- --
Kevin Walzer
Poetic Code
http://www.kevin-walzer.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFERplcrTC5hIgjqTMRAsCBAKCc9xo8vDnrmjXLkQo169WuRKZIVACdE0YQ
EnPHZBT02PfxgBrcrfASRjA=
=voUD
-END PGP SIGNATURE-
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fixing the documentation...

On Apr 19, 2006, at 12:52, Ronald Oussoren wrote:       2.1 macpath -- MacOS path manipulation functions  Deprecate. Also note that the 2.4.3 documentation now says "It can   be used to manipulate old-style Macintosh pathnames on Mac OS X (or   any other platform)." which is incorrect (it uses POSIX-style   paths), so delete that sentence.  I'm not a native english speaker, but I read this as "you can use   this to manipulate OS9 style paths on any platform". Just like you   can use ntpath to manipulate windows-style paths (c:\foo\bar.txt) on   any platform. That's actually a useful feature.  As I mentioned in another message this module might be useful to work   with OS9-style paths as used by some Carbon API's. Good suggestion, Ronald. I was just tinkering around with appscript and MS Excel a few days ago (still cannot access some things like borders properly and others are just 'bass-ackwards' in the Excel terminology defs so I gave up) but Excel expects colon-separated paths in file paths (yes even in 2004 when they last updated it). SO keeping the OS9 path separator routines is a good idea. I didn't know about them and so wrote my own regex conversion functions (ugh!) as a workaround.___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac Python is DEAD

2006-04-19 Thread skip

Bill> But the NEWS section of python.org is totally disfunctional.
Bill> Months go by without anyone bothering to add anything to it; I
Bill> think the trouble is that no one knows what the "add" procedure
Bill> is.

I tend to agree with you.  Given all the recent changes to the site,
including a completely new tool chain used to build it, details about
updating various bits like NEWS have been lost by many.

Skip

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fixing the documentation...

> 
> On 19-apr-2006, at 18:14, Bill Janssen wrote:
> 
> > Thanks, Has.
> >
> > I was hoping someone would go through that list bit-by-bit.
> >
> > I'm still in favor of simply removing outdated and dangerous docs, but
> > perhaps there's some effective way of thoroughly marking them as bad,
> > instead.
> 
> I'm in favour of fixing stuff :-)
> 
> Ronald
> 

Sure.  The question is, who's signing up to fix what, and how?

Bill
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac Python is DEAD

2006-04-19 Thread skip


Ronald> It is annoying that www.python.org/download/mac doesn't mention
Ronald> the universal installer.

It does now.  It will take a few minutes for the global build process to
update the website, but I checked in a minimal change to Subversion.

Skip
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fixing the documentation...

Ronald wrote:

>Macpath deals with OS9/Carbon style paths (Volume:directory:file  instead of 
>/Volume/directory/file).

Don't know where you're seeing this; I've tried a few of the functions and none 
work with HFS-style paths, only POSIX-style paths. The documentation describes 
it as an OS9 implementation of os.path, which I take to mean same Python API, 
presumably bridged to from os.path, but a different underlying implementation 
to get around the lack of POSIX APIs in OS 9 and earlier.

I would imagine os.path just uses the standard Unix APIs on OS X, in which case 
this module is completely redundant and can be removed fairly quickly after 
deprecation.

>Has can probably  comment on the usefulness of the rest of section 3.

Way ahead of you already. :)

http://mail.python.org/pipermail/pythonmac-sig/2006-April/017046.html

has
-- 
http://freespace.virgin.net/hamish.sanderson/
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac Python is DEAD

On 19-apr-2006, at 22:06, Bill Janssen wrote:

>> It is annoying that www.python.org/download/mac doesn't mention the
>> universal installer. Could someone please fix that?
>
> Will do.  Should this replace the dual-installer procedure that's
> mentioned there?  For both 10.3 and 10.4?

The universal installer can be used for OSX 10.3.9 and later. There is
no current installer for earlier releases of the OS.

I haven't checked yet if the universal installer on python.org is still
the original one without optimization or if it got replaced by the  
newer one.
I've removed the latter from my iDisk because I ran out of the  
bandwidth allotment
for my site :-(.

Ronald

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fixing the documentation...

On 19-apr-2006, at 22:11, Kevin Walzer wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Ronald Oussoren wrote:
>
>>>
4.2 Carbon.AH -- Apple Help
>>> Do nothing.
>>
>> Documentation would be nice :-)
>>
>>>
>
> I might be able to help here. I've actually used this module in
> non-Python apps (I used to use in Tcl/Tk apps by exec'ing 'python -c
> "from Carbon.AH...") and Aquamacs still loads its help docs this  
> way. A
> Tkinter app I'm developing will also use this.
>
> What's the format for documentation? Who should it be sent to?

The format is a dialect of LaTeX, but supplying just plain text  
should be
fine to as the documentation maintainers will convert it to the proper
format if needed. Any documentation should be uploaded as a patch on
sourceforge.

Ronald
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening

On Apr 19, 2006, at 13:04, Ronald Oussoren wrote:I'll post the script I'm using to build universal packages this weekend. I have recipes for the software I'm using and several other. That   includes PIL (including jpeg, tif and freetype support).I'll put mine on my iDisk and send you a link. I'd like to see your scripts since I did it by hand and recorded it with bash typescript--to later script it using sed for the text editing. I have a Macbook Pro and PPC will be happy to test things. It is actually not very hard to build univeral libraries for most   software.Yeah, if *I* can do it it cannot be too arcane ;-) I'd really prefer to ship addon packages as standalone eggs. AgreedDaniel___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fixing the documentation...

On 19-apr-2006, at 22:13, Bill Janssen wrote:

>>
>> On 19-apr-2006, at 18:14, Bill Janssen wrote:
>>
>>> Thanks, Has.
>>>
>>> I was hoping someone would go through that list bit-by-bit.
>>>
>>> I'm still in favor of simply removing outdated and dangerous  
>>> docs, but
>>> perhaps there's some effective way of thoroughly marking them as  
>>> bad,
>>> instead.
>>
>> I'm in favour of fixing stuff :-)
>>
>> Ronald
>>
>
> Sure.  The question is, who's signing up to fix what, and how?

I don't know who will do it, I do know that we won't get very far by  
just
talking about it ;-). Pick some part that you consider broken and  
propose
how this can be fixed. I do want to fix as many bugs as possible for  
python 2.5,
but that won't happen by itself.

Ronald

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac Python is DEAD


On 19-apr-2006, at 22:20, [EMAIL PROTECTED] wrote:

>
> Ronald> It is annoying that www.python.org/download/mac doesn't  
> mention
> Ronald> the universal installer.
>
> It does now.  It will take a few minutes for the global build  
> process to
> update the website, but I checked in a minimal change to Subversion.

Thanks.

Ronald

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Mac Python is DEAD

NEWS was broken long before the new site.

Bill
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fixing the documentation...

2006-04-19 Thread skip


Ronald> I don't know who will do it, I do know that we won't get very
Ronald> far by just talking about it ;-). Pick some part that you
Ronald> consider broken and propose how this can be fixed. I do want to
Ronald> fix as many bugs as possible for python 2.5, but that won't
Ronald> happen by itself.

If you find something that needs fixing to the website and don't have
Subversion checkin privileges, feel free to send me ([EMAIL PROTECTED]) the
proposed change(s).  I tend to get behind reading Python mailing lists not
directly related to Python development, but if you send changes directly to
me I'll try and get to them within a few hours or a day.

Skip
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening

On 19-apr-2006, at 22:27, Daniel Lord wrote:

>
> On Apr 19, 2006, at 13:04, Ronald Oussoren wrote:
>
>> I'll post the script I'm using to build universal packages this  
>> weekend.
>> I have recipes for the software I'm using and several other. That
>> includes
>> PIL (including jpeg, tif and freetype support).
> I'll put mine on my iDisk and send you a link. I'd like to see your  
> scripts since I did it by hand and recorded it with bash  
> typescript--to later script it using sed for the text editing. I  
> have a Macbook Pro and PPC will be happy to test things.

I have a python script that's derived from the script that I'm using  
to build the univeral python distribution.

>
>> It is actually not very hard to build univeral libraries for most
>> software.
> Yeah, if *I* can do it it cannot be too arcane ;-)

It can be pretty involved. If you're very unlucky you'll have to  
build a ppc and intel version version of software and then merge them  
using lipo. Luckily most python-related software I've run into until  
now can be coaxed into building using 'cc -arch ppc -arch i386' as  
the compiler.

Ronald

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

has wrote:
> Jacob Rus wrote:
>>> There's the flat logo, but the logo I was pointing to was a version
>>> that's shaded a bit to look slightly raised and rounded.
>> Were you looking for something more like [this][1]?
>> [1]: http://hcs.harvard.edu/~jrus/python/Glassy-Icon.png
> 
> The snake logo you've used there is an earlier, boxier attempt that's not as 
> pleasing to the eye, and not the final version used on python.org.
> 
> The version Bill means (I couldn't get his link to work) is this:
> 
> http://www.fastmirrors.org/python/pub/beta.python.org/resources/design/newlogo/python-logo-master-v3-trans.png
> 
> Each snake has a slight linear colour gradient running diagonally, and the 
> outer edges are curved.

Ok, got it.  Well, I've now put more time into this than I wanted to, 
but I've got a glassy version of the correct python logo at full size, 
[here][4].  Let me know what you all think.  If it looks good to 
everyone, I can make a .py icon like the one linked above, and an editor 
icon like Script Editor and TextEdit's, though someone will have to help 
me with the pen/pencil/whatever.  I'm still not clear what the 
"drag-n-drop script runner" icon should look like.

-Jacob

[4]: http://hcs.harvard.edu/~jrus/python/python-logo-glassy.png

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fixing the documentation...


On 19-apr-2006, at 22:23, has wrote:

> Ronald wrote:
>
>> Macpath deals with OS9/Carbon style paths (Volume:directory:file   
>> instead of /Volume/directory/file).
>
> Don't know where you're seeing this; I've tried a few of the  
> functions and none work with HFS-style paths, only POSIX-style  
> paths. The documentation describes it as an OS9 implementation of  
> os.path, which I take to mean same Python API, presumably bridged  
> to from os.path, but a different underlying implementation to get  
> around the lack of POSIX APIs in OS 9 and earlier.

 >>> help(macpath)

 >>> macpath.join('foo', 'bar')
':foo:bar'


macpath is what got used as os.path on MacOS9, just like posixpath is  
os.path on unixy systems (including OSX) and ntpath is used on  
windows. Those can be used directly to manipulate paths for other  
platforms which is occasionally useful.

>
> I would imagine os.path just uses the standard Unix APIs on OS X,  
> in which case this module is completely redundant and can be  
> removed fairly quickly after deprecation.

Yes, os.path is posixpath on OSX.
>
>
>> Has can probably  comment on the usefulness of the rest of section 3.
>
> Way ahead of you already. :)
>
> http://mail.python.org/pipermail/pythonmac-sig/2006-April/017046.html

I noticed ;-)

Ronald

>
> has
> -- 
> http://freespace.virgin.net/hamish.sanderson/

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

On Apr 19, 2006, at 13:41, Jacob Rus wrote:Ok, got it.  Well, I've now put more time into this than I wanted to,  but I've got a glassy version of the correct python logo at full size,  [here][4].  Let me know what you all think.  If it looks good to  everyone, I can make a .py icon like the one linked above, and an editor  icon like Script Editor and TextEdit's, though someone will have to help  me with the pen/pencil/whatever.  I'm still not clear what the  "drag-n-drop script runner" icon should look like.  -Jacob  [4]: http://hcs.harvard.edu/~jrus/python/python-logo-glassy.png Awesome! Ya da man! This get's my vote.___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] Universal PIL for Python 2.4 on OS X 10.4 needs testing

I tested my Universal PIL installer for Python 2.4 on 10.4 on my  
MacbookPro but not PPC (my daughters refuse to quit Zoo Tycoon 2 and  
log off so I can tinker with it ;-) and it seems to work though I  
don't have a rigorous PIL test suite. The zip file is on my iDisk if  
anyone wants to give it a try. If it works, please somebody move it  
to a public host so I don't use up my bandwidth allotment like Ronald  
did ;-)

http://homepage.mac.com/daniellord

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

2006-04-19 Thread Nicholas Riley

On Wed, Apr 19, 2006 at 04:41:59PM -0400, Jacob Rus wrote:
> Ok, got it.  Well, I've now put more time into this than I wanted to, 
> but I've got a glassy version of the correct python logo at full size, 
> [here][4].  Let me know what you all think.  If it looks good to 
> everyone, I can make a .py icon like the one linked above, and an editor 
> icon like Script Editor and TextEdit's, though someone will have to help 
> me with the pen/pencil/whatever.  I'm still not clear what the 
> "drag-n-drop script runner" icon should look like.

Looks great.  Quick, make the other icons before anyone else
complains! :)

-- 
Nicholas Riley <[EMAIL PROTECTED]> | 
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

2006-04-19 Thread Saggau

First thing that hit my brain:  "That's IT."   wrote:On Wed, Apr 19, 2006 at 04:41:59PM -0400, Jacob Rus wrote:
> Ok, got it.  Well, I've now put more time into this than I wanted to,> but I've got a glassy version of the correct python logo at full size,> [here][4].  Let me know what you all think.  If it looks good to
> everyone, I can make a .py icon like the one linked above, and an editor> icon like Script Editor and TextEdit's, though someone will have to help> me with the pen/pencil/whatever.  I'm still not clear what the
> "drag-n-drop script runner" icon should look like.Looks great.  Quick, make the other icons before anyone elsecomplains! :)--Nicholas Riley <
[EMAIL PROTECTED]> | ___Pythonmac-SIG maillist  -  
[email protected]://mail.python.org/mailman/listinfo/pythonmac-sig-- The extent to which an individual can resist being blindly led by tradition is a good measure of his vitality.  - Harry Partch
There is a computer disease that anybody who works with computers knows about. It's a very serious disease and it interferes completely with the work. The trouble with computers is that you 'play' with them! - Richard P. Feynman
Few people are capable of expressing with equanimity opinions which differ from the prejudices of their social environment.  Most people are not even capable of forming such opinions.  - Einstein
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

Ok, what do you all think of these script and compiled script icons:

PNG: http://hcs.harvard.edu/~jrus/python/python-icons-a1.png
ZIP: http://hcs.harvard.edu/~jrus/python/python-icons-a1.zip

The zip file contains icns files, png files, and also folders with the 
icons applied.

I'm glad to provide Photoshop files as well, if someone wants them.

-Jacob

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening

Bob Ippolito wrote:
> The libs should all be statically linked to the extensions, they 
> shouldn't be separate in the installer.

Ronald Oussoren wrote:
> I'd prefer to have fully self contained packages, and preferably
> eggs at that. Having a shared libary makes it *harder* to independendly
> update extensions using libpng or libfreetype.

No one answered my question directly, but both Bob and Ronald have spoken:

It's better for each package to statically link any libs it needs 
(unless Apple provides them), even though that means that a given python 
program may well end up using three copies of the same lib.

Just to be totally clear: Is there any problem with the same program 
using three slightly different versions of the same lib?

> I'll have to package up my package build script one of these days ;-)

What does it do? Something different than bdist_mpkg ?

Daniel Lord wrote:
> I built Universal jpeg-6b, freetype2, and zlib for my current project  
> of Universal PIL. I can add libpng in easily so I'll do it.
> So that makes jpeg, png, freetype, and zlib. What else?

Those are the ones I need at the moment. Thanks! I guess a zip archive 
of the collection would be the best way to get it out there.

> I have successfully packaged up a Universal PIL for 2.4 (thanks for  
> the tips Bob;-). Packaged--not tested yet on PPC and Intel so I am  
> closer to releasing it.

Post a link to it here when you are ready so we can test it.

Maybe it would be helpful to have a standard way to link static libs 
with our packages. What I've done for matplotlib is create a 
"StaticLibs" directory at the same level as the setup./py, then hacked 
the setup.py to include it in the linking (and header) paths.

I'll probably create one that has all of the above libs in it, then I 
can add a symlink to it for each package I'm trying to build.

If anyone has any better ideas, I'd be glad to hear them.

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

Jacob Rus wrote:
> Ok, what do you all think of these script and compiled script icons:

They look great, but what the heck is "DATA"?

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

2006-04-19 Thread Paul Berkowitz

On 4/19/06 1:41 PM, "Jacob Rus" <[EMAIL PROTECTED]> wrote:

> Ok, got it.  Well, I've now put more time into this than I wanted to,
> but I've got a glassy version of the correct python logo at full size,
> [here][4].  Let me know what you all think.  If it looks good to
> everyone, I can make a .py icon like the one linked above, and an editor
> icon like Script Editor and TextEdit's, though someone will have to help
> me with the pen/pencil/whatever.  I'm still not clear what the
> "drag-n-drop script runner" icon should look like.
> 
> -Jacob
> 
> [4]: http://hcs.harvard.edu/~jrus/python/python-logo-glassy.png

Looks great. And all the icons too.

-- 
Paul Berkowitz


___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

Christopher Barker wrote:
 > They look great, but what the heck is "DATA"?

It was has's [idea][1] for what a .pyo/.pyc icons should look like, 
similar to how script editor allows saving of plain text .applescript 
files with an icon labeled "TEXT".

[1]: http://mail.python.org/pipermail/pythonmac-sig/2006-April/016912.html

Here are my thoughts on the rest of his post:

 > IDLE.app application - a text-based script editor for
 > Python. I'd suggest something similar to Script
 > Editor.app, except using the Python logo and a different
 > style of pen (e.g. technical drawing pen/pencil) of
 > course.

Does someone have an example picture of a technical drawing pencil/pen 
that I could copy?

 > .py/.pyw files - Python source code document, editable
 > and executable; the 'normal' file format used by Python
 > scripters. I'd suggest something similar to AppleScript
 > .scpt files, except using the Python logo
 >
 > .pyc/.pyo files - Python binary code document,
 > executable but non-editable (should be similar to
 > .py/.pyw icon, exept indicating binary content); these
 > are mostly auto-generated by Python for efficiency. I'd
 > suggest a variation of the .py icon that indicated
 > binary content, e.g. a light backdrop of rows of random
 > 1s and 0s, or a word like '011010', 'byte' or 'data' in
 > its lower half.

Ok, this is what I tried to do with those examples.  Do people like them 
as is, or are there other ideas?

 > BuildApplet.app application - a drag-n-drop converter
 > that turns Python code files into standalone
 > double-clickable applications. A DropStuff.app-style
 > grinder (which is what the old icon uses) is certainly
 > one option.

Does anyone have an OS X icon suitable grinder image?  Alternately, 
something like the [help indexer][2] icon may work.  I agree we want the 
idea of scripts going in and applications coming out.  That probably 
means whatever we use for the applet icon should be coming out the other 
side.  Thoughts?

[2]: /Developer/Applications/Utilities/Help Indexer.app

 > applet applications - applets created by Build
 > Applet.app should be given a generic 'Python-based
 > applet' icon by default. Probably use something similar
 > to the AppleScript applets created by Script Editor.app.

Hmm.  I'm not sure whether python logo sitting on a white square will 
really do it.  I can try to mock that up though.  Are there any other 
ideas out there?

 > PythonLauncher.app application - a drag-n-drop script
 > runner. Possibly use something similar to the Applet
 > Launcher.app for Java.

Grey rocket ship with python logo on the front?  This might work, but 
also might look kind of lame, like the java Applet Launcher icon does. 
Then again, I don't have any great ideas for better ways to do this.

Also, does anyone have anyone have any suggestions for the glassy python 
logo before I go ahead and make a bunch more icons based on it?

-Jacob

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fixing the documentation...

Well, I was planning on fixing the documentation, but apparently the
process requires a level of bureaucracy I'm just not willing to go
through (though I can see why it might be necessary).  I can't just
check out the TeX sources and fix them, then check them back in.
Instead, I apparently have to submit patches against them to
sourceforge, using the cumbersome bugzilla, and wait for the
documentation elves to update the documents.

Perhaps this is why the documentation lags behind the code?

Bill
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening


On Apr 19, 2006, at 15:53, Christopher Barker wrote:

> Bob Ippolito wrote:
>> The libs should all be statically linked to the extensions, they
>> shouldn't be separate in the installer.
>
> Ronald Oussoren wrote:
>> I'd prefer to have fully self contained packages, and preferably
>> eggs at that. Having a shared libary makes it *harder* to  
>> independendly
>> update extensions using libpng or libfreetype.
>
> No one answered my question directly, but both Bob and Ronald have  
> spoken:
>
> It's better for each package to statically link any libs it needs
> (unless Apple provides them), even though that means that a given  
> python
> program may well end up using three copies of the same lib.
>
> Just to be totally clear: Is there any problem with the same program
> using three slightly different versions of the same lib?
NOt as far as I can tell--the libraries are statically linked so  
don't even need to be on the platform after that.
>
>> I'll have to package up my package build script one of these days ;-)
>
> What does it do? Something different than bdist_mpkg ?
By build I by hand: curl, patch code by hand, make; sudo make  
install. The libs need their make components patched to compile FAT  
binaries and PIL needed to be patched to find the .a files to link  
into its binaries. And freetype uses a confusing Jam-based install  
which had me searching for where to change it.
>
> Daniel Lord wrote:
>> I built Universal jpeg-6b, freetype2, and zlib for my current project
>> of Universal PIL. I can add libpng in easily so I'll do it.
>> So that makes jpeg, png, freetype, and zlib. What else?
>
> Those are the ones I need at the moment. Thanks! I guess a zip archive
> of the collection would be the best way to get it out there.
I'll zip up the .a files and put them on my iDisk--will send you a  
URL when ready.
>
>> I have successfully packaged up a Universal PIL for 2.4 (thanks for
>> the tips Bob;-). Packaged--not tested yet on PPC and Intel so I am
>> closer to releasing it.
>
> Post a link to it here when you are ready so we can test it.
Bob tested it and posted it already (see his email). More testing  
would be appropriate though.

> Maybe it would be helpful to have a standard way to link static libs
> with our packages. What I've done for matplotlib is create a
> "StaticLibs" directory at the same level as the setup./py, then hacked
> the setup.py to include it in the linking (and header) paths.
That sound reasonable, but not what I did--I installed them in /usr/ 
local/lib & include.
>
> I'll probably create one that has all of the above libs in it, then I
> can add a symlink to it for each package I'm trying to build.
>
> If anyone has any better ideas, I'd be glad to hear them.
>
> -Chris
>
>
>
>
> -- 
> Christopher Barker, Ph.D.
> Oceanographer
>   
> NOAA/OR&R/HAZMAT (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> [EMAIL PROTECTED]
> ___
> Pythonmac-SIG maillist  -  [email protected]
> http://mail.python.org/mailman/listinfo/pythonmac-sig

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

2006-04-19 Thread Dethe Elza

On 4/19/06, Jacob Rus <[EMAIL PROTECTED]> wrote:
> Ok, what do you all think of these script and compiled script icons:
>
> PNG: http://hcs.harvard.edu/~jrus/python/python-icons-a1.png
> ZIP: http://hcs.harvard.edu/~jrus/python/python-icons-a1.zip
>
> The zip file contains icns files, png files, and also folders with the
> icons applied.
>
> I'm glad to provide Photoshop files as well, if someone wants them.
>
> -Jacob

The icons are great, very Aqua and very Pythonic.  Thanks for the time
you put into this, and thanks to everyone else on the list for putting
in the effort to test and critique other designs.  This is going to
make Python on the Mac look much more professional than the old
falling weight did.  Very nice.

--Dethe
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

Jacob,

Looks fine.

It's interesting to look at the icons for TextEdit, in
/Applications/TextEdit.app/Contents/Resources/*.icns.

And looking at the XCode icons
(/Developer/Applications/Xcode.app/Contents/Resources/*.icns), it
looks like the "Mac way" of doing code icons (like for .py files) is
to start with
/Developer/Applications/Xcode.app/Contents/Resources/wosfile.icns and
add a text version of the file suffix, in our case ".py".  Apparently
it should be a color; I'd pick green because the ".java" icon is a
green one, and Python, like Java, is a byte-code interpreted language.

Bill
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] py2app argvemulation bug (or mis-configure) on i386 Python 2.4 on OS X 10.4

I decide to create a droplet from py2app in my copious spare time for  
a few minutes earlier and I noticed some errors in the Console plus  
the code is simply printing out all the strings in sys.argv plus, of  
course given the error, the paths of the files dropped on it never  
showed up in sys.argv[].

platform: Python 2.4 OS X 10.4 Universal MacbookPro i386
I did set: argv_emulation=True in the py2app options in setup.py

I this below a know error on Python 2.4 on Intel?

Console output:

Exception in AE event handler function
Traceback (most recent call last):
   File "/Library/Frameworks/Python.framework/Versions/2.4//lib/ 
python2.4/plat-mac/argvemulator.py", line 75, in callback_wrapper
 raise 'Cannot happen: AE callback without handler', (_class, _type)
Cannot happen: AE callback without handler: ('tvea', 'codo')
AE error:  (-1, 'queue element not found during deletion')
in High Level Event: '0x61657674' '0x6f636f64'
Traceback (most recent call last):
   File "/Library/Frameworks/Python.framework/Versions/2.4//lib/ 
python2.4/plat-mac/argvemulator.py", line 53, in lowlevelhandler
 AE.AEProcessAppleEvent(event)
Error: (-1, 'queue element not found during deletion')

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

Bill Janssen wrote:
> It's interesting to look at the icons for TextEdit, in
> /Applications/TextEdit.app/Contents/Resources/*.icns.
> 
> And looking at the XCode icons
> (/Developer/Applications/Xcode.app/Contents/Resources/*.icns), it
> looks like the "Mac way" of doing code icons (like for .py files) is
> to start with
> /Developer/Applications/Xcode.app/Contents/Resources/wosfile.icns and
> add a text version of the file suffix, in our case ".py".  Apparently
> it should be a color; I'd pick green because the ".java" icon is a
> green one, and Python, like Java, is a byte-code interpreted language.
No, I disagree.  If there is any text, it should be in dark gray 18 
point Lucida Grande, as per the HIG.  XCode uses colored file extensions 
in its document graphics because it deals with many different types of 
source files, and this keeps them distinguishable.  Python only has to 
worry about python scripts, and so a document icon with a 
distinguishable logo is sufficient (no need for text).  This follows the 
example of apps like Script Editor.

As for the rest of the icons.  [Here][1] are several icons used by 
various OS X apps.  Which of them should we draw on, and how?

-Jacob

[1]: http://hcs.harvard.edu/~jrus/python/misc-icons.png

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

I found two articles on creating icons that may provide some info.

http://www.oreillynet.com/lpt/a/866 and http://www.oreillynet.com/lpt/a/964.

Bill
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

> No, I disagree.  If there is any text, it should be in dark gray 18 
> point Lucida Grande, as per the HIG.  XCode uses colored file extensions 
> in its document graphics because it deals with many different types of 
> source files, and this keeps them distinguishable.

It's not just XCode.  *Users* deal with many different kinds of source
files, and apparently the icons used in XCode are the ones that Mac OS
X uses generically.  For example, look at the Finder icon for a Java
source file, and you'll see that the XCode icon is used there, as
well.  The greeked source code in the background of the document
indicates "source code", the file extension indicates the language,
and the color apparently indicates something as well, though it's not
clear (to me) just what.

I'm happy with your .py icon, though having the greeked source code in
the background would be cool.  Of course, it's not Python source code.
But we should be clear that we are using a non-Mac visual vocabulary
here.

Bill
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

Bill Janssen wrote:
>> No, I disagree.  If there is any text, it should be in dark gray 18
>>  point Lucida Grande, as per the HIG.  XCode uses colored file
>> extensions in its document graphics because it deals with many
>> different types of source files, and this keeps them
>> distinguishable.
> 
> It's not just XCode.  *Users* deal with many different kinds of
> source files, and apparently the icons used in XCode are the ones
> that Mac OS X uses generically.  For example, look at the Finder icon
> for a Java source file, and you'll see that the XCode icon is used
> there, as well.

Yes, java source files get the xcode icons, because XCode is set up on 
your machine as the editor for java files (and registered as such with 
Launch Services).  Similarly for c, etc.  On my machine, some of these 
get XCode document icons, and some get TextMate document icons, because 
for me, TextMate is the editor for those file types.

You miss my point, which is that python files don't need giant colored 
"py" splashed across them, if they have a distinguishable python icon. 
XCode does not follow the HIG, because it makes distinguishing c files 
from java files easier.  Our new python icon will not have this problem, 
because it only needs to represent with one type of file.

> The greeked source code in the background of the document indicates 
> "source code", the file extension indicates the language, and the 
> color apparently indicates something as well, though it's not clear 
> (to me) just what.

If you like, we could add some greeked source code.  If we do, then the 
pyo/pyc files will need something other than random 1s and 0s to 
distinguish it, especially at small sizes.  I'm open to suggestions.

> I'm happy with your .py icon, though having the greeked source code 
> in the background would be cool.  Of course, it's not Python source 
> code. But we should be clear that we are using a non-Mac visual 
> vocabulary here.

It's easy enough to add greeked python source code.  If the feeling is 
that this helps the icon, we can add whatever type of greeked source 
code we like.

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] Unintsaller for Universal

2006-04-19 Thread kevin parks

Hi... I been happily running 2.4.1 on my mac but i decided to load the 
universal installer on a different mac (that we plan to use for 
performance) and use 2.4.3 ... i mean why install and old version right 
  ... uhmm ... anyway 2.4.3 is causing me much acid indigestion and is 
not playing nice with an audio package that i use and depend on..  
(http://www.rtcmix.org)  clearly i me and the folks who make rtcmix 
don't know enough about distutils to be on the cutting edge... I am 
desperate to dumb down to 2.4.1 and reinstall my rtcmix install with 
that (since i know it works on the other mac that way just fine)  
My understanding from reading this SIG is that this puppy would have a 
clean UNINSTALLER ... yet i don't see it...  How do i uninstall 2.4.3? 
so that i can dial back to 2.4.1? or am i screwed?

cheers,

kevin


___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

2006-04-19 Thread Brendan Simons

>> Jacob Rus wrote:
>>
 There's the flat logo, but the logo I was pointing to was a version
 that's shaded a bit to look slightly raised and rounded.

>>> Were you looking for something more like [this][1]?
>>> [1]: http://hcs.harvard.edu/~jrus/python/Glassy-Icon.png
>>>
>> The snake logo you've used there is an earlier, boxier attempt  
>> that's not as pleasing to the eye, and not the final version used  
>> on python.org.
>> The version Bill means (I couldn't get his link to work) is this:
>> http://www.fastmirrors.org/python/pub/beta.python.org/resources/ 
>> design/newlogo/python-logo-master-v3-trans.png
>> Each snake has a slight linear colour gradient running diagonally,  
>> and the outer edges are curved.
>>
>
> Ok, got it.  Well, I've now put more time into this than I wanted  
> to, but I've got a glassy version of the correct python logo at  
> full size, [here][4].  Let me know what you all think.  If it looks  
> good to everyone, I can make a .py icon like the one linked above,  
> and an editor icon like Script Editor and TextEdit's, though  
> someone will have to help me with the pen/pencil/whatever.  I'm  
> still not clear what the "drag-n-drop script runner" icon should  
> look like.
>
> -Jacob
>
> [4]: http://hcs.harvard.edu/~jrus/python/python-logo-glassy.png


I fiddled with the java applet launcher icon a few weeks ago, but I  
didn't much like the result.  You can see a copy here:  http:// 
www.flickr.com/photos/[EMAIL PROTECTED]/131701626/
If you want the photoshop file with just the stretched out rocket,  
let me know

Brendan
--
Brendan Simons



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

2006-04-19 Thread Brendan Simons

On 19-Apr-06, at 8:57 PM, [EMAIL PROTECTED] wrote:Christopher Barker wrote: > They look great, but what the heck is "DATA"? It was has's [idea][1] for what a .pyo/.pyc icons should look like, similar to how script editor allows saving of plain text .applescript files with an icon labeled "TEXT". [1]: http://mail.python.org/pipermail/pythonmac-sig/2006-April/016912.htmlDATA is fine then I guess. The regular .py files should probably be badged "Python" as well, for users unfamiliar with the logo, and it could include a few lines of code (steal some from the cookbook) in the same font and colour as the "DATA" icon (see my thoughts on that below) > > .pyc/.pyo files - Python binary code document, > executable but non-editable (should be similar to > .py/.pyw icon, exept indicating binary content); these > are mostly auto-generated by Python for efficiency. I'd > suggest a variation of the .py icon that indicated > binary content, e.g. a light backdrop of rows of random > 1s and 0s, or a word like '011010', 'byte' or 'data' in > its lower half. Ok, this is what I tried to do with those examples. Do people like them as is, or are there other ideas?The general idea is good, but the implementation looks a bit cluttered. You could reduce the conflict by greying out the 10010 somewhat, making the font smaller (more lines), and leaving a bigger gap between the bottom of the 101010 and the word DATA. Somebody did this work for the last set of Python logos. Does anyone have the source? > PythonLauncher.app application - a drag-n-drop script > runner. Possibly use something similar to the Applet > Launcher.app for Java. Grey rocket ship with python logo on the front? This might work, but also might look kind of lame, like the java Applet Launcher icon does. Then again, I don't have any great ideas for better ways to do this. See my last email. Yeah, the potential for lameness is there, but maybe you can do something with it. Also, does anyone have anyone have any suggestions for the glassy python logo before I go ahead and make a bunch more icons based on it? I like it, but Aqua has tuned down a lot its glassiness in recent years. I would tone down the difference between highlights and shadows myself, but I'm not going to argue about it :)Good job! Brendan--Brendan Simons___
Pythonmac-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

2006-04-19 Thread Brendan Simons

On 20-Apr-06, at 12:15 AM, [EMAIL PROTECTED] wrote:From: Jacob Rus <[EMAIL PROTECTED]> Date: April 19, 2006 10:06:34 PM EDT (CA) To: [email protected] Subject: Re: [Pythonmac-SIG] Fwd: MacPython icon mockup   Bill Janssen wrote: No, I disagree.  If there is any text, it should be in dark gray 18  point Lucida Grande, as per the HIG.  XCode uses colored file extensions in its document graphics because it deals with many different types of source files, and this keeps them distinguishable. It's not just XCode.  *Users* deal with many different kinds of source files, and apparently the icons used in XCode are the ones that Mac OS X uses generically.  For example, look at the Finder icon for a Java source file, and you'll see that the XCode icon is used there, as well.  Yes, java source files get the xcode icons, because XCode is set up on your machine as the editor for java files (and registered as such with Launch Services).  Similarly for c, etc.  On my machine, some of these get XCode document icons, and some get TextMate document icons, because for me, TextMate is the editor for those file types.  You miss my point, which is that python files don't need giant colored "py" splashed across them, if they have a distinguishable python icon. XCode does not follow the HIG, because it makes distinguishing c files from java files easier.  Our new python icon will not have this problem, because it only needs to represent with one type of file.I agree completely.  The greeked source code in the background of the document indicates "source code", the file extension indicates the language, and the color apparently indicates something as well, though it's not clear (to me) just what.  If you like, we could add some greeked source code.  If we do, then the pyo/pyc files will need something other than random 1s and 0s to distinguish it, especially at small sizes.  I'm open to suggestions.I tried colourizing the document, but it's nearly impossible to find a colour that complements both the blue and yellow of the logo.  You could darken the paper slightly (not so much that you couldn't read the word "DATA" though. Brendan--Brendan Simons___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening

Daniel Lord wrote:

> That sound reasonable, but not what I did--I installed them in /usr/ 
> local/lib & include.

I've done that, but the only way I could make sure that they got 
statically linked was to make sure that there were not dynamic versions 
of the same libs anywhere else on the search path, so I found it easier 
to put them in a special place, and it's always possible that I'd have 
the dynamic libs installed for some other reason.

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

Jacob Rus wrote:
> Christopher Barker wrote:
>  > They look great, but what the heck is "DATA"?
> 
> It was has's [idea][1] for what a .pyo/.pyc icons should look like, 
> similar to how script editor allows saving of plain text .applescript 
> files with an icon labeled "TEXT".

Well, a script is text, but a .pyc file is not Data. Maybe "bytecode", 
which is too long, or "bytes" or "code" or ".pyc" or ???

In fact, I think the ones-and-zeros background without any words might 
work just fine.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

On Apr 19, 2006, at 21:41, Christopher Barker wrote:

> Well, a script is text, but a .pyc file is not Data. Maybe "bytecode",
> which is too long, or "bytes" or "code" or ".pyc" or ???

I think it should be an Apple with a bite out of it--get it? Apple,  
snake, apple, byte .
I kill myself ;-) Okay obviously I need to shut up and go away  
now...Bye.
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

Christopher Barker wrote:
> Jacob Rus wrote:
>> Christopher Barker wrote:
>>  > They look great, but what the heck is "DATA"?
>> It was has's [idea][1] for what a .pyo/.pyc icons should look like, 
>> similar to how script editor allows saving of plain text .applescript 
>> files with an icon labeled "TEXT".
> Well, a script is text, but a .pyc file is not Data. Maybe "bytecode", 
> which is too long, or "bytes" or "code" or ".pyc" or ???
> In fact, I think the ones-and-zeros background without any words might 
> work just fine.

Easy enough: http://hcs.harvard.edu/~jrus/python/pyc-icon-variations.png

Which do you prefer?

-Jacob

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Unintsaller for Universal

2006-04-19 Thread kevin parks

thank you bob you rock!

\m/ (>.<) \m/

this totally works ... (for anyone else needing to dumb down to 2.4.1)

cheers all...

-kp--



On Apr 20, 2006, at 1:02 AM, Bob Ippolito wrote:

>
> On Apr 19, 2006, at 7:55 PM, kevin parks wrote:
>
>> How do i uninstall 2.4.3?
>> so that i can dial back to 2.4.1? or am i screwed?
>
> I don't think there were any plans for an uninstaller.  Just install 
> 2.4.1 and everything will work fine, it'll overwrite everything that 
> needs to be overwritten.
>
> -bob

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

Brendan Simons wrote:
> I like it, but Aqua has tuned down a lot its glassiness in recent 
> years.   I would tone down the difference between highlights and shadows 
> myself, but I'm not going to argue about it :)

You're probably right, but make sure you look at the actual icon files 
(in the zip files I linked to earlier) as well as the png files.  There 
are some icc profile mismatch issues here, which I always seem to run 
into with png files (and it previews differently in Camino and Safari, 
for instance).  The actual version may be duller than the preview you're 
seeing.  Maybe I should post a screenshot instead of saving from photoshop.

-Jacob

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

On Apr 19, 2006, at 22:47, Jacob Rus wrote:Brendan Simons wrote: I like it, but Aqua has tuned down a lot its glassiness in recent  years.   I would tone down the difference between highlights and shadows  myself, but I'm not going to argue about it :)  You're probably right, but make sure you look at the actual icon files  (in the zip files I linked to earlier) as well as the png files.  There  are some icc profile mismatch issues here, which I always seem to run  into with png files (and it previews differently in Camino and Safari,  for instance).  The actual version may be duller than the preview you're  seeing.  Maybe I should post a screenshot instead of saving from photoshop. Jacob,I think your 'glassiness' is understated and fine. I never meant the extreme of the original colored iMac look.I think it adds a nice 3-D look especially in the smaller sizes and is under-stated enough to fit the Apple look of today with a little of a yellow and blue color Apple doesn't use. Could it be turned down a bit? Yeah I suppose. But there is a time to tweak and a time to move on when the diminishing returns of tweaking are vanishingly small and we can ignore subsequent terms in the series (flash-back to advanced engineering math ;-). Guess what time I think it is IMHO?Daniel___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

2006-04-19 Thread Nicholas Riley

On Thu, Apr 20, 2006 at 01:40:00AM -0400, Jacob Rus wrote:
> Easy enough: http://hcs.harvard.edu/~jrus/python/pyc-icon-variations.png
> 
> Which do you prefer?

I'd say "PYC", because although it isn't a word, the icon does a
better job of connoting the file contents than any of the other words,
and for people who know Python, "PYC" means something.

My second choice would be the unadorned one.

I'm actually wondering if using the folded-corner document icon for
.pyc files is a good idea at all.  The document icon usually indicates
something that can be edited or at least viewed, and a .pyc file
certainly can't be (easily :).  Consider the executable icon (cd into
/bin or whatever) as an example - although, I guess even run-only
AppleScripts get a document icon.

-- 
Nicholas Riley <[EMAIL PROTECTED]> | 
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup

Hi again,

So that others can more easily play with these icons, here are the 
Photoshop versions of the full-size glassy [logo][1], and the [document 
icons][2].  All the layers are included, so it should be pretty easy to 
tweak the highlights, etc.  I probably won't have any more time to work 
on this for 2-3 days.

-Jacob

[1]: http://hcs.harvard.edu/~jrus/python/python-logo.psd
[2]: http://hcs.harvard.edu/~jrus/python/python-icons.psd

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I succeeded this evening

On 20-apr-2006, at 0:53, Christopher Barker wrote:

> Bob Ippolito wrote:
>> The libs should all be statically linked to the extensions, they
>> shouldn't be separate in the installer.
>
> Ronald Oussoren wrote:
>> I'd prefer to have fully self contained packages, and preferably
>> eggs at that. Having a shared libary makes it *harder* to  
>> independendly
>> update extensions using libpng or libfreetype.
>
> No one answered my question directly, but both Bob and Ronald have  
> spoken:
>
> It's better for each package to statically link any libs it needs
> (unless Apple provides them), even though that means that a given  
> python
> program may well end up using three copies of the same lib.
>
> Just to be totally clear: Is there any problem with the same program
> using three slightly different versions of the same lib?

Thanks to two-level namespaces that shouldn't be a problem unless two
extensions share datastructures from a library. An example of this are
the curses and panel extensions in the stdlib, both link to libcurses
and they share datastructures from curses. You'll see a hard crash when
those extensions are staticly linked to curses.

>
>> I'll have to package up my package build script one of these days ;-)
>
> What does it do? Something different than bdist_mpkg ?

Its one level higher: a script that uses bdist_egg and bdist_mpkg to  
build
binary packages given a list of recipes. That makes it a lot easier to
tweak the build process or rebuild packages when the libraries they use
are changed. Its the result of a pet peeve: I like binary packages on
pythonmac.org, but don't like the fact that most of them seem to build
by hand and that some required manual prodding to get them to work.

Ronald
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup


On 20-apr-2006, at 0:30, Jacob Rus wrote:

> Ok, what do you all think of these script and compiled script icons:
>
> PNG: http://hcs.harvard.edu/~jrus/python/python-icons-a1.png
> ZIP: http://hcs.harvard.edu/~jrus/python/python-icons-a1.zip
>
> The zip file contains icns files, png files, and also folders with the
> icons applied.
>
> I'm glad to provide Photoshop files as well, if someone wants them.

I like these icons, although I'm not sure about the DATA label on  
the .pyc
icon.

Thank you for working on this,

Ronald

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup