GUI2Exe Improvements

Hi All,

    I am in the process of fixing the outstanding bugs in GUI2Exe,
adding new features and implementing the GUI interface for all the
executable builders I know of.

The current version of GUI2Exe works only with py2exe, but I have
extended it to support cx_Freeze and bbFreeze (which work also on
Linux/Unix as far as I know), and I am starting to code the GUI part
related to PyInstaller. Later on I'll do the same with py2app (for the
Mac), but obviously I will need someone with a Mac to test my
implementation.

Anyway, as my understanding of PyInstaller and its API is very
limited, and as I would like to support as many PyInstaller options as
possible from the GUI frontend, I would like to ask to all the mailing
lists members which are currently using PyInstaller whether they could
provide their PyInstaller "setup scripts", in order for me to get a
better understanding on how to best implement the GUI part of GUI2Exe.
The more complex the "setup scripts" are, the better, as I will get a
very broad view on the GUI layout. If you could throw some explanatory
lines of comment in your setup scripts I would be very grateful.

For those of you who don't know what the heck GUI2Exe is, the current
GUI2Exe version (plus some screenshots on Windows and Mac) is here:

http://xoomer.alice.it/infinity77/main/GUI2Exe.html

As you can see, GUI2Exe was (is) my first attempt to unify all the
available "executable builders" for Python in a single and simple to
use graphical user interface. I have now found the will to complete
the project and I hope it will be a useful tool for all the
Pythonistas out there :smiley:

Thank you very much.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

Andrea,

Andrea Gavana wrote:

Hi All,

    I am in the process of fixing the outstanding bugs in GUI2Exe,
adding new features and implementing the GUI interface for all the
executable builders I know of.

The current version of GUI2Exe works only with py2exe, but I have
extended it to support cx_Freeze and bbFreeze (which work also on
Linux/Unix as far as I know), and I am starting to code the GUI part
related to PyInstaller. Later on I'll do the same with py2app (for the
Mac), but obviously I will need someone with a Mac to test my
implementation.
  

To be able to handle the different platforms is very attractive, will have to have a look at this in the near future in more detail.

Looking at the screen shots and your description I can't see if you will support multiple .exe generation for one project?

I.e. a windows and a console one, or actually multiple .exe based on different scripts but ending up in the same distribution.

Werner

Please find here attached my pyinstaller setup script.
I added also a PyInstaller Manual I downloaded some time ago from the web. Unfortunately, I did not write down the address and the author, but it served me well, so far.

(PyInstall in origin wore proudly the extension bat: I had to take it off to pass the censorship)

PyInstaller Manual.doc (67 KB)

PyInstall (1.59 KB)

···

2008/8/5 Andrea Gavana andrea.gavana@gmail.com

Hi All,

I am in the process of fixing the outstanding bugs in GUI2Exe,

adding new features and implementing the GUI interface for all the

executable builders I know of.

The current version of GUI2Exe works only with py2exe, but I have

extended it to support cx_Freeze and bbFreeze (which work also on

Linux/Unix as far as I know), and I am starting to code the GUI part

related to PyInstaller. Later on I’ll do the same with py2app (for the

Mac), but obviously I will need someone with a Mac to test my

implementation.

Anyway, as my understanding of PyInstaller and its API is very

limited, and as I would like to support as many PyInstaller options as

possible from the GUI frontend, I would like to ask to all the mailing

lists members which are currently using PyInstaller whether they could

provide their PyInstaller “setup scripts”, in order for me to get a

better understanding on how to best implement the GUI part of GUI2Exe.

The more complex the “setup scripts” are, the better, as I will get a

very broad view on the GUI layout. If you could throw some explanatory

lines of comment in your setup scripts I would be very grateful.

For those of you who don’t know what the heck GUI2Exe is, the current

GUI2Exe version (plus some screenshots on Windows and Mac) is here:

http://xoomer.alice.it/infinity77/main/GUI2Exe.html

As you can see, GUI2Exe was (is) my first attempt to unify all the

available “executable builders” for Python in a single and simple to

use graphical user interface. I have now found the will to complete

the project and I hope it will be a useful tool for all the

Pythonistas out there :smiley:

Thank you very much.

Andrea.

“Imagination Is The Only Weapon In The War Against Reality.”

http://xoomer.alice.it/infinity77/


wxpython-users mailing list

wxpython-users@lists.wxwidgets.org

http://lists.wxwidgets.org/mailman/listinfo/wxpython-users

Better than the manual that comes with PyInstaller?
<E:\PyInstaller\doc\Manual.html>

Dick Moores

···

On Tue, Aug 5, 2008 at 12:41 PM, raffaello <barbarossa.platz@gmail.com> wrote:

Please find here attached my pyinstaller setup script.
I added also a PyInstaller Manual I downloaded some time ago from the web.
Unfortunately, I did not write down the address and the author, but it
served me well, so far.

Shorter and to the point.

···

2008/8/5 Dick Moores rdmoores@gmail.com

On Tue, Aug 5, 2008 at 12:41 PM, raffaello barbarossa.platz@gmail.com wrote:

Please find here attached my pyinstaller setup script.

I added also a PyInstaller Manual I downloaded some time ago from the web.

Unfortunately, I did not write down the address and the author, but it

served me well, so far.

Better than the manual that comes with PyInstaller?

<E:\PyInstaller\doc\Manual.html>

Dick Moores


wxpython-users mailing list

wxpython-users@lists.wxwidgets.org

http://lists.wxwidgets.org/mailman/listinfo/wxpython-users

Andrea,

Thanks for this cool application.

I'd like to know how you add Python Modules in the "Includes"
box, and same question with Python Packages ? I must be missing
something, but I don't see how to do that.

Raphael

···

----- Original Message ----- From: "Andrea Gavana" <andrea.gavana@gmail.com>
To: <wxPython-users@lists.wxwidgets.org>
Cc: <py2exe-users@lists.sourceforge.net>; <PyInstaller@googlegroups.com>
Sent: Tuesday, August 05, 2008 5:38 PM
Subject: [wxpython-users] GUI2Exe Improvements

Hi All,

   I am in the process of fixing the outstanding bugs in GUI2Exe,
adding new features and implementing the GUI interface for all the
executable builders I know of.

The current version of GUI2Exe works only with py2exe, but I have
extended it to support cx_Freeze and bbFreeze (which work also on
Linux/Unix as far as I know), and I am starting to code the GUI part
related to PyInstaller. Later on I'll do the same with py2app (for the
Mac), but obviously I will need someone with a Mac to test my
implementation.

Anyway, as my understanding of PyInstaller and its API is very
limited, and as I would like to support as many PyInstaller options as
possible from the GUI frontend, I would like to ask to all the mailing
lists members which are currently using PyInstaller whether they could
provide their PyInstaller "setup scripts", in order for me to get a
better understanding on how to best implement the GUI part of GUI2Exe.
The more complex the "setup scripts" are, the better, as I will get a
very broad view on the GUI layout. If you could throw some explanatory
lines of comment in your setup scripts I would be very grateful.

For those of you who don't know what the heck GUI2Exe is, the current
GUI2Exe version (plus some screenshots on Windows and Mac) is here:

http://xoomer.alice.it/infinity77/main/GUI2Exe.html

As you can see, GUI2Exe was (is) my first attempt to unify all the
available "executable builders" for Python in a single and simple to
use graphical user interface. I have now found the will to complete
the project and I hope it will be a useful tool for all the
Pythonistas out there :smiley:

Thank you very much.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users

Hi Raph,

Thanks for this cool application.

I'd like to know how you add Python Modules in the "Includes"
box, and same question with Python Packages ? I must be missing
something, but I don't see how to do that.

There is a small tutorial in my website and in GUI2Exe which explains
more or less everything. As Modules, Packages, Includes/Excludes are
represented using ListCtrl, I thought convenient to use Ctrl+A to add
items to those lists. But as you are the second or the third person
who found it counter-intuitive or non-evident, I think this design
decision was not very smart from my part, and I will add another way
to add items to the lists (such as right click popup menus or the
like).

So, the short answer is: for the moment, hit Ctrl+A to add items to
the list controls you are interested in, until a new version of
GUI2Exe comes out :smiley:

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

···

On 8/6/08, Raph wrote:

Hi Werner,

Looking at the screen shots and your description I can't see if you will
support multiple .exe generation for one project?

I.e. a windows and a console one, or actually multiple .exe based on
different scripts but ending up in the same distribution.

This is not possible at the moment, but I have thought about it and it
is actually pretty easy to modify the interface to handle multiple
.exe generation for one project. I just need to see if other
executable builders can support the same approach (to generalize the
GUI) or to design a special case for py2exe. In any case, I have added
your request to the list of features I am implementing in GUI2Exe.

Thank you for the suggestion.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

···

On 8/5/08, Werner F. Bruhin wrote:

Hi Werner,

Hi Werner,

> Looking at the screen shots and your description I can't see if you will
> support multiple .exe generation for one project?
>
> I.e. a windows and a console one, or actually multiple .exe based on
> different scripts but ending up in the same distribution.

This is not possible at the moment, but I have thought about it and it
is actually pretty easy to modify the interface to handle multiple
.exe generation for one project. I just need to see if other
executable builders can support the same approach (to generalize the
GUI) or to design a special case for py2exe. In any case, I have added
your request to the list of features I am implementing in GUI2Exe.

I am taking back my words :smiley:

As I have never used the "multiple exe" feature of py2exe, I didn't
pay too much attention to this issue. Now that I am looking at it, it
looks like every single executable you want to build (in the multiple
exe group) can have its set of options, like icon_resources, manifest
files, data_files and so on. As far as I can understand, this means
actually replicating the same GUI panel (with all the options) for
every executable you wish to build. And it looks like a PITA from the
GUI point of view, as I am not sure implementing this thing will not
break compatibility with previous GUI2Exe versions: for those who
already use GUI2Exe, they have a database of projects saved on the
hard drive, which can be retrieved by a single click, adjusted and
recompiled without messing with the source code. Now, going from a
single panel (for a single executable) to a multiple panels GUI will
probably break the existing databases unless I find an intelligent
solution to the problem.

I'll see what I can do, and if the solution I will arrive to is good enough...

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

···

On 8/6/08, Andrea Gavana wrote:

On 8/5/08, Werner F. Bruhin wrote:

Andrea Gavana wrote:

Hi Werner,

I'll see what I can do, and if the solution I will arrive to is good enough...

Hi Andrea!

One thing you can do is maintain a database version number, to keep track of issues like this. For example if your database was a dictionary:

def getVersion(db):
    if 'version' in db:
        return db['version']
    else:
        return 1

so, since you didn't version the first revision, you want to return 1, otherwise the version number stored in your db, however you do that. So when you make your multi-exe db version 2, you can just check the version to determine handling. Additionally you may want to "upgrade" the version at this time and write out the new version number, so current users of your project can start making multiple exes without creating a new project. If each time you make a new version, you write a script that can convert the last version to the new one, then you can convert any version to the latest by running the necessary scripts in series (ie 1->2, 2->3).

Does anyone have any comments or criticisms of this method? It is how I am thinking of handling differences in the database for one of my projects.

PS Andrea, did you ever get anywhere with wxAuiTabArt, putting icons in AUI tabs? Is it wrapped properly in Python yet? I was previously out of the loop for a bit.

- Mike

···

On 8/6/08, Andrea Gavana wrote:

Andrea Gavana wrote:

Hi Werner,

Hi Werner,

Looking at the screen shots and your description I can't see if you will
support multiple .exe generation for one project?

I.e. a windows and a console one, or actually multiple .exe based on
different scripts but ending up in the same distribution.
      

This is not possible at the moment, but I have thought about it and it
is actually pretty easy to modify the interface to handle multiple
.exe generation for one project. I just need to see if other
executable builders can support the same approach (to generalize the
GUI) or to design a special case for py2exe. In any case, I have added
your request to the list of features I am implementing in GUI2Exe.
    
I am taking back my words :smiley:

As I have never used the "multiple exe" feature of py2exe, I didn't
pay too much attention to this issue. Now that I am looking at it, it
looks like every single executable you want to build (in the multiple
exe group) can have its set of options, like icon_resources, manifest
files, data_files and so on. As far as I can understand, this means
actually replicating the same GUI panel (with all the options) for
every executable you wish to build. And it looks like a PITA from the
GUI point of view, as I am not sure implementing this thing will not
break compatibility with previous GUI2Exe versions: for those who
already use GUI2Exe, they have a database of projects saved on the
hard drive, which can be retrieved by a single click, adjusted and
recompiled without messing with the source code. Now, going from a
single panel (for a single executable) to a multiple panels GUI will
probably break the existing databases unless I find an intelligent
solution to the problem.

I'll see what I can do, and if the solution I will arrive to is good enough...

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

I'm probably being naive here, but for projects with multi-exes, couldn't you just nest tabs? For example, in the "New Project" menu, you could ask the developer if they want a single or a multi exe interface. The single one would use your current model (or however you've updated it of late), but the multi-exe one could use a nested Flatbook or Toolbook control and then iterate over each page when compiling.

Anyway, thanks for the excellent tool. I use it quite a bit.

Mike

···

On 8/6/08, Andrea Gavana wrote:

On 8/5/08, Werner F. Bruhin wrote:

Mike Rooney wrote:

Andrea Gavana wrote:

Hi Werner,

I'll see what I can do, and if the solution I will arrive to is good enough...

Maybe define each exe as you do now and have another option/screen which allows you to select exe's to be generated in one go?

  
Hi Andrea!

One thing you can do is maintain a database version number, to keep track of issues like this. For example if your database was a dictionary:

def getVersion(db):
   if 'version' in db:
       return db['version']
   else:
       return 1

so, since you didn't version the first revision, you want to return 1, otherwise the version number stored in your db, however you do that. So when you make your multi-exe db version 2, you can just check the version to determine handling. Additionally you may want to "upgrade" the version at this time and write out the new version number, so current users of your project can start making multiple exes without creating a new project. If each time you make a new version, you write a script that can convert the last version to the new one, then you can convert any version to the latest by running the necessary scripts in series (ie 1->2, 2->3).

Does anyone have any comments or criticisms of this method? It is how I am thinking of handling differences in the database for one of my projects.

Similar to what I do on my shareware, first thing application checks what the database version is, if it is lower then program database version then an upgrade script is called which supports to jump over multiple releases (i.e. 1.0 > 1.1 > 1.2 ..., but when I issued 2.0 one had to be on the latest 1.x release to be able to upgrade.

You also have to check that the database is not newer then the program, i.e. handle the case when the user installs a wrong program version.

Werner

···

On 8/6/08, Andrea Gavana wrote:

Hi All,

Mike Rooney wrote:
> Andrea Gavana wrote:
>
> > Hi Werner,
> >
> > I'll see what I can do, and if the solution I will arrive to is good
enough...
> >
> >
>
Maybe define each exe as you do now and have another option/screen which
allows you to select exe's to be generated in one go?
>
> >
> >
>
> Hi Andrea!
>
> One thing you can do is maintain a database version number, to keep track
of issues like this. For example if your database was a dictionary:
>
> def getVersion(db):
> if 'version' in db:
> return db['version']
> else:
> return 1
>
> so, since you didn't version the first revision, you want to return 1,
otherwise the version number stored in your db, however you do that. So when
you make your multi-exe db version 2, you can just check the version to
determine handling. Additionally you may want to "upgrade" the version at
this time and write out the new version number, so current users of your
project can start making multiple exes without creating a new project. If
each time you make a new version, you write a script that can convert the
last version to the new one, then you can convert any version to the latest
by running the necessary scripts in series (ie 1->2, 2->3).
>
> Does anyone have any comments or criticisms of this method? It is how I am
thinking of handling differences in the database for one of my projects.
>
Similar to what I do on my shareware, first thing application checks what
the database version is, if it is lower then program database version then
an upgrade script is called which supports to jump over multiple releases
(i.e. 1.0 > 1.1 > 1.2 ..., but when I issued 2.0 one had to be on the latest
1.x release to be able to upgrade.

You also have to check that the database is not newer then the program, i.e.
handle the case when the user installs a wrong program version.

Thanks to you all for your suggestions. I think (I hope) I found an
easier and less cluttered way to handle multiple exe files, without
repeating the same information all over multiple panels. I attach a
view of the current GUI2Exe for those interested.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

···

On 8/6/08, Werner F. Bruhin wrote:

> > On 8/6/08, Andrea Gavana wrote:

Andrea Gavana wrote:

Hi All,

Mike Rooney wrote:
    

Andrea Gavana wrote:

Hi Werner,

I'll see what I can do, and if the solution I will arrive to is good
        

enough...
    

Maybe define each exe as you do now and have another option/screen which
allows you to select exe's to be generated in one go?
    

Hi Andrea!

One thing you can do is maintain a database version number, to keep track
      

of issues like this. For example if your database was a dictionary:
    

def getVersion(db):
  if 'version' in db:
      return db['version']
  else:
      return 1

so, since you didn't version the first revision, you want to return 1,
      

otherwise the version number stored in your db, however you do that. So when
you make your multi-exe db version 2, you can just check the version to
determine handling. Additionally you may want to "upgrade" the version at
this time and write out the new version number, so current users of your
project can start making multiple exes without creating a new project. If
each time you make a new version, you write a script that can convert the
last version to the new one, then you can convert any version to the latest
by running the necessary scripts in series (ie 1->2, 2->3).
    

Does anyone have any comments or criticisms of this method? It is how I am
      

thinking of handling differences in the database for one of my projects.
    Similar to what I do on my shareware, first thing application checks what
the database version is, if it is lower then program database version then
an upgrade script is called which supports to jump over multiple releases
(i.e. 1.0 > 1.1 > 1.2 ..., but when I issued 2.0 one had to be on the latest
1.x release to be able to upgrade.

You also have to check that the database is not newer then the program, i.e.
handle the case when the user installs a wrong program version.
    
Thanks to you all for your suggestions. I think (I hope) I found an
easier and less cluttered way to handle multiple exe files, without
repeating the same information all over multiple panels. I attach a
view of the current GUI2Exe for those interested.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
  
As always, your applications look good. Looking forward to seeing it in action.

Mike

···

On 8/6/08, Werner F. Bruhin wrote:

On 8/6/08, Andrea Gavana wrote:

Mike Driscoll wrote:
...

  
As always, your applications look good. Looking forward to seeing it in action.

Can only agree with this!
Werner

Hi All,

I think I am in the final stages of making GUI2Exe really doing its
job on all the executable builder out there, and specifically I have
added support for:

- cx_Freeze (Windows and Linux);
- bbFreeze (Windows and Linux);
- PyInstaller (all platforms (?) )

I am actually coding the support for py2app for Mac developers. One of
the main problems I am facing is that I don't have access to a Mac and
I know next to nothing about Mac. Moreover, py2app has a gazillion of
options, most of which I have never heard of.
So, if there is someone out there using py2app, could he/she enlighten
me about the following issues:

1) iconfile: does the icon resource on Mac always have the extension *.icns?
2) dylib-excludes: do these dylib things have a file extension?
3) datamodels: what are xcdatamodels?

There might be some other question but at the moment this is the
information I am looking for.
As I don't have a Mac here I would like to ask if someone is willing
to test the new GUI2Exe version on Mac and help me finding the bugs I
will for sure introduce :smiley:

Thank you very much.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

Hello,

Hi All,

I think I am in the final stages of making GUI2Exe really doing its
job on all the executable builder out there, and specifically I have

added support for:

  • cx_Freeze (Windows and Linux);
  • bbFreeze (Windows and Linux);
  • PyInstaller (all platforms (?) )

I am actually coding the support for py2app for Mac developers. One of
the main problems I am facing is that I don’t have access to a Mac and

I know next to nothing about Mac. Moreover, py2app has a gazillion of
options, most of which I have never heard of.
So, if there is someone out there using py2app, could he/she enlighten
me about the following issues:

  1. iconfile: does the icon resource on Mac always have the extension *.icns?

Yes, I believe so

  1. dylib-excludes: do these dylib things have a file extension?

You can think of these basically as .dll’s on windows. The extension is .dylib.

  1. datamodels: what are xcdatamodels?

Not sure on this one, never used it nor seen it.

Most of the important configuration options for py2app that differ from py2exe are in the Plist dictionary. Which py2app converts to the required xml for a mac app bundle. This allows for setting of things like filetype association, program type, language settings, ect…

Cody

···

On 8/20/08, Andrea Gavana andrea.gavana@gmail.com wrote:

Andrea Gavana wrote:

Hi All,

I think I am in the final stages of making GUI2Exe really doing its
job on all the executable builder out there, and specifically I have
added support for:

- cx_Freeze (Windows and Linux);
- bbFreeze (Windows and Linux);
- PyInstaller (all platforms (?) )

I am actually coding the support for py2app for Mac developers. One of
the main problems I am facing is that I don't have access to a Mac and
I know next to nothing about Mac. Moreover, py2app has a gazillion of
options, most of which I have never heard of.
So, if there is someone out there using py2app, could he/she enlighten
me about the following issues:

1) iconfile: does the icon resource on Mac always have the extension *.icns?

Yes. FYI, it's a special file format that can contain multiple copies of the same image at different sizes or even different color depths IIRC.

2) dylib-excludes: do these dylib things have a file extension?

Yep. It's .dylib. The docstring says that option is also used for excluding frameworks, so that would be, yep you guessed it, the .framework file extension. I've never used this option however so I'm not sure if the extensions are required or if you can just give the name...

3) datamodels: what are xcdatamodels?

No idea. A bit of googling shows that it is something produced by XCode, and that it's file extension is .xcdatamodel. (Can you see a pattern here? :wink: )

Actually, they are not really files, but packages, which on OS X are directories containing subdirectories and files in a certain structure and format. From the UI however you can usually treat them as if they were files. Frameworks, Applications and other things work the same way.

There might be some other question but at the moment this is the
information I am looking for.
As I don't have a Mac here I would like to ask if someone is willing
to test the new GUI2Exe version on Mac and help me finding the bugs I
will for sure introduce :smiley:

You may wan to mail to pythonmac-sig about this too. You may find some folks there interested in helping out that are doing something besides wx applications.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Andrea Gavana wrote:

I am actually coding the support for py2app for Mac developers.

Thanks for the effort!

1) iconfile: does the icon resource on Mac always have the extension *.icns?

yes.

2) dylib-excludes: do these dylib things have a file extension?

yes -- "dylib" as in: libwx_macud-2.8.0.dylib

3) datamodels: what are xcdatamodels?

That, I don't know.

There might be some other question but at the moment this is the
information I am looking for.

keep them coming.

As I don't have a Mac here I would like to ask if someone is willing
to test the new GUI2Exe version on Mac and help me finding the bugs I
will for sure introduce :smiley:

I should be able to do that. This could turn out to be a pretty cool tool!

-CHB

···

--
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