Re: Roadmap
Vadim Zeitlin
DO> 1) Is there a (more or less) official roadmap for the future of wxWidgets
Not really. There are plans but calling them a roadmap would imply
assigning schedule to implementing them and currently we don't really have
it.
DO> 2) I've read a lot about upcoming Version 3 that includes Unicode but when
DO> looking at the documentation Unicode is already supported as a build option.
DO> Could someone help me to better understand?
wx 2.8 can be built in either ANSI or Unicode version. The main change in
wx 3.0 is that it will have only one build which will use Unicode
internally but provide API compatible with both the existing ANSI and
Unicode versions. This is very important for us as it reduces the number of
builds/packages (in addition to ANSI/Unicode there is also debug/release,
STL/non-STL, ...) and it's also important for wx users who didn't use
Unicode build of wx before because they unable to switch to wchar_t strings
everywhere.
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
Dieter Oberkofler
ad 1) I understand. What would be the closest to a roadmap the project
currently has? Based on what "information" is the current development (there
is a lot of changes going on the trunk) triggered?
ad 2) Is there a documentation (any kind) of what is planned for version 3?
Will there be major API changes and are they known? Is there "any" schedule
for when version 3 might be ready?
I have continued with my testing and would have a few new questions:
3) I'm trying to understand the differences between the top-level Window
classes and especially between CFrame and CDialog. It seems as CFrame would
best fit our typical dialog classes as we typically use a Status Bar and
Toolbar. ON the other hand only CDialog has the modality features. What
would be the way to go if someone needs mixed features from each of those
two classes?
4) The typical event handling in wxWidgets seems to be static and
macro-based but according to the documentation it is also possible to
dynamically link events to a function. I have a hard time to understand how
this works and was not able to find a good example. Let's for example say
that I have a wxButton that should send it events to a function
OnButtonPressed and I would like to setup this event relationship at
runtime. Is there any good documentation or example on how to do so?
Thank you,
Dieter
-----Original Message-----
From: wx-users...@lists.wxwidgets.org
[mailto:wx-users...@lists.wxwidgets.org] On Behalf Of Vadim Zeitlin
Sent: Saturday, November 29, 2008 13:48
To: wx-u...@lists.wxwidgets.org
Subject: Re: Roadmap
On Sat, 29 Nov 2008 13:29:15 +0100 Dieter Oberkofler
<doberkof...@gmail.com> wrote:
DO> 1) Is there a (more or less) official roadmap for the future of
DO> wxWidgets
Not really. There are plans but calling them a roadmap would imply
assigning schedule to implementing them and currently we don't really have
it.
DO> 2) I've read a lot about upcoming Version 3 that includes Unicode
DO> but when looking at the documentation Unicode is already supported as a
Vadim Zeitlin
DO> Thank you for your feedback!
DO>
DO> ad 1) I understand. What would be the closest to a roadmap the project
DO> currently has?
Basically release 2.9.0 a.s.a.p. (realistically this means the beginning
of the next year) and wait for the users reaction. For 3.0 I guess the main
task is strategically speaking is the finalization of Carbon/Cocoa ports
unification under Mac as this is necessary to support 64 bit systems. Other
than that I don't think there are any "must have" items for 3.0 although
there a lot of "[very] nice to have" ones.
DO> Based on what "information" is the current development (there
DO> is a lot of changes going on the trunk) triggered?
Different people have different motivations but my own approach to
development is rather pragmatic: when I need some feature which wxWidgets
doesn't provide in an application I'm working on I try to add it to wx or
at least make adding it to the application easier. So quite a few changes
end up being done because they're (directly or indirectly) sponsored by the
companies developing wxWidgets applications -- at least this is true for me
and I suspect it's true for other people submitting patches.
Of course, many things are not sponsored by anything, e.g. during the
week end I refactored the Win32 classes registration code just because I
got sick of its ugliness and couldn't stand looking at it any more. And
Francesco, Brian and the others have spent incredible amount of time on
improving wxWidgets documentation absolutely on their own volition. But
needing some feature in an application using wxWidgets is usually a good
impetus for extending wx to provide it.
DO> ad 2) Is there a documentation (any kind) of what is planned for version 3?
Not yet I'm afraid... We do have a list of things which already changed
though:
http://docs.wxwidgets.org/trunk/overview_changes_since28.html
DO> Will there be major API changes and are they known?
There already were major API changes (Unicode-related). No other
(incompatible) ones are currently being planned.
DO> Is there "any" schedule for when version 3 might be ready?
I do hope it will be in 2009.
DO> I have continued with my testing and would have a few new questions:
FWIW it's usually better to keep separate questions in separate threads as
this allows discussing them independently.
DO> 3) I'm trying to understand the differences between the top-level Window
DO> classes and especially between CFrame and CDialog. It seems as CFrame would
DO> best fit our typical dialog classes as we typically use a Status Bar and
DO> Toolbar. ON the other hand only CDialog has the modality features. What
DO> would be the way to go if someone needs mixed features from each of those
DO> two classes?
As Igor wrote, you can have status and tool bars with wxDialog, it's just
that they're usually used only with wxFrame. The only big difference
between these classes is that wxDialog can be modal and wxFrame can't.
DO> 4) The typical event handling in wxWidgets seems to be static and
DO> macro-based but according to the documentation it is also possible to
DO> dynamically link events to a function.
Please see
http://wxwidgets.blogspot.com/2007/01/in-praise-of-connect.html
The documentation was also updated in the trunk and is now hopefully more
helpful:
http://docs.wxwidgets.org/trunk/overview_eventhandling.html
Dieter Oberkofler
Understood: so it is ok to use wxDialog and (manually) just add a Toolbar
and Status bar if needed.
Connect():
Now I understand!
Thank you,
Dieter
-----Original Message-----
From: wx-users...@lists.wxwidgets.org
[mailto:wx-users...@lists.wxwidgets.org] On Behalf Of Vadim Zeitlin
Sent: Tuesday, December 02, 2008 09:54
To: wx-u...@lists.wxwidgets.org
Subject: Re[2]: Roadmap
On Tue, 2 Dec 2008 08:15:15 +0100 Dieter Oberkofler
<doberkof...@gmail.com> wrote:
DO> >wxDialog has a possibility of having a toolbar and a status bar in it.
DO> I understand but according to the documentation in wxDiaog they
DO> would somehow need to be created "manually" as child window where in
DO> wxFrame there is explicit methods that can be used to create status
DO> bar and tool bar. The wxDialog class does not offer them?
No, it doesn't.
DO> Is this just a "missing feature" or would it imply that I should
DO> rather use wxFrame.
Usually you would use wxFrame for normal windows having toolbars. And
usually dialogs don't have toolbars. So the decision was made (consciously)
to provide the "bar" methods only in wxFrame.
DO> What also puzzles me, is the fact that wxDialog is not derived from
DO> wxFrame?
They both derive from wxTopLevelWindow. wxFrame adds "bar" methods to the
base class interface while wxDialog basically adds ShowModal().
DO> When suing the wxEvtHandler::Connect method to dynamically connect
DO> an event to it's handler the documentation say that when creating a
DO> window the window identifier set to wxID_ANY also the Connect method
DO> should use wxID_ANY and this seems very strange to me. Is it not the
DO> window id that identifies the window and how would wxWidgets bee
DO> able to differentiate between multiple windows. How would this work
DO> if wxID_ANY always generates a unique negative window identifier?
When you call Connect() on the window it will only get events for itself
(and its children maybe, but if you connect to wxEVT_COMMAND_BUTTON_CLICKED
on a button you don't risk getting clicks from any other buttons). So you
can perfectly well use wxID_ANY, there is no ambiguity. OTOH you do need to
use unique ids if you handle events at the parent window level as it may get
events from multiple different buttons.
To explain it in another way: both event propagation ("bubbling up") and
Connect() can be used to handle the child window events in the parent. But
in the latter case you really handle them in the child and just call the
parents method from it.
Robert Roebling
Dieter Oberkofler wrote:
> wxDialog vs. wxFrame:
> Understood: so it is ok to use wxDialog and (manually) just add
> a Toolbar and Status bar if needed.
This is only correct in theory, while in practice you'd
violate the most basic user interface guidelines and
experiences and could confuse your users.
Robert
Dieter Oberkofler
I completely agree with you!
In my case I'm currently trying to understand on how to emulate an existing
UI with wxWidgets and I have (at least some) windows being modal and having
a toolbar.
Thank you,
Dieter
Mark Gollahon
successfully enabled several locales under Windows and Linux, but I
can't seem to figure out how to make any locale other than English auto
detect on MacOSX. I've been following
http://wiki.wxwidgets.org/Mac_OS_X_And_Xcode_For_Beginners
and
http://docs.wxwidgets.org/2.6/wx_internationalization.html
for information.
If I force the locale in wxLocale.Init(), then everything seems to work,
but why does wxLocale not autodetect the current locale?
Any help would be appreciated.
-Mark Gollahon
Exacq Technologies, Inc.
Mark Gollahon
Regards,
-Mark Gollahon
Exacq Technologies, Inc.
On Fri, 2008-12-05 at 15:55 +0100, Vadim Zeitlin wrote:
> On Fri, 05 Dec 2008 09:49:23 -0500 Mark Gollahon <mgol...@exacq.com> wrote:
>
> MG> I'm sorry, but that doesn't quite make sense to me.
>
> Probably because I misunderstood your question. I thought you were asking
> why wxLocale was not initialized to the current user locale by wx itself.
>
> MG> class wxMyApp:public wxApp
> MG> {
> MG> ...
> MG> wxLocale m_locale;
> MG> ...
> MG> }
> MG>
> MG> wxMyApp::wxMyApp()
> MG> {
> MG> ...
> MG> m_locale.Init();
> MG> ...
> MG> }
> MG>
> MG> So, is this the way to initialize locales on Mac?
>
> Yes, on Mac and everywhere else.
>
> MG> Furthermore, since (obviously) this is not working on my setup, does
> MG> anyone have suggestions as to what I should be looking at?
>
> This is more difficult to answer, I don't know why isn't the locale
> detected. The first thing to check would be what do various wxLocale statis
> GetSystemXXX() methods (e.g. GetSystemLanguage(), GetSystemEncoding(), ...)
> return. I guess they misdetect the locale...
>
> Good luck,
> VZ
>
> _______________________________________________
> wx-users mailing list
> wx-u...@lists.wxwidgets.org
> http://lists.wxwidgets.org/mailman/listinfo/wx-users
Paul Koning
MG> class wxMyApp:public wxApp { ... wxLocale m_locale; ... }
MG>
MG> wxMyApp::wxMyApp() { ... m_locale.Init(); ... }
MG>
MG> So, is this the way to initialize locales on Mac?
Vadim> Yes, on Mac and everywhere else.
MG> Furthermore, since (obviously) this is not working on my setup,
MG> does anyone have suggestions as to what I should be looking at?
Vadim> This is more difficult to answer, I don't know why isn't the
Vadim> locale detected. The first thing to check would be what do
Vadim> various wxLocale statis GetSystemXXX() methods
Vadim> (e.g. GetSystemLanguage(), GetSystemEncoding(), ...)
Vadim> return. I guess they misdetect the locale...
I just checked a wxMac app of mine that has locale support, and it
doesn't work there either. What's curious is that I'm quite sure this
worked at one time. It fails on both Mac OS 10.4 and 10.5, so I don't
think it's the OS version (it worked before on my 10.4 system). The
particular version I have was built with wxWidgets 2.6.4. I should
try rebuilding it with the newest version...
Linux isn't cooperating right now either, but that's probably user
error.
paul
Mark Gollahon
Everything started working correctly once I:
1. made sure the MO files could be found properly (i.e. found
fully-qualified dir of argv[0] and put that dir into
AddCatalogSearchPath());
2. added my languages to my bundle's Info.plist (instead of using all of
those <lang>.lproj dirs);
3. and logged off and back onto my Mac after adjusting the Mac's
languages priority list.
I never could figure out how to make WX look for or load the MOs from
the bundle's Resources/<lang>.lproj directories. I "punted" on it and
moved the MOs back to the MacOS directory with the executable.
Thanks for everyone's help!
Regards,
-Mark Gollahon
On Fri, 2008-12-05 at 10:23 -0500, Mark Gollahon wrote:
> Thank you for the pointers - I'll check them and see what I can see.
>
> Regards,
> -Mark Gollahon
> Exacq Technologies, Inc.
>
>
> On Fri, 2008-12-05 at 15:55 +0100, Vadim Zeitlin wrote:
> > On Fri, 05 Dec 2008 09:49:23 -0500 Mark Gollahon <mgol...@exacq.com> wrote:
> >
> > MG> I'm sorry, but that doesn't quite make sense to me.
> >
> > Probably because I misunderstood your question. I thought you were asking
> > why wxLocale was not initialized to the current user locale by wx itself.
> >
> > MG> class wxMyApp:public wxApp
> > MG> {
> > MG> ...
> > MG> wxLocale m_locale;
> > MG> ...
> > MG> }
> > MG>
> > MG> wxMyApp::wxMyApp()
> > MG> {
> > MG> ...
> > MG> m_locale.Init();
> > MG> ...
> > MG> }
> > MG>
> > MG> So, is this the way to initialize locales on Mac?
> >
> > Yes, on Mac and everywhere else.
> >
> > MG> Furthermore, since (obviously) this is not working on my setup, does
> > MG> anyone have suggestions as to what I should be looking at?
> >
> > This is more difficult to answer, I don't know why isn't the locale
> > detected. The first thing to check would be what do various wxLocale statis
> > GetSystemXXX() methods (e.g. GetSystemLanguage(), GetSystemEncoding(), ...)
> > return. I guess they misdetect the locale...
> >