cold shower request

Vladimir_Ignatov · November 7, 2005, 1:01pm

Hi,

Situation is like this: I like python I like it very much and IMHO there
is still room for a python GUI toolkit. It seams to me that all available
toolkits have something wrong, you cannot pick a clear winner and altho I
really like wxPython I think it has a lot of problems.

I feel exactly the same.

... <another gui proposal>

Is it feasible? Could it be done?

Don't do it. Put your money on hold. Set down, cold down and think a little.
At least for 30 day trial period

What do you think?

I think the world do not needed another "ordinal" GUI. That the IDEA will be
behind of you GUI? That is the _key difference_? New names for a classes?
New prefix instead "wx"?

I think that improvement of wx is much more worthily.

Well, if you decide to born another GUI, then here is (my) list of key
features for it:

1) Standad unittest suite
2) Standad unittest suite
3) Standad unittest suite
4) Sizers or such.
5) Do not take control over "main" ("main" should reside in application
code, not inside framework).
6) "Free-style" events binding (bind events to any free or member function)
[as opposite to use overloading]
7) Provide access to "platform-dependent" handles (like hwnd, hdc).

That is all. Hope you choose the right option and support wx development
instead splitting the world even more.

Vladimir Ignatov
www.colorpilot.com

Peter_Damoc1 · November 7, 2005, 1:49pm

[...]

Don't do it. Put your money on hold. Set down, cold down and think a little.
At least for 30 day trial period

I have until January to think I promised myself I won't do anything by 1st of January, anything but documentation I mean

What do you think?

I think the world do not needed another "ordinal" GUI. That the IDEA will be
behind of you GUI? That is the _key difference_? New names for a classes?
New prefix instead "wx"?

well... not exactly, why I dream about is more like QT without all the classes that are already provided by the python distribution, a pure GUI library if you want.

I think that improvement of wx is much more worthily.

Well, if you decide to born another GUI, then here is (my) list of key
features for it:

1) Standad unittest suite
2) Standad unittest suite
3) Standad unittest suite

I agree that unittests should be part of the toolkit BUT they might not be trivial to implement and be relevant... implementing a unittest for a refresh issue for example might be a tricky part.

4) Sizers or such.

absolute positioning and standard boxes (VBox, HBox) should be there from the start... more complex layout mechanisms are not a priority.

5) Do not take control over "main" ("main" should reside in application
code, not inside framework).

this is definitely one feature pythoneers would love, create the main event loop in another thread and open a line of communication to that loop so you could push commands into that event loop

6) "Free-style" events binding (bind events to any free or member function)
[as opposite to use overloading]

of course

7) Provide access to "platform-dependent" handles (like hwnd, hdc).

That is all. Hope you choose the right option and support wx development
instead splitting the world even more.

I won't support wx devel, I will either do something different or do nothing at all.
I don't want to split the world, I want to give people options. If I do something that would convince developers to leave wx for my project... maybe I'm doing something right, maybe it would be worthed to switch.

···

On Mon, 07 Nov 2005 15:01:48 +0200, Vladimir Ignatov <100xcd@100xcd.com> wrote:

Grant · November 7, 2005, 4:22pm

I think the world do not needed another "ordinal" GUI. That the IDEA will be
behind of you GUI? That is the _key difference_? New names for a classes?
New prefix instead "wx"?

IMO, wx is just too low-level -- and it's not very "Pythonic".

If you want to see a good example of a high-level language with
a GUI toolkit, take a look at STk <http://kaolin.essi.fr/STk/>\.

When I was comparing the two, an equivalent task takes about
twice as many lines of code in wxPython as it does in STk. The
difference is due not to the language, but to the low level and
loose integration of wx. In Stk, you can do things like attach
a variable to a widget just like you would a handler. When the
variable's value changes the widget reflects that chagne. When
the user changes the widget, the variable's value changes. You
don't have to spend all your time shovelling data back and
forth between the programs data structures and the widgets by
calling get/set methods.

Tk integration with Python is also rather loose (yes, I
understand why), and has many of the same issues that wxPython
has.

I think that improvement of wx is much more worthily.

Probably.

There are people working on higher level wrappers for wxPython
(e.g. Wax). These packages hide some of the nasty low-level
wxWidgets stuff, but they're still in-progress.

That is all. Hope you choose the right option and support wx
development instead splitting the world even more.

wx is in need of some basic improvement like being able to pass
a callble to a button class contructor rather than having to do
bindings in a separate step. Having a class that can't create
a useful instance in a single call is just silly.

···

On 2005-11-07, Vladimir Ignatov <100xcd@100xcd.com> wrote:

--
Grant Edwards grante Yow! It's the land of
at DONNY AND MARIE as promised
visi.com in TV GUIDE!

Peter_Decker · November 7, 2005, 6:30pm

data -> widget is easy with proper and liberal use of properties. With
a bit of work, you can generate a set of automatic wrappers to handle
the widget -> data transfer. Want to combine them all together? Well,
hack a custom metaclass and you can use a Python class/subclass to
handle the automatic wrapping, set up your event handlers, etc.

While I don't use the database stuff, Dabo comes with data binding
built into all controls. And they use a 3-tier approach, so that your
UI and database are kept separate by a business object layer.

Why hasn't such a thing been done yet? I don't know. Maybe someone
hasn't tried to do such a thing yet.

It's been done; see above.

[1] I really don't like the idea of using...

wx.XYZ(..., handlers={wx.EVT_TEXT:self.OnText,
wx.EVT_TEXT_ENTER:self.OnEnter,...})
or
wx.XYZ(..., handlers=[(wx.EVT_TEXT,self.OnText),
(wx.EVT_TEXT_ENTER,self.OnEnter),...])

Seems like a wart to me.

It's a big, ugly wart. Dabo features auto-binding of methods to events
by simply naming the method 'onXXX', where 'XXX' is the name of the
event (you can turn that off if you want). And it doesn't use the wx
events and their UGLY_UPPERCASE_NAMES, either; Dabo events are
normal-case and simply named. So if you want to fire an action when a
control loses focus, just give it an 'onLostFocus(self, evt):' method,
and it just works.

···

On 11/7/05, Josiah Carlson <jcarlson@uci.edu> wrote:

--

# p.d.

Josiah_Carlson · November 7, 2005, 7:03pm

> data -> widget is easy with proper and liberal use of properties. With
> a bit of work, you can generate a set of automatic wrappers to handle
> the widget -> data transfer. Want to combine them all together? Well,
> hack a custom metaclass and you can use a Python class/subclass to
> handle the automatic wrapping, set up your event handlers, etc.

While I don't use the database stuff, Dabo comes with data binding
built into all controls. And they use a 3-tier approach, so that your
UI and database are kept separate by a business object layer.

Heck, I wasn't even talking about database binding, I was talking about
obj.attr = value updating a control's value via SetValue(), and vv.

> [1] I really don't like the idea of using...
>
> wx.XYZ(..., handlers={wx.EVT_TEXT:self.OnText,
> wx.EVT_TEXT_ENTER:self.OnEnter,...})
> or
> wx.XYZ(..., handlers=[(wx.EVT_TEXT,self.OnText),
> (wx.EVT_TEXT_ENTER,self.OnEnter),...])
>
> Seems like a wart to me.

It's a big, ugly wart. Dabo features auto-binding of methods to events
by simply naming the method 'onXXX', where 'XXX' is the name of the
event (you can turn that off if you want). And it doesn't use the wx
events and their UGLY_UPPERCASE_NAMES, either; Dabo events are
normal-case and simply named. So if you want to fire an action when a
control loses focus, just give it an 'onLostFocus(self, evt):' method,
and it just works.

Nice and convenient, though easily done with a prebinding of all
possible events on an object, or a generation of events based on the
names of methods during class instantiation.

I went to the Dabo page earlier, if only to see actual code (having
never used Visual FoxPro), and in navigating the most obvious places, I
was unable to discover any sample code snippets. It's probably in the
download, but I shouldn't have to download an entire project just to see
some code snippets. I certainly hope that Dabo gets bigger, if only
because they might then get decent documentation.

- Josiah

···

Peter Decker <pydecker@gmail.com> wrote:

On 11/7/05, Josiah Carlson <jcarlson@uci.edu> wrote:

Josiah_Carlson · November 8, 2005, 7:49am

Monday, November 7, 2005, 3:30:39 PM, Peter Decker wrote:

> (...)
> It's a big, ugly wart. Dabo features auto-binding of methods to
> events by simply naming the method 'onXXX', where 'XXX' is the name
> of the event (you can turn that off if you want). And it doesn't use
> the wx events and their UGLY_UPPERCASE_NAMES, either; Dabo events
> are normal-case and simply named. So if you want to fire an action
> when a control loses focus, just give it an 'onLostFocus(self,
> evt):' method, and it just works.

Any reason why these features are not part of the standard wxPython
distribution?

I would imagine that it is partially caused by the fact that the
majority of wxPython is generated by SWIG, and probably resulting from
no one actually taking the time to make wrap everything manually before
for inclusion in the later mentioned "metaclasses" directory.

I mean, why can't we just grab the nice features of Dabo and maybe
other projects around, create some "metaclasses" directory and put
some samples of them on the wxPython demo?

Maybe 'import wx.dabo as wxd'? While people should be generating
standard wxPython bindings for general use (for use in Boa, etc.),
another group could be generating Pythoninc bindings for as many base
and custom wx classes as absolutely possible. Heck, to guarantee
interoperability, custom classes should be required to be a standard
wxPython style class with optional (but recommended) metaclass bindings.

- Josiah

···

"E. A. Tacao" <e.a.tacao@estadao.com.br> wrote: