Chomping at Chandler

I think..

I just realized today that not everything has to be a block. Attribute editors are really just (relatively) lightweight wx widgets. So the email address field/overflow indicator thingee that has been causing me so many problems doesn’t have to be two separate blocks that talk to each other. I can put both wx widgets inside a sizer and hand that off as the “control” for the editor. i.e. the CreateControl() method can return the sizer.

Now, when that sizer is handed back in later methods, I will need to get the two child controls out of the sizer. Hopefully that won’t be too hard.

This is just as vent. No doubt I’ve missed something blindingly obvious, as usual.

So my plan last night was to simply copy Stefan’s new toolbar code into the alpha3 wx, test it with chandler, check it in and tell Bear the new tarball was ready to roll. But when I built wx and ran Chandler — it was the Attack of the Non-Native Toolbar.

This isn’t the first time this has happened to me. My previous battles with the NNT resulted in my eventual victory, through no means that I could discern. So here I am once again locked in mortal combat with the beast.

It should be so simple. There is one place that needs to have the right value: include/wx/mac/carbon/chkconf.h. In it, the constant ‘wxMAC_USE_NATIVE_TOOLBAR‘ is defined to be 1.

The only place that does *not* define wxMAC_USE_NATIVE_TOOLBAR to be 1 is in the CVS checkout of wx widgets, where it defaults to zero. But I never build in that directory.

So I try various shenanigans, like editing include/wx/mac/setup0.h, which has a line that says:
“#define wxUSE_TOOLBAR_NATIVE 0“.

However, I am assured that include/wx/macsetup0.h is not used in the build process at all, in which case I wonder why it’s still around?

Ah well, off to try my 4th or 5th iteration of a full build. Once I have appeased the gods, perhaps I will emerge victorious.

Well, I’ve turned off spell checking, so no more crashes. However, still no search bar!

The control is created and is getting called on occasion (e.g. to get its size when the window changes size). It’s just not visible.

One thing I had to do to the control before adding it to the toolbar was to remove it from its superview. When the control was created its “Window” was set to be the Chandler window. However, the toolbar API doc specifically says that the control should be created with a NULL Window parent. I thought the best I could do (since I have no control over how the control is created) was to call HIViewRemoveFromSuperview() on it. From the debugger, I could tell it certainly set the control’s window to NULL, so I think it’s the right thing to do.

However, whenever I do a dump of the control, I now see that its “Visible” value is always “no”. And indeed, it is not shown at all. I’ve added code to explicitly make the control visible, but it makes no difference.

So tomorrow I’m going to look into trying things like putting another (non-text) control in the toolbar and see if it’s another text-field-specific thing. I’ll just put a button in or something.

*sigh

I seem to have all the code working correctly, but Chandler crashes on startup.

You can see the stack traces here in both C++ and Python. It’s weird, as if it’s failing when it tries to start up a Cocoa runtime environment. Very frustrating too, because it’s the last thing that stands in the way of the search bar on Mac OS. :-/

I “filled in” the code for embedding any arbitrary control in a toolbar on the Mac. It’s a little tricky, because I was unable to pass the toolbar item down through the code as user data or a refcon or what have you. So instead, I use a static fifo (a C++ queue) to make the pointer available at the lowest level.

It’s a little frustrating becuase it *looks* like you can pass arbitrary data all the way down, however the OS seems to parse the data because it crashes if I try to do it. It may be that I need to wrap the pointer in a CFDataRef or something. But for now the static fifo is doing the job just fine.

I’m still working on them. Thought you’d like to see what the data structure looks like.

wx toolbar UML diagram

I made it using OmniGraffle, and excellent app for doing all sorts of diagrams. It’s the Visio equivalent for the Mac.

A few days before the 0.7α3 feature freeze, I managed to get the search field working on OS X by turning on “native toolbar” support in wx. However, there were a number of negative side-effects, and it was decided that search wasn’t a priority for this release, so I thought it would be a good idea to turn the toolbar back to the way it was.

It shouldn’t have been too difficult. There are two places that define the required #define, and I changed both of them. However, the toolbar remained as it was. Ack!

I have spent the days since then attempting to build a wx that restores the old toolbar. And so far, with no success! The specific files involved are: include/wx/mac/setup0.h and include/wx/mac/carbon/chkconf.h. These files contain a #define for wxMAC_USE_NATIVE_TOOLBAR.

To restore the old toolbar, all I need do is set this to zero. However, I have been unable to accomplish this in builds on my Mac. I have ripped apart, blown-away-and-re-checked-out everything to no avail.

At this point I wonder if it’s best to just edit the code, check it in, and hope that the official build gets it working?

Update [2006-06-29-1037]:
There is another #define called wxUSE_TOOLBAR_NATIVE, but it isn’t used for anything in the Mac code at all. It’s weird. I think that perhaps the creation of wxMAC_USE_NATIVE_TOOLBAR was a mistake, and wxUSE_TOOLBAR_NATIVE should have been used instead. Oh well.

I got these errors when I tried to build wx tonight:

./bk-deps g++ -c -o monodll_colheader.o -I.pch/wxprec_monodll -D__WXMAC__ -I../src/tiff -I../src/jpeg -I../src/png -I../src/regex -I../src/expat/lib -DwxUSE_BASE=1 -DWXMAKINGDLL -dynamic -fPIC -DPIC -DWX_PRECOMP -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -Ilib/wx/include/mac-unicode-release-2.7 -I../include -fpascal-strings -I../src/mac/carbon/morefilex -I/Developer/Headers/FlatCarbon -Wall -Wundef -Wno-ctor-dtor-privacy -O2 -fno-strict-aliasing -fno-common ../src/generic/colheader.cpp
../src/generic/colheader.cpp: In member function ‘void wxChandlerGridLabelWindow::OnMouseEvent(wxMouseEvent&)’:
../src/generic/colheader.cpp:225: error: ‘m_StyleVariant’ was not declared in this scope
../src/generic/colheader.cpp: In constructor ‘wxColumnHeader::wxColumnHeader(wxWindow*, wxWindowID, const wxPoint&, const wxSize&, long int, const wxString&)’:
../src/generic/colheader.cpp:444: error: ‘m_StyleVariant’ was not declared in this scope
../src/generic/colheader.cpp: In member function ‘void wxColumnHeader::Init()’:
../src/generic/colheader.cpp:475: error: ‘m_StyleVariant’ was not declared in this scope
../src/generic/colheader.cpp: In member function ‘bool wxColumnHeader::Create(wxWindow*, wxWindowID, const wxPoint&, const wxSize&, long int, const wxString&)’:
../src/generic/colheader.cpp:528: error: ‘CalculateDefaultItemSizeInWindow’ is not a member of ‘wxColumnHeader’
../src/generic/colheader.cpp: At global scope:
../src/generic/colheader.cpp:918: error: no ‘wxSize wxColumnHeader::CalculateDefaultItemSizeInWindow(const wxSize&, bool&) const’ member function declared in class ‘wxColumnHeader’
make[1]: *** [monodll_colheader.o] Error 1
make: *** [wxWidgets] Error 2

At a guess it looks like a header file wasn’t checked in or something.

Overheard in IRC..

[14:51] aparna: mikeal-fu: you want to try changing the wx tarball to relver 35 and try?
[14:51] mikeal-fu: i haven’t done it before
[14:51] mikeal-fu: but I’ll try
[14:51] ovaltofu: here are the steps mikeal-fu:
[14:51] ovaltofu: change wxPython in chandler/Makefile to 35
[14:52] ovaltofu: then remove the wsPython-*-.inst files in release
[14:52] ovaltofu: make wxPython (in chandler)
[14:52] heikkit: ovaltofu, mikeal-fu: just to be sure, might want to rm wx* in site-packages before the make command

Just thought this might prove useful later..

After looking into things a bit, I’ve found out that the term “toolbar” means different things to different platforms.

On the Mac, there is one (1) toolbar per window, and it lives directly under the window’s title bar. No ifs, ands or buts.

Meanwhile, on Windows, a toolbar can be anywhere, can have customizable tools, can be dragged out of a window sometimes, and turned into its own little palette window.

Linux pretty much follows Windows in this regard.

So, we have an unfortunate conflict of terms here. I would say that the Windows “toolbar” is more like a “pane”, or perhaps the Mac “toolbar” is really a “windowbar”. I dunno. But the two “toolbars” need to be divorced from each other in terms of implementation.

---

Hm, went on a bit of a tangent there. I was going to say that after talking with Mimi, Sheila, Philippe and Bryan, I am going to remove the “toolbar” from underneath the Markup Bar buttons. This should make life much easier, because this makes them just a bunch-o’-buttons.

Now I can make my own button class and be a happy camper.

Hey, I just found out that there is a wxRuby! This is interesting because Chandler is a big wxPython app, and I’ve always been a fan of Ruby myself.

I wonder if the two could be made to talk to each other? Maybe extend Chandler to handle other languages.

Developers tend to be very protective of their language-of-choice.