Long live all VW apps
Locked
 
|
From: Maarten Mostert
[mailto:[hidden email]]
The fact is that except... for your HackerTalkers not a single developer who tried Widgetry came back stating it is not worth the change. Whether something is "worth the change" depends on more than just "is Widgetry better than Wrapper". Until there is an automated conversion or interpretation of Wrapper windowSpecs and ApplicationModels to make them work in Widgetry, I don't even need to try Widgetry to tell you it's not going to be worth it for me to migrate. Our application has been built in VisualWorks since 1992, with something between 50 and 100 man-years of effort. It doesn't take much maths to show that even to just move with a "word by word" translation to Widgetry would take rather a long time, and give very little real benefit instantly (update speed is not much different, maybe some less flickering). To take advantage of any new features Widgetry offers would take even longer, and still not significantly enhance our application from the point of view of its users. Our users definitely don't buy our product just to look at whether the emulation of a button is pixel perfect, but to use our features. We'd be much better off spending our time on those features than on a massive GUI migration project to stand still. For the remainder of this message, I'll
assume that Widgetry is significantly better than Wrapper - mostly the
important thing is that it is internally better, lacking the crusty
agglomeration of hacks that Wrapper has become in many places.
Put simply, the less existing investment in
VW that people had, the more likely they were to invest in building apps with
Widgetry. But generally speaking, the people who actually pay Cincom are the
ones who already have a significant investment in VW. By not providing a clear,
low-effort, low-risk migration path to Widgetry, Cincom ruled out that migration
for most people who pay its bills.
So we have three groups that are
interesting:
1) Cincom
2) long term customers who pay Cincom's
bills and have large amounts of Wrapper GUI but no Widgetry experience,
3) new customers who pay Cincom little yet,
may not have used Wrapper much and have invested in using Widgetry
Group 2 would be happy for Wrapper to
continue and be improved, yet recognise that at some point it would be great to
have a new GUI framework. They're used to having a graphical GUI builder for
one-off UIs, but also build GUIs programmatically when necessary. They've put up
with an awful lot of trouble from Widgetry over the last 6 years, since it has
stopped sorely needed work on their existing GUIs, and has stretched its
deadline to four times what was promised. Group 2 are those that would directly
benefit the most from the promised automated conversion, yet neither they nor
group 3 are really expert enough in both sides of the conversion to build it.
Group 3 would be happy for Wrapper to be
killed right now, preferably with a stake through its heart (thank you Maarten
for making that vehemence clear! :-> ). They have no direct desire for
conversion, or for a graphical GUI builder (since they have been prepared to
build everything by code, they are probably in the 20% of the populace that
prefers text to visual). Indeed, they may even oppose work on those areas, as
they would divert resources from other improvements to Widgetry.
That leaves us with Cincom. They have the
experience on both sides of the conversion. They can't afford to support two
frameworks in the long run. They thus have to guess whether group 2 is going to
continue providing income in the long term with Wrapper-based applications, or
group 3 is going to grow and provide a similar amount of income with its
Widgetry-based applications. My guess is that group 2 splits into 2a, whose apps
are not actively pushed forward and will not update to Widgetry under any
circumstances, and 2b, whose apps are actively developed and would be updated
(grudgingly!) given a sufficiently good automated conversion. Long term, 2b will
tend to provide income and 2a will tend to die out - regardless of our choices
here.
For Widgetry to survive it must become the
single GUI framework in VW, in about the same timeframe as VW replaced
ObjectWorks, or events replaced polling. For that to happen, groups 2b and 3
both need to push Cincom to provide automatic conversion.
Effectively, Cincom have built a new
"house" whilst allowing the old house to fall into disrepair: unless the new
house is seriously flawed, it doesn't make sense to abandon the new house and
start patching up the old house, just because we suddenly notice we haven't yet
hired a removal van to help us move house.
Cheers,
Steve |
|
|
There are three main things which upsets me most: 1) They could have guessed this to happen 3 years ago but never said anything (You call that what you want but I call that mismanagement, there is no place here for unlucky). 2) They you and me end up having to work with solutions which are way below the capacities of the language and the environment (As Sam now showed us what the language can offer this is much harder to swallow) and most of all this cannot be a long term solution for you and me to make money. 3) You the existing user base with milions of investements have been informed about this change for 6 six years. Now it finally came you tell the world that in fact you don't want a change (You could and should have explained that 6 years before). First of all I think that the fact that Cincom has limited resources is only relative (They are part of a big money making group) (In big groups it is not the results that count but the presentation of the result, which is often very different). Then of course there are a couple of "easy" things they could have done. 1) Create a oneway only canvas to script translator, doing everything but embedded specs (I know we do that all the time but still). 2) Update Wrappers bitmaps with those of Widgetry in a way that both type of applications show more consistant within the same image (Actually this is so easy that I am sure that this are the only improvements we will see "in weeks" as James stated. The remaining comments are incrusted. Steven Kelly a écrit : I can very well understand that and it is true. However we have heard that infinite times during the DOS to Windows conversion. And the outcome was very bad for the late comers. Have a look ate the other line news: c.l.smalltalk Eliots remarks speak ages. That is bloody true but this has everything to do with management priorities marketing and resource attributions. A like to add a little footnote here: I recently heard 3 podcasts over version control and retained only 3 points: - George Heeg provided a wishlist for Store which woke up cincoms management. - Store and especially the public store is slow because it is running on a 12 year old machine (pentium 2 or something). - Store pops up with dialogs to request which version to choose which sometimes confuses users. Between you and me is it really worth it that they took Sam of of Widgetry to do Store ? Actually that is not entirely true. I have about 3.5 megs of source code hanging behind Wrapper and won't be able to convert all that within a small time frame. For the moment I only did a part of my main application and hardly any of the subdialogs and wizards. That is actually true. I never really liked it in ObjectWorks but in Widgetry it is really fun. Before doing any major work on a new GUI builder they should do a serious plan of how they are going to support hardware accelerated graphics. This is going to be very risky and tricky you cannot do that with the Ad-Hoc type of management decisions we see now. I think it was is and remains all in Sams hand. Lets pray. @+Maarten, |
|
|
In reply to this post by Steven Kelly
Dear Steve,
> For Widgetry to survive it must become the single GUI framework > in VW, in about the same timeframe as VW replaced ObjectWorks, That was between VW 1.0 and VW 2.5. > or events replaced polling. For that to happen, groups 2b and 3 both > need to push Cincom to provide automatic conversion. This is indeed the key. If there were a trusted automatic converter today, this issue would probably be going along a different path. (Your remark about converting wrapper specs to widgetry UIs is the first step to such a thing.) > Effectively, Cincom have built a new "house" whilst allowing the old > house to fall into disrepair: unless the new house is seriously flawed, > it doesn't make sense to abandon the new house and start patching > up the old house, just because we suddenly notice we haven't yet > hired a removal van to help us move house. A removal van costs far, far less than a house and can be hired in a day. Right now, I think Cincom is worried that a converter is an unknown cost for something of unknown efficacy. Christian and I discussed building one with Travis et al at ESUG. Some Widgetry patterns differ significantly from Wrapper patterns: Cincom's internal experience of rewriting some example apps was harder than expected. After talking through these examples, Christian and I remained positive about feasibility but concluded that months, not weeks, of effort was the prudent estimate - and XP tells us with what caution we should regard all such early estimates. (That's for a funded commercial project, of course. If you wait to get it as a Camp Smalltalk project, you may be waiting for a while. :-/) So, as regards > groups 2b and 3 both need to push Cincom to provide automatic conversion. Group 3 is pushing in the only way it can: people who have done significant.work in Widgetry are saying (quite loudly :-)) that they are motivated by it. This group's technical evaluation is worth something. However (AFAIK) this group do not of themselves have large budgets or represent large budgets to Cincom. Those who do are in group 2b. In your earlier post, you expressed relief that the 2b customer you represent, MetaCase, does not have an urgent need for Widgetry (IIUC, and I quite see that it is so from MetaCase' point of view). So, are there any 2b customers who will say they _do_ really need Widgetry? If so, the next point is that Cincom - and I agree with them absolutely about the importance of this - are very focussed on some other issues: one is not missing their chance to turn Seaside into a window of opportunity for Smalltalk, and to ride VW through that window. No merely verbal pushing will make them sacrifice that (and I'd be worried if I thought it could). Pushing them to spend money on a converter is pushing them to take money from something, so what can be deferred?. I therefore guess that their first question to any such 2b customer(s) will be, "Do you want a converter enough to help fund it?" That completes my analysis. HTH. Yours faithfully Niall Ross > *From:* Maarten Mostert [mailto:[hidden email]] > *The fact is that except... for your HackerTalkers not a single > developer who tried Widgetry came back stating it is not worth the > change. > > *Whether something is "worth the change" depends on more than just "is > Widgetry better than Wrapper". Until there is an automated conversion > or interpretation of Wrapper windowSpecs and ApplicationModels to make > them work in Widgetry, I don't even need to /try/ Widgetry to tell you > it's not going to be worth it for me to migrate. Our application has > been built in VisualWorks since 1992, with something between 50 and > 100 man-years of effort. It doesn't take much maths to show that even > to just move with a "word by word" translation to Widgetry would take > rather a long time, and give very little real benefit instantly > (update speed is not much different, maybe some less flickering). To > take advantage of any new features Widgetry offers would take even > longer, and still not significantly enhance our application from the > point of view of its users. Our users definitely don't buy our product > just to look at whether the emulation of a button is pixel perfect, > but to use our /features/. We'd be much better off spending our time > on those features than on a massive GUI migration project to stand still. > > For the remainder of this message, I'll assume that Widgetry is > significantly better than Wrapper - mostly the important thing is that > it is internally better, lacking the crusty agglomeration of hacks > that Wrapper has become in many places. > > Put simply, the less existing investment in VW that people had, the > more likely they were to invest in building apps with Widgetry. But > generally speaking, the people who actually pay Cincom are the ones > who already have a significant investment in VW. By not providing a > clear, low-effort, low-risk migration path to Widgetry, Cincom ruled > out that migration for most people who pay its bills. > > So we have three groups that are interesting: > 1) Cincom > 2) long term customers who pay Cincom's bills and have large amounts > of Wrapper GUI but no Widgetry experience, > 3) new customers who pay Cincom little yet, may not have used Wrapper > much and have invested in using Widgetry > > Group 2 would be happy for Wrapper to continue and be improved, yet > recognise that at some point it would be great to have a new GUI > framework. They're used to having a graphical GUI builder for one-off > UIs, but also build GUIs programmatically when necessary. They've put > up with an awful lot of trouble from Widgetry over the last 6 years, > since it has stopped sorely needed work on their existing GUIs, and > has stretched its deadline to four times what was promised. Group 2 > are those that would directly benefit the most from the promised > automated conversion, yet neither they nor group 3 are really expert > enough in both sides of the conversion to build it. > > Group 3 would be happy for Wrapper to be killed right now, preferably > with a stake through its heart (thank you Maarten for making that > vehemence clear! :-> ). They have no direct desire for conversion, or > for a graphical GUI builder (since they have been prepared to build > everything by code, they are probably in the 20% of the populace that > prefers text to visual). Indeed, they may even oppose work on those > areas, as they would divert resources from other improvements to Widgetry. > > That leaves us with Cincom. They have the experience on both sides of > the conversion. They can't afford to support two frameworks in the > long run. They thus have to guess whether group 2 is going to continue > providing income in the long term with Wrapper-based applications, or > group 3 is going to grow and provide a similar amount of income with > its Widgetry-based applications. My guess is that group 2 splits into > 2a, whose apps are not actively pushed forward and will not update to > Widgetry under any circumstances, and 2b, whose apps are actively > developed and would be updated (grudgingly!) given a sufficiently good > automated conversion. Long term, 2b will tend to provide income and 2a > will tend to die out - regardless of our choices here. > > For Widgetry to survive it must become the single GUI framework in VW, > in about the same timeframe as VW replaced ObjectWorks, or events > replaced polling. For that to happen, groups 2b and 3 both need to > push Cincom to provide automatic conversion. > > Effectively, Cincom have built a new "house" whilst allowing the old > house to fall into disrepair: unless the new house is seriously > flawed, it doesn't make sense to abandon the new house and start > patching up the old house, just because we suddenly notice we haven't > yet hired a removal van to help us move house. > > Cheers, > Steve |
|
|
In reply to this post by Steven Kelly
From: Maarten Mostert
[mailto:[hidden email]] 6 years ago we were promised
Pollock/Widgetry in 18 months, with automatic conversion for 80% of existing
code and semi-automatic for another 16 of the remaining 20 percentage points.
With promises like that, we were ready to bite the bullet and accept the change.
As time has passed, and the pressure on existing GUIs from lack of improvements
to Wrapper has increased, I and others have been vocal in voicing our concerns
publicly:
and I'm sure bigger customers have been
similarly vocal in private meetings with Cincom.
The biggest surprises to me
were:
1) the 400% longer wait for the core
framework of "production" Widgetry
2) no GUI builder tools, and no plans for
them
3) that "production" Widgetry didn't
include conversion
4) the axing of Widgetry, despite
virtually no public criticism of it from customers
1, 2 and 3 are the reasons you haven't
heard criticism of Widgetry itself from me earlier. I need 2 to estimate our
costs of building new apps with it, and 3 to estimate our conversion
costs. Only when all three are in place - as was promised to us - can I
sensibly spend time looking at Widgetry. As I said nearly two years
ago:
Remember too that Cincom in 2001 was rather different from today: we were used to just getting what we were given, when it was ready, and not much information beforehand, or choice in the matter. I don't recall being consulted about ObjectWorks => VisualWorks, or polling => events. Sames was an important part of the move to more transparency in the development process, and I salute him for that. The important thing now is not really how much we can kick Cincom, but whether the best solution is to dump Widgetry or make a converter or interpreter for it. If there is an interpreter, we could carry on using most of our existing code and the existing GUI painter. As Niall Ross pointed out, building such an interpreter will cost substantially more than my exaggerated removal van analogy, but presumably only a few percent of the cost already sunk into Widgetry, and much less than the cost of post-fitting Widgetry-style improvements into the creaking behemoth that is Wrapper. I don't care if VW's own development tools stay in Wrapper for a fair while. (Some bits could clearly do with a rewrite from scratch, though: the thought of trying to work on the existing Store GUIs presumably fills Sames with loathing and an unhealthy desire to deploy trinitrotoluene, and I personally volunteer to light the fuse.) I may want to initially leave some of my stuff in Wrapper and move some to Widgetry, but soon I'd like to be deploying just one framework in my app. My users aren't going to want to put up with inconsistency of look and feel within a single app - bad enough that there are some differences between the app and the native OS behaviour. Steve |
|
|
In reply to this post by Steven Kelly
I would say that life comes with compromises. One of Widgetry's vocations was to be able to supply an equal or superioir GUI painter environement. This means that some basic conversion tools could come quite easily. Due however to Wrappers dead-end UI-Builder environment and Widgetry's significant difference, full conversion tools however might be very expesive. That's why I would propose a canvas per canvas one-way only conversion tool, which will still save you a lot of time in refactoring your applications.
You are almost there now but be be very carefull. If you ever decide to give Widgetry a serious try you will expose yourself to get hooked. If you do so however you'll find that Sam blog is not so much about hacking your way around but all about translating you business idea into Smalltalk applications. Your favorite widget might not yet be in WIdgetry but you will have the impression that you can do that on your own and within days (That is really thrilling). Rgrds, @+Maarten,
|
|
|
In reply to this post by Steven Kelly
If I just said: << Wrappers dead-end UI-Builder environment >> then that was motivated by Eliot Mirandas statement in the smalltalk newsgroup:
I sometimes tend to believe these old Sioux wisdoms. Rgrds, @+Maarten, |
|
|
In reply to this post by Steven Kelly
Just for the record. Go into your WinXp control panneaux system confirguration ODBC sources. Change the source of your Jet Engine ACCES file and see a file dialog that probably dates back to the Windows NT 1.0 release. Who Cares ?? Rgrds, @+Maarten,
|
|
|
In reply to this post by Maarten Mostert-2
A couple of things to keep in mind. Circa
2000 (before we started Widgetry), there was no GUI team. The team working
on VW at that time was what was left after the problems at ParcPlace/Digitalk
and ObjectShare. The entire GUI staff that had been part of the
VW team either left or got laid off in 1995-1996 - and the people who were
left worked in other areas of the product. The only way GUI
improvements of any kind happened at that point was the addition of third
party components (eg: the Look and Feels from IC&C). In VW 3 and VW
5i, no UI work of note was done by the internal team, and no one on that team
had any particular expertise in UI. That's not a knock on any of them,
btw - it's just the state things were in back then.
|
|
|
In reply to this post by Maarten Mostert-2
Maarten MOSTERT escreveu:
> My users aren't going to want to put up with inconsistency of look > and feel /within/ a single app - bad enough that there are some > differences between the app and the native OS behaviour. > > Just for the record. > > Go into your WinXp control panneaux system confirguration ODBC sources. > Change the source of your Jet Engine ACCES file and see a file dialog > that probably dates back to the Windows NT 1.0 release. > > Who Cares ?? > For an applet to be used by a sysadmin when and then, you're right: nobody could care less. For an application (a.k.a. 'business app') that has to live side by side with the last incantation of Office or some application based on the Web interface Microsoft is pushing (Antivirus, graphic packages, etc.), then the differences become quite noticeable. Just my .0199999..... -- Cesar Rabak GNU/Linux User 52247. Get counted: http://counter.li.org/ |
|
|
In reply to this post by Steven Kelly
Dear Steve,
> The important thing now is not really how much we can kick Cincom, but > whether the best solution is to dump Widgetry or make a converter or > interpreter for it. If there is an interpreter, we could carry on > using most of our existing code and the existing GUI painter. As Niall > Ross pointed out, building such an interpreter will cost substantially > more than my exaggerated removal van analogy, but presumably only a > few percent of the cost already sunk into Widgetry, > Yes indeed; precisely a less-than-one-hand-count-of-percent of the sunk cost is our estimate. The issue is that, for decision purposes, this is not compared with the sunk cost; sunk costs are sunk costs. It is compared (I assume) with the VW 4th-quarter-of-2007 development budget, from which it would (by hypothesis) come, unless a customer(s) comes forward. It may look larger in that context. It will certainly look harder to find. > and much less than the cost of post-fitting Widgetry-style > improvements into the creaking behemoth that is Wrapper. > That is the $64,000 question (less than that, of course, as regards building the converter, but one can also list other things that Widgetry would _like_ - Christian and I did - and if the release decision, as such decisions may, ended up pulling them all in as well, perhaps it could approach it). I agree with your answer, but suspect that, as well as concerns about relative value, there are concerns about the relative certainty of getting value: 1) 'Work on Wrapper instead' means _some_ level of UI improvement will appear every increment. The uncertainty is over scope. It has already been suggested in this thread that fixing Wrapper instead of releasing Widgetry means descoping, with various opinions about how brutal a descoping it will be and whether a wall of Wrapper brittleness lurks in wait. 2) By contrast: > Our application has been built in VisualWorks since 1992, > with something between 50 and 100 man-years of effort If 40% of that effort was in UI code affected by rewrite then (simplifying very greatly) a 90%-complete converter would leave you with between one and two years of effort to put in to move your application to Widgetry. That would not be good enough: you would need a 99%-complete converter or better, producing thoroughly readable evolvable code. Now I fully believe that is doable. However _until_ it reached that stage, would the converter be valuable at all to you, or to the many customers like you? I can image that just at the moment 'get all the value at the end' project proposals are not flavour of the month. I hope I've represented the viewpoints fairly despite my own (I assume) being plain. I think I've said all I usefully can so will (try to :-)) restrain myself from posting on and on about this. I'll still be reading others' posts with interest. Yours faithfully Niall Ross |
|
|
On Mon, 17 Sep 2007 17:26:50 +0100
Niall Ross <[hidden email]> wrote: > 2) By contrast: > > > Our application has been built in VisualWorks since 1992, > > with something between 50 and 100 man-years of effort > > If 40% of that effort was in UI code affected by rewrite then > (simplifying very greatly) a 90%-complete converter would leave you with > between one and two years of effort to put in to move your application > to Widgetry. Out of curiosity: is 40% a realistic estimate? My (granted small) experience with such long-lived applications is that a *lot* of previous development time is either replaced by later changes (i.e. a complete rewrite of a data entry dialog that took you months to get perfect) or spent behind the curtains tweaking the logic to keep up with changing requirements. Thanks, s. |
|
|
Stefan,
I would say Nialls estimation is pretty realistic. I know a few very long running Smalltalk projects which are centered around a few hundred screens. Each screen has been kind of a functionality driver, meaning the applications were architected and analysed around screens. So a really big part of the functionality is somewhat hardcoede into and around the GUI classes. If I had had to pick a number, I'd probably chosen 30+ percent instead of fourty, but Niall's calculation would still be valid and bring up impressive figures. cu Joachim Stefan Schmiedl schrieb: > Out of curiosity: is 40% a realistic estimate? My (granted small) > experience with such long-lived applications is that a *lot* of previous > development time is either replaced by later changes (i.e. a complete > rewrite of a data entry dialog that took you months to get perfect) or > spent behind the curtains tweaking the logic to keep up with changing > requirements. > > Thanks, > s. > |
Re: Long live all VW apps [Just one question]
|
|
In reply to this post by Steven Kelly
Behind the scenes its all Glorp but some of you probably guessed that allready (thanks Alan). Just one question: Imagine you have gathered all this decisions makers together for your demonstartion and then you open up your image (Some of you who were in Sales might remember that thrill). Then tell me honestly which project you would prefer to be on. @+Maarten, PS 1) If we combine Andre's sugestion list with Steve expérience with delai and Eliots opinion about the underlaying system we will be in for at least another....months to .....years wait. But then off course I miscount the fact that the new generation will succeed where the others failed. 2) Anyone who is interested to turn this project into a Killer Widgetry App is allowed to contact me off-line. |
Wrapper.png (164K)
RE: Long live all VW apps [Just one question]
|
|
In reply to this post by Steven Kelly
From: Maarten Mostert
[mailto:[hidden email]]:
Oh no, this is
terrible, and I don't think you'll believe me. I honestly thought for a good 10
seconds that you'd mistakenly swapped the names of the files around. The one
called Widgetry has a clunky, ugly tree view on the left, the Organisation tree
view has most of the same problems, the toolbar icons don't have enough spacing,
the Gantt table has ugly black cell borders, its Progress bars' tick marks are
misaligned and some sliders are missing their right hand edges. The one called
Widgetry looks prettier in the Gantt table because of the icons, has a beautiful
Gantt chart, and has pretty icons in the Resources list.
That was my first
impression. Of course looking more closely I can recognise some familiar Wrapper
"features":
- the Gantt table
headers are ugly buttons. We use a slightly modified UndecoratedButtonView for
those
- the status bar is
done in an old-fashioned way with group borders. We use the same more modern
look that you have in the Widgetry status bar
- you haven't set a
mask for some of the main tab view's tab icons
There's also
something you could consider changing in both:
- the big default
font is used in the Projects, Organisation and Resources list. We find
using the smaller system font makes things look more
"modern"
I know part of the
initial perceived prettiness was because of what content was displayed - I'm
assuming you could show similar icons and charts in the Gantt areas in Widgetry
still. Allowing for that, and the corrections you can make without changing
Wrapper, I'd say Wrapper just wins.
What these pictures
don't show is the "feel" side of the UI, i.e. how the controllers respond.
That's one of Wrapper's weak points: mouse down opens menus when it should be
mouse up, pull-down lists don't respond properly to the keyboard,
etc.
Thanks for giving
those of us who haven't used Widgetry a useful point of comparison. I think I'll
leave this topic now.
Good luck with your
application!
Steve
|
|
|
In reply to this post by Stefan Schmiedl
Stefan Schmiedl <[hidden email]> wrote:
> Niall Ross <[hidden email]> wrote: > > > 2) By contrast: > > > Our application has been built in VisualWorks since > > > 1992, with > > > something between 50 and 100 man-years of effort > > > > If 40% of that effort was in UI code affected by rewrite then > > (simplifying very greatly) a 90%-complete converter would > > leave you with between one and two years of effort to put > > in to move your application to Widgetry. > > Out of curiosity: is 40% a realistic estimate? My (granted > small) experience with such long-lived applications is that a > *lot* of previous development time is either replaced by > later changes (i.e. a complete rewrite of a data entry dialog > that took you months to get perfect) or spent behind the > curtains tweaking the logic to keep up with changing requirements. We have somewhat over 400 UIs, so most of our work is elsewhere. Certainly much work is elsewhere than in the code - in the thinking behind the code, which won't change when moving to a new GUI framework. Maybe 40% of effort went into the UI, but if we use Brooks' figures, only 1/6 of that was spent on the actual coding, maybe 1/3 if we include the coding part of maintenance. That gives something like 10-15% being spent on UI code, which feels about right to me for our app. One tricky thing to judge is how much of our ApplicationModel code is doing something that would no longer work under Widgetry. Messages sent to widgets etc. (e.g. postBuildWith:) clearly won't work out of the box. Messages to aspects might or might not work, depending how many of the various dependency mechanisms still work in Widgetry. Messages sent to manipulate model objects more directly should work - but probably shouldn't be in the ApplicationModel anyway. In moving to a new GUI framework, a sizeable part of the time would be spent on getting to know the new framework. With 80% + 80%*20% conversion, it would be greater than the effort spent on conversion - the more so the more programmers there are. But I think it's time for me to leave this conversation... Steve |
RE: GUI development time share
|
|
In reply to this post by Stefan Schmiedl
Steve you became a HackerTalker without knowing it. Your Wrapper widgets are simply not flexible enough to do these things on initialization. You forgot that if you don't respect the initialize, prebuild postBuild and postOpen scheme you can simply not do that. That is why everybody made his container component container component includes: etc code. If they do something seriously about the "Who is the real builder widget question", all this code will be broken anyway. So you will remain obliged to hack & test around all your UI's for month's before upgrades. In widgetry you can simply call your postbuilWith type message at the end of the createInterface method and your tabcontrol will open on the right page.
Here you can take advantage of this nice new Class Announcement system, where the announcement itself contains loads of information like the positon and the cell wich triggered the event. Appreantly this will be ported to Wrapper ASAP so your aspect question is allready out of the Window (Offcourse aspect can be many things so I might misunderstood the question).
You should count the time to read the old Polluck manuel and Sams Blog. lets say 1 day. Then you should do the examples so antoher day. After that you take of and you make tree level tabcontrol interface on a sunday afternoon. How many month's again did it took you to get your HackerTalker certificate and do that in Wrapper ? Notice that Widgetry is all about simplicity and simplicity into todays buisiness where intelectual masturbastion rules the world has turned out in being an Art and a science in itself. @+Maarten, |
|
|
I really hate the HackerTalker term that was created to describe Wrapper
development. It's unfair and highly insulting to developers who have been doing Wrapper work for years which is most of the VisualWorks community. Most projects I know of have added extensions to the ApplicationModel such as those proposed by Tim Howard's book "The Smalltalk Developer's Guide to VisualWorks" which makes Wrapper programming much better and, in fact, provides facilities that Widgetry doesn't have but should have (and wouldn't be hard to add). With this framework, I can say in my application model: self enable: #(#widget1 #widget2 #widget3) onCondition: someBoolean It enables those widgets if the boolean is true and disables them if it's false. I did a project in Widgetry and one task was to add a close button to the tabs in a tab view. I did it, but I had to create several overrides of Widgetry methods which I felt I shouldn't have had to do. The code to add the "tab scrolling buttons" is hard-coded and I felt like I had to hack it in order to add an extra button. Widgetry isn't immune to hacking. Wrapper can be written without hacking. PLEASE bury the term HackerTalker. Thanks David Buck Maarten MOSTERT wrote: > > Steve you became a HackerTalker without knowing it. > |
Re: GUI development time share
|
|
In reply to this post by Stefan Schmiedl
That is fine Dave, I just am remain and are still highly upset about this decision. And after hearing this nice clap in the hand and drink a beer podcast I heard this morning even more. The truth remains that they did not put in the required resources to make Widgetry a succes and remain without a single engagement to do so for Wrapper (they happily make the same mistake twice). The Java C# fear still seem to have ruled over Smalltalk and over this decision. We have no clear vision about a new graphic subsystem. Their current technical direction remains highly compromised. We have no more reason to believe them more now then we did before. With regards and respect. You were right. @+Maarten,
|
Re: GUI development time share
|
|
I'm not about to make any grand sweeping statements
about the UI right now - what I will say is that we have some exploratory
development going on, and that ideas from that exploration will likely be merged
back into the existing UI. On graphics, we are exploring two different
possibilities - more native tie-ins for drawing, and Cairo. Both
approaches are exploratory right now; we aren't about to commit to a path until
we have a better idea which direction is more likely to work out.
|
Re: Long live all VW apps [Just one question]
|
|
In reply to this post by Maarten Mostert-2
Maarten,
On 9/17/07, Maarten Mostert <[hidden email]> wrote:
I'd actually love to see side-by-side images. B ut you've posted two quite different views so its hard to infer anything from them. Please repost a Wigetry image that includes the Gannt chart tab. tia |
| Free forum by Nabble | Edit this page |