Christian,
Just to set straight what we are talking about here: What's been called "Wrapper" in this thread is a combination of several layers of frameworks, and it is misleading to lump them all together. At the lowest level, there is the class library of VisualComponent, VisualPart, View, and Wrapper. It actually has a nice design, and provides the basis for implementing custom Views. See Travis' blog post for where it went astray. The next layer is ApplicationModel, UIBuilder, WindowSpecs, and SpecWrappers. Not too bad, but UIBuilder does too many things at once. Also, the ApplicationModel interface lacks some features, which has been addressed by additional frameworks like Tim Howard's ExtendedApplicationModel or Steven Abell's ValueInterface. The third layer consists of the library of widgets (it does not actually depend on the second layer). Some of the widgets have design flaws or problems in the implementation (think tables, lists, look-and-feel). Christian Haider schrieb am 16.09.2007 08:42: >> toolbar addTool: SearchUI new label: 'Search'. >> >> The toolbar will then go and deal with the rest by itself - >> spacing, positioning, etc, read from a configuration file, >> dictionary - with a UI to allow users to customize it.. you know, >> all the stuff we've been wishing we could do for years in VW. > > I agree very much with this point. But I would not expect something > like this to be in a UI framework per se. But I would expect a good > UI framework to make it easy to create such things (as add-on or > goodie or something). to do. > And I believe that this is exactly the kind of thing which is > virtually impossible to do in the old stuff (i.e. doing it in a > proper way without massive overrides or creating incompatibilities > with client code using it). I disagree. Why overrides? We are talking about Cincom changing the way a toolbar can be accessed and configured. That's a change in the system code, no overrides are needed. Any change creates "incompatibilities", but that's not a problem as long as adapting to a new version of VisualWorks causes work which is in the "normal" range of upgrading efforts. If people use overrides of system methods, they are aware that this incurs the risk of having to revise them for a new version of VisualWorks. Technically, the problem with accessing the menubar and toolbar is that the component of a Window is a ReComposingComposite, which is simply a CompositePart reacting to changes in preferredBounds. For easier access to the menubar and toolbar, this can be replaced by a (not yet existing) kind of Wrapper which knows about its menubar, its toolbar(s) and the contents of the window. It wouldn't be all that difficult to implement, and there is a single method (UILookPolicy>>finalHookupWindow:component:into:) which would have to be changed to use it. And then on to a new Toolbar implementation. I don't see how this would be impossible with the existing frameworks. > P.S. Arnt you lucky that you dont actually have to prove your points > about how easy the old stuff is to improve, since you do SeaSide now > instead? This kind of pointed remarks isn't very helpful IMHO. Joachim |
> -----Ursprüngliche Nachricht-----
> Von: Joachim Geidel [mailto:[hidden email]] > ... > > And I believe that this is exactly the kind of thing which is > > virtually impossible to do in the old stuff (i.e. doing it in a > > proper way without massive overrides or creating incompatibilities > > with client code using it). > I disagree. Why overrides? We are talking about Cincom > changing the way > a toolbar can be accessed and configured. That's a change in > the system > code, no overrides are needed. Any change creates > "incompatibilities", > but that's not a problem as long as adapting to a new version of > VisualWorks causes work which is in the "normal" range of upgrading > efforts. If people use overrides of system methods, they are > aware that > this incurs the risk of having to revise them for a new version of > VisualWorks. No, we misunderstood each other. I meant that such a ToolbarLayouter is quite difficult to do as an add-on of a third party. If Cincom rewrites the code you are right of course. But this means that Cincom has to do some work to allow this, whereas with Widgetry this would IMHO not be necessary. > ... > This kind of pointed remarks isn't very helpful IMHO. Yes, you are right. I apologize. Christian |
In reply to this post by Bruce Badger
I think the relevant distinction is between things in the
contributed directory as opposed to others. Things in the contributed
directory are not Cincom copyrighted (I think that's true of everything)
and have their own licenses. The same is true of a few things in other
directories that come from partners. Widgetry/Pollock has been in the
preview directory previously, where things can be assumed to be under
Cincom license.
Things in those directories under some different license (e.g. Glorp, which is in the preview directory) should make that different license extremely clear. I think that Glorp does so, and I'm not offhand aware of anything else under a different license outside the contributed directory. It would probably be a good idea to make the license for Cincom copyright code that appears in the public repository clearer. Or for code in the public repository in general, but there's relatively little Cincom can do to enforce that. At 11:15 AM 9/13/2007, Bruce Badger wrote: On 13/09/2007, Terry Raymond <[hidden email]> wrote: --
Alan Knight [|], Cincom Smalltalk Development
|
In reply to this post by Joachim Geidel
Well, there's one thing Cincom could do to make it easier to add copyright information to code in Store: Add an additional code tool in the refactoring browser for editing the copyright information attribute which already exists somewhere, IIRC. Add a pane to the "Published Items" tool which shows this information. And add some kind of warning before publishing code without copyright information, and before replicating such code to another repository. The warning should be optional and it should only appear for "foreign" repositories, so it might be a good idea to introduce a distinction between "my own" and "foreign" repositories. And of course, the tools should show warning icons for code without copyright information, similar to code without comments. You might even go so far as adding a predefined list of copyright texts for the most prominent open-source licenses, and let me choose from them !
by selecting from a menu.
Best regards, Joachim Alan Knight schrieb: I think the relevant distinction is between things in the contributed directory as opposed to others. Things in the contributed directory are not Cincom copyrighted (I think that's true of everything) and have their own licenses. The same is true of a few things in other directories that come from partners. Widgetry/Pollock has been in the preview directory previously, where things can be assumed to be under Cincom license. |
Free forum by Nabble | Edit this page |