[wxWorkshop-dev] State of Conversion to wxWidgets-2.6.1 - week 3
Status: Pre-Alpha
Brought to you by:
spicerun
|
From: <wxw...@li...> - 2005-08-05 23:01:03
|
Hello,
Time again for my weekly summary on what is going on with wxWorkshop.
We added a new Developer to the Project, Tod Filer, who has been
furthering the work to get wxWorkshop to compile with Microsoft's Visual
Studio 2003.
George Tasker was also able to get wxWorkshop to compile a week earlier
on his Visual Studio 2003 (VS2003) setup although I understand he had a
lot of headaches. Tod Filer added some patches to CVS and he reports
that he was able to get wxWorkshop to compile with his VS2003 setup as
well. It appears that both George and Tod can not start looking for the
other bugs and resolving some issues. Tod reports that his version of
the build on VS2003 also works with the wxWidgets-2.6.1 (wxW-2.6.1)
included xrc libraries, and he has been using some of the files I have
altered to include the Unicode macros and replace deprecated functions
with the only issue being the outlctrl.cpp file in the src/wspp
directory, an issue with wxArrayString handling error that is not
present with the wxArrayString handling already included in other
files. Tod also reports that he is getting an Assert Error that he
thinks is coming from the pmf libraries as well, and he is investigating
that problem. I believe both George and Tod are compiling wxWorkshop on
an ANSI build of wxMSW if I am not mistaken.
As for my progress, I have been lagging behing George and Tod as I have
been going through each source file and converting types and strings to
Unicode strings, as well as handling conversions between the two, to get
wxWorkshop to compile on my Unicode wxGTK-2.6.1 environment, which has
been a lot of work since, obviously, wxWorkshop was never written to be
Unicode aware. I have to admit that I am a lot better in picking the
functions to convert between Unicode wxStrings and char arrays than I
was when I started this project.
As most of you know, the Unicode version of wxW is much pickier about
the String types, and will not just accept a literal string as a proper
type for a Unicode string, so I have had to make a large use of the
_T("string") macro to indicate that this is to be a Unicode string, and
I've had to do a lot of wxString::FromAscii() and wxString::ToAscii()
functions to convert between char strings and wxStrings in the files.
Fortunately, the ANSI build of wxW appears to ignore the _T() macro, and
things seem to work as before the files were 'converted' to Unicode.
This makes a good case to me for always programming the wxWidgets
application like a Unicode application for future implementations, even
though it may just be built on an ANSI environment.
In addition I have been converting deprecated functions into the newer
recommended replacement functions with the most common conversions
being: First()->GetFirst(), Number()->GetCount, KeyCode->GetKeyCode,
GetSystemColour->GetColour, etc. The only deprecations I've left in
the code currently is in the diamond directory, where the g++ compiler
informs me that the Headers used in those files are deprecated, and need
to be converted to the equivalent C++ headers. For now, I am leaving
this until I get a build that executes on my Machine.
Also, a major conversion I am doing is to replace all wxStringList type
variables with the wxArrayString variables as recommended on both the
wxWidgets-2.6.1 and 2.4.2 manuals where the notation under the
wxStringList is "NB: This class is obsolete, please don't use it any
longer. You can use wxArrayString or type safe list class instead." I
am probably wrong, but I also looked up the wxStringList definition in
the include file, and I thought I saw that it is making the memory space
for the wxStringList, then copying it over to an wxArrayString. If that
is the case, I thought it would be better to use the wxArrayString from
the start without having more memory allocated than needed.
All this has led up to being able to build all of the shared libraries
in the wxWorkshop/src directories, and I have made separate *.linux
files to be able to compile just for the linux environment in all
directories without interferring with the other platform make
environments. I still need to do a lot more work with these Makefiles
before inflicting them on the public at large.
Currently, I am working on converting the .cpp files in the
wxWorkshop/ws directory, having half of them converted and compiling. I
hope to have an executable soon. All of my work is checked into the
wxWorkshop CVS repository except for the files I've converted in the ws
directory, but I expect to have those checked in the next couple of days.
My immediate future plans are to:
1) Build and troubleshoot the Executable & Sources (including fixing
some conversion mistakes I'm sure I have made).
2) Finalize the Linux Build environment (I hope to get autogen involved).
=================
Other Notes:
--Notes on the CVS Repository:
Just to sum up the State of the Repository, Before this new work was
done, the existing v0.7.0 code in the Repository was tagged as
"BEFORE_UPDATE_TO_WXWIDGETS261", and this Code is also Branched under
the Label "v_0_7_0_wxWidgets_2_4_2" for anybody who wishes to keep
developing the wxWorkshop 0.7.0 version on wxWidgets-2.4.2/2.5.x. The
MAIN branch contains all our work to convert wxWorkshop to
wxWidgets-2.6.1/2.6.2 when wxW-2.6.2 is released (in 3 days?).
--Insights to the Linux Porting I am undertaking:
It occurs to me that I have never explained to exactly which Linux
parameters I am fixing wxWorkshop to compile under, so let me some
specifications on my Linux computer that I am using to build wxWorkshop:
Computer: Sony VAIO Laptop PCG-FRV37
Processor: Pentium 4 - 2.8Ghz
Ram: 512Mbyte
Hard Disk: 60Gbyte
Linux Distribution: Gentoo Source Distribution (kept updated nightly)
<Gentoo is a versionless distribution>
Compiler: g++ v3.4.4
wxWidgets: 2.6.1 Unicode (from wxALL, but using wxGTK), compiled from
source tarball.
wxWidgets Installation Directory Prefix: /usr/local
===================
George & Tod, please correct me if I've made some inadvertent mistakes
in this E-mail. The mistakes are unintentional.
--James
|