wxGlade GUI builder

wxPython Users
1

Hi!

As wxPython Phoenix is approaching the release, I would like to encourage you to have a look and test the latest version of wxGlade as well.

If you have a need for a GUI builder and did test wxGlade before, but you found that wxGlade did not fit your purpose, then please give the new version a try anyway. It's really different from the previous revisions. wxGlade is still sizer based, i.e. absolute positioning is not and will not be supported.

As of now, you just may download the latest repository version from https://bitbucket.org/wxglade/wxglade/get/default.zip and run wxglade.py .

Once it is running, hit F1 to open the tutorial and read at least the section "wxGlade Overview".
(The tutorial can be previewed at https://htmlpreview.github.io/?https://bitbucket.org/wxglade/wxglade/raw/ad4067300ebd0da145c7001b10f6f285a203f839/docs/Tutorial.html )

The tutorial is not too good yet. It is a new start, trying to help both people with and without wx experience.

Please report bugs by email or at https://sourceforge.net/p/wxglade/bugs/ or on the mailing list at https://lists.sourceforge.net/lists/listinfo/wxglade-general

This version supports Python 3 and Phoenix as well as previous versions. I'm testing with Python 2.7 / wxPython 3.0.2 and Python 3.6 / Phoenix snapshots on Windows. Sometimes I'm also testing on Mac OS. It would be good to have some Linux testers / contributors for a better coverage.
Sometimes it might be necessary not to use the very latest Phoenix snapshot, but I will always try to find a workaround and report bugs to Robin.

The file format of the current repository version is still identical to the old release 0.7.2.
The focus of last year's work was not to add features, but to increase usability, support Phoenix and clean up some internal things. Future versions will add features and widget options which will break the forward compatibility.

Regards,

Dietmar

2

I am looking into integrationg WXG into Boa Constructor, so the package may start to make sense possibly. :wink:

3

Sorry, I don't understand this sentence.

About the subject: yes, wxGlade is a GUI builder. It is not and does not aim to be an IDE, though. There are good Python IDEs like Wing and PyCharm.

Regards,

Dietmar

···

On 6/15/17 9:34 PM, firefox@firemail.cc wrote:

I am looking into integrationg WXG into Boa Constructor, so the package may start to make sense possibly. :wink:

4

Except that the whole world calls stuff like wxglade a "GUI designer", while, say, Delphi and Lazarus are real GUI builders.

5

Hi,

Except that the whole world calls stuff like wxglade a "GUI designer",
while, say, Delphi and Lazarus are real GUI builders.

Delphi is actually a complete-blown IDE for a Pascal, not just a GUI
designer/builder.

Can't say anything about Lazarus.

Thank you.

···

On Thu, Jun 15, 2017 at 4:07 PM, <firefox@firemail.cc> wrote:

--
You received this message because you are subscribed to the Google Groups
"wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to wxpython-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

6

I doubt that the whole world knows and talks about "stuff like wxGlade".
With respect to Python e.g. Qt Designer would be a GUI designer as it does not create a Python program but just a file that can be converted and/or imported by a Python program.

But anyway, please don't spam this thread if you don't want to contribute. You have opened enough threads this week to do there whatever you want.

Regards,
Dietmar

···

On 6/15/17 10:07 PM, firefox@firemail.cc wrote:

Except that the whole world calls stuff like wxglade a "GUI designer", while, say, Delphi and Lazarus are real GUI builders.

7

well, many real existing IDEs these days offer NOTHING when it comes to GUI building or GUI designing, to tell you the truth.

8

(The tutorial can be previewed at GitHub & BitBucket HTML Preview )

Not bad at all.

This version supports Python 3 and Phoenix as well as previous versions. I'm
testing with Python 2.7 / wxPython 3.0.2 and Python 3.6 / Phoenix snapshots
on Windows. Sometimes I'm also testing on Mac OS. It would be good to have
some Linux testers / contributors for a better coverage.

Once it has entered Debian I'll automatically test ...

The file format of the current repository version is still identical to the
old release 0.7.2.
The focus of last year's work was not to add features, but to increase
usability, support Phoenix and clean up some internal things. Future
versions will add features and widget options which will break the forward
compatibility.

Just to make sure: Does this mean that future versions will
not be able to read the previous *.wxg file version ?

Thanks,
Karsten

···

On Thu, Jun 15, 2017 at 09:17:15PM +0200, Dietmar Schwertberger wrote:
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

9

(The tutorial can be previewed at GitHub & BitBucket HTML Preview )

Not bad at all.

Thanks :slight_smile:

Once it has entered Debian I'll automatically test ...

This will proabably take quite some time and it probably requires a volunteer to manage this.
I will focus on development, not on installers and packaging (for a developer tool, I think that should be acceptable).
I would suggest to install Phoenix for Python 3 via PyPi and just download wxGlade to the user directory.
This should not interfere with any Debian pre-installed software as this would only have wxPython for Python 2.x, not for python3.

Just to make sure: Does this mean that future versions will
not be able to read the previous *.wxg file version ?

There will always be backward compatibility, i.e. the new version will always be able to read the old file version.
Just the other way round might not work all the time.

Regards,
Dietmar

···

On 6/15/17 10:53 PM, Karsten Hilbert wrote:

10

  1. I’d start with a option to send the generated code to a stc code preview frame.

  2. Option to remove all the BEGIN/END wxGlade comments in the generated code.

  3. Encoding should be a dropdown combobox with various encodings

  4. _ = wx.GetTranslation

  5. More widgets. Lacking in this aspect. Start with stc.StyledTextCtrl…That will keep you busy for years :wink:

  6. Post some pics of other GUI Builders, so as to compare features, or storyboard mockup layouts, etc.

  7. Tell ‘furfur’ to quit spamming.

  8. Consider moving project to GitHub, so it’s super ez to contribute.

wxglade_vs_sourcecoder.png

11

> Once it has entered Debian I'll automatically test ...
This will proabably take quite some time and it probably requires a
volunteer to manage this.

apt-cache show wxglade:

  Package: wxglade
  Version: 0.7.2-2
  Installed-Size: 5753
  Maintainer: Georges Khaznadar <georgesk@debian.org>

I truly hope Georges will keep up the good work :slight_smile:

It may take a bit more time for Phoenix to land in Python.
But then, that isn't *required* for wxGlade, is it ?

> Just to make sure: Does this mean that future versions will
> not be able to read the previous *.wxg file version ?
There will always be backward compatibility, i.e. the new version will
always be able to read the old file version.
Just the other way round might not work all the time.

Yeah, that's fine. I was confused about forwards vs backwards
compatibility for a moment :slight_smile:

Karsten

···

On Thu, Jun 15, 2017 at 11:04:10PM +0200, Dietmar Schwertberger wrote:
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

12

1. I'd start with a option to send the generated code to a stc code preview frame.

Nice one !

2. Option to remove all the BEGIN/END wxGlade comments in the generated code.

Unless I am mistaken these are needed for the "do NOT
overwrite when generating source code" functionality.

The "option" could be to not generate them comments if
"overwrite source" is requested :slight_smile:

In this age of reproducible builds it'd be nice to switch off
*all* code generation random facts like:

  # generated by wxGlade 0.6.8

(most can be switched off, this one can't to my knowledge)

3. Encoding should be a dropdown combobox with various encodings

For me, utf8 works for pretty much any case. Which use cases
do you have in mind ?

I'd agree to consider _removing_ the encoding selection and
making it utf8 all the way OR making it a dropdown.

4. _ = wx.GetTranslation

Ah, well, this should be an option at most
(whether _ = gettext.gettext or wx.GetTranslation)

5. One thing I'd really like to see is a " private" flag
next to the "extra code" panel. Rationale:

I often use "extra code" to import widgets enhanced elsewhere
in my project code for use in the current panel. Such imports
are placed at the top of a wxGlade generated Python file (1)
but sometimes they need to be place "further inside" or else
they will create "cannot import name" exceptions due to them
also being used elsewhere. This can be solved by placing the
import at (2).

  #!/usr/bin/env python
  # -*- coding: utf-8 -*-
  # generated by wxGlade 0.6.5 from "/home/ncq/Projekte/gm-git/gnumed/gnumed/client/wxg/wxgTestPanelEAPnl.wxg"

  import wx

  # begin wxGlade: extracode
(1) from Gnumed.wxpython.gmCodingWidgets import cGenericCodesPhraseWheel
  # end wxGlade

  class wxgTestPanelEAPnl(wx.ScrolledWindow):
      def __init__(self, *args, **kwds):

(2) from Gnumed.wxpython.gmCodingWidgets import cGenericCodesPhraseWheel

          # begin wxGlade: wxgTestPanelEAPnl.__init__
          kwds["style"] = wx.NO_BORDER | wx.TAB_TRAVERSAL
          wx.ScrolledWindow.__init__(self, *args, **kwds)

(btw, this is an example of what BEGIN/END wxGlade is used
for: because the generated begin is marked wxGlade can keep
my manual modifications around when I regenerate the source
without "overwrite source")

I do agree this is a code smell and best avoided but
sometimes it is quite difficult to refactor such as to avoid
the circular import. I also do agree the import could be more
intelligent (after all, if it does notice it already imported
something why not "just" reuse that ?).

Best,
Karsten

···

On Thu, Jun 15, 2017 at 10:04:02PM -0700, Metallicow wrote:
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

13

It's not required, but Python 3 and Phoenix are more pleasant to use.

Regards,
Dietmar

···

On 6/16/17 9:34 AM, Karsten Hilbert wrote:

It may take a bit more time for Phoenix to land in Python.
But then, that isn't *required* for wxGlade, is it ?

14

OK then, that means it likely won't take that long after
release for wxGlade-next to land in Debian and for me to test.

Karsten

···

On Fri, Jun 16, 2017 at 10:03:30AM +0200, Dietmar Schwertberger wrote:

On 6/16/17 9:34 AM, Karsten Hilbert wrote:
> It may take a bit more time for Phoenix to land in Python.
> But then, that isn't *required* for wxGlade, is it ?
It's not required, but Python 3 and Phoenix are more pleasant to use.

--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

15

I don't recommend this approach.
We're talking about a developer tool.
By waiting for installers, you are more or less cut off from bug fixes or feature requests.
What is the added value of an installer for a Python program? There are just files to be copied to the harddisk. Even with an installer, you need to decide yourself which Python and wxPython version to use.
If you are still using 0.7.2 then you have missed a lot already.

Regards,
Dietmar

···

On 6/16/17 10:33 AM, Karsten Hilbert wrote:

OK then, that means it likely won't take that long after
release for wxGlade-next to land in Debian and for me to test.

16

> OK then, that means it likely won't take that long after
> release for wxGlade-next to land in Debian and for me to test.
I don't recommend this approach.
We're talking about a developer tool.
By waiting for installers, you are more or less cut off from bug fixes or
feature requests.

I know. And I do test earlier versions using downloads.

What is the added value of an installer for [wxGlade]

A "standardized" install procedure.

A clean, systemwide install/uninstall.

A reproducible build environment.

What is the added value of an installer for a Python program?

A "standardized" install procedure.

A clean, systemwide install/uninstall.

There are just files to be copied to the harddisk.

Sure, but there's not just an installer (as in "copy a: c:").
A package maintainer will make sure that dependancies are
meetable and met and that the tool fits well into the
distribution's ecosystem. There may need to be helper scripts
written, backup procedures set up, etc etc.

Some code may need to be place apart from the application
code (such as libs) which are useful outside the application.

Say, TheTimeLineProject: They provide a nice Timeline
application which also includes wxPython panel which can be
reused in other wxPython projects so that they can include
timeline functionality. There is no packages for TimeLine.
Therefore, GNUmed needs to *include* the relevant TimeLine
code as a secondary copy in order to provide a systemwide
install for all users of GNUmed which is really unfortunate.

Such things lead to "private-DLL hell" and all-in-one
monster-packages.

Of course, only a few of the above considerations apply to
wxGlade as a developer tool.

Karsten

···

On Fri, Jun 16, 2017 at 11:10:23AM +0200, Dietmar Schwertberger wrote:
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

17

1. I'd start with a option to send the generated code to a stc code preview frame.
2. Option to remove all the BEGIN/END wxGlade comments in the generated code.

I need to refactor and streamline the code generation process first. After that I will look into such things. Currently it would not be too easy to display the generated code on the fly. The code generation is currently done by creating XML in memory and parsing this, which is unnecessarily complicated. Also, the BEGIN/END blocks were implemented in a way that is not very robust and future-proof. I want to change this in the long term to move a bit towards a RAD tool.

3. Encoding should be a dropdown combobox with various encodings

Just added, for the most important options like UTF-8 and Latin-1.

4. _ = wx.GetTranslation

That's a good idea. I will look into this once the code generation is modified.

5. More widgets. Lacking in this aspect. Start with stc.StyledTextCtrl...That will keep you busy for years :wink:

Widget support is the part which is easy to be contributed by users...

6. Post some pics of other GUI Builders, so as to compare features, or storyboard mockup layouts, etc.

Well, the choice is not that big. If I would have found one to satisfy my needs as Python developer, I would have used that one.
But for sure, the website needs to be improved with respect to that.
Your screenshot is lacking the Design and Preview windows. That's why I suggested to read at least the overview section of the tutorial. Of course, nowadays the Tree window is the most important one as many things can easier be edited in the hierarchical view.

8. Consider moving project to GitHub, so it's super ez to contribute.

My preference would also be GitHub and it would fit better into the wx universe. So I think I will move later this year.

Thanks for your feedback.
Technical things like this should probably rather be discussed on the wxGlade mailing list than here.

Regards,

Dietmar

···

On 6/16/17 7:04 AM, Metallicow wrote:

18

> 4. _ = wx.GetTranslation
That's a good idea. I will look into this once the code generation is
modified.

Please don't make this mandatory. Let us have a say:

  Translation support: (*) gettext ( ) wx.GetTranslation

Thanks !

But for sure, the website needs to be improved with respect to that.
Your screenshot is lacking the Design and Preview windows. That's why I
suggested to read at least the overview section of the tutorial. Of course,
nowadays the Tree window is the most important one as many things can easier
be edited in the hierarchical view.

Or, rather, the DataViewCtrl ...

Karsten

···

On Fri, Jun 16, 2017 at 12:36:42PM +0200, Dietmar Schwertberger wrote:
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

19

wxglade is "stuff" (for lack of a better word) which wastes your time in an unprecedented way. wxglade never ever produced anything of any value, let alone stuff that works, let alone stuff which actually runs in python and shows a window or frame of any kind.

It is some ridiculous misnomer click tool with the primary goal to produce core dumps which it does for every single py source file it may generate or fail to.

All its frames are invalid. Same applies for the windows which wxglade produces:

wx._core.wxAssertionError: C++ assertion "(m_widget != __null)" failed at
/P/w/wxPython-4.0.0a3/ext/wxWidgets/src/gtk/window.cpp(2974) in DoSetClientSize(): invalid window

wx._core.wxAssertionError: C++ assertion "m_widget" failed at
/P/w/wxPython-4.0.0a3/ext/wxWidgets/src/gtk/toplevel.cpp(1453) in SetTitle(): invalid frame