/** Objects of type InfoWindow are autonomous and must therefore always be instantiated using operator new.* In addition to this, InfoWindow does not have any non-static public class members.** Since a (technically 100% correct) statement like* new InfoWindow("foo", "bar");* is unintuitive, confusing or even objective to some people, this class uses a variation of the "Named Constructor Idiom".** InfoWindow::Display("foo", "bar");* does the exact same thing as the above statement but looks a lot nicer.*/

#ifndef INFOWINDOW_H#define INFOWINDOW_H//#define __WXMAC__//-----------------------------------------------------------------------------#if (defined(__WXMAC__) || defined(_TEST_NO_INFOWINDOW_))//-----------------------------------------------------------------------------// There is no wxPopupWindows for wxMac. Use wxMessageBox instead.

// in wxGTK this initialization raises an assertion (makes sense too)// so initialize them to -1 and we 'll set them up correctly in InfoWindow's ctor the first timeint InfoWindow::screenWidth = -1;//wxSystemSettings::GetMetric(wxSYS_SCREEN_X);int InfoWindow::screenHeight = -1;//wxSystemSettings::GetMetric(wxSYS_SCREEN_Y);

wxWidgets for Mac has no support for wxPopupWindow. Here is a workaround.

The purpose of InfoWindow was to remove many of those annoying, intrusive dialog boxes. The idea was that even if you show messages of low importance that way ("the project was created"), it does not prevent the user from doing his work. On the downside, because InfoWindow is a lot less disturbing, we now have even more of them than before. Reverting to message boxes will probably make life on Macintosh a pain :?The reason for using wxPopupWindow in the first place was that there is no obvious way (at least not obvious to me) to open a window that doesn't immediately hijack the focus and move the top-level window back. wxPopupWindow, on the other hand side (although not documented) is perfectly unintrusive.Do you think it would be a good idea to try to find a hack that generates a "normal" thin-border toplevel window which gives back focus to the main window as soon as it gets it? There must be a way to accomplish this, since for example the popups shown by a wxChoice or wxComboBox are implemented using wxPopupWindow under GTK and Windows. Obviously, there must be a way to do this on MacOS, too.

Quote

Or is it just a waste of time (mine and everybody else's) before a core developer gets his/her hands on a Mac?

Well, let's put it that way: my estimate of the likelihood for this to happen during the next half year is zero.

To my knowledge, none of the other core devs has access to a Mac. I am a former Mac user decided to never spend one Euro on overpriced underpowered Apple hardware again, so that concludes myself, anyway Yiannis might possibly buy a machine from the project's donations one distant day in the future. However, to date, the donations do not even cover the web hosting for the forums, so that idea is way out of sight.Thus... unless a core dev happens to change jobs and happens to find a Mac over there, or some crazy rich Texan donates a Mac, the chances are dim, very dim...

« Last Edit: July 17, 2006, 06:00:23 pm by thomas »

Logged

"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

The purpose of InfoWindow was to remove many of those annoying, intrusive dialog boxes.<snip>Do you think it would be a good idea to try to find a hack that generates a "normal" thin-border toplevel window which gives back focus to the main window as soon as it gets it? There must be a way to accomplish this, since for example the popups shown by a wxChoice or wxComboBox are implemented using wxPopupWindow under GTK and Windows. Obviously, there must be a way to do this on MacOS, too.

Yes, a hack is needed. And thank you for the hints re: wxComboBox and wxChoice.The only reason I "hacked back" to messageBox was to get the new squirrel code working on the Mac and create new project xml's and patches.

I had already put the "infoMessage" support on the todo list.

I do, however, think that there are going to be many developers using CB on the Mac someday. Probably sooner than later looking at the interest stirred up on the forum. (Especially in schools)

Being an old Mac poo'er myself I was given the iMac and challenged to make CB work on it. With the promise that there would be a MacnTel in the future if I succeeded. So here I am..

Note: there is a wxBounty on making wxPopupWindow work on the Mac. Anyone interested?

Thanks for the advice, I applied the workaround to infowindow.I also made a change to wxPropertyGrid::SetFont, and moved the last return statement on line 5904 to a place inside the #if !defined(__WXMAC__) statement since it was undeclared in this context.

Now it compiles ok, but it does not link to wxwidgets, it concludes all wx symbols to be unresolved:/usr/bin/ld: Undefined symbols:wxStringBase::nposwxStringBase::InitWith(wchar_t const*, unsigned long, unsigned long)wxThread::TestDestroy()wxThread::~wxThread()...and more.

Thanks for the advice, I applied the workaround to infowindow.I also made a change to wxPropertyGrid::SetFont, and moved the last return statement on line 5904 to a place inside the #if !defined(__WXMAC__) statement since it was undeclared in this context.

Now it compiles ok, but it does not link to wxwidgets, it concludes all wx symbols to be unresolved:/usr/bin/ld: Undefined symbols:wxStringBase::nposwxStringBase::InitWith(wchar_t const*, unsigned long, unsigned long)wxThread::TestDestroy()wxThread::~wxThread()...and more.

Can you do a "./configure --help" and see if you can specify the way CB is built. Eg, you might need "./configure --enable-shared --enable-monolithic --enable-unicode" or some such verbage in order to match CB to your wx libs.

I've never been able to make the autotools work on my 10.3, so I'm not much help here.The trick is to generate CB to match the wx libs.

Also look at your config.log and config.status to see what it thought it was doing.

And about the link to the application, I have seens it.Actually, you answered my question about a problem I had with it,After unpacking, starting, and Ok on the compiler detection, I get a window "Scripting Error" Error compiling script, Error code -17(INVALID CONFIGURATION) any you answered that Angelscript wasn't supported yet.I was hoping a new build would solve the issue, maybe.

I begin to think that my darwinports wxwidgets installation may me the problem.In /opt/local/lib I see only wx-dylibs. Does wxwidgets never use static libraries? I will try manual installation from wxMac or similar and try again.

Correct me if I am wrong, but it seems you (and many others) have succeded in building C::B on OS X?If so, why do we have this problem?

AngelScript is no longer used. I thought you were using SVN.Anyway, getting the error in the first place is a feather in your hat.

Quote

In /opt/local/lib I see only wx-dylibs. Does wxwidgets never use static libraries?

CB only uses dynamic libraries. You can build and use static monolithic libs for your own projects. That is the suggested method for distributing your own Mac apps.

Quote

I will try manual installation from wxMac or similar and try again.

Correct me if I am wrong, but it seems you (and many others) have succeded in building C::B on OS X?If so, why do we have this problem?

I have never succeeded building wxMac263 on 10.4. So I couldn't build CodeBlocks. I think using a non-default Mac SDK will solve this problem. I suspect wxMac requires SDK3.3, but don't quote me. It's on the todo list.

I am very successful with Codeblocks on 10.3. No problems. I'm currently trying to find the glitches in wxMac Unicode and keep up with the core developers' changes.

Once I get unicode wx/CB stable, I'll tackle 10.4

All of us would be interested in your autotool experience.Could you do a "1,2,3 steps to success" report?

I will report whatever success I might have.Still I am problem whithe last stage in make, lots of unrecognized wx symbols.However, I will be away for vacation now for 3 weeks, so I will be silent for a while.

The bootstrap script requires the following versions of autotools etc.# - autoconf 2.50+# - automake 1.7+# - libtool 1.4+which is not what Apple darwin has as installed. I have 10.4.7 and the latest Xcode tools, so this is a bit surprising, or I missed something.

Install darwinports (http://www.darwinports.org)and doport install autoconfport install automakeport install libtool (which is accessed by the name of glibtool and glibtoolize)

All of these are installed at /opt/local/bin.

I don't want to interfere with the system I do not touch the native versions. and I also skip changing the path order for now.Instead I change the 'bootstrap' file, see bootstrap.txt:

Now configure and Makefile are created.configure and make behaves as expected.Well, not quite, since make never succeeds since it does not link properly to wxwidgets, lots of unresolved wx symbols.I cannot tell wether this is another problem or if it actually is because of a problem in the autotools.