wxWidgets again

[Jonathan Stickel]

Mojca

Your efforts to sort this out are appreciated. wxwidgets and wxpython 
are a headache and poorly developed and maintained upstream (IMO).

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. 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. I could be wrong totally wrong, but I suspect this 
is part of the reason you are not receiving much response from Macports 
developers.

Some more comments interspersed below.

Jonathan


On 8/13/13 10:52 , macports-dev-request at lists.macosforge.org wrote:
> Date: Tue, 13 Aug 2013 15:10:27 +0200
> From: Mojca Miklavec<mojca at macports.org>
> To: MacPorts Development<macports-dev at lists.macosforge.org>
> Subject: Re: wxWidgets again
> Message-ID:
> 	<CALBOmsZ1CSfa4ne6VOqFk2aeP5sw1M_P=ZeqWLtMoxDkErVJog at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> since I would like to proceed with testing, I would really be grateful
> for a bit of your help and opition, mainly: how to call the wxWidgets
> variants of ports which depend on wxWidgets and how to properly put
> constraints into the PortGroup?
>
> My idea is the following:
> (1) all dependencies that work with 2.9 should depend on 2.9 only
> (2) all dependencies that only work with 2.8 should depend on 2.8, but:
>    (a) on 10.8 and later and on Xcode 4.4 or later they have to depend
> on wxgtk-2.8
>    (b) on 10.7 with Xcode 4.3 or earlier they can depend on 32-bit carbon
>
> My questions:
> (i) How would you call the port variants?
> (ii) In case of (2b) the port needs to declare things like
>        supported_archs i386 ppc
>        # somewhere in pre-fetch
>        if {${os.major} >= 12 || [vercmp $xcodeversion 4.4] >= 0} {
>            return -code return "won't work"
>        }
> I would like to put this into PortGroup. How?
>
> Thank you,
>      Mojca
>
> On Sun, Aug 11, 2013 at 5:18 PM, Mojca Miklavec wrote:
>> >Hi,
>> >
>> >After some playing with wxWidgets, this is where I managed to come.
>> >Instead of the following ports (each conflicting with each other):
>> >- wxgtk (2.8)
>> >- wxWidgets (2.8)
>> >- wxWidgets-python (2.8, with gtk)
>> >- wxWidgets30 (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!

>> >- wxWidgets-devel (2.9)
>> >
>> >I created a bunch of ports that can be installed independent from each other:
>> >- wxWidgets-2.8 (2.8; with gtk)
>> >    - (planned subport) wxgtk-2.8
>> >- wxWidgets-3.0
>> >- wxPython-3.0
>> >
>> >The port "wxWidgets-python" is not really needed. The only difference
>> >in functionality of the current port is that it provides gtk, but that
>> >can already be provided by wxWidgets-2.8 (or its planned subport
>> >wxgtk-2.8).

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.

>> >
>> >The port wxPython-3.0 is there for one single reason: because releases
>> >of wxWidgets and wxPython are often out-of-sync, but the ports are
>> >otherwise independent.
>> >
>> >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. This is the reason I personally abandoned wx 
backend and started using QT4 for enthought ports.

>> >
>> >I need help with coming up with a slightly better PortGroup, but I
>> >would like to proceed as follows:
>> >- all dependencies that work with 2.9 should depend on 2.9
>> >- all dependencies that only work with 2.8 should depend on 2.8, ...
>> >- BUT: I would like to offer the choice (an extra variant) to allow
>> >the user to switch between 32-bit Carbon variant and possibly 64-bit
>> >or universal GTK/X11 variant of wxWidgets 2.8, so that all these ports
>> >would also compile on OS X >= 10.7
>> >
>> >I tried compiling FileZilla. It compiles fine on 10.7 as 64-bit, but
>> >apparently it ends up with
>> >   /opt/local/bin/filezilla
>> >   /opt/local/bin/fzputtygen
>> >   /opt/local/bin/fzsftp
>> >along with plenty of other files as opposed to FileZilla.app. But at
>> >least it works. Similar "problems" might arise with other ports.
>> >
>> >My question is: how would you call these port variants to switch
>> >between Carbon and GTK/X11 of wxWidgets 2.8?
>> >
>> >Mojca