wxPython versus wxWidgets

[Mojca Miklavec]

On Wed, Aug 14, 2013 at 3:50 AM, Michael Dickens wrote:
> I see in your branch that there is (1) graphics/wxPython-3.0, (2)
> graphics/wxWidgets-3.0, and (3) python/py-wxpython-3.0.  I see that
> you've set the gnuradio port to try to use (1); I know this will not
> work,

Why not? (I don't know gnuradio at all and I didn't test it yet, so
I'm just curious why this wouldn't work [for reasons other than the
confusing name].)

> but I'll correct the issue before it is merged; I appreciate your
> efforts; really.
>
> I have a few questions; please do not take these as critiques; I'm just
> trying to understand & facilitate discussion:
>
> + I see that (3) depends on (1), which is confusing (to me)

It's definitely suboptimal, but it's the best that I came up with so
far. (To me it's also a bit confusing that wxWidgets-python fetches
the sources from wxPython and not from wxWidgets.)

> because (1)
> is actually installing a version of wxWidgets (that provided with
> wxPython, such that the versions always match up if the ports' versions
> are aligned).  wxPython is the Python interface to wx, and that's even
> what the current Portfile for (1) says -- so, if nothing else a
> correction to the description needs to be made for (1).

Correction to the description is definitely needed. I'm just not a
very creative writer, so I copy-pasted to start with (I didn't bother
too much since it didn't affect functionality in any way, but a proper
description is definitely needed to avoid even more confusion).

> + Why is the wxPython-included-wxWidgets port named wxPython instead of
> some variant on wxWidgets?

I'm not saying that this is the best possible decision, so it can
still be changed, but here are some of my thoughts/arguments why I
have chosen it that way:

Yes, wxPython provides just wxWidgets.

1.) But it comes from wxPython sources (currently
$prefix/var/macports/distfiles/wxPython/2.9.4.0/wxPython-src-2.9.4.0.tar.bz2)
and to simplify fetching files from the same source as for
py-wxpython-3.0 I would need to change the distname to wxPython
anyway.

2.) I needed a simple distinct name. Now the different wxWidgets
installations end up in
    ${frameworks_dir}/wxWidgets/Versions/wxGTK/2.8/
    ${frameworks_dir}/wxWidgets/Versions/wxWidgets/2.8/
    ${frameworks_dir}/wxWidgets/Versions/wxWidgets/3.0/
    ${frameworks_dir}/wxWidgets/Versions/wxPython/3.0/
wxgtk is actually "just wxWidgets" as well, it's not GTK (even though
wxGTK is at least consistent, I agree that wxPython is not as
consistent as the rest).

> It does not provided wxPython; it provides
> wxWidgets no matter that the source is from wxPython.  That is also what
> the port "wxWidgets-python" tries to do, with its awkward naming.  I'm
> not saying I have a better naming scheme, but I do not like it being
> called wxPython if is provides wxWidgets.

You say that "wxWidgets-python" is awkward. But what name is left out
there which is not? I'm looking for:
- name of the port
- name inside the "quasi-framework" where the files end up being
installed on disk
- name where wxPython sources are stored
and these can be distinct names if needed.

>  Which takes me to just having
> a wxWidgets port (as in the next item) for installing wxWidgets.
>
> + Is the version of wxWidgets provided inside the wxPython tarball the
> same as that found from wxWidgets directly (for the same version)?

No. wxWidgets is at 2.9.5 and wxPython is at 2.9.4.0.

>  If
> so, then why bother with the special port since wxWidgets is already
> provided elsewhere?

Exactly because it's currently broken and nobody knows when one will
be able to upgrade to the next version of wxPython. I also read from
old tickets in MacPorts that sometimes wxPython did their own
additions on top of wxWidgets, so that the original wxWidgets didn't
actually work as expected with wxPython.

>  Yes, it can result in the current predicament where
> wxPython has not yet caught up to the wxWidgets API.

That.

>  But, it avoids
> adding another conflicting or selectable port to those already there.

The main point is that it is not conflicting any more. While
wxWidgets-python is conflicting with wxWidgets themselves, this was a
huge problem because one could not have both wxWidgets and
wxWidgets-python installed at the same time, and thus also not any of
their dependencies installed together.

But wxWidgets-3.0 and wxPython-3.0 are not conflicting and can happily
coexist. When the last version of wxWidgets in the 3.0 series gets
released, wxPython-3.0 can be removed.

> Fewer ports is generally less confusing.

While this is true in general, my preference would still be to pick
better functionality if I had to choose between smoother
experience/better functionality and less confusion.

If another instance of wxWidgets from wxPython can be installed
without interference and can allow additional freedom with wxWidgets
updates, less confusion alone doesn't seem to justify not adding the
extra port. I'm definitely open to suggestions for a better name, but
I would like to keep two ports.

Mojca