Excellent! Doru
On 20 Nov 2011, at 14:53, Stéphane Ducasse wrote: > > On Nov 20, 2011, at 1:11 PM, Lukas Renggli wrote: > >> FYI: The mail of Colin Putney to the Squeak mailing list regarding the >> future of OmniBrowser. >> >> For Pharo there are also some changes upcoming: >> >> The latest GUI takes better advantage of the standard Polymorph >> widgets and brings resizable column and faster updates. > > cool! > > Stef > > > >> Lukas >> >> ---------- Forwarded message ---------- >> From: Colin Putney <[email protected]> >> Date: 20 November 2011 09:56 >> Subject: [squeak-dev] OmniBrowser and ToolBuilder >> To: Squeak-Dev <[email protected]> >> >> >> Hi folks, >> >> Lately I've been working with Lukas Renggli on a new version of >> OmniBrowser. The main focus has been on cleaning up and isolating >> platform dependencies so that we can have a single version that works >> well on both Squeak and Pharo, while fitting comfortably into each >> platform's idioms. That part of it has been quite well. >> >> For proper integration with Squeak, I've been trying to get OB >> building its interface using ToolBuilder. It *mostly* works, but there >> are some areas where ToolBuilder doesn't provide the functionality >> that OmniBrowser needs. I had planned to extend ToolBuilder a bit with >> the additional functionality that OB needs, but that turns out to be >> more work than I anticipated, and I wasn't able to get it done before >> the 4.3 feature freeze. So, given the constraint of working with the >> Squeak 4.3 feature set, I'm not quite sure how to proceed. >> >> Here are some of the options: >> >> 1) Abandon ToolBuilder and just deal with Morphic directly. This is >> what OB has historically done, and I'd just be updating the old >> Morphic code to fit better into modern Squeak conventions. There's no >> longer any need to have this code work on Pharo, since Lukas is now >> using a separate Polymorph-specific widget package on Pharo. >> >> 2) Use ToolBuilder where possible, but customize its output. This >> misses the point of ToolBuilder, since it means OB won't be able to >> work with MVC, but at least it reduces the chance that OB will get >> left behind if someone adds a feature to ToolBuilder. It is a bit of >> "worst of both worlds" situation. >> >> 3) Use ToolBuilder, and just accept that not all the features of OB >> will be available until they get added to ToolBuilder. I'm not sure >> how much graceful degradation I can acheive, but it might not be too >> bad, and it'll give us (me) motivation to improve ToolBuilder for >> Squeak 4.4. >> >> 4) Have the OB installation process patch the base image to add the >> needed functionality. That would be the cleanest in terms of the OB >> code, but has the potential to break other packages that users might >> want to load. >> >> I'd really like to make this next release a solid toolset for Squeak, >> and fix a lot of the little annoyances that cause Squeakers to avoid >> it. Lukas' refactoring stuff is really excellent, better than the >> VisualWorks refactoring browser IMHO, and I want to make it palatable >> to more people in the Squeak community. I'm leaning towards option #1, >> because I suspect it's the mostly likely to achieve that, but I >> thought I'd put it out there and ask the community for advice. So, how >> important is ToolBuilder? What options am I missing? >> >> >> Cheers, >> >> Colin >> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > -- www.tudorgirba.com "It's not how it is, it is how we see it."
