From greg.ewing at canterbury.ac.nz Tue Feb 2 03:11:57 2010 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Tue, 02 Feb 2010 15:11:57 +1300 Subject: [Pygui] Native wrappers? In-Reply-To: <9B8A1B28-86C6-4109-9B04-1CADA526458A@gmail.com> References: <00656ABA-4C96-4677-8F9C-BC30BF0FED6F@gmail.com> <4B22BE49.3060703@canterbury.ac.nz> <23DC8E6C-356C-409E-8139-5B84BE197674@gmail.com> <4B230596.80907@canterbury.ac.nz> <08E898C4-F22B-4659-9616-D0C37882EC71@gmail.com> <4B26BEE7.5020703@canterbury.ac.nz> <4B2809B9.5000403@canterbury.ac.nz> <4B2D942F.103@canterbury.ac.nz> <397377D4-FCD6-49D1-BCEE-F1FD0229F7D5@gmail.com> <4B2EB98F.6060509@canterbury.ac.nz> <9B8A1B28-86C6-4109-9B04-1CADA526458A@gmail.com> Message-ID: <4B6789ED.5040308@canterbury.ac.nz> Dan Villiom Podlaski Christiansen wrote: > I understand that Pyrex would probably ease the implementation. > However, it seems to me that using it would run counter to the stated > goals of the project, unless Pyrex itself was to be included into the > Python core library. No, if the generated C sources are included with the distribution, then Pyrex would only be needed for developing PyGui, not using it. And of course precompiled binaries would be made available for each platform. -- Greg From greg.ewing at canterbury.ac.nz Sat Feb 6 09:08:09 2010 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Sat, 06 Feb 2010 21:08:09 +1300 Subject: [Pygui] ANN: PyGUI 2.2 Message-ID: <4B6D2369.4080508@canterbury.ac.nz> PyGUI 2.2 is available: http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ Highlights of this version: - TextEditor component with tabs, scrolling and word wrap - Classes for laying out components in rows, colums and grids - Printing support What is PyGUI? -------------- PyGUI is a cross-platform GUI toolkit designed to be lightweight and have a highly Pythonic API. -- Gregory Ewing greg.ewing at canterbury.ac.nz http://www.cosc.canterbury.ac.nz/greg.ewing/ From amcnabb at mcnabbs.org Mon Feb 8 21:44:54 2010 From: amcnabb at mcnabbs.org (Andrew McNabb) Date: Mon, 8 Feb 2010 13:44:54 -0700 Subject: [Pygui] Python 3 Plans Message-ID: <20100208204454.GH9251@mcnabbs.org> Hi. I was just curious whether there are any current plans for Python 3 support in PyGUI. Also, I didn't notice anything on the PyGUI page about how to make contributions to the code. Is there a version control system in place or a bug tracker for submitting patches to? I don't have a huge amount of time at the moment, but it's nice to know where I would go if I had a bug fix or feature or something. Thanks. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 From greg.ewing at canterbury.ac.nz Tue Feb 9 05:59:43 2010 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Tue, 09 Feb 2010 17:59:43 +1300 Subject: [Pygui] Python 3 Plans In-Reply-To: <20100208204454.GH9251@mcnabbs.org> References: <20100208204454.GH9251@mcnabbs.org> Message-ID: <4B70EBBF.3050808@canterbury.ac.nz> Andrew McNabb wrote: > Hi. I was just curious whether there are any current plans for Python 3 > support in PyGUI. None whatsoever as yet. I'm waiting until the dust settles on Python 3 before even thinking about it. > Also, I didn't notice anything on the PyGUI page about how to make > contributions to the code. Is there a version control system in place > or a bug tracker for submitting patches to? No, there isn't, sorry. But you're welcome to send me code and I'll consider merging it in. -- Greg From jared at jaredforsyth.com Tue Feb 9 06:40:13 2010 From: jared at jaredforsyth.com (Jared Forsyth) Date: Mon, 8 Feb 2010 22:40:13 -0700 Subject: [Pygui] Gtk/GL.py syntax error In-Reply-To: <9a5375241002082134n255d4fa4l368f0a5b3d93aa2a@mail.gmail.com> References: <9a5375241002082134n255d4fa4l368f0a5b3d93aa2a@mail.gmail.com> Message-ID: <9a5375241002082140k223a2923q49287e55af608a6@mail.gmail.com> There's an error in the GL.py that prevents it from importing -- it tries to use "as" as a variable name... here's a patch p.s. it would be great to have something like git to work with -- I know github is great for projects like this. Jared -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GL.py.patch Type: text/x-patch Size: 264 bytes Desc: not available URL: From vernondcole at gmail.com Tue Feb 9 16:08:11 2010 From: vernondcole at gmail.com (Vernon Cole) Date: Tue, 9 Feb 2010 08:08:11 -0700 Subject: [Pygui] Python 3 Plans In-Reply-To: <4B70EBBF.3050808@canterbury.ac.nz> References: <20100208204454.GH9251@mcnabbs.org> <4B70EBBF.3050808@canterbury.ac.nz> Message-ID: Dear Greg: On Mon, Feb 8, 2010 at 9:59 PM, Greg Ewing wrote: > Andrew McNabb wrote: > >> Hi. I was just curious whether there are any current plans for Python 3 >> support in PyGUI. >> > > None whatsoever as yet. I'm waiting until the dust settles > on Python 3 before even thinking about it. > Pardon me, but, Python 3 is fully mature. The reason why "nobody" is using it is because package authors are not supporting it. I have made the decision to drop wxPython. Part of the reason I made that decision is because Robin Dunn has no plans for a Python 3 version (or so he said when I asked the same question there as Andrew just asked here.) I am actively moving everything I can over to Python 3, and am depending on you to have a graphics package ready for me. Pywin32 is done. Yes, it took some effort, but it was do-able, and the build system now handles all the differences for new releases. Don't let me down here. I do not want to be stuck with TK. > > Also, I didn't notice anything on the PyGUI page about how to make >> contributions to the code. Is there a version control system in place >> or a bug tracker for submitting patches to? >> > > No, there isn't, sorry. But you're welcome to send me code > and I'll consider merging it in. > In order for PyGui to be a practical choice for long term production work, it needs to live on a server where the code can continue to be developed by others -- just in case you get run over by a truck. The reason that I am the administrator for adodbapi is because the original author disappeared without a trace. After many months of non-contact, sourceforge gave me access to continue the work. I picked up the outstanding patches and applied them. The rest is history. I recommend sourceforge very highly. You can maintain as much autonomy as you feel you need, and gradually share responsibility when you are ready. I have also tried google code and launchpad, there are no flies on them, but I still like sourceforge better. > -- > Greg By the way... I have been thinking about making an IronPython version of PyGUI -- after I get done with a better (i.e. genuine ADO.NET) IronPython version of adodbapi. IPy 2.6 is about halfway to Python 3 (there is no difference between str and unicode.) You could get more help with stuff like this if you were to move to a DVCS. -- Vernon -------------- next part -------------- An HTML attachment was scrubbed... URL: From amcnabb at mcnabbs.org Tue Feb 9 19:02:40 2010 From: amcnabb at mcnabbs.org (Andrew McNabb) Date: Tue, 9 Feb 2010 11:02:40 -0700 Subject: [Pygui] Python 3 Plans In-Reply-To: References: <20100208204454.GH9251@mcnabbs.org> <4B70EBBF.3050808@canterbury.ac.nz> Message-ID: <20100209180240.GA11413@mcnabbs.org> On Tue, Feb 09, 2010 at 08:08:11AM -0700, Vernon Cole wrote: > > Pardon me, but, Python 3 is fully mature. The reason why "nobody" is using > it is because package authors are not supporting it. I agree with this sentiment, and it would be great to see more packages moving over to Python 3. It looks like PyGTK still needs to be ported to Python 3, but they have already made some progress on this. Here's a bug report about it: https://bugzilla.gnome.org/show_bug.cgi?id=566641 > I recommend sourceforge very highly. You can maintain as much autonomy as > you feel you need, and gradually share responsibility when you are ready. I > have also tried google code and launchpad, there are no flies on them, but I > still like sourceforge better. I'm not sure if it matters where it's hosted, but I would definitely be more inclined to contribute an occasional patch if PyGUI were in Git or Mercurial or something. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 From danchr at gmail.com Tue Feb 9 20:49:14 2010 From: danchr at gmail.com (Dan Villiom Podlaski Christiansen) Date: Tue, 9 Feb 2010 20:49:14 +0100 Subject: [Pygui] Python 3 Plans In-Reply-To: References: <20100208204454.GH9251@mcnabbs.org> <4B70EBBF.3050808@canterbury.ac.nz> Message-ID: <705DEE0E-C9C2-438A-8E99-C366529283CA@gmail.com> On 9 Feb 2010, at 16:08, Vernon Cole wrote: > Pardon me, but, Python 3 is fully mature. The reason why "nobody" is using it is because package authors are not supporting it. I couldn't agree more; I'd love to use Python 3.1, but very little software I use runs on it :-/ > I recommend sourceforge very highly. You can maintain as much autonomy as you feel you need, and gradually share responsibility when you are ready. I have also tried google code and launchpad, there are no flies on them, but I still like sourceforge better. I imported all the releases of PyGUI I could find into a Mercurial repository, and uploaded it to Bitbucket.[1] It also includes the fix to make PyGUI run on Mac OS X 10.6, as 2.2 _still_ doesn't work there. With regard to hosting, I'd personally prefer either them or Google Code, as I've always found the Sourceforge user experience quite annoying. > By the way... I have been thinking about making an IronPython version of PyGUI -- after I get done with a better (i.e. genuine ADO.NET) IronPython version of adodbapi. IPy 2.6 is about halfway to Python 3 (there is no difference between str and unicode.) You could get more help with stuff like this if you were to move to a DVCS. My Mercurial repository contains an experimental, incomplete native Cocoa backend. I abandoned it partially because of the lack of collaboration? [1] -- Dan Villiom Podlaski Christiansen danchr at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1943 bytes Desc: not available URL: From greg.ewing at canterbury.ac.nz Wed Feb 10 00:29:26 2010 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Wed, 10 Feb 2010 12:29:26 +1300 Subject: [Pygui] Python 3 Plans In-Reply-To: <20100209180240.GA11413@mcnabbs.org> References: <20100208204454.GH9251@mcnabbs.org> <4B70EBBF.3050808@canterbury.ac.nz> <20100209180240.GA11413@mcnabbs.org> Message-ID: <4B71EFD6.9060309@canterbury.ac.nz> Andrew McNabb wrote: > I agree with this sentiment, and it would be great to see more packages > moving over to Python 3. I'll certainly tackle it at some point, I just can't say when I'll be able to find simultaneous time and enthusiasm for it. I'm not using Python 3 myself yet, so it's not one of my itches. > I'm not sure if it matters where it's hosted, but I would definitely be > more inclined to contribute an occasional patch if PyGUI were in Git or > Mercurial or something. The problem is that I really don't enjoy working with any of the current generation of VCSes. They're incompatible with the way I like to work. I've tried it with Pyrex, and I find it adds a level of stress that I could do without. That tends to discourage me from using a VCS for any further projects. I'm not saying it won't happen, just that for me it's not entirely the no-brainer that it probably appears to be to most other people. -- Greg From greg.ewing at canterbury.ac.nz Wed Feb 10 00:38:36 2010 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Wed, 10 Feb 2010 12:38:36 +1300 Subject: [Pygui] Python 3 Plans In-Reply-To: <705DEE0E-C9C2-438A-8E99-C366529283CA@gmail.com> References: <20100208204454.GH9251@mcnabbs.org> <4B70EBBF.3050808@canterbury.ac.nz> <705DEE0E-C9C2-438A-8E99-C366529283CA@gmail.com> Message-ID: <4B71F1FC.3080501@canterbury.ac.nz> Dan Villiom Podlaski Christiansen wrote: > It also includes the fix to > make PyGUI run on Mac OS X 10.6, as 2.2 _still_ doesn't work > there. I don't remember seeing a patch for that. If you send it to me I'll try to put it in. Thanks, Greg From amcnabb at mcnabbs.org Wed Feb 10 00:56:35 2010 From: amcnabb at mcnabbs.org (Andrew McNabb) Date: Tue, 9 Feb 2010 16:56:35 -0700 Subject: [Pygui] Python 3 Plans In-Reply-To: <4B71EFD6.9060309@canterbury.ac.nz> References: <20100208204454.GH9251@mcnabbs.org> <4B70EBBF.3050808@canterbury.ac.nz> <20100209180240.GA11413@mcnabbs.org> <4B71EFD6.9060309@canterbury.ac.nz> Message-ID: <20100209235635.GB12038@mcnabbs.org> On Wed, Feb 10, 2010 at 12:29:26PM +1300, Greg Ewing wrote: > > The problem is that I really don't enjoy working with any > of the current generation of VCSes. They're incompatible > with the way I like to work. I've tried it with Pyrex, and > I find it adds a level of stress that I could do without. I'm fascinated because this is a rare opinion. Most people I've talked to are initially frustrated by version control but quickly get used to it. I haven't run into too many people who don't get used to it. Just out of curiosity, is there any one thing in particular that caused the majority of the stress? If you don't like Mercurial, have you considered looking at Git? Also, systems like GitHub (for Git) and Bitbucket (for Mercurial) can make hosting easier. > That tends to discourage me from using a VCS for any further > projects. I'm not saying it won't happen, just that for me > it's not entirely the no-brainer that it probably appears to > be to most other people. Part of the reason that DVCS seems like a no-brainer is that it makes it tons easier to collaborate, both from the standpoint of the contributor and the maintainer. At least in my experience. > I'll certainly tackle it at some point, I just can't say > when I'll be able to find simultaneous time and enthusiasm > for it. I'm not using Python 3 myself yet, so it's not one > of my itches. Version control would certainly make it easier for others to contribute scratches (if that makes any sort of grammatical sense). ;-) -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 From greg.ewing at canterbury.ac.nz Wed Feb 10 06:25:00 2010 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Wed, 10 Feb 2010 18:25:00 +1300 Subject: [Pygui] Python 3 Plans In-Reply-To: <20100209235635.GB12038@mcnabbs.org> References: <20100208204454.GH9251@mcnabbs.org> <4B70EBBF.3050808@canterbury.ac.nz> <20100209180240.GA11413@mcnabbs.org> <4B71EFD6.9060309@canterbury.ac.nz> <20100209235635.GB12038@mcnabbs.org> Message-ID: <4B72432C.5030207@canterbury.ac.nz> Andrew McNabb wrote: > Just > out of curiosity, is there any one thing in particular that caused the > majority of the stress? I do most of my personal software development on a Mac. I like to use the Finder for moving and renaming files, but when using a VCS you can't do that. You can't even use the standard shell commands, either -- you have to use the VCS's special commands at all times, and if your forget and slip up, you end up with a mess to be repaired. Another problem is that none of the VCSes I know of are aware of the metadata that MacOS associates with files (resource forks, file types, etc.) I use BBEdit Lite, which makes use of this metadata, and I don't want to lose it. > If you don't like Mercurial, have you > considered looking at Git? Also, systems like GitHub (for Git) and > Bitbucket (for Mercurial) can make hosting easier. I do actually quite like Mercurial, as VCSes go. The problems aren't really in the VCS itself, but the fact that it doesn't integrate well with normal ways of handling files, and with the Mac file system in particular. If you know of a VCS that respects Mac metadata, I'd be interested to hear about it. > Part of the reason that DVCS seems like a no-brainer is that it makes it > tons easier to collaborate, both from the standpoint of the contributor > and the maintainer. At least in my experience. Yes, I know, and that makes me feel a bit bad about dragging my heels on the issue. But if I don't fully enjoy working on the project myself, I'll be less likely to do so. -- Greg From list at qtrac.plus.com Wed Feb 10 09:53:12 2010 From: list at qtrac.plus.com (Mark Summerfield) Date: Wed, 10 Feb 2010 08:53:12 +0000 Subject: [Pygui] Python 3 Plans In-Reply-To: <4B71EFD6.9060309@canterbury.ac.nz> References: <20100208204454.GH9251@mcnabbs.org> <20100209180240.GA11413@mcnabbs.org> <4B71EFD6.9060309@canterbury.ac.nz> Message-ID: <201002100853.12091.list@qtrac.plus.com> On 2010-02-09, Greg Ewing wrote: > Andrew McNabb wrote: > > I agree with this sentiment, and it would be great to see more packages > > moving over to Python 3. > > I'll certainly tackle it at some point, I just can't say > when I'll be able to find simultaneous time and enthusiasm > for it. I'm not using Python 3 myself yet, so it's not one > of my itches. I think that's a shame. Also, it kind of contradicts your aim of having PyGUI in Python's standard library. Python 2.7 is likely to be the last 2.x version and I can't see PyGUI going into that. So the only realistic possibility for PyGUI to be in the standard library is to go into a 3.x version. -- Mark Summerfield, Qtrac Ltd, www.qtrac.eu C++, Python, Qt, PyQt - training and consultancy "Rapid GUI Programming with Python and Qt" - ISBN 0132354187 From amcnabb at mcnabbs.org Wed Feb 10 18:50:45 2010 From: amcnabb at mcnabbs.org (Andrew McNabb) Date: Wed, 10 Feb 2010 10:50:45 -0700 Subject: [Pygui] Python 3 Plans In-Reply-To: <4B72432C.5030207@canterbury.ac.nz> References: <20100208204454.GH9251@mcnabbs.org> <4B70EBBF.3050808@canterbury.ac.nz> <20100209180240.GA11413@mcnabbs.org> <4B71EFD6.9060309@canterbury.ac.nz> <20100209235635.GB12038@mcnabbs.org> <4B72432C.5030207@canterbury.ac.nz> Message-ID: <20100210175045.GA12801@mcnabbs.org> On Wed, Feb 10, 2010 at 06:25:00PM +1300, Greg Ewing wrote: > > I do most of my personal software development on a Mac. I > like to use the Finder for moving and renaming files, but > when using a VCS you can't do that. You can't even use the > standard shell commands, either -- you have to use the > VCS's special commands at all times, and if your forget > and slip up, you end up with a mess to be repaired. That's a very valid complaint. I think in a few years, we'll start seeing more integration with the Finder (with contextual menus, etc.), but this definitely is a current weakness. > Another problem is that none of the VCSes I know of are > aware of the metadata that MacOS associates with files > (resource forks, file types, etc.) I use BBEdit Lite, which > makes use of this metadata, and I don't want to lose it. Are you still using Mac OS 9? :) I didn't know that you could still have resource forks in OS X. As far as file types go, I've never seen OS X use anything other than the file extension. The only metadata I've seen in OS X is the .DS_Store, which has things like icon positioning, etc.--things which don't seem particularly important for a code project. With OS X, I'm quite surprised that metadata would be a problem. > Yes, I know, and that makes me feel a bit bad about > dragging my heels on the issue. But if I don't fully > enjoy working on the project myself, I'll be less > likely to do so. Is there any chance that you might enjoy working on PyGUI even if version control were involved? I've been hopeful that PyGUI would prove to be the future of GUIs in Python. For this to happen, the project has to hit a certain level of maturity, which would certainly require having more than one developer involved. I'm just having a hard time imagining this future without seeing version control in the picture. I certainly wouldn't want to talk you into using version control if the change would kill off PyGUI, but I'm also wary of spending too much time with PyGUI if I have worries about the scalability of the project. I really am excited about PyGUI--it seems cleaner and more Pythonic than any other GUI system I've worked with. Thanks, and sorry for putting on so much pressure. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 From manders2k.dev at gmail.com Wed Feb 10 19:45:25 2010 From: manders2k.dev at gmail.com (Matt Anderson) Date: Wed, 10 Feb 2010 12:45:25 -0600 Subject: [Pygui] Python 3 Plans In-Reply-To: <20100210175045.GA12801@mcnabbs.org> References: <20100208204454.GH9251@mcnabbs.org> <4B70EBBF.3050808@canterbury.ac.nz> <20100209180240.GA11413@mcnabbs.org> <4B71EFD6.9060309@canterbury.ac.nz> <20100209235635.GB12038@mcnabbs.org> <4B72432C.5030207@canterbury.ac.nz> <20100210175045.GA12801@mcnabbs.org> Message-ID: <9C2DCCDD-9785-495D-B136-D2E5483D7FC7@gmail.com> On Feb 10, 2010, at 11:50 AM, Andrew McNabb wrote: > Are you still using Mac OS 9? :) I didn't know that you could still > have resource forks in OS X. As far as file types go, I've never seen > OS X use anything other than the file extension. The only metadata I've > seen in OS X is the .DS_Store, which has things like icon positioning, > etc.--things which don't seem particularly important for a code project. > With OS X, I'm quite surprised that metadata would be a problem. Actually, since 10.4 HFS+ has supported arbitrary extended attributes (sometimes called 'named forks'), which have become increasingly used for attaching various data to files. TextMate, for example, saves information about editing state as extended attributes[1] (caret position, bookmarks, text folding). They're used by Apple for the "quarantine" subsystem, finder/spotlight comments, etc. Snow Leopard does all sorts of other weird things with extended attributes too[2]. Also, third party software has started to make use of them for associating arbitrary text "tags" with files which are findable with spotlight[3]. I was just starting to use extended attributes more extensively (for tagging) when I began using Mercurial, and I found it extremely frustrating that they didn't get saved in the repository, and I couldn't find a work around to save them. There's probably a way to access them as an "apple double" file and check that into the repository, but my few hours of research didn't turn up how. Eventually, I just gave up on using them because it was too much bother (and continued using mercurial, which I love). So to me, lack of metadata support is a legitimate problem. My solution (for now) has been to ignore the problem, but I can definitely see where that might be undesirable or unacceptable to some. In any event, I'll chime in and say I would LOVE to see progress on pygui accelerate, and a larger community of folks get involved. I personally don't care so much about the cross-platform aspect of pygui -- I've given myself over to the Mac for the most part (though occasionally I'll use some other unix in a server capacity). But I hate programming in Cocoa/PyObjC. I can hobble along, but I would much prefer to write my entire Mac-only programs in "pythonic" python (sans Cocoa API) and still have a native GUI. Though, having them be mostly cross-platform with no additional effort would be a definite plus. If there was an source repository and a clear way of being a contributor for the project, chances are high I would get involved and contribute. [1] http://manual.macromates.com/en/saving_files.html#extended_attributes_metadata [2] http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/3#footprint [3] http://code.google.com/p/openmeta/ -- Matt Anderson -------------- next part -------------- An HTML attachment was scrubbed... URL: From amcnabb at mcnabbs.org Wed Feb 10 20:18:06 2010 From: amcnabb at mcnabbs.org (Andrew McNabb) Date: Wed, 10 Feb 2010 12:18:06 -0700 Subject: [Pygui] Python 3 Plans In-Reply-To: <9C2DCCDD-9785-495D-B136-D2E5483D7FC7@gmail.com> References: <20100208204454.GH9251@mcnabbs.org> <4B70EBBF.3050808@canterbury.ac.nz> <20100209180240.GA11413@mcnabbs.org> <4B71EFD6.9060309@canterbury.ac.nz> <20100209235635.GB12038@mcnabbs.org> <4B72432C.5030207@canterbury.ac.nz> <20100210175045.GA12801@mcnabbs.org> <9C2DCCDD-9785-495D-B136-D2E5483D7FC7@gmail.com> Message-ID: <20100210191806.GB13697@mcnabbs.org> On Wed, Feb 10, 2010 at 12:45:25PM -0600, Matt Anderson wrote: > > Actually, since 10.4 HFS+ has supported arbitrary extended attributes (sometimes called 'named forks'), which have become increasingly used for attaching various data to files. TextMate, for example, saves information about editing state as extended attributes[1] (caret position, bookmarks, text folding). They're used by Apple for the "quarantine" subsystem, finder/spotlight comments, etc. Snow Leopard does all sorts of other weird things with extended attributes too[2]. Also, third party software has started to make use of them for associating arbitrary text "tags" with files which are findable with spotlight[3]. Ouch. I thought that Apple learned in the late '90s that the resource fork thing was a design mistake. When they abandoned resource forks with Mac OS X, the Macintosh became a much more Internet-capable operating system. Apparently they unlearned that lesson, and we now have at least two people reporting that this makes it harder to collaborate with others. This regression is disappointing. Anyway, thanks for the information. > In any event, I'll chime in and say I would LOVE to see progress on pygui accelerate, and a larger community of folks get involved. I personally don't care so much about the cross-platform aspect of pygui -- I've given myself over to the Mac for the most part (though occasionally I'll use some other unix in a server capacity). But I hate programming in Cocoa/PyObjC. I can hobble along, but I would much prefer to write my entire Mac-only programs in "pythonic" python (sans Cocoa API) and still have a native GUI. Though, having them be mostly cross-platform with no additional effort would be a definite plus. There hasn't been any suggestion to remove cross-platform support from PyGUI, has there? This would surprise me. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 From manders2k.dev at gmail.com Wed Feb 10 20:32:30 2010 From: manders2k.dev at gmail.com (Matt Anderson) Date: Wed, 10 Feb 2010 13:32:30 -0600 Subject: [Pygui] Python 3 Plans In-Reply-To: <20100210191806.GB13697@mcnabbs.org> References: <20100208204454.GH9251@mcnabbs.org> <4B70EBBF.3050808@canterbury.ac.nz> <20100209180240.GA11413@mcnabbs.org> <4B71EFD6.9060309@canterbury.ac.nz> <20100209235635.GB12038@mcnabbs.org> <4B72432C.5030207@canterbury.ac.nz> <20100210175045.GA12801@mcnabbs.org> <9C2DCCDD-9785-495D-B136-D2E5483D7FC7@gmail.com> <20100210191806.GB13697@mcnabbs.org> Message-ID: <71DFE857-8039-4F4D-863D-64091474CA45@gmail.com> On Feb 10, 2010, at 1:18 PM, Andrew McNabb wrote: > Ouch. I thought that Apple learned in the late '90s that the resource > fork thing was a design mistake. When they abandoned resource forks > with Mac OS X, the Macintosh became a much more Internet-capable > operating system. Apparently they unlearned that lesson, and we now > have at least two people reporting that this makes it harder to > collaborate with others. This regression is disappointing. Anyway, > thanks for the information. Actually, Linux, FreeBSD and others support extended attributes also[1]. Not doing lots with linux or freebsd recently, I'm not sure how widely they're used though. I don't think that having xattrs is inherently a problem, in fact they're very convenient and powerful. It's just unfortunate they aren't standardized across the various OSes. The details are frequently filesystem-dependent. The OS X extended attribute API might be API-compatible with FreeBSD; not sure. > There hasn't been any suggestion to remove cross-platform support from > PyGUI, has there? This would surprise me. No, no. I'm sure the opposite. I was just stating my personal perspective/motivation. [1] http://en.wikipedia.org/wiki/Extended_file_attributes -- Matt Anderson > On Wed, Feb 10, 2010 at 12:45:25PM -0600, Matt Anderson wrote: >> >> Actually, since 10.4 HFS+ has supported arbitrary extended attributes (sometimes called 'named forks'), which have become increasingly used for attaching various data to files. TextMate, for example, saves information about editing state as extended attributes[1] (caret position, bookmarks, text folding). They're used by Apple for the "quarantine" subsystem, finder/spotlight comments, etc. Snow Leopard does all sorts of other weird things with extended attributes too[2]. Also, third party software has started to make use of them for associating arbitrary text "tags" with files which are findable with spotlight[3]. > > Ouch. I thought that Apple learned in the late '90s that the resource > fork thing was a design mistake. When they abandoned resource forks > with Mac OS X, the Macintosh became a much more Internet-capable > operating system. Apparently they unlearned that lesson, and we now > have at least two people reporting that this makes it harder to > collaborate with others. This regression is disappointing. Anyway, > thanks for the information. > > >> In any event, I'll chime in and say I would LOVE to see progress on pygui accelerate, and a larger community of folks get involved. I personally don't care so much about the cross-platform aspect of pygui -- I've given myself over to the Mac for the most part (though occasionally I'll use some other unix in a server capacity). But I hate programming in Cocoa/PyObjC. I can hobble along, but I would much prefer to write my entire Mac-only programs in "pythonic" python (sans Cocoa API) and still have a native GUI. Though, having them be mostly cross-platform with no additional effort would be a definite plus. > > > -- > Andrew McNabb > http://www.mcnabbs.org/andrew/ > PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 > _______________________________________________ > Pygui mailing list > Pygui at python.org > http://mail.python.org/mailman/listinfo/pygui -------------- next part -------------- An HTML attachment was scrubbed... URL: From amcnabb at mcnabbs.org Wed Feb 10 23:03:34 2010 From: amcnabb at mcnabbs.org (Andrew McNabb) Date: Wed, 10 Feb 2010 15:03:34 -0700 Subject: [Pygui] Python 3 Plans In-Reply-To: <71DFE857-8039-4F4D-863D-64091474CA45@gmail.com> References: <4B70EBBF.3050808@canterbury.ac.nz> <20100209180240.GA11413@mcnabbs.org> <4B71EFD6.9060309@canterbury.ac.nz> <20100209235635.GB12038@mcnabbs.org> <4B72432C.5030207@canterbury.ac.nz> <20100210175045.GA12801@mcnabbs.org> <9C2DCCDD-9785-495D-B136-D2E5483D7FC7@gmail.com> <20100210191806.GB13697@mcnabbs.org> <71DFE857-8039-4F4D-863D-64091474CA45@gmail.com> Message-ID: <20100210220334.GC14447@mcnabbs.org> On Wed, Feb 10, 2010 at 01:32:30PM -0600, Matt Anderson wrote: > > Actually, Linux, FreeBSD and others support extended attributes also[1]. Not doing lots with linux or freebsd recently, I'm not sure how widely they're used though. I don't think that having xattrs is inherently a problem, in fact they're very convenient and powerful. It's just unfortunate they aren't standardized across the various OSes. The details are frequently filesystem-dependent. Yeah. Extended attributes vary with different operating systems and filesystems. Additionally, since the metadata is not part of the normal stream of data, support would have to be individually added to every program and network protocol dealing with data. This simply isn't practical. I'm convinced that for most purposes, extended attributes are the wrong solution. Anyway, I guess I'm getting off-topic. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 From greg.ewing at canterbury.ac.nz Thu Feb 11 00:58:05 2010 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 11 Feb 2010 12:58:05 +1300 Subject: [Pygui] Python 3 Plans In-Reply-To: <201002100853.12091.list@qtrac.plus.com> References: <20100208204454.GH9251@mcnabbs.org> <20100209180240.GA11413@mcnabbs.org> <4B71EFD6.9060309@canterbury.ac.nz> <201002100853.12091.list@qtrac.plus.com> Message-ID: <4B73480D.2080709@canterbury.ac.nz> Mark Summerfield wrote: > I think that's a shame. Also, it kind of contradicts your aim of having > PyGUI in Python's standard library. That's a *very* long term plan, or maybe "wish" would be a better term. I'm not expecting it to happen any time soon. If it does, by that time a Python 3 version will almost certainly exist. -- Greg From greg.ewing at canterbury.ac.nz Thu Feb 11 06:43:46 2010 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 11 Feb 2010 18:43:46 +1300 Subject: [Pygui] Python 3 Plans In-Reply-To: <20100210175045.GA12801@mcnabbs.org> References: <20100208204454.GH9251@mcnabbs.org> <4B70EBBF.3050808@canterbury.ac.nz> <20100209180240.GA11413@mcnabbs.org> <4B71EFD6.9060309@canterbury.ac.nz> <20100209235635.GB12038@mcnabbs.org> <4B72432C.5030207@canterbury.ac.nz> <20100210175045.GA12801@mcnabbs.org> Message-ID: <4B739912.70801@canterbury.ac.nz> Andrew McNabb wrote: > That's a very valid complaint. I think in a few years, we'll start > seeing more integration with the Finder (with contextual menus, etc.) To my way of thinking, the VCS should be implemented as a virtual file system. Then you could access the files any way you wanted and it would always do the right thing. > Are you still using Mac OS 9? :) I didn't know that you could still > have resource forks in OS X. Yes, MacOSX still has them, although Apple seems to be discouraging their use in new apps. I'm using BBEdit Lite, which started its life in the classic era, and it uses the resource fork to store info about tab settings, line endings, etc. > As far as file types go, I've never seen > OS X use anything other than the file extension. Apps ported over from the previous era still do, but you're right, this is another thing that that Apple seems to be trying to kill. It's a great pity, because the old way was vastly superior in several respects. I'm quite disappointed by the way Apple is letting OSX get dragged down to the lowest common denominator for the sake of compatibility with inferior systems. > The only metadata I've > seen in OS X is the .DS_Store, which has things like icon positioning, > etc.--things which don't seem particularly important for a code project. I don't care about icon positioning much any more. I used to take pleasure in arranging my file icons in useful ways, but OSX ruined the whole experience by having the Finder insist on spacing them about 5 miles apart horizontally when using the snapping grid. So I've given up on icons and I use the column view almost exclusively now. > I certainly wouldn't want to talk you into using version control if the > change would kill off PyGUI Oh, don't worry, I wouldn't find it *that* bad by a long shot. And I fully understand that a VCS is going to be a prerequisite to getting it into Python. But I don't feel that it's anywhere near that level of maturity yet. It's still very early days. -- Greg From greg.ewing at canterbury.ac.nz Thu Feb 11 07:03:11 2010 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 11 Feb 2010 19:03:11 +1300 Subject: [Pygui] Python 3 Plans In-Reply-To: <9C2DCCDD-9785-495D-B136-D2E5483D7FC7@gmail.com> References: <20100208204454.GH9251@mcnabbs.org> <4B70EBBF.3050808@canterbury.ac.nz> <20100209180240.GA11413@mcnabbs.org> <4B71EFD6.9060309@canterbury.ac.nz> <20100209235635.GB12038@mcnabbs.org> <4B72432C.5030207@canterbury.ac.nz> <20100210175045.GA12801@mcnabbs.org> <9C2DCCDD-9785-495D-B136-D2E5483D7FC7@gmail.com> Message-ID: <4B739D9F.2060508@canterbury.ac.nz> Matt Anderson wrote: > I was just starting to use extended attributes more extensively (for > tagging) when I began using Mercurial, and I found it extremely > frustrating that they didn't get saved in the repository... There's > probably a way to access them I don't know about the extended attributes, but the resource fork and finder info can be accessed by appending "/rsrc" and "/info" to the file pathname, so it probably wouldn't be too hard to enhance Mercurial to deal with them. The problem is that the Mercurial maintainers appear to be philosophically opposed to giving Mercurial any platform-specific functionality of any kind, so the chances of getting any such enhancement into the standard version of hg seem to be very slim. (This despite the stated aim that Mercurial should be usable for "any kind of data", not just text files. This is currently not true on MacOSX, nor can it be given the abovementioned philosophical position.) -- Greg From greg.ewing at canterbury.ac.nz Thu Feb 11 07:42:29 2010 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 11 Feb 2010 19:42:29 +1300 Subject: [Pygui] Python 3 Plans In-Reply-To: <20100210220334.GC14447@mcnabbs.org> References: <4B70EBBF.3050808@canterbury.ac.nz> <20100209180240.GA11413@mcnabbs.org> <4B71EFD6.9060309@canterbury.ac.nz> <20100209235635.GB12038@mcnabbs.org> <4B72432C.5030207@canterbury.ac.nz> <20100210175045.GA12801@mcnabbs.org> <9C2DCCDD-9785-495D-B136-D2E5483D7FC7@gmail.com> <20100210191806.GB13697@mcnabbs.org> <71DFE857-8039-4F4D-863D-64091474CA45@gmail.com> <20100210220334.GC14447@mcnabbs.org> Message-ID: <4B73A6D5.4000402@canterbury.ac.nz> Andrew McNabb wrote: > Yeah. Extended attributes vary with different operating systems and > filesystems. If they're starting to appear in other systems, maybe we can hope for some convergence in the future, so that they can be dealt with in a cross-platform way. Then we might see VCSes, web services, etc. start to respect them. Experience with resource forks in the classic era has shown how tremendously handy it can be to have a way of attaching out-of-band data to a file in such a way that it can't get accidentally lost and that apps that don't know about it can just ignore it. -- Greg From amcnabb at mcnabbs.org Thu Feb 11 07:56:57 2010 From: amcnabb at mcnabbs.org (Andrew McNabb) Date: Wed, 10 Feb 2010 23:56:57 -0700 Subject: [Pygui] Python 3 Plans In-Reply-To: <4B73A6D5.4000402@canterbury.ac.nz> References: <20100209180240.GA11413@mcnabbs.org> <4B71EFD6.9060309@canterbury.ac.nz> <20100209235635.GB12038@mcnabbs.org> <4B72432C.5030207@canterbury.ac.nz> <20100210175045.GA12801@mcnabbs.org> <9C2DCCDD-9785-495D-B136-D2E5483D7FC7@gmail.com> <20100210191806.GB13697@mcnabbs.org> <71DFE857-8039-4F4D-863D-64091474CA45@gmail.com> <20100210220334.GC14447@mcnabbs.org> <4B73A6D5.4000402@canterbury.ac.nz> Message-ID: <20100211065657.GA17345@mcnabbs.org> On Thu, Feb 11, 2010 at 07:42:29PM +1300, Greg Ewing wrote: > > If they're starting to appear in other systems, maybe we can > hope for some convergence in the future, so that they can > be dealt with in a cross-platform way. Then we might see > VCSes, web services, etc. start to respect them. Web services can't start to respect them unless HTTP is changed to deal with multiple streams for each file. For true cross-platform support, every file-related protocol and application would have to be changed individually. Given how slowly it's taking to upgrade to IPv6, it's hard to imagine this happening anytime soon. :) > Experience with resource forks in the classic era has shown > how tremendously handy it can be to have a way of attaching > out-of-band data to a file in such a way that it can't get > accidentally lost and that apps that don't know about it can > just ignore it. My experience in the classic era was the same. The out-of-band data really were handy. As soon as I started to use networks, however, the out-of-band data became a nightmare. I nostalgiacally recall many hours spent dealing with files packed with BinHex and MacBinary and files that should have been but weren't. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 From amcnabb at mcnabbs.org Thu Feb 11 08:18:25 2010 From: amcnabb at mcnabbs.org (Andrew McNabb) Date: Thu, 11 Feb 2010 00:18:25 -0700 Subject: [Pygui] Python 3 Plans In-Reply-To: <4B739912.70801@canterbury.ac.nz> References: <20100208204454.GH9251@mcnabbs.org> <4B70EBBF.3050808@canterbury.ac.nz> <20100209180240.GA11413@mcnabbs.org> <4B71EFD6.9060309@canterbury.ac.nz> <20100209235635.GB12038@mcnabbs.org> <4B72432C.5030207@canterbury.ac.nz> <20100210175045.GA12801@mcnabbs.org> <4B739912.70801@canterbury.ac.nz> Message-ID: <20100211071825.GB17345@mcnabbs.org> On Thu, Feb 11, 2010 at 06:43:46PM +1300, Greg Ewing wrote: > > To my way of thinking, the VCS should be implemented as a > virtual file system. Then you could access the files any > way you wanted and it would always do the right thing. I know that there are people doing interesting work with versioned file systems. They really are quite interesting, but I think that code repositories are the best application for them. Since versioned file systems do everything automatically, it's very difficult to make sense of concepts like branching, merging and commit messages, which are critical for large projects. > Yes, MacOSX still has them, although Apple seems to be > discouraging their use in new apps. I'm using BBEdit Lite, > which started its life in the classic era, and it uses > the resource fork to store info about tab settings, line > endings, etc. I didn't know that BBEdit uses resource forks; that's very interesting. Does BBEdit work if it's used with a UFS filesystem? I'm pretty sure that UFS can't deal with resource forks. What does it do if a file is stored on a FAT filesystem? > Apps ported over from the previous era still do, but > you're right, this is another thing that that Apple seems > to be trying to kill. It's a great pity, because the old > way was vastly superior in several respects. I'm quite > disappointed by the way Apple is letting OSX get dragged > down to the lowest common denominator for the sake of > compatibility with inferior systems. Resource forks certainly have benefits on standalone machines, but I'd rather give up resource forks than network communication. :) > Oh, don't worry, I wouldn't find it *that* bad by a > long shot. And I fully understand that a VCS is going > to be a prerequisite to getting it into Python. But I > don't feel that it's anywhere near that level of > maturity yet. It's still very early days. I think you're just being modest. :) PyGUI is already at the point where I would much rather use it (and work around any problems I run into) than deal with Tkinter. I think its biggest weakness is the size of the community behind it. The only reason that I've made such a big deal about the VCS issue is that I think this is a small thing that could make a big difference. Anyway, I'll stop pestering you about it, but it would be really great to have a timeline or a plan. I've been thinking about getting PyGUI into Fedora, but having a VCS is definitely a prerequisite. Thanks for all of your hard work with PyGUI. It's a great project. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 From greg.ewing at canterbury.ac.nz Thu Feb 11 23:49:12 2010 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Fri, 12 Feb 2010 11:49:12 +1300 Subject: [Pygui] Python 3 Plans In-Reply-To: <20100211071825.GB17345@mcnabbs.org> References: <20100208204454.GH9251@mcnabbs.org> <4B70EBBF.3050808@canterbury.ac.nz> <20100209180240.GA11413@mcnabbs.org> <4B71EFD6.9060309@canterbury.ac.nz> <20100209235635.GB12038@mcnabbs.org> <4B72432C.5030207@canterbury.ac.nz> <20100210175045.GA12801@mcnabbs.org> <4B739912.70801@canterbury.ac.nz> <20100211071825.GB17345@mcnabbs.org> Message-ID: <4B748968.90508@canterbury.ac.nz> Andrew McNabb wrote: > Since versioned file > systems do everything automatically, it's very difficult to make sense > of concepts like branching, merging and commit messages, which are > critical for large projects. You wouldn't want your whole disk to just be one big versioned file system. What I have in mind would be more like mounting a disk image on MacOSX. Each repository would be a volume of its own, and there would be an interface for doing all the VCS type stuff like branching and merging. > I didn't know that BBEdit uses resource forks; that's very interesting. The version I'm using is rather old, so I'm not sure whether current versions still do. I ought to get hold of TextWrangler at some point and find out. > Does BBEdit work if it's used with a UFS filesystem? I'm pretty sure > that UFS can't deal with resource forks. What does it do if a file is > stored on a FAT filesystem? MacOSX has alternative ways of storing its metadata on non-HFS file systems, e.g. on UFS I think it creates ._filename files, and on FAT it uses a directory called something like __MACOSX. > Resource forks certainly have benefits on standalone machines, but I'd > rather give up resource forks than network communication. :) Same here, but it's disappointing to be forced to choose between the two. > I think its biggest weakness is the size > of the community behind it. The only reason that I've made such a big > deal about the VCS issue is that I think this is a small thing that > could make a big difference. You may be right. I'll give the matter some serious thought. -- Greg From gabriele.lanaro at gmail.com Tue Feb 23 22:32:18 2010 From: gabriele.lanaro at gmail.com (Gabriele Lanaro) Date: Tue, 23 Feb 2010 22:32:18 +0100 Subject: [Pygui] Some questions Message-ID: Hi, this is my first time here, I was curious about this library because of its portable nature. It seems very logic, stable and nice! My questions are: 1) Are there plans about implementing tree/list widgets? 2) Are there suggestions about deploying the software on windows (like simple, standalone installer)? 3) Are there suggestions about deploying the software on linux? (well, here I guess is sufficient setuptools) Thank you and bye! -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Wed Feb 24 23:45:09 2010 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 25 Feb 2010 11:45:09 +1300 Subject: [Pygui] Some questions In-Reply-To: References: Message-ID: <4B85ABF5.7040306@canterbury.ac.nz> Gabriele Lanaro wrote: > 1) Are there plans about implementing tree/list widgets? No definite plans yet, but something along those lines will probably happen at some point. > 2) Are there suggestions about deploying the software on windows (like > simple, standalone installer)? Just use py2exe or some other such tool. > 3) Are there suggestions about deploying the software on linux? (well, here > I guess is sufficient setuptools) Yes, using distutils or setuptools to build an rpm or whatever would seem to be the way to go. -- Greg