Long live Widgetry

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Long live Widgetry

Joachim Geidel
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).
Right. And I also think it wouldn't be hard or prohibitively expensive
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

Reply | Threaded
Open this post in threaded view
|

AW: Long live Widgetry

Christian Haider
> -----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

Reply | Threaded
Open this post in threaded view
|

Re: Re :Long live Widgetry

Alan Knight-2
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:
> However, it was also distributed on the Software CD. So,
> the licenses that apply to the CD should also apply to its form
> from the repository.

My PostgreSQL drivers are on the CD too,  and Sport.  Also Glorp is on
there.  Jun, GemStone... etc

Sorry if I came over as a pest.  Really, I just wanted to understand
the situation.

Best regards,
    Bruce
--
Make the most of your skills - with OpenSkills
http://www.openskills.org/

--
Alan Knight [|], Cincom Smalltalk Development
Reply | Threaded
Open this post in threaded view
|

Re: Long live Widgetry

Joachim Geidel
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.

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 pu! blic repository clearer. Or for code in the public repository in gener al, 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:
> However, it was also distributed on the Software CD. So,
> the licenses that apply to the CD should also apply to its form
> from the repository.

My PostgreSQL drivers are on the CD too,  and Sport.  Also Glorp is on
there.  Jun, GemStone... etc

Sorry if I came over as a pest.  Really, I just wanted to understand
the situation.

Best regards,
    Bruce
--
Make the most of your skills - with OpenSkills
http://www.openskills.org/

--
Alan Knight [|], Cincom Smalltalk Development
[hidden email]
123