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 |
On 20 November 2011 08:56, Colin Putney <[hidden email]> wrote:
> 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? What options are missing from ToolBuilder? Is it just a case of missing specs (+ Morphic backing) for some set of widgets? I really like ToolBuilder: it lets me see the skeleton of the UI - and alter it - without the steep Morphic learning curve that's so far put me off learning it. frank |
In reply to this post by Colin Putney-3
On 11/20/11 6:56 AM, "Colin Putney" <[hidden email]> wrote: > 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 this extended functionality comes in near future Squeak 4.4. > 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. And add some logic for when we updated Squeak also updated OB. OB becomes default at some point IMHO. Very thanks to you and to Lukas for working in OB. Edgar |
In reply to this post by Colin Putney-3
On Sun, Nov 20, 2011 at 12:56:26AM -0800, Colin Putney wrote:
> 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. This (option 4) sounds like the right thing to do. Toolbuilder is not really complete at this point, so it seems likely that whatever you need to implement for OmniBrowser will turn out to be the right thing to do in the long run. I am not aware of any other projects in development that would lead to conflicts, so if you add ToolBuilder extensions to OB now, adopting these in the base ToolBuilder package later should be no problem. > > 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? Thanks for doing this. Improvements to ToolBuilder would be welcome, and having them driven by the requirements of a real application (OB) should help ensure that the right features are implemented. Dave |
In reply to this post by Frank Shearar-3
On 2011-11-20, at 1:15 AM, Frank Shearar <[hidden email]> wrote:
> What options are missing from ToolBuilder? Is it just a case of > missing specs (+ Morphic backing) for some set of widgets? No, the widgets all seem to be there. What's missing is configuration options, and in some cases, capability in the Morphic widgets. For example, a bunch of refactorings operate on the current selection in the text pane. (eg. Extract Method.) Pluggable TextMorphPlus doesn't give the model any way to find out what the selection is when the building the context menu, so it can't decide what refactorings are applicable. Colin |
In reply to this post by David T. Lewis
On 11/20/11, David T. Lewis <[hidden email]> wrote:
> On Sun, Nov 20, 2011 at 12:56:26AM -0800, Colin Putney wrote: >> 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. > > This (option 4) sounds like the right thing to do. Toolbuilder is > not really complete at this point, so it seems likely that whatever > you need to implement for OmniBrowser will turn out to be the right > thing to do in the long run. I am not aware of any other projects > in development that would lead to conflicts, so if you add ToolBuilder > extensions to OB now, adopting these in the base ToolBuilder package > later should be no problem. I like option 4 as well. >> >> 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? > > Thanks for doing this. Improvements to ToolBuilder would be welcome, and > having them driven by the requirements of a real application (OB) should > help ensure that the right features are implemented. My thanks as well. This is great news that you worked with Lukas to create a common code base and are working on adaptions to Squeak and Pharo. --Hannes > Dave > > > |
In reply to this post by Colin Putney-3
Have you considered fixing / augmenting the general capabilities of
ToolBuilder with the needs of OB? Seems like needing to know the selection at any time is something that any TextMorph widget should be able to provide! I'm pretty surprised it doesn't already. Are there very many more cases where ToolBuilder falls short? Does your option 4 mean you need to chanse existing base methods? You said, "add" the functionality so maybe you mean only add extensions. If that is the case, I think that's fine. However, if you meant the former, then my concern about option 4 would be that it would pretty much guarantee a continued "dichotomy" between ToolBuilder and OB. I like a lot of OB, but wouldn't be able to use it if I had to abandon the highly-productive windows we have now.. - Chris On Sun, Nov 20, 2011 at 12:37 PM, Colin Putney <[hidden email]> wrote: > On 2011-11-20, at 1:15 AM, Frank Shearar <[hidden email]> wrote: > >> What options are missing from ToolBuilder? Is it just a case of >> missing specs (+ Morphic backing) for some set of widgets? > > No, the widgets all seem to be there. What's missing is configuration > options, and in some cases, capability in the Morphic widgets. > > For example, a bunch of refactorings operate on the current selection > in the text pane. (eg. Extract Method.) Pluggable TextMorphPlus > doesn't give the model any way to find out what the selection is when > the building the context menu, so it can't decide what refactorings > are applicable. > > Colin > > |
On Tue, Nov 22, 2011 at 11:37 AM, Chris Muller <[hidden email]> wrote:
> Have you considered fixing / augmenting the general capabilities of > ToolBuilder with the needs of OB? Yeah, that was my original intention, but I couldn't get it done in time for the 4.3 feature freeze. > Seems like needing to know the selection at any time is something that > any TextMorph widget should be able to provide! I'm pretty surprised > it doesn't already. Agreed. There's a bit of a hack in MenuMorph to get around this problem; look at the senders and implementors of #perform:orSendTo:. I've implemented a better solution in PluggableTextMorphPlus that works pretty well for OmniBrowser's needs. I'll commit to trunk after 4.3 is out. > Are there very many more cases where ToolBuilder falls short? Well, a few: One thing that was just impossible was implementing a good completion dialog. If you choose "find class" in the standard browser, a dialog box comes up that lets you type a class name and shows you possible matches as you type. In the standard browser this is implemented by ListChoose (Morphic-specific). OmniBrowser does something similar for finding classes and several other operations. For a dialog like that to work well, it has to be open ready to receive input and respond instantly, and get out of the way when it's done. ToolBuilder doesn't provide a way to have the search field automatically accept the text every time it changes. There's no way to direct the keyboard focus to the search field when the window opens. There's no way to send all keystrokes in the window to the search field. There's no way to position the window near the hand. Even closing the window when you have an answer is tricky and hackish. ToolBuilder lists don't support icons. Apparently Pharo has a version of ToolBuilder with icon support, so I'm going take a look at harvesting that. There's no way to create a scrolling panel. I need this for browsers with dynamically added columns - eg the chasing browsers. This one I can work around, but I don't know how usable it is. This is more Morphic than ToolBuilder, but right now I'm wrestling with the way SystemWindow insets panes and inserts proportional splitters. It works fine for the stock browsers, but it's tricky to get reasonable behaviour for the generality that OmniBrowser provides. (I'll probably have at least one bug fix for 4.3 here). There are probably a few more that I haven't encountered yet. > Does your option 4 mean you need to chanse existing base methods? You > said, "add" the functionality so maybe you mean only add extensions. > If that is the case, I think that's fine. However, if you meant the > former, then my concern about option 4 would be that it would pretty > much guarantee a continued "dichotomy" between ToolBuilder and OB. I > like a lot of OB, but wouldn't be able to use it if I had to abandon > the highly-productive windows we have now.. Option 4 would involve changing base methods, but wouldn't change the existing behaviour. For example, PluggableTextMorphPlus currently raises an error if you give it a getMenuSelector with more than 2 arguments. My fix to the text selection problem changes the menu logic to allow 3-argument selectors - if you give it one, it'll send you the text selection in the third argument. Shouldn't break anything. In any case, Option 4 would be temporary, since the changes would go into the trunk for inclusion in Squeak 4.4. I definitely don't want to continue the dichotomy; the whole point of using ToolBuilder is to get rid of it. I'm going to see how far I can get with Option 4, but if I have to cheat a bit by tweaking the Morphs directly (Option 1) I will. Colin |
Free forum by Nabble | Edit this page |