3.0-RC1

[Vadim Zeitlin]

Hello,

I'm going to build 3.0-RC1 sources tomorrow. I don't think we need
binaries for this release so I'm just going to upload the sources and
announce them. Please let me know if I should wait for anything before
doing this.

Thanks,
VZ

[Fulvio Senore]

May I humbly ask if there is any chance to have this ticket fixed?

http://trac.wxwidgets.org/ticket/14734

I would like to switch to Cocoa but at the moment I am stuck with Carbon
because help from modal dialog is not working.

Fulvio Senore

[Vadim Zeitlin]

On Sat, 05 Oct 2013 18:29:18 +0200 Fulvio Senore wrote:

FS> Il 05/10/2013 17.07, Vadim Zeitlin ha scritto:
FS> > Hello,
FS> >
FS> > I'm going to build 3.0-RC1 sources tomorrow. I don't think we need
FS> > binaries for this release so I'm just going to upload the sources and
FS> > announce them. Please let me know if I should wait for anything before
FS> > doing this.
FS> >
FS>
FS> May I humbly ask if there is any chance to have this ticket fixed?
FS>
FS> http://trac.wxwidgets.org/ticket/14734

I have no idea about how to fix this so I can't plan to make 3.0 release
only when it's fixed as this could mean that this release is never done at
all. Besides, using ShowWindowModal() looks like a decent enough workaround
for me...

Regards,
VZ

[Fulvio Senore]

ShowWindowModal() returns immediately, unlike ShowModal(). Using it
would require changing the source code. I have more than 100 dialogs in
that program.
Moreover ShowWindowModal() makes the window modal only to its parent: if
a dialog shows another dialog that would make the main frame responsive
again, causing many problems to the program.

Fulvio Senore

[Vadim Zeitlin]

On Sat, 05 Oct 2013 21:14:30 +0200 Fulvio Senore wrote:

FS> ShowWindowModal() returns immediately, unlike ShowModal(). Using it
FS> would require changing the source code. I have more than 100 dialogs in
FS> that program.
FS> Moreover ShowWindowModal() makes the window modal only to its parent: if
FS> a dialog shows another dialog that would make the main frame responsive
FS> again, causing many problems to the program.

All this is true. But notice that under OS X ShowWindowModal() is really
the right function to use, ShowModal() is wrong from the native UI point of
view. So if you really want your program to work well under OS X, you should
still do the necessary changes and use it.

Regards,
VZ

[Julian Smart]

That would certainly be a show-stopper for me too and would prevent me
from using wxOSX (I'm currently being ultra-cautious and sticking with a
slightly tweaked 2.8 for now). I don't think that it's reasonable to
expect people to change their code so radically, and I doubt that Mac
users will be crying into their beer when confronted with a
modal-on-modal dialog. I've not had any complaints about it from
customers. Also, sometimes for complex UIs you simply need lots of
nested modal dialogs - even mobile apps exhibit this kind of modality
when you have layers of menus. There's nothing intrinsically wrong with it.

Is this just a problem with the help window? I find it strange that the
problem is so specific. I wonder why it doesn't happen for other
modal-on-modal dialogs. Or does it?

Regards,

Julian

[Vadim Zeitlin]

On Sat, 05 Oct 2013 21:27:50 +0100 Julian Smart wrote:

JS> > All this is true. But notice that under OS X ShowWindowModal() is really
JS> > the right function to use, ShowModal() is wrong from the native UI point of
JS> > view. So if you really want your program to work well under OS X, you should
JS> > still do the necessary changes and use it.
JS> That would certainly be a show-stopper for me too and would prevent me
JS> from using wxOSX (I'm currently being ultra-cautious and sticking with a
JS> slightly tweaked 2.8 for now). I don't think that it's reasonable to
JS> expect people to change their code so radically, and I doubt that Mac
JS> users will be crying into their beer when confronted with a
JS> modal-on-modal dialog.

That's because they probably drink lattes and not beers.

JS> Also, sometimes for complex UIs you simply need lots of
JS> nested modal dialogs

As long as the first dialog is window modal, the other ones really have to
be window modal too. Of course, it doesn't change anything for the UI you
present for this window, it's just that this doesn't prevent the user from
switching to another window. And that it's more bothersome to implement.
Although with the recent Vaclav's enhancements, not so much so when you're
using a C++11 compiler.

JS> There's nothing intrinsically wrong with it.

Personally I think it is fundamentally wrong as it's a trade off between
programmer's convenience (that no end user cares about) and user's freedom
of action (which at least some users do care about a lot). But I really am
not looking to restart this discussion, I'm just stating two things:

1. Apparently using window modal dialogs helps with the original problem.
2. Window modal dialogs are recommended by Apple documentation.


JS> Is this just a problem with the help window? I find it strange that the
JS> problem is so specific. I wonder why it doesn't happen for other
JS> modal-on-modal dialogs. Or does it?

Sorry, I really don't know. As I said, I don't have any hope of
successfully debugging this problem myself because I just don't know enough
about wxOSX handling of the modality.
Regards,
VZ

[Stefan Csomor]

Hi

I'll try to dissect the different options for OnInit today, so if Monday
would be ok as well, this would be great.

Thanks,

Stefan

[Vadim Zeitlin]

On Sun, 6 Oct 2013 07:49:04 +0000 Stefan Csomor wrote:

SC> >I'm going to build 3.0-RC1 sources tomorrow. I don't think we need
SC> >binaries for this release so I'm just going to upload the sources and
SC> >announce them. Please let me know if I should wait for anything before
SC> >doing this.
SC>
SC> I'll try to dissect the different options for OnInit today, so if Monday
SC> would be ok as well, this would be great.

OK, please let me know when you're done with it or decide that it's going
to take too much time to do it and I'll tag the sources and make the
archives either this night or tomorrow.

TIA and good luck!
VZ

[Stefan Csomor]

Hi Vadim

>OK, please let me know when you're done with it or decide that it's going
>to take too much time to do it and I'll tag the sources and make the
>archives either this night or tomorrow.
>
> TIA and good luck!

thanks, I hope r74947 works also for Vaclav. I'm doing OnInit at a moment
where the system is fully ready, so modal dialogs work, and store the
openFiles: parameter instead of executing directly in case we receive the
event too early (it can be called also for a running app, then of course
calling MacOpenFiles directly

Best,

Stefan

[Vadim Zeitlin]

Hello again,

I've uploaded and announced 3.0.0-rc1 now (the web site will take some
time to update). I'd like to wait a couple of days to see if no really bad
problems are found and, if not, create a 3.0 branch in svn and make
3.0.0-rc2 from it, including the binaries this time. And then release 3.0.0
after another week or two, hopefully without any important changes.

Unfortunately I won't be there from 20 to 23 October, so we can't do rc2
on October 20 (well, unless someone else wants to take care of doing it, of
course). So what would be the best date for 3.0.0-rc2? I.e. when would it
be possible for people to create setup.exe and, especially, the binaries
for all the various compilers (I hope to have them for MinGW too this
time)?

Thanks in advance,
VZ

[D.O. Scott]

I am around the week of the 20th so anytime that week is good, and probably the week after as well.

Danny Scott
From my iPad

[Vadim Zeitlin]

On Mon, 7 Oct 2013 10:31:46 -0300 D.O. Scott wrote:

DS> I am around the week of the 20th so anytime that week is good, and
DS> probably the week after as well.

Thanks Danny, let's plan for 3.0-rc2 for October 27 then. And perhaps 3.0
final for November 10 (+2 weeks)?
VZ

[D.O. Scott]

The 10th should work for me.

Danny Scott
From my iPad

[Xaviou]

Hi

> Thanks Danny, let's plan for 3.0-rc2 for October 27 then. And perhaps 3.0
> final for November 10 (+2 weeks)?
> VZ

No problem for me to build the MinGW binaries for these dates.

Just let me know how, and where to upload the archives when they will be ready...

Regards

Xav'

[Vadim Zeitlin]

On Wed, 9 Oct 2013 06:43:16 -0700 (PDT) Xaviou wrote:

X> > > Thanks Danny, let's plan for 3.0-rc2 for October 27 then. And perhaps
X> > > 3.0 final for November 10 (+2 weeks)?
X> >
X>
X> No problem for me to build the MinGW binaries for these dates.

OK, thanks in advance! I'll post here when I tag the version to be used.

X> Just let me know how, and where to upload the archives when they will be
X> ready...

Please give me your SourceForge user name so that I could give you the
permissions to upload there and contact Chris (biol75 AT york DOT ac DOT
uk) for the access to the FTP mirror.

Thanks again,
VZ

[Xaviou]

Hi.

It seems that I forgot to reply : sorry.

My SourceForge user name is xaviou74 (public name Xaviou). 

I can't remember why I've created this account, but I've never used it :-/

Do I have to contact Chris myself, or will you do it ?

 Thanks again,
VZ

Regards

Xav' 

[Vadim Zeitlin]

On Wed, 16 Oct 2013 11:42:56 -0700 (PDT) Xaviou wrote:

X> Le mercredi 9 octobre 2013 19:00:13 UTC+2, VZ a écrit :
X>
X> My SourceForge user name is xaviou74 (public name Xaviou)<http://sourceforge.net/users/xaviou74>
X> .
X> I can't remember why I've created this account, but I've never used it :-/

As long as you've kept a password for it and can use it, it should be
fine.

X> Do I have to contact Chris myself, or will you do it ?

It would be easier if you could please do it directly.

Thanks again,
VZ

[Xaviou]

Le mercredi 16 octobre 2013 22:51:49 UTC+2, VZ a écrit :

On Wed, 16 Oct 2013 11:42:56 -0700 (PDT) Xaviou wrote:

X> Le mercredi 9 octobre 2013 19:00:13 UTC+2, VZ a écrit :
X>
X> My SourceForge user name is xaviou74 (public name Xaviou)<http://sourceforge.net/users/xaviou74>
X> .
X> I can't remember why I've created this account, but I've never used it :-/

 As long as you've kept a password for it and can use it, it should be
fine.

Yes, yes : there's no problem : I have the password of this account and I can log-in with it.

X> Do I have to contact Chris myself, or will you do it ?

 It would be easier if you could please do it directly.

 I'll do it.

Regards

Xav'

[Danny Scott]

The release candidate binaries, using the OFFICIAL_BUILD argument, will be named similar to

wxbase30u_net_vc90.dll

Is there any concern that this does not identify the binaries as being release candidates?

I don't plan on generating the msi files for the release candidate for this reason.

I've just installed the VS2013 package and it looks like I will be able to include those binaries along with VS2008, VS2010 and VS2012.

--
Danny Scott

[Vadim Zeitlin]

On Sat, 19 Oct 2013 20:36:04 -0300 Danny Scott wrote:

DS> The release candidate binaries, using the OFFICIAL_BUILD argument, will be
DS> named similar to
DS>
DS> wxbase30u_net_vc90.dll
DS>
DS> Is there any concern that this does not identify the binaries as being
DS> release candidates?

The "RC1" suffix should appear in the DLL version information so by
looking carefully it should be possible to distinguish them from the final
binaries.

DS> I've just installed the VS2013 package and it looks like I will be able to
DS> include those binaries along with VS2008, VS2010 and VS2012.

Great, TIA!

I still plan to make 3.0-RC2 the next week-end (October 27) and will post
here when the sources are ready for it.

Thanks,
VZ

[Xaviou]

Will start build as soon as they will be available.

@Danny Scott : Will your archives's naming convention change ? (I'll try to make something that looks like what you've done for the wx-2.95 binaries).

Actually, my archives names look like the following :

• wxMSW-3.0.0-rc1-gcc471TDM_x86_Release_MultiLib.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x64_Release_MultiLib.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x86_Release_MonoLib.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x64_Release_MonoLib.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x86_Release_MultiDll.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x64_Release_MultiDll.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x86_Release_MonoDll.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x64_Release_MonoDll.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x86_Debug_MultiLib.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x64_Debug_MultiLib.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x86_Debug_MonoLib.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x64_Debug_MonoLib.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x86_Debug_MultiDll.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x64_Debug_MultiDll.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x86_Debug_MonoDll.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x64_Debug_MonoDll.7z 
  

And the libs/dll files will be placed in a "gcc471TDM_x86_dll / gcc471TDM_x86_lib / gcc471TDM_x64_dll / gcc471TDM_x64_lib" sub-folder of the "lib" dir.

Regards

Xav' 

[Herb Thompson]

On Monday, October 21, 2013 4:55:49 AM UTC-3, Xaviou wrote:

...

 

@Danny Scott : Will your archives's naming convention change ? (I'll try to make something that looks like what you've done for the wx-2.95 binaries).

Actually, my archives names look like the following :

• wxMSW-3.0.0-rc1-gcc471TDM_x86_Release_MultiLib.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x64_Release_MultiLib.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x86_Release_MonoLib.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x64_Release_MonoLib.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x86_Release_MultiDll.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x64_Release_MultiDll.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x86_Release_MonoDll.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x64_Release_MonoDll.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x86_Debug_MultiLib.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x64_Debug_MultiLib.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x86_Debug_MonoLib.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x64_Debug_MonoLib.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x86_Debug_MultiDll.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x64_Debug_MultiDll.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x86_Debug_MonoDll.7z 
  
• wxMSW-3.0.0-rc1-gcc471TDM_x64_Debug_MonoDll.7z 
  

And the libs/dll files will be placed in a "gcc471TDM_x86_dll / gcc471TDM_x86_lib / gcc471TDM_x64_dll / gcc471TDM_x64_lib" sub-folder of the "lib" dir.

Regards

Xav' 

Do you plan to build binaries for TDM 4.8.1 also, or just  4.7?

[Xavier Perrissoud]

2013/10/21 Herb Thompson <herb...@gmail.com>

Do you plan to build binaries for TDM 4.8.1 also, or just  4.7?

Actually, I just have gcc-4.7.1-TDM installed (both 32 and 64 bits versions).

If I find the time this week, I'll try to install gcc-4.8.1-TDM and test the wx-build with it.

Regards

Xav'

 

[Xavier Perrissoud]

2013/10/21 Herb Thompson <herb...@gmail.com>

I could not resist, so I've tested it... and all worked fine.

@VZ : Do you think I should provide both 4.7.1 and 4.8.1 binaries ?

There is no problem for me to do that, but that will give 32 different archives to manage...

Perhaps should we use differents binaries folders (one for each compiler).

Regards

Xav'

[Danny Scott]

wxMSW-3.0.0-RC2_vc90_ReleaseDLL.7z
wxMSW-3.0.0-RC2_vc90_x64_ReleaseDLL.7z

etc., same as prior releases; lack of _x64 denotes x86

--
To unsubscribe, send email to wx-dev+un...@googlegroups.com
or visit http://groups.google.com/group/wx-dev
 

--
Danny Scott

[Xavier Perrissoud]

Hi

2013/10/21 Danny Scott <dos...@gmail.com>

wxMSW-3.0.0-RC2_vc90_ReleaseDLL.7z
wxMSW-3.0.0-RC2_vc90_x64_ReleaseDLL.7z

etc., same as prior releases; lack of _x64 denotes x86

You're right : I'll follow this rule.

The only difference will be that I'll keep the "MultiLib/MonoLib/MultiDll/MonoDll" part of the archive name, as I'll have to differenciate these variants.

Regards

Xav'

[Vadim Zeitlin]

On Mon, 21 Oct 2013 13:31:30 +0200 Xavier Perrissoud wrote:

XP> @VZ : Do you think I should provide both 4.7.1 and 4.8.1 binaries ?

Are they really incompatible? I.e. can't 4.7 binaries be used with the
user code compiled with 4.8 (or vice versa?)?

XP> There is no problem for me to do that, but that will give 32 different
XP> archives to manage...

This is indeed starting to be too many. However I'd like to repeat, once
again, that we should really only provide multilib binaries, so this should
divide their number by 2 (as from your other reply saying that you also
have "MultiLib/MonoLib/MultiDll/MonoDll" in the name I got the impression
that you still planned to have monolithic ones as well). And maybe we
shouldn't bother with the static libraries neither?

XP> Perhaps should we use differents binaries folders (one for each compiler).

I'd prefer to keep the number of files manageably small instead, to be
honest...

Regards,
VZ

[Xavier Perrissoud]

Hi

2013/10/24 Vadim Zeitlin <va...@wxwidgets.org>

On Mon, 21 Oct 2013 13:31:30 +0200 Xavier Perrissoud wrote:

XP> @VZ : Do you think I should provide both 4.7.1 and 4.8.1 binaries ?

 Are they really incompatible? I.e. can't 4.7 binaries be used with the
user code compiled with 4.8 (or vice versa?)?

It seems they are not fully compatible.

I've just made some tests with a "minimal-like" application (just a window with some basics controls), and I've obtained a lot of errors and warnings.

Some configurations seems to build fine (and run fine), but as it is not a very complex application, I don't think we can say it is fully working without any more complex tests.

XP> There is no problem for me to do that, but that will give 32 different
XP> archives to manage...

 This is indeed starting to be too many. However I'd like to repeat, once
again, that we should really only provide multilib binaries, so this should
divide their number by 2 (as from your other reply saying that you also
have "MultiLib/MonoLib/MultiDll/MonoDll" in the name I got the impression
that you still planned to have monolithic ones as well). And maybe we
shouldn't bother with the static libraries neither?

Ok : so, archives names will be :

• wxMSW-3.0.0-rc2-gcc471TDM_ReleaseDLL.7z 
  
• wxMSW-3.0.0-rc2-gcc471TDM_x64_ReleaseDLL.7z 
  
• wxMSW-3.0.0-rc2-gcc471TDM_DebugDLL.7z 
  
• wxMSW-3.0.0-rc2-gcc471TDM_x64_DebugDLL.7z 
  
• wxMSW-3.0.0-rc2-gcc481TDM_ReleaseDLL.7z 
  
• wxMSW-3.0.0-rc2-gcc481TDM_x64_ReleaseDLL.7z 
  
• wxMSW-3.0.0-rc2-gcc481TDM_DebugDLL.7z 
  
• wxMSW-3.0.0-rc2-gcc481TDM_x64_DebugDLL.7z 
  

Just for informations, the 8 equivalents archives for rc1 give a total of less than 200Mb.

Each of them contains the dll files, and the corresponding ".a" lib files.

XP> Perhaps should we use differents binaries folders (one for each compiler).

 I'd prefer to keep the number of files manageably small instead, to be
honest...

 Regards,
VZ

And about the "README" file ? Who write it ?

Will there be only one README, or a "README.vc" and "README.gcc" ?

Regards

Xav'

[Vadim Zeitlin]

On Thu, 24 Oct 2013 21:22:43 +0200 Xavier Perrissoud wrote:

XP> 2013/10/24 Vadim Zeitlin <va...@wxwidgets.org>
XP>

XP> > On Mon, 21 Oct 2013 13:31:30 +0200 Xavier Perrissoud wrote:
XP> >

XP> > XP> @VZ : Do you think I should provide both 4.7.1 and 4.8.1 binaries ?
XP> >
XP> > Are they really incompatible? I.e. can't 4.7 binaries be used with the
XP> > user code compiled with 4.8 (or vice versa?)?
XP> >
XP> It seems they are not fully compatible.
XP> I've just made some tests with a "minimal-like" application (just a window
XP> with some basics controls), and I've obtained a lot of errors and warnings.

Disappointing. Out of curiosity, what were the errors related to?

XP> Ok : so, archives names will be :
XP>
XP> - wxMSW-3.0.0-rc2-gcc471TDM_ReleaseDLL.7z
XP> - wxMSW-3.0.0-rc2-gcc471TDM_x64_ReleaseDLL.7z
XP> - wxMSW-3.0.0-rc2-gcc471TDM_DebugDLL.7z
XP> - wxMSW-3.0.0-rc2-gcc471TDM_x64_DebugDLL.7z
XP> - wxMSW-3.0.0-rc2-gcc481TDM_ReleaseDLL.7z
XP> - wxMSW-3.0.0-rc2-gcc481TDM_x64_ReleaseDLL.7z
XP> - wxMSW-3.0.0-rc2-gcc481TDM_DebugDLL.7z
XP> - wxMSW-3.0.0-rc2-gcc481TDM_x64_DebugDLL.7z

Could you please use "_gcc" instead of "-gcc" for consistency with the
"_vc" in the existing binaries names? Otherwise this looks good to me,
thanks!

XP> And about the "README" file ? Who write it ?
XP> Will there be only one README, or a "README.vc" and "README.gcc" ?

Good question... I'd probably prefer to stay with a single file but I'm
not sure if it's going to remain sufficiently readable. Well, I guess the
only way to learn it is to try updating it to mention the gcc binaries :-)
The file itself is in docs/release_binaries.mdwn and if you can update it,
it would be very welcome, of course. Otherwise I'll try to do it (and will
ask you to review it).

Regards,
VZ

[Xavier Perrissoud]

OMG !!!!

I've just realized that what I was planning to provide wasn't the same thing that what Danny has provided for the 2.9.5 version.

• The "Dev" archives contains both "debug" and "release" library files and related dll.
  
• The "ReleaseDll" archives contains only the dll files.
  

Si, I should provide 4 archives for developers (each of them contains the debug and release lib files and dll) :

• wxMSW-3.0.0-rc2_gcc471TDM_Dev.7z
  
• wxMSW-3.0.0-rc2_gcc471TDM_x64_Dev.7z
  
• wxMSW-3.0.0-rc2_gcc481TDM_Dev.7z
  
• wxMSW-3.0.0-rc2_gcc481TDM_x64_Dev.7z
  

And also 4  archives for end users :

• wxMSW-3.0.0-rc2_gcc471TDM_ReleaseDLL.7z
  
• wxMSW-3.0.0-rc2_gcc471TDM_x64_ReleaseDLL.7z
  
• wxMSW-3.0.0-rc2_gcc481TDM_ReleaseDLL.7z
  
• wxMSW-3.0.0-rc2_gcc481TDM_x64_ReleaseDLL.7z
  

I'm not sure these last 4 archives are very usefull, because I think that developers should provide the binaries with their applications.

I'm actually trying to update the README file : I'll post it here as soon as I have something "readable" to have your opinion and Danny's one.

Regards

Xav'

[Xavier Perrissoud]

Here is a possible content of the README file (I didn't include the "Feedback", "Check Sums" and "Credit" part of this file but they should also be updated).

----------------------------------------------------------------------------

wxWidgets 3.0.0-rc2 Binaries

============================

This directory contains binary files for wxWidgets 3.0.0-rc2 release.

Currently the binaries are available for the following compilers:

* Microsoft Visual C++ compiler versions 9.0, 10.0 and 11.0

  corresponding to marketing product names of Microsoft Visual Studio

  2008, 2010 and 2012 respectively

* MinGW-TDM versions 4.7.1 and 4.8.1 (with the default SJLJ exceptions

  propagation method).

For Developers

--------------

For developing applications with wxWidgets you need to download the

compiler-independent wxMSW-3.0.0-rc2_Headers.7z file.

Depending on your compiler version, you'll allso have to download one

of the wxMSW-3.0.0-rc2_vcXXX_Dev.7z or wxMSW-3.0.0-rc2_gccXXX_Dev.7z

files.

Unpack both files into the same directory so that "include" and "lib"

directories are at the same level after unpacking. You should be able

to compile and link applications using wxWidgets in both debug and

release modes but the debug symbols are provided only for debug

libraries in this archive, see below for the release build debug

symbols.

For End Users

-------------

End users may download one of the wxMSW-3.0.0-rc2_vcXXX_ReleaseDLL.7z

or wxMSW-3.0.0-rc2_gccXXX_ReleaseDLL.7z files to get just the DLLs

required for running the applications using wxWidgets.

For Debugging

-------------

* Ms Visual C++ users : The files wxMSW-3.0.0-rc2_vcXXX_ReleasePDB.7z

  contain the debug symbols for the release build of the DLLs. Download

  them if you want to debug your own applications in release build or

  if you want to get meaningful information from mini-dumps retrieved

  from your users machines.

* MinGW-TDM users : There is actually no debug symbols available for the

  release build of the DLLs (only the debug versions of the DLLs contains

  the debug symbols).

----------------------------------------------------------------------------

Regards

Xav'

[Danny Scott]

re "I'm not sure these last 4 archives are very usefull, because I think that developers should provide the binaries with their applications."

By using "Official Build" libraries, your end users are not tied into you for updates as they can download them from the internet directly. Similarly you are not tied down trying to keep end users up to date if you advise end users of where they can check for updates. Even if you want to maintain control, when the binaries are updated the end users only require the compiler specific end user archive.

It would be nice some day to reach the point where your application could "call home" to see if the wx binaries need updating.

--

To unsubscribe, send email to wx-dev+un...@googlegroups.com
or visit http://groups.google.com/group/wx-dev
 

--
Danny Scott

[Vadim Zeitlin]

On Fri, 25 Oct 2013 14:28:57 +0200 Xavier Perrissoud wrote:

XP> Here is a possible content of the README file

Great, thanks! I've committed your additions now, IMHO the file with the
combined instructions is still quite readable so, at least for now, let's
keep it like this.

XP> (I didn't include the "Feedback", "Check Sums" and "Credit" part of
XP> this file but they should also be updated).

I did this too.

I also added the mention of VC12 binaries (as Danny wrote that he was
going to build them as well) and corrected the name of the headers file (it
is called wxWidgets-3.0.0-rc2_Headers.7z, not wxMSW-3.0.0-rc2_Headers.7z).

Please let me know if you notice anything wrong in the version committed
in r75075, TIA!
VZ