What about wxTNG (was wxQt status)
Peter Most
> we can ever achieve anything I could personally feel proud of (and I know I
> don't speak for everyone here but, well, I do speak for myself) in this
> way. This is why I keep dreaming that some day I'm going to have enough
> time/money to spend several months and finally do something about this.
>
I'm sorry to disappoint you, but this day will probably never come. As I
already wrote, why not try to fix wx *now*? Hasn't 2.9 just been released and
are we now heading towards a 3.0? Then this would be the perfect time to
change some things more 'radically' then usually.
> It's more than a feeling, I know what I'd like to change. I just don't
> know how to do it. To give you some ideas:
>
Well I can only repeat myself: Write it down! Update your wxWiki ideas! Get a
discussion going, otherwise it will never happen!
> 0. Most important by far: API should only provide methods which work.
> I.e. stuff which doesn't work shouldn't compile instead of failing
> (and especially failing _silently_) during run-time. This is very far
> from the current wx design philosophy. I don't know if it's really
> better, but I'd surely like to try working with toolkit in which I could
> be sure that when my code compiles it's going to work as expected on
> all supported platforms.
>
What do you mean exactly? How can you convert runtime errors to compiler
errors?
> 1. Exceptions should be used to indicate errors instead of using return
> codes or IsOk() methods.
>
Why don't we change the policy then, that is it allowed to use exceptions?
IMO this would definitely be a more modern approach.
> 4. Smarter events: this includes the fact that it should be impossible to
> connect to the events which are never triggered as well as possibility
> to avoid generating the events at all until there is a handler for them.
>
See my other post for the non-existent handler, after that I have a better
understanding which control is generating which events and how to prevent
connecting to never triggered events.
Regards Peter
Vadim Zeitlin
PM> I'm sorry to disappoint you, but this day will probably never come. As I
PM> already wrote, why not try to fix wx now?
Because most of the things I want to do are impossible without radical API
changes.
PM> Hasn't 2.9 just been released and are we now heading towards a 3.0?
PM> Then this would be the perfect time to change some things more
PM> 'radically' then usually.
We need to change things not "more radically" but "completely" to achieve
many of my objectives. Once again, there is simply no way to connect the
current wx API to the mooted wxTNG one by any kind of continuous path.
PM> Well I can only repeat myself: Write it down! Update your wxWiki ideas! Get a
PM> discussion going, otherwise it will never happen!
I don't really like to have discussions if nobody has time to work on
implementing them. And so I keep hoping that I do find some time to do
something to have at least some code and not just empty ideas. So far this
hasn't happened though...
PM> > 0. Most important by far: API should only provide methods which work.
PM> > I.e. stuff which doesn't work shouldn't compile instead of failing
PM> > (and especially failing silently) during run-time. This is very far
PM> > from the current wx design philosophy. I don't know if it's really
PM> > better, but I'd surely like to try working with toolkit in which I could
PM> > be sure that when my code compiles it's going to work as expected on
PM> > all supported platforms.
PM> >
PM> What do you mean exactly? How can you convert runtime errors to compiler
PM> errors?
You don't, of course. You just don't allow calling the functions which
don't make sense by not providing them. And there are *plenty* of things
which you may do at wx API level which are never going to work. In addition
to the previously mentioned examples consider painting over a native
control: this is something that people happily do under MSW where it may
even work sometimes. But it never works under GTK. My solution would be to
not allow to bind to EVT_PAINT on arbitrary widgets at all but only do it
for some Canvas widget which is meant to be used for this. Of course,
people would still be able to do what they want under MSW by going through
the current wx API if they wish. But at least they will know they're doing
something not supported.
PM> > 1. Exceptions should be used to indicate errors instead of using return
PM> > codes or IsOk() methods.
PM> >
PM> Why don't we change the policy then, that is it allowed to use exceptions?
Because current code is not exception safe. I'm trying to change it here
and there but we'll probably never succeed with it. OTOH it seems possible
to through exceptions from outside of current wx code if we take care to
write the wrappers themselves to be exception safe.
Regards,
VZ
Peter Most
> Because most of the things I want to do are impossible without radical
> API
> changes.
> We need to change things not "more radically" but "completely" to achieve
> many of my objectives. Once again, there is simply no way to connect the
> current wx API to the mooted wxTNG one by any kind of continuous path.
>
This is something I simply cannot believe and we will never know if you don't write it down. It is always possible to refactor code into a new kind of API. Not all at once, of course, but step by step.
> I don't really like to have discussions if nobody has time to work on
> implementing them. And so I keep hoping that I do find some time to do
> something to have at least some code and not just empty ideas. So far this
> hasn't happened though...
>
How do you know that there is nobody who wants to implement it?
Take me for example: When I read the typesafe event proposal from Brian and it was not rejected because of the template usage, then I thought "great finally they (wx) accept a more modern approach" and so I made my proposal and joined the effort.
I might not be the typical case, because I wanted to join wxWidgets for a long time, but the point is, that maybe the ideas for wxTNG might attract new developers who are just waiting for a chance to modernize wxWidgets.
So again: As long as you or your co-main-developer don't write down your "vision" or "ideas" then there will never be any change and wxTNG will never be more than vapor ware!
And as a last point: I don't have any data to support this, but now that QT has been LGPLed, it might attract more developers and so now might be a good time to seriously think about a more "modern" wxWidgets.
Regards Peter
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Vadim Zeitlin
PM> > We need to change things not "more radically" but "completely" to achieve
PM> > many of my objectives. Once again, there is simply no way to connect the
PM> > current wx API to the mooted wxTNG one by any kind of continuous path.
PM> >
PM> This is something I simply cannot believe and we will never know if you
PM> don't write it down. It is always possible to refactor code into a new
PM> kind of API. Not all at once, of course, but step by step.
I don't know what kind of a proof would you like but you clearly can't
make the current wxWindow same as Widget in wxTNG because it's used in
different roles (see http://trac.wxwidgets.org/wiki/wxTNG/WindowHierarchy).
Here alone wxTNG is completely incompatible with current wx API.
PM> > I don't really like to have discussions if nobody has time to work on
PM> > implementing them. And so I keep hoping that I do find some time to do
PM> > something to have at least some code and not just empty ideas. So far this
PM> > hasn't happened though...
PM> >
PM> How do you know that there is nobody who wants to implement it?
Ok, I'm not certain about this but it does look rather unlikely.
PM> So again: As long as you or your co-main-developer don't write down
PM> your "vision" or "ideas" then there will never be any change and wxTNG
PM> will never be more than vapor ware!
As I said, I'm trying to but this is not simple, you need time to do even
the design part, not just for writing it (which can actually be rather
simple if the design was done well).
PM> And as a last point: I don't have any data to support this, but now
PM> that QT has been LGPLed, it might attract more developers and so now
PM> might be a good time to seriously think about a more "modern"
PM> wxWidgets.
My idea is that providing a new, clean and nice C++ API which could be
implemented using either wx or Qt as backend would be much more interesting
now that Qt is LGPL.
Regards,
VZ
Julian Smart
> I don't know what kind of a proof would you like but you clearly can't
> make the current wxWindow same as Widget in wxTNG because it's used in
> different roles (see http://trac.wxwidgets.org/wiki/wxTNG/WindowHierarchy).
> Here alone wxTNG is completely incompatible with current wx API.
>
always enjoyed thinking about any kind of window as a window, and having
to prise apart my model of windows so top-level windows are quite
different from child windows, and composite widgets are a different
beast again, doesn't seem intuitive or elegant. Whether a window is
going to contain other windows can be something that is not fixed in
advance - the roles can and should be interchangeable. For example,
create a new tab in a browser-type app. Without any content, it might
just paint a message like a control. Now when you fill it with content,
it becomes a container. OK, so in this case you could put a message in
the composite control but I don't see the need to restrict the way
controls work. I have windows in my apps that for the most part paint
their own content but can also contain transient controls e.g. a label
editor.
I also think trying to expose the implementation of native versus
non-native controls is strange and unnecessary. One of the nice things
about wxWidgets is that this distinction is an implementation detail and
may indeed change from one platform to the next. It's surely about
hiding the details. So what if you can't always intercept native event
processing or painting - all you have to do is document the
restrictions. And indeed in some cases, such as wxTextCtrl, you _can_
intercept events for native controls, where supported.
So if this is going to be a central pillar of wxTNG, then I'm most
definitely staying with old-style wxWidgets even if wxTNG ever
happens... apart from the fact I really don't want to rewrite literally
100s of 1000s of lines of code for dubious benefit. I might as well just
start goat farming, since the porting effort would wreck my business,
motivation and any shred of creativity I might have had. Sorry...
improvements and evolution: yes. Completely new toolkit: I just don't
see the benefits ever outweighing the pain for all concerned. It'll
simply divert attention and energy that we can't afford to waste.
My 2c, anyhoo...
Julian
Vadim Zeitlin
JS> Vadim Zeitlin wrote:
JS> > I don't know what kind of a proof would you like but you clearly can't
JS> > make the current wxWindow same as Widget in wxTNG because it's used in
JS> > different roles (see http://trac.wxwidgets.org/wiki/wxTNG/WindowHierarchy).
JS> > Here alone wxTNG is completely incompatible with current wx API.
JS> >
JS> I don't see a lot of advantage to the new distinctions made here.
I know. This is why you designed the original API this way. And I respect
your opinion. But personally I think it's wrong to provide possibility to
do something which makes no sense in the API and the current API makes it
all too easy.
It's like the difference between static and dynamic typing. There is no
right and wrong here but I prefer static if possible. And, C++ being a
static typed language, I think it would be better to use strict statically
typed API for C++ GUI framework.
Maybe it's obvious to you that you can't create children of wxButton. Or
that it's a bad idea to create more than one window directly in a wxFrame.
But it's clearly (as documented by wx-users archives from many years past)
not so obvious to everyone. I'd prefer if the API didn't allow doing this
(and about 367,417 other things) to begin with.
JS> For example, create a new tab in a browser-type app.
...
This example can be implemented using the proposed hierarchy. Except that
you'd need an extra window into this tab. Is it really a problem? If this
is all the price to pay for a better API I'd do it gladly.
JS> So what if you can't always intercept native event processing or
JS> painting - all you have to do is document the restrictions.
Just as we always did...
JS> So if this is going to be a central pillar of wxTNG, then I'm most
JS> definitely staying with old-style wxWidgets even if wxTNG ever
JS> happens...
The nice thing is that you (and many others, who will undoubtedly stick to
the current API because of the existing code using it) will be perfectly
able to. And you would even be able to start using (parts of) wxTNG API
(that you like) while still continuing to use it too. This is the most
important part of the plan and what really distinguishes wxTNG from just
some other new C++ GUI framework.
JS> apart from the fact I really don't want to rewrite literally
JS> 100s of 1000s of lines of code for dubious benefit. I might as well just
JS> start goat farming, since the porting effort would wreck my business,
JS> motivation and any shred of creativity I might have had. Sorry...
JS> improvements and evolution: yes. Completely new toolkit: I just don't
JS> see the benefits ever outweighing the pain for all concerned. It'll
JS> simply divert attention and energy that we can't afford to waste.
I understand you and I am quite sure I'm not going to be able to change
your mind whatever I say so I won't try very hard. All I will say is that
this is the best plan I have to adjust wx to the evolution of the C++
programming during 15 years since wx was started. And, as I mentioned
previously, by opening the door to writing other backends for wxTNG API you
could actually attract new people to wx development -- because believe me,
few C++ programmers are going to be attracted to the existing wx API.
Also, personally, I have more and more trouble convincing myself to spend
(no, it's not waste...) energy on current wx code base. It's difficult to
motivate oneself to work on something which seems to have an endless supply
of not just bugs (they will always happen) but also API decisions which
simply can't be justified. Especially when even the latest additions use
so, let me be polite here, questionable design. I'd like to continue
working on wx but I need to have something to look forward to, too, it's
just too depressing otherwise.
Regards,
VZ
Vaclav Slavik
> I know. This is why you designed the original API this way. And I
> respect your opinion. But personally I think it's wrong
Not only it's wrong in principle, it's visibly harmful. That is, if
somewhat passable so-so nativeness is not good enough for you. Maybe
Julian will disagree too, but it isn't good enough for me -- that's why
I don't use Qt yet.
wxGTK had (and I bet still has) more than one subtle breakage of native
behavior thanks to futile attempts at implementing the
impossible-to-implement wx API. For example, input methods handling used
to be totally broken due to the attempts to intercept keyboard events in
native controls. This was eventually fixed, but only at the cost of lot
of necessarily ugly code.
Vaclav