UI November 2007

ui@lists.squeakfoundation.org

15 participants
42 discussions

Printing??
by Bill Schwab 22 Nov '07

22 Nov '07

Hello all, Not really a UI question, but do any of you print from Squeak? I would need to do so on Windows and Linux. I have found post script canvas classes, but nothing that looks like it gets regular use for creating hardcopy. My actual need is to print "graphics" that I split across typically < 20 pages. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029

3 2

Patches to apply
by Bill Schwab 20 Nov '07

20 Nov '07

Hello all, I found the following: http://bugs.squeak.org/view.php?id=0006576 http://bugs.squeak.org/view.php?id=6588 Is that the stuff I need for 3.9? Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029

1 0

Re: [UI] Re: MenuMorph hand weirdness
by Bill Schwab 20 Nov '07

20 Nov '07

Jason, Agreed about a graphical view editor - it is a must for many kinds of things. However, five years or so ago, a friend and colleague of mine needed to store several hundred data points on each of 100+ patients. It is small time compared to much of the database work that goes on in the world, but it was big for us. Note that "us" turns into "***ME*** (gulp!)" when it comes to making work. I actually tried to build it using Access (trying to do it the "accepted" way), and it was starting to look like a disaster in the making. I then turned to Dolphin and began scripting the view composer; with some tweaks, the image survived it, and it soon turned into quite a display of Smalltalk's power. A similar trick will be necessary for a sombre task: converting a LOT of GUI code and view resources to another Smalltalk system. That process will be essential to a robust port, and will provide a lot of testing for a new MVP framework. It is a natural place for me to start any serious port attempt, hence the focus. I share you desire for a graphical view editor. Do you have any thoughts on how to build it given that "views" will include morphs, svg structures, and even native widgets? Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> jason.johnson.081(a)gmail.com 11/20/07 2:34 PM >>> On Nov 20, 2007 2:50 AM, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: > > This was a question to gauge the importance of having menus themed as > standard, in the general IDE sense... more of fixing what we have rather > than the new big thing. > > In terms of "the new big thing" I think we have to become very much more > focussed. That means really working together. Perhaps everyone could make a > prototype system to demonstrate to us all... then work together with the > best bits? > > As a start, we should be able to easily conform to any particular "look and > feel"... take the Java abstraction classes as an example. We could also > incorporate "native" (Win32/GTK) as part of the framework (different to the > "emulated" Java). I'd really like anything we do to be non-exclusive and > all-encompassing, both potentially attainable goals. > > Might sound a bit "bloaty" but a framework that can plug-and-play our > concepts would be nice... I think this is all very doable within MVP and in fact MVP would make this sort of thing much easier to do, since very little if any code would depend on what view was being used. > I think it comes down to the way(s) you want to be able to describe a > user-interface. Need to be able to express the intention of the ui in a > flexible manner but, also, for some applications, have exact control (plus a > lot of in-betweens). ToolBuilder does a lot of that, but is not yet rich > enough to do the latter... Personally I prefer to use a graphical tool to draw exactly the interface I want, but different people want different things, so having a nice framework that can support all of us is the answer I believe. _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

2 1

RE: [UI] Re: MenuMorph hand weirdness
by Bill Schwab 20 Nov '07

20 Nov '07

Gary, Re-reading your reply (after clicking send - when else?), I caught your supportive emphasis on streams. I'll give it whirl, and let you decide for yourself given a (hopefully) working implementation to try. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> gazzaguru2(a)btinternet.com 11/20/07 1:15 PM >>> We have some extensions along the lines of "self synchronize: [aBlock]"... which was why the semaphore stuff was important. I guess we'll (Pinesoft) get some time to release these things too... Go for it with Streams, personally I still use them in the "traditional" sense, quirks and all! As for (presentation) platforms it will be some work to provide a flexible and pertinent layer for that... > -----Original Message----- > From: ui-bounces(a)lists.squeakfoundation.org > [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Bill Schwab > Sent: 20 November 2007 5:08 PM > To: ui(a)lists.squeakfoundation.org > Subject: RE: [UI] Re: MenuMorph hand weirdness > > > Gary, > > MVP indeed predates OA's work, but I have to walk a fine line of making > something compatible and untainted. I do not think I can serve as a > coder on a clean version. Tests I can write and distribute. > > As for you starting at the bottom and me at the top, that's perfect! > You clearly have great skill at graphical coding, and have a lot of MVP > work that can stress test my (non-existent, so far) MVP framework; I > also have meta data->code translators that can push it. A design goal > should be to allow the view hierarchy to change; OA anticipated that, > and it makes sense to continue and extend it. If the effort succeeds, > we can begin work on a clean room version knowing that success is > possible. > > 3.9 it is. I am very pleased to see you also using processes. The > first tangible system I would be likely to port is a serial > communication multiplexer. It makes heavy use of streams[*], and > arguably heavy use of processes. The latter is murky to me, as my > earliest evaluations of Squeak included a reality check on the scheduler > and synchronization; at the time people reported dwarfing my > requirements without problems. The more recent "fix this or we switch > to Java" discussions were unsettling, though you reported having > improved results with the resulting patches. > > [*] I would very much like to put teeth into EndOfStream. I might even > see how to do it. As I see it, silent truncation by #next: is an > accident waiting to happen, and exception handling is the answer. The > problem would be getting it accepted. > > Bill > > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 846-1285 > FAX: (352) 392-7029 > > >>> gazzaguru2(a)btinternet.com 11/20/07 10:06 AM >>> > > > > -----Original Message----- > > From: ui-bounces(a)lists.squeakfoundation.org > > [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Bill Schwab > > Sent: 20 November 2007 2:44 PM > > To: ui(a)lists.squeakfoundation.org > > Subject: RE: [UI] Re: MenuMorph hand weirdness > > > > > > Gary, > > > > In terms of describing an interface, I immediately zoom out to the two > > ways one might approach it: graphical editing, and writing code. The > > nature of the GUI editor and the language are "just details." IMHO, > > both methods are essential for happy programmers. I have some GUI > > generating/translating tools that I would expect to port to whatever > > Smalltalk system I end up using; they speak MVP. If I land in Squeak, > > it will have an MVP framework, if only because I will write one out of > > frustration :) > > a concise (programmatic) construction framework would be nice as > a basis > for graphical tools. Code generation-reintegration is, IMHO, more > flexible > and explict than live prototypes. It is alway good to know that there is > a > basis for recreating a (specific) UI for a system. Similar to the > concept of > the image, good to know that it can (essentially) be regenerated if > corruption problems occur. > > > > > As I have mentioned before, I am concerned that any MVP work I do > would > > be tainted with Object Arts' intellectual property. However, if I > > create a framework (tainted) and my own tests for it (by definition > > clean - right???), then the tests could be the basis for a clean MVP > > framework for Squeak. Any flaws? It is a lot of wasted work to write > > and then have someone else rewrite a framework, but it might solve the > > problem. At least the rewrite would occur with the benefit of tests. > > > > MVP, as I remember, predates Dolphin in research terms... > > > With some cleverness, Morphs as views, native widgets, SVG, etc., are > > hopefully just different types of views in the framework. > > > > Indeed, though a mechanism (call it a theme or configuration > perhaps) to > bind a coherent set of things together will help. If things are > cross-pluggable then it should be easy to mix-n-match to suit any need. > > > As a practical matter, I have a few too many Squeak images for my own > > good. I need to archive them all, mine code out of them, and create > one > > image that will move back and forth between Linux and Windows. Any > > thoughts on 3.9 vs. 3.10? For 3.9, I would want the > > delay/queue/semaphore fixes; IIRC, those are included in 3.10?? > > > > Bill > > Since I'm currently working on deployment to customers I'll be > sticking > with 3.9 (fixes applied) for the moment. Others in the office are on the > 3.10 dev beta images. Once our release is stable we'll migrate to 3.10 > in > the background, I don't forsee any real problems, not the right time to > abandon 3.9 for our deliverables just yet. > > Found another process related bug i may have to air in the dev > list. Looks > like Process>>isTerminated is not thread safe/and/or correct. Have has > instances where a live process has responded "true" to isTerminated, > briefly! (we are using quite a few processes at various priorities - > preemption bites!) > > For me, for a fresh start, I'd like to start at "the bottom", > basic > drawing/interation (Cairo/BitBlt/Balloon/GTK etc). Perhaps we can meet > halfway... > > > _______________________________________________ > UI mailing list > UI(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/ui > > _______________________________________________ > UI mailing list > UI(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/ui _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

1 0

RE: [UI] Re: MenuMorph hand weirdness
by Bill Schwab 20 Nov '07

20 Nov '07

Gary, I am having some trouble envisioning #synchronize: - I tend to think in terms of shared resources identified by/with a mutex, or something along those lines. Being a process junkie, I look forward to seeing what you have done. Could I interest you in more cross-dialect-friendly stream semantics? IMHO, once you have an exception catch a format deviation "now vs. later," you'll be hooked. No hard feelings if you decide to stick with Squeaky streams. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> gazzaguru2(a)btinternet.com 11/20/07 1:15 PM >>> We have some extensions along the lines of "self synchronize: [aBlock]"... which was why the semaphore stuff was important. I guess we'll (Pinesoft) get some time to release these things too... Go for it with Streams, personally I still use them in the "traditional" sense, quirks and all! As for (presentation) platforms it will be some work to provide a flexible and pertinent layer for that... > -----Original Message----- > From: ui-bounces(a)lists.squeakfoundation.org > [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Bill Schwab > Sent: 20 November 2007 5:08 PM > To: ui(a)lists.squeakfoundation.org > Subject: RE: [UI] Re: MenuMorph hand weirdness > > > Gary, > > MVP indeed predates OA's work, but I have to walk a fine line of making > something compatible and untainted. I do not think I can serve as a > coder on a clean version. Tests I can write and distribute. > > As for you starting at the bottom and me at the top, that's perfect! > You clearly have great skill at graphical coding, and have a lot of MVP > work that can stress test my (non-existent, so far) MVP framework; I > also have meta data->code translators that can push it. A design goal > should be to allow the view hierarchy to change; OA anticipated that, > and it makes sense to continue and extend it. If the effort succeeds, > we can begin work on a clean room version knowing that success is > possible. > > 3.9 it is. I am very pleased to see you also using processes. The > first tangible system I would be likely to port is a serial > communication multiplexer. It makes heavy use of streams[*], and > arguably heavy use of processes. The latter is murky to me, as my > earliest evaluations of Squeak included a reality check on the scheduler > and synchronization; at the time people reported dwarfing my > requirements without problems. The more recent "fix this or we switch > to Java" discussions were unsettling, though you reported having > improved results with the resulting patches. > > [*] I would very much like to put teeth into EndOfStream. I might even > see how to do it. As I see it, silent truncation by #next: is an > accident waiting to happen, and exception handling is the answer. The > problem would be getting it accepted. > > Bill > > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 846-1285 > FAX: (352) 392-7029 > > >>> gazzaguru2(a)btinternet.com 11/20/07 10:06 AM >>> > > > > -----Original Message----- > > From: ui-bounces(a)lists.squeakfoundation.org > > [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Bill Schwab > > Sent: 20 November 2007 2:44 PM > > To: ui(a)lists.squeakfoundation.org > > Subject: RE: [UI] Re: MenuMorph hand weirdness > > > > > > Gary, > > > > In terms of describing an interface, I immediately zoom out to the two > > ways one might approach it: graphical editing, and writing code. The > > nature of the GUI editor and the language are "just details." IMHO, > > both methods are essential for happy programmers. I have some GUI > > generating/translating tools that I would expect to port to whatever > > Smalltalk system I end up using; they speak MVP. If I land in Squeak, > > it will have an MVP framework, if only because I will write one out of > > frustration :) > > a concise (programmatic) construction framework would be nice as > a basis > for graphical tools. Code generation-reintegration is, IMHO, more > flexible > and explict than live prototypes. It is alway good to know that there is > a > basis for recreating a (specific) UI for a system. Similar to the > concept of > the image, good to know that it can (essentially) be regenerated if > corruption problems occur. > > > > > As I have mentioned before, I am concerned that any MVP work I do > would > > be tainted with Object Arts' intellectual property. However, if I > > create a framework (tainted) and my own tests for it (by definition > > clean - right???), then the tests could be the basis for a clean MVP > > framework for Squeak. Any flaws? It is a lot of wasted work to write > > and then have someone else rewrite a framework, but it might solve the > > problem. At least the rewrite would occur with the benefit of tests. > > > > MVP, as I remember, predates Dolphin in research terms... > > > With some cleverness, Morphs as views, native widgets, SVG, etc., are > > hopefully just different types of views in the framework. > > > > Indeed, though a mechanism (call it a theme or configuration > perhaps) to > bind a coherent set of things together will help. If things are > cross-pluggable then it should be easy to mix-n-match to suit any need. > > > As a practical matter, I have a few too many Squeak images for my own > > good. I need to archive them all, mine code out of them, and create > one > > image that will move back and forth between Linux and Windows. Any > > thoughts on 3.9 vs. 3.10? For 3.9, I would want the > > delay/queue/semaphore fixes; IIRC, those are included in 3.10?? > > > > Bill > > Since I'm currently working on deployment to customers I'll be > sticking > with 3.9 (fixes applied) for the moment. Others in the office are on the > 3.10 dev beta images. Once our release is stable we'll migrate to 3.10 > in > the background, I don't forsee any real problems, not the right time to > abandon 3.9 for our deliverables just yet. > > Found another process related bug i may have to air in the dev > list. Looks > like Process>>isTerminated is not thread safe/and/or correct. Have has > instances where a live process has responded "true" to isTerminated, > briefly! (we are using quite a few processes at various priorities - > preemption bites!) > > For me, for a fresh start, I'd like to start at "the bottom", > basic > drawing/interation (Cairo/BitBlt/Balloon/GTK etc). Perhaps we can meet > halfway... > > > _______________________________________________ > UI mailing list > UI(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/ui > > _______________________________________________ > UI mailing list > UI(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/ui _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

1 0

Re: [UI] Re: MenuMorph hand weirdness
by Bill Schwab 20 Nov '07

20 Nov '07

Andreas, You raise an excellent point: Andy might well let us release my effort. I share you assessment of the buyout. I keep hoping they will prove me wrong, but it appears to be going nowhere fast. Out of respect for the folks involved, I will stop short of declaring it a failure just yet. As I expected, I am getting mixed recommendations re 3.9 vs. 3.10. I will probably go with 3.9 just since that is what Gary is using at present. The important thing is to stop poking at images here and there and escalate to some real work. It is a complicated story. So far, my "production" use of Squeak has been to gather literature and BibTeX entries using an Ubuntu system that has taking over my network access at home. The goal is to have one fewer Windows shop in the world, but it will take some time. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> A.Wacknitz(a)gmx.de 11/20/07 12:23 PM >>> Bill Schwab schrieb: > Gary, > > In terms of describing an interface, I immediately zoom out to the two > ways one might approach it: graphical editing, and writing code. The > nature of the GUI editor and the language are "just details." IMHO, > both methods are essential for happy programmers. I have some GUI > generating/translating tools that I would expect to port to whatever > Smalltalk system I end up using; they speak MVP. If I land in Squeak, > it will have an MVP framework, if only because I will write one out of > frustration :) > > As I have mentioned before, I am concerned that any MVP work I do would > be tainted with Object Arts' intellectual property. However, if I > An alternative might be to ask Andy and Blair for an explicit OK to open your Squeak MVP framework, if the Dolphin buyout fails (which seem to be stalled for some weeks now). > create a framework (tainted) and my own tests for it (by definition > clean - right???), then the tests could be the basis for a clean MVP > framework for Squeak. Any flaws? It is a lot of wasted work to write > and then have someone else rewrite a framework, but it might solve the > problem. At least the rewrite would occur with the benefit of tests. > > With some cleverness, Morphs as views, native widgets, SVG, etc., are > hopefully just different types of views in the framework. > > As a practical matter, I have a few too many Squeak images for my own > good. I need to archive them all, mine code out of them, and create one > image that will move back and forth between Linux and Windows. Any > thoughts on 3.9 vs. 3.10? For 3.9, I would want the > delay/queue/semaphore fixes; IIRC, those are included in 3.10?? > I would go for 3.10 as it seems to be mostly a bug fix release with some additional unit tests to me. Probably you will want to wait for the final release. Andreas _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

1 0

Re: [UI] Hands up who want menus themed
by Bill Schwab 20 Nov '07

20 Nov '07

Gary, Obviously, it is your call. I will admit that Squeak's menus could use a face lift, but I am much more concerned about Morphic/hand weirdness (feel) than the appearance (which has improved over time). So, if they look and work better, I won't complain. If you decide that there are more important battles to fight with the required effort, so be it. Another slant would be to ask what else you might do for Squeak if you left the menus alone? You might throw some ideas at us to see what resonates as needing work. That said, I am very grateful for your sharing your changes with us, and will happily go along for the ride. Does that help? Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> gazzaguru2(a)btinternet.com 11/19/07 11:49 AM >>> It will be a quite intrusive set of modifications... Currently, themed menus are available when using the Theme directly (or via the TEasilyThemed trait). This will be about some extensions to UIManager to indirect the creation of menus. Of course, the PSUIManager will use the theme support while the extensions will leave things open. _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

6 9

RE: [UI] Re: MenuMorph hand weirdness
by Bill Schwab 20 Nov '07

20 Nov '07

Gary, In terms of describing an interface, I immediately zoom out to the two ways one might approach it: graphical editing, and writing code. The nature of the GUI editor and the language are "just details." IMHO, both methods are essential for happy programmers. I have some GUI generating/translating tools that I would expect to port to whatever Smalltalk system I end up using; they speak MVP. If I land in Squeak, it will have an MVP framework, if only because I will write one out of frustration :) As I have mentioned before, I am concerned that any MVP work I do would be tainted with Object Arts' intellectual property. However, if I create a framework (tainted) and my own tests for it (by definition clean - right???), then the tests could be the basis for a clean MVP framework for Squeak. Any flaws? It is a lot of wasted work to write and then have someone else rewrite a framework, but it might solve the problem. At least the rewrite would occur with the benefit of tests. With some cleverness, Morphs as views, native widgets, SVG, etc., are hopefully just different types of views in the framework. As a practical matter, I have a few too many Squeak images for my own good. I need to archive them all, mine code out of them, and create one image that will move back and forth between Linux and Windows. Any thoughts on 3.9 vs. 3.10? For 3.9, I would want the delay/queue/semaphore fixes; IIRC, those are included in 3.10?? Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> gazzaguru2(a)btinternet.com 11/19/07 8:50 PM >>> Will try that as a (feel) start... As for other efforts, I'm game for it... Just the (maybe last) uncharted territory in themeability... ------- This was a question to gauge the importance of having menus themed as standard, in the general IDE sense... more of fixing what we have rather than the new big thing. In terms of "the new big thing" I think we have to become very much more focussed. That means really working together. Perhaps everyone could make a prototype system to demonstrate to us all... then work together with the best bits? As a start, we should be able to easily conform to any particular "look and feel"... take the Java abstraction classes as an example. We could also incorporate "native" (Win32/GTK) as part of the framework (different to the "emulated" Java). I'd really like anything we do to be non-exclusive and all-encompassing, both potentially attainable goals. Might sound a bit "bloaty" but a framework that can plug-and-play our concepts would be nice... I think it comes down to the way(s) you want to be able to describe a user-interface. Need to be able to express the intention of the ui in a flexible manner but, also, for some applications, have exact control (plus a lot of in-betweens). ToolBuilder does a lot of that, but is not yet rich enough to do the latter... There is no easy answer, however... yet. All speculation welcomed! > -----Original Message----- > From: ui-bounces(a)lists.squeakfoundation.org > [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Matthew > Fulmer > Sent: 19 November 2007 8:38 PM > To: ui(a)lists.squeakfoundation.org > Subject: [UI] Re: MenuMorph hand weirdness > > > On Mon, Nov 19, 2007 at 02:17:47PM -0500, Bill Schwab wrote: > > Gary, > > > > Obviously, it is your call. I will admit that Squeak's menus could use > > a face lift, but I am much more concerned about Morphic/hand weirdness > > (feel) than the appearance (which has improved over time). So, if they > > look and work better, I won't complain. If you decide that there are > > more important battles to fight with the required effort, so be it. > > I fixed the Menu hand weirdness in > http://bugs.squeak.org/view.php?id=6687 > > Load MenuMorph-BetterMouseHandling.2.cs. I don't know if this > should go in UI enhancements or base Morphic. I use this change > set in all my images (and can't live without it anymore). I > haven't tried to push it other than by announcing it here (on the > UI list) once before. > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ > Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808 > _______________________________________________ > UI mailing list > UI(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/ui _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

3 3

RE: [UI] Re: MenuMorph hand weirdness
by Bill Schwab 20 Nov '07

20 Nov '07

Gary, MVP indeed predates OA's work, but I have to walk a fine line of making something compatible and untainted. I do not think I can serve as a coder on a clean version. Tests I can write and distribute. As for you starting at the bottom and me at the top, that's perfect! You clearly have great skill at graphical coding, and have a lot of MVP work that can stress test my (non-existent, so far) MVP framework; I also have meta data->code translators that can push it. A design goal should be to allow the view hierarchy to change; OA anticipated that, and it makes sense to continue and extend it. If the effort succeeds, we can begin work on a clean room version knowing that success is possible. 3.9 it is. I am very pleased to see you also using processes. The first tangible system I would be likely to port is a serial communication multiplexer. It makes heavy use of streams[*], and arguably heavy use of processes. The latter is murky to me, as my earliest evaluations of Squeak included a reality check on the scheduler and synchronization; at the time people reported dwarfing my requirements without problems. The more recent "fix this or we switch to Java" discussions were unsettling, though you reported having improved results with the resulting patches. [*] I would very much like to put teeth into EndOfStream. I might even see how to do it. As I see it, silent truncation by #next: is an accident waiting to happen, and exception handling is the answer. The problem would be getting it accepted. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> gazzaguru2(a)btinternet.com 11/20/07 10:06 AM >>> > -----Original Message----- > From: ui-bounces(a)lists.squeakfoundation.org > [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Bill Schwab > Sent: 20 November 2007 2:44 PM > To: ui(a)lists.squeakfoundation.org > Subject: RE: [UI] Re: MenuMorph hand weirdness > > > Gary, > > In terms of describing an interface, I immediately zoom out to the two > ways one might approach it: graphical editing, and writing code. The > nature of the GUI editor and the language are "just details." IMHO, > both methods are essential for happy programmers. I have some GUI > generating/translating tools that I would expect to port to whatever > Smalltalk system I end up using; they speak MVP. If I land in Squeak, > it will have an MVP framework, if only because I will write one out of > frustration :) a concise (programmatic) construction framework would be nice as a basis for graphical tools. Code generation-reintegration is, IMHO, more flexible and explict than live prototypes. It is alway good to know that there is a basis for recreating a (specific) UI for a system. Similar to the concept of the image, good to know that it can (essentially) be regenerated if corruption problems occur. > > As I have mentioned before, I am concerned that any MVP work I do would > be tainted with Object Arts' intellectual property. However, if I > create a framework (tainted) and my own tests for it (by definition > clean - right???), then the tests could be the basis for a clean MVP > framework for Squeak. Any flaws? It is a lot of wasted work to write > and then have someone else rewrite a framework, but it might solve the > problem. At least the rewrite would occur with the benefit of tests. > MVP, as I remember, predates Dolphin in research terms... > With some cleverness, Morphs as views, native widgets, SVG, etc., are > hopefully just different types of views in the framework. > Indeed, though a mechanism (call it a theme or configuration perhaps) to bind a coherent set of things together will help. If things are cross-pluggable then it should be easy to mix-n-match to suit any need. > As a practical matter, I have a few too many Squeak images for my own > good. I need to archive them all, mine code out of them, and create one > image that will move back and forth between Linux and Windows. Any > thoughts on 3.9 vs. 3.10? For 3.9, I would want the > delay/queue/semaphore fixes; IIRC, those are included in 3.10?? > > Bill Since I'm currently working on deployment to customers I'll be sticking with 3.9 (fixes applied) for the moment. Others in the office are on the 3.10 dev beta images. Once our release is stable we'll migrate to 3.10 in the background, I don't forsee any real problems, not the right time to abandon 3.9 for our deliverables just yet. Found another process related bug i may have to air in the dev list. Looks like Process>>isTerminated is not thread safe/and/or correct. Have has instances where a live process has responded "true" to isTerminated, briefly! (we are using quite a few processes at various priorities - preemption bites!) For me, for a fresh start, I'd like to start at "the bottom", basic drawing/interation (Cairo/BitBlt/Balloon/GTK etc). Perhaps we can meet halfway... _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

2 1

Re: [UI] Compiler messages
by Bill Schwab 19 Nov '07

19 Nov '07

Colin, I respectfully disagree. Exceptions shine when a problem is detected (e.g. end of stream) in code that cannot be expected to know how to handle it. Exceptions both propagate the information to a level that can be expected to cope with it, and prevent silent failures by faulting if the exception is not handled. That is exactly what is required in my medical data parsing example. In the case of the compiler, it can (and I submit should) all be handled with messages to a context since the scenario is fairly focused. This is both a concern of mine (ensuring robust stream behavior in a critical and complex system) and something of a long-term agenda to avoid wasteful programming. Bloatware happens a few bytes and microseconds at a time. Again, in the compiler example, I agree with the plan, but see it as a clever way of compensating for configuration management deficiencies rather than being an appropriate technological choice. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029 >>> cputney(a)wiresong.ca 11/13/07 7:14 PM >>> On 13-Nov-07, at 2:47 PM, Bill Schwab wrote: > Agreed, with the caveat that I am currently thinking contexts are > preferred to exceptions in this case (for speed). Of course, that > would > require changing a LOT of code, where the exception solution can be > stealthy. Changing default actions is a worthy compromise. I will > take > a shot at it. Tim is right, speed is just not an issue here. Exceptions only get raised if the compiler is in "interactive" mode, as when invoked from a browser. In that case, compilation takes milliseconds, and adding a few microseconds doesn't matter. Further, if the exception handler interacts with the user, the time to raise an exception is dwarfed by the time spend waiting for the user to react. Colin _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

UI November 2007