wxWidgets libraries versus QT libraries
AM Christophe
Hi,
What is missing to wxWidgets/wxWindows to become as successfull as QT from
Trolltech? I would like to have your well-thought-out opinion about this.
I'm still asking myself.
Regards
Amrein-Marie Christophe
Peter Strempel
AM Christophe wrote:
> What is missing to wxWidgets/wxWindows to become as successfull as QT from
> Trolltech? I would like to have your well-thought-out opinion about this.
> I'm still asking myself.
I think wxWidgets already is a very successfull toolkit. However, it did
not make it into the brains of as many people yet. I suppose the main reason
is Qt being used for the KDE project which naturally gives it a high
penetration to many programmers. wxWidgets isn't used in a high-profile
project like KDE which is installed on many Linux boxes. If you install one
of the comment Linux distros today, you always get Qt installed by default,
but most distros don't install wxWidgets. Someone really needs to be not
interested in development at all to run Linux and not have heard about Qt
(no offense intented, not everyone is a programmer. But we are talking
about programmers now). To discover the existance of wx one needs to do a bit
more exploring.
I personally would estimate Qt and wxWidgets being on the same level of
usability. Both offer a rich GUI set and are very good for cross-platform
development. THe most noticable difference to wx is probably the license for
Windows and Mac. The licence thing might be irrelevant for some people while
for others it's the argument which kicks Qt off their radar screen.
I did a couple of Qt projects around 4 years ago, then switched to Java,
then to wxWidgets. I think I will stay with wx for now, it suits my demands
best. However, different people have different demands, so please just take
this as my personal opinion.
Peter
Jem Berkes
> What is missing to wxWidgets/wxWindows to become as successfull as QT
> from Trolltech? I would like to have your well-thought-out opinion
> about this. I'm still asking myself.
Let me give some feedback, not as a wxWidgets user (haven't tried it out
yet) but rather as a programmer and potential wx-user.
- I never heard of wxWidgets until yesterday, and this is despite being an
active Windows and UNIX software developer for some number of years. I was
referred by a couple people on the Wine users mailing list.
- Although I have used wxWidgets apps in the past (like Audacity) I didn't
actually realize they used wx. THIS IS GOOD: in Windows, the application
looks like a native Win32 GUI app. And there is no separate DLL so there
are no clues that there is an 'external' widget-set.
- Myself, I was going to start looking at QT because I was familiar with
its existence (KDE-install). However I was reluctant because of the rather
large (into megabytes) of DLLs required. Also, the test app I tried looked
a bit goofy under Windows.
So maybe a good angle for wxWidgets would be to push the native-GUI
appearance, and the convenient Windows static linking that doesn't require
huge external DLLs.
--
Jem Berkes
http://www.sysdesign.ca/
Vaclav Slavik
Jem Berkes wrote:
> - Although I have used wxWidgets apps in the past (like Audacity) I
> didn't actually realize they used wx. THIS IS GOOD: in Windows, the
> application looks like a native Win32 GUI app.
That's our goal, thanks for confirming it works ;)
> So maybe a good angle for wxWidgets would be to push the native-GUI
> appearance, and the convenient Windows static linking that doesn't
> require huge external DLLs.
To be fair, Qt can be built as static library (at least on Unix, I
don't know about Windows) and wxWindows can be built as a set of DLLs
if you prefer it.
Regards,
Vaclav
--
PGP key: 0x465264C9, available from http://pgp.mit.edu/
Corey
> its existence (KDE-install). However I was reluctant because of the rather
> large (into megabytes) of DLLs required. Also, the test app I tried looked
> a bit goofy under Windows.
>
> So maybe a good angle for wxWidgets would be to push the native-GUI
> appearance, and the convenient Windows static linking that doesn't require
> huge external DLLs.
You can use XP Styles with Qt, but then you lose the ability to do things
like button coloring/etc in Qt correctly.
corey
sylvie pfister
Hi all,
I think that the big differences are the support and documentation. Qt, is
better for that.That's all !!
wxWindows Community and KDE community must work in narrow collaboration.
"AM Christophe" <xx...@freesurf.fr> a écrit dans le message de news:
mVw9c.32876$zm5....@nntpserver.swip.net...
David Elliott
>>
>> So maybe a good angle for wxWidgets would be to push the native-GUI
>> appearance, and the convenient Windows static linking that doesn't
>> require
>> huge external DLLs.
>
> You can use XP Styles with Qt, but then you lose the ability to do
> things
> like button coloring/etc in Qt correctly.
Sure, and you get the Aqua GUI with Qt for OS X but it will never look
like a real Cocoa or Carbon GUI using native widgets.
wxWindows supports both Carbon and Cocoa.
-Dave
David Elliott
> "AM Christophe" <xx...@freesurf.fr> a écrit dans le message de news:
> mVw9c.32876$zm5....@nntpserver.swip.net...
>>
>> Hi,
>>
>> What is missing to wxWidgets/wxWindows to become as successfull as QT
>> from
>> Trolltech? I would like to have your well-thought-out opinion about
>> this.
>> I'm still asking myself.
>>
>
> Hi all,
> I think that the big differences are the support and documentation.
> Qt, is better for that. That's all !!
> wxWindows Community and KDE community must work in narrow
> collaboration.
>
Hmm, I think the documentation for wxWindows is fine, especially with
the new class hierarchy pages.
As for support, you'll pay for Qt to get paid support and you can pay
to get wxWindows support as well, in fact, the "Support" link on
wxwidgets.org lists commercial support first and foremost.
-Dave
simo
I'm evaluation both myself at the moment (moving on from TKinter in
Python and MFC in C++). I've written a few small apps using Qt, and am
currently writing quite a big app using wxWidgets.
Here's what I have to say for both toolkits:
wxWidgets:
==========
good - usable cross-platform [free] license
good - native look'n'feel (although that can give you limitations)
bad - not great documentation, needs more examples, screenshots, it's
actually misleading sometimes too - or doesn't mention "gotchas" that
you have to trawl through newsgroups to find
bad - half-implemented widgets, or widgets that vastly differ between
Linux/Windows, or aren't even implemented under Linux
bad - no true MDI under Linux
Qt:
===
good - large widget set
good - excellent documentation, QtAssistant has screenshots of every
widget too
good - widgets behave/look identical[ly] across all platforms
bad - no free Windows license (expensive personal/commercial license)
bad - widget emulation - non-native, and somewhat KDE-ish on all
platforms
I think, if there was a GPL Windows license for Qt (and PyQt), then I
would be using it over wxPython, mainly because of the Linux problems
with wxWidgets. I have no experience with either toolkit under MacOS,
but I've used Qt under Solaris too.
Corey
useful built-in Qt classes that I like. The fact that it doesn't compile in
a WinMain.
wxWindows compiles into the program well. It offers a lot of low-level
event overrides easily. Widgets like openGL are a LOT more detailed than
Qt's although Qt's stuff runs very solid with mouse issues like I've had
with wxWindows on that level.
I think, unless you're trying to find a suite idiot proof for a large
project of random developers, that the key is in the program you're trying
to make. If you have a team of talented programmers, both libraries will
perform. If you need something where the libraries hands the programmer the
answer on a very dulled-edge plate somtimes, Qt is there.
corey
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wx-users-u...@lists.wxwidgets.org
> For additional commands, e-mail: wx-use...@lists.wxwidgets.org
>
>
>
rob...@roebling.de
> bad - half-implemented widgets, or widgets that vastly
> differ between Linux/Windows, or aren't even implemented
> under Linux
Could you let us know what the problems were, which
widgets are not implemented under wxGTK and what
the vast differences were. It is hard to correct
something that you don't know about.
> bad - no true MDI under Linux
It just doesn't exist under GTK+. This can only
be fully solved by the GTK+ people (but they will
not).
> QtAssistant has screenshots of every widget too
I like the idea of adding screenshots from every
platform to the doc section of the various controls.
I'll do that for GTK controls.
Robert
Otto Wyss
To give you an idea what some developers using QT think I summarize the
feedback I got from several developers (about 20) during my campaign of
wxGuide. About a rough 1/3 already knew wxWidgets before I asked them.
Another 4 promised to look into wxWidgets after I asked them and 2 of
them actually answered afterwards.
Their arguments:
- Each said he's using QT because he writes KDE stuff.
- The ones who know about wxWidgets complained about the poor quality of
wxWidgets on Linux.
- None valued the cross platform aspect either because QT were it also
or they just write apps for Linux.
- A few mentioned wxWidgets is too Windows centric. This was always said
when I questioned the poor quality argument.
I probably haven't been able to persuade any QT developer to switch to
wxWidgets. I'm not sure but I got the impression that some of the GTK
developers switched (or intended to switch) to wxWidgets because of my
asking. I'm confidential that at least one switched because of wxGuide
but this one already thought of a redesign of his cross platform
application.
The conclusion for wxWidgets:
- Forget about QT (KDE) developers
- Improve the quality of the Linux ports, giving the GTK developers a
better reason.
- Try to encourage Windows (MFC) developers to port their apps to Linux
using wxWidgets.
Besides the overall above mentioned goals someone (I won't) should do
the following action:
- All ms-windows newsgroups should be monitored for messages about
questions for tools, frameworks, infos what to use for development.
Answers to these messages should point anyone to wxWidgets and
especially beginners should be pointed to wxGuide (Demo sample). IMO
beginners are the most easy developers to win over and with the help of
wxGuide they will fast mutate to good developers. I do a similar task on
the Linux development groups.
O. Wyss
--
See "http://freshmeat.net/projects/wxguide" for application design
See "http://freshmeat.net/projects/wxguide-editor" for a nice editor
Andy Robinson
As far as increasing the attractiveness of wx is concerned, I think when
the Mac version is stable on OS-X this will be a major plus : there are
a lot of people who write apps to target Windows & Mac.
Andy Robinson, Seventh String Software, www.seventhstring.demon.co.uk
Christopher Mellon
I'd started some work using Qt, really liked it, but quickly became disappointed with
the 'free' windows version, and didn't have the cash for a license. I came across wxWindows
and very quickly came to prefer it over Qt, so that now I wouldn't switch back even without
the licensing issue.
Otto Wyss
Andy Robinson <an...@seventhstring.com> wrote:
> As far as increasing the attractiveness of wx is concerned, I think when
> the Mac version is stable on OS-X this will be a major plus : there are
> a lot of people who write apps to target Windows & Mac.
>
Yes, but since I don't develop on the Mac, I can't check if wxGuide
builds and works well on the Mac.
simo
rob...@roebling.de wrote:
> > bad - half-implemented widgets, or widgets that vastly
> > differ between Linux/Windows, or aren't even implemented
> > under Linux
> Could you let us know what the problems were, which
> widgets are not implemented under wxGTK and what
> the vast differences were. It is hard to correct
> something that you don't know about.
Oops, I guess I just assumed they were known about....
Off the top of my head (don't have access to wxGTK at work), these are
from 2.4.2, not tried 2.5.1 yet:
wxColourDialog looks completely different under wxGTK;
wxMessageDialog doesn't center to the parent on Windows, it centers to
the screen (that's due to using WinAPI);
wxWidgets has a lot of flicker problems - this is one of the main
reasons the company I work for choose Qt over wxWidgets, I've noticed
it at least with wxListCtrl and wxPanel;
wxLIST_AUTOSIZE_HEADER under Windows seems to fit to the largest of
column header or column [cell] content, which makes sense. wxGTK seems
to just set the header to 80 pixels and not look to see if the content
will fit in that.
This is documented IIRC, and I fix it by setting the column width
using both methods, and finding the largest, but that's taking up a
few processor cycles....
> > bad - no true MDI under Linux
> It just doesn't exist under GTK+. This can only
> be fully solved by the GTK+ people (but they will
> not).
Yes, I guess this is one of the good things about emulation as per Qt.
Mind you, I guess nobody really likes MDI anyway....
> > QtAssistant has screenshots of every widget too
> I like the idea of adding screenshots from every
> platform to the doc section of the various controls.
> I'll do that for GTK controls.
There are quite a few at wxpython.org, although it really needs to be
comprehensive. I can't tell you how many times I've written code using
a widget, then when it's done, realised that this isn't what I need,
like the MDI/Notebook issue, or wxListBox/wxListCtrl.
You shouldn't have to write code to figure out what a widget looks
like. I guess you can run the demo, but that doesn't cover all the
widgets.
Maybe you could make a Wiki that people can post their screenshots to?
Micha Feigin
gui before, mostly kernel work and similar level work so I can't
compare.
I was looking for a cross platform toolkit. QT was dropped immediately
because of the license. gtk is reported to be unstable with
windows. That left a choice between wxWidgets, fox and fltk.
fltk was reported to be a little problematic with large programs, and
fox didn't seem as mature (don't know if its true, just a fleeting
impression) but was also recommended when I was looking for a toolkit.
I'm mostly happy with wxWidgets. The documentation not bad for someone
with enough programming experience, can be somewhat problematic for
newbies. It could use more examples and some more notes and pointers
about pitfalls and usage recommendations. Screenshots could be nice,
but not essential (I use wxGlade for most of that).
I did notice that full screen drawing in linux is a bit slower on linux
then on windows (haven't had time to look into that yet). When drawing
full screen bitmaps I got a flicker on linux. Could be just an
implementation method issue.
I also prefer callbacks to message lists, but probably because thats
what I am used to from the kernel and doing OOP in c.
For the moment I am happy.
> +++++++++++++++++++++++++++++++++++++++++++
> This Mail Was Scanned By Mail-seCure System
> at the Tel-Aviv University CC.
>
Hendrik Sattler
David Elliott wrote:
>> I think that the big differences are the support and documentation.
>> Qt, is better for that. That's all !!
>> wxWindows Community and KDE community must work in narrow
>> collaboration.
>>
> Hmm, I think the documentation for wxWindows is fine, especially with
> the new class hierarchy pages.
Hmm, it looks like being correct but does it really give a better overview?
Sorry, but I really, really doubt that: I can only see a small part of even
at 1024x768 screen resolution (I think, pretty common). Additionally, it's
limited to part of the browser window, making the view even smaller.
It imagine that it was a lot of work but the way that it is displayed is not
optimal at all...
Also, it doesn't solve other issues with documentation. Just a pointer to a
question that I had when I looked at wxWidgets' documentation:
What kinds of protocols can you use with wxURL?
So you look at the documentation page of wxURL and find
"See also: wxSocketBase, wxProtocol"
Task 1: Find wxSocketBase and wxProtocol in the class hierarchy graphics
Maybe you'll find wxProtocol to be useful to point to wxHTML and wxFTP.
You'll eventually see that http:// and ftp:// will work.
You also see that wxURL::GetInputStream returns wxInputStream.
Task 2: Find wxInputStream in the class hierarchy graphics.
Task 3: Find out which of the classes that depend on wxInputStream can be
used with wxURL.
Hmm, you managed task 2 but not really sure about task 3.
However, that's what documentation really is about: telling the programmer
what he can do with a class.
So I tell you that a "file:" URL is also possible. Yeah, but not "file://"
prefix to a path! Really only "file:" as the prefix. But be aware that it
shall be _unencoded_ when given to wxURL constructor: that's not
documented, too.
If you look at the source code about wxURL, you'll see that it uses classes,
that are not documented at all (maybe because they shall not be used
directly outside of wxWidgets).
Maybe now you can answer the question again: how exactly does the class
hierarchy graphics helps you?
HS
Tsolakos Stavros
>Hmm, it looks like being correct but does it really give a better overview?
>Sorry, but I really, really doubt that: I can only see a small part of even
>at 1024x768 screen resolution (I think, pretty common). Additionally, it's
>limited to part of the browser window, making the view even smaller.
>It imagine that it was a lot of work but the way that it is displayed is not
>optimal at all...
>
>
would be plenty of room to display it on a 120x100cm poster...
It would be really good if we could make one.
Regards,
Stavros
Vadim Zeitlin
s> wxMessageDialog doesn't center to the parent on Windows, it centers to
s> the screen (that's due to using WinAPI);
Err, is it really a big problem? Not trying to be negative, just curious as
to why would anyone complain about it. As you say yourself, Windows insisits
on positioning message boxes itself, which could be slightly illogical but
does it really bother anyone?
s> wxWidgets has a lot of flicker problems - this is one of the main
s> reasons the company I work for choose Qt over wxWidgets, I've noticed
s> it at least with wxListCtrl and wxPanel;
Have you used wxNO_FULL_REPAINT_ON_RESIZE with the latter (former is the
native control, we don't have any control over it)?
s> Maybe you could make a Wiki that people can post their screenshots to?
This seems like a good idea. Putting screenshots for N windows on M platforms
in the manual could seriously bloat it...
Regards,
VZ
Vaclav Slavik
simo wrote:
> bad - half-implemented widgets, or widgets that vastly differ
> between Linux/Windows, or aren't even implemented under Linux
Widgets that vastly differ is a *good* thing -- it means wx uses
native look & feel, which is different on different platforms.
Half-implemented is not, of course.
> bad - no true MDI under Linux
Again, this is good. There's no such thing as MDI known to X Window
System, it's a foreign concept. A well-written cross-platform
application will not use MDI on Unix, only bad ones do (I have an
example of such application -- written using Qt, BTW -- right here on
my desktop and it looks horrible). There was extensive discussion of
this on the list recently.
Jem Berkes
> As far as increasing the attractiveness of wx is concerned, I think when
> the Mac version is stable on OS-X this will be a major plus : there are
> a lot of people who write apps to target Windows & Mac.
I would love to be able to write for Mac OS... I had the impresion that wx
was pretty stable on Mac, are there certain aspects that aren't?
Ryan Wilcox
Hash: SHA1
Normally wxMac IS pretty stable. Right now wxMac from CSV is well... not as
stable as it is normally.
But once we get all the bugs ironed out, wxMac will be *much* better than it was
(calling more modern APIs, etc etc).
The original poster may have been referring to other things (I believe both
sockets and threads on wxMac are in transitional states ATM), but wxMac works
quite well for my app (as well as applications from an increasing number of
developers on this list.)
Hope this helps,
_Ryan Wilcox
================================================================
Wilcox Development Solutions: http://www.wilcoxd.com
Toolsmiths for the Internet Age PGP: 0x2F4E9C31
-----BEGIN PGP SIGNATURE-----
Version: PGP SDK 3.0.3
iQA/AwUBQGjPaW2DtKgvTpwxEQJJHQCeLzSckBACCU4z3KW/V0F0aNKHDlsAoL8K
NFz/KeeA6YILsnPRHgILzGDl
=8Kj4
-----END PGP SIGNATURE-----
Steve Schow
wxWidgets. I had planned on writing an app for MacOSX only. However, since
I can use wxMac, if I'm careful about my codeing it should be very
straightforward to deploy on both Windows as well as Linux. And as others
have pointed out, my mac UI will look aqua, my windows will look like win32,
etc..
Additionally, from what I have discovered so far, the wxWidgets framework is
very MFC-like, which is a proven paradigm for quickly creating applications
and maintaining them. Having this framework not only makes it so that you
write code for wx and it displays in different GUI flavors, but also that
the overall application architecture for event handling, etc..can be
generalized in a way that makes sense and will work on all the platforms
that wx supports.
David Elliott
Because of the rapid progress of OS X from the classic Mac OS there
were some rendering issues in wxWindows. In order to remedy this
Stefan (spurred on by Kevin Ollivier) has made some major changes to
the CVS HEAD. There was, unfortunately, no way to make these changes
except all at once and so many bugs resulted although they seem to be
all better now (In only a day, too! Great work Stefan). wxMac now
requires Carbon (which will work on OS 9 and X) although the
pure-classic version has been spun off so that a few people can
continue to use it for their projects.
In addition to wxMac there is wxCocoa which is only for OS X. There is
still much to be done with wxCocoa although a lot works already. In
addition to using wxCocoa on OS X I hope to be able to port it to
GNUstep in the future so that it may be used on other operating systems
such as Linux, *BSD, and possibly even Windows (evil, I know). The
stumbling block to that is lack of Objective-C++ support in GCC
releases other than Apple's. There are few, if any, critical APIs I
use that aren't part of the OpenStep specification.
There have in the past been a few issues with wxWindows on Macintosh
but it has become a high priority and major improvements have been
made. In fact, with the recent changes to wxMac I believe it has
become the ONLY cross-platform toolkit to support the OS >= 10.2
compositing. And as far as I know there is no other cross platform
toolkit that targets Cocoa aside from wxCocoa.
The closest competitors to wxWindows that target Macintosh are
PowerPlant and Qt. PowerPlant uses native widgets but they don't
always look right on OS X. Qt uses pseudo-native widgets and some of
them are still using an outdated 10.2 look when running on Panther.
wxWindows is the only toolkit focused on modern Mac development.
-Dave
Casey O'Donnell
beyond the "evaluation" stage with QT, so I'm a bit biased. I've
investigated FLTK in the past, and wx is MUCH easier to use (IMHO). I'm
impressed with the licencing of wx, as well as the native "look and feel"
that you get using it. I've also been impressed what I can do...
http://homepage.mac.com/codonnell/research/RW-New.PNG
...with non-standard GUI design. Though I'd like to abstract some of these
more generic GUI objects for later inclusion (interested?), it's really been
nice working with wx for so many different projects.
One downside has been the lack of "integrated" XML libraries, though given
the plethora of other useful XML libraries, this is a minor issue. QT
definitely has a boat-load of other utility libraries that might be useful
for thinking about the future of wxWidgets. All in all, I've been quite
impressed with stability, functionality, etc. Why it isn't beating out QT?
I have no idea. I think those of us using wx ought to make sure we're
linking back to wxWidgets.org...just so people do know when a developer has
used wx.
I saw some comment about message maps versus callbacks...message maps all
the way. Win and MacOS (carbon anyway) love callbacks, and they drive me
crazy. They break much of the beauty of OOP/OOD. (Again, IMHO)
Cheers.
Casey
_________________________________________________________________
MSN Toolbar provides one-click access to Hotmail from any Web page – FREE
download! http://toolbar.msn.com/go/onm00200413ave/direct/01/
Reed Hedges
I've been using CVS (2.5.x) on Mac and have not had any real problems
with wx yet. (I'm not using all features though)
reed
--
Reed Hedges
re...@zerohour.net
http://zerohour.net/~reed
AIM: ReedHedges
VOS/Interreality: http://interreality.org
Reed Hedges
On Monday, March 29, 2004, at 04:26 PM, Hendrik Sattler wrote:
> So you look at the documentation page of wxURL and find
> "See also: wxSocketBase, wxProtocol"
> Task 1: Find wxSocketBase and wxProtocol in the class hierarchy
> graphics
> Maybe you'll find wxProtocol to be useful to point to wxHTML and wxFTP.
> You'll eventually see that http:// and ftp:// will work.
I don't understand why you need to go back to the class hierarchy? The
"See also" items are hyperlinks, click on them...
<http://wxwidgets.org/manuals/2.4.2/wx405.htm#wxurl>
Hendrik Sattler
Reed Hedges wrote:
Yes, but wxProtocol dodumentation does not tell about classes that derived
from it, does it?
I thought that's what the class hierarchy graphics is for...
Common text parts in the documentation would be more useful, like:
Parent classes:
parentClass1, parentClass2, ...
Classes that this class is parent for:
derivedClass1, derivedClass2, ...
HS
Reed Hedges
On Tuesday, March 30, 2004, at 10:31 AM, Hendrik Sattler wrote:
>
> Yes, but wxProtocol dodumentation does not tell about classes that
> derived
> from it, does it?
You' re right. In general, the wx API you usually work with is pretty
shallow: the control classes. But in some instances like wxProtocol
knowing about child classes would be useful.
Arnout Engelen
Hash: SHA1
On Mon, Mar 29, 2004 at 10:19:13AM -0800, simo wrote:
> > > QtAssistant has screenshots of every widget too
>
> > I like the idea of adding screenshots from every
> > platform to the doc section of the various controls.
> > I'll do that for GTK controls.
>
> Maybe you could make a Wiki that people can post their screenshots to?
Feel free to add them to the current wxWiki!
if you want them hosted on the wiki machine, just send them to me in
e-mail. Thanks!
Arnout
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAcRMeWSAvNcFEP+sRAlJKAJ9lW+3iSqLu/ttonGvuXharn85yFgCgsqBO
CPr9qyttQcuGrhoASTWcbu0=
=/vKf
-----END PGP SIGNATURE-----
Arnout Engelen
Hash: SHA1
On Mon, Mar 29, 2004 at 11:26:20PM +0200, Hendrik Sattler wrote:
> David Elliott wrote:
> >> I think that the big differences are the support and documentation.
> >> Qt, is better for that. That's all !!
> >> wxWindows Community and KDE community must work in narrow
> >> collaboration.
> >>
> > Hmm, I think the documentation for wxWindows is fine, especially with
> > the new class hierarchy pages.
>
> Hmm, it looks like being correct but does it really give a better overview?
> Sorry, but I really, really doubt that: I can only see a small part of even
> at 1024x768 screen resolution (I think, pretty common). Additionally, it's
> limited to part of the browser window, making the view even smaller.
> It imagine that it was a lot of work but the way that it is displayed is not
> optimal at all...
It's not optimal - i'm still looking for better (dynamic?) ways of
representing. Ideas welcome.
> Also, it doesn't solve other issues with documentation.
it wasn't meant to :)
> Just a pointer to a question that I had when I looked at wxWidgets'
> documentation: What kinds of protocols can you use with wxURL?
>
> So you look at the documentation page of wxURL and find
> "See also: wxSocketBase, wxProtocol"
> Task 1: Find wxSocketBase and wxProtocol in the class hierarchy graphics
> Maybe you'll find wxProtocol to be useful to point to wxHTML and wxFTP.
Why would you want to find those in the hierarchy? You can just click
on the 'see also' links..
I agree the class documentation should not show only parents but also
children. I partially implemented that, see
http://wiki.wxwidgets.org/class.cgi?name=wxButton
Right now the 'parents' list shows all parents (recursively). Should the
same happen for the children? That's a long list for for example wxWindow.
Maybe only direct children would be better.
A little dynamically-generated part of the graphical class hierarchy
would be cool, too, i guess. I'll think about it :)
> If you look at the source code about wxURL, you'll see that it uses classes,
> that are not documented at all (maybe because they shall not be used
> directly outside of wxWidgets).
This is a very good thing, in my opinion. These classes are
implementation details that
*) might change in following wxWidgets versions
*) might be different on other platforms supported by wxWidgets
As such, imho, they're not part of the public API and should not be in
the documentation for the public API :)
Arnout
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAcRKCWSAvNcFEP+sRAlPTAKCD4mrvMOzB6JIDKUkOIOeAmWTy1wCgn6ty
kiPQ3FCw4wPT3x/6VEQli6Y=
=OeiP
-----END PGP SIGNATURE-----
AM Christophe
There's just the screenshot button that is missing for better documentation
clarity.
Screenshots are not needed for mathematician of imaginative people but I
found in my little experience that they talk a lot to almost everyone.
Julian Smart
You're right, I'll add this button to the toolbar; we need
to improve the selection of screenshots too. If a wxWiki
page is created with further images, I'll add a link to that.
Regards,
Julian
Reed Hedges
Hendrik Sattler
simo wrote:
> Oops, I guess I just assumed they were known about....
>
> Off the top of my head (don't have access to wxGTK at work), these are
> from 2.4.2, not tried 2.5.1 yet:
>
> wxColourDialog looks completely different under wxGTK;
Isn't that because native dialogs are used? Should a color dialog in wxGTK
look like color dialogs in other GTK applications? (hint: answer is yes).
However, I didn't use it myself, yet.
> wxLIST_AUTOSIZE_HEADER under Windows seems to fit to the largest of
> column header or column [cell] content, which makes sense. wxGTK seems
> to just set the header to 80 pixels and not look to see if the content
> will fit in that.
>
> This is documented IIRC, and I fix it by setting the column width
> using both methods, and finding the largest, but that's taking up a
> few processor cycles....
Yes, I already found that one, too. That should really be fixed. If GTK
itself does not provide it, maybe a work-around can be done?
If you have one, write a patch for wxWidgets. Actually, patches get
accepted :)
> There are quite a few at wxpython.org, although it really needs to be
> comprehensive. I can't tell you how many times I've written code using
> a widget, then when it's done, realised that this isn't what I need,
> like the MDI/Notebook issue, or wxListBox/wxListCtrl.
That's funny, never happened to me.
However, putting graphics into documentation makes it
a) lot bigger and
b) you still do not know, how the button looks like on extremely themable
environments.
Example to b: gtk-theme-geramik looks completely different than the default
theme (and sometimes has bugs that alter font color or whatever).
HS