wxWidgets again

[Mojca Miklavec]

On Tue, Aug 13, 2013 at 7:35 PM, Jonathan Stickel wrote:
> Mojca
>
> Your efforts to sort this out are appreciated. wxwidgets and wxpython are a
> headache and poorly developed and maintained upstream (IMO).

Agreed ;)

> I am the maintainer for several enthought ports that depend on wx or QT4
> (py-pyface being most relevant). Historically, Enthought's support for wx
> was better than for QT4, but with wx-2.8 not working with 64-bit
> architecture, that has changed. Therefor, QT4 now seems to be the preferred
> backend:
>
> https://support.enthought.com/entries/22601196-wxPython
>
> For py-pyface, I make pyqt4 the default variant and wx is there as an option
> should anyone want to use it on 32-bit systems. However, I have not tested
> nor plan to test the wx variant, and so I have no idea if it even works.

So ... a tiny request, see below.

> My
> point is this:  because of the trouble with wx, I expect that it will slowly
> fade away. Projects that use it will start to use alternative backends.

This might be true for your ports, but probably not in general. I
don't expect a Qt version of Poedit to ever get released. Come on ...
even Google is building services on top of wxWidgets 2.9.

> Despite what is stated on the wxWidgets website, I doubt that 3.0 will be
> available soon. As even stated on the wxWidgets roadmap, it has been 7 years
> since the release of stable 2.8!

It probably won't be released next month, but I expect it in, say, a
year from now. Am I being too optimistic?

> I created wxWidgets-python precisely for the reason mentioned next: versions
> of wxWidgets and wxPython are often out-of-sync. This can be a huge problem
> and needs to be dealt with carefully. It boggles my mind why the developers
> of wxPython think it is OK to do this.

Yes, this is why I kept a separate port wxPython-3.0, but only for
2.9. (I don't ever expect any wxPython 2.8.13.0.)

>>> >The port wxgtk can go and can be replaced with a subport of
>>> >wxWidgets-2.8. I managed to compile wxWidgets also with a flag
>>> >--enable-graphics_ctx and if it's compiled with GTK2/X11, it can
>>> >easily be compiled on any Mac OS X, also as 64-bit, not just on 10.6
>>> >and lower as 32-bit. I tried compiling with GTK2/Quartz, but I believe
>>> >that more work would be needed to get there since wxWidgets make some
>>> >weird assumptions (just as an example: even when compiling with GTK on
>>> >Mac, wxWidgets don't add OpenGL flags from mesa, assuming that those
>>> >are not needed).
>
> It seems that no one really wants X11 as part of a backend when there should
> be alternatives.

Except when you need to choose between 32-bit Carbon and X11. Then X11
might be the only option.

(Getting GTK2/Quartz to work might be a huge challenge and I'm not
ready to go there at the moment. It probably works with wxWidgets 2.9,
but with 2.8 it seems like another can of worms.)

> This is the reason I personally abandoned wx backend and
> started using QT4 for enthought ports.

If Qt4 works better than xw anyway, I have a slightly "selfish"
request: would it be possible to remove the wxWidgets variant from
these ports altogether? (Or, if you want, you could add the variant
back after wxWidgets mess is cleaned up.)

The reason is that every single ports that depends on wxWidgets needs
to be carefully adapted and tested. I know that pyface compiles with
wxPython 2.9, but I also know that I had no clue how to even start it
to see whether it works. And if not even the maintainer is willing to
test the wxWidgets variant, it's probably better if it gets removed
altogether.

Every single port that gets rid of the dependency spares a ton of work
during "making sure that all wx ports still work" phase ;) ;) ;)

Thanks,
    Mojca