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@anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
gazzaguru2@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@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
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!
-----Original Message----- From: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Bill Schwab Sent: 14 February 2008 2:08 PM To: ui@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@anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
gazzaguru2@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@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
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@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Bill Schwab Sent: 14 February 2008 2:08 PM To: ui@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@anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
gazzaguru2@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@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
On Thu, Feb 14, 2008 at 5:04 PM, Karl karl.ramberg@comhem.se wrote:
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
Yea, I wish there were a way to make preference closer to what they modify somehow. So instead of going to one place and reading big long variable names, you just change the preference in the place you would expect to (e.g. Window focus behavior changed on the windows, etc.)
Just a start in the direction of having choices in UI frameworks.
On Thu, Feb 14, 2008 at 3:08 PM, Bill Schwab BSchwab@anest.ufl.edu wrote:
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.
Personally, given previous conversations I think the best option would be to allow multiple of the Squeak windows. That is, objects are always rendered on a Squeak type canvas, a text box is always purely drawn in Squeak and never native, but we can just have several of these instead of only the one.
On 15-Feb-08, at 11:51 AM, Jason Johnson wrote:
On Thu, Feb 14, 2008 at 3:08 PM, Bill Schwab BSchwab@anest.ufl.edu wrote:
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.
Personally, given previous conversations I think the best option would be to allow multiple of the Squeak windows. That is, objects are always rendered on a Squeak type canvas, a text box is always purely drawn in Squeak and never native, but we can just have several of these instead of only the one.
Our basic intent when designing Ffenestri was to allow pretty much any usage. If you want to map a single SystemWindow level object to a host window then that would be good and would match most needs in typical applications. Don't forget to consider floating palette type windows as well - those that accompany a main window and provide a palette of tool icons etc. And menus could be implemented by opening a short lived small window; this might well be much simpler and more portable than trying to hook cleanly into every OS menu api, whilst allowing the menu to be taller than a small app. window if needed.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Klingon Code Warrior:- 10) "This code is a piece of crap! You have no honor!"
On Fri, Feb 15, 2008 at 9:00 PM, tim Rowledge tim@rowledge.org wrote:
Our basic intent when designing Ffenestri was to allow pretty much any usage. If you want to map a single SystemWindow level object to a host window then that would be good and would match most needs in typical applications. Don't forget to consider floating palette type windows as well - those that accompany a main window and provide a palette of tool icons etc. And menus could be implemented by opening a short lived small window; this might well be much simpler and more portable than trying to hook cleanly into every OS menu api, whilst allowing the menu to be taller than a small app. window if needed.
Yea, that sounds good. After hearing from several sources the efficiency problems of trying to do that clean mapping you mention I think something like what you outlined would be the best of all worlds.
-
Bill Schwab -
Gary Chambers -
Jason Johnson -
Karl -
tim Rowledge