[python-win32] Possible future direction for PyGUI on Win32

[Octavian Rasnita]

From: "Greg Ewing" <greg.ewing at canterbury.ac.nz>
> Octavian Rasnita wrote:
>> From: "Greg Ewing" <greg.ewing at canterbury.ac.nz>
>>
>>> No, if I go this way, I would probably stop maintaining
>>> the current implementation.
>>
>> Oh, in that case imho I think this is a very bad idea.
>
> Can you elaborate on exactly what is bad about it, and
> suggest an alternative?

Windows Forms - based apps have a few disadvantages:
- First, the most important, and with no solution is that Win32 GUI widgets 
are much fast responsive than Windows Forms, and it is annoying to use 
Windows Forms - based apps with the keyboard;
- Second, it is harder to create executables that include the support for 
DotNet, because it is not sure that DotNet is available. The package should 
be either very big and include DotNet, or it should detect if it is not 
present and offer the possibility of downloading it from the web, but some 
computers are not connected to the internet...;
- Windows Forms offer very many accessibility features for screen readers, 
however this GUI is *always* less accessible than the standard Win32 widgets 
for those who need to use a screen reader.
- I think there are solutions for making Windows Forms - based apps already, 
and they can be used if somebody prefers to use this GUI, so it wouldn't be 
a good idea to dupplicate it and offer the same interface.

>
> The standard Windows GUI API is severely crippled compared
> to what is available natively in Cocoa and Gtk. The only
> alternatives I see at the moment are:
>
> * Allow Windows to hold back the development of PyGUI on
> all the other platforms.
>
> * Implement the missing functionality on Windows in pure
> Python -- a lot of work, and probably not practical for
> something complex such as a rich text or HTML widget.
>
> * Rely on a third party library to supply the missing
> functionality on Windows.
>
> -- 
> Greg



I don't know which of these ways would be the most simple to implement, but 
it is true that it will be more difficult, because I've seen how these 
problems were solved in other GUIs like wxWIDGETS and SWT.

wxWIDGETS offers custom widgets for those which are not offered by the 
standard Win32 API, but most of them are badly made with no corresponding 
accessibility features, and if those widgets are used in an application, 
they could steal the focus or make other problems that make the whole 
application not accessible for those who use a screen reader.
So a better solution than the one offered by wxWIDGETS would mean much more 
work.

In SWT, as far as I know, those widgets which are not offered by the Win32 
API are not offered at all, but I am not sure, so others who may know more 
can comment. But if this is true, this is not an extraordinary solution 
either.

However, I don't know if the focus should be to offer all the possible 
widget types under all platforms, because now there are more and more 
platforms considered, like different kind of PDAs and mobile phones, and it 
would probably be very hard or impossible to offer a GUI that can do 
everything everywhere.

Octavian