Re: [wx-dev] future of wxWindows (=wxUniversal)?
Vadim Zeitlin
PAT> Hi! All the recent discussions on where wxWindows is going has got me a
PAT> little nervous about what's going to happen to wxWindows in the coming
PAT> couple of years. Stefan seems to be saying that he's taking wxMac back out
PAT> of the common CVS tree, meaning wxMac is going to be essentially
PAT> incompatible with wxMSW and wxGTK again.
I hope wxMac will also stay in the main cvs. I sincerely hope that Stefan
just meant that he would be maintaining another, less recent and
experimental but more stable version of wxWindows in house, but if he
and/or Gilles were to stop working on "public" wxMac it would, of course,
be a major catastrophe for wxWindows. Once again, I hope that it doesn't
happen.
PAT> But now that's disappearing? And there's some question (at least
PAT> in my mind) about how well wxGTK is going to work with GTK 2.0 and the
PAT> massive changes that seem likely to be required for this.
I'm not the expert here but I don't think the changes are going to be as
massive as this. IMHO they will be concntrated in the low level parts of
wxGTK which are completely invisible to the user code.
PAT> I agree with someone else's comment that wxX11 is probably the way to go for
PAT> unix platforms, skipping GTK completely, since it does seem to be a largely
PAT> redundant layer, and adds another moving target that's out of wxWindows
PAT> developers' control.
But GTK is the de facto standard GUI for Linux which is our second (or
first?) main platform. Of course, if we can't support it (e.g. Robert
decides to stop working on wxWindows), we won't. But if we can, it would be
very nice to continue with it.
PAT> This leads me to the thought: why not move to wxUniversal for *all*
PAT> platforms, and drop the old-fashioned native-API-using ports completely?
Because we aim for providing the native look and feel. This is the
difference between wxWindows and Swing, Tk or Qt. I still believe that our
approach is better, although having wxUniv is very nice for the reasons
I've mentioned many times in the past (simpler ports to new platforms or to
the platforms without native GUI framework, possibility - yet unimplemented
- to use the univ widgets alongside the native ones, having a "reference"
port, ...)
PAT> The
PAT> core wxWin developers seem to be understandably more motivated to work on
PAT> wxUniv anyway, remembering Vadim's comment from a while back that "it's a
PAT> joy to work on wxUniv widgets where we have control, rather than spending so
PAT> much time trying to learn and adapt divergent native API widgets" (apologies
PAT> Vadim, if I'm totally misremembering what you said!).
No, you're right that IMHO it's more fun to write your widgets yourself.
But we will never be able to duplicate the work of GTK+ and MS Windows
teams so wxUniv will never look 100% natively.
PAT> My main goal in using wxWindows has always been to have a solid, functional
PAT> GUI that works on three major platforms (for me - and I understand not for
PAT> everyone - these are Windows, Mac, and Unix). I'm not as concerned about
PAT> having a totally "native" look and feel for each of these;
But for many user-oriented applications it is a big issue.
PAT> I'm more
PAT> interested in real portability and solidity. I think this may be true of
PAT> most people looking to save time and money by using a cross-platform
PAT> library? Otherwise, they'd write in native APIs and shoulder the extra
PAT> expense of porting from one platform to another themselves.
The goal of wxWindows is to provide the native LNF without having to write
this compatibility layer - and I think it's still a good one. IOW, IMHO
having both the native ports and wxUniv is ideal: like this everybody can
choose what he needs. For perfect cross-platform compatibility, use wxUniv.
For native LNF, use the native ports. But if I had to choose between the 2
(luckily I don't!) I'd probably have chosen to keep the native ports at the
very least because it's our niche where we don't compete head to head with
TrollTech who have much more resources than we.
Regards,
VZ
Paul A. Thiessen
it back in the same CVS and see all the wonderful progress of wxMac over the
last year! But now that's disappearing? And there's some question (at least
in my mind) about how well wxGTK is going to work with GTK 2.0 and the
So I'm trying to think about how to tighten the broadening scope of
wxWindows ports in general. Please understand, I don't mean to say that I
have all the answers (or even any!), but I'd like to try to think
constructively about the (re)engineering of wxWindows in general.
I agree with someone else's comment that wxX11 is probably the way to go for
unix platforms, skipping GTK completely, since it does seem to be a largely
redundant layer, and adds another moving target that's out of wxWindows
developers' control.
This leads me to the thought: why not move to wxUniversal for *all*
platforms, and drop the old-fashioned native-API-using ports completely? The
core wxWin developers seem to be understandably more motivated to work on
wxUniv anyway, remembering Vadim's comment from a while back that "it's a
joy to work on wxUniv widgets where we have control, rather than spending so
much time trying to learn and adapt divergent native API widgets" (apologies
Vadim, if I'm totally misremembering what you said!).
Now I realize this is, at the very least, a potentially controversial
notion! :) But wouldn't it be easier to build a focused wxWindows around the
non-GUI (and hence, hopefully, quite portable) core of support classes, with
a wxUniv-style drawing library (along with basic UI handlers for mouse,
keyboard, etc.) for each platform? This way wxWin developers could spend
more time creating nifty wxTools and less time fighting with native API's.
Granted, I suppose there are some flashy features on each platform that will
be missing if native widgets are never used. But these could perhaps be
add-ons, rather than core widgets? I confess my ignorance here about how
wxUniv is structured, whether it's possible to write a wrapper for a native
widget that can adapt it to a wxUniv app. But if there were a way to create
the much-sought-after solid core of wxUniv (done by core wx developers),
while leaving open the possibility of customized expansion into native
widgets (more as contribs from outside), I think this would satisfy a lot of
people.
My main goal in using wxWindows has always been to have a solid, functional
GUI that works on three major platforms (for me - and I understand not for
everyone - these are Windows, Mac, and Unix). I'm not as concerned about
having a totally "native" look and feel for each of these; I'm more
interested in real portability and solidity. I think this may be true of
most people looking to save time and money by using a cross-platform
library? Otherwise, they'd write in native APIs and shoulder the extra
expense of porting from one platform to another themselves.
Anyway, this message is long enough, and after all the recent flame wars,
people are probably tired of long posts to this list. :) I would just like
to propose this as a point of discussion, in an effort to think
constructively about how to address some of the general concerns being
discussed about where wxWindows is heading.
- Paul
--
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Paul A. | NCBI / NIH
Thiessen | thie...@ncbi.nlm.nih.gov
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+