Had a go at S4 and created a git branch for it: https://github.com/rksm/LivelyKernel/tree/samurai_fixes
Best, Fabian On Wed, Mar 14, 2012 at 5:45 AM, Jens Lincke <[email protected]> wrote: > Hi, Dan - > > thank you, that you took the time to write these issues down. I added them > to track and created a new milestone for them > http://lively-kernel.org/trac/query?status=assigned&status=new&status=accepted&status=reopened&group=status&milestone=M4+-+Samurai+Coding > > The question is now: How to proceed? Some of the issues are clear how to > address them, but some are trickier and will take longer to solve. > > Are there any volunteers to tackle the issues? > > Best, > Jens > > Am 12.03.2012 um 18:19 schrieb Dan Ingalls: > > Folks - > > Over the weekend i did some Samurai coding. I haven't been able to do much > of this recently, but it is very instructive. > > The bad news: I found myself constantly thwarted my minor annoyances. The > good news: it is clear to me that if we only fixed about a dozen things, > Lively could be a true Samurai environment. For that reason I have taken > care to document my experiences... > > S1: It is a real problem to have <save> in the search list (cmd-shift-F) > behave differently from in the SCB (System Code Browser). Even if the > message tells you that changes are only local, it simply doesn't work to > have cooperating tools with different conventions. > > S2: We must be able to browse old versions of code that we have changed. > Yes, one can use the wiki revert mechanism, but it is way too complex and > time-consuming, and usually forces you to revert other things that you don't > want to change. This is easy to do (see Squeak browse versions) and it will > pay off the minute we put it in place. The Samurai knows where he is going > and our job is to clear all the obstructions out of his way. > > S3: I'm convinced there is something wrong with the add/remove method logic > in the SCB when you use "sorted" mode. And why wouldn't we use "sorted" all > the time? This should be fixed and sorted should be the default. > > S4 The management of keyboard focus and selections is infuriating. This > *has* to be made right. We can't ask a Samurai to keep making his > selections over again just because of changing from one window to another. > And we can't have cmd-D saving a bookmark instead of evaluating a selection > just because keyboard focus isn't treated right. > > S5: Pan(two-finger) scrolling still does not work right. The rule is very > simple: pan scrolling should affect only the innermost scrollable context in > which the gesture starts. And it needs to respond immediately. It either > works right or it is a distraction. We have enough distractions already. > > S6: Text frames *must* have adequate margins. We can't ask a Samurai to > pick single pixels when trying to select a line of text. > > S7: The green save message in the SCB does not appear when the method text > is scrolled up. If we're going to show it, we should show it, eg, in the > middle of the frame as in the Object Editor. > > S8: We are paying a huge penalty for not having built a scaling pane > structure for windows. It must be easy to reshape and position windows on > the screen. This should be in the kernel, with a splittable pane in the > parts bin. We need a bit of design here, but nothing that hard. > > S9: For instance it is almost impossible to get a reasonable amount of > workspace at the bottom of an inspector. And also on the inspector, arrays > longer than 10 or 20 need to be abbreviated, lest they kill the system. > > S10: It is a huge mistake that we consider syntax errors to be program > errors. The Parser should never break and should not cause any program > errors (huge red paragraphs splashed all over the screen). If there is a > syntax error it should be noted either in the text or with a "before..." or > "after..." hint. Why do I call this "huge"? Two reasons. First, the whole > job of the parser is to find the errors; why then ask the programmer to > find them again without even any help. The second reason comes next... > > Chris's debugger is really great! I almost started using it all the time. > Except that syntax errors are treated as program errors and thus get slowed > down by the need to start up the debugger. Let's fix the syntax error > problem and all start using the debugger. > > S11: We need a console window so we can see console messages without having > to use the native console. This worked nicely in LK1. > > S12: The tools have to be fast. I'm talking about inspector, object > editor, SCB, search panels, and debugger. It's OK to fetch them from the > parts bin once, but they should be cached thereafter. The delay to respond > to a change should not be much more than the time it takes the coder to get > ready for it. Even for this old Samurai, that's about two seconds. > > Every one of these obstructions carries a doubled cost. The first is the > time wasted; the second is the loss in momentum which is much more costly. > > I would have (and probably should have) put these all into TRAC, but I think > it's important that they be presented as parts of a *gestalt*. If each of > these problems is addressed (and most could probably be addressed in a > focussed day of work), we will all be working on an entirely new level. It > will actually make us better. Even part way through this list, we will be > finishing the job faster. > > Maybe someone could turn this into a Samurai page where we can coordinate > this work, or put it into TRAC in a way that the gestalt gets preserved -- > maybe by adding a new category of priority called Samurai. I don't want to > mess up the current organization, which I think is good. But I do want to > establish a distinct new initiative which is to take our coding power to the > next level. > > Let's get busy... > _______________________________________________ > lively-kernel mailing list > [email protected] > http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel > > > > _______________________________________________ > lively-kernel mailing list > [email protected] > http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel > _______________________________________________ lively-kernel mailing list [email protected] http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
