Squeak-dev July 2000

squeak-dev@lists.squeakfoundation.org

121 participants
566 discussions

Re: [VM][Events][BUG][FIX] PluggableListMorphs: to many clicks necessary to select/unselect, if the mouse stays at the same point...
by Tim Rowledge 27 Jul '00

27 Jul '00

In message <3978FE14.FB8EBEE1(a)evolgo.de> Stephan Rudlof <sr(a)evolgo.de> wrote: > In PluggableListMorphs there are two clicks necessary to deselect/select > an already selected/deselected item, if the mouse stays at the same > point. If you move it a little, then you need just one click (as > expected). > > Seems to be one of the odd (not serious) effects if event stuff is > introduced. Fixed it, or should I say, found a workaround. The bug was noted in several symptonms:- 1. when using meta-F to open a find FillInTheBlank, you had to move the mouse a little to get the FITB to activate 2. if you deselect an item in a pluggablelistmorph, you had to click twice to get it to reselelct unles you moved the mouse 3. if you drag select down (or up) out of a view with a large text, the drag-scroll would stop after a very short while. All these symptoms are related to an architectural bug in the Morphic processEvents code. The code is relying on an artifact of the old mouse-state-polling regime that provided a fake mouse-move event every time HandMorph>processEvents was called. Naughty code!! It seems primarily to be related to #mouseOver: not getting called unless this fake event is provided. The FITB for example really ought to activate explicitly, since we deliberately open it, rather than misusing #mouseOver:. As a workaround, I have made the event code provide a similar fake mousemove. This is ugly and the proper architectural change should be made by somebody that really understands the Morphic stuff. tim -- Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: ESBD: Erase System and Burn Documentation

2 2

www.squeak.org problems: Apache set up wrong?
by Ned Konz 27 Jul '00

27 Jul '00

I just went to http://www.squeak.org and got the following cheerful notice (which is probably not what is wanted): It Worked! The Apache Web Server is Installed on this Web Site! If you can see this page, then the people who own this domain have just installed the Apache Web server software successfully. They now have to add content to this directory and replace this placeholder page, or else point the server at their real content. If you are seeing this page instead of the site you expected, please contact the administrator of the site involved. (Try sending mail to < Webmaster@domain>.) Although this site is running the Apache software it almost certainly has no other connection to the Apache Group, so please do not send mail about this site or its contents to the Apache authors. If you do, your message will be ignored. -- Ned Konz currently: Stanwood, WA email: ned(a)bike-nomad.com homepage: http://bike-nomad.com

1 1

Re: Programmatically deleting windows - Project in particular
by Tim Rowledge 27 Jul '00

27 Jul '00

In message <200007270249.WAA21996(a)fellspt.charm.net> you wrote: > The morph deleted in this case is the ProjectViewMorph which is in a > SystemWindow. The SystemWindow would normally have been deleted a little > later when Project>>okToChange returned to its sender, > SystemWindow>>delete (where the user started the process rolling by > clicking the close X). Ah, OK, I didn't spot the split betwen the two Morphs. That makes me wonder just how effective the code in the zapMVCProject method could really be; seems like it wouldn't handle theImageSegment stuff nor the project window! It would be really nice to find a way to separate out the UI side of a lot of this window manipulating stuff, so that programmatic manipulation could work. I suppose that with an event queue working I could be really evil and force made-up events onto the queue so that the UI would think the user had said yes in the right places ;-) tim -- Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim If at first you don't succeed, you must be a programmer.

1 0

www.squeak.org problems: Apache set up wrong?
by Ned Konz 27 Jul '00

27 Jul '00

1 0

Block closures
by Mats Nygren 27 Jul '00

27 Jul '00

Hi, I've had a look at the compiler and the VM. I can do the block closures. But don't expect to see anything before the middle of October as I have other things that has to be done. I have the straighforard way of doing it in mind, allocating block contexts. No fancy optimizations. The semantics I have in mind is as in ANSI Smalltalk, is that what is wanted? In particular it will be possible to shadow variables in enclosing scopes. While at it I will restructure the compiler a little. /Mats

4 3

Re: Window Frames for system windows
by Lex Spoon 27 Jul '00

27 Jul '00

Ned Konz <ned(a)bike-nomad.com> wrote: > Lex Spoon wrote: > > > > Ultimately, the right answer seems to be to talk about centimeters > > instead of pixels. To be practical, though, this does require having a > > certain resolution available; 70-100 dpi is probably not enough, > > especially for text. > > This breaks down at the extremes of screen sizes. For instance, I can spend > 5mm or so on a window title bar without sacrificing much on my 19" monitor. > It has about a 260mm vertical size, so it's about 2% of my screen height, > and represents about 20 pixels. But the same 5mm is perhaps 7% of my screen > height on my NEC MObilePro 770 WinCE machine with 640x240 LCD screen, and takes > up 17 pixels or so because of the lower resolution. So ideally I want to see > my titlebars, etc. smaller on the WinCE machine if I can get them that way. > (yes, at 85 or so dpi it's hard to see good text). Certainly; you wouldn't want overlapping windows on a small handheld even it did have 1024x768 resolution. On the other hand, whatever UI you use at 1024x768 on a handheld is going to work fine at 2048x1536 as well. Making the same UI work at multiple resolutions, though, is easiest to do if the UI implementation talks about centimeters instead of pixels. Man, after all this talk I'm really wishing I had such a UI available right now, even though I've got a plain ~100dpi monitor! I think I could live with 50% larger font sizes in return for such a convenient and scalable UI framework. > I've noticed that there are already Squeak menus that don't fit on my 640x240 > screen -- and there's no way that I've been able to find to interact with them, > as they don't auto-scroll, and there's no way to move them without dragging > either the titlebar or the move halo (both of which are on the top of the > menu!). Here's a trick: click very carefully on the border of the menu, and you can pick it up. Surely this is a bug, but hey, it's a way :) -Lex

1 0

Re: Block closures
by Lex Spoon 27 Jul '00

27 Jul '00

Don't forget references to variables in a surrounding block. A single "home" pointing back to the surrounding method will no longer be enough.... -Lex Mats Nygren <nygren(a)sics.se> wrote: > Hi, > > I've had a look at the compiler and the VM. > > I can do the block closures. But don't expect to see anything before the > middle of October as I have other things that has to be done. I have the > straighforard way of doing it in mind, allocating block contexts. No fancy > optimizations. > > The semantics I have in mind is as in ANSI Smalltalk, is that what is > wanted? In particular it will be possible to shadow variables in > enclosing scopes. > > While at it I will restructure the compiler a little. > > /Mats

1 0

Athlon Benchmark
by Michael Rueger 27 Jul '00

27 Jul '00

Hi all, just ran the tinyBenchmark on my shiny new 700 Mhz Athlon, 256 MB: '69830878 bytecodes/sec; 2106836 sends/sec' Any explanation why the bytecode number is that high? It's not a Thunderbird, so it can't be the onchip cache. Michael

3 5

Re: Window Frames for system windows
by Lex Spoon 27 Jul '00

27 Jul '00

Ultimately, the right answer seems to be to talk about centimeters instead of pixels. To be practical, though, this does require having a certain resolution available; 70-100 dpi is probably not enough, especially for text. On the other hand, most people run their video cards way belowe what they can actually do. What a shame that people are *that* locked into pixel-oriented graphics applications! The whole situation is similar to the old "turbo" buttons that would let people run their CPU at a fraction of its full speed. This is necessary when running programs that talk about cycles instead of seconds.... -Lex "Jim Benson" <jb(a)speed.net> wrote: > Bob, > > I've thought about this for a couple of days, but I have not been able to > come up with what a general purpose solution should do. As is usually the > case, I keep running into the dichotomy of Squeak. It's big and it's small, > with no real target machine. Maybe it has a big display, maybe it has a > small display, or no display at all (though we can probably have pretty > small minimumExtents on that one :) . So, when you set the minimumExtent to > some value, it depends on what type of platform you're running on to > determine what a reasonable default should be. > > There are other examples of this strewn throughout the system. Minimum > extent of system tools is one, default font size is another nasty one. > > There is a major difference between things like 100@80 extents for browsers > on a PDA vs. a 1600@1200 PC/workstation display. On a 1600@1200 display on a > 21" monitor, working the menus is a real challenge due to the small font > size, and you pretty much have to have magnifying glasses on to look at the > default text sizes for any length of time. Yet on a 640@480 screen, it looks > huge. Going forward, I would hope we have much larger displays with much > higher resolution. Just adjusting your preferences would become a major > challenge on higher resolution displays. > > Another problem with the minimumExtent for SystemWindows is that all of the > panes in some of the common windows do not honor the bounds of the > SystemWindow. For example, look at a default PackageBrowser instantiated > from a 'browse code' menu command in the file list, when the Preferences is > set for inbound scrollbars. When an Explorer is sized to 200@200, the > scrollbar overhangs the window frame. It seems to me that there has to be a > minimum size in pixels that a pane must honor when being resized, or else > the whole thing becomes a mess real quick. > > To experienced Squeakers, that's not a *real* big deal because you can set > all of your preferred font sizes and preferences just once, then save them > to an external file using sophisticated Lex Spoon approved Squeak code. > These external files may be later filed into other images to setup "your" > preferred Preferences. > > To the neophyte, however, to say that it's a challenge to set the font sizes > is a major understatement. And there are only three default fonts ( if you > count Comic Plain and Comic Bold as two fonts <grin> ) !!! Imagine if Squeak > became like a modern application and had a reasonable number fonts!!! My > guess is that you lose a lot of these folks right from the get go when they > try to figure out how to change things in the appearance or preferences > area. It's way too hard for what it does. > > MinimumExtent is tricky. For example, when I bring up a browser on my rig, I > resize it to a workable size. Every stinking time I have to browse > something. > > So then I started thinking things like "Well, how about if you had > preferences for things like minimumExtent that they were calculated based on > the current screen resolution and the extent of the native OS window that > Squeak was running in?" Same thing with fonts on system startup. Then I just > keep running back to the same questions, "How do I make Squeak act like a > window manager without writing an entire window manager?" and "Preferences > are not my friend, yet I keep wanting to add more?" Usually by then I get > hopelessly confused, and lose interest. > > Jim > > > Bob wrote: > > > > > I think a useful approach here might be to start setting the minimumExtent > for things. For browsers, you could do this in the places where > SystemWindows were created for browsers by adding something like: > > > > window setProperty: #minimumExtent toValue: 200@200. > > > > since a System Browser running in a 100@80 space seems a bit too small to > be useful. Alternatively, you could decide that any system window needed to > be a certain size and include the setting in SystemWindow>>initialize. > >

2 1

Programmatically deleting windows - Project in particular
by Tim Rowledge 27 Jul '00

27 Jul '00

No, this isn't about removing M$ project planning tools from my machine. Happily, there are NO M$ products in my office... BUT I want to be able to remove Projects and their views programatically as part of a script to shrink the image. So far I'm not having much luck. I started by looking into SystemDictionary>zapMVCProjects and noticed the Project>oktoChange method. The latter does a whole load more than the former, lots of ImageSegment stuff etc. It also uses Confirmers and Menus which I want to avoid. By making the later part of okToChange into a separate method (and sending the new message in okToChange - gotta keep this clean!) I thought I might at least have a chance of success, however despite the fact that the method sends the ProjectViewMorp #deletingProject: which claims to delete the morph, and then also sends #abandon which seems intended to do the same thing, the window resolutely stays there. It seems that zapMVCProjects and oktoChange have got out of step a little ? Have I misunderstood completely? I should probably add that I am trying this from a morphic project, attemtping to delete a newly created project - both mvc & morphic have the same behavior so far. In general, is there intended to be a way to programatically close windows without requiring further user interaction? So far it looks as if all the related methods are pretty UI intermingled, which is a pity. tim -- Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- Not as dumb as he looks, but that would be impossible.

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
57
Older →

Jump to page: