UI January 2008

ui@lists.squeakfoundation.org

9 participants
14 discussions

Re: [UI] Re: Promoting Squeak/Smalltalk
by Bill Schwab 31 Jan '08

31 Jan '08

Andreas, Some random thoughts: The standard (and not altogether unreasonable) answer to "no support for x on y" is "Want FFI on Solaris? Write it." You are correct in pointing out the deficiencies; "they" are correct in pointing out that "we" could help more. Sadly, I suspect many would help more if help were more aggressively accepted. I accept some blame for failing to make it easier to write certain apps. I really should put an MVP wrapper around some of the morphic chaos. Various things have distracted me, including learning more about Linux - Squeak is of dubious value to me if I stay on Windows, hence the diversion. Ubuntu installs quite easily, though an upgrade to 7.10 fried my VPN (getting to be a pain) and added/revealed some largely cosmetic bugs. I also want to get craftier with shell scripts. I am starting to think fondly of "reinstall, run custom script, return to find re-configured machine." Come to think of it, I want the same thing for Squeak, getting the latest version of various things (Gary's work being high on the list) w/o having to click and wait my way through a GUI. No lack of gratitude implied; the GUIs are great, but sometimes a script is the better way to go. I also looked at ST/X, and found pretty much what you did. It has strong supporters, but early experiments left me concerned that it would fail a lot too easily for my taste and needs. Re Squeak's GUI speed, have you tried some older versions? IIRC, Squeak took a real speed hit somewhere around 3.8 or 3.9???? That's not to say "downgrade or suck it up," but I _am_ curious if older versions are faster. One nice thing about slow platforms is that slow code crawls all the more on them. To add a concern to your list, what about incompatibilities with other dialects? To continue my rant about streams, 'hello' at:200 raises an error, but 'hello' readStream next:200 truncates. Hmmmm. Dolphin and VW get this one right. Nile includes some beginning efforts to rewrite some methods to use its streams, but to really fix it (I think) requires a breaking change. I am tempted to turn the RB loose to turn #next into #nextOrNil and #next into #nextAvailable: (there might be others I have yet to recognize), and then begin work in the new image after adding some methods and/or switching to Nile. Add confusion over that to my list of reasons/excuses for delay in MVP ;) Humor aside, it *is* a concern to me. So, what are we going to do to fix all of this stuff? 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 01/30/08 4:20 PM >>> The following is from a different subject but I find it more appropriate for the "Promote Squeak/Smalltalk" thread: Bill Schwab schrieb: > Lukas, > > Gary provided the authoritative answer, to which I will add that a stray > method to set the various preferences might be helpful. We will all > have our own variants, but it is getting hard to tell which options are > not truly independent. FWIW, it is a great problem to have. > > As far as keyboard focus being off topic: it is **ON TOPIC**. I wish > you guys could have heard Aileen type. Failing that, watch a clerk who > has learned how to work without a mouse (and hates having to stop to > touch it) pound on a keyboard. We should be able to meet their > expectations. > > Meeting expectations is a good catchword. And to make a long story short: Squeak is often advertised as being "multi platform" and having a decent class library. In my experience the reality is different: Windows is supported best, followed by Mac and Linux x86. Every other platform has more or less problems: - On Solaris (x86 and SPARC): FFI is not supported and thus no depending packages like ODBC (so no generic database connectivity). - Are there any actual VMs and images for ARM, MIPS or something similar? - What about Linux on non-Intel? Another, often discussed problem area for Squeak is its not standard conforming GUI. It may be that Morphic is in many areas superior to most other GUI frameworks. Nevertheless it is very difficult and annoying to create GUIs for standard business applications (eg. the aforementioned bank account SW). Code quality and documentation is another major concern. There is a lot of brilliant code in the Squeak base. But there is also a lot of mess in it. And you can be sure that most experienced programmers will find many more occurrences of mess than brilliant code. At least the mess is more likely to be remembered. Furthermore it is quite easy to find problems and annoyances in the tools of a standard image. (BTW I have similar experiences with ST/X. It takes only a few minutes to find MNUs in the standard tools.) Did I mention that Squeak is sometimes painfully slow on my Sun Blade 2000 (equipped with two US-III+ processors and 8GB RAM)? This has two causes: gcc produces slow code for SPARC (and Sun C and its tool chain is not quite supported) and Morphic (or at least most of Squeak's GUI) is painfully slow. Regards Andreas _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

2 1

Re: [UI] Fwd: OBSystemBrowser vs. Browser
by Bill Schwab 30 Jan '08

30 Jan '08

Lukas, Gary provided the authoritative answer, to which I will add that a stray method to set the various preferences might be helpful. We will all have our own variants, but it is getting hard to tell which options are not truly independent. FWIW, it is a great problem to have. As far as keyboard focus being off topic: it is **ON TOPIC**. I wish you guys could have heard Aileen type. Failing that, watch a clerk who has learned how to work without a mouse (and hates having to stop to touch it) pound on a keyboard. We should be able to meet their expectations. 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 >>> renggli(a)gmail.com 01/30/08 7:52 AM >>> > Of course, the context menu for taskbar buttons is only available if the existing "generalizedYellowButtonMenu" preference is switched off (don't ask why!). > As for window switching, alt-leftArrow/alt-rightArrow was the only combination I could find that wouldn't conflict with (mostly text) morphs and the host OS. > > All described here http://wiki.squeak.org/squeak/6005 This is really cool. Thanks for the pointers. Even if this is getting more and more off-topic, what would it take to get the focus detached from the mouse? Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

3 3

RE: [UI] Mouse wheel
by Bill Schwab 30 Jan '08

30 Jan '08

Gary, I will try it later today. Thanks! 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 01/28/08 11:42 AM >>> Load Pinesoft-Widgets-gvc.284 from SqueakSource and enjoy! Was tricky to figure out but done nicely, I think. If the VMs get arround to generating mouse wheel events natively (rrather than simulating with a keystroke) it is a small matter to support that when/if that happens. Will await feedback before updating the Universe. Regards, Gary. > -----Original Message----- > From: ui-bounces(a)lists.squeakfoundation.org > [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Bill Schwab > Sent: 22 January 2008 3:21 AM > To: ui(a)lists.squeakfoundation.org > Subject: Re: [UI] Mouse wheel > > > Gary, > > It is not terribly high on my priority list, but the more I work with > Squeak, the more I notice that the way other apps handle the wheel makes > a LOT of sense. Given a choice, I would opt for solid keyboard focus > every time. > > Thanks! > > 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 01/21/08 6:27 PM >>> > I've looked at that, would be nice! Unfortunately, in Squeak, the mouse > wheel is simulated as keyboard events. It would require some hacking to > pick these up and send to the mouse focus instead. If there is > sufficient interest I'll take a stab at it. > > Thanks. Gary. > > ----- Original message ----- > From: Bill Schwab <BSchwab(a)anest.ufl.edu> > To: <ui(a)lists.squeakfoundation.org> > Sent: Mon, 21 Jan 2008, 20:45:13 GMT > Subject: [UI] Mouse wheel > Gary, > > I hope this is not a repeat, or worse yet reflective of my not having > installed a new enough release, but _almost_ as much as I think keyboard > focus should be managed very carefully and independent of the mouse > cursor location, I think the mouse wheel input should follow the mouse > cursor, even so far as scrolling panes that are not active, and not even > part of the active shell. First, I just noticed Ubuntu, its graphical > terminal, and OpenOffice do this to good effect (as just one example); > second, if I am typing, mouse movement is probably made to avoid visual > distraction from the cursor, if I am turning the mouse wheel, it is > almost certainly a deliberate action associated with the cursor > location. Fair? > > 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 > > _______________________________________________ > 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

Fwd: OBSystemBrowser vs. Browser
by Damien Cassou 30 Jan '08

30 Jan '08

---------- Forwarded message ---------- From: Lukas Renggli <renggli(a)gmail.com> Date: Jan 30, 2008 11:58 AM Subject: Re: OBSystemBrowser vs. Browser To: OmniBrowser developers <ob-dev(a)wiresong.ca> > Do you refer to a task bar like the ones in Windows, KDE or Gnome? If > yes, then this task bar exists and is activated by default in all > squeak-dev beta images (ftp://ftp.ofset.org/squeak/squeak-dev/beta). I tried the TaskBar in your image, this is a really cool extension for Squeak. What is missing is an X, to be able to close the window right from the task bar. Also some keybindings would be nice to switch to the next window. -- Damien Cassou

3 3

Re: [UI] Mouse wheel
by Bill Schwab 28 Jan '08

28 Jan '08

Gary, It is not terribly high on my priority list, but the more I work with Squeak, the more I notice that the way other apps handle the wheel makes a LOT of sense. Given a choice, I would opt for solid keyboard focus every time. Thanks! 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 01/21/08 6:27 PM >>> I've looked at that, would be nice! Unfortunately, in Squeak, the mouse wheel is simulated as keyboard events. It would require some hacking to pick these up and send to the mouse focus instead. If there is sufficient interest I'll take a stab at it. Thanks. Gary. ----- Original message ----- From: Bill Schwab <BSchwab(a)anest.ufl.edu> To: <ui(a)lists.squeakfoundation.org> Sent: Mon, 21 Jan 2008, 20:45:13 GMT Subject: [UI] Mouse wheel Gary, I hope this is not a repeat, or worse yet reflective of my not having installed a new enough release, but _almost_ as much as I think keyboard focus should be managed very carefully and independent of the mouse cursor location, I think the mouse wheel input should follow the mouse cursor, even so far as scrolling panes that are not active, and not even part of the active shell. First, I just noticed Ubuntu, its graphical terminal, and OpenOffice do this to good effect (as just one example); second, if I am typing, mouse movement is probably made to avoid visual distraction from the cursor, if I am turning the mouse wheel, it is almost certainly a deliberate action associated with the cursor location. Fair? 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 _______________________________________________ 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

2 1

Re: [UI] Mouse wheel
by Gary Chambers 22 Jan '08

22 Jan '08

I've looked at that, would be nice! Unfortunately, in Squeak, the mouse wheel is simulated as keyboard events. It would require some hacking to pick these up and send to the mouse focus instead. If there is sufficient interest I'll take a stab at it. Thanks. Gary. ----- Original message ----- From: Bill Schwab <BSchwab(a)anest.ufl.edu> To: <ui(a)lists.squeakfoundation.org> Sent: Mon, 21 Jan 2008, 20:45:13 GMT Subject: [UI] Mouse wheel Gary, I hope this is not a repeat, or worse yet reflective of my not having installed a new enough release, but _almost_ as much as I think keyboard focus should be managed very carefully and independent of the mouse cursor location, I think the mouse wheel input should follow the mouse cursor, even so far as scrolling panes that are not active, and not even part of the active shell. First, I just noticed Ubuntu, its graphical terminal, and OpenOffice do this to good effect (as just one example); second, if I am typing, mouse movement is probably made to avoid visual distraction from the cursor, if I am turning the mouse wheel, it is almost certainly a deliberate action associated with the cursor location. Fair? 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 _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

1 0

Mouse wheel
by Bill Schwab 21 Jan '08

21 Jan '08

Gary, I hope this is not a repeat, or worse yet reflective of my not having installed a new enough release, but _almost_ as much as I think keyboard focus should be managed very carefully and independent of the mouse cursor location, I think the mouse wheel input should follow the mouse cursor, even so far as scrolling panes that are not active, and not even part of the active shell. First, I just noticed Ubuntu, its graphical terminal, and OpenOffice do this to good effect (as just one example); second, if I am typing, mouse movement is probably made to avoid visual distraction from the cursor, if I am turning the mouse wheel, it is almost certainly a deliberate action associated with the cursor location. Fair? 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

OLPC review
by Bill Schwab 20 Jan '08

20 Jan '08

Hello all, You might find this interesting: http://www.reghardware.co.uk/2008/01/17/review_xo_laptop_hands_on/print.html The hardware problems and hobbled features as described are disappointing to say the least. Those aside, the hardest landing punch is probably as follows: "Most of these changes come down to the OLPC organisation placing more emphasis on real-world usability and less on their ideals of a perfect interface. If they can manage to do this, the XO laptop could be a great tool for learning and play." 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

Re: [UI] C# methodologies
by Bill Schwab 16 Jan '08

16 Jan '08

Jason, Morphic's API certainly leaves room for improvement. My main interest in it is that it works and can get us to whatever we decide to do next. Given that, it seems reasonable to consider it as one of our view hierarchies of interest. The more you describe what you want to do, the more I think about WindowBuilder. I appears to be alive and well via Instantiations and VA, but it should also live in Smalltalk Express. If we can get that to run, you will quickly get an idea of what it can do. The following might work (subject to AV checks, etc.): http://www.smalltalk.org/versions/SmalltalkExpress.html The patches probably refer to some changes to get it to run on "high" color depth video systems (aka, almost anything in use now<g>). The "other" Dolphin-based generator I mentioned can be found here: http://www.cjd77.com/smalltalk/PresenterGenTool.htm I share your surprise at the way the rest of the world writes software. I could draw political analogies for it, but suffice it to say that I doubt the situation will change much. All of us found Smalltalk, and others will too, provided dialects continue to exist and remain viable. 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 01/15/08 1:11 PM >>> On Jan 14, 2008 9:23 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Jason, > > I probably did misunderstand you. Dolphin's ViewComposer does some of > what you describe, but I suspect that Object Arts would be the first to > agree that it could be done better. It might be interesting to look at > WindowBuilder (if we can find a copy of Smalltalk Express or something > else that has it and then get it to run), Dolphin Community Edition, and > Squeak/Morphic. I'm still go looking for documentation on Morphic from time to time to try to figure out what the advantage is. So far my impression is that it was a good idea from Self that just doesn't translate well to Smalltalk. And it sounds like the API is terrible. > I think the correct solution merges a code generator > with a visual editor, the nature of which might change with the views > (e.g. Morphic, wx, etc.). I have long done the code and view generator > in a "batch" mode to generate GUIs based on various meta data sources. At this point I'm not so big on generating views from "batch" mode, but the system I envision would be in pure Smalltalk so it wouldn't know or differentiate between receiving messages from code or from a designer application. I certainly wouldn't go out of my way to stop people from doing something they want to do. > There is a Dolphin solution that approaches it from the view, IIRC, > generating code to match it. I should dig around for it and add it to > our list of examples. Throw anything else you want in with it, stir, > and plan a GUI editor. Is that closer? Well, that's probably further then I had thought about at this point. I just noticed the C# ability to let one go very far in application development purely in the visual builder and think that would be nice to have in Smalltalk. Of course there are times one needs extreme flexibility in building a system but the vast majority of applications don't require nearly that much work. When I look at the free software world around us one thing that sticks out to me is that these guys who do this in their precious spare time are writing their graphical applications in C (!!!). Why is that? Why wouldn't one use Smalltalk to slap together a GUI in a day? I want to change that. I want to make a graphical building system that lets one build GUIs so fast that nearly everything in use on Linux could be duplicated in such a short time that the productivity can't be ignored. The Smalltalk and Lisp communities always talk about how much more productive we are (and I believe that), but we're not showing it. >BTW, just because I advocate > against volatile changes to the language, please do not feel like we > have to stick to ST-80. I would very much like to see Squeak more fully > embrace exception handling, as well as provide shortcuts to avoid the > overhead (such as using #at:ifAbsent: vs. having to catch errors from > #at:). I really like #ifAbsent: and use that pattern in my own code. By "stock ST-80" I just meant not adding any language extensions. The libraries need to always be advancing. For example, Smalltalk has resumable exceptions. Having known about them from Lisp I thought that was good that they have them. But when one looks at how they look when used it leads to some pretty ugly hard to understand code. One thing I would like to explore at some point is adding Lisp-style restarts to Smalltalk so this would not only look better but be (imo) state of the art. > Squeak does it in some places and not others. If you want to > call that "Smalltalk 95" or so, I'd let you get away with it. Dolphin > and VW do some related things quite wel, and IMHO, Squeak should "learn" > from them. Agreed. _______________________________________________ UI mailing list UI(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui

2 1

Re: [UI] C# methodologies
by Bill Schwab 15 Jan '08

15 Jan '08

Jason, I probably did misunderstand you. Dolphin's ViewComposer does some of what you describe, but I suspect that Object Arts would be the first to agree that it could be done better. It might be interesting to look at WindowBuilder (if we can find a copy of Smalltalk Express or something else that has it and then get it to run), Dolphin Community Edition, and Squeak/Morphic. I think the correct solution merges a code generator with a visual editor, the nature of which might change with the views (e.g. Morphic, wx, etc.). I have long done the code and view generator in a "batch" mode to generate GUIs based on various meta data sources. There is a Dolphin solution that approaches it from the view, IIRC, generating code to match it. I should dig around for it and add it to our list of examples. Throw anything else you want in with it, stir, and plan a GUI editor. Is that closer? BTW, just because I advocate against volatile changes to the language, please do not feel like we have to stick to ST-80. I would very much like to see Squeak more fully embrace exception handling, as well as provide shortcuts to avoid the overhead (such as using #at:ifAbsent: vs. having to catch errors from #at:). Squeak does it in some places and not others. If you want to call that "Smalltalk 95" or so, I'd let you get away with it. Dolphin and VW do some related things quite wel, and IMHO, Squeak should "learn" from them. More in a bit - gotta run. 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

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

UI January 2008