Squeak-dev March 2010

squeak-dev@lists.squeakfoundation.org

158 participants
767 discussions

My UI principles was: (Re: [squeak-dev] Re: Simple Frame Adornments - default value...)
by Chris Muller 04 Mar '10

04 Mar '10

I think Preferences are a good tool for reconciliation of our UI differences. However, another good tool is if we can establish a constructive dialogue about UI. Such a dialogue could perhaps occasionally spare us a new preference in favor of a slightly more cohesive result, because it was a solution that was good enough for the overwhelming majority. Let's talk about it! Of course preferences are great because they allow our users to heavily customize the system.. I hope, my having gone through Maui and forced myself through dozens of painstaking design and usability choices, at least illustrates my own _interest_ in this subject. I'm interested, in talking about these ideas with those interested in making Squeak look drop-dead gorgeous not just on the surface, but in the details too. Understanding each others' core-UI principles I think would be very helpful in establishing a constructive dialog. Here are mine: 1) That, at least the a software dev-environment (which is about what we're talking about), that this software, Squeak, expects users to have Basic Computer-Literacy before attempting to use Squeak. "Basic Computer Literacy" is defined as: - Use of the keyboard, including the Enter or Return key, arrow keys, page/home/end. - Use of the mouse as a pointing device. - Use of the (red/left/primary) mouse button as a means to "select" or "activate". - Use of the (yellow/right/alternate) mouse button, and understanding that is how to ask an object for options or information. 2) A user with Basic Computer Literacy, will be able to, at least, _discover_ how to operate a system with merely those skills. If the system requires further skills, it should be discoverable via help or guidance-elements accessed only with BCL. Typically, users learn about UI-elements not already obvious to them by yellow-clicking for interrogation and discovery. 3) Humans direct, software responds. Software should take care not to interrupt human. Software should no't ask "are you sure?", instead, provide undo. 4) Ensuring not to break rule 2, give the user the most powerful gestures possible to efficiently operate the software. This typically means: - minimize the demands of the users fine motor-skill (i.e., small-area left-clicking) - employ high-traction strategies, such as the power of pointing - good keyboard support is almost always, really necessary. That's it, those are my UI principles. If software requires user to be "frantic" to go fast, then it does not provide enough power-per-gesture. The principles I heard from rado are: - favors practicality over aesthetic - that the machine should make it easy on him, not force his eyes to "search for the corner" to see the status (and not forgetting, there may be several dirty windows with their corner exposed) I understand these. The principles from Igor are: 1. friendly for newcomers 2. convenient for citizens. however, I am not sure what he meant by "friendly" and "convenient". Igor, I am very interested in your ideas in a constructive dialogue.. - Chris On Wed, Mar 3, 2010 at 5:56 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 4 March 2010 01:21, radoslav hodnicak <rh(a)4096.sk> wrote: >> >> I do not care whether a feature is ugly as long as it's practical and making >> it less ugly means making it less practical. I also do not care if a feature >> is counterintuitive to newcomers, if making it less counterintuitive means >> making it less practical too. >> > > Practical is to use cell phone for calls. This means that your iPhone > is not much more practical than > 10-year old cell phone with tiny monochrome display. So, why people buying it? > I know people who still prefer using a unix command line and feel very > distracted, when they need to switch to graphic mode to look something > on the web. But let us be realistic: user interface is User Interface, > meant for humans, not for robots which doesn't have any sense of > aestetics or any use of good look and feel. > A good UI is one which is > 1. friendly for newcomers > 2. convenient for citizens. > > remove either of above, and you don't have good UI. You will have crap. > We should always care about both of these. > > Just my 2 cents.. > >> Sure a red frame is not very pretty aesthetically speaking (although I'd be >> hard pressed to rate an orange rectangle in the corner as a dramatic >> improvement), but it provides a very clear visual clue that is accessible >> *immediately*, without focusing on a window corner with my eyes. >> >> Substance > Style >> >> That said, as long as it's a preference, I don't mind what the default value >> is. >> >> I'd like to ask all folks messing with the user interface to always add >> preferences for the the changes you do - in other words: add features and >> keep the old ones. Don't replace. I'm open to trying out new things and see >> if they speed up my workflow, but chances are they won't. >> >> rado >> >> >> On Thu, 4 Mar 2010, Igor Stasenko wrote: >> >>> Chris, >>> i add -1 to red outline too. This is a counterintuitive and ugly. >>> I still remember when i first opened squeak and i were unable to >>> figure out what this red herring means. :) >>> >>> On 4 March 2010 00:22, Chris Muller <asqueaker(a)gmail.com> wrote: >>>> >>>> Ok, thanks for speaking up, I just didn't know whether there was any >>>> voice at all for the new look. >>>> >>>> And please don't get me wrong, I am *all for* better form. And I even >>>> agree, this one "looks" better, artistically. It's just that some of >>>> the 3.11 improvements to form have come at a cost to function, and >>>> THAT, in itself, can sometimes detracts from form somewhat (i.e., >>>> greater function has implicitly better form). Perhaps we considered >>>> making the ugly solid-line red-frame simply look better, like with >>>> three progressively-more translucent rectangles, each inset one pixel >>>> of the outer? Or maybe a combination of the two looks, one >>>> (translucent?) line combined with the new (corner) look. >>>> >>>> Since your -1 is big and fat, I consider it the winner of the vote and >>>> I'll adjust my own Preference file accordingly. Going forward, if we >>>> can find ways to have our cake and eat it too, it would be better than >>>> having introduce a yet another Preference that forces one to choose >>>> between form and function. >>>> >>>> - Chris >>>> >>>> >>>> On Wed, Mar 3, 2010 at 3:49 PM, Andreas Raab <andreas.raab(a)gmx.de> wrote: >>>>> >>>>> On 3/3/2010 12:40 PM, Chris Muller wrote: >>>>>> >>>>>> Thanks for adding the preference, but unfortunately the default is >>>>>> false such that the new way still presses in for each new image. >>>>>> >>>>>> In the original thread, there were two people who expressed this was a >>>>>> "step backward" for them, but there were no proponents for the change >>>>>> voiced. Therefore, unless there are strong objectors who can make >>>>>> some arguments for, I'd like to put the default value for this to >>>>>> restore the default functionality that has been there for years. >>>>>> >>>>>> 3.11 has suffered several usability degradations over 3.9 in terms of >>>>>> the UI. I would like to begin addressing them, starting with this >>>>>> one. >>>>> >>>>> A big fat -1 from me. From my perspective the rectangular frame is ugly. >>>>> Simple as that. It's visually unpleasant and in conflict with the rest >>>>> of >>>>> the window and the default shouldn't be that. If the new cue is too >>>>> subtle >>>>> to be of use for you personally, that's what we got preferences for, but >>>>> I >>>>> think we should at least *try* to get a teenie weenie bit less heinous >>>>> in >>>>> the default L&F. >>>>> >>>>> Cheers, >>>>> - Andreas >>>>> >>>>> >>>> >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >> >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

3 4

AlternatePluggableListMorphOfMany
by Chris Muller 04 Mar '10

04 Mar '10

I've just posted Morphic-cmm.372, which introduces AlternatePluggableListMorphOfMany. (Be sure to also get Tools-cmm.200). Those concerned with Squeak being familiar to new-users may appreciate this; it is basically the same as the standard PluggableListMorphOfMany, but allowing range-selections via Shift+clicking. Also, swipe-selecting does not miss interim selections (e.g., in the middle of the swipe). Now, I have not changed any existing users of PluggableListMorphOfMany to use AlternatePluggableListMorphOfMany, but there is a demonstration of it by enabling on the preference, "traceMessages" in the Preferences. This will utilize a MessageTrace instead of a MessageSet when browsing senders/implementors. If we like it, we can convert some or all of the legacy PluggableListMorphOfMany's to the new one and then rename it. Or if there is a need for both then both or, if we don't like it, of course, it can easily be deleted.. - Chris

3 4

[Squeak 4.0] URGENT: Relicense Contributors
by Ronald Spengler 04 Mar '10

04 Mar '10

Good people of Squeak, If you've contributed significantly to the relicense effort, or know someone who has, who is not on the following list, I need to know about it ASAP. Relicense Contributers: Dan Ingalls Craig Latta Bert Freudenberg Yoshiki Ohshima Tim Rowledge Randal L. Schwartz Igor Stasenko Jecel Assumpcao Jr. Ken Causey Andreas Raab -- Ron

2 1

Towards a Trunk Release [help needed]
by Andreas Raab 04 Mar '10

04 Mar '10

Folks - This is part two of two about upcoming releases. Besides the 4.0 release we need to get ready for a release from the trunk. If you look at rather long list of improvements this is a good time to get a release out. One of the things that's a bit odd here is that we don't know yet whether the trunk release will become 3.11 or 4.1. That's because it depends on whether we can get the relicensing done before the trunk release is ready or not. If the 4.0 release happens relatively quickly, we can go straight to 4.1. However, at the board meeting we had agreement that we didn't want to introduce an artificial dependency here, so we'll be working towards 3.11 and if 4.0 gets done in time we'll just jump straight into 4.1. To avoid confusion, let's refer to it as "trunk release" until we have more clarity of what version it is likely to be. The real question is what remains to be done for the next release. In theory, we could just release a trunk image pretty much "as is" but from my perspective this is aiming too low. I'd like to make this a richer release than what a trunk image contains. To do this we'll have to find consensus about: * what documentation to include * what external/optional packages to include * what the welcome screen should look like * what extra projects to include * ... and more .... and that's besides the usual release work of ensuring that we've got the tests green, packaging Squeak for the platforms and so on. I think what we're looking for here is really a release manager and team that think a bit like a product manager. We have a Squeak image and there's plenty of interesting code out there, what we need to do is to build an interesting AND useful artifact that we like as a starting point for people to explore Squeak. I know some people have expressed interest in the release manager role for the next release (nudge, nudge Edgar :-) so again we need volunteers both for driving the process, decide on the deadlines, and get things done as well as team members for the various bits to be done. Please don't be shy. If you'd like to actively participate in the next release, post your thoughts. Cheers, - Andreas

10 17

The Trunk: PreferenceBrowser-bf.43.mcz
by commits＠source.squeak.org 04 Mar '10

04 Mar '10

Bert Freudenberg uploaded a new version of PreferenceBrowser to project The Trunk: http://source.squeak.org/trunk/PreferenceBrowser-bf.43.mcz ==================== Summary ==================== Name: PreferenceBrowser-bf.43 Author: bf Time: 4 March 2010, 12:16:47.804 pm UUID: e5fa5ebe-421e-464f-a543-c66644198852 Ancestors: PreferenceBrowser-ar.42 - make browsing senders of pragma preferences work =============== Diff against PreferenceBrowser-ar.42 =============== Item was added: + ----- Method: Preference>>selectors (in category '*PreferenceBrowser') ----- + selectors + "for browsing senders" + ^{name}! Item was added: + ----- Method: PragmaPreference>>selectors (in category '*PreferenceBrowser') ----- + selectors + "for browsing senders" + ^ {getter. setter}! Item was changed: ----- Method: PBPreferenceView>>offerPreferenceNameMenu: (in category 'user interface') ----- offerPreferenceNameMenu: aPreferenceBrowser "the user clicked on a preference name -- put up a menu" | aMenu | aMenu := MenuMorph new defaultTarget: self preference; addTitle: self preference name. (Preferences okayToChangeProjectLocalnessOf: self preference name) ifTrue: [aMenu addUpdating: #isProjectLocalString target: self preference action: #toggleProjectLocalness. aMenu balloonTextForLastItem: 'Some preferences are best applied uniformly to all projects, and others are best set by each individual project. If this item is checked, then this preference will be printed in bold and will have a separate value for each project']. + aMenu add: 'browse senders' translated target: self systemNavigation selector: #browseAllSelect:name:autoSelect: argumentList: {[:m | self preference selectors anySatisfy: [:sel | m hasLiteralThorough: sel]]. 'Preference senders: {1}' translated format: {self preference name}. self preference selectors first}. - aMenu add: 'browse senders' translated target: self systemNavigation selector: #browseAllCallsOn: argument: self preference name. aMenu balloonTextForLastItem: 'This will open a method-list browser on all methods that the send the preference "', self preference name, '".'. aMenu add: 'show category...' target: aPreferenceBrowser selector: #findCategoryFromPreference: argument: self preference name. aMenu balloonTextForLastItem: 'Allows you to find out which category, or categories, this preference belongs to.'. Smalltalk isMorphic ifTrue: [aMenu add: 'hand me a button for this preference' target: self selector: #tearOffButton. aMenu balloonTextForLastItem: 'Will give you a button that governs this preference, which you may deposit wherever you wish']. aMenu add: 'copy this name to clipboard' target: self preference selector: #copyName. aMenu balloonTextForLastItem: 'Copy the name of the preference to the text clipboard, so that you can paste into code somewhere'. aMenu popUpInWorld!

1 0

Fwd: Squeak and RosettaCode
by Andreas Raab 04 Mar '10

04 Mar '10

Anyone interested? -------- Original Message -------- Subject: Squeak and RosettaCode Date: Wed, 03 Mar 2010 03:37:59 +0000 From: Bruce Axtens <axtens_b(a)users.sourceforge.net> Message body follows: Dear Sir Squeak is a significant accomplishment. More people should know about it. May I suggest RosettaCode <http://www.rosettacode.org>. This is a programming chrestomathy site which compares languages by defining tasks and challenging programmers to solve those tasks with their preferred language. I have no affiliation with the site. I am simply a programmer, attempting these tasks with VBScript. I have benefited from facing these tasks, and I am sure you shall also. It will also introduce more people to Squeak, leading perhaps to a more widespread adoption of the language. Kind regards, Bruce M. Axtens

2 1

The Trunk: Kernel-ar.415.mcz
by commits＠source.squeak.org 04 Mar '10

04 Mar '10

Andreas Raab uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-ar.415.mcz ==================== Summary ==================== Name: Kernel-ar.415 Author: ar Time: 3 March 2010, 9:42:13.86 pm UUID: dc49d9cd-b446-8747-8337-1712a9d0258f Ancestors: Kernel-dtl.414 Attempt to complete ensure blocks that are currently under execution when terminating a process. =============== Diff against Kernel-dtl.414 =============== Item was changed: ----- Method: Process>>terminate (in category 'changing process state') ----- terminate "Stop the process that the receiver represents forever. Unwind to execute pending ensure:/ifCurtailed: blocks before terminating." | ctxt unwindBlock oldList | self isActiveProcess ifTrue: [ ctxt := thisContext. [ ctxt := ctxt findNextUnwindContextUpTo: nil. ctxt isNil ] whileFalse: [ (ctxt tempAt: 2) ifNil:[ ctxt tempAt: 2 put: nil. unwindBlock := ctxt tempAt: 1. thisContext terminateTo: ctxt. unwindBlock value]. ]. thisContext terminateTo: nil. self suspend. ] ifFalse:[ "Always suspend the process first so it doesn't accidentally get woken up" oldList := self suspend. suspendedContext ifNotNil:[ "Figure out if we are terminating the process while waiting in Semaphore>>critical: In this case, pop the suspendedContext so that we leave the ensure: block inside Semaphore>>critical: without signaling the semaphore." (oldList class == Semaphore and:[ suspendedContext method == (Semaphore compiledMethodAt: #critical:)]) ifTrue:[ suspendedContext := suspendedContext home. ]. + + "If we are terminating a process halfways through an unwind, try + to complete that unwind block first." + (suspendedContext findNextUnwindContextUpTo: nil) ifNotNil:[:outer| + (suspendedContext findContextSuchThat:[:c| c closure == (outer tempAt: 1)]) ifNotNil:[:inner| + "This is an unwind block currently under evaluation" + suspendedContext runUntilErrorOrReturnFrom: inner. + ]. + ]. + ctxt := self popTo: suspendedContext bottomContext. ctxt == suspendedContext bottomContext ifFalse: [ self debug: ctxt title: 'Unwind error during termination']]. ]. !

1 0

The Trunk: Tests-ar.54.mcz
by commits＠source.squeak.org 04 Mar '10

04 Mar '10

Andreas Raab uploaded a new version of Tests to project The Trunk: http://source.squeak.org/trunk/Tests-ar.54.mcz ==================== Summary ==================== Name: Tests-ar.54 Author: ar Time: 3 March 2010, 9:40:26.558 pm UUID: 641315e3-0990-a04c-8e7a-2374969f846e Ancestors: Tests-ar.53 Add a test for the issue of terminating a well-behaved unwind block int he middle. =============== Diff against Tests-ar.53 =============== Item was added: + ----- Method: ProcessTerminateBug>>testTerminationDuringUnwind (in category 'tests') ----- + testTerminationDuringUnwind + "An illustration of the issue of process termination during unwind. + This uses a well-behaved unwind block that we should allow to complete + if at all possible." + | unwindStarted unwindFinished p | + unwindStarted := unwindFinished := false. + p := [[] ensure:[ + unwindStarted := true. + Processor yield. + unwindFinished := true. + ]] fork. + self deny: unwindStarted. + Processor yield. + self assert: unwindStarted. + self deny: unwindFinished. + p terminate. + self assert: unwindFinished.!

1 0

Simple Frame Adornments - default value (was: unsaved changes indicator)
by Chris Muller 04 Mar '10

04 Mar '10

Thanks for adding the preference, but unfortunately the default is false such that the new way still presses in for each new image. In the original thread, there were two people who expressed this was a "step backward" for them, but there were no proponents for the change voiced. Therefore, unless there are strong objectors who can make some arguments for, I'd like to put the default value for this to restore the default functionality that has been there for years. 3.11 has suffered several usability degradations over 3.9 in terms of the UI. I would like to begin addressing them, starting with this one. Thanks.. Chris

6 8

Daily Commit Log
by commits＠source.squeak.org 04 Mar '10

04 Mar '10

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2010-March/002890.html Name: Morphic-cmm.370 Ancestors: Morphic-ar.369 Added hot-key to invoke pretty-print on a method. It is crucial for the computer to handle mundane code-formatting, because it allows code to "flow" into the system as quickly as one can type. The key is Shift+Command+S. The pretty-print command also now positions the cursor at the end of the code, where there is a chance you wish to continue the method, instead of at the beginning, where there is no chance of that. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2010-March/002891.html Name: Tests-ar.53 Ancestors: Tests-ar.52 Improved PackageDependencyTest now prints out dependencies upon failure so that we can see what the dependencies are and what we need to fix. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2010-March/002892.html Name: Morphic-laza.370 Ancestors: Morphic-ar.369 Add to the windows menu: - contain every visible window (collapsed or not) - show a collapsed window in the list by putting () around the label - show a touched window by putting a leading * to the label - group windows by model (eg. Browsers are most likely always at the top of the list) - have a "close all like this" menu entry to close all windows of a same kind (eg. close all open inspectors) [won't touch any windows with changed content] - have a "close all but this" menu entry which does exactly like the above, but without closing the selected window ============================================= http://lists.squeakfoundation.org/pipermail/packages/2010-March/002893.html Name: Tools-ar.198 Ancestors: Tools-laza.197 A quick adoption of DependencyBrowser. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2010-March/002894.html Name: Tools-laza.199 Ancestors: Tools-ar.198 Fixes ChangeSorter find ============================================= http://lists.squeakfoundation.org/pipermail/packages/2010-March/002895.html Name: Morphic-cmm.372 Ancestors: Morphic-cmm.371, Morphic-laza.370 Merged laza.370. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2010-March/002896.html Name: Tools-cmm.200 Ancestors: Tools-cmm.199, Tools-laza.199 - MessageTrace, a new subclass of MessageSet, presents message flow via a succint hierarchy. To turn it on, enable the preference #traceMessages. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2010-March/002897.html Name: System-cmm.275 Ancestors: System-cmm.274 Added #traceMessages preference. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2010-March/002898.html Name: ToolBuilder-Kernel-cmm.32 Ancestors: ToolBuilder-Kernel-dtl.31 - Support for newly introduced AlternatePluggableListMorphOfMany. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2010-March/002899.html Name: ToolBuilder-Morphic-cmm.51 Ancestors: ToolBuilder-Morphic-dtl.50 - Support for newly introduced AlternatePluggableListMorphOfMany. =============================================

1 0

← Newer
1
...
68
69
70
71
72
73
74
...
77
Older →

Jump to page: