X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/ce3ed50dbe32d118321082db84c3a9abb047d5b7..af7451accccaac0504a87fd06a7bf3619652b4fe:/docs/html/faqgen.htm
diff --git a/docs/html/faqgen.htm b/docs/html/faqgen.htm
index 2e059f5675..cdea35dd73 100644
--- a/docs/html/faqgen.htm
+++ b/docs/html/faqgen.htm
@@ -61,6 +61,191 @@ wxWindows 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.
+
I am about to start a wxWindows 1.xx project. Should I use 2 instead?
+
+wxWindows 2 is still in beta but it's actually pretty useable (Windows, GTK, Motif).
+
+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.
+
+
Why would I want to use wxWindows 2 in preference to wxWindows 1.xx?
+
+Some reasons:
+
+
+- In 2 there is far more flexibility, for example in the way windows can be
+nested, and the way events are intercepted.
+
- There is more functionality for producing sophisticated applications,
+for example using the wxTreeCtrl and wxListCtrl classes.
+
- There is better C++-conformance (such as usage of wxString and const) which
+will make your applications more reliable and easier to maintain.
+
- wxWindows 2 will be better supported than 1.xx.
+
- The GTK version is attractive for people interested in writing Linux and GNOME
+applications.
+
- The Mac version will be one of the best frameworks available on that platform.
+
+
+How can I prepare for wxWindows 2?
+
+To make porting to wxWindows 2 easier in the future, take a look at some
+tips for writing existing code in a 2-compatible way.
+
+
How much has the API changed since 1.xx?
+
+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.
+
+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).
+
+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.
+
+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.
+
+
What classes have disappeared?
+
+wxForm, wxTextWindow (subsumed into wxTextCtrl).
+
+Does wxWindows 2 mean that wxWindows 1.xx is dead?
+
+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.
+
+
What platforms will be supported by wxWindows 2?
+
+
+- Windows 3.1, Windows 95/98, Windows NT;
+
- Linux and other Unix platforms with GTK+;
+
- Unix with Motif or the free Motif clone Lesstif;
+
- Mac (coming later in 1999);
+
- A BeOS port is being investigated.
+
- A Windows CE port is being investigated.
+
- 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.
+
+
+
+
How does wxWindows 2 support platform-specific features?
+
+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
+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
+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
+as the MDI classes, have been emulated on other platforms. I can imagine
+that even wxTaskBarIcon may be implemented for Unix desktops one day.
+
+
+In other words, wxWindows 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.
+
+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.
+
+Another reason why wxWindows 2 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.
+
+
Does wxWindows use STL? or the standard string class?
+
+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
+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.
+In addition, use of templates can lead to executable bloat, which is something
+wxWindows 2 is strenously trying to avoid.
+
+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
+by being able to modify our own string class. Some compatibility with the string class
+has been built into wxString.
+
+There is nothing to stop an application using templates or the string class for its own
+purposes.
+
+
Is there a rich edit/markup widget for wxWindows 2?
+
+These are the possibilities so far:
+
+
+- The richedit sample has a text editor that does markup.
+
- See www.scintilla.org for
+a very nice syntax-highlighting editor widget. Robin Dunn is writing a wxWindows wrapper
+for this widget.
+
- If you only need to display marked-up information, rather than edit it,
+then wxHTML will suit your needs. wxHTML is built into wxWindows - please see the reference
+manual for details, and samples/html.
+
- There are rich edit widgets in both WIN32 and GTK+, but there is currently
+no wxWindows wrapper for these.
+
+
+
+
+
How is wxWindows 2 being developed?
+
+We are using the CVS system to develop and maintain wxWindows. This allows
+us to make alterations and upload them instantly to the server in Edinburgh, from
+which others can update their source.
+
+To build source from CVS, see the file BuildCVS.txt in the top-level wxWindows distribution
+directory.
+
+
How is wxWindows 2 distributed?
+
+By ftp, and via the wxWindows CD-ROM.
+
+
What are the plans for the future?
+
+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.
+
+Other possibilities include: DCOM/CORBA compatibility; a wxWindows book;
+wxStudio, an IDE;
+other platforms; other interface abilities such as speech output.
+
+We will investigate the possibility of compiler or operating system vendors bundling wxWindows with
+their product.
+
+The high-level goal of wxWindows is to be thought of as the number one C++ framework,
+for virtually any platform. Move over, MFC!
+
+
What about Java?
+
+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.
+
+
How can I help the project?
+
+Please check out the Backroom pages,
+in particular the suggested projects, and
+mail Julian Smart or the developers' mailing list with your own suggestions.
+