[UI] Morphic restructuring

[Karl]

Gary Chambers wrote:
> Not planning any Tweak low-level stuff. Just a restructuring of the event
> mechanism to allow both "world" based and individual (host) window based
> opportunity. Pick-n-mix!
>   
A few morphic issues come to mind:
Keyboard focus stuff is messy and cause lots of errors.
Dozens of preferences that nobody use or know what are for.
The mix of AlignmentMorph and other morphs for doing layout stuff.
And more and more

Karl
>   
>> -----Original Message-----
>> From: ui-bounces at lists.squeakfoundation.org
>> [mailto:ui-bounces at lists.squeakfoundation.org]On Behalf Of Bill Schwab
>> Sent: 14 February 2008 2:08 PM
>> To: ui at lists.squeakfoundation.org
>> Subject: Re: [UI] Morphic restructuring
>>
>>
>> Gary,
>>
>> Morphic works, there is not much else to say in its favor, and you have
>> shown amazing flare for user interface implementation, so I tend to
>> trust your judgement.  That said, a couple of questions/comments:
>>
>> Are you thinking of multiple host windows as in allowing each system
>> window to have its own host window, perhaps in it own morphic world
>> running therein?  I have *no* idea whether the world is
>> good/bad/optional.  Details aside, it could be nice to have that option.
>>  There are times when a single host window for the IDE is great, and
>> times when it is unfortunate.  Any system that emulates (and I am
>> convinced that emulation is a good thing far more often than the
>> mainstream would have us believe) should be able to give the user the
>> choice to host in one window or many.  Great idea.  Like it a lot :)  As
>> an example of when I might want to use a single window, imagine a
>> machine running multiple "deployed" Squeak images with some debugging
>> and image re-saving as part of the plan. Intermingling tools in host
>> windows might get very confusing; I have not done this, but I would
>> expect to do so if I end up using Squeak on a large scale.  Multiple
>> host windows have myriad uses, all the more so when considering end
>> users.
>>
>> You mentioned Tweak.  I fear Tweak.  It has some good ideas, but
>> altering the compiler was (IMHO) a huge mistake.  I could mention
>> a_few_other_things that are not quite where_they_belong, but you get the
>> idea.  Build separate code-generating/editing tools (e.g. WindowBuilder
>> on steroids) to provide the same functionality with an
>> object-composition/code-based event system underneath the tools, and I'm
>> all over it.  Put another way, I like new things to be built in
>> Smalltalk, not into it, unless there is no other way.  However, I
>> suspect you are proposing backward-compatible changes to Morphic events
>> to enhance it, which is probably great.  What do you have in mind? :)
>>
>> Bill
>>
>>
>>
>>
>> Wilhelm K. Schwab, Ph.D.
>> University of Florida
>> Department of Anesthesiology
>> PO Box 100254
>> Gainesville, FL 32610-0254
>>
>> Email: bschwab at anest.ufl.edu
>> Tel: (352) 846-1285
>> FAX: (352) 392-7029
>>
>>     
>>>>> gazzaguru2 at btinternet.com 02/11/08 11:01 AM >>>
>>>>>           
>> Would anyone agree that a reorganisation of the Morphic event system
>> would
>> be useful?
>> Just looking to perhaps transparently support use of multiple host
>> windows.
>> Kind of like, if an event has a tag of some kind that it is deferred to
>> a
>> registered handler, default would be as-is. A little bit Tweaky but just
>> a
>> start on the infrastructure.
>>
>>
>> Gary.
>>
>> _______________________________________________
>> UI mailing list
>> UI at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/mailman/listinfo/ui
>>
>> _______________________________________________
>> UI mailing list
>> UI at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/mailman/listinfo/ui
>>     
>
> _______________________________________________
> UI mailing list
> UI at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>
>