Rune Devik wrote:
You can ask the registry where the appdata folder is.
The proper way to get at this information is to use shell api functions.
E.g., assuming pywin32 is available:
from win32com.shell import shellcon, shell
print shell.SHGetFolderPath(0, shellcon.CSIDL_COMMON_APPDATA, 0, 0)
- Anders
Anders J. Munch wrote:
Rune Devik wrote:
You can ask the registry where the appdata folder is.
The proper way to get at this information is to use shell api functions.
E.g., assuming pywin32 is available:
from win32com.shell import shellcon, shell
print shell.SHGetFolderPath(0, shellcon.CSIDL_COMMON_APPDATA, 0, 0)
Thanks for posting this. I've wrapped it in Dabo, available using:
import dabo.lib.utils as utils
print utils.getUserAppDataDirectory()
(I used CSIDL_APPDATA instead of CSIDL_COMMON_APPDATA, though.)
Previously we were relying on environmental variables to be set which was probably kind of fragile, given how often Microsoft likes to change its conventions.
--
pkm ~ http://paulmcnett.com
Anders J. Munch wrote:
Rune Devik wrote:
You can ask the registry where the appdata folder is.
The proper way to get at this information is to use shell api functions.E.g., assuming pywin32 is available:
from win32com.shell import shellcon, shell
print shell.SHGetFolderPath(0, shellcon.CSIDL_COMMON_APPDATA, 0, 0)
I think wx.StandardPaths is a nicer method as it is not Win specific and I would think that under the hood it does something like the above on Windows.
Werner
Werner F. Bruhin wrote:
Anders J. Munch wrote:
Rune Devik wrote:
You can ask the registry where the appdata folder is.
The proper way to get at this information is to use shell api functions.
E.g., assuming pywin32 is available:
from win32com.shell import shellcon, shell
print shell.SHGetFolderPath(0, shellcon.CSIDL_COMMON_APPDATA, 0, 0)
I think wx.StandardPaths is a nicer method as it is not Win specific and I would think that under the hood it does something like the above on Windows.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Robin Dunn wrote:
Werner F. Bruhin wrote:
Anders J. Munch wrote:
Rune Devik wrote:
You can ask the registry where the appdata folder is.
The proper way to get at this information is to use shell api functions.
E.g., assuming pywin32 is available:
from win32com.shell import shellcon, shell
print shell.SHGetFolderPath(0, shellcon.CSIDL_COMMON_APPDATA, 0, 0)
I think wx.StandardPaths is a nicer method as it is not Win specific and I would think that under the hood it does something like the above on Windows.
wx.StandardPaths looks perfect. Now, how do I include it in my py2exe-generated exe that doesn't use wx without pulling all the wx stuff into the exe?
--
pkm ~ http://paulmcnett.com
Hi Paul,
Paul McNett wrote:
wx.StandardPaths looks perfect. Now, how do I include it in my py2exe-generated exe that doesn't use wx without pulling all the wx stuff into the exe?
You re-write your app into a wx app 
Werner
Werner F. Bruhin wrote:
Hi Paul,
Paul McNett wrote:
wx.StandardPaths looks perfect. Now, how do I include it in my py2exe-generated exe that doesn't use wx without pulling all the wx stuff into the exe?
You re-write your app into a wx app
I'm actually being kind of serious, here. I notice that when I do a py2exe of my wx application, I get pretty much the whole busload - xrc, aui, all the gizmos, extra controls that I never use, etc. etc.
I propose a SOC project for next year that aims to modularize the wx namespace so that tools like py2exe can actually pull only those names that are required by the given application.
Is it as easy changing my import conventions from "import wx" to "from wx import TextCtrl", or is it much more complicated than that?
I realize that this is a huge problem. The wx namespace alone contains 3409 names as of this writing, but if my app only uses 50 of those names, that's all I want to have end up in the exe (well, those 50 names will bring in their own set of dependencies of course). And the various dlls and pyd's that are not necessary shouldn't end up in the exe either. I tried manually excluding the xrc stuff but the executable wouldn't run when I did that.
And, back to the matter at hand: I'd really like to be able to use wx.StandardPaths in all my apps, not just the wx-based ones, but the dependency on wx is just too heavy.
I'm not complaining about wxPython, mind you. Just bringing up an area where it could be substantially improved over the next decade or so.
--
pkm ~ http://paulmcnett.com
It’s got to be that easy! If it isn’t, then that would be a very much needed change. That sounds like essential Python behavior.
On 5/31/07, Paul McNett p@ulmcnett.com wrote:
Is it as easy as changing my import conventions from “import wx” to “from
wx import TextCtrl”, or is it much more complicated than that?
Eric Ongerth wrote:
Is it as easy as changing my import conventions from "import wx" to
"from
wx import TextCtrl", or is it much more complicated than that?It's got to be that easy! If it isn't, then that would be a very much needed change. That sounds like essential Python behavior.
It's much more complicated than that. wxPython relies on the bindings, which depend on the dlls. Even with a non-monolithic build, there are a lot of cross-dependencies.
It SHOULD be possible to at least remove some of the "big things" like aui, xrc, grid, etc, but that's not trivial either. Also, almost everything relies on wxCore, which has lots of basic building blocks like wxString, etc. Last I looked, the "extra" stuff was kind of small compared to the core stuff anyway.
This has come up a lot, and no ones done it yet. I think that's because in truth, it's really just disk space and network bandwidth, which really are cheap compared to the work required to change the way it now.
For things like wxStandardPaths, maybe there should just be a pure python implementation -- ideally in the standard lib.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
Ok, that makes sense. I can live with that.
On 5/31/07, Christopher Barker Chris.Barker@noaa.gov wrote:
This has come up a lot, and no ones done it yet. I think that’s because
in truth, it’s really just disk space and network bandwidth, which
really are cheap compared to the work required to change the way it now.
Christopher Barker wrote:
Eric Ongerth wrote:
Is it as easy as changing my import conventions from "import wx" to
"from
wx import TextCtrl", or is it much more complicated than that?It's got to be that easy! If it isn't, then that would be a very much needed change. That sounds like essential Python behavior.
It's much more complicated than that. wxPython relies on the bindings, which depend on the dlls. Even with a non-monolithic build, there are a lot of cross-dependencies.
It SHOULD be possible to at least remove some of the "big things" like aui, xrc, grid, etc, but that's not trivial either. Also, almost everything relies on wxCore, which has lots of basic building blocks like wxString, etc. Last I looked, the "extra" stuff was kind of small compared to the core stuff anyway.
True.
This has come up a lot, and no ones done it yet. I think that's because in truth, it's really just disk space and network bandwidth, which really are cheap compared to the work required to change the way it now.
True, although I'm about to go into production on an application that will go out to potentially hundreds of end-users, with connections that are potentially unreliable and slow compared with what us techies are used to, with frequent and required application updates. The smallest I've been able to make my setup.exe is 9.5 MB.
I guess if it becomes a problem I can figure out how to distribute patches instead of full downloads of the setup.exe each time an update is required.
For things like wxStandardPaths, maybe there should just be a pure python implementation -- ideally in the standard lib.
...yes, and this was really what I was getting at in my initial reply - it doesn't rely on anything else in wx (well, it shouldn't anyway), so why do I need to bring in almost the entirety of wx to get access to it?
--
pkm ~ http://paulmcnett.com
When not using wxPython, I usually use Tim Golden's "winshell" module
found here: Tim Golden's Python Stuff: winshell. Now that I think
about it, I am probably still using it in some of my console-to-GUI ports.
I'll have to try that wx.StandardPaths method next.
Miek
-----Original Message-----
From: Anders J. Munch [mailto:ajm@flonidan.dk]
Sent: Thursday, May 31, 2007 8:43 AM
To: wxPython-users@lists.wxwidgets.org
Subject: Re: [wxPython-users] wxpython application vistaRune Devik wrote:
> You can ask the registry where the appdata folder is.The proper way to get at this information is to use shell api
functions.E.g., assuming pywin32 is available:
from win32com.shell import shellcon, shell print
shell.SHGetFolderPath(0, shellcon.CSIDL_COMMON_APPDATA, 0, 0)- Anders
Hi Paul,
Robin Dunn wrote:
> Werner F. Bruhin wrote:
>> Anders J. Munch wrote:
>>> Rune Devik wrote:
>>>
>>>> You can ask the registry where the appdata folder is.
>>>
>>> The proper way to get at this information is to use shell api functions.
>>>
>>> E.g., assuming pywin32 is available:
>>>
>>> from win32com.shell import shellcon, shell
>>> print shell.SHGetFolderPath(0, shellcon.CSIDL_COMMON_APPDATA, 0, 0)
>>>
>> I think wx.StandardPaths is a nicer method as it is not Win specific
>> and I would think that under the hood it does something like the above
>> on Windows.
>
> Yep. See
> http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/src/msw/stdpaths.cpp?rev=1.18&content-type=text/vnd.viewcvs-markupwx.StandardPaths looks perfect. Now, how do I include it in my
py2exe-generated exe that doesn't use wx without pulling all the wx
stuff into the exe?
I thought that Python had something that dealt with this issue... but
my search got me nowhere. I, like you, thought that it was a fairly
standard thing. Surprisingly enough, it's not that standard 
As far as I know, refactoring the wx workspace so that you can exclude
some part of it is maybe the most complex task after the automatic GUI
testing project. And, as others have already pointed out, the bulk of
wx lives in wxCore, which limits the advantages of splitting
Sorry if I don't have any useful suggestion, but I was a bit surprised
Python itself didn't provide something similar.
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.virgilio.it/infinity77/
On 5/31/07, Paul McNett wrote:
Christopher Barker wrote:
Eric Ongerth wrote:
Is it as easy as changing my import conventions from "import wx" to
"from
wx import TextCtrl", or is it much more complicated than that?It's got to be that easy! If it isn't, then that would be a very much needed change. That sounds like essential Python behavior.
It's much more complicated than that. wxPython relies on the bindings, which depend on the dlls. Even with a non-monolithic build, there are a lot of cross-dependencies.
It SHOULD be possible to at least remove some of the "big things" like aui, xrc, grid, etc, but that's not trivial either. Also, almost everything relies on wxCore, which has lots of basic building blocks like wxString, etc. Last I looked, the "extra" stuff was kind of small compared to the core stuff anyway.
That much should be possible already. The only extension modules imported by "import wx" are _core_, _gdi_, _windows_, _controls_, and _misc_. Last I checked those are the only modules that pyexe copies for simple wx apps. Paul, what errors did you get when you tried to eliminate XRC?
>>> import sys
>>> sys.modules.keys()
['cStringIO', 'copy_reg', '__main__', 'site', '__builtin__', 'encodings', 'posixpath', 'pprint', 'encodings.codecs', 'os.path', '_codecs', 'encodings.exceptions', 'stat', 'zipimport', 'warnings', 'encodings.types', 'UserDict', 'encodings.utf_8', 'sys', 'codecs', 'readline', 'types', 'signal', 'linecache', 'posix', 'encodings.aliases', 'exceptions', 'os']
>>> import wx
>>> sys.modules.keys()
['cStringIO', 'copy_reg', 'locale', 'wx.codecs', '__main__', 'site', '__builtin__', 'wx._gdi', 'wx.__version__', 'wx.locale', 'encodings', 'wx._core', 'posixpath', 'wx.types', 'pprint', 'encodings.codecs', 'wx._controls', 'wx._controls_', 'os.path', '_codecs', 'new', 'encodings.exceptions', 'wx._misc', 'wx._misc_', 'stat', 'zipimport', 'warnings', 'encodings.types', 'UserDict', 'swig_runtime_data2', 'encodings.utf_8', 'wx.new', 'sys', 'wx.swig_runtime_data2', 'codecs', 'wx._windows', 'readline', 'types', 'wx', '_locale', 'wx.sys', 'wx.wx', 'signal', 'wx._core_', 'linecache', 'posix', 'encodings.aliases', 'exceptions', 'os', 'wx._windows_', 'wx._gdi_']
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Eric Ongerth wrote:
Is it as easy as changing my import conventions from "import wx" to
"from
wx import TextCtrl", or is it much more complicated than that?It's got to be that easy! If it isn't, then that would be a very much needed change. That sounds like essential Python behavior.
The granularity used by py2exe and similar tools is the module, not the class. So in order for that to work every wrapped C++ class would have to be in its own extension module. That means that you would have to import each one you need separately, because if you import all of them with the import wx then there is no difference than now. It also means that everything gets lots more complex for everybody because then instead of writing wx.TextCtrl when you use it you'll need to write something like wx.textctrl.TextCtrl, and so on.
On 5/31/07, *Paul McNett* <p@ulmcnett.com <mailto:p@ulmcnett.com>> wrote:
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Robin Dunn wrote:
Eric Ongerth wrote:
Is it as easy as changing my import conventions from "import wx" to
"from
wx import TextCtrl", or is it much more complicated than that?It's got to be that easy! If it isn't, then that would be a very much needed change. That sounds like essential Python behavior.
The granularity used by py2exe and similar tools is the module, not the class. So in order for that to work every wrapped C++ class would have to be in its own extension module. That means that you would have to import each one you need separately, because if you import all of them with the import wx then there is no difference than now. It also means that everything gets lots more complex for everybody because then instead of writing wx.TextCtrl when you use it you'll need to write something like wx.textctrl.TextCtrl, and so on.
I was also going to write that with some python magic you could probably do some lazy on-demand loading of the class module from wx to make 'wx.TextCtrl' still work, but it would be lots more than just the classes that would have to support this. There is the styles and the event types that are specific to each widget class for starters, so this could easily get real complex real fast, and magic tends to break py2exe and friends anyway.
On 5/31/07, *Paul McNett* <p@ulmcnett.com <mailto:p@ulmcnett.com>> wrote:
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Robin Dunn wrote:
Eric Ongerth wrote:
Is it as easy as changing my import conventions from "import wx" to
"from
wx import TextCtrl", or is it much more complicated than that?It's got to be that easy! If it isn't, then that would be a very much needed change. That sounds like essential Python behavior.
The granularity used by py2exe and similar tools is the module, not the class. So in order for that to work every wrapped C++ class would have to be in its own extension module. That means that you would have to import each one you need separately, because if you import all of them with the import wx then there is no difference than now. It also means that everything gets lots more complex for everybody because then instead of writing wx.TextCtrl when you use it you'll need to write something like wx.textctrl.TextCtrl, and so on.
How about if a new namespace was given for this behavior, such as wx_:
import wx_ as wx
import wx.app
myApp = wx.app.App()
...
The wx_ namespace would have very very little (a few names, like most python packages). Perhaps each subpackage could load all its names into the main wx_ namespace upon import, so that we get the best of all worlds:
import wx_ as wx
import wx.app
myApp = wx.App()
...the end result being that the wx_ namespace can grow as needed to have just as many names as the wx namespace does now, but it doesn't start out that way upon 'import wx_'.
I don't know if I'm just rattling the cage without having actual good ideas, but achieving something like this would make wxPython smell much better in lots of ways, I would think.
On 5/31/07, *Paul McNett* <p@ulmcnett.com <mailto:p@ulmcnett.com>> wrote:
--
pkm ~ http://paulmcnett.com
Robin Dunn wrote:
I was also going to write that with some python magic you could probably do some lazy on-demand loading of the class module from wx to make 'wx.TextCtrl' still work, but it would be lots more than just the classes that would have to support this. There is the styles and the event types that are specific to each widget class for starters, so this could easily get real complex real fast, and magic tends to break py2exe and friends anyway.
You are absolutely correct. Let's leave this thread for the archives and move along... Thanks for the thoughtful replies, Robin!
--
pkm ~ http://paulmcnett.com
> For things like wxStandardPaths, maybe there should just be a pure
> python implementation -- ideally in the standard lib.
Absolutely.
...yes, and this was really what I was getting at in my initial reply -
it doesn't rely on anything else in wx (well, it shouldn't anyway),
It does, too ! It supposedly relies on SetAppName() having been called - which can be done only *after* wx.App() is initialized ... (On wxPython 2.6, anyway.)
Karsten
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: GMX Handytarife 2024 | jetzt wechseln & sparen
Andrea Gavana wrote:
Hi Paul,
Robin Dunn wrote:
> Werner F. Bruhin wrote:
>> Anders J. Munch wrote:
>>> Rune Devik wrote:
>>>
>>>> You can ask the registry where the appdata folder is.
>>>
>>> The proper way to get at this information is to use shell api functions.
>>>
>>> E.g., assuming pywin32 is available:
>>>
>>> from win32com.shell import shellcon, shell
>>> print shell.SHGetFolderPath(0, shellcon.CSIDL_COMMON_APPDATA, 0, 0)
>>>
>> I think wx.StandardPaths is a nicer method as it is not Win specific
>> and I would think that under the hood it does something like the above
>> on Windows.
>
> Yep. See
> http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/src/msw/stdpaths.cpp?rev=1.18&content-type=text/vnd.viewcvs-markupwx.StandardPaths looks perfect. Now, how do I include it in my
py2exe-generated exe that doesn't use wx without pulling all the wx
stuff into the exe?I thought that Python had something that dealt with this issue... but
my search got me nowhere. I, like you, thought that it was a fairly
standard thing. Surprisingly enough, it's not that standard
As far as I know, refactoring the wx workspace so that you can exclude
some part of it is maybe the most complex task after the automatic GUI
testing project. And, as others have already pointed out, the bulk of
wx lives in wxCore, which limits the advantages of splitting
Sorry if I don't have any useful suggestion, but I was a bit surprised
Python itself didn't provide something similar.
In case of an user application data folder, you could use this pure python function of os.path:
expanduser(path)
On Unix, return the argument with an initial component of "~" or "~user" replaced by that user's home directory. An initial "~" is replaced by the environment variable HOME if it is set; otherwise the current user's home directory is looked up in the password directory through the built-in module pwd. An initial "~user" is looked up directly in the password directory.
On Windows, only "~" is supported; it is replaced by the environment variable HOME or by a combination of HOMEDRIVE and HOMEPATH.
If the expansion fails or if the path does not begin with a tilde, the path is returned unchanged.
There is also os.path.expandvars for more general variables.
Stani
On 5/31/07, Paul McNett wrote: