Menu
▾
▴
wxlua-users
|
From: <af...@al...> - 2006-03-06 19:26:34
|
Hi, I've posted a patch to the SourceForge tracker with some changes needed for wxMac compilation... http://sourceforge.net/tracker/index.php? func=detail&aid=1444354&group_id=140042&atid=745326 Some of it applied to the general parts of wxLua, it was missing a declaration and some inlines ? Applying that, and messing around with the configuration (like adding Scintilla and wxStEdit to wx, for instance) makes it compile and work on Mac OS X as well as the others. (tested on Mac OS X 10.3 with wxWidgets 2.6.1 for "Carbon") One needs to run the usual `wx-config --rezflags` on the exe/binaries or bundle them up, but that is standard on Mac. Thanks for a great package, --anders http://www.algonet.se/~afb/ |
|
From: Francesco M. <f18...@ya...> - 2006-03-06 22:29:43
|
Hi, Anders F Björklund ha scritto: > I've posted a patch to the SourceForge tracker > with some changes needed for wxMac compilation... > > http://sourceforge.net/tracker/index.php?func=detail&aid=1444354&group_id=140042&atid=745326 Thanks ! I'm quite sure the patch is good. Unfortunately I haven't got a Mac to test it nor John or Klaas, I think so your help is very useful! > Applying that, and messing around with the configuration > (like adding Scintilla and wxStEdit to wx, for instance) > makes it compile and work on Mac OS X as well as the others. > (tested on Mac OS X 10.3 with wxWidgets 2.6.1 for "Carbon") I see in patch tracker comment that you had to tweak the lua makefile. Why did you use it ? the configure script should do all checks for you and it will produce a modules/Makefile which should build lua without using lua's own makefile (which is not generated through configure and is placed in modules\lua\Makefile).,, > One needs to run the usual `wx-config --rezflags` on the > exe/binaries or bundle them up, but that is standard on Mac. On my linux, wx-config --rezflags returns: @true Warning: --rezflags, along with Mac OS classic resource building is deprecated. You should remove this from your Makefile and build .app bundles instead. but I have no idea what .app bundles are. If you could help making mac installation smoother, it would be great ! Francesco |
|
From: <af...@al...> - 2006-03-06 22:38:44
|
Francesco Montorsi wrote: > I'm quite sure the patch is good. Unfortunately I haven't got a Mac to > test it nor John or Klaas, I think so your help is very useful! No problem, but some of the issues encountered should be present on all the platforms ? Especially these two: 1) wxluaedit.cpp patch 2) wxlua.cpp + wxlsock.cpp patch > I see in patch tracker comment that you had to tweak the lua makefile. > Why did you use it ? > the configure script should do all checks for you and it will produce > a modules/Makefile which should build lua without using lua's own > makefile (which is not generated through configure and is placed in > modules\lua\Makefile).,, Okay, maybe that was uncalled for then... :-) I'm just kinda used to patching Lua for the Mac, so it mostly went out of old habit or something. (see http://www.algonet.se/~afb/lua/) > On my linux, wx-config --rezflags returns: > > @true > Warning: --rezflags, along with Mac OS classic resource building is > deprecated. You should remove this from your Makefile and build .app > bundles instead. > > but I have no idea what .app bundles are. Deprecated doesn't mean "dead", though... :-) It still works. I did a write-up on the subject for the Code::Blocks wiki, maybe it helps you: http://wiki.codeblocks.org/index.php?title=Compiling_Code:: Blocks_in_Mac_OS_X#Bundle_application_for_Mac > If you could help making mac installation smoother, it would be great ! Sure, I can make an installer for it. (eventually) --anders |
|
From: Francesco M. <f18...@ya...> - 2006-03-06 23:00:38
|
Anders F Björklund ha scritto: > Francesco Montorsi wrote: > >> I'm quite sure the patch is good. Unfortunately I haven't got a Mac to >> test it nor John or Klaas, I think so your help is very useful! > > No problem, but some of the issues encountered should > be present on all the platforms ? Especially these two: > 1) wxluaedit.cpp patch 2) wxlua.cpp + wxlsock.cpp patch the absence of __WXMAC__ symbols can only be noticed when compiling on Mac :) the inclusion of lua internal.h is strange - we don't need it on win or unix. Last the addition of the wxSTENotebook is probably not required using the latest wxStEdit from CVS... > >> I see in patch tracker comment that you had to tweak the lua makefile. >> Why did you use it ? >> the configure script should do all checks for you and it will produce >> a modules/Makefile which should build lua without using lua's own >> makefile (which is not generated through configure and is placed in >> modules\lua\Makefile).,, > > Okay, maybe that was uncalled for then... :-) > I'm just kinda used to patching Lua for the Mac, > so it mostly went out of old habit or something. > > (see http://www.algonet.se/~afb/lua/) ok, could you please check out the latest CVS of wxLua and try the configure script on your Mac ? It would be very useful to know how much portable it is... > >> On my linux, wx-config --rezflags returns: >> >> @true >> Warning: --rezflags, along with Mac OS classic resource building is >> deprecated. You should remove this from your Makefile and build .app >> bundles instead. >> >> but I have no idea what .app bundles are. > > Deprecated doesn't mean "dead", though... :-) ;) > It still works. I did a write-up on the subject > for the Code::Blocks wiki, maybe it helps you: > > http://wiki.codeblocks.org/index.php?title=Compiling_Code::Blocks_in_Mac_OS_X#Bundle_application_for_Mac I'll look deeper into this ASAP > > >> If you could help making mac installation smoother, it would be great ! > > Sure, I can make an installer for it. (eventually) interesting ! I think adding a folder like build\macbundle containing all required files could be enough ? Would you require any change in build system (i.e. Makefiles)? We manage them using Bakefile so I can help with it... Francesco |
|
From: <af...@al...> - 2006-03-06 23:27:30
|
Francesco Montorsi wrote: > the absence of __WXMAC__ symbols can only be noticed when compiling on > Mac :) Yeah, those I'll worry about so no need to check on Windows/Linux :-) > the inclusion of lua internal.h is strange - we don't need it on win > or unix. Well, the reason I needed to add it was that I got missing symbols for lua2wx and wx2lua. It is supposed to inline those calls, but... > Last the addition of the wxSTENotebook is probably not required using > the latest wxStEdit from CVS... Okey dokey, will check the CVS then (SourceForge CVS lags a *lot* for anonymous access, it's only live when you are using SSH...) > ok, could you please check out the latest CVS of wxLua and try the > configure script on your Mac ? > It would be very useful to know how much portable it is... configure script worked like a charm, that "config" was in error > I think adding a folder like build\macbundle containing all required > files could be enough ? Yes, or just a few extra steps before packaging it up for the end user. The current Makefile does all things needed for a UNIX-type installation > Would you require any change in build system (i.e. Makefiles)? > We manage them using Bakefile so I can help with it... Not to just compile it, no. And the Installer packages are easiest done with Apple's PackageMaker.app, not sure it needs a Makefile ? --anders |
|
From: Francesco M. <f18...@ya...> - 2006-03-07 12:10:39
|
Hi,
Anders F Björklund ha scritto:
> Francesco Montorsi wrote:
>> the inclusion of lua internal.h is strange - we don't need it on win
>> or unix.
>
> Well, the reason I needed to add it was that I got missing symbols
> for lua2wx and wx2lua. It is supposed to inline those calls, but...
I've checked in the __WXMAC__ changes and the inclusion of internal.h
but not these changes:
+#ifndef __WXMAC__
// call constructor
returns = new wxDropSource(win, *iconCopy, *iconMove, *iconStop);
+#else
+ returns = new wxDropSource(win);
+#endif
they affect automatically-generated files rather than their generators
and thus should be changed.
Why does Mac need this asimmetry ?
>
>> Last the addition of the wxSTENotebook is probably not required using
>> the latest wxStEdit from CVS...
>
> Okey dokey, will check the CVS then (SourceForge CVS lags a *lot*
> for anonymous access, it's only live when you are using SSH...)
I know :(
>
>> ok, could you please check out the latest CVS of wxLua and try the
>> configure script on your Mac ?
>> It would be very useful to know how much portable it is...
>
> configure script worked like a charm, that "config" was in error
good
>
>> I think adding a folder like build\macbundle containing all required
>> files could be enough ?
>
> Yes, or just a few extra steps before packaging it up for the end user.
> The current Makefile does all things needed for a UNIX-type installation
ok; then just send me the files to put there once you've prepared them...
>
>> Would you require any change in build system (i.e. Makefiles)?
>> We manage them using Bakefile so I can help with it...
>
> Not to just compile it, no. And the Installer packages are easiest
> done with Apple's PackageMaker.app, not sure it needs a Makefile ?
if it needs a Makefile I could just create a small target "macbundle" in
wxLua makefile which just calls it...
Thanks,
Francesco
|
|
From: <af...@al...> - 2006-03-07 12:23:00
|
Francesco Montorsi wrote:
> I've checked in the __WXMAC__ changes and the inclusion of internal.h
> but not these changes:
>
> +#ifndef __WXMAC__
> // call constructor
> returns = new wxDropSource(win, *iconCopy, *iconMove, *iconStop);
> +#else
> + returns = new wxDropSource(win);
> +#endif
>
> they affect automatically-generated files rather than their generators
> and thus should be changed.
> Why does Mac need this asimmetry ?
Someone declared the Mac constructor with the wrong type arguments...
The icons aren't being used anyway, so it's a pretty silly error :-)
// ctors: if you use default ctor you must call SetData() later!
//
// NB: the "wxWindow *win" parameter is unused and is here only for
wxGTK
// compatibility, as well as both icon parameters
wxDropSource( wxWindow *win = (wxWindow *)NULL,
const wxCursor &cursorCopy = wxNullCursor,
const wxCursor &cursorMove = wxNullCursor,
const wxCursor &cursorStop = wxNullCursor);
I thought it would be easiest to just *not* supply the icons on wxMac ?
(BTW; You can peek at the Mac stuff for wxWidgets, it's in "mac/carbon")
--anders
|
|
From: Francesco M. <f18...@ya...> - 2006-03-07 17:25:00
|
Anders F Björklund ha scritto: > Francesco Montorsi wrote: > >> I've checked in the __WXMAC__ changes and the inclusion of internal.h >> but not these changes: >> >> +#ifndef __WXMAC__ >> // call constructor >> returns = new wxDropSource(win, *iconCopy, *iconMove, *iconStop); >> +#else >> + returns = new wxDropSource(win); >> +#endif >> >> they affect automatically-generated files rather than their generators >> and thus should be changed. >> Why does Mac need this asimmetry ? > > Someone declared the Mac constructor with the wrong type arguments... > The icons aren't being used anyway, so it's a pretty silly error :-) > > // ctors: if you use default ctor you must call SetData() later! > // > // NB: the "wxWindow *win" parameter is unused and is here only for > wxGTK > // compatibility, as well as both icon parameters > wxDropSource( wxWindow *win = (wxWindow *)NULL, > const wxCursor &cursorCopy = wxNullCursor, > const wxCursor &cursorMove = wxNullCursor, > const wxCursor &cursorStop = wxNullCursor); > > I thought it would be easiest to just *not* supply the icons on wxMac ? > (BTW; You can peek at the Mac stuff for wxWidgets, it's in "mac/carbon") This really looks as a bug in wxWidgets itself. I think it would be difficult to handle this case nicely in wxLua binding wrappers... it's probably better to submit a patch to wx devs and ask them to apply it before 2.6.3... if those icons aren't really used it should not be a big issue just replacing wxCursor->wxIcon... am I right ? Francesco |
|
From: <af...@al...> - 2006-03-07 21:33:38
|
Francesco Montorsi wrote:
> This really looks as a bug in wxWidgets itself.
Yes it does, but it's present in 2.6.1 and 2.6.2 at least even if we
"fix" 2.6.3 ?
> I think it would be difficult to handle this case nicely in wxLua
> binding wrappers... it's probably better to submit a patch to wx devs
> and ask them to apply it before 2.6.3...
> if those icons aren't really used it should not be a big issue just
> replacing wxCursor->wxIcon...
> am I right ?
It might be a little trickier, as they actually pass them up to
wxDropSourceBase...
wxDropSource::wxDropSource(wxWindow *win,
const wxCursor &cursorCopy,
const wxCursor &cursorMove,
const wxCursor &cursorStop)
: wxDropSourceBase(cursorCopy, cursorMove, cursorStop)
{
wxMacEnsureTrackingHandlersInstalled() ;
m_window = win;
}
wxDropSourceBase(const wxCursor &cursorCopy = wxNullCursor,
const wxCursor &cursorMove = wxNullCursor,
const wxCursor &cursorStop = wxNullCursor)
: m_cursorCopy(cursorCopy),
m_cursorMove(cursorMove),
m_cursorStop(cursorStop)
{ m_data = (wxDataObject *)NULL; }
So the current workaround, of not passing anything for wxMac should
work better ?
--anders
|
|
From: Francesco M. <f18...@ya...> - 2006-03-08 20:03:25
|
Anders F Björklund ha scritto:
> Francesco Montorsi wrote:
>
>> This really looks as a bug in wxWidgets itself.
>
> Yes it does, but it's present in 2.6.1 and 2.6.2 at least even if we
> "fix" 2.6.3 ?
>
>> I think it would be difficult to handle this case nicely in wxLua
>> binding wrappers... it's probably better to submit a patch to wx devs
>> and ask them to apply it before 2.6.3...
>> if those icons aren't really used it should not be a big issue just
>> replacing wxCursor->wxIcon...
>> am I right ?
>
> It might be a little trickier, as they actually pass them up to
> wxDropSourceBase...
>
> wxDropSource::wxDropSource(wxWindow *win,
> const wxCursor &cursorCopy,
> const wxCursor &cursorMove,
> const wxCursor &cursorStop)
> : wxDropSourceBase(cursorCopy, cursorMove, cursorStop)
> {
> wxMacEnsureTrackingHandlersInstalled() ;
> m_window = win;
> }
>
> wxDropSourceBase(const wxCursor &cursorCopy = wxNullCursor,
> const wxCursor &cursorMove = wxNullCursor,
> const wxCursor &cursorStop = wxNullCursor)
> : m_cursorCopy(cursorCopy),
> m_cursorMove(cursorMove),
> m_cursorStop(cursorStop)
> { m_data = (wxDataObject *)NULL; }
>
> So the current workaround, of not passing anything for wxMac should work
> better ?
I've Cc'ed you with the reply of a mail I got from wxDev...
I'll try to make a patch when I have time for that.
By now if the mod of John works, everything is okay ;)
Francesco
|
|
From: John L. <jla...@gm...> - 2006-03-07 19:02:28
|
On 3/7/06, Francesco Montorsi <f18...@ya...> wrote:
> Anders F Bj=F6rklund ha scritto:
> > Francesco Montorsi wrote:
> >
> >> I've checked in the __WXMAC__ changes and the inclusion of internal.h
> >> but not these changes:
> >>
> >> +#ifndef __WXMAC__
> >> // call constructor
> >> returns =3D new wxDropSource(win, *iconCopy, *iconMove, *iconStop=
);
> >> +#else
> >> + returns =3D new wxDropSource(win);
> >> +#endif
> >>
> >> they affect automatically-generated files rather than their generators
> >> and thus should be changed.
> >> Why does Mac need this asimmetry ?
> >
> > Someone declared the Mac constructor with the wrong type arguments...
> > The icons aren't being used anyway, so it's a pretty silly error :-)
> >
> > // ctors: if you use default ctor you must call SetData() later!
> > //
> > // NB: the "wxWindow *win" parameter is unused and is here only for
> > wxGTK
> > // compatibility, as well as both icon parameters
> > wxDropSource( wxWindow *win =3D (wxWindow *)NULL,
> > const wxCursor &cursorCopy =3D wxNullCursor,
> > const wxCursor &cursorMove =3D wxNullCursor,
> > const wxCursor &cursorStop =3D wxNullCursor);
> >
> > I thought it would be easiest to just *not* supply the icons on wxMac ?
> > (BTW; You can peek at the Mac stuff for wxWidgets, it's in "mac/carbon"=
)
> This really looks as a bug in wxWidgets itself.
> I think it would be difficult to handle this case nicely in wxLua
> binding wrappers... it's probably better to submit a patch to wx devs
> and ask them to apply it before 2.6.3...
> if those icons aren't really used it should not be a big issue just
> replacing wxCursor->wxIcon...
I did a fix for it in the binding files. Hopefully it'll work now.
%win|%mac wxDropSource(wxWindow* win =3D NULL, const wxCursor&
iconCopy =3D wxNullCursor, const wxCursor& iconMove =3D wxNullCursor,
const wxCursor& iconStop =3D wxNullCursor)
%gtk wxDropSource(wxWindow* win =3D NULL, const wxIcon& iconCopy =3D
wxNullIcon, const wxIcon& iconMove =3D wxNullIcon, const wxIcon&
iconStop =3D wxNullIcon)
Francesco, are there any other things that need to be fixed that you
haven't done yet?
Regards,
John Labenski
|
|
From: Francesco M. <f18...@ya...> - 2006-03-07 19:09:04
|
John Labenski ha scritto: > On 3/7/06, Francesco Montorsi <f18...@ya...> wrote: >> Anders F Björklund ha scritto: >>> Francesco Montorsi wrote: >>> >>>> I've checked in the __WXMAC__ changes and the inclusion of internal.h >>>> but not these changes: >>>> >>>> +#ifndef __WXMAC__ >>>> // call constructor >>>> returns = new wxDropSource(win, *iconCopy, *iconMove, *iconStop); >>>> +#else >>>> + returns = new wxDropSource(win); >>>> +#endif >>>> >>>> they affect automatically-generated files rather than their generators >>>> and thus should be changed. >>>> Why does Mac need this asimmetry ? >>> Someone declared the Mac constructor with the wrong type arguments... >>> The icons aren't being used anyway, so it's a pretty silly error :-) >>> >>> // ctors: if you use default ctor you must call SetData() later! >>> // >>> // NB: the "wxWindow *win" parameter is unused and is here only for >>> wxGTK >>> // compatibility, as well as both icon parameters >>> wxDropSource( wxWindow *win = (wxWindow *)NULL, >>> const wxCursor &cursorCopy = wxNullCursor, >>> const wxCursor &cursorMove = wxNullCursor, >>> const wxCursor &cursorStop = wxNullCursor); >>> >>> I thought it would be easiest to just *not* supply the icons on wxMac ? >>> (BTW; You can peek at the Mac stuff for wxWidgets, it's in "mac/carbon") >> This really looks as a bug in wxWidgets itself. >> I think it would be difficult to handle this case nicely in wxLua >> binding wrappers... it's probably better to submit a patch to wx devs >> and ask them to apply it before 2.6.3... >> if those icons aren't really used it should not be a big issue just >> replacing wxCursor->wxIcon... > > I did a fix for it in the binding files. Hopefully it'll work now. > > %win|%mac wxDropSource(wxWindow* win = NULL, const wxCursor& > iconCopy = wxNullCursor, const wxCursor& iconMove = wxNullCursor, > const wxCursor& iconStop = wxNullCursor) > > %gtk wxDropSource(wxWindow* win = NULL, const wxIcon& iconCopy = > wxNullIcon, const wxIcon& iconMove = wxNullIcon, const wxIcon& > iconStop = wxNullIcon) very nice workaround but I'll send a mail to wxdev anyway. > > Francesco, are there any other things that need to be fixed that you > haven't done yet? no; now wxLua should compile & work also on wxMac. We just need wxMac screenshots and packaging stuff :) Francesco |
|
From: John L. <jla...@gm...> - 2006-03-07 19:24:35
|
On 3/7/06, Francesco Montorsi <f18...@ya...> wrote: > John Labenski ha scritto: > > Francesco, are there any other things that need to be fixed that you > > haven't done yet? > no; now wxLua should compile & work also on wxMac. > We just need wxMac screenshots and packaging stuff :) Great! That'd be pretty nice to get it going there too. -John Labenski |
|
From: <af...@al...> - 2006-03-07 21:27:54
|
Francesco Montorsi wrote: >> Francesco, are there any other things that need to be fixed that you >> haven't done yet? > no; now wxLua should compile & work also on wxMac. > We just need wxMac screenshots and packaging stuff :) It compiles OK, but works ? Not 100%, I discovered. Missed that the tabs of wxLuaEdit are screwed up :( But it could be something minor, or upstream problem. (i.e. no reason to say that it doesn't support wxMac) --anders |
|
From: Francesco M. <f18...@ya...> - 2006-03-08 19:39:22
|
Anders F Björklund ha scritto: > Francesco Montorsi wrote: > >>> Francesco, are there any other things that need to be fixed that you >>> haven't done yet? >> no; now wxLua should compile & work also on wxMac. >> We just need wxMac screenshots and packaging stuff :) > > It compiles OK, but works ? Not 100%, I discovered. > Missed that the tabs of wxLuaEdit are screwed up :( > > But it could be something minor, or upstream problem. > (i.e. no reason to say that it doesn't support wxMac) does the wxStedit sample looks good on your Mac ? Francesco |
|
From: <af...@al...> - 2006-03-08 20:43:19
|
Francesco Montorsi wrote: >> Missed that the tabs of wxLuaEdit are screwed up :( >> But it could be something minor, or upstream problem. >> (i.e. no reason to say that it doesn't support wxMac) > does the wxStedit sample looks good on your Mac ? Yes it does, so there is hope :-) --anders |
|
From: John L. <jla...@gm...> - 2006-03-08 23:13:59
|
On 3/8/06, Anders F Bj=F6rklund <af...@al...> wrote:
> Francesco Montorsi wrote:
>
> >> Missed that the tabs of wxLuaEdit are screwed up :(
> >> But it could be something minor, or upstream problem.
> >> (i.e. no reason to say that it doesn't support wxMac)
> > does the wxStedit sample looks good on your Mac ?
>
> Yes it does, so there is hope :-)
What do you mean about tabs being screwed up? Could you try again, I
made a little fix to the sizing of the wxLuaConsole class so that it
uses EVT_SIZE and not virtual wxWindow::DoSetSize. Hopefully this'll
do it?
Regards,
John Labenski
|
|
From: Francesco M. <f18...@ya...> - 2006-03-08 23:21:51
|
John Labenski ha scritto: > On 3/8/06, Anders F Björklund <af...@al...> wrote: >> Francesco Montorsi wrote: >> >>>> Missed that the tabs of wxLuaEdit are screwed up :( >>>> But it could be something minor, or upstream problem. >>>> (i.e. no reason to say that it doesn't support wxMac) >>> does the wxStedit sample looks good on your Mac ? >> Yes it does, so there is hope :-) > > What do you mean about tabs being screwed up? Could you try again, I > made a little fix to the sizing of the wxLuaConsole class so that it > uses EVT_SIZE and not virtual wxWindow::DoSetSize. Hopefully this'll > do it? you can see the problem he's referring to looking at http://localhost/wxLuaWebsite/screenshots/wxlua_miscsamples_mac.png Francesco |
|
From: <af...@al...> - 2006-03-08 23:22:58
|
John Labenski wrote: > What do you mean about tabs being screwed up? See the screenshot, it's "really really small" :-) http://wxlua.sourceforge.net/screenshots/wxlua_miscsamples_mac.png Here is what the "wxstedit" C++ sample looks like: http://www.algonet.se/~afb/wx/wxstedit.png > Could you try again, Will do that tomorrow, then. --anders |
|
From: <af...@al...> - 2006-03-09 07:28:11
|
John Labenski wrote: > made a little fix to the sizing of the wxLuaConsole class so that it > uses EVT_SIZE and not virtual wxWindow::DoSetSize. Hopefully this'll > do it? Updated from CVS, but seems there are some other changes as well: #error wxStEdit does not define its version symbols STE_MAJOR_VERSION, STE_MINOR_VERSION, STE_RELEASE_VERSION Will investigate what I need to update on my end. Tomorrow, was it ? :-) --anders |
|
From: Francesco M. <f18...@ya...> - 2006-03-09 18:40:54
|
Anders F Björklund ha scritto: > John Labenski wrote: > >> made a little fix to the sizing of the wxLuaConsole class so that it >> uses EVT_SIZE and not virtual wxWindow::DoSetSize. Hopefully this'll >> do it? > > Updated from CVS, but seems there are some other changes as well: > > #error wxStEdit does not define its version symbols STE_MAJOR_VERSION, > STE_MINOR_VERSION, STE_RELEASE_VERSION > > Will investigate what I need to update on my end. Tomorrow, was it ? :-) this is a error message I added yersterday. Make sure to update wxStEdit from CVS too and the problem should disappear... Francesco |
|
From: <af...@al...> - 2006-03-09 19:25:59
|
Francesco Montorsi wrote: >> Will investigate what I need to update on my end. Tomorrow, was it ? >> :-) > this is a error message I added yersterday. Make sure to update > wxStEdit from CVS too and the problem should disappear... Found that wxstedit had installed itself to /usr/local/include/wx, so it was still picking up 1.0.0 from /usr/local/include/wx-26/wx... Then, my header has: #define STE_MAJOR_VERSION 1 #define STE_MINOR_VERSION 2 #define STE_RELEASE_NUMBER 0 #define STE_SUBRELEASE_NUMBER 0 But configure checked: #if defined(STE_MAJOR_VERSION) && defined(STE_MINOR_VERSION) && defined(STE_RELEASE_VERSION) So that was why it still didn't think the version was defined enough. --anders |
|
From: <af...@al...> - 2006-03-09 20:49:02
|
> What do you mean about tabs being screwed up? Could you try again, I > made a little fix to the sizing of the wxLuaConsole class so that it > uses EVT_SIZE and not virtual wxWindow::DoSetSize. Hopefully this'll > do it? Well, eventually I got it all updated from CVS (and to wxStEdit 1.2.0) and it looks a whole lot better now! Will take another Mac screenshot, as soon as the packaging is done and some minor install issues cleared: cp: ./build/autopackage/wxlua.xml: No such file or directory --anders |
|
From: Francesco M. <f18...@ya...> - 2006-03-09 22:07:00
|
Anders F Björklund ha scritto: >> What do you mean about tabs being screwed up? Could you try again, I >> made a little fix to the sizing of the wxLuaConsole class so that it >> uses EVT_SIZE and not virtual wxWindow::DoSetSize. Hopefully this'll >> do it? > > Well, eventually I got it all updated from CVS (and to wxStEdit 1.2.0) > and it looks a whole lot better now! Will take another Mac screenshot, > as soon as the packaging is done and some minor install issues cleared: > > cp: ./build/autopackage/wxlua.xml: No such file or directory my fault: I forgot to add to CVS that file... It should be fixed now. BTW, does your locale uses a dot or a comma or something else for decimal point ? If it uses something != dot, could you please try to run the wxluasudoku.wx.lua sample in samples\: I've applied a fix for locales with decimal point != dot only for __WXGTK__ but maybe it's needed also for __WXMAC__.... Francesco |
|
From: <af...@al...> - 2006-03-09 22:51:45
|
Francesco Montorsi wrote: > BTW, does your locale uses a dot or a comma or something else for > decimal point ? Sweden uses a comma for decimal point, I think that should be in my locale ? (it varies a little, sometimes I use an US locale for the shell and terminal) > If it uses something != dot, could you please try to run the > wxluasudoku.wx.lua sample in samples\: I've applied a fix for locales > with decimal point != dot only for __WXGTK__ but maybe it's needed > also for __WXMAC__.... Could be, but wxluasudoku.wx.lua has some other problems on wxMac, it seems... For starters it doesn't draw any lines or digits, which I think it should ? :-) http://www.algonet.se/~afb/wx/wxluasudoku-wxmac.png And I think I spoke too soon about the wxluaedit progress. Now it looks OK. The only problem is that the "New" and "Open" menu items doesn't work ? If you try starting it with an argument, like: wxluaedit samples/dialog.wx.lua you get a crash (bus error, same as segfault on Linux) in wxledit.cpp, I think: Program received signal EXC_BAD_ACCESS, Could not access memory. 0x00009c9c in wxLuaEditorApp::OnInit() () (gdb) bt #0 0x00009c9c in wxLuaEditorApp::OnInit() () #1 0x01979954 in wxEntry(int&, char**) () #2 0x000090d4 in main () Will recompile wxLua with full debugging symbols enabled tomorrow, I think. --anders |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X