Peter Damoc wrote:
There was a piggyback ride on the "POLL: wx.DC methods" thread about the
use of IDs
I think it deserves a closer look.
I argued the presence of IDs in the constructors of the wxPython widgets.
Personally I think they are useless and should disappear.
And I showed you a perfectly good reason why they are useful. So we agree
that they are of no use to some people and a lot of use to others. There
is a default value if you don't care: -1
I see them as a backwards compability thing. The way things used to be done. Ok people are still using them BUT I cannot see their value over a more OO aproach (create menus, toolbars and buttons with the same action object)
The remaining problem is how to fix the API. The problem there is that
Python (nor C++ or most other languages) allow you to have arguments
with default values followed by ones without default values. The only
way to get around this would be to re-order the arguments.
> Consequently some of what the underlying systems require will leak
> through into the API for wxWidgets. While it could in theory be
> possible to make wxWidgets work the way you describe, it would become
> horrendously complex under the hood.
complexity can be distributed on several layers.
Yes. That statement doesn't solve the problem though. wxWidgets is
constrained by the underlying systems. No amount of layers takes
that away.
wanna bet? 
take a look at wax or anygui... they manage to hide at least some of the complexity.
> In general wxWidgets supplies default arguments for most things.
> You can supply defaults (-1, "") for some as well.
I shouldn't have to.
It is infrequent. The only case you have come up with is not using
ids, which has only been practically possible in wxPython 2.5.
Feel free to invent a time machine, visit Julian in 1993 and tell him
that using ids is not needed despite all the toolkits he was putting
wxWidgets on top of using them.
wxWidgets and the rest of the toolkits used by wxWidgets are programmed in low level languages like C or C++, they need the IDs, wxPython is Python... and there are some nice features of python that maybe doesn't justify such a strong management.
I respect the work of the people involved in the whole wx effort, I also
think they did a good job BUT I also think that things can be better.
Yes, but change is only worthwhile if there is a benefit from the
disruption. Every widget takes the parent and id as the first
two parameters. Changing the API isn't going to make programmers
more productive other than not having to supply -1 where they
don't care about the id. So you save a few hundred keystrokes.
I don't see that justifying the change.
well, it might not help you BUT it might help a newbie. It might not reduce the size of the code all that much but it will reduce the number of things to worry about, I think it will sharpen the focus on the arguments.
Also note that you are asking for things to be removed, which
takes away functionality other people are already using.
I don't see it as taking away functionality. What use do you see for the parent argument? And if IDs can be replaced by a simpler action mechanism what's the point in using them? Also what I propose is a layer on top of wxpython so if you want to use the old way you still will be able to do it.
I think that most of the people who use wxpython use it because is THE
BEST python GUI toolkit BUT being the best does not mean that it cannot be
improved.
I don't think anyone would disagree with that statement 
Incidentally I use it because it is cross platform (Windows, Linux and Mac)
and includes printing.
Nobody likes their code to break, or to be forced to update to a new
namespace or fix the code so that their scripts work with a new version of
the widgets this is why I think a new namespace is the best approach. It
should be part of the wxpython and it should provide a wrapper for the
wxpython toolkit. It should have a clear, consistent API that would allow
programmers to get the most out of the wxpython with minimum effort.
Go ahead and do it! Put your words into action. You can do this with
(wx)Python already. Look at how Robin did the script that supplied
extra XY methods, as well as wx package renamers. You can make a new
namespace and put in automatic wrappers that do away with the id argument
but supply -1 to the parent class.
there is the wax project, the anygui project and maybe others, as I see it for such an initiative to succed it must have an official bessing, it must be something that the developers of wxpython would recomand to newbies. Such an initiative requires something like an API designer, I don't have enough experience to do this right, sure, I can take let's say the API of Swing and adapt it to the python/wxpython BUT that doesn't guarantees a good result.
Things I would like to see disappear are IDs and the need for a parent at
declaration.
This can be achieved very easy via a "Container", widgets are born
"parentless" and are given a parent when they are placed in the Container.
A LayoutManager mechanism should replace the current Sizers with default
LayoutManagers provided for Containers.
Like I said, use other toolkits first. Your scheme has a huge problem.
What do you do about methods called before items are added to a sizer
(and what if they are never added?) Many people initialise the settings
etc in their widgets before adding them to sizers. You will have to
remember all that, fake answers for things that require an actual widget
to exist (eg calls asking about size or background colour). And then
create the widget later. Again, you do this by writing your own wrappers
without modifying the existing toolkit.
Not really, I think this can be done without faking, maybe via a hidden parent - reparent - repaint mechanism
Incidentally QT also requires a parent object supplied in the constructor
(except for top level items as far as I can tell). They draw their own
widgets so they are not constrained by the underlying gui platform.
Incidentally QT was not writen in/for python.
Adoption of the new API should be voluntary not mandatory (different
namespace).
We could use Wax as a point of departure.
http://zephyrfalcon.org/weblog/arch_Wax.html
We also need someone to drive this subproject.
Ahh, you want everyone else to do your work? Go for it. Python
allows you to very easily wrap up other stuff. Proove your concepts
work.
Wax already proves my concepts (or at least some of them) work. If nobody else volunters... I might give it a try. All I need is a list of guidlines/suggestions and Robin's blessing
···
On Mon, 26 Apr 2004 00:29:08 -0700, Roger Binns <rogerb@rogerbinns.com> wrote:
On Sun, 25 Apr 2004 13:06:52 -0700, Roger Binns <rogerb@rogerbinns.com> >> wrote:
Roger
--
Peter Damoc
Hacker Wannabe
http://www.sigmacore.net/about.html
