wxworkshop-developers Mailing List for wxWorkshop

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hello,

This project is now receiving donations.

Thanks,
The SourceForge.net Crew

Hello,

This project is now receiving donations.

Thanks,
The SourceForge.net Crew

Hi Guys,

A.  Just to let everyone know that:

1)  I have done the first pass at cleaning up the wxWorkshop 
website....fixing links, and deleting all unnecessary files on the site.

2)  I have branched off the Windows code into the wxMSW_v0_80 branch so 
that the code is held uncorrupted for Windows while it is being fixed 
for the other platforms.  The code previously in the Linux_v0_80 branch 
has been merged with the MAIN branch in CVS, and development will 
continue there.

B.  While I am not in a rush to purge people from the roster of 
Developers or the roster of subscribed users to the maillist, I am 
trying to clean these rosters up in preparation of future 
participation.  Therefore, for all of you receiving this E-mailing, You 
need to let me know if you want to remain on this mailing list.  If I 
don't hear from you by March 1, 2006, I will remove you from this list.

C.  Also, I'm anticipating turning on the Donations on or shortly after 
March 1, 2006.

Stay tuned....

** wxWorkshop **
** Reorganization **

Today I have taken over as one of the Administrators of the wxWorkshop 
Project.  I look forward to re-invigorating the project, and moving it 
into the present. 

I have also added another administrator who will help with the project 
management and generally keep the group on track with the goals.

The goals of wxWorkshop hasn't changed in that the end product is still 
going to be an IDE & RAD tool for wxWidgets that will work for Linux, 
Windows, Unix, and MacIntosh platforms.  And it will still be a totally 
GPL licensed program which is the license wxWorkshop has been all along.

I am going to make some changes to how wxWorkshop is developed and 
managed, with the idea that we're going to get a release yet out of this 
project, and a very powerful program that wxWidgets Developers will want 
to use.  Therefore, some of the changes:

    * wxMSW Development on wxWorkshop will be put into its own Branch in
      the CVS Software Repository, and will be suspended until
      wxWorkshop is fixed to work correctly on wxGTK, wxX, and wxMAC
      platforms.  Once the code does work on those platforms, the wxMSW
      code will be merged back into the repository main branch, and all
      wxWidgets platforms will continue.
    * wxWorkshop will now use good Portable Coding Standards on all
      platforms, which will be rigidly enforced.  There is no reason
      that the exact same source code can not work on all platforms.
    * Also, wxWorkshop will be coded entirely in Unicode.  The Unicode
      macros in wxWidgets will still compile on ANSI versions of
      wxWidgets so that the Developers using wxWorkshop will now have a
      choice depending on which wxWidgets version they use.
    * No wxWorkshop releases will occur unless wxWorkshop works on all
      platforms equally well with the features implemented for that release.
    * wxWorkshop will now be refactored to replace obsolete and
      deprecated code and libraries, and made to work with the latest
      wxWidgets toolset and platforms at the time of the releases.
    * wxWorkshop will now accept contributions:  Labor AND Monetary
      contributions to help those of us to bring wxWorkshop to completion.
    * A new timeframe will be set up to the completion of wxWorkshop. 
      If it is just myself working on wxWorkshop, I predict that I will
      have the first full release of wxWorkshop sometimes in 2009;
      sooner if I have help.  Of course, this date is just an estimate
      and may change.  (BTW, I will not abandon developing this tool
      since it is critical to the success of my future projects).
    * I make the pledge to Developers that whatever code they contribute
      will stay in wxWorkshop under the GPL or LGPL licensing.  None of
      the source code will be allowed to be allocated into closed-source
      environments.  Developers, as the authors of the code, will retain
      full rights to the code under the GPL.  At no time will wxWorkshop
      become a closed-sourced program/application.

So, who do we need to get wxWorkshop implemented and released?  We need:

    * wxGTK, wxX, and wxMAC contributing programmers (we'll be ready for
      wxMSW contributing programmers once wxWorkshop is consistent on
      all platforms).  Initially the work will be total refactoring,
      replacing deprecated functions/libraries, and bringing the source
      code up to good programming standards (example:  All hardcoded
      strings and numbers to be moved to include files, and referred in
      the rest of the code as defined symbols.  This makes for much
      easier translation of wxWorkshop to other languages)
    * Autotools/Autoconf & Bakefile experts who can work with the build
      system to allow for the libraries to be built as either static or
      dynamic libraries, and allow the entire source code to be built as
      debug or release versions.
    * Contributors who can correct and write the manuals, user guides,
      and tutorials.

    I am hoping for a good resurrection of wxWorkshop and hope many of 
you agree that wxWorkshop has the potential to be an excellent tool for 
the community.  I look forward to working with everyone in making a good 
and serious cross-platform tool that helps adoption of wxWidgets everywhere.

--Spicerun

Progress still continues on wxWorkshop although some authors are still 
declaring the project extinct (Latest alert I got was from this 
article:  
http://www.pcplus.co.uk/tutorials/default.asp?pagetypeid=2&articleid=37317&subsectionid=379).  
I will love to see the reactions when we burst forward with another 
release, whenever that will be.  Realistically, I'm thinking December 
where at least the basic functions have been restored, and, surely, 
wxWidget-2.6.2 will have been released by then.  Meanwhile there are 
some interesting hurdles to overcome.

I have tracked down the area of a problem that I was having with the 
wxFileDialog Class.  (This bug is only in wxGTK) This bug is listed on 
wxWidgets Bug  Tracker #1287999 where the normal gtk++ wxFileDialog 
crashes in the ShowModal Function when it is passing through gnome-vfs 
to gtk+.  Apparently it doesn't happen on all Linux distributions, but I 
know of 2 machines under different owners that have the problem, both 
are Gentoo Linux machines.  For now, I am working with a workaround from 
Julian Smart that allows me to work with a Generic File Open Dialog Box 
(also mentioned in that bug report).  I will continue tracking that 
problem down, but it is a difficult one since it eludes the gdb debugger 
(in fact, works under the debugger but not during normal operations).  I 
will be spending a lot of time this coming week trying to find the 
problem (via printfs apparently) in tracing the program flow between 
wxWorkshop<>gnome-vfs<>gtk+.  I wish I knew when I'll be able to fix 
this problem.

Meanwhile I have gone forward with more of the code development on 
wxWorkshop.  I've cleared up minor bugs, (including fixing the icons & 
Splash Screen to say wxWidgets instead of wxWindows),etc.  I'm looking 
at some file parsing errors which I'm sure are related to my conversion 
of wxStringLists to wxArrayStrings, so I will be working with that bug, 
as well as looking to getting the Editor up & running again.

I heard briefly from George was mentioned about how useful it would be 
to make the startup config file in the xml format, something that I will 
definitely be looking into.  I haven't heard anything from Tod at all 
this week so I assume he has been extremely busy.

BTW, wxWorkshop is not dead, and I sent an E-mail to pcplus.co.uk to let 
them know.  The automated response was interesting:  "I'm out sunning 
myself on the beaches of Athens at the behest of Acer."

The wxWorkshop work continues on....stay tuned. 

--James

Hello again,

Progress continues on wxWorkshop although a little slower than previous 
weeks.

I have been working on the Linux build and I was able to clear a 
non-fixed Font assert error on wxWorkshop when it starts up.  The 
problem was that the Courier font being selected is not a fixed-font 
under Linux (unless you're running a true-type font server under 
Linux).  I changed the code to select the default fixed-font under wxGTK 
while still selecting the fixed Courier font under wxMSW.

I am still working out the problem with the File Open Dialog Box when 
File Open is selected from the Menu.  On the Linux build the program 
segfaults as soon as the File Dialog box displays, and I have tracked it 
down to something going wrong in the wxDialogManager::OnFileOpen() 
function.  I am still trying to understand what the exact error is that 
function.

I have also been working on the autoconf scripts which have taken a 
little longer than I had hoped.  I should have it worked out in a couple 
of weeks.

The Linux sources can be checked out from the Linux_v0_80 branch.

I haven't heard from the other 2 people on the Project so I assume 
they've been busy.  I believe Tod is designing a new layout for the 
Project webpage and I'm anticipating seeing it soon.  Until Tod's pages 
are ready, I've done a little modification on the web pages to put up 
current news in the news link, and fix some Unix compiling 
instructions.  On the main page proper, I only changed the 'Built by 
Windows' to the 'Built by wxWidgets" logo, and added the sourceforge 
logo on the page as well (Sourceforge requires their logo on all of the 
projects homepages they host).

Anyhow, work continues on....stay tuned.

--James

Hello,

It's been 2 weeks since the last Progress Status on wxWorkshop, but 
progress has been continuing....

It has gotten apparent that there are some differences between the 
Windows compiler & how it handles the source code, and  the g++ compiler 
used on Linux, and the way it handles source code, which is why I have 
created a Linux_v0_80 Branch for the linux code work.  Eventually we 
will be merging this code back into the main branch.  So currently we 
have the following in the wxWorkshop CVS Repository on sourceforge.net:

HEAD or MAIN Branch - wxWorkshop v0.7.5 for Window (only the ansi 
version has been tested), that builds with MS Visual Studio 2003, and 
creates a binary that can even do simple editing on a file, but nothing 
else.

Linux_v0_80 Branch - wxWorkshop v0.8.0 for Linux (ansi & unicode 
versions tested), that builds with g++ v4.0.1, and creates a binary that 
does nothing much than display the initial dialog box and the about 
box.  This Linux version is set up to build with wxWidgets-2.6.1, 
unicode or ansi version, g++ v4.0.1 for the C++ compiler, and the 
wxWorkshop libraries are being linked statically into the wxWidgets 
binary (in the future, the user will get to decide between shared 
dynamic libraries or statically linked libraries).  Also, if the unicode 
build is selected to be built, an external libiodbc library will need to 
be installed to be linked with the binary.

By the above, you can determine that we have reached a minor milestone, 
which is we now have wxWorkshop building with wxWidgets-2.6.1 with 
source code converted for Unicode (but it can also build on the Ansi 
version of wxWidgets) for both Windows (via MS Visual Studio 2003), and 
Linux (g++ v4.0.1).

The immediate next step for me which should not take long is to make the 
Linux package use the autoconf utility so that a package may be created 
to allow a linux user to just put the sources on their machine, and with 
running 3 commands (configure, make, and make install), be able to 
create an executable binary for their system.

Once this is done, we can now start tackling the features (debugging why 
existing features aren't working), and start getting the new features 
implemented.  The fun really starts now.

Tod & George will be helping me getting the source code more common 
between our 2 platforms and we will be working on the features together 
as we continue to resurrect wxWorkshop.  We are expecting that the Web 
Page for wxWorkshop will be revamped soon.

The fun is only beginning.  :)  Stay tuned.

--James (The Spicerun)

Hello,

Well, progress has been slow this week in making wxWorkshop compile on 
Linux systems.  I am still hammering out the Class 'hidden functions' 
problem with g++.  I have found that the soon to be released g++-4.x 
version will be able to handle it, but the problem is that it will be a 
while before most Linux distributions have included the g++-4.x series 
(g++-4.x will also require some attributes not found in MSVC and BCC, so 
there will need to be some #ifdefs in the future for that).  Currently, 
most up-to-date distributions are running the g++-3.4.x series.

So, for compatibility, and still hoping that the code can stay 
compatible with MSVC++ and BCC, I am rewriting sections of the pmf 
library to unhide those functions so hopefully everyone can build 
wxWorkshop.  Currently, I'm tracking down a problem in the 
lseditor.h/lseditor.cpp where g++ is getting upset at the return value 
from one of these hidden functions.

Once these functions are unhidden, and all of the compilers can see the 
class functions, then everybody should be able to build wxWorkshop, then 
we can look at fixing some more of the problems (as well as getting the 
source code into shape for a distribution package which is sorely needed).

I believe Tod Filer is planning to examine and update the wxWorkshop Web 
Page.

Stay tuned....

--James

I'm doing some CCs this week to some people since I'm not sure they are 
on the development list.  This is a one time copying only.

Hello,

Time again for my weekly report on the progress to converting wxWorkshop 
to wxWidgets-2.6.1

Progress this week slowed as I ran into a lot of problems in linking the 
object files for wxWorkshop in the final ws directory.

I have gotten all of the source files converted well enough to compile 
on my Linux unicode wxWidgets-2.6.1 platform by adding all of the 
Unicode macros, and removing Deprecated functions, of which 99% of them 
have been changed to the recommended replacement functions).

In the ws directory alone, I have not yet converted the wxStringList 
variables to the wxArrayString types as I have been working on the 
unresolved references problems when trying to link & create the final 
program.

And this has been my delay all week, that I have a lot of unresolved 
class members in the libraries which took a while to track down.  I have 
found that those class members are in the pmf library.  After some time 
as to analyzing why the classes aren't resolving, I have class members 
like TPinPainterBase::mPinPainterBase(int tc) exist in the pmf files, 
but the unresolved reference is TPinPainterBase::TPinPainterBase(int 
tc).  I have a suspicion that the Visual Studio 2003 C++ is taking these 
symbols and is somehow resolving them, allowing the program object files 
to be linked.  However, g++, the GNU compiler used on linux, does not 
know that these class members are one in the same, and does not see the 
problem class members it needs.

I will be converting the pmf files to provide the proper classes for the 
g++ compiler this coming week, and hope to have an executable soon for a 
baseline to start with.  Also, I need input from people who successfully 
compile wxWorkshop on their Windows environment to see what adjustments 
can be made to the files that will be acceptable to the MS C++ and g++ 
compilers.

I need some help from the Visual Studio Guys as to why these classes resolve and build in 
Windows.

Stay tuned,
--James

Well, I finally got everything converted and compiling on linux, but now 
I'm getting the following errors in linking:

This is building the application in the ws directory...

In part:

g++  -o ws aboutdialog.o bmpeditor.o cardglyph.o build_svc.o 
indexing_svc.o helpfinder_svc.o classfinder_svc.o codecompl_svc.o 
scriptproc.o dmbrowser.o dmcmn.o eventeditor.o eventgen.o eventinfo.o 
gedthandler.o hellosvc.o labeleditdlg.o markersvc.o membereditor.o 
menuedit.o nbookglyph.o pm_sample.o propedit.o res_doc.o res_templ.o 
resbrowser.o scripttempl.o sizerglyphs.o txtrecset.o ui_lookeditor.o 
ui_lookrenderer.o widgeteditor.o wkp_main.o wspmcore.o grep_eng.o 
findinfile_svc.o findinfile_dlg.o dbsrc/Idxrel.o 
-L~/Projects/wxWorkshop-0.7.5/lib -lpmfd `wx-config --libs fl` -lawtlayd 
-ldiamondd `wx-config --libs xrc` -lwsppd -lsourceparserd -lxobjectsd 
-lwsutilsd -leqsolverd -lstdc++  `wx-config --libs`
build_svc.o: In function `ErrorPinPainter::ErrorPinPainter(int)':
build_svc.cpp:(.text+0x114): undefined reference to 
`TPinPainterBase::TPinPainterBase(int)'build_svc.o: In function 
`ErrorPinPainter::ErrorPinPainter(int)':
build_svc.cpp:(.text+0x138): undefined reference to 
`TPinPainterBase::TPinPainterBase(int)'build_svc.o: In function 
`wxPMBuildService::OnNextMessage(wxCommandEvent&)':
build_svc.cpp:(.text+0x63c8): undefined reference to 
`wxTextEditorView::GetModel()'
build_svc.cpp:(.text+0x64bf): undefined reference to 
`TPosition::TPosition(unsigned int, unsigned int)'

...etc.
.....

Sure enough, I go checking and can't find any references to a 
TPinPainterBase class at all.  Yet this compiles unders Windows, so my 
question is What library or file am I missing?  Any comments?

Thanks for any help,
--James

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

wxw...@li... wrote:
> In the Visual Studio 2003 build, I already use the XRC in wxWidgets so it
> does work.
>   
Excellent News.  That will help tremendously.
> Maybe you should upgrade to a Windows computer ;)
>   
As the old quote goes, "They said to use Windows or better, so I 
installed Linux."  ;)

--James

>   
>> -----Original Message-----
>> From: wxw...@li...
>> [mailto:wxw...@li...]
>> Sent: Wednesday, August 03, 2005 9:26 PM
>> To: wxw...@li...
>> Subject: [wxWorkshop-dev] Finally, more progress...
>>
>> Finally, I've got the library directories building and installing in
>> /usr/local/lib in my case.  So now I am working on the ws directory,
>> hoping to have an executable soon.  I am also going to try to use the
>> xrc libraries in wxWidgets-2.6.1 rather than the one included in the
>> contrib subdirectory.
>>
>> Stay tuned...
>>
>>
>>     
>   

In the Visual Studio 2003 build, I already use the XRC in wxWidgets so it
does work.

Maybe you should upgrade to a Windows computer ;)

Tod

> -----Original Message-----
> From: wxw...@li...
> [mailto:wxw...@li...]
> Sent: Wednesday, August 03, 2005 9:26 PM
> To: wxw...@li...
> Subject: [wxWorkshop-dev] Finally, more progress...
> 
> Finally, I've got the library directories building and installing in
> /usr/local/lib in my case.  So now I am working on the ws directory,
> hoping to have an executable soon.  I am also going to try to use the
> xrc libraries in wxWidgets-2.6.1 rather than the one included in the
> contrib subdirectory.
> 
> Stay tuned...
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> wxWorkshop-developers mailing list
> wxW...@li...
> https://lists.sourceforge.net/lists/listinfo/wxworkshop-developers

Finally, I've got the library directories building and installing in 
/usr/local/lib in my case.  So now I am working on the ws directory, 
hoping to have an executable soon.  I am also going to try to use the 
xrc libraries in wxWidgets-2.6.1 rather than the one included in the 
contrib subdirectory.

Stay tuned...

Hi guys,

I think it is time for another progress report from me again for 
converting wxWorkshop to wxWidgets-2.6.1.  As you know, I am fixing the 
Make files and compile/build process for the Unicode Linux platform 
(wxGTK port).

Since last week, I've finally gotten the files in /src/pmf converted an 
building to make another library.  I only have one more library 
directory left, and that is proving to be more challenging as I am 
replacing the Deprecated functions with the recommended functions in 
wxWidgets-2.6.1.  The directory I am working on is /usr/wspp.  The fun 
part in this directory is replacing all of the wxStringList variables, 
which are deprecated in 2.6.1, and replacing them with wxArrayString 
variables as recommended.  I will continue to work on this directory 
this next week.  Hopefully I will finish it shortly, and be able to 
start on the last 2 directories.

I have been looking at the Makefile and source code in the /ws directory 
and am preparing to tackle it next.  I am still deciding if I should 
bother with the xrc directory at this time, or try to make this program 
work with the wxrc library already in the wxGTK port.  I need to get 
more information on this.

All of my work so far is checked into the CVS Repository on the Main Branch.

Stay tuned....

--James (aka Spicerun)

Hi guys,

I think about Every weekend I'm going to send a State of the Conversion 
message to let you guys how things are progressing.....

Since I've been working on the wxWorkshop conversion to wxWidgets-2.6.1 
Unicode:

--I am now able to create libraries from the awtlay, diamond, wsutils, 
and xobject directories.  The files do compile and build in the diamond 
directory, however, I get many Warnings about deprecated C++ Header 
files.  I searched the Internet for a possible update to the diamond db 
source files, and found that the source & diamond db project have 
totally disappeared.  Later, when we are adding features to wxWorkshop, 
I would like to propose that the diamond db gets replaced by whatever 
database that the wxDB class will hook to, as well as deciding what a 
suitable Database will be.

--I am concentrating on the compiling/building for Linux, and I hope I 
have the Makefile.linux files generic enough to work on most Linux 
distributions.  For your reference, I am converting wxWorkshop to work 
on wxWidgets-2.6.1 (wxGTK), unicode version, compiled with g++ v3.4.4.

--I have changed the default Makefiles to now give a message directing 
the user to use one of the other Makefile.* files when making.  It is my 
hope that the other Makefiles for the other platforms will also be 
updated to work with their respective platforms.  Obviously, I'm 
developing using the Makefile.linux files.  And the original default 
Makefiles have been moved to Makefile.org files, so they can be used as 
well if needed.

--Plans for this coming week, to continue to convert the remaining 4 
directories to compile & build making the whole program.  From here it 
gets more difficult as I am running into issues with Deprecated 
functions that have no direct replacement in wxWidgets-2.6.1, and also 
there are some additional conversions I have to do to convert char types 
to wxString types, and wxStrings to ints, etc. that are not 
straightforward.  In My opinion, this just shows that when programming 
in wxWidgets, you do yourself a favor by sticking the wxWidgets types 
like wxChar and wxString, and only deal with chars, and arrays only as 
necessary.  This is the what I've done in the past with other wxWidget 
programs, and I note this approach works very well.

My Next Report will be next weekend.

Regards everyone,
--James Rasmussen
aka Spicerun

Hi all,

I've started checking in some updated files to work with 
wxWidgets-2.6.1.  I have made *.linux Makefiles & environment files, and 
have changed some of the sources to use Unicode Strings (_T() macros, 
etc.), and have replaced deprecated functions with the 2.6.1 function.  
So far, only the /src/awtlay and /src/diamond will compile and create 
libraries in the wxWorkshop/lib directory, but to build, you will need 
to run make in the appropriate directory under the /src/directory.

My build is: 
     Compiler: g++ version 3.4.4

     wxWidgets-2.6.1 libraries are installed in /usr/local/lib with the 
includes in /usr/local/lib/wx.  The wx-config script is in /usr/local/bin.

     My wxWidgets-2.6.1 libraries are compiled for Unicode.

     I am concentrating on building just for linux with priority in just 
getting everything to compile & build.  Troubleshooting will come 
immediately after.

I am checking the code into the head, but I have labeled it 
BEFORE_UPDATE_TO_WXWIDGETS_2.6.1, and it is now on the v_0_7_0_WXW_2_4_2 
branch if someone still wants to continue to work with the previous 
version of wxWorkshop that is made for wxWindows-2.4.2 & 2.5.1.

I will add more files as I get them converted..

--James

wxw...@li... wrote:
>
> I would be willing to help in whatever ways I can.  Time is a little 
> lacking at the moment for me, however I can definitely give it some 
> good testing on Slackware Linux 10.1/wxGTK-2.6.1 and Windows 2000 
> Professional.

Nice.

>
> I also may be able to assist with bakefiles (which will allow for 
> better operating system interchangeability).

I may take you up on that Michael since I know nothing about bakefiles.

Thanks, much.
--Spicerun

> Anyhow, I hope others will join too.  The only things you guys may not 
> like is that right now I want to focus on the RAD tool aspects.  Myself, 
> I'm looking for a good replacement for wxGlade.  wxGlade is OK, but I 
> don't want to program or run wxPython (just my preference), and right 
> now, I'm seeing problems with wxGlade trying to work with version 2.6.1.

I would be willing to help in whatever ways I can.  Time is a little 
lacking at the moment for me, however I can definitely give it some good 
testing on Slackware Linux 10.1/wxGTK-2.6.1 and Windows 2000 Professional.

> By the way, be patient with me, I'm just now starting to convert the 
> files (and will apparently be adjusting the make environment to start 
> using the wx-config options rather than the .env files needed in the 
> existing projects.  This may take me a while.  I might suggest that you 
> get MinGW (with MSYS tools) on your system, then compile the wxMSW port 
> of wxWidgets on it so you can experiment with Windows make files under 
> MinGW.  My goal is to have one set of sources, but a different Makefile 
> to match the platform the program is made on.  It looks like the 
> original project does this already.

I also may be able to assist with bakefiles (which will allow for better 
operating system interchangeability).

> --Spicerun

~Michael

wxw...@li... wrote:
> Hi,
>    I am surprised and delighted that someone is still looking at this 
> project. I am also surprised that I was still registered in the 
> mailing list!
Hey, we can all use the help we can get.
>    I am a total novice, and I once tried to understand why this 
> project died. I have since given up trying to make sense of it. I 
> needed a IDE to begin learning about C/C++ and wxwindows/wxwidgits and 
> the mingw compiler.
There is an ide that works well with MinGW, but not a RAD Tool, I 
believe it is Visual-MinGW, (http://visual-mingw.sourceforge.net), that 
I used when I had a WinXP machine and making wxWIdgets programs for both 
Windows & Linux for my employer.  Now, I work for another employer and 
don't have access to a Windows machine.

> Others that I have found do not make it easy. I hoped that this was 
> the answer. There was an attempt about a year ago and sadly I was 
> unable to help. The project was discouraged by one of the developers.
Why was it discouraged?  If that is the project I read about trying to 
make the wxWidgets classes match up with MFC classes, then, yeah, I can 
understand why.  Personally, I think it would be a big mistake to 
emulate MFC in wxWidgets, and think it would just be better if wxWidgets 
interoperated with MFC and other classes instead.  If that wasn't the 
reason, I'd be interested to know why this project was being 
discouraged?  Only motivation I can think of, then, would be that 
someone wants to steer people to their pay versions of their IDEs 
instead of letting people use free versions.
>    I am unsure how I can help... I currently use a windows 2000 system.
Even if just testing on your system is help that would be appreciate I 
would think.

Anyhow, I hope others will join too.  The only things you guys may not 
like is that right now I want to focus on the RAD tool aspects.  Myself, 
I'm looking for a good replacement for wxGlade.  wxGlade is OK, but I 
don't want to program or run wxPython (just my preference), and right 
now, I'm seeing problems with wxGlade trying to work with version 2.6.1.

By the way, be patient with me, I'm just now starting to convert the 
files (and will apparently be adjusting the make environment to start 
using the wx-config options rather than the .env files needed in the 
existing projects.  This may take me a while.  I might suggest that you 
get MinGW (with MSYS tools) on your system, then compile the wxMSW port 
of wxWidgets on it so you can experiment with Windows make files under 
MinGW.  My goal is to have one set of sources, but a different Makefile 
to match the platform the program is made on.  It looks like the 
original project does this already.

--Spicerun

Hi,
    I am surprised and delighted that someone is still looking at this 
project. I am also surprised that I was still registered in the mailing 
list!

    I am a total novice, and I once tried to understand why this project 
died. I have since given up trying to make sense of it. I needed a IDE 
to begin learning about C/C++ and wxwindows/wxwidgits and the mingw 
compiler. Others that I have found do not make it easy. I hoped that 
this was the answer. There was an attempt about a year ago and sadly I 
was unable to help. The project was discouraged by one of the developers.
    I am unsure how I can help... I currently use a windows 2000 system.

chips42

wxw...@li... wrote:

> Hi all,
>
> (I have sent a copy of this E-mail to George Tasker)
>
> I have been looking for a native C++ program dialog editor for wxWidgets
> when I found the wxWorkshop link.
>
> I have pulled the code out of CVS and am now converting it to
> wxWidgets-2.6.1 under Linux (obviously I'm using the wxGTK platform
> although I built wxWidgets using the wxAll port tarball).  I do think
> this project has potential, and I want to see if I can get the project
> going again (at least for myself).  Admittedly I am just looking for a
> wxWidgets Dialog Editor (RAD tools), especially an alternative to 
> wxGlade (ie - I
> don't want to program or have wxPython on my system...just my 
> preferences).
>
> Anyhow, would you be interested when I get it fixed up?  I'm calling my
> version 0.7.5 even though I know it has no bearing on anything right now.
>
> I'm curious too as to why this project seems to have died?  I think
> there are a lot of people who would be interested in this.
>
>
> My plan is:
>
> Step 1).  Get wxWorkshop to compile with wxWidgets-2.6.1, and I've got 
> a few more conversions to get it to work with my Unicode version of 
> wxWidgets on my Linux system (I run Gentoo btw).  However, I've got a 
> good part of the pmf files to compile already (I'm still working on 
> keybinder.cpp).  Yes, I'm  just getting started.
>
> Step 2).  Get wxWorkshop to work with Autoconf, and to use Autoconf to 
> set the options to compile between Unicode and normal ASCII versions.
>
> Step 3).  Once the source and make files are set up, then make a new 
> set of Make files only for wxWidgets and MinGW.  (I don't want to 
> support Cygwin as there are licensing issues with distributing the 
> cygwin .dll files).  Here I will need some help as I don't have a 
> Windows machine to test this on.  I've done a lot of work with MinGW 
> and wxWidgets before at a previous company I've worked with, and they 
> were delighted to have both a Windows and Linux version of the program 
> with the exact same source files.
>
> Step 4)  Start working on the bugs and get them resolved.
>
> Step 5)  Redraw up a List of Features & start getting them implemented.
>
> Obviously it is going to take me a little time to get from Step 1 to 
> Step 5, but I need this program and look to carry it through.  I hope 
> we could get rekindle some interest and get some help on it too.
>
> I believe this program can be a significant contribution to the 
> wx-world.  I hope there are still some of you developers out there who 
> agree.
>
> Thanks,
> --Spicerun
> aka James Rasmussen
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar 
> happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted 
> by HP,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> wxWorkshop-developers mailing list
> wxW...@li...
> https://lists.sourceforge.net/lists/listinfo/wxworkshop-developers
>

Hi all,

(I have sent a copy of this E-mail to George Tasker)

I have been looking for a native C++ program dialog editor for wxWidgets
when I found the wxWorkshop link.

I have pulled the code out of CVS and am now converting it to
wxWidgets-2.6.1 under Linux (obviously I'm using the wxGTK platform
although I built wxWidgets using the wxAll port tarball).  I do think
this project has potential, and I want to see if I can get the project
going again (at least for myself).  Admittedly I am just looking for a
wxWidgets Dialog Editor (RAD tools), especially an alternative to 
wxGlade (ie - I
don't want to program or have wxPython on my system...just my preferences).

Anyhow, would you be interested when I get it fixed up?  I'm calling my
version 0.7.5 even though I know it has no bearing on anything right now.

I'm curious too as to why this project seems to have died?  I think
there are a lot of people who would be interested in this.

My plan is:

Step 1).  Get wxWorkshop to compile with wxWidgets-2.6.1, and I've got a 
few more conversions to get it to work with my Unicode version of 
wxWidgets on my Linux system (I run Gentoo btw).  However, I've got a 
good part of the pmf files to compile already (I'm still working on 
keybinder.cpp).  Yes, I'm  just getting started.

Step 2).  Get wxWorkshop to work with Autoconf, and to use Autoconf to 
set the options to compile between Unicode and normal ASCII versions.

Step 3).  Once the source and make files are set up, then make a new set 
of Make files only for wxWidgets and MinGW.  (I don't want to support 
Cygwin as there are licensing issues with distributing the cygwin .dll 
files).  Here I will need some help as I don't have a Windows machine to 
test this on.  I've done a lot of work with MinGW and wxWidgets before 
at a previous company I've worked with, and they were delighted to have 
both a Windows and Linux version of the program with the exact same 
source files.

Step 4)  Start working on the bugs and get them resolved.

Step 5)  Redraw up a List of Features & start getting them implemented.

Obviously it is going to take me a little time to get from Step 1 to 
Step 5, but I need this program and look to carry it through.  I hope we 
could get rekindle some interest and get some help on it too.

I believe this program can be a significant contribution to the 
wx-world.  I hope there are still some of you developers out there who 
agree.

Thanks,
--Spicerun
aka James Rasmussen

confirm 931490=20
 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f
=20
 Sponsor:
 Natsabe.it la pi=F9 grande erboristeria multimarca online.
Solo prodotti di altissima qualit=E0.=20

 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=3D1308&d=3D20040=
811

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.

With many thanks for your participation,
Benno Luthiger

PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________
Hi everyone,

This posting is here to prompt discussion in whether or not the wxWorkshop
project has enough support to be revivied and actively pursue a
working/finished product.

Support would come in three forms:

1) Active developers willing to spend their time and efforts on learning the
existing code,  fixing existing functionality, and funally enhancing
wxWorkshop functionality.

2) Financial support for developers tackling the tasks of wxWorkshop may be
an option that might work for some companies.  When Aleks left the project,
he was searching for a way to feed himself, and had to leave off his efforts
to get a paying job.  I'm not sure whether funding would be enough to ensure
people spending quality time coding, but I put it out there as an option.

3) Testing/Debugging work is required.  But to do that, we need people that
are committed a bit more than just a casual observer stopping by to see
where progress has advanced to.  People who may not have time to dive in
full force, but would be willing to tackle bugs submitted to the bug
tracker, or take on smaller tasks.

So to begin, lets find out what everyone's commitment level is, and we can
move from there.

Thanks all for your interest!!
g

2004	Jan	Feb	Mar	Apr	May (4)	Jun	Jul	Aug (1)	Sep	Oct	Nov	Dec
2005	Jan	Feb	Mar	Apr	May	Jun	Jul (8)	Aug (7)	Sep (3)	Oct	Nov	Dec
2006	Jan	Feb (3)	Mar (2)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

wxworkshop-developers Mailing List for wxWorkshop

wxworkshop-developers — Developers mailing list for wxWorkshop