Long live Widgetry
Locked
123
123
 
|
First of all I have a deep respect for what you do for us and the community and I certainly am happy not to have your mail box these days. However you are the product manager so you are paid to assume: James Robertson a écrit : You should have put Michael and Travis imediately on the job of finalising Widgetry and start them to build the associated tools. Why didn't you ???? You said earlier: << However, it does not mean that there will be no improvements. In the next release (scheduled for January, 2008), improvements to existing tools (the Refactoring Browser in particular) will appear. Incremental improvements to the UI will start to appear after that, including: >> This would mean Spring 2009 and Winter 2009/2010 for our potential customers. For me that does not sound <<fairely quickly>> As a professional you should know that building new things with new tools is a whole lot easier then trying to maintain evolutions of the past. The IT industry is loaded with such examples. Look at autodesk they made huge efforts to transform AutoCad into parametric 3DCAD tool but ended up with a full rewrite tocatch-up with industrie. That may be true for the NetClient if this is well done and it is certainly true for Widgetry. However I simply don't believe you for Wrapper which is loaded with hacks & flags. Notice that Smalltalk's top technologies like Seaside and Glorp all started from scratch.
As
to Widgetry, we do not plan to open source it. However, it will stay
in the Public Store repository, and you (or any customer) is free to
use it on an 'as is' basis.
You have created a dangerous Monster now you have to assume it as such and be aware that it is going to bite back. ==========//=============== From my point of view what most likely happended is that your top 10 clients informed you that they would not take the effort of migrating to a new GUI builder interface in the first place. You probably have as much pain in the hart as we have but you are obliged to reply politically correct. Regards and thanks again and again Sames for creating this. @+Maarten, |
|
|
Didn't Vassili have a prototype UI builder for Widgetry? If possible this
should be made available. Perhaps it could be finished as a community project. -Carl Gundel http://www.libertybasic.com |
Re: AW: Re :Long live Widgetry
|
|
In reply to this post by Christian Haider
Just notice that Michael Lucas Smith indicated this hack as a very positive "Wrapper Experience" or even better: "I've never gotten as much positive feedback for a tool in my whole life" As copied from his blog: <<Recently, I had a very positive "Wrapper" experience - by god I hate that name, it's a wonderful piece of propaganda - you can hear the clumsy music playing in the background every time you say it, "Uh duh, wrapper, let's, uh, wrap things." At Travis's suggestion, I stopped using the UI Builder and specs and actually made a subclass of VisualPart and just -wrote- a widget. The result of this venture? SmallSpotlight. I can save without a doubt that I've never gotten as much positive feedback for a tool in my whole life as I have for SmallSpotlight! >>>Are this the examples of the bright future ? Do I understand well that in order to do cool things the UI builder has to be dumped anyway ? @+Maarten, |
|
|
In reply to this post by Maarten Mostert-2
"James Robertson a écrit :
The need for customers to make a significant change to their code was a major issue, yes. It was not the only one though. Widgetry was under development for 6 years before any effort was made to build tools or applications in it. This was a large mistake on our part, and one that won't be made again. You should have put Michael and Travis imediately on the job of finalising Widgetry and start them to build the associated tools. Why didn't you ????" ------------------------
We did do that. A large part of this decision stems from the unhappy
results of that. We took that path, and we were distinctly unhappy with
how it was looking. Ultimately, in my role as Product Manager, I had to
ask a simple question:
"If our internal people are having this much trouble dealing with Widgetry,
how are customers going to
deal with it?" This does not imply that Wrapper is some shining city on a hill, or that
Widgetry is a disaster. Here's the rub: In order to ask customers to
migrate from Wrapper to Widgetry, Widgetry would have to be dramatically better
than Wrapper. At the end of the day, we couldn't say that it was. It
was an improvement in many areas, but it also has problems, and simply didn't
"move the ball forward" enough to ask people to move to it.
As to the schedule of improvements, we truly aren't looking at years, or
even months. In the case of some widget improvements, we are likely
looking at weeks, and I expect that work to make it to the January
release.
As to this: "As a professional you should know that building new things with new tools
is a whole lot easier then trying to maintain evolutions of the past. The
IT industry is loaded with such examples. Look at autodesk they made huge
efforts to transform AutoCad into parametric 3DCAD tool but ended up with a full
rewrite tocatch-up with industrie"
I disagree, and a lot of what's wrong with the IT industry is the idea that
pitching working code and starting over is always the right answer.
Sometimes, a full rewrite is the correct answer - I just don't think now is one
of those times.
As to the theory that I am being forced to craft "politically correct" responses: not so much. I sometimes ask colleagues whether they think my wording on a response conveys the right message, but I usually just answer as I am now - straight up and without any "political" considerations. As to customer responses on Widgetry, the positive messages that I have received on this have all come after the fact, not before. This decision was made on internal considerations, not due to outside people pushing us.
|
Re: AW: Re :Long live Widgetry
|
|
In reply to this post by Maarten Mostert-2
>> That's already done in the RB toolbar search field. As you mention, >> achieving things like this at the moment is a hack, but at least >> you'd be copying Cincom's own (presumably well-informed and >> supported) hack. >> >> Like you, i did look into that of course. The find widget is >> implemented entirely on the application level and there is no attempt >> to do anything about it on the framework level. >> Have you seen the method RefactoringBrowser>>addFind ? The comment reads: >> "This isn't a pretty method, but I want an input field in the toolbar." >> And what a beauty it is! All the navigation to get to the right >> pieces - couldnt be more brittle. And, of course, a generic error >> handler around all of it :-) >> > Just notice that Michael Lucas Smith indicated this hack as a very > positive "Wrapper Experience" dreadful hack, horrible code. It's nice that it can be done that way, but the APIs to do it and the code produced are really yuck. I added a search field to the menu bar of a Widgetry widget for an internal project though and I have to say the code to do that wasn't much better. Michael |
AW: AW: Re :Long live Widgetry
|
|
In reply to this post by James Robertson-7
Please show it (the Widgetry code), maybe we can help you :-)
Christian -----Ursprüngliche Nachricht----- Von: Michael Lucas-Smith [mailto:[hidden email]] Gesendet: Freitag, 14. September 2007 17:01 An: [hidden email] Cc: Christian Haider; Steven Kelly; VW NC Betreff: Re: AW: Re :Long live Widgetry >> That's already done in the RB toolbar search field. As you mention, >> achieving things like this at the moment is a hack, but at least >> you'd be copying Cincom's own (presumably well-informed and >> supported) hack. >> >> Like you, i did look into that of course. The find widget is >> implemented entirely on the application level and there is no attempt >> to do anything about it on the framework level. >> Have you seen the method RefactoringBrowser>>addFind ? The comment reads: >> "This isn't a pretty method, but I want an input field in the toolbar." >> And what a beauty it is! All the navigation to get to the right >> pieces - couldnt be more brittle. And, of course, a generic error >> handler around all of it :-) >> > Just notice that Michael Lucas Smith indicated this hack as a very > positive "Wrapper Experience" dreadful hack, horrible code. It's nice that it can be done that way, but the APIs to do it and the code produced are really yuck. I added a search field to the menu bar of a Widgetry widget for an internal project though and I have to say the code to do that wasn't much better. Michael |
|
|
In reply to this post by James Robertson-7
I think we're
talking about two different things. I mean the Find field that has been in
the RB toolbar since 5i.4 / 2001. Michael was talking about SmallSpotlight, which is in the public
repository and made in the last month or so.
Still, we do need a
rewrite of the toolbar. That's not too bad, since the current toolbar is only a
menu anyway from the developer's point of view. It would be relatively easy,
given a new Toolbar View that can contain any widget, can lay them out
sequentially - possibly over several lines, and can float over or sidle around
the edge of the window, to add the backwards compatibility to read an old menu
as a source of what widgets to include. Note that the key thing here is not that
this would be any easier or harder for Cincom to do than in Widgetry, but that
it would generally be zero effort for customers to move old code to use the
new toolbar in Wrapper.
The same goes for
Wrapper Menus: there's not so much wrong with the public interface for using
menus, it's the code in Menu Views and Controllers that has accreted too much
slag in its attempt to solve bugs and mimic different platforms'
behaviour.
So I put it to
Cincom again: how hard would it be to build a "translator" that would take an
existing ApplicationModel with windowSpec, postBuildWith: etc., and open a
Widgetry window with equivalent contents? Or is there some reason why Widgetry,
if it were backwards compatible and had a GUI Builder, would be less good as a
basis for further enhancements than Wrapper? You'll have to rewrite significant
pieces of Wrapper anyway, and the GUI Builder is one of
them...
Steve
|
Re: AW: AW: Re :Long live Widgetry
|
|
In reply to this post by Christian Haider
Christian Haider wrote:
> Please show it (the Widgetry code), maybe we can help you :-) > The basic code is this: find where we want to put our new stuff instantiate a ui with a builder add it to the ui position it the addFind code is messy, but if we break it down: find where we want to put our new stuff - 3 lines + a weird guard clause instantiate a ui with a builder - 4 lines add it to the ui - 2 line position it - 14 lines the widgetry code in question adds a search field to an application, the basic code is: "instantiate a ui with a builder" | searchUI searchForm | (searchUI := SearchUI new) id: #search. searchForm := Form new. searchForm addComponentsFromInterface: searchUI. self addTabOrderPane: (self mainWindow paneAt: #search). self actions add: (Action id: #search receiver: self selector: #search). self keymap map: (Keystroke ctrl: #F) to: #search. "add it to the ui" self addComponent: searchForm. "position it - not we're cheating here, because we're not measuring the height of the menu to position it correctly - this is also not the same as the addFind example, which adds it to the toolbar which can hide/show" searchForm frame: (FractionalFrame leftFraction: 1 offset: -300 rightFraction: 1 offset: 0 topFraction: -27 offset: 0 bottomFraction: 0 offset: 20) So we can break the widgetry version down too: the addFind code is messy, but if we break it down: find where we want to put our new stuff - none, we're putting it in the menubar, not the toolbar instantiate a ui with a builder - 6 lines add it to the ui - 1 line position it - 10 lines With refactoring, my widgetry code was much simpler - but the same goes for the wrapper code. I have no idea why that RB #addFind method was never refactored and made.. normal like regular smalltalk code. The point is that the two methods are very equivalent when you break them down and the number of lines to say the same thing is roughly the same. The methods called are almost equivalent too. Ideally, a UI would be more like this: | searchUI | searchUI := SearchUI new. self add: searchUI. self keymap add: (Keystroke ctrl: $F) do: [self search]. searchUI desiredPreferredBounds: [:area | (area width - 300 @ 0) corner: (area width @ 20)] ... four lines. Michael |
|
|
In reply to this post by James Robertson-7
OK, James already answered my question in his post that
crossed with mine in the
mail:
That then was perhaps the
big mistake: not getting people to use Widgetry early on. For all the talk
about this being an XP project, the customer was not involved for six years.
External customers couldn't be forced, maybe, but dogfooding should have been
started sooner. If that had happened, it would also have been a brake on some of
the changes that appeared ridiculous to me - e.g. changing the whole namespace
and important APIs at late dates. That kind of lack of apparent stability was
certainly not encouraging people to jump in and start using Widgetry
yet.
Those are just my musings
as an outsider, and based on the declared premise that Widgetry would be a
public demonstration of some flavour of agile development, and indeed form an
experience that we can all learn from. If others more closely involved can
provide more info and opinions (without anger or blameseeking), that would be
useful as a project retrospective.
Steve
|
AW: AW: AW: Re :Long live Widgetry
|
|
In reply to this post by James Robertson-7
To me the Widgetry code looks rather straight forward to me (I do have a couple of different idioms reducing the number of lines, but otherwise it looks just fine).
I also agree partly with your analysis (basically the same approach and basically the same amount of code), except that the old code is extremely brittle and depends very much on the shape of the visual hierarchy (the find-where-to-put-stuff part): components := self builder window component components. components size = 3 ifFalse: [^self]. ((toolbar := (components at: 2) component) isKindOf: ToolBar) ifFalse: [^self]. Leaves the issue of the generic error handler around all of it... So, where is/was the problem with Widgetry then? Cheers, Christian -----Ursprüngliche Nachricht----- Von: Michael Lucas-Smith [mailto:[hidden email]] Gesendet: Freitag, 14. September 2007 17:30 An: Christian Haider Cc: VW NC Betreff: Re: AW: AW: Re :Long live Widgetry Christian Haider wrote: > Please show it (the Widgetry code), maybe we can help you :-) > The basic code is this: find where we want to put our new stuff instantiate a ui with a builder add it to the ui position it the addFind code is messy, but if we break it down: find where we want to put our new stuff - 3 lines + a weird guard clause instantiate a ui with a builder - 4 lines add it to the ui - 2 line position it - 14 lines the widgetry code in question adds a search field to an application, the basic code is: "instantiate a ui with a builder" | searchUI searchForm | (searchUI := SearchUI new) id: #search. searchForm := Form new. searchForm addComponentsFromInterface: searchUI. self addTabOrderPane: (self mainWindow paneAt: #search). self actions add: (Action id: #search receiver: self selector: #search). self keymap map: (Keystroke ctrl: #F) to: #search. "add it to the ui" self addComponent: searchForm. "position it - not we're cheating here, because we're not measuring the height of the menu to position it correctly - this is also not the same as the addFind example, which adds it to the toolbar which can hide/show" searchForm frame: (FractionalFrame leftFraction: 1 offset: -300 rightFraction: 1 offset: 0 topFraction: -27 offset: 0 bottomFraction: 0 offset: 20) So we can break the widgetry version down too: the addFind code is messy, but if we break it down: find where we want to put our new stuff - none, we're putting it in the menubar, not the toolbar instantiate a ui with a builder - 6 lines add it to the ui - 1 line position it - 10 lines With refactoring, my widgetry code was much simpler - but the same goes for the wrapper code. I have no idea why that RB #addFind method was never refactored and made.. normal like regular smalltalk code. The point is that the two methods are very equivalent when you break them down and the number of lines to say the same thing is roughly the same. The methods called are almost equivalent too. Ideally, a UI would be more like this: | searchUI | searchUI := SearchUI new. self add: searchUI. self keymap add: (Keystroke ctrl: $F) do: [self search]. searchUI desiredPreferredBounds: [:area | (area width - 300 @ 0) corner: (area width @ 20)] ... four lines. Michael |
|
|
In reply to this post by James Robertson-7
How do you explain that the few of us who had the time to take the experience before 9/11 all seem to agree that Widgetry comes natural and is a major improvement. All the ones who agreed with you seem to have never tried ! I know that this was not so polite to ask and I actually didn't expect you to reply. If there really are only local technical/financial reasons why didn't you push it out with the messsage that you were seriously doubting wheter Widgetry was up to expectation giving us "the community" 2 month's to make up their mind and to reply to that. We are now all sad and divided between those who did the experience and got hooked and those who didn't. This has costs you a huge amount of money uptil now without talking the impact and side effects to CincomsSmalltalk image (Adn ours to). Why would'nt you give it a second chance. As I sad earlier only idiots never change their minds. @+Maarten, |
|
|
>> "If our internal people are having this much trouble dealing with
>> Widgetry, how are customers going to >> deal with it?" > How do you explain that the few of us who had the time to take the > experience before 9/11 all seem to agree that Widgetry comes natural and > is a major improvement. > > All the ones who agreed with you seem to have never tried ! My experience with Widgetry has been very positive in terms of its programmability. I really like the model. -Carl Gundel, author of Liberty BASIC http://www.libertybasic.com |
Re: AW: AW: AW: Re :Long live Widgetry
|
|
In reply to this post by Christian Haider
Christian Haider wrote:
> To me the Widgetry code looks rather straight forward to me (I do have a couple of different idioms reducing the number of lines, but otherwise it looks just fine). > > I also agree partly with your analysis (basically the same approach and basically the same amount of code), except that the old code is extremely brittle and depends very much on the shape of the visual hierarchy (the find-where-to-put-stuff part): > > components := self builder window component components. > components size = 3 ifFalse: [^self]. > ((toolbar := (components at: 2) component) isKindOf: ToolBar) ifFalse: [^self]. > > Leaves the issue of the generic error handler around all of it... > > So, where is/was the problem with Widgetry then? > code - the one in addFind and the stuff I did for an internal project, were similar - I did not state that Widgetry had a problem wrt to this code. The fact that the code is so similar - better naming - really does suggest that updating Wrapper isn't a big deal. Knowing what to change and why is the key. Widgetry's big advantage was - from an API point of view - better message naming (in general) and more direct APIs for twiddling things (eg: myCheckbox textBackground: ColorValue pink). When we get in to the guts of it - sticking a find field on the toolbar should look nothing like any of the three examples I gave. Toolbars should be more configurable, controllable by the user, etc.. so we'd actually want to do something like this: 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. Wrapper doesn't have it, Widgetry doesn't have it. Both Wrapper and Widgetry have roughly the same design for menus and toolbars - so naturally the work to do it in either framework is going to be about the same... which brings us back to the very arguments James has been making. Michael > Cheers, > Christian > > -----Ursprüngliche Nachricht----- > Von: Michael Lucas-Smith [mailto:[hidden email]] > Gesendet: Freitag, 14. September 2007 17:30 > An: Christian Haider > Cc: VW NC > Betreff: Re: AW: AW: Re :Long live Widgetry > > Christian Haider wrote: > >> Please show it (the Widgetry code), maybe we can help you :-) >> >> > The basic code is this: > > find where we want to put our new stuff > instantiate a ui with a builder > add it to the ui > position it > > the addFind code is messy, but if we break it down: > find where we want to put our new stuff - 3 lines + a weird guard clause > instantiate a ui with a builder - 4 lines > add it to the ui - 2 line > position it - 14 lines > > the widgetry code in question adds a search field to an application, the > basic code is: > > "instantiate a ui with a builder" > | searchUI searchForm | > (searchUI := SearchUI new) id: #search. > searchForm := Form new. > searchForm addComponentsFromInterface: searchUI. > self addTabOrderPane: (self mainWindow paneAt: #search). > self actions add: (Action id: #search receiver: self selector: #search). > self keymap map: (Keystroke ctrl: #F) to: #search. > > "add it to the ui" > self addComponent: searchForm. > > "position it - not we're cheating here, because we're not measuring the > height of the menu to position it correctly - this is also not the same > as the addFind example, which adds it to the toolbar which can hide/show" > searchForm frame: > (FractionalFrame > leftFraction: 1 > offset: -300 > rightFraction: 1 > offset: 0 > topFraction: -27 > offset: 0 > bottomFraction: 0 > offset: 20) > > So we can break the widgetry version down too: > the addFind code is messy, but if we break it down: > find where we want to put our new stuff - none, we're putting it in the > menubar, not the toolbar > instantiate a ui with a builder - 6 lines > add it to the ui - 1 line > position it - 10 lines > > With refactoring, my widgetry code was much simpler - but the same goes > for the wrapper code. I have no idea why that RB #addFind method was > never refactored and made.. normal like regular smalltalk code. The > point is that the two methods are very equivalent when you break them > down and the number of lines to say the same thing is roughly the same. > The methods called are almost equivalent too. > > Ideally, a UI would be more like this: > > | searchUI | > searchUI := SearchUI new. > self add: searchUI. > self keymap add: (Keystroke ctrl: $F) do: [self search]. > searchUI desiredPreferredBounds: [:area | (area width - 300 @ 0) corner: > (area width @ 20)] > > ... four lines. > > Michael > > > > > > |
|
|
In reply to this post by James Robertson-7
--- James Robertson <[hidden email]> wrote: > "James Robertson a écrit : > The need for customers to make a significant change to their code was > a major issue, yes. > It was not the only one though. Widgetry was under development for 6 > years before any effort was made to > build tools or applications in it. This was a large mistake on our > part, and one that won't be made again. > > > > > You should have put Michael and Travis imediately on the job of > finalising Widgetry and start them to > build the associated tools. Why didn't you ????" > > > > ------------------------ > > We did do that. A large part of this decision stems from the unhappy > results of that. We took that path, and we were distinctly unhappy > with how it was looking. Ultimately, in my role as Product Manager, > I had to ask a simple question: > > "If our internal people are having this much trouble dealing with > Widgetry, how are customers going to > deal with it?" > > This does not imply that Wrapper is some shining city on a hill, or > that Widgetry is a disaster. Here's the rub: In order to ask > customers to migrate from Wrapper to Widgetry, Widgetry would have to > be dramatically better than Wrapper. At the end of the day, we > couldn't say that it was. It was an improvement in many areas, but > it also has problems, and simply didn't "move the ball forward" > enough to ask people to move to it. > > As to the schedule of improvements, we truly aren't looking at years, > or even months. In the case of some widget improvements, we are > likely looking at weeks, and I expect that work to make it to the > January release. The understandable message in the first announcement is this: "When we began looking at migrating our own tools forwards, it became clear that we would have had to commit a large percentage of the total development effort to this task alone, sacrificing numerous other areas that are also important to our customers." Every time you say things like "We have come to the conclusion that the leap to Widgetry is simply too large for most of our customers, and have decided not to make it" and "The need for customers to make a significant change to their code was a major issue in the decision to cancel Widgetry" /you invite/ your customers to disagree, and tell you how much they like widgetry and explain why widgetry is better than wrappers - you have moved away from the understandable "development effort" message. Every time you say things like "As to the schedule of improvements, we truly aren't looking at years, or even months." and "The difference between what would have happened with Widgetry and what is happening now is the difference between revolutionary change and evolutionary change." /you invite/ your customers disbelief because you avoid saying the only thing that can make these statements sensible - you are planning to make far fewer UI "improvements" than Widgetry envisioned, you are slashing scope in line with the understandable "development effort" message. Widgetry really would have to be wonderfully amazing to justify committing "a large percentage of the total development effort to this task alone". ____________________________________________________________________________________ Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ |
|
|
I agree with you, and you have made what I said clearer. All I can add is:
"what he said". ----- Original Message ----- From: "Isaac Gouy" <[hidden email]> To: "James Robertson" <[hidden email]>; <[hidden email]> Sent: Friday, September 14, 2007 2:30 PM Subject: [!! SPAM] Re: Re :Long live Widgetry > > --- James Robertson <[hidden email]> wrote: > >> "James Robertson a écrit : >> The need for customers to make a significant change to their code was >> a major issue, yes. >> It was not the only one though. Widgetry was under development for 6 >> years before any effort was made to >> build tools or applications in it. This was a large mistake on our >> part, and one that won't be made again. >> >> >> >> >> You should have put Michael and Travis imediately on the job of >> finalising Widgetry and start them to >> build the associated tools. Why didn't you ????" >> >> >> >> ------------------------ >> >> We did do that. A large part of this decision stems from the unhappy >> results of that. We took that path, and we were distinctly unhappy >> with how it was looking. Ultimately, in my role as Product Manager, >> I had to ask a simple question: >> >> "If our internal people are having this much trouble dealing with >> Widgetry, how are customers going to >> deal with it?" >> >> This does not imply that Wrapper is some shining city on a hill, or >> that Widgetry is a disaster. Here's the rub: In order to ask >> customers to migrate from Wrapper to Widgetry, Widgetry would have to >> be dramatically better than Wrapper. At the end of the day, we >> couldn't say that it was. It was an improvement in many areas, but >> it also has problems, and simply didn't "move the ball forward" >> enough to ask people to move to it. >> >> As to the schedule of improvements, we truly aren't looking at years, >> or even months. In the case of some widget improvements, we are >> likely looking at weeks, and I expect that work to make it to the >> January release. > > > > The understandable message in the first announcement is this: > > "When we began looking at migrating our own tools forwards, it became > clear that we would have had to commit a large percentage of the total > development effort to this task alone, sacrificing numerous other areas > that are also important to our customers." > > > > Every time you say things like > > "We have come to the conclusion that the leap to Widgetry is simply too > large for most of our customers, and have decided not to make it" > > and > > "The need for customers to make a significant change to their code was > a major issue in the decision to cancel Widgetry" > > /you invite/ your customers to disagree, and tell you how much they > like widgetry and explain why widgetry is better than wrappers - you > have moved away from the understandable "development effort" message. > > > > Every time you say things like > > "As to the schedule of improvements, we truly aren't looking at years, > or even months." > > and > > "The difference between what would have happened with Widgetry and what > is happening now is the difference between revolutionary change and > evolutionary change." > > /you invite/ your customers disbelief because you avoid saying the only > thing that can make these statements sensible - you are planning to > make far fewer UI "improvements" than Widgetry envisioned, you are > slashing scope in line with the understandable "development effort" > message. > > > > Widgetry really would have to be wonderfully amazing to justify > committing "a large percentage of the total development effort to this > task alone". > > > > ____________________________________________________________________________________ > Pinpoint customers who are looking for what you sell. > http://searchmarketing.yahoo.com/ > |
Re: AW: AW: AW: Re :Long live Widgetry
|
|
In reply to this post by Michael Lucas-Smith-2
So I just went to Travis Blog and found this:
"To this day, I'll use the builder based tools only for a short time, before I discover "screw it, it won't do the dynamic thing I want to do." Then I just step around it and make/manage my own visual parts. But others haven't had that exposure, and we've done a terrible job of hiding that knowledge and not documenting that as the primary way to learn about the widget system. I don't believe you'll find a fundamental discussion of how the view tree works anywhere in our docs, and what objects play what roles." To comments on this paragraph: 1) As I concluded earlier you indicate that one of the hottest thing about the upcoming Wrapper version is the fact that you are going to document the way how to dump the GUI builder to do cool things. I might sound sarcastic here but actually I am not. I more and more convinced that the only way out for Wrapper actually is to dump the GUI tool. 2) I can tell you something about the undocumented TreeViews: If I do TreeViews from Wrapper out of a Glorp query I am obliged to convert my root Object in a kindof AssociationTreeWithParent in order for the TreeView class to understand what are the parent child relations ships. As my treeViews happen to present big organisations and building structures of Cruise Ships they tent to be quite big. When initializing the TreeView it will fire thousends of queries around the link tables to know who is what and where. :-( If I do the same thing in Widgetry, I can point to a glorp object directly as it doesn't have this requirments to carry this complicated superstructure. All the requirement for Widgetry TreeView is the fact that the tree must know the children's accessor (and this can be any kind of object). When I connect to a database it will this time not load the entire building structure of all the projects and the organisation, it will just query what is actually unfolded. I think that is just very smart :-) @+Maarten, |
Re: AW: AW: AW: Re :Long live Widgetry
|
|
By "View Tree", Travis meant the hierarchy of objects from VisualPart down
through View (underneath there are less abstract and concrete View subclasses). The tree widget is another subject entirely. ----- Original Message ----- From: "Maarten Mostert" <[hidden email]> To: <[hidden email]> Cc: "VW NC" <[hidden email]> Sent: Friday, September 14, 2007 4:45 PM Subject: Re: AW: AW: AW: Re :Long live Widgetry > So I just went to Travis Blog and found this: > > "To this day, I'll use the builder based tools only for a short time, > before I discover "screw it, it won't do the dynamic thing I want to > do." Then I just step around it and make/manage my own visual parts. But > others haven't had that exposure, and we've done a terrible job of > hiding that knowledge and not documenting that as the primary way to > learn about the widget system. I don't believe you'll find a fundamental > discussion of how the view tree works anywhere in our docs, and what > objects play what roles." > > To comments on this paragraph: > > 1) As I concluded earlier you indicate that one of the hottest thing > about the upcoming Wrapper version is the fact that you are going to > document the way how to dump the GUI builder to do cool things. I might > sound sarcastic here but actually I am not. I more and more convinced > that the only way out for Wrapper actually is to dump the GUI tool. > > 2) I can tell you something about the undocumented TreeViews: > > If I do TreeViews from Wrapper out of a Glorp query I am obliged to > convert my root Object in a kindof AssociationTreeWithParent in order > for the TreeView class to understand what are the parent child relations > ships. As my treeViews happen to present big organisations and building > structures of Cruise Ships they tent to be quite big. When initializing > the TreeView it will fire thousends of queries around the link tables to > know who is what and where. :-( > > If I do the same thing in Widgetry, I can point to a glorp object > directly as it doesn't have this requirments to carry this complicated > superstructure. All the requirement for Widgetry TreeView is the fact > that the tree must know the children's accessor (and this can be any > kind of object). When I connect to a database it will this time not load > the entire building structure of all the projects and the organisation, > it will just query what is actually unfolded. > I think that is just very smart :-) > > @+Maarten, > > > |
Re: AW: AW: AW: Re :Long live HackerTalk
|
|
Your lead developper seem to get a kick out of this but personnaly I don't. If you go to their blogs there pages and pages of HackerTalk all the way around. What where the flag settings again for having a scrollbar in a dropdown widget of a tableView cell. It hink it is 1 is for a left scrollbar 2 is for a bottom scrollbar and 3 for both. You probably remember better then me beacause I am a Smalltalker not a HackerTalker. Notice that you cincom smalltalk never ever used the GUI builder in your own interface design. All the way through the message is clear. Todays GUI requirements ( and user expections towards them) can no longer be fullfilled by graphical design except for their most basic forms. In France we have a proverb for this "Stop painting our pair of glasses". The fact is that exception made for your HackerTalkers not a single developper who tried Widgetry came back stating it is not wordth the change. @+Maarten, James Robertson a écrit : By "View Tree", Travis meant the hierarchy of objects from VisualPart down through View (underneath there are less abstract and concrete View subclasses). The tree widget is another subject entirely. |
Re: AW: AW: AW: Re :Long live Widgetry [Examples]
|
|
In reply to this post by Michael Lucas-Smith-2
Michael Lucas-Smith a écrit :
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. Wrapper doesn't have it, Widgetry doesn't have it. Both Wrapper and Widgetry have roughly the same design for menus and toolbars - so naturally the work to do it in either framework is going to be about the same... which brings us back to the very arguments James has been making.Lets show some examples here: Wrapper: The standard 16 pixel window icons are becoming somewhere outdated nowadays so my goal was to be in accordance with FireFox 32 pixel height. No problem Wrappers toolbar adjust nicely to my freshly acquired 32 icons.  The problem is that my toolbar is much higher then expected. Wrappers add some useless pixel around my icons to give them a non -standard look. I can offcourse scale down my my icons but then I loose graphics quality. Except if you are HackerTalker you are now blocked. Widgetry: In Widgtery things are different, you don't have to be an expert to find out that the tool bar height is defined in the WinXP ToolBarArtist class. You just subclass this with something like toolbarHeight "used to be ^30" ^37 and off you go:  As you can see my toolbar hieght is know identical to the Firefox toolbar height. This certainly is way to easy for a HackerTalker but for me as a Smalltalker this is simple and easy to understand. @+Maarten, |
AW: AW: AW: AW: Re :Long live Widgetry
|
|
In reply to this post by James Robertson-7
> Von: Michael Lucas-Smith [mailto:[hidden email]]
... > so we'd > actually want to do something like this: > > 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). I believe that Widgetry was especially designed to make this easy. And I believe that this has been achieved very nicely. 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). > Wrapper doesn't have it, > Widgetry > doesn't have it. Both Wrapper and Widgetry have roughly the > same design > for menus and toolbars - so naturally the work to do it in either > framework is going to be about the same... which brings us > back to the > very arguments James has been making. See above. I strongly disagree with this judgement! And BTW, maybe you should forget about lines of code as a quality measure for OO code. Even not perfect, but a bit better is to count statements. This would give you quite different numbers for your comparisons... Cheers, Christian 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? |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |