[wxPython-dev] Using AUI in the demo

Thu May 10 11:11:09 PDT 2007

Hi Andrea,

On May 10, 2007, at 3:22 AM, Andrea Gavana wrote:

> Hi Kevin and All,
>
>> Let me give you a quick example. To fix the accessibility issues
>> Rafael Bejarano raised (i.e. VoiceOver support on Mac) for
>> CustomTreeCtrl, someone would have to craft a cross-platform wx
>> accessibility API at the C++ level, go on wx-dev and iron it out,
>> then implement it on Win/Mac/Linux, and then modify CustomTreeCtrl to
>> use that accessibility API. Unless you or someone else volunteers for
>> that effort, that leaves us with two options - forget about
>> accessibility support, or use native controls, which mostly have
>> support built-in or can be quickly fixed because we can access the
>> underlying native control events/APIs from C++.
>
> as long as I will be using wxPython (and that will be forever, as for
> me a superior GUI toolkit doesn't exist yet), I volunteer to make
> whatever modification to keep it updated. CustomTreeCtrl is one of my
> children, and I contributed it to the community because *I* thought it
> would have been useful. The fact that a lot of users have switched
> from wx.TreeCtrl to CustomTreeCtrl is a measure of its usefulness.
> Moreover, as far as wxWidgets is concerned, on GTK and Mac
> CustomTreeCtrl *is* the native tree control. Mac and GTK are using the
> generic implementation of wx.TreeCtrl, that means CustomTreeCtrl
> without the whistles and bells I attached. I am sure Mac and GTK have
> their own native implementation, but the fact that wxWidgets is not
> wrapping them means only that the generic one is good enough on those
> platforms.

Have you considered that maybe it's because we don't have anyone with  
both the skills and time to implement wx.TreeCtrl natively? I think  
most people on wx-devs would be ecstatic if someone came along with a  
native wx.TreeCtrl for GTK and OS X.

> So, if that is good enough, I don't see why wxAUI should
> not be good enough also on Mac.

It's good enough in the sense that "it's not native and has a foreign  
(read: Windows) way of handling UI panes, but we don't have anything  
better and some apps need this."  Again, I doubt any AUI devs will  
gripe if someone comes along and modifies the impl. to work more  
natively on Mac, nor do I think they would argue it can't be made  
more native on Mac.

It's just that it happens to be a fair amount of work to do, and  
again, no one has done it yet. Until someone does it, though, AUI for  
Mac really won't go beyond "passable, if you need it" rather than  
"modern, Mac-like UI."

>> Well, I think AUI looks less native on Mac and works in a fairly non-
>> intuitive manner compared to native apps. I think some of it could be
>> fixed, but I still think it would be awkward on Mac,
>
> Maybe, but I don't remember many objections when wxAUI was proposed to
> be included in wxWidgets. If wxAUI didn't exist, then it would have
> been wxIFM, but the result would have been the same. Noting how
> selective Vadim and wx-dev crew are in adding or modifying something,
> the fact that wxAUI was included in wxWidgets on *all* platforms is
> another confirmation of my way of thinking. Then we can argue as much
> as you want about non-nativeness on Mac, but wxAUI will still be
> there.

Be it with MDI, wxDocView or AUI, they all are rather Windows-centric  
(and Linux-centric in that it uses a Windows-like way of managing  
windows), but they got added and weren't removed because lots of  
Windows and Linux app developers could use them. In the end, its up  
to the developer to decide whether to ignore Mac, just do a quick  
port, or get it right. I just think "get it right" is the choice we  
should make for the demo.

>> and moreover, I think 2.8.4 should not be held back by it in order  
>> to increase our
>> chances of getting the wx updates into Leopard.
>
> Ok, it looks like I am the only one that likes the new demo interface.
> No problem about that, I believe it's better if Robin will put back
> the old one and we forget about the new one. I don't really care, it
> was just my way to respond to a comment Robin made in the demo:
>
> # UI Interface more modern?
>
> It seems to me it looks like that, but maybe my sense of "modern" is a
> bit screwed up :-D. I'll think twice the next time I feel something is
> going to look better before proposing it.

Well, let me say I do appreciate all your help and if you think  
otherwise, then I gave you the wrong impression. Still, I think your  
viewpoint (and accordingly, the demo) is very Windows-centric, which  
is certainly understandable, but what I don't understand is that you  
refuse to acknowledge that point. Instead, you will argue "it must be  
this way on Mac, because of what wx does here or there" and that is  
good enough for you to think you understand how Mac should work or  
how to create a solid Mac interface.

Some might argue I'm picky, and I'd certainly agree, and I suspect it  
annoys more than a couple people. ;-) But have you read the Mac HIGs?  
Apple is picky, and so are a lot of Mac developers. I don't think  
wxPython should settle for "good enough" on any platform if it is  
really to gain new users and succeed. Considering that Macs are  
experiencing 3 times the growth rate in sales as PCs are, I think we  
really ought to take the Mac market, and its approach, seriously and  
try not to compete for 2nd or 3rd place in quality toolkits to  
develop for.

Regards,

Kevin

> Andrea.
>
> "Imagination Is The Only Weapon In The War Against Reality."
> http://xoomer.virgilio.it/infinity77/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wxPython-dev-unsubscribe at lists.wxwidgets.org
> For additional commands, e-mail: wxPython-dev-help at lists.wxwidgets.org
>