X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/ce3ed50dbe32d118321082db84c3a9abb047d5b7..06b781c7c630ff8c2ab30211cb4351b4cb5bfb47:/docs/html/faqgen.htm?ds=sidebyside diff --git a/docs/html/faqgen.htm b/docs/html/faqgen.htm index 2e059f5675..4bcbaf21df 100644 --- a/docs/html/faqgen.htm +++ b/docs/html/faqgen.htm @@ -8,10 +8,10 @@ - +
- @@ -30,10 +30,11 @@ different platforms. wxWindows defines a common API across platforms, but uses t so your program will take on the native 'look and feel' that users are familiar with.

Although GUI applications are mostly built programmatically, there is a dialog editor to help -build attractive dialogs and panels.

+build attractive dialogs and panels. Robert Roebling's wxDesigner +makes light work of resizable, portable dialogs.

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. +such as CLIPS, Python, Scheme, XLisp and Perl, and there is a Python interface for wxWindows 2.

Can I use wxWindows 2 for both proprietary (commercial) projects, and GPL'ed projects?

@@ -61,6 +62,164 @@ 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.

+See Users for a list of some users and their applications, and +also Feedback for comments.

+ +

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 are supported by wxWindows 2?

+ + +

+ +

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:

+ +

+ +

+ +

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 SourceForge server, 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.

+

- + + wxWindows 2 FAQ: General