X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/1a7f306263595bff3b74e96e4c2bee6f0a008500..ecd87e5b71cdfd71b3356181ab8be1bf508942ef:/docs/html/faqgen.htm diff --git a/docs/html/faqgen.htm b/docs/html/faqgen.htm index 2cf955358a..64144dcaac 100644 --- a/docs/html/faqgen.htm +++ b/docs/html/faqgen.htm @@ -1,18 +1,19 @@ + <HTML> <HEAD> -<TITLE>wxWindows 2 FAQ: General</TITLE> +<TITLE>wxWidgets FAQ: General</TITLE> </HEAD> -<BODY BGCOLOR=#FFFFFF TEXT=#000000 LINK=#FF0000 VLINK=#000000> +<BODY BGCOLOR=#FFFFFF TEXT=#000000 VLINK="#00376A" LINK="#00529C" ALINK="#313063"> <font face="Arial, Lucida Sans, Helvetica"> -<table width=100% border=4 cellpadding=5 cellspacing=0> +<table width=100% border=0 cellpadding=3 cellspacing=0> <tr> -<td bgcolor="#660000"> +<td bgcolor="#004080" align=left height=24 background="images/bluetitlegradient.gif"> <font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF"> -wxWindows 2 FAQ: General +<b>wxWidgets FAQ: General</b> </font> </td> </tr> @@ -22,131 +23,99 @@ wxWindows 2 FAQ: General See also <a href="faq.htm">top-level FAQ page</a>. <hr> +<h3>List of questions in this category</h3> +<ul> +<li><a href="#whatis">What is wxWidgets?</a></li> +<li><a href="#licence">Can I use wxWidgets for both proprietary projects, and GPL'ed projects?</a></li> +<li><a href="#support">Is there support?</a></li> +<li><a href="#users">Who uses wxWidgets?</a></li> +<li><a href="#platforms">What platforms are supported by wxWidgets?</a></li> +<li><a href="#specific">How does wxWidgets support platform-specific features?</a></li> +<li><a href="#stl">Does wxWidgets use STL? or the standard string class?</a></li> +<li><a href="#richedit">Is there a rich edit/markup widget for wxWidgets?</a></ li> +<li><a href="#exceptions">How to use C++ exceptions with wxWidgets?</a></ li> +<li><a href="#dev">How is wxWidgets being developed?</a></li> +<li><a href="#distrib">How is wxWidgets distributed?</a></li> +<!-- +<li><a href="#future">What are the plans for the future?</a></li> +--> +<li><a href="#base">What is wxBase?</a></li> +<li><a href="#univ">What is wxUniversal?</a></li> +<li><a href="#jave">What about Java?</a></li> +<li><a href="#dotnet">What about .NET/Mono?</a></li> +<li><a href="#help">How can I help the project?</a></li> +<li><a href="#newport">How do I start a new port?</a></li> +</ul> +<hr> -<H3><a name="whatis">What is wxWindows?</a></H3> +<H3><a name="whatis">What is wxWidgets?</a></H3> -wxWindows is a class library that allows you to compile graphical C++ programs on a range of -different platforms. wxWindows defines a common API across platforms, but uses the native graphical user interface (GUI) on each platform, -so your program will take on the native 'look and feel' that users are familiar with.<P> +wxWidgets is a class library that allows you to compile graphical C++ programs on a range of +different platforms. wxWidgets defines a common API across platforms, but uses the native graphical user interface (GUI) on each platform, +so your program will take on the native 'look and feel' that users are familiar with.<P> -Although GUI applications are mostly built programmatically, there is a dialog editor to help -build attractive dialogs and panels.<P> +Although GUI applications are mostly built programmatically, there are several dialog editors to help +build attractive dialogs and panels. Robert Roebling's <a href="http://www.roebling.com">wxDesigner</a> +and Anthemion Software's <a href="http://www.anthemion.co.uk/dialogblocks/" target=_new>DialogBlocks</a> +are two commercial examples, but there are others: see the <a href="lnk_tool.htm">Useful Tools</a> page.<P> -You don't have to use C++ to use wxWindows: wxWindows 1 has been interfaced to several interpreted languages, -such as CLIPS, Python, Scheme, XLisp and Perl, and there is a Python interface for wxWindows 2. +You don't have to use C++ to use wxWidgets: there is a <a href="http://wxpython.org">Python interface</a> for wxWidgets, +and also a <a href="http://wxperl.sourceforge.net" target=_top>Perl interface</a>. <P> -<h3>Can I use wxWindows 2 for both proprietary (commercial) projects, and GPL'ed projects?</h3> +<h3><a name="licence">Can I use wxWidgets for both proprietary (commercial) projects, and GPL'ed projects?</a></h3> Yes. Please see the <a href="newlicen.htm">licence</a> for details, but basically -you can distribute proprietary binaries without distributing any source code, and neither will wxWindows +you can distribute proprietary binaries without distributing any source code, and neither will wxWidgets conflict with GPL code you may be using or developing with it. <P> -The conditions for using wxWindows 2 are the same whether you are a personal, academic +The conditions for using wxWidgets are the same whether you are a personal, academic or commercial developer. <P> -<h3>Is there support?</h3> +<h3><a name="support">Is there support?</a></h3> No official support, but the mailing list is very helpful and some people say that -wxWindows support is better than for much commercial software. The developers are +wxWidgets support is better than for much commercial software. The developers are keen to fix bugs as soon as possible, though obviously there are no guarantees. <P> -<H3><a name="users">Who uses wxWindows?</a></H3> +<H3><a name="users">Who uses wxWidgets?</a></H3> Many organisations - commercial, government, and academic - across the -world. It's impossible to estimate the true number of users, since -wxWindows is obtained by many different means, and we cannot monitor +world. It's impossible to estimate the true number of users, since +wxWidgets is obtained by many different means, and we cannot monitor distribution. The mailing list contains around 300-400 entries which is quite large for a list of this type.<P> -<H3>I am about to start a wxWindows 1.xx project. Should I use 2 instead?</H3> - -wxWindows 2 is still in beta but it's actually pretty useable (Windows, GTK, Motif).<P> - -Porting to wxWindows 2 from 1.xx will not be too painful; see the next question -for ways in which you can make it easier.<P> - -<H3>Why would I want to use wxWindows 2 in preference to wxWindows 1.xx?</H3> - -Some reasons: - -<ul> -<li>In 2 there is far more flexibility, for example in the way windows can be -nested, and the way events are intercepted. -<li>There is more functionality for producing sophisticated applications, -for example using the wxTreeCtrl and wxListCtrl classes. -<li>There is better C++-conformance (such as usage of wxString and const) which -will make your applications more reliable and easier to maintain. -<li>wxWindows 2 will be better supported than 1.xx. -<li>The GTK version is attractive for people interested in writing Linux and GNOME -applications. -<li>The Mac version will be one of the best frameworks available on that platform. -</ul> - -<H3>How can I prepare for wxWindows 2?</H3> - -To make porting to wxWindows 2 easier in the future, take a look at some -<a href="http://web.ukonline.co.uk/julian.smart/wxwin/prepare.htm">tips</a> for writing existing code in a 2-compatible way.<P> - -<H3>How much has the API changed since 1.xx?</H3> - -It's difficult to summarize, but some aspects haven't changed very much. For example, if you have some -complex drawing code, you will mostly need to make sure it's parameterised with a device -context (instead of obtaining one from a window or storing it). You won't have -to completely rewrite the drawing code.<P> - -The way that events are handled has changed, so for example, where you overrode -OnSize before, you now have a non-virtual OnSize with a single event class argument. -To make this function known to wxWindows, you add an entry in an 'event table' using macros. Addition of these macros -will eventually be made easier by a tool which will allow selection from a list -and copy-and-paste into your editor. This is extended to button presses, listbox selection -etc. so callbacks have gone (they may be added back for limited backward compatibility).<P> - -The class hierarchy has changed to allow greater flexibility but it probably won't affect your -existing application. One exception to this is MDI applications which now use separate MDI classes instead of style -flags. As a result, it won't be possible to switch between MDI and SDI operation at run-time -without further coding, but a benefit is less interdependence between areas of code, -and therefore smaller executable size.<P> - -Panel items (now called controls) no longer have labels associated with most of them, -and default panel layout has been removed. The idea is that you make greater use -of dialog resources, for better-looking dialogs.<P> - -<H3>What classes have disappeared?</H3> - -wxForm, wxTextWindow (subsumed into wxTextCtrl). - -<H3>Does wxWindows 2 mean that wxWindows 1.xx is dead?</H3> - -While wxWindows 2 is being developed, there will be further patches to wxWindows 1.xx. -Obviously we are investing most of our energy into the new code, but we're also trying -to fix bugs in the current version.<P> +See <a href="users.htm">Users</a> for a list of some users and their applications, and +also <A href="feedback.htm">Feedback</a> for comments.<P> +Our highest-profile user yet is industry veteran and Lotus Corp. founder Mitch Kapor +and his <a href="http://www.osafoundation.org" target=_new>Open Source Applications Foundation</a>. +<P> -<H3>What platforms will be supported by wxWindows 2?</H3> +<H3><a name="platforms">What platforms are supported by wxWidgets?</a></H3> <ul> -<li>Windows 3.1, Windows 95/98, Windows NT; -<li>Linux and other Unix platforms with GTK+; -<li>Unix with Motif or the free Motif clone Lesstif; -<li>Mac (coming later in 1999); -<li>A BeOS port is being investigated. -<li>A Windows CE port is being investigated. -<li>There are no plans to support OS/2 or XView. However, -you may be able to compile the GTK and Motif versions under OS/2 with X and GTK -installed, or the Windows version with IBM's Open32 extensions. +<li>Windows 3.1, Windows 95/98, Windows NT, Windows 2000, Windows ME. +<li>Linux and other Unix platforms with GTK+. +<li>Unix with Motif or the free Motif clone Lesstif. +<li>Mac OS. +<li>Embedded platforms are being investigated. See the <a href="wxuniv.htm">wxUniversal</a> project. +<li>An OS/2 port is in progress, and you can also compile wxWidgets for GTK+ or Motif +on OS/2. </ul> <P> -<H3>How does wxWindows 2 support platform-specific features?</H3> +<H3><a name="specific">How does wxWidgets support platform-specific +features?</a></H3> This is a hotly-debated topic amongst the developers. My own philosophy -is to make wxWindows as platform-independent as possible, but allow in a +is to make wxWidgets as platform-independent as possible, but allow in a few classes (functions, window styles) that are platform-specific. For example, Windows metafiles and Windows 95 taskbar icons have their own classes on Windows, but nowhere else. Because these classes -are provided and are wxWindows-compatible, it doesn't take much +are provided and are wxWidgets-compatible, it doesn't take much coding effort for an application programmer to add support for some functionality that the user on a particular platform might otherwise miss. Also, some classes that started off as platform-specific, such @@ -154,29 +123,29 @@ as the MDI classes, have been emulated on other platforms. I can imagine that even wxTaskBarIcon may be implemented for Unix desktops one day. <P> -In other words, wxWindows is not a 'lowest common denominator' approach, +In other words, wxWidgets is not a 'lowest common denominator' approach, but it will still be possible to write portable programs using the core API. Forbidding some platform-specific classes would be a stupid approach that would alienate many potential users, and encourage -the perception that toolkits such as wxWindows are not up to the demands -of today's sophisticated applications.<P> +the perception that toolkits such as wxWidgets are not up to the demands +of today's sophisticated applications.<P> Currently resources such as bitmaps and icons are handled in a platform-specific way, but it is hoped to reduce this dependence in due course.<P> -Another reason why wxWindows 2 is not a 'lowest common denominator' toolkit is that +Another reason why wxWidgets is not a 'lowest common denominator' toolkit is that some functionality missing on some platform has been provided using generic, platform-independent code, such as the wxTreeCtrl and wxListCtrl classes.<P> -<H3>Does wxWindows use STL? or the standard string class?</H3> +<H3><a name="stl">Does wxWidgets use STL? or the standard string class?</a></H3> No. This is a much-discussed topic that has (many times) ended with the conclusion that it is in -wxWindows' best interests to avoid use of templates. Not all compilers can handle +wxWidgets' best interests to avoid use of templates. Not all compilers can handle templates adequately so it would dramatically reduce the number of compilers -and platforms that could be supported. It would also be undersirable to make -wxWindows dependent on another large library that may have to be downloaded and installed. +and platforms that could be supported. It would also be undesirable to make +wxWidgets dependent on another large library that may have to be downloaded and installed. In addition, use of templates can lead to executable bloat, which is something -wxWindows 2 is strenously trying to avoid.<P> +wxWidgets is strenuously trying to avoid.<P> The standard C++ string class is not used, again because it is not available to all compilers, and it is not necessarily a very efficient implementation. Also, we retain more flexibility @@ -184,49 +153,214 @@ by being able to modify our own string class. Some compatibility with the string has been built into wxString.<P> There is nothing to stop an application using templates or the string class for its own -purposes.<P> +purposes. With wxWidgets debugging options on, you may find you get errors when including +STL headers. You can work around it either by switching off memory checking, +or by adding this to a header before you include any STL files:<P> + +<PRE> +#ifdef new +#undef new +#endif +</PRE> + +<P> + + +<H3><a name="richedit">Is there a rich edit/markup widget for wxWidgets?</a></H3> + +These are the possibilities so far:<P> + +<ul> +<li>See <a href="http://www.scintilla.org" target=_top>www.scintilla.org</a> for +a very nice syntax-highlighting editor widget. Robin Dunn has written a wxWidgets wrapper +for this widget, available in the wxWidgets distribution under contrib/src/stc. +<li>If you only need to display marked-up information, rather than edit it, +then wxHTML will suit your needs. wxHTML is built into wxWidgets - please see the reference +manual for details, and samples/html. +<li>There are rich edit widgets in both WIN32 and GTK+, but there is currently +no wxWidgets wrapper for these (but text attribute functions are being added in the wxWidgets 2.3.x series). +</ul> -<H3>How is wxWindows 2 being developed?</H3> +<P> + +<h3><a name="exceptions">How to use C++ exceptions with wxWidgets?</a></h3> + +wxWidgets library itself is unfortunately <i>not</i> exception-safe (as its +initial version predates, by far, the addition of the exceptions to the C++ +language). However you can still use the exceptions in your own code and use +the other libraries using the exceptions for the error reporting together with +wxWidgets. + +<p> +There are a few issues to keep in mind, though: +<ul> + <li>You shouldn't let the exceptions propagate through wxWidgets code, + in particular you should always catch the exceptions thrown by the + functions called from an event handler in the handler itself and not + let them propagate upwards to wxWidgets. + + <li>You may need to ensure that the compiler support for the exceptions is + enabled as, considering that wxWidgets itself doesn't use the + exceptions and turning their support on results in the library size + augmentation of 10% to 20%, it is turned off by default for a few + compilers. Moreover, for gcc (or at least its mingw version) you must + also turn on the RTTI support to be able to use the exceptions, so you + should use <tt>--disable-no_rtti --disable-no_exceptions</tt> options + when configuring the library (attention to the double negation). +</ul> -We are using the <a href="cvs.htm">CVS</a> system to develop and maintain wxWindows. This allows -us to make alterations and upload them instantly to the server in Edinburgh, from +<p> + +<H3><a name="dev">How is wxWidgets being developed?</a></H3> + +We are using the <a href="cvs.htm">CVS</a> system to develop and maintain wxWidgets. This allows +us to make alterations and upload them instantly to the server, from which others can update their source.<P> -To build source from CVS, see the file BuildCVS.txt in the top-level wxWindows distribution +To build source from CVS, see the file BuildCVS.txt in the top-level wxWidgets distribution directory.<P> -<H3>How is wxWindows 2 distributed?</H3> +<H3><a name="distrib">How is wxWidgets distributed?</a></H3> + +By ftp, and via the <a href="cdrom2.htm">wxWidgets CD-ROM</a>. +<P> +If you are feeling adventurous, you may also check out the sources directly +from <a href="cvs.htm">cvs</a>. +<p> + +<!-- +<H3><a name="future">What are the plans for the future?</a></H3> + +TODO -By ftp, and via the <a href="cdrom2.htm">wxWindows CD-ROM</a>.<P> +<p> -<H3>What are the plans for the future?</H3> +--> -Currently we're working too hard on getting wxWindows 2 finished (are GUI toolkits ever -finished?) to think very far ahead. However, we know we want to make wxWindows as robust -and well-publicised as possible. We also want to aim for better platform-independence of -resources such as icons and bitmaps, standardising on the PNG for all platforms.<P> +<h3><a name="base">What is wxBase?</a></h3> -Other possibilities include: DCOM/CORBA compatibility; a wxWindows book; -<a href="http://wxstudio.linuxbox.com/">wxStudio</a>, an IDE; -other platforms; other interface abilities such as speech output.<P> +wxBase is a subset of wxWidgets comprised by the non-GUI classes. It includes +wxWidgets container and primitive data type classes (including wxString, +wxDateTime and so on) and also useful wrappers for the operating system objects +such as files, processes, threads, sockets and so on. With very minor +exceptions wxBase may be used in exactly the same way as wxWidgets but it +doesn't require a GUI to run and so is ideal for creating console mode +utilities or server programs. It is also possible to create a program which can +be compiled either as a console application (using wxBase) or a GUI one (using +a full featured wxWidgets port). -We will investigate the possibility of compiler or operating system vendors bundling wxWindows with -their product.<P> +<H3><a name="univ">What is wxUniversal?</a></H3> -The high-level goal of wxWindows is to be thought of as the number one C++ framework, -for virtually any platform. Move over, MFC!<P> +The main difference between wxUniversal-based ports (such as wxX11, wxMGL) and other ports (such as wxMSW, wxGTK+, wxMac) +is that wxUniversal implements all controls (or widgets) in +wxWidgets itself thus allowing to have much more flexibility (for example, support for +themes even under MS Windows). It also means that it is now much easier to +port wxWidgets to a new platform as only the low-level classes must be ported +which make for a small part of the library. +<p> +You may find more about wxUniversal <a href=wxuniv.htm>here</a>. -<H3>What about Java?</H3> +<H3><a name="jave">What about Java?</a></H3> The Java honeymoon period is over :-) and people are realising that it cannot -meet all their cross-platform development needs. We don't anticipate a major threat -from Java, and the level of interest in wxWindows is as high as ever.<P> +meet all their cross-platform development needs. We don't anticipate a major threat +from Java, and the level of interest in wxWidgets is as high as ever.<P> + +<H3><a name="dotnet">What about .NET/Mono?</a></H3> + +Microsoft is spending a lot on promoting the .NET initiative, which +is a set of languages, APIs and web service components for Windows. +Ximian has started an open source version of .NET, mostly for Linux. +C# is Microsoft's alternative to Java, supporting 'managed code', +garbage collection and various other Java-like language features.<P> + +Although this may be attractive to some developers, there +is a variety of reasons why the .NET/Mono combination is unlikely +to make wxWidgets redundant. Please note that the following comments +are Julian Smart's opinions.<P> + +<ol> +<li>Not everyone wants or needs net services. +<li>C++ will be used for a long time to come; compared with C++, C# is a recent development and its future is not certain. +<li>Mono Forms may only target Winelib (at least to begin with), so the end result is not as native as +wxWidgets (I'm aware there is GTK# for use with the C# language). +<li>C# is usually byte-compiled and therefore slower. Plus, .NET adds a layer of overhead to the client computer +that wxWidgets does not require. +<li>Mono hasn't proven its long-term viability yet (it's a complex system of components); wxWidgets is ready now. +<li>You may not wish to buy into Microsoft marketing spin and APIs. +<li>Microsoft may at some point sue developers of non-Microsoft .NET implementations. After all, +platform-independence is not in Microsoft's interest. +<li>.NET might never be implemented on some platforms, especially Mac and embedded variants of Linux. +<li>wxPython and other language variants provide further reasons for wxWidgets to continue. +<li>The same issue exists for Qt: if Qt sales remain strong, it's a good indication that +the market for a C++-based approach is still there. (Either that, or everyone's turning to wxWidgets!) +</ol> + +There is nothing to stop folk from developing a C# version of the wxWidgets API; +we already have bindings to Python, Perl, JavaScript, Lua, Basic, and Eiffel. +Update: a <a href="http://wxnet.sourceforge.net/" target=_new>wx.NET</a> project is now in progress. -<H3>How can I help the project?</H3> +<P> + +<H3><a name="help">How can I help the project?</a></H3> + +Please check out the <a href="http://www.wxwidgets.org/develop2.htm">Community</a> pages, +in particular the <a href="projects.htm">suggested projects</a>, and +mail the developers' mailing list with your own suggestions.<P> -Please check out the <a href="http://web.ukonline.co.uk/julian.smart/wxwin/develop.htm" target=main>Backroom</a> pages, -in particular the <a href="http://web.ukonline.co.uk/julian.smart/wxwin/projects.htm">suggested projects</a>, and -mail <a href="mailto:julian.smart@ukonline.co.uk">Julian Smart</a> or the developers' mailing list with your own suggestions.<P> +<H3><a name="newport">How do I start a new port?</a></H3> + +Please subscribe to the wx-dev <a href="maillst2.htm">developers' mailing list</a> and +ask if anyone else is interested in helping with the port, or +has specific suggestions. Also please read the <a href="standard.htm">coding standards</a>. + +<P> +Each port consists of a platform-specific part (e.g. src/msw, include/wx/msw), +a generic set of widgets and dialogs for when the port doesn't support +them natively (src/generic, include/wx/generic) and the common code +that all ports use (src/common, include/wx). By browsing the source +you should get a good idea of the general pattern.<P> + +Take a port that most closely matches your port, and strip out +the implementation so you have a skeleton port that compiles. Ask on wx-dev +first for the wxStubs port - however, any such predefined skeleton +port may be out of date, so make a judgement on whether to use it. +Perhaps it will still save you time to clean up wxStubs, and +others may benefit from this too.<P> + +You will need to define a symbol for the new port, e.g. __WXXBOX__. +Look at files such as wx/defs.h, wx/wxchar.h for areas where you'll +need to add to existing conditionals to set up wide character +support and other issues. If the GUI runs on a Unix variant, +define the __UNIX__ variable in your makefile.<P> + +Then you can start implementing the port, starting with +wxWindow, wxTopLevelWindow, wxFrame, wxDialog so you +can get the minimal sample running as soon as possible.<P> + +If GDI objects (wxPen, wxBrush, etc.) are not concepts in your +native GUI, you may wish to use very generic versions of +some of these - see the wxX11 port.<P> + +Consider using the wxUniversal widget set as a quick way +to implement wxWidgets on your platform. You only need +to define some basic classes such as device contexts, +wxWindow, wxTopLevelWindow, GDI objects etc. and +the actual widgets will be drawn for you. See wxX11, +wxMGL, and wxMSW/Univ for sample wxUniversal ports.<P> + +To begin with, you can use whatever makefiles or project +files work for you. Look at existing makefiles to see what +generic/common/Unix files need to be included. Later, you'll want to integrate support +for your port into configure (Unix-like systems and gcc under Windows), +and bakefile (for other makefiles on Windows).<P> + +Submit your port as patches via SourceForge; you might +wish to separate it into one patch that touches common headers +and source files, and another containing the port-specific code, to make +it much easier for us to review and apply the patches.<P> + +Good luck! </font>