wx question

wxPython Users
1

I am looking into using wxwindows for a gui to develop applications in
Python. The
Apps need to be cross-platform Mac, Windows, Linux. I work
For a bible college and will be developing applications ranging from
online Registration to business office software. My question is what is
your guys Experiences with wxwindows/python? What is the best tool that
is stable I can use? I am looking into using wxDesigner with maybe Wing
or Komodo. What do you guys think?

On the Python list someone mentioned to me that he felt wx was not
stable
Enough on Linux. Is this true?

2

Based on our (limited) experience with wxWindows (actually wxPython),
supporting multiple platforms will involve porting/development work
for each platform.

How much, really depends on the widgets you actually require. Only
the most basic, trivial widgets will work everywhere without special,
platform specific code.

If you use any of the more complex, higher level widgets, you will
end up with things which work on one and not on other platforms.
Those more complex, elaborate widgets are the main strength of
wxWindows, in our opinion*.

If you do require minimal or no porting effort you probably should
look in other graphical toolkits. The choice is limited and depends
on additional requirements, like native 'look and feel', language
support, etc.

Or, you might want to look into developing your applications as web
applications, i.e. server-based applications with web pages as the
user interface.

That is the present situation and over time things may change and
improve, obviously.

/Jean Brouwers
  ProhhICy Semiconductor

PS) The widget set and native look and feel is the main reason why
we decided to use wxWindows on Linux. Our applications work well
and look good on Linux. We tried moving one application to Windows
but ended up cancelling that project, for the reason mentiond above.
If we do need to support Windows and other platforms, we probably
will take the web-based route.

Jason Tesser wrote:

···

I am looking into using wxwindows for a gui to develop applications in
Python. The Apps need to be cross-platform Mac, Windows, Linux. I work
For a bible college and will be developing applications ranging from
online Registration to business office software. My question is what is
your guys Experiences with wxwindows/python? What is the best tool that
is stable I can use? I am looking into using wxDesigner with maybe Wing
or Komodo. What do you guys think?

On the Python list someone mentioned to me that he felt wx was not
stable Enough on Linux. Is this true?

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org

3

Jason Tesser wrote:

>>The Apps need to be cross-platform Mac, Windows, Linux. I work
>> For a bible college and will be developing applications ranging from
>> online Registration to business office software.

wxPython is an excelent choice, though online Registration sounds more lke a web app to me...see below. Python, but not wx is a good choice for that, of course.

>> is stable I can use? I am looking into using wxDesigner

wxDesigner is pretty nice.
>> with maybe Wing or Komodo.

I've always jsut used an editor and command line, but I've heard good things about Wing.

>> On the Python list someone mentioned to me that he felt wx was not
>> stable Enough on Linux. Is this true?

No. wxPython is very stable on Linux and Windows. OS-X is now the weakest link, but it's gotten pretty good lately too.

Jean Brouwers wrote:

Based on our (limited) experience with wxWindows (actually wxPython),
supporting multiple platforms will involve porting/development work
for each platform.

Well yes. wxPython is definately write once, test everywhere.

  > How much, really depends on the widgets you actually require. Only

the most basic, trivial widgets will work everywhere without special,
platform specific code.

I havn't used all of the more complex widgets (wxGrid comes to mind), but I think this is much too strong a statement. In fact, I have NEVER needed "special, platform specific code". While I have found that an approach I used on one platform doesn't always work on others, I have always been able to find a platfrom independent solution to the problem, and it usually is a cleaner/better approach, and one that matches the documented API better.

Those more complex, elaborate widgets are the main strength of
wxWindows, in our opinion*.

Yes, they are, but as the elaborate widgets are written in wxWindows themselves, they're really pretty darn platform independent.

If you do require minimal or no porting effort you probably should
look in other graphical toolkits.

Like what? I've heard good things about QT, so if its licencing requirements suit you, I'd check it out, but I doubt you'll find anything all that much better. TK is the only other option, and really not as good, particularly on OS-X

Or, you might want to look into developing your applications as web
applications, i.e. server-based applications with web pages as the
user interface.

That is a good option, if it fits your needs. However, I'd do it because a thin-client/server approach makes sense for your apps, not because it's easier. Different browsers are different, and I've found the UI development is much harder, as you don't have a stateful intereaction with the client. Granted, I've only started doing web apps, but I'm finding it painful.

Our applications work well
and look good on Linux. We tried moving one application to Windows
but ended up cancelling that project, for the reason mentiond above.

That's probably the source of your problems. There are differences between the platforms, and the sooner you find them the better. If you're going to be supporting multiple platfroms, you need to test early and often. If you take a full-blown app developed on one platform, and try to get it run on another, you're likely to have multiple problems, and you might have made a major commitment to an approach that doesn't work everywhere. If you find that kind of problem early, you can probably choose another approach that does work everywhere you need it to.

Check the archives of this list for similar messages, and take a look at:

http://wiki.wxpython.org/index.cgi/wxPython_20Platform_20Inconsistencies

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

4

A few more comments, interspersed below.

Chris Barker wrote:

> Jason Tesser wrote:
>>The Apps need to be cross-platform Mac, Windows, Linux. I work
>> For a bible college and will be developing applications ranging from
>> online Registration to business office software.

wxPython is an excelent choice, though online Registration sounds more lke a web app to me...see below. Python, but not wx is a good choice for that, of course.

>> is stable I can use? I am looking into using wxDesigner

wxDesigner is pretty nice.
>> with maybe Wing or Komodo.

I've always jsut used an editor and command line, but I've heard good things about Wing.

>> On the Python list someone mentioned to me that he felt wx was not
>> stable Enough on Linux. Is this true?

No. wxPython is very stable on Linux and Windows. OS-X is now the weakest link, but it's gotten pretty good lately too.

Jean Brouwers wrote:

Based on our (limited) experience with wxWindows (actually wxPython),
supporting multiple platforms will involve porting/development work
for each platform.

Well yes. wxPython is definately write once, test everywhere.

> How much, really depends on the widgets you actually require. Only

the most basic, trivial widgets will work everywhere without special,
platform specific code.

I havn't used all of the more complex widgets (wxGrid comes to mind),

wxGrid and wxGridTable are the major ones we use, plus a bunch of trivial
things like menus. Our code was developed on Linux, very basic, without
anything fancy or tricky. Then, after moving to Windows, the code around
wxGrid/Table needed a couple of changes, nothing dramatic since those
worked fine on Linux as well.

But things like menus do not work, at least not yet. No idea why and at
this moment, we're unable to invest more time into that porting project.

Chances are that we have done something incorrectly since as I mentioned,
we have only limited experience with wxPython development.

But the point is that it's all plain wxPython related Python code. We
just expected that to work without having to worry about the underlying
platform. But it doesn't. That was another mistake on our part.

but I think this is much too strong a statement. In fact, I have NEVER needed "special, platform specific code". While I have found that an approach I used on one platform doesn't always work on others, I have always been able to find a platfrom independent solution to the problem, and it usually is a cleaner/better approach, and one that matches the documented API better.

That is another issue with wxPython/Windows, the documentation is
rather cryptic. This is not meant to be critical, our expectations
when we started were different. By far the most helpful part of
wxPython/Windows is this very mailing list!

Those more complex, elaborate widgets are the main strength of
wxWindows, in our opinion*.

Yes, they are, but as the elaborate widgets are written in wxWindows themselves, they're really pretty darn platform independent.

Correct, at least the two we tried are, wxGrid/GridTable.

If you do require minimal or no porting effort you probably should
look in other graphical toolkits.

Like what? I've heard good things about QT, so if its licencing requirements suit you, I'd check it out, but I doubt you'll find anything all that much better. TK is the only other option, and really not as good, particularly on OS-X

We don't have any first hand experience with Qt, but we've seen very
convincing evidence of Qt's portability and 'single-source' capability
across the supported platforms. Licensing is another requirement to
take into consideration.

Or, you might want to look into developing your applications as web
applications, i.e. server-based applications with web pages as the
user interface.

That is a good option, if it fits your needs. However, I'd do it because a thin-client/server approach makes sense for your apps, not because it's easier. Different browsers are different, and I've found the UI development is much harder, as you don't have a stateful intereaction with the client. Granted, I've only started doing web apps, but I'm finding it painful.

Our applications work well
and look good on Linux. We tried moving one application to Windows
but ended up cancelling that project, for the reason mentiond above.

That's probably the source of your problems. There are differences between the platforms, and the sooner you find them the better. If you're going to be supporting multiple platfroms, you need to test early and often. If you take a full-blown app developed on one platform, and try to get it run on another, you're likely to have multiple problems, and you might have made a major commitment to an approach that doesn't work everywhere. If you find that kind of problem early, you can probably choose another approach that does work everywhere you need it to.

You are probably right on this one. Supporting Windows is not (yet)
a critical need for our applications and if it was, we certainly would
revisit this issue. Again, the point is do not expect -like we did,
mistakenly- your wxPython application to work on any platform. It will
take additional time and effort for each platform.

Check the archives of this list for similar messages, and take a look at:

http://wiki.wxpython.org/index.cgi/wxPython_20Platform_20Inconsistencies

-Chris

/Jean

5

I am looking into using wxwindows for a gui to develop applications in
Python. The
Apps need to be cross-platform Mac, Windows, Linux. I work
For a bible college and will be developing applications ranging from
online Registration to business office software. My question is what is
your guys Experiences with wxwindows/python? What is the best tool that
is stable I can use? I am looking into using wxDesigner with maybe Wing
or Komodo. What do you guys think?

I *personally* think the best way to do this would be with a nice
Python-friendly editor and the wx docs close at hand, simply because I think
you'll get more familiar with the idioms of wx and be able to design an app
that will lend itself better to cross-platform use, but I admit I'm a bit of
an IDE primma donna. I have not tried wxDesigner but I have worked with Boa,
and I really didn't like the approach. YMMV, of course.

On the Python list someone mentioned to me that he felt wx was not
stable Enough on Linux. Is this true?

It is true; somebody did indeed say that. (grin)

I think it's more a matter of finding the quirks and avoiding them than
anything else. As to actual stability, I haven't had any problems I would
call "stability" issues on my Mandrake/Gnome system, per se, but to me
"unstable" generally implies something catastrophic :slight_smile: Quirks, yes. But no
more than I've seen from other apps / libraries.

6

Jeff Grimmett wrote:

On the Python list someone mentioned to me that he felt wx was not
stable Enough on Linux. Is this true?
   
It is true; somebody did indeed say that. (grin)

I think it's more a matter of finding the quirks and avoiding them than
anything else. As to actual stability, I haven't had any problems I would
call "stability" issues on my Mandrake/Gnome system, per se, but to me
"unstable" generally implies something catastrophic :slight_smile: Quirks, yes. But no
more than I've seen from other apps / libraries.

This has been my experience as well. Stability is not really a problem; if it runs, it will run well. It's more like you get your app running on one platform and then you bring it to another platform and it runs fine except for one widget. Then you fix it on the second platform (perhaps by substituting another similar widget) and then you test it again on the first platform to see if your change works on the first platform. If it does then you're done. So it's never a show stopper just a little irritation.

Frankly, I would really like the wxWindows team to focus on this problem and ensure that it runs clean everywhere, rather than as someone said earlier "wxPython is write once, test everywhere". wxWindows/wxPython has acquired this reputation (of platform dependent quirks), and the sad thing is that even people on this mailing list grudgingly admit its true.

Bob

7

Bob Klimek wrote:

wxWindows/wxPython has acquired this reputation (of platform dependent quirks), and the sad thing is that even people on this mailing list grudgingly admit its true.

Because it is, though I think it's true for all mutilplatform development. I've certainly heard it about Java, and you'd better be testing your Win32 apps on Win95/98, 2000, XP,...

Is there an option that has significantly fewer of these problems?

Frankly, I would really like the wxWindows team to focus on this problem and ensure that it runs clean everywhere, rather than as someone said earlier "wxPython is write once, test everywhere".

Well, I'm not so sure the issue is a lack of focus on the problem. Perhaps Borland's involvement will make for a little more focus on fixing quirks, and that would be good.

Unfortunatly, most of what causes the problem is that wxWindows wraps the native widgets, rather than re-writing them. This creates a more native app, but makes for inevitable differences on the platforms. The trick is to learn what is platform dependent behaviour, and what is not. An example is that you shouldn't count on the order in which controls are painted and refreshed (see Frank Millman's recent posts). Unfortunately, you usually don't know till you try something, and find it doesn't work the same.

A solution is to do more to document what we discover. Everyone please put stuff on:

http://wiki.wxpython.org/index.cgi/wxPython_20Platform_20Inconsistencies

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

8

Frankly, I would really like the wxWindows team to focus on this problem
and ensure that it runs clean everywhere, rather than as someone said
earlier "wxPython is write once, test everywhere". wxWindows/wxPython
has acquired this reputation (of platform dependent quirks), and the sad
thing is that even people on this mailing list grudgingly admit its true.

Moving forward, I'll be doing a lot of work on modernising the demo, and as
I do so I'll be focusing on both W2K and Linux as test beds. I'm hoping that
we'll be able to use the demo as a QA tool as well, and have designs in that
direction, so with any luck, this will help us expose issues of Linux/Win
compatability.

After all, the biggest hurdle right now is actually /describing/ the issues
accuratly enough so that Robin can find the best solution. I don't think
anyone has a /clear/ understanding of all the issues, and that makes the job
extremely unpleasant.

Naturally, if anyone picks up the ball ahead of me, I will applaud as loud
as anyone :slight_smile:

9

Because it is, though I think it's true for all mutilplatform
development. I've certainly heard it about Java, and you'd better be
testing your Win32 apps on Win95/98, 2000, XP,...

Yeah, there's that as well, excellent point. I know of a number of apps that
have issues just between distros or versions of Win, let alone Linux to Win
to Mac.

  An example is that you shouldn't count on the order in which controls
are painted and refreshed (see Frank Millman's recent posts).

Holy cat, why in the world would anyone /want/ to do that? :slight_smile:

10

Chris Barker said:

Well, I'm not so sure the issue is a lack of focus on the problem...

I agree; I think that the wxWindows team puts a lot of effort into
resolving bugs / platform differences that appear.

I believe, though, that one cause of the continuing issues are that the
development and design of components seems kind of ad-hoc. There aren't
platform-independent architectural plans for what the behavior of any
particular widget, are groups of systems are.

I think this comes down to the development style of the leading contributors.

My point of view comes from work I was doing a year ago. I was trying to
really nail down how components react with sizers, and how components that
change their size during runtime are or should be handled. This was
essentially impossible. This information didn't exist.

IMO, a development process that'd lead to more reliability over time would
be something like:

1. Draft a set of specifications for the windowing system; how it should
work.

2. When widgets on a particular platform don't work, their performance
would be judged against these documents, NOT against the performance of
the widget on other platforms.

3. App developers code to the API spec'd in #1. When a broken widget is
fixed, they can be assured that their code will eventually work without
modification.

I believe that instead of #2 happening, "broken" widgets are fixed to
conform simply to the other platforms, instead of to an API. I remember
seeing messages on the wxWindows development list to the effect of
figuring out how different widgets should function -- all on the fly,
without referencing any design documents. And, essentially deciding by
basically using 'majority wins' - going with the implementations of other
platforms. I think that this causes problems for app developers.

Please don't take my comments as harsh criticism. I see wxPython as the
best app development framework available. I use it for ALL client-side
development. I simply see where, IMO, the process can be improved.

Robb

11

Robert Stuart said:
...

That was me, by the way - I had my email client misconfigured.

Robb Shecter

12

Robert Stuart wrote:

IMO, a development process that'd lead to more reliability over time would
be something like:

1. Draft a set of specifications for the windowing system; how it should
work.

2. When widgets on a particular platform don't work, their performance
would be judged against these documents, NOT against the performance of
the widget on other platforms.

But there's only so much you can do when the underlying widget is out of your hands. If you pick an arbitrary design, you may find you can't make it work on any platform due to the requirements of the existing widget sets. But if you base it on an existing platform's implementation, you can guarantee it works in at least one place and is moderately practical.

The alternative is a lowest-common denominator API that would have to remain very vague so that there was no chance that it could possibly fail on any current or future OS/widget set combination.

···

--
Ben Sizer
http://pages.eidosnet.co.uk/kylotan

13

Ben Sizer said:

But there's only so much you can do when the underlying widget is out of
your hands. If you pick an arbitrary design, you may find you can't make
it work on any platform...

Right. But I don't think that the design should be arbitrary. It should
be done looking at how the current situation is.

But, I think that what's essential is that these design documents must
exist as a thing we can all look at and point to.

So, even where there have been mojority-wins decisions in the past, those
should be encoded somewhere independently.

14

Chris Barker wrote:

> An example is that you shouldn't count on the order in which controls
> are painted and refreshed (see Frank Millman's recent posts).

Jeff Grimmett wrote:

Holy cat, why in the world would anyone /want/ to do that? :slight_smile:

I don't think Chris meant that one would consciously do this. It is rather
that one can get a particular effect working, without realising that
internally it is 'order dependent'. If you then run it on another platform,
you may find that it does not work.

Here is an example that happened to me just the other day.

My standard sequence of events is as follows -
    1. create a frame
    2. create a panel
    3. set up the panel - create sizers, add controls, set focus on the
first control
    4. call a function to check if ok to proceed with frame
    5. either 'show' the frame or 'destroy' the frame, depending on the
result of step 4

This worked fine for me using MSW and GTK2. Then I found that with GTK1, if
I invoke a dialog in step 4, I get various annoying error messages. Robin
explained because the parent of the dialog is the frame, and the frame has
not been shown yet, GTK1 is missing certain information, hence the messages.
One suggested workaround was to 'show' and then 'hide' the frame between
steps 3 and 4. I did this, and it worked.

A while later, I ran my app on MSW, and wondered why I could not get focus
on the first control. It took me a while to work out that the above sequence
of events has an effect on MSW. I set focus in step 3, then show and hide
the frame. By the time I 'officially' show the frame in step 5, for some
reason the focus has disappeared.

Obviously I can find an alternative solution, but it demonstrates how
fragile this cross-platform portability is. Personally I try to test
everything on MSW and GTK1 simultaneously, to uncover any problems as
quickly as possible. I have given up on GTK2 for the time being, due to
printing problems. Heaven help me if anyone decides they want to run my app
on a Mac.

Frank Millman