wxextended-developers — Mailing list for developers of wxExtended projects

Re: [Wxextended-developers] Has this project been abandoned?

[Spicerun <spi...@ve...>]

Mark,

I'm glad to hear it.  Not that I've got all the time in the world 
either, but I really am working on wxDockIT since I do need it for my 
OSS projects.

I have plans to use wxDockIT in wxTuxcards, wxDevelStudio, and 
wxdevstudio projects on sourceforge, and I'm hoping to replace the 
original Frame Layout libraries in wxWorkshop.  This all may take a 
couple of years, but I plan to get it done.

I will be happy to give you guys my patches as needed.  It is just that 
right now, Autotools/Autoconf is being a challenge to me, especially in 
getting the wxWidgets macros right.  And, just for you guys, I'm 
learning Bakefiles too.....although I'm not thrilled with Bakefiles.

I'll keep in touch,
--Spicerun

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

Mark McCormack wrote:
> Abandonded?  No.  Really in a sort of moth-ball state rather than that.
>
> I'm afraid that as the primary developer I just don't have time at the moment to
> continue work on wxDockIt.  Neither it would seem do any of the other registered
> developers at the moment.
>
> If you feel you could help/contribute I'd be more than happy.
>
> Mark.
>
> --- Spicerun <spi...@ve...> wrote:
>
>   
>> I hope not.  I'm not thrilled with wxIFM (the developer there is a jerk 
>> for one), and I'm not fond that wxIFM is being integrated into the 
>> wxWidgets code tree.
>>
>> BTW, I have been working to get wxDockIT to compile in release mode 
>> (ie-configurable).  Unfortunately, it is taking me time to learn 
>> Bakefiles, much less Autotools/Autoconf.  But the problem with the 
>> Bakefiles/Autoconf right now is that the scripts assume that only one 
>> version (Debug) of wxWidgets is installed, and does not take into 
>> account that there can be a Debug, Release, Static, or multiple platform 
>> versions of wxWidgets coexisting on a single machine.  The script does 
>> need to check via wx-config that the version being specified in 
>> configure is present (for example:  wx-config --release or wx-config 
>> --static).  I am working on this very thing, as well as looking to 
>> correct the bugs as why wxDockIt has errors compiling in release mode.
>>
>> I hope the activity is continuing.
>>
>> --Spicerun
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>> for problems?  Stop!  Download the new AJAX search engine that makes
>> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>> _______________________________________________
>> Wxextended-developers mailing list
>> Wxe...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxextended-developers
>>
>>     
>
>
>
> 		
> ___________________________________________________________ 
> NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Wxextended-developers mailing list
> Wxe...@li...
> https://lists.sourceforge.net/lists/listinfo/wxextended-developers
>
>   

Re: [Wxextended-developers] Has this project been abandoned?

[Mark M. <mar...@ya...>]

Abandonded?  No.  Really in a sort of moth-ball state rather than that.

I'm afraid that as the primary developer I just don't have time at the moment to
continue work on wxDockIt.  Neither it would seem do any of the other registered
developers at the moment.

If you feel you could help/contribute I'd be more than happy.

Mark.

--- Spicerun <spi...@ve...> wrote:

> I hope not.  I'm not thrilled with wxIFM (the developer there is a jerk 
> for one), and I'm not fond that wxIFM is being integrated into the 
> wxWidgets code tree.
> 
> BTW, I have been working to get wxDockIT to compile in release mode 
> (ie-configurable).  Unfortunately, it is taking me time to learn 
> Bakefiles, much less Autotools/Autoconf.  But the problem with the 
> Bakefiles/Autoconf right now is that the scripts assume that only one 
> version (Debug) of wxWidgets is installed, and does not take into 
> account that there can be a Debug, Release, Static, or multiple platform 
> versions of wxWidgets coexisting on a single machine.  The script does 
> need to check via wx-config that the version being specified in 
> configure is present (for example:  wx-config --release or wx-config 
> --static).  I am working on this very thing, as well as looking to 
> correct the bugs as why wxDockIt has errors compiling in release mode.
> 
> I hope the activity is continuing.
> 
> --Spicerun
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Wxextended-developers mailing list
> Wxe...@li...
> https://lists.sourceforge.net/lists/listinfo/wxextended-developers
> 



		
___________________________________________________________ 
NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/

[Wxextended-developers] Has this project been abandoned?

[Spicerun <spi...@ve...>]

I hope not.  I'm not thrilled with wxIFM (the developer there is a jerk 
for one), and I'm not fond that wxIFM is being integrated into the 
wxWidgets code tree.

BTW, I have been working to get wxDockIT to compile in release mode 
(ie-configurable).  Unfortunately, it is taking me time to learn 
Bakefiles, much less Autotools/Autoconf.  But the problem with the 
Bakefiles/Autoconf right now is that the scripts assume that only one 
version (Debug) of wxWidgets is installed, and does not take into 
account that there can be a Debug, Release, Static, or multiple platform 
versions of wxWidgets coexisting on a single machine.  The script does 
need to check via wx-config that the version being specified in 
configure is present (for example:  wx-config --release or wx-config 
--static).  I am working on this very thing, as well as looking to 
correct the bugs as why wxDockIt has errors compiling in release mode.

I hope the activity is continuing.

--Spicerun

[Wxextended-developers] Bakefiles ... must it only be these?

[JR N. <jrn...@ve...>]

Hi,

I'm looking through the Bakefiles in trying to fix some scripts so that 
the release and static library builds can be configured from the command 
line, and I'm seriously thinking about doing just a standard autoconf 
script for it.  Bakefiles look unnecessarily complex to me (although 
autoconf could be simpler too).  Anyhow, my question is, if I get some 
autoconf scripts working correctly, would you be interested in patches 
with the building, or does everything have to be in bakefiles?

I'm am trying to fix the following in at least the configure scripts:

1.  A very bad assumption is being made in that the Debug or Release 
Selection test assumes that only a debug or release version of wxWidgets 
will be resident on a machine.  In my case, I have both installed, so 
that testing wx-config --debug and wx-config --release will always 
return TRUE or Valid.  In this case, the script assumes that only the 
debug version of wxWidgets exists because wx-config --debug tests as 
valid, and builds that version, even if Release is specified.

2.  I would like wxDockit to build in a separate build directory very 
closely to how wxWidgets does it.  Currently, the configure script will 
run in the separate build directory, but the paths while compiling are 
not correct to allow compilation.

--Anyhow, let me know.

Thanks,
--Spicerun

Re: [Wxextended-developers] Help with development?

[Dave J. <dav...@ya...>]

I'm not really familiar with any of the code, so
starting anywhere would be fine by me. I think that
fixing up the known bugs would be good, but whatever
you think is best. I think that it's already a great
system, but it would definitely be cool to add new
things like the Visual Studio style stuff and that
would only make it better than the great system that
it already is.
Dave

Re: [Wxextended-developers] Help with development?

[Mark M. <mar...@ya...>]

We are always looking for help :o)  Seriously, I am happy to have you on board if you
want.  The other existing admins/devs. are probably like me too, rather busy at
times.  So we can always do with more dev. help.

At the moment I am trying to get the last few bugs out of the current code.  There
are some minor ones hanging around in the latest v2.1 release.

Francesco is helping greatly with the build side of things and Landon has recently
done the XML load/save capability (which is the prefered format for load/save). 
Currently the slidebar and main window layouts are not load/save via XML, so that is
something which needs to be done soon.

As far as further future development goes there are a couple of bigger things that I
can think of:

1) More complex docking behaviour (e.g. like MS Visual Studio)
2) Floating toolbars

This is open to anyone on this dev-list too, how do you think the project should
develop?

Mark.

--- Dave Johansen <dav...@ya...> wrote:

> I just started using wxWindows and think that wxDockIt
> is a great addition and would love to do anything to
> help the development out. I don't know what needs to
> be done or if you are looking for help, but I wouldn't
> mind helping the project keep improving. Just let me
> know,
> Dave Johansen
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Wxextended-developers mailing list
> Wxe...@li...
> https://lists.sourceforge.net/lists/listinfo/wxextended-developers
> 



	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

[Wxextended-developers] Help with development?

[Dave J. <dav...@ya...>]

I just started using wxWindows and think that wxDockIt
is a great addition and would love to do anything to
help the development out. I don't know what needs to
be done or if you are looking for help, but I wouldn't
mind helping the project keep improving. Just let me
know,
Dave Johansen

Re: [Wxextended-developers] New Release?

[Mark M. <mar...@ya...>]

I've released the latest CVS code as v2.1.  If there is any big errors or ommisions
please let me know!

BTW just noticed the doxygen docs, which look rather good already!  They really could
do with getting fleshed out - of course, but at least we have a placeholder to get
started.

Mark.

--- Mark McCormack <mar...@ya...> wrote:

> OK, I have about 5 seconds of free time at some point tomorrow and I'm going to put
> a
> new release up on sourceforge (v2.1)!  I have merged in the changes/fixes that I
> have
> been keeping local and I'm going to try tidy up the examples and any obvious
> things.
> 
> If there is any glaring bugs with this release then we can fix them in a later
> release.
> 
> Regards,
> Mark.
> 
> --- Francesco Montorsi <f18...@ya...> wrote:
> 
> > Hi,
> > 
> > > Thanks for your continued efforts!  BTW just a little info on what input I have
> > > recently been able to make to the project.
> > > 
> > > Thankfully, a chap at my work has used wxDockIt in one his applications (wxMSW)
> > and
> > > has found a number of fixes for things.  It has also given me the opportunity
> to
> > look
> > > into a few of the more annoying bugs (e.g. programatic docking) and produce
> fixes
> > > too.
> > wonderful ;-)
> > 
> > > I shall shorty be merging these changes into the CVS (no new files, or
> anything)
> > and
> > > then I feel the time is right for a release.  Even if there are some obvious
> bugs
> > in
> > > the new release, I really want to get a new version out there - I'll still
> leave
> > > 2.0.1 downloadable anyway.
> > yes a new version is really required but what about the documentation ?
> > it is fundamental to help people understand how to use wxDockIt; I have 
> > not much time in these days and I feel that I have not a good 
> > understanding of the overall structure of the library so I can help 
> > write the docs for the less important classes only....
> > 
> > Francesco
> > 
> > 
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > _______________________________________________
> > Wxextended-developers mailing list
> > Wxe...@li...
> > https://lists.sourceforge.net/lists/listinfo/wxextended-developers
> > 
> 
> 
> 
> 		
> ___________________________________________________________ 
> How much free photo storage do you get? Store your holiday 
> snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Wxextended-developers mailing list
> Wxe...@li...
> https://lists.sourceforge.net/lists/listinfo/wxextended-developers
> 



	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

Re: [Wxextended-developers] New Release?

[Mark M. <mar...@ya...>]

OK, I have about 5 seconds of free time at some point tomorrow and I'm going to put a
new release up on sourceforge (v2.1)!  I have merged in the changes/fixes that I have
been keeping local and I'm going to try tidy up the examples and any obvious things.

If there is any glaring bugs with this release then we can fix them in a later
release.

Regards,
Mark.

--- Francesco Montorsi <f18...@ya...> wrote:

> Hi,
> 
> > Thanks for your continued efforts!  BTW just a little info on what input I have
> > recently been able to make to the project.
> > 
> > Thankfully, a chap at my work has used wxDockIt in one his applications (wxMSW)
> and
> > has found a number of fixes for things.  It has also given me the opportunity to
> look
> > into a few of the more annoying bugs (e.g. programatic docking) and produce fixes
> > too.
> wonderful ;-)
> 
> > I shall shorty be merging these changes into the CVS (no new files, or anything)
> and
> > then I feel the time is right for a release.  Even if there are some obvious bugs
> in
> > the new release, I really want to get a new version out there - I'll still leave
> > 2.0.1 downloadable anyway.
> yes a new version is really required but what about the documentation ?
> it is fundamental to help people understand how to use wxDockIt; I have 
> not much time in these days and I feel that I have not a good 
> understanding of the overall structure of the library so I can help 
> write the docs for the less important classes only....
> 
> Francesco
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Wxextended-developers mailing list
> Wxe...@li...
> https://lists.sourceforge.net/lists/listinfo/wxextended-developers
> 



		
___________________________________________________________ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

[Wxextended-developers] Re: Is wxDockIt still active?

[Francesco M. <f18...@ya...>]

Hi,

>> the fact is that the CVS version is already full Unicode-compliant: 
>> all those wxT() macros have already been added ;-)
>>
>> Sorry if this was unclear from my last mail...
> 
> 
> No, it was clear. But I started patching prior to receiving your email! 
> Anyway, it was funny. It is a hobby project, after all.
;-)


> I will download 
> the cvs version. By the way, I studied a little bit your code, trying to 
> understand how the whole thing works. I like very much that there are 
> wxStreams for "interdockbar" communication. It looks like a very good 
> design. Perhaps I could give back something to the project in the future.
well, I have to say that the real code has been written by Mark 
McCormack and Landon Bradshaw (I think); I joined the project to create 
the bakefile build system ;-)

> Congratulations and thank you for providing such a "cute" library.
the problem with this lib is that other admin are really busy and we 
still need good docs for the lib ;-)
Maybe that if you have time and you have a good comprehension of how the 
library works and you'd like to contribute... ;-)

> wxExtended, IIUC, will contain extensions to the wxWidgets. I have 
> written some custom controls, but I don't know if you are interested in 
> creating a subproject so that users may contribute their controls. There 
> are several such projects (wxCode, wxCRP) but there is something missing 
> in them. Just a thought.
I don't exactly know which are the plans about addition/creation of 
other libraries in wxExtended... but I know that I've just completed the 
restyling of wxCode ;-)
If you want a good place where you can post your small-to-medium-sized 
components, I think wxCode is now the best choice...

Francesco Montorsi

Re: [Wxextended-developers] New Release?

[Francesco M. <f18...@ya...>]

Hi,

> Thanks for your continued efforts!  BTW just a little info on what input I have
> recently been able to make to the project.
> 
> Thankfully, a chap at my work has used wxDockIt in one his applications (wxMSW) and
> has found a number of fixes for things.  It has also given me the opportunity to look
> into a few of the more annoying bugs (e.g. programatic docking) and produce fixes
> too.
wonderful ;-)

> I shall shorty be merging these changes into the CVS (no new files, or anything) and
> then I feel the time is right for a release.  Even if there are some obvious bugs in
> the new release, I really want to get a new version out there - I'll still leave
> 2.0.1 downloadable anyway.
yes a new version is really required but what about the documentation ?
it is fundamental to help people understand how to use wxDockIt; I have 
not much time in these days and I feel that I have not a good 
understanding of the overall structure of the library so I can help 
write the docs for the less important classes only....

Francesco

Re: [Wxextended-developers] New Release?

[Mark M. <mar...@ya...>]

Hello again,

Thanks for your continued efforts!  BTW just a little info on what input I have
recently been able to make to the project.

Thankfully, a chap at my work has used wxDockIt in one his applications (wxMSW) and
has found a number of fixes for things.  It has also given me the opportunity to look
into a few of the more annoying bugs (e.g. programatic docking) and produce fixes
too.

I shall shorty be merging these changes into the CVS (no new files, or anything) and
then I feel the time is right for a release.  Even if there are some obvious bugs in
the new release, I really want to get a new version out there - I'll still leave
2.0.1 downloadable anyway.

Mark.

--- f18m_217828 <f18...@ya...> wrote:

> Hi,
> 
> > however I have to say that also under 
> > GTK there are various problems... I recently did a little modification 
> > to wxDockPanel::OnLeftUp in generic\dockpanel.cpp to solve this problem 
> > but I still have to test it...
> well, my modification has partially removed the bug: the SDI & MDI 
> samples now allow you to dock/undock windows but they hang in some 
> inexplicable cases... I think this is because improper mouse 
> capturing/releasing.
> 
> > well, I can test the following builds:
> > 1) MSVC++ 6 & MSVC++ .NET (just installed :-))
> > 2) Borlandc++ 5.5
> > 3) Mingw
> > 4) obviously nmake
> > 5) autoconf build system with GCC 3.2 under my Red Hat 9
> I tested them all and now (with some few modifications) they all compile.
> I'm ready to help with packaging of the new version...
> 
> Francesco
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
> _______________________________________________
> Wxextended-developers mailing list
> Wxe...@li...
> https://lists.sourceforge.net/lists/listinfo/wxextended-developers
> 



	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

Re: [Wxextended-developers] New Release?

[f18m_217828 <f18...@ya...>]

Hi,

> however I have to say that also under 
> GTK there are various problems... I recently did a little modification 
> to wxDockPanel::OnLeftUp in generic\dockpanel.cpp to solve this problem 
> but I still have to test it...
well, my modification has partially removed the bug: the SDI & MDI 
samples now allow you to dock/undock windows but they hang in some 
inexplicable cases... I think this is because improper mouse 
capturing/releasing.

> well, I can test the following builds:
> 1) MSVC++ 6 & MSVC++ .NET (just installed :-))
> 2) Borlandc++ 5.5
> 3) Mingw
> 4) obviously nmake
> 5) autoconf build system with GCC 3.2 under my Red Hat 9
I tested them all and now (with some few modifications) they all compile.
I'm ready to help with packaging of the new version...

Francesco

Re: [Wxextended-developers] New Release?

[f18m_217828 <f18...@ya...>]

Hi,

Mark McCormack wrote:
> I think it is about time for a new release.  I have also recently checked out wxIFM
> again, and it looks promising, but I still don't see any Load/Save yet?  I am missing
> something?  Also, it looks really bad on WinXP because it falls into the same problem
> FL has - it doesn't exploit 'native' windows.  So, I don't think wxIFM is yet a
> viable solution for people wanting a complete docking solution for wxWidgets.  Still,
> going to look cool, as long as it gets finished ;o)
I agree; it also does not have a good build-support ;-)

> OK, had a quick look at the state of wxDockIt.  There are two things we need to sort
> out before a realese:
> 
> 1) Load/Save layout is broken in todays CVS.  The proportions of docked windows are
> not being correctly reimplemented on load.  Any ideas what could have caused this?  I
> have just compiled a older 2.0.1 relase - and it was find at that point in time.
I'll try to find why this happens, however I have to say that also under 
GTK there are various problems... I recently did a little modification 
to wxDockPanel::OnLeftUp in generic\dockpanel.cpp to solve this problem 
but I still have to test it...

> 
> 2) Make sure as may of the builds, er, build.  I can check the .NET2003 stuff, but
> I'm afraid that's about it.  We've come a long way since it was just MSVC, any idea
> how we can test all supplied builds?
well, I can test the following builds:
1) MSVC++ 6 & MSVC++ .NET (just installed :-))
2) Borlandc++ 5.5
3) Mingw
4) obviously nmake
5) autoconf build system with GCC 3.2 under my Red Hat 9

Francesco

[Wxextended-developers] New Release?

[Mark M. <mar...@ya...>]

Hi, (re: Francesco's mail kind of)

> I think we should make a sign to users that wxDockIt still lives: I've 
> just found that wxIFM has made a new release:
> 
> http://www.solidsteel.nl/users/wxwidgets/viewtopic.php?t=2153
> 
> it also have good docs !
> 
> What about docs & new release ?
> 
> Francesco

I think it is about time for a new release.  I have also recently checked out wxIFM
again, and it looks promising, but I still don't see any Load/Save yet?  I am missing
something?  Also, it looks really bad on WinXP because it falls into the same problem
FL has - it doesn't exploit 'native' windows.  So, I don't think wxIFM is yet a
viable solution for people wanting a complete docking solution for wxWidgets.  Still,
going to look cool, as long as it gets finished ;o)

OK, had a quick look at the state of wxDockIt.  There are two things we need to sort
out before a realese:

1) Load/Save layout is broken in todays CVS.  The proportions of docked windows are
not being correctly reimplemented on load.  Any ideas what could have caused this?  I
have just compiled a older 2.0.1 relase - and it was find at that point in time.

2) Make sure as may of the builds, er, build.  I can check the .NET2003 stuff, but
I'm afraid that's about it.  We've come a long way since it was just MSVC, any idea
how we can test all supplied builds?

Mark.


	
	
		
___________________________________________________________ 
Yahoo! Messenger - want a free and easy way to contact your friends online? http://uk.messenger.yahoo.com

Re: [Wxextended-developers] Couple of areas for improvement

[f18m_217828 <f18...@ya...>]

Hi,

> ok; I'm still trying to understand how some "secondary" classes interact 
> with main ones (wxLayoutManager...) and so I still need to get the whole 
> idea of the lib internals, so I still cannot start to write docs... :-(
> 
> Anyway, I think that we should divide this work... maybe that we (3 
> developers) can take up 5 classes to document (see 
> http://wxextended.sourceforge.net/docs/annotated.html; there are 15 
> classes to document listed there).
> 
> Is this a good idea ?
> If so, please suggest me the classes I should document so that this week 
> I'll do the work...
> 
I think we should make a sign to users that wxDockIt still lives: I've 
just found that wxIFM has made a new release:

http://www.solidsteel.nl/users/wxwidgets/viewtopic.php?t=2153

it also have good docs !

What about docs & new release ?

Francesco

Re: [Wxextended-developers] Couple of areas for improvement

[f18m_217828 <f18...@ya...>]

Hi,

>>yes, I think that strange behaviour should never happen; I prefer an 
>>ASSERT failure which tells me that I did something wrong (e.g. that I've 
>>not called SetLayout() before user starts docking) that a strange 
>>behaviour which requires a lot of time spent debugging...
> 
> 
> I'll take a look into this, see what I think appears the best way.  An ASSERT with
> message will probably do the job.
I agree


>>Also, I would like to know what you think about doxygen docs 
>>"placement": headers or sources ? (see 
>>https://sourceforge.net/mailarchive/message.php?msg_id=11729919)
> 
> 
> Only thing I would say about putting the docs in the headers is that it *sometimes*
> makes it more difficult for users just scanning the headers to get a feel for the
> API.  As there is loads of text between all the declarations and the headers can
> become large.
> 
> To be honest though, I'm not too bothered either way.  If the header file way is
> easier in syntax, then lets use that one.
ok; I'm still trying to understand how some "secondary" classes interact 
with main ones (wxLayoutManager...) and so I still need to get the whole 
idea of the lib internals, so I still cannot start to write docs... :-(

Anyway, I think that we should divide this work... maybe that we (3 
developers) can take up 5 classes to document (see 
http://wxextended.sourceforge.net/docs/annotated.html; there are 15 
classes to document listed there).

Is this a good idea ?
If so, please suggest me the classes I should document so that this week 
I'll do the work...

Francesco

Re: [Wxextended-developers] Couple of areas for improvement

[Mark M. <mar...@ya...>]

re:

> > 1) [SDI] If you don't set a client area with SetLayout(), crazy things start
> > happening with the docking.  Of course, you will always execute SetLayout() at
> some
> > point - just that when people are first building up an application, they don't
> have
> > this line and therefore they think the weird stuff is as a result of something
> they
> > are doing. -Suggestion- Maybe add a default wxPane or wxWindow until this is
> > overriden by the user?
>  > 2) [MDI] If you forget to intercept the OnSize event of the MDI 
> window to let the
>  > LayoutManager handing the positioning of the MDI client container (as 
> the  MDI
>  > example does) then again, crazy things start happening.
> 
> yes, I think that strange behaviour should never happen; I prefer an 
> ASSERT failure which tells me that I did something wrong (e.g. that I've 
> not called SetLayout() before user starts docking) that a strange 
> behaviour which requires a lot of time spent debugging...

I'll take a look into this, see what I think appears the best way.  An ASSERT with
message will probably do the job.

> >  Have we any FAQ or doc file
> > the need for this could be stated? 
> I just added a new file (doxypages.txt) in the DOCS folder of the 
> project; it contains some hand-written pages for the doxygen docs (which 
> I have also uploaded in the website)... maybe that's the best place for 
> this hint.
> 
> Also, I would like to know what you think about doxygen docs 
> "placement": headers or sources ? (see 
> https://sourceforge.net/mailarchive/message.php?msg_id=11729919)

Only thing I would say about putting the docs in the headers is that it *sometimes*
makes it more difficult for users just scanning the headers to get a feel for the
API.  As there is loads of text between all the declarations and the headers can
become large.

To be honest though, I'm not too bothered either way.  If the header file way is
easier in syntax, then lets use that one.

Mark.


		
___________________________________________________________ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

Re: [Wxextended-developers] Couple of areas for improvement

[Landon B. <la...@ph...>]

Unfortunately I am in sort of a crisis mode as our server was hacked 
yesterday (I think there was a black cat that crossed my path for Friday 
the 13th) ... just a couple of quick comments ...

For both of these issues in the current dev version (and next release) I 
think we should have it covered in the docs ... a detailed FAQ would 
probably be the quickest way for people to find it ... then we can have 
the time to deal with the issue properly ...

...Landon

Mark McCormack wrote:
> Hi,
> 
> I've had two issues from people trying to use wxDockIt, one with the SDI and one with
> the MDI.  Wondering what people think.
> 
> 1) [SDI] If you don't set a client area with SetLayout(), crazy things start
> happening with the docking.  Of course, you will always execute SetLayout() at some
> point - just that when people are first building up an application, they don't have
> this line and therefore they think the weird stuff is as a result of something they
> are doing. -Suggestion- Maybe add a default wxPane or wxWindow until this is
> overriden by the user?
> 
> 2) [MDI] If you forget to intercept the OnSize event of the MDI window to let the
> LayoutManager handing the positioning of the MDI client container (as the  MDI
> example does) then again, crazy things start happening.  Have we any FAQ or doc file
> the need for this could be stated? 
> 
> Mark. 
> 
> 
> 	
> 	
> 		
> ___________________________________________________________ 
> Yahoo! Messenger - want a free and easy way to contact your friends online? http://uk.messenger.yahoo.com
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> _______________________________________________
> Wxextended-developers mailing list
> Wxe...@li...
> https://lists.sourceforge.net/lists/listinfo/wxextended-developers
> 

-- 
Words to remember:
Bagpipes (n): an octopus wearing a kilt.
Eclair (n): a cake long in shape but short in duration.
Wisdom (n): a trait that leads you to use Linux.

Be forever contactable ... Get an I-Name at http://www.idcommons.net/

Find me at: http://public.xdi.org/=landon.bradshaw

Re: [Wxextended-developers] Couple of areas for improvement

[f18m_217828 <f18...@ya...>]

Hi,

> 1) [SDI] If you don't set a client area with SetLayout(), crazy things start
> happening with the docking.  Of course, you will always execute SetLayout() at some
> point - just that when people are first building up an application, they don't have
> this line and therefore they think the weird stuff is as a result of something they
> are doing. -Suggestion- Maybe add a default wxPane or wxWindow until this is
> overriden by the user?
 > 2) [MDI] If you forget to intercept the OnSize event of the MDI 
window to let the
 > LayoutManager handing the positioning of the MDI client container (as 
the  MDI
 > example does) then again, crazy things start happening.

yes, I think that strange behaviour should never happen; I prefer an 
ASSERT failure which tells me that I did something wrong (e.g. that I've 
not called SetLayout() before user starts docking) that a strange 
behaviour which requires a lot of time spent debugging...

I'm still trying to learn how wxDockIt works so I cannot still say what 
is the best choice to avoid such thing.

>  Have we any FAQ or doc file
> the need for this could be stated? 
I just added a new file (doxypages.txt) in the DOCS folder of the 
project; it contains some hand-written pages for the doxygen docs (which 
I have also uploaded in the website)... maybe that's the best place for 
this hint.

Also, I would like to know what you think about doxygen docs 
"placement": headers or sources ? (see 
https://sourceforge.net/mailarchive/message.php?msg_id=11729919)

Let me know,
Francesco

[Wxextended-developers] Couple of areas for improvement

[Mark M. <mar...@ya...>]

Hi,

I've had two issues from people trying to use wxDockIt, one with the SDI and one with
the MDI.  Wondering what people think.

1) [SDI] If you don't set a client area with SetLayout(), crazy things start
happening with the docking.  Of course, you will always execute SetLayout() at some
point - just that when people are first building up an application, they don't have
this line and therefore they think the weird stuff is as a result of something they
are doing. -Suggestion- Maybe add a default wxPane or wxWindow until this is
overriden by the user?

2) [MDI] If you forget to intercept the OnSize event of the MDI window to let the
LayoutManager handing the positioning of the MDI client container (as the  MDI
example does) then again, crazy things start happening.  Have we any FAQ or doc file
the need for this could be stated? 

Mark. 


	
	
		
___________________________________________________________ 
Yahoo! Messenger - want a free and easy way to contact your friends online? http://uk.messenger.yahoo.com

Re: [Wxextended-developers] Changes and Documentation

[f18m_217828 <f18...@ya...>]

Hi,
    other two doxygen issues:

1) does doxygen generates the "class hierarchy" for you ? I'm using 
version 1.4.2 (just downloaded) and the class hierarchy seems to have 
disappeared for some unknown reason... can you see it in the generated 
docs ?

2) we should decide where we put the docs: in the headers or in the 
sources ?
I see that you have documented the XML load/save functions in the source 
files however I'd personally prefer to put the docs in the headers also 
because this makes easy to write docs for members and classes (if you 
want to write docs for a class defined in a header file from a source 
file you have to use a slightly more complex syntax).

Let me know,
Francesco


Landon Bradshaw wrote:
> Yes, this is something I am trying to fix ... it can be ignored for the 
> moment ... it's part of the commit email system ...
> 
> f18m_217828 wrote:
> 
>> Hi,
>>    I have just committed to the CVS an updated wxDockitWebsite module 
>> containing the first wxDockIt docs generated through doxygen; I hope 
>> to be able to update the website as soon as possible.
>>
>> Also I noticed that when trying to commit files to the CVS repository, 
>> cvs worries about syncmail script...
>> is this a known problem ?
>>
>> Francesco
>>
>>
>> f18m_217828 wrote:
>>
>>> done;
>>> let me know for any problem...
>>>
>>> f18m_217828 wrote:
>>>
>>>> Landon Bradshaw wrote:
>>>>
>>>>> Yes, I think going with the separation is good ... personally I 
>>>>> always keep the static and dynamic builds up-to-date because I have 
>>>>> different projects that use both ...
>>>>
>>>>
>>>>
>>>>
>>>> ok; in few minutes I'll commit the new bakefiles....
>>>>
>>>> FM
>>>>
>>>> PS: I've just fixed the (default and annoying !!) behaviour of 
>>>> SF.net mailing list which set the reply-to field to the poster and 
>>>> not to the mailing list....
>>>>
>>>>
>>>>
>>>>> f18m_217828 wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Landon Bradshaw wrote:
>>>>>>
>>>>>>> Glitch in the VC6 project files generated from the bakefiles ... 
>>>>>>> all the libraries go into ../../lib and do not get separated into 
>>>>>>> vc_lib and vc_dll (just had a fun time trying to figure out why 
>>>>>>> my app was not able to build as a release but was successful as a 
>>>>>>> debug build) ... we need to separate them so that the .lib 
>>>>>>> associated with the DLL does not get confused with the static 
>>>>>>> .lib ...
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> yes; that would make thing easier when you want to build multiple 
>>>>>> configurations of the same library :-)
>>>>>>
>>>>>> However, I think that we have two choices:
>>>>>> 1) keep the current build output configuration: all the output 
>>>>>> always go to the LIB folder (this is easier for users' to 
>>>>>> understand and makes easier the setting of the library link path 
>>>>>> in their projects)
>>>>>>
>>>>>> 2) adopt a wx-like organization of build output: this does not 
>>>>>> only means separation of the static and shared builds in folders 
>>>>>> like _lib and _dll but also the separation of object files created 
>>>>>> by different compilers: gcc_, vc_, bcc_ folders would be required.
>>>>>> This makes a lot easier multi-config builds but it's a bit more 
>>>>>> complex...
>>>>>>
>>>>>> I think that since wxDockIt relies on wxWidgets, users of wxDockIt 
>>>>>> will not have problems to use a LIB/VC_DLL (or GCC_LIB or BCC_DLL) 
>>>>>> link path also for wxDockIt; it's very easy to implement in 
>>>>>> bakefiles...
>>>>>>
>>>>>> what do you think of it ?
>>>>>>
>>>>>> Separation of only shared/static builds is a bad halfway, I think.
>>>>>>
>>>>>> Francesco
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by Oracle Space Sweepstakes
>>>> Want to be the first software developer in space?
>>>> Enter now for the Oracle Space Sweepstakes!
>>>> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
>>>> _______________________________________________
>>>> Wxextended-developers mailing list
>>>> Wxe...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/wxextended-developers
>>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by Oracle Space Sweepstakes
>>> Want to be the first software developer in space?
>>> Enter now for the Oracle Space Sweepstakes!
>>> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
>>> _______________________________________________
>>> Wxextended-developers mailing list
>>> Wxe...@li...
>>> https://lists.sourceforge.net/lists/listinfo/wxextended-developers
>>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by Oracle Space Sweepstakes
>> Want to be the first software developer in space?
>> Enter now for the Oracle Space Sweepstakes!
>> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
>> _______________________________________________
>> Wxextended-developers mailing list
>> Wxe...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxextended-developers
>>
> 

Re: [Wxextended-developers] Changes and Documentation

[f18m_217828 <f18...@ya...>]

Hi,
    I'm now facing another little problem with wxdockits docs: I think 
we should completely exclude from doxygen list of processed files the

include/wx/generic
include/wx/gtk
include/wx/msw
src/gtk
src/msw

folders: they contain platform-specific implementation of classes and 
the platform-specific functions they add to the Base version of the 
classes should not be used by users who want to write cross-platform apps...
also, adding to the docs gives some troubles to doxygen because some 
classes are defined twice with the same name (e.g. gtk/wxDockWindow and 
msw/wxDockWindow).

I think that we should tell doxygen to document only the 
wxDockWindowBase version of wxDockWindow and then just put a notice to 
the beginning of the docs telling the user that he should refer to 
wxDockWindowBase when he wants to use wxDockWindow.... do you agree ?

Francesco


Landon Bradshaw wrote:
> Yes, this is something I am trying to fix ... it can be ignored for the 
> moment ... it's part of the commit email system ...
> 
> f18m_217828 wrote:
> 
>> Hi,
>>    I have just committed to the CVS an updated wxDockitWebsite module 
>> containing the first wxDockIt docs generated through doxygen; I hope 
>> to be able to update the website as soon as possible.
>>
>> Also I noticed that when trying to commit files to the CVS repository, 
>> cvs worries about syncmail script...
>> is this a known problem ?
>>
>> Francesco
>>
>>
>> f18m_217828 wrote:
>>
>>> done;
>>> let me know for any problem...
>>>
>>> f18m_217828 wrote:
>>>
>>>> Landon Bradshaw wrote:
>>>>
>>>>> Yes, I think going with the separation is good ... personally I 
>>>>> always keep the static and dynamic builds up-to-date because I have 
>>>>> different projects that use both ...
>>>>
>>>>
>>>>
>>>>
>>>> ok; in few minutes I'll commit the new bakefiles....
>>>>
>>>> FM
>>>>
>>>> PS: I've just fixed the (default and annoying !!) behaviour of 
>>>> SF.net mailing list which set the reply-to field to the poster and 
>>>> not to the mailing list....
>>>>
>>>>
>>>>
>>>>> f18m_217828 wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Landon Bradshaw wrote:
>>>>>>
>>>>>>> Glitch in the VC6 project files generated from the bakefiles ... 
>>>>>>> all the libraries go into ../../lib and do not get separated into 
>>>>>>> vc_lib and vc_dll (just had a fun time trying to figure out why 
>>>>>>> my app was not able to build as a release but was successful as a 
>>>>>>> debug build) ... we need to separate them so that the .lib 
>>>>>>> associated with the DLL does not get confused with the static 
>>>>>>> .lib ...
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> yes; that would make thing easier when you want to build multiple 
>>>>>> configurations of the same library :-)
>>>>>>
>>>>>> However, I think that we have two choices:
>>>>>> 1) keep the current build output configuration: all the output 
>>>>>> always go to the LIB folder (this is easier for users' to 
>>>>>> understand and makes easier the setting of the library link path 
>>>>>> in their projects)
>>>>>>
>>>>>> 2) adopt a wx-like organization of build output: this does not 
>>>>>> only means separation of the static and shared builds in folders 
>>>>>> like _lib and _dll but also the separation of object files created 
>>>>>> by different compilers: gcc_, vc_, bcc_ folders would be required.
>>>>>> This makes a lot easier multi-config builds but it's a bit more 
>>>>>> complex...
>>>>>>
>>>>>> I think that since wxDockIt relies on wxWidgets, users of wxDockIt 
>>>>>> will not have problems to use a LIB/VC_DLL (or GCC_LIB or BCC_DLL) 
>>>>>> link path also for wxDockIt; it's very easy to implement in 
>>>>>> bakefiles...
>>>>>>
>>>>>> what do you think of it ?
>>>>>>
>>>>>> Separation of only shared/static builds is a bad halfway, I think.
>>>>>>
>>>>>> Francesco
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by Oracle Space Sweepstakes
>>>> Want to be the first software developer in space?
>>>> Enter now for the Oracle Space Sweepstakes!
>>>> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
>>>> _______________________________________________
>>>> Wxextended-developers mailing list
>>>> Wxe...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/wxextended-developers
>>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by Oracle Space Sweepstakes
>>> Want to be the first software developer in space?
>>> Enter now for the Oracle Space Sweepstakes!
>>> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
>>> _______________________________________________
>>> Wxextended-developers mailing list
>>> Wxe...@li...
>>> https://lists.sourceforge.net/lists/listinfo/wxextended-developers
>>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by Oracle Space Sweepstakes
>> Want to be the first software developer in space?
>> Enter now for the Oracle Space Sweepstakes!
>> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
>> _______________________________________________
>> Wxextended-developers mailing list
>> Wxe...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxextended-developers
>>
> 

Re: [Wxextended-developers] Changes and Documentation

[Landon B. <la...@ph...>]

Yes, this is something I am trying to fix ... it can be ignored for the 
moment ... it's part of the commit email system ...

f18m_217828 wrote:
> Hi,
>    I have just committed to the CVS an updated wxDockitWebsite module 
> containing the first wxDockIt docs generated through doxygen; I hope to 
> be able to update the website as soon as possible.
> 
> Also I noticed that when trying to commit files to the CVS repository, 
> cvs worries about syncmail script...
> is this a known problem ?
> 
> Francesco
> 
> 
> f18m_217828 wrote:
> 
>> done;
>> let me know for any problem...
>>
>> f18m_217828 wrote:
>>
>>> Landon Bradshaw wrote:
>>>
>>>> Yes, I think going with the separation is good ... personally I 
>>>> always keep the static and dynamic builds up-to-date because I have 
>>>> different projects that use both ...
>>>
>>>
>>>
>>> ok; in few minutes I'll commit the new bakefiles....
>>>
>>> FM
>>>
>>> PS: I've just fixed the (default and annoying !!) behaviour of SF.net 
>>> mailing list which set the reply-to field to the poster and not to 
>>> the mailing list....
>>>
>>>
>>>
>>>> f18m_217828 wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Landon Bradshaw wrote:
>>>>>
>>>>>> Glitch in the VC6 project files generated from the bakefiles ... 
>>>>>> all the libraries go into ../../lib and do not get separated into 
>>>>>> vc_lib and vc_dll (just had a fun time trying to figure out why my 
>>>>>> app was not able to build as a release but was successful as a 
>>>>>> debug build) ... we need to separate them so that the .lib 
>>>>>> associated with the DLL does not get confused with the static .lib 
>>>>>> ...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> yes; that would make thing easier when you want to build multiple 
>>>>> configurations of the same library :-)
>>>>>
>>>>> However, I think that we have two choices:
>>>>> 1) keep the current build output configuration: all the output 
>>>>> always go to the LIB folder (this is easier for users' to 
>>>>> understand and makes easier the setting of the library link path in 
>>>>> their projects)
>>>>>
>>>>> 2) adopt a wx-like organization of build output: this does not only 
>>>>> means separation of the static and shared builds in folders like 
>>>>> _lib and _dll but also the separation of object files created by 
>>>>> different compilers: gcc_, vc_, bcc_ folders would be required.
>>>>> This makes a lot easier multi-config builds but it's a bit more 
>>>>> complex...
>>>>>
>>>>> I think that since wxDockIt relies on wxWidgets, users of wxDockIt 
>>>>> will not have problems to use a LIB/VC_DLL (or GCC_LIB or BCC_DLL) 
>>>>> link path also for wxDockIt; it's very easy to implement in 
>>>>> bakefiles...
>>>>>
>>>>> what do you think of it ?
>>>>>
>>>>> Separation of only shared/static builds is a bad halfway, I think.
>>>>>
>>>>> Francesco
>>>>>
>>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by Oracle Space Sweepstakes
>>> Want to be the first software developer in space?
>>> Enter now for the Oracle Space Sweepstakes!
>>> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
>>> _______________________________________________
>>> Wxextended-developers mailing list
>>> Wxe...@li...
>>> https://lists.sourceforge.net/lists/listinfo/wxextended-developers
>>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by Oracle Space Sweepstakes
>> Want to be the first software developer in space?
>> Enter now for the Oracle Space Sweepstakes!
>> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
>> _______________________________________________
>> Wxextended-developers mailing list
>> Wxe...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxextended-developers
>>
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> _______________________________________________
> Wxextended-developers mailing list
> Wxe...@li...
> https://lists.sourceforge.net/lists/listinfo/wxextended-developers
> 

-- 
Words to remember:
Bagpipes (n): an octopus wearing a kilt.
Eclair (n): a cake long in shape but short in duration.
Wisdom (n): a trait that leads you to use Linux.

Be forever contactable ... Get an I-Name at http://www.idcommons.net/

Find me at: http://public.xdi.org/=landon.bradshaw

Re: [Wxextended-developers] Changes and Documentation

[f18m_217828 <f18...@ya...>]

Hi,
    I have just committed to the CVS an updated wxDockitWebsite module 
containing the first wxDockIt docs generated through doxygen; I hope to 
be able to update the website as soon as possible.

Also I noticed that when trying to commit files to the CVS repository, 
cvs worries about syncmail script...
is this a known problem ?

Francesco


f18m_217828 wrote:
> done;
> let me know for any problem...
> 
> f18m_217828 wrote:
> 
>> Landon Bradshaw wrote:
>>
>>> Yes, I think going with the separation is good ... personally I 
>>> always keep the static and dynamic builds up-to-date because I have 
>>> different projects that use both ...
>>
>>
>> ok; in few minutes I'll commit the new bakefiles....
>>
>> FM
>>
>> PS: I've just fixed the (default and annoying !!) behaviour of SF.net 
>> mailing list which set the reply-to field to the poster and not to the 
>> mailing list....
>>
>>
>>
>>> f18m_217828 wrote:
>>>
>>>> Hi,
>>>>
>>>> Landon Bradshaw wrote:
>>>>
>>>>> Glitch in the VC6 project files generated from the bakefiles ... 
>>>>> all the libraries go into ../../lib and do not get separated into 
>>>>> vc_lib and vc_dll (just had a fun time trying to figure out why my 
>>>>> app was not able to build as a release but was successful as a 
>>>>> debug build) ... we need to separate them so that the .lib 
>>>>> associated with the DLL does not get confused with the static .lib ...
>>>>
>>>>
>>>>
>>>>
>>>> yes; that would make thing easier when you want to build multiple 
>>>> configurations of the same library :-)
>>>>
>>>> However, I think that we have two choices:
>>>> 1) keep the current build output configuration: all the output 
>>>> always go to the LIB folder (this is easier for users' to understand 
>>>> and makes easier the setting of the library link path in their 
>>>> projects)
>>>>
>>>> 2) adopt a wx-like organization of build output: this does not only 
>>>> means separation of the static and shared builds in folders like 
>>>> _lib and _dll but also the separation of object files created by 
>>>> different compilers: gcc_, vc_, bcc_ folders would be required.
>>>> This makes a lot easier multi-config builds but it's a bit more 
>>>> complex...
>>>>
>>>> I think that since wxDockIt relies on wxWidgets, users of wxDockIt 
>>>> will not have problems to use a LIB/VC_DLL (or GCC_LIB or BCC_DLL) 
>>>> link path also for wxDockIt; it's very easy to implement in 
>>>> bakefiles...
>>>>
>>>> what do you think of it ?
>>>>
>>>> Separation of only shared/static builds is a bad halfway, I think.
>>>>
>>>> Francesco
>>>>
>>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by Oracle Space Sweepstakes
>> Want to be the first software developer in space?
>> Enter now for the Oracle Space Sweepstakes!
>> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
>> _______________________________________________
>> Wxextended-developers mailing list
>> Wxe...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxextended-developers
>>
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> _______________________________________________
> Wxextended-developers mailing list
> Wxe...@li...
> https://lists.sourceforge.net/lists/listinfo/wxextended-developers
>