UI September 2007

ui@lists.squeakfoundation.org

29 participants
102 discussions

Re: Squeak Roadmap ...
by Brad Fuller 20 Sep '07

20 Sep '07

On Wed September 19 2007, GeertC wrote: > Brad Fuller-2 wrote: > > Join our UI efforts in the UI mailing list! > > > > brad > > How come the "comp.lang.smalltalk.squeak.ui" is not on Nabble? i dunno. don't know how to do it. It's on gmane.

1 0

Re: [UI] Well, shall we do something then?
by Bill Schwab 19 Sep '07

19 Sep '07

Is the weak dictionary problem unique to Squeak? Dolphin seems to get along just fine with MVP. OTOH, what you describe could be a part of why I emulate for large grids, etc., or it could be a "SquWeakness" that needs attention. I use events with the emulated framework, but there is also some Years ago now, I made inquires about Squeak's process syncrhonization objects, and scaling of threads, and was regaled with stories of great victories over the dragons of software complexity ;) More recently, I am getting the sense that (e.g. "we almost had to rewrite in Java") some of this stuff is just plain broke. It is unclear whether it really is sound, or was sound and has since gotten into trouble, etc. Any ideas? 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 >>> lewis(a)mail.msen.com 09/19/07 6:46 AM >>> On Wed, Sep 19, 2007 at 12:38:44AM +0300, Igor Stasenko wrote: > On 18/09/2007, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: > > Well, there is the Model but there has to be a linkage for when the model > > changes. That's the basics. We need to decide on the way(s) we wish that to > > happen. I find changed/update rather inefficient. Much prefer when:send:to:. > > > > But that's just the start. Pretty fundamental though. > > > Yes! And i think this is the point where we should start from. > How to create flexible event system , how exchange data between view > and model. Based on that we then can build up a model which will use > it (MVP/Morphic whatever) A note of caution: The #when:send:to: mechanism can have serious performance issues due to its use of weak dictionaries. Performance of the entire image is seriously impacted by weak array finalization as the number of these dictionaries increases. There is no easy fix for this, so make sure you know what you are getting into before you start with an approach based on this mechanism. Dave _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

2 1

Re: [UI] Squeak's Menus
by Bill Schwab 19 Sep '07

19 Sep '07

Todd, Seconded, with two exceptions: (1) if you use Microsoft software, you *deserve* to have trouble<g>; (2) IMHO, menus should never[*] be picked up except via halos. The current behavior is very annoying, and even now, I can hear the screams from the real-world users. The tear-off-to-create-a-gui is fine, but it is a design-time consideration, hence my halo position. [*] I might soften that to almost never given a good argument. As it is, I see it as being such an infrequent task that I would gladly resort to a halo in order to the blasted things stop "sticking to the mouse" (as my users would describe it). 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 >>> tblanchard(a)mac.com 09/19/07 2:43 AM >>> Well that's your opinion, of course. But about 50% of the time my interaction with the thing results in the menu being picked up by the hand. Which is never what I want. And so, my experience is that they are frustrating to work with. I find that significantly annoying. Much like I find the characterization of my opinion of the experience as "plain wrong". >:-P No other menu I have ever worked with has ever exhibited such an odd magnetic attraction to the mouse pointer while consistently thwarting my intent to invoke an action. The only other UI element comparably frustrating in my experience is the endlessly tearoff-able, moveable toolbars in Microsoft apps like Outlook - wherein I am constantly inadvertently tearing off, or collapsing, or expanding, or rearranging tool bars by accident. I suspect that the problem could be alleviated by only allowing menus to be picked up by the hand if the mouse is properly in the title item. Just wanted to clear that up. :-) On Sep 18, 2007, at 2:53 PM, Chris Muller wrote: > Squeak's menus are anything but "awful." Specifically, they support > the keyboard and not just a modifier+hot-key (a la MS Windows menus). > The usefulness of this is especially evidenced with > World>>open...>>file... Just type away instead of "hunt-and-click". > > Squeak menus entry's can be tacked in place, and even invdividual menu > items can be torn off (use the duplicate halo) and placed anywhere on > the desktop or on a flap; thus building-up your own little custom IDE. > They can even be turned sideways for special cases. > > Your complaint seemed pretty insignificant to me, so I felt the > subject language of this thread was more than overly critical; more > like plain wrong. > > > On 9/13/07, Todd Blanchard <tblanchard(a)mac.com> wrote: >> Specifically, they open to the right of the mouse. If you open a >> menu, don't move the mouse, and click, you will pick up the menu with >> the hand. This happens to me - oh - about 50% of the time. Either >> open the menu under the mouse, or make it so I can't pick it up >> except with the title bar. >> >> Just did this for the nth time today and had to vent. >> >> -Todd Blanchard >> _______________________________________________ >> 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

Improving ToolBuilder
by Damien Cassou 18 Sep '07

18 Sep '07

Hi, I've just tried to replace part of OB-Morphic (the framework to build OmniBrowser interfaces using Morphic) by UIManager. It worked for: OBMorphicPlatform>>handleChoiceRequest: request | choice | choice := (PopUpMenu labelArray: request labels lines: request lines) startUpWithCaption: request prompt. ^ request values at: choice ifAbsent: [nil] I replace it by: OBMorphicPlatform>>handleChoiceRequest: request ^ UIManager default chooseFrom: request labels values: request values lines: request lines title: (request prompt ifNil: ['']) But how can I change OBMorphicPlatform>>handleConfirmationRequest: request ^ PopUpMenu confirm: request prompt trueChoice: request okChoice falseChoice: request cancelChoice There is no such method in UIManager. And this one: OBMorphicPlatform>>handleTextRequest: request ^ FillInTheBlankMorph request: request prompt initialAnswer: request template centerAt: Sensor cursorPoint inWorld: World onCancelReturn: nil acceptOnCR: true There is no way of returning nil on Cancel. The empty string is always returned. -- Damien Cassou

2 5

Re: [UI] Well, shall we do something then?
by Bill Schwab 17 Sep '07

17 Sep '07

Dave, Thanks. A related thought is the following: use critical sections early and often. Deadlocks are (in my experience at least) generally easy to resolve from a dump of callstacks. All but one thread will be waiting on a semaphore of some type; then look for the ones you created, and look for the critical sections to see if you are making it impossible for the code to run. Common fixes involve (carefully!) splitting one critical section into pieces, adding a shared queue to move objects from source to sink thread, etc. When interacting with the GUI, post an action to the input queue vs. making the calls directly from the worker thread. 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 >>> lewis(a)mail.msen.com 09/17/07 7:33 AM >>> On Sun, Sep 16, 2007 at 10:51:51PM -0400, Bill Schwab wrote: > Another thing to consider is that user interfaces tend to like > changes to be injected on their main thread. I forget the name of > Squeak's notion of a "deferred action," but I can find it later if there > is a need - I suspect you or one of our peers will be able to provide > the relevant selector name. My primary contribution is to ask whether > you have considered it. I tend to queue GUI updates whether they need > it or not ;) The selector is WorldState class>>addDeferredUIMessage: See also http://bugs.squeak.org/view.php?id=1578 if MVC consistency is if interest. Dave _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

2 1

RE: [UI] Squeak's Menus Are Awful
by Bill Schwab 17 Sep '07

17 Sep '07

Sounds great! 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 9/14/2007 2:28 PM >>> Sounds fair. There are still a lot of direct users of PopupMenu in the image (ST-80 based), grim. Perhaps they should be changed to go via the UIManager and/or theme and use a MenuMorph. (even confirm: in the standard MorphicUIManager uses PopupMenu rather than a MenuMorph). Then fix/modify MenuMorph to have the behaviour we require (or subclass it and direct it from the active UIManager). I could adapt the technique I used for a DropList's list to make surethe menu gets deleted when a click occurs beyond its bounds. > -----Original Message----- > From: ui-bounces(a)lists.squeakfoundation.org > [mailto:ui-bounces@lists.squeakfoundation.org] On Behalf Of > Jason Johnson > Sent: 14 September 2007 5:51 pm > To: Squeak's User Interface > Subject: Re: [UI] Squeak's Menus Are Awful > > > Sounds like you have a handle on it to me. :) > > On 9/14/07, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > > Gang, > > > > Now that I have filtered this list into its own folder, I have > > remember to **look at it** ~:0 > > > > How about this as a compromise: menus that are worthy of > being left in > > place (not many IMHO - they should instead be separate > system windows) > > should have a title bar and be draggable by that; other > menus should > > be sufficiently modal that it is not a consideration. > > > > Squeak has long (ab)used menus in situations where more > complex views > > were appropriate. Look at the file picking menus: one gets > a chain of > > menus vs. a dialog. Note that there are dialogs, but there > are also > > hideous menus. > > > > 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 09/13/07 7:00 PM >>> > > I think you should be "able" to pick up the menus, just via halo > > though, to move them out of the way. Not by a default click/drag. > > > > > > > -----Original Message----- > > > From: ui-bounces(a)lists.squeakfoundation.org > > > [mailto:ui-bounces@lists.squeakfoundation.org] On Behalf Of tim > > > Rowledge > > > Sent: 13 September 2007 11:55 pm > > > To: Squeak's User Interface > > > Subject: Re: [UI] Squeak's Menus Are Awful > > > > > > > > > > > > On 13-Sep-07, at 3:18 PM, Todd Blanchard wrote: > > > > > > > Specifically, they open to the right of the mouse. > > > There's a good reason for that; if you click the mouse button you > > > get a button-down followed by a button-up. If the menu > opened under > > > the mouse location you would have accidentally picked > whatever item > > > was in the right place. Delete all files, anyone? > > > > > > It's particularly likely to be annoying when the menus > are slow to > > > dispaly, which they certainly seem to be in recent Squeak images. > > > Now venting about Morphic performance in 3.9 is something worth > > > doing. Dismal. And I'm running on a 2GHz dualcore OSX > machine with > > > 2Gb ram, not exactly a slow system. > > > > > > > If you open a menu, don't move the mouse, and click, you will > > > > pick up the menu with the hand. This happens to me - > oh - about > > > > 50% of the time. Either open the menu under the mouse, > or make it > > > > so I can't pick it up except with the title bar. > > > Do the latter for the reasons mentioned above. Being able > to pick up > > > a menu at any point is insane. > > > > > > > > > tim > > > -- > > > tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim Press > > > [ESC] to detonate or any other key to explode. > > > > > > > > > _______________________________________________ > > > 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 > > > _______________________________________________ > 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] Well, shall we do something then?
by Bill Schwab 17 Sep '07

17 Sep '07

Have you looked at Dolphin's layout managers? If not, you might want to grab the free version and play around in the view composer for a while. FramingLayout is not particularly easy to use, but that can be fixed with helper methods and good tools. 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 >>> hmm(a)heeg.de 09/17/07 1:34 AM >>> tim Rowledge schrieb: > > On 16-Sep-07, at 2:32 PM, Hans-Martin Mosner wrote: > >> >> CSS allows for some pretty decent layout, and maybe using it as the >> method for specifying GUI layouts would lead to some synergy effects >> between web GUI and screen GUI developments. > We've been using some CSS for UI layout in Sophie. Seems to work > reasonably but decent integration would be useful. Having text files > sitting around is not a good solution in my mind. That's right, I was more interested in the functionality of style sheets than in the actual syntactic representation used in CSS files. What I am contemplating is a kind of "smalltalkization" of CSS such that a style sheet can be written as a method with ordinary message sends, somewhat analogous to the way HTML or window parts are specified in seaside and ToolBuilder, respectively. Parsing actual CSS files can be useful, too, but should not be the main mechanism for handling GUI layout CSS. Cheers, Hans-Martin _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

1 0

Re: [UI] Well, shall we do something then?
by Bill Schwab 17 Sep '07

17 Sep '07

Todd, Either I have been very, VERY lucky, or I have made some level of peace with Smalltalk Processes. A shared queue between a couple of threads _should_ be ok. Did you see the relatively recent messages surrounding Delay, etc. fixes for Squeak? I found the whole thing somewhat unsettling, to say the least - still do. Your problem might be that the shared queue does not work??? Checking for patches might be a worthy effort. Another thing to consider is that user interfaces tend to like changes to be injected on their main thread. I forget the name of Squeak's notion of a "deferred action," but I can find it later if there is a need - I suspect you or one of our peers will be able to provide the relevant selector name. My primary contribution is to ask whether you have considered it. I tend to queue GUI updates whether they need it or not ;) 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 >>> tblanchard(a)mac.com 09/16/07 10:31 PM >>> On Sep 16, 2007, at 2:12 PM, tim Rowledge wrote: > Costumes are in my opinion one of the more useful parts of the > tweak design. You an change the look by changing the costume. Perhaps - but when wanting to make a custom control - it gets unclear (to me anyway) whether one should subclass one or both of the player/ class pair. This is the bit I expect people to get wrong often. An example is the multi-column Mac OS X file browser - I sat down to try to make one of these a couple different times and never really got anywhere as I kept going around and around on whether I should just keep the existing file chooser player, but make a new costume, or make a new player to go along with it. Having once built an event based system that relied on a pair of threads separated by a queue - I can see how debugging things can be a pain as you don't have that nice stack to figure out just how you got here. -Todd Blanchard

2 1

Re: [UI] Well, shall we do something then?
by Bill Schwab 17 Sep '07

17 Sep '07

Hans-Martin, Have you looked at Magritte? I do not know enough about it to vouch for it, but it seems a worthy effort (and I would expect no less given Stef's involvement). Re generating, I have done some work on it in Dolphin. If you grab my Dolphin Goodies, you will find a package called ViewGeneratorBase, or something like that. It is the basis for some meta-driven generators that I use. Some of the technology will likely remain closed, but on a rewrite/port, there are additional parts that I would hope to open. Something that does not yet exist, but would if I move to Squeak, is a converter for Dolphin views. It should be possible to do something similar to analyze the hierarchy of a live view, but I suspect it would always be preferable to go back to a builder that created the view and modify it directly. OTOH, I have some things that analyze existing structures and generate a builder that I then maintain after the initial import, and that works well. WindowBuilder was very good at analyzing existing views. If its sources are now open(??), it might be worth some time to see if it did anything beyond generating code from the views. For layout, I really like the managers that Dolphin provides. The only exception being that FramingLayout is a little cumbersome to use. To get around that, I wrote a package called Wizardry that includes an IDE extension for the Dolphin view composer. It adds commands for positioning a panel over a fixed-size row of buttons that are positioned from the left and from the right, depending on the command. More and better things could be done, of course. 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 >>> hmm(a)heeg.de 09/16/07 5:32 PM >>> After playing a little with seaside and its HTML rendering mechanism (which has some similarities to ToolBuilder's) I can imagine a combination of these things: 1. A way of specifying a GUI programmatically somewhat more similar to the HTML rendering in seaside (i.e. more concise, better structural nesting). Let's call it ToolBuilderToo since it would really be a slightly imrpoved ToolBuilder. 2. A mechanism for creating such "buildWith:" methods from existing GUIs which may have either been created using a kind of GUI painter, or are real live GUIs. For example, taking a live browser window, adding a button with some function, and storing its specification would be nice. Of course, it's entirely reasonable if this is only supported in one or two ToolBuilderToo targets, such as Morphic and Tweak for example. 3. A more powerful layout mechanism - GUIs built with ToolBuilder are pretty limited since it needs to cope with MVC's viewport/window transformation ugliness which essentially forces the GUI to have only proportionally scaled panes. I know that I have struggled with MVC and fixed-height panes ever since I first touched a Smalltalk-80 system 20 years ago, so this might not be easy. 4. (maybe in combination with 3) Something like cascading style sheets for specifying different layouts and colorings for GUIs. Maybe it would even be possible to specify GUI themes using some kind of CSS? CSS allows for some pretty decent layout, and maybe using it as the method for specifying GUI layouts would lead to some synergy effects between web GUI and screen GUI developments. Cheers, Hans-Martin _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

1 0

Re: [UI] Well, shall we do something then?
by Bill Schwab 17 Sep '07

17 Sep '07

Tim, Hans-Martin, I _think_ I would favor working with objects and rendering to the various targets, allowing builders to do the right thing for each target. 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 >>> tim(a)rowledge.org 09/16/07 7:15 PM >>> On 16-Sep-07, at 2:32 PM, Hans-Martin Mosner wrote: > > CSS allows for some pretty decent layout, and maybe using it as the > method for specifying GUI layouts would lead to some synergy effects > between web GUI and screen GUI developments. We've been using some CSS for UI layout in Sophie. Seems to work reasonably but decent integration would be useful. Having text files sitting around is not a good solution in my mind. tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim Useful random insult:- If he were any more stupid, he'd have to be watered twice a week. _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

UI September 2007