I don’t know if I’m stepping on anybody’s toes here, but I have been also looking at the code for pandapack and have been integrating it into a wxPython app that would give a little more flexibility in building up the NSIS installer and consequently make packaging a little more user-friendly.
wxPython was deliberately chosen as the windowing toolkit because it was multiplatform (Windows, Linux, OS X) and also extremely easy to work with in Python.
If there are no objections, I’d like to post it up here as well so people can play with it. Bear in mind that it does require wxPython be installed. I used the base Python install with Panda and haven’t had any problems. Of course this could also be packaged up using py2exe to make it completely standalone.
This might be a good add-on package for people who want a GUI to manage that part of their project’s production.
Being able to load/save a “pack profile” of all of the options required to build the installer.
Instead of working from the command line and adding even more options (which can get tedious), also being able to extend it with a few more configuration options from the GUI.
Some of the options such as --pyc and --bam would then become simple checkboxes.
Not everybody wants to to jump to the shell in order to build a package. Though I am sure a lot don’t mind.
I was also considering the philosophy of Panda being easy to access and program using Python. Why not go one step further and give the packaging tools a good interface?
It’s also entirely possible that, given a multi-person team, the person responsible for building the installations is not a programmer.
Heck, even I, as a programmer, would like to have a tool that makes my job easier in some way. Not saying that this would be for everyone, but it opens a lot more options for people to use the entire system and gives it one more merit.
As I said, I don’t know if this would be even needed, but I sure would like to have it. Even NSIS has its own (3rd-party) GUI editors and wizards to aid in the process of making installers.
The GUI itself is coded in Python also, so there’s need to jump languages to do something like this.
I don’t know. I’ll fool around with it and see what I come up with. The proof is in the pudding, as they say.
Why not use tk instead of wxPython ? I know tk looks horrible but it comes standard with panda3d and most tools are written in tk like particle editor and stuff.
For me i just create a script to run the installation process with one button so i dont think this tool would be all that useful being in wx and for part that most people don’t use.
I think it would be cool to have more tools like pview and uis for different egg conventions for which you have to see in 3d.
Hm,ok.
But again,how big will a standalone app. be?Just curious.
PS.I think a Config.prc editor would be good too.End-user can change things with windows and buttons.
I had thought of using DirectGUI for it, but for a tool like this, I didn’t think it needed to have a dependency on it to function. Frankly, my own experiences with wxPython have been quite positive, especially with using wxGlade for the design portion of it.
bestseclub: as far as a final executable size goes, you’re looking at around 2-3MB fully compiled. After doing a little trimming that could be brought down even further.
An interesting side note, the one big thing that I noticed was that, in installing wxPython into the Panda3D Python branch, it bloated it up about an extra 40MB. Which resulted in the installers being created being even larger with even bigger installs.
As such, I’ve also been investigating the NSIS script itself and have managed to get it pared down the bare minimums for an installer for a game. Rather than a 50+MB file, it’s down to around 17.8MB, without any large game-specific files, of course. And it still runs, even with some of the demo programs compiled to bytecode and included.
Another thing that might be worth investigating is integrating py2exe and getting all of the redistributables bundled using that, then building the installer around the /dist output subdirectory.
It’s basically taking what is pandapack.py right now and going from there. The central idea is that it makes this less difficult than it is right now and capable of building more customized installers.
I feel that I may have tripped onto a nerve with a few folks, which was not my intention. Sometimes I do get a little excited about an idea and tend to run with it down the field.
The code will not be hard, no harder than what pandapack.py already is. wxPython code, if done right, is neatly managed into Python modules and classes, just like the Panda3D wrapper API is. Believe me, I don’t want to make people’s lives harder; rather the opposite in this case.
For some parts of it, such as previewing bitmaps for the installer, it would likely need to be more graphic-oriented. It can be made to look good and be functional if that is the question.
You have nothing to apologize for at all, trying to make things easier which is in total lock step with the easy to use panda ( python, etc.), is totally appropriate I think so I wish you well in this endeavor The whole notion that command line use is the only entrance to useful tools is rather obnoxious to me ( though I can do it with the best of them IF I choose to ) , so go you
IMHO wxPython is an excellent tool for development that needs a GUI. I have used it for several crossplatform projects (linux, embedded linux and windows) and have never been disappointed.
Thanks for the feedback everyone. I’ll do some tinkering around with wxPython and see if I can come up with something that is usable in the near future, then put the code up for people to play with.
It’s a little more involved than making a script to compile a CHM file from the HTML reference, and I am doing it in my spare time, but I will try to be quick about it.
This might also be something to include as a feature for the installer builder, where it could generate the Config.prc file with either the default values, or whatever is entered as overrides from the UI. That way it’s customized for that particular install only at install build time, and doesn’t interfere with the existing one that you may want to change prior to packaging.
Okay, I’ve got a rudimentary wxPython app for setting up/writing a .prc file. It grabs the initial values by interrogating the ConfigVariableXXX classes and then filling it in.
From there, you can save a .prc file with the values. I’ve been going through the doc and trying to build up a good, logical way to organize all of the variables. So far I’m just playing around with it, but I’ve only been at it for about 2 hours.
Here’s a screenshot in Windows of what it looks like. If you run a wxPython program in KDE or Gnome, it will use the underlying window manager’s themes and styles.
Wow,dklon,just what i ment
Now if this will appear in the startup after installation,end-users will be able to
1)change from DirectX 9 to OpenGL and even to software renderer
2)Change from fullscreen to windowed.
3)Change the default screen resolution(dunno if this is useful).
4)Change the default window name.
Maybe more,i dont know much about the prc file.
Anyway,looks like a good feature for a game to have its own settings editor.
After I hacked away at this for a few more hours, it dawned on me that there might be 2 versions of this: one for developers to make their .prc files, and the other for the players of the games. The one for the players would be more stripped down and not have as many different options (such as debugging variable control).
Anyways, I have a lot more added since then. Basic, 3D, and Audio are the 3 tabs right now in the app. I’ll post the code here soon. Remember to download wxPython 2.8-Unicode or higher if you want to run it.
I hacked away some more, going through the documentation on configuration variables and gotten to this point, as shown below.
I’m copying the descriptions out as tooltips for each variable, but also substituting some of my own where there isn’t any real description.
The end-user configurator could be based on the same modular codebase and just tuned down with certain things turned off (could be a switch in the main app perhaps?)
In regards to the volume thing being 0-100 rather than 0.00 to 1.00, I just multiplied the value by 100, then divide by 100 when writing out the file, so the interface is a little more user-friendly.
this thing is looking more useful than i first thought. it’s indeed less intresting for the developers. but a striped-down version for the end-user certainly makes sense.
keep up the good work
The whole notion that command line use is the only entrance to useful tools is rather obnoxious to me ( though I can do it with the best of them IF I choose to ) , so go you 
