Greetings all,
This is a cautionary tale. I apologize to Juan for wasting his time, but how was I to know?? Basically, the story is this. I have been losing the Taskbar and seeing some inconsistent behaviors. ================From a Cuis Workspace: Date current print. "17 October 2013 " Smalltalk isRunningCog. "false" ==========But in the Linux command line: >>> date Tue Oct 29 09:08:13 PDT 2013 >>> which squeak /root/my-applications/bin/squeak >>> `which squeak` --version unknown option: --version Usage: /root/my-applications/bin/../lib/squeak/4.0-2776/squeak [<option>...] [<imageName> [<argument>...]] ##So command line squeak is COG 2776, BUT.. !!! >>> ps aux |grep -i squeak root 7924 6.8 0.9 1056392 29024 tty1 S 08:59 1:41 /usr/local/lib/squeak/4.10.2-2724/squeakvm /root/Cuis-4.2/Cuis-Smalltalk-Dev/Cuis4.3-MorphNoExtension.image #######!!!NOTE WRONG VM!!!####### [clearly] Cuis-Smalltalk-Dev >>> /root/my-applications/bin/squeak Cuis4.2-1855.image ========================1855 Workspace w correct VM Date current print. "29 October 2013" Smalltalk isRunningCog. "true" ============================================================== So. When I clicked on the desktop icon for an image, I got an old VM, but when I invoked an image from the command line, I got the new VM. Sometimes I would start an image by clicking, sometimes via command line. Inconsistent results to say the least! So for you Linux users out there, particularly if using Rox Filer, be sure to use full pathnames to the VM you want to use. I have no idea why invoking "squeak" from the command like is different than invoking "squeak" setup via the icon panel. Ranlib? Anyway, the short story is to check and not be fooled into thinking you are getting what you ask for! FYI, -KenD -- Ken [dot] Dickey [at] whidbey [dot] com _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
Hi Ken, curious about a couple of things, stuff to say about something else.
What distro and version are you using Linux-wise? When you talk about losing the taskbar, are you talking about the Cuis taskbar (which I'm mostly guilty for) or the one in your X11 environment? Other thing: my taskbar sucks. It was a quick hack that made the system remotely usable again after Squeak's minimize-SystemWindow behavior was removed for being crufty. I have a project on my disk that might fix it. Well I guess I should really start a different thread about this. On Oct 29, 2013, at 10:05 AM, Ken Dickey <[hidden email]> wrote: > Greetings all, > > This is a cautionary tale. I apologize to Juan for wasting his time, but how was I to know?? > > Basically, the story is this. I have been losing the Taskbar and seeing some inconsistent behaviors. > > ================From a Cuis Workspace: > > Date current print. "17 October 2013 " > Smalltalk isRunningCog. "false" > > ==========But in the Linux command line: > >>>> date > Tue Oct 29 09:08:13 PDT 2013 > >>>> which squeak > /root/my-applications/bin/squeak > >>>> `which squeak` --version > unknown option: --version > Usage: /root/my-applications/bin/../lib/squeak/4.0-2776/squeak [<option>...] [<imageName> [<argument>...]] > > ##So command line squeak is COG 2776, BUT.. !!! > >>>> ps aux |grep -i squeak > root 7924 6.8 0.9 1056392 29024 tty1 S 08:59 1:41 /usr/local/lib/squeak/4.10.2-2724/squeakvm /root/Cuis-4.2/Cuis-Smalltalk-Dev/Cuis4.3-MorphNoExtension.image > > #######!!!NOTE WRONG VM!!!####### > > [clearly] Cuis-Smalltalk-Dev >>> /root/my-applications/bin/squeak Cuis4.2-1855.image > > ========================1855 Workspace w correct VM > > Date current print. "29 October 2013" > Smalltalk isRunningCog. "true" > > ============================================================== > > So. When I clicked on the desktop icon for an image, I got an old VM, but when I invoked an image from the command line, I got the new VM. Sometimes I would start an image by clicking, sometimes via command line. > > Inconsistent results to say the least! > > So for you Linux users out there, particularly if using Rox Filer, be sure to use full pathnames to the VM you want to use. > > I have no idea why invoking "squeak" from the command like is different than invoking "squeak" setup via the icon panel. Ranlib? > > Anyway, the short story is to check and not be fooled into thinking you are getting what you ask for! > > FYI, > -KenD > -- > Ken [dot] Dickey [at] whidbey [dot] com > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
On Wed, 30 Oct 2013 04:11:45 -0700
Casey Ransberger <[hidden email]> wrote: > Hi Ken, curious about a couple of things, stuff to say about something else. > > What distro and version are you using Linux-wise? Puppy Linux [Precise]. It is a small distro that runs in RAM. I use OpenBSD for financial stuff and bigger Linux distros for various tests and tools. > When you talk about losing the taskbar, are you talking about the Cuis taskbar (which I'm mostly guilty for) or the one in your X11 environment? The Cuis taskbar. The short story here is that, running multiple distros, I keep the HW clock on UTC, not local (GMT-7) time. The old VM was not picking this up, so the Taskbar stepTime was way in the future. No steps meant that the taskbar came up off-screen and never refreshed to a location according with my screen size. I could send "Taskbar reset; initialize" or start stepping the existing Taskbar but it did not appear on my screen and I had to use the World Menu > Windows > Find Window facility to restore minimized windows. Big pain and I learned a lot by finding out where and how the Taskbar works. It took me forever to discover that the location was reset in the Step method. But I did learn a lot! -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
Ugh! Enough already!
This irked me when I was writing the miserable thing. There should be a general facility that can inform a morph about the dimensions of the screen, which can tell that morph that the screen's dimensions have changed, without using stepping. Ideally, or I think, by asking the VM more or less directly and not having to worry about the World (I say this because if we can use a prim, I bet we can get rid of that nasty delay after changing the window size where the taskbar seems to need to catch up with the eye as a consequence of waiting on #stepTime.) Can anyone think of anything? The main reason the taskbar has to do this stupid dance is when the user changes the size of the window, if it doesn't poll the VM for window size, it won't stick to the bottom of the window, or be the proper width. There has got to be a better way to do this. Halp? Ideas? Even Juan was like (paraphrasing here) "well, I wouldn't have thought of doing it this way, but okay." Mainly because -- at the time -- it fixed a problem with some behavior he'd removed. If you clicked the minimize button you'd get a DNU. So I wrote a hacky taskbar to give it a better behavior than that. End result was the minimize button actually still worked. But the use of stepping to size the bloody thing has always bothered me. There's got to be a better way to do it. Grump grump grump, dumb dumb dumb, me me me. Seriously halp, mah peoples. On Oct 30, 2013, at 9:56 AM, Ken Dickey <[hidden email]> wrote: > On Wed, 30 Oct 2013 04:11:45 -0700 > Casey Ransberger <[hidden email]> wrote: > >> Hi Ken, curious about a couple of things, stuff to say about something else. >> >> What distro and version are you using Linux-wise? > > Puppy Linux [Precise]. It is a small distro that runs in RAM. I use OpenBSD for financial stuff and bigger Linux distros for various tests and tools. > >> When you talk about losing the taskbar, are you talking about the Cuis taskbar (which I'm mostly guilty for) or the one in your X11 environment? > > The Cuis taskbar. > > The short story here is that, running multiple distros, I keep the HW clock on UTC, not local (GMT-7) time. The old VM was not picking this up, so the Taskbar stepTime was way in the future. > > No steps meant that the taskbar came up off-screen and never refreshed to a location according with my screen size. I could send "Taskbar reset; initialize" or start stepping the existing Taskbar but it did not appear on my screen and I had to use the World Menu > Windows > Find Window facility to restore minimized windows. > > Big pain and I learned a lot by finding out where and how the Taskbar works. It took me forever to discover that the location was reset in the Step method. But I did learn a lot! > > -KenD > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
On Wed, 30 Oct 2013 12:22:47 -0700
Casey Ransberger <[hidden email]> wrote: > This irked me when I was writing the miserable thing. There should be a general facility that can inform a morph about the dimensions of the screen, which can tell that morph that the screen's dimensions have changed, without using stepping. Two facilities: startUp & shutDown are sent when the image is restored / saved. For screen size changes, we should make use of the event system. E.g Utilities class>>startUp registers for events. Perhaps DisplayScreen>>setExtent:depth: could "triggerEvent: #screenSizeUpdate" or some such. $0.02, -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
In reply to this post by Casey Ransberger-2
On Wed, 30 Oct 2013 12:22:47 -0700
Casey Ransberger <[hidden email]> wrote: > This irked me when I was writing the miserable thing. There should be a general facility that can inform a morph about the dimensions of the screen, which can tell that morph that the screen's dimensions have changed, without using stepping. Aside from the #screenSizeChanged (or whatever) event, would it make sense to trigger a #morphScaleChanged when a morph is rescaled (e.g. to the taskbar)? Or would it make more sense to drawOn: aCanvas withScale: aScale as a morph could have multiple views, at different scales? I favor the latter. $0.02, -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
Hi Ken. Right now I'm moving across town. I won't have network access for a while. I don't have my laptop here right now, and don't have Internet at the new place yet, so I won't be able to look at the code I wrote for awhile.
Since you have a preference here, if you've got the time and are willing, and no one is raising an objection, I'd like to strongly urge you to make the change. That code doesn't belong to me. It belongs to the community. Thanks for digging deep, Casey On Oct 31, 2013, at 2:17 PM, Ken Dickey <[hidden email]> wrote: > On Wed, 30 Oct 2013 12:22:47 -0700 > Casey Ransberger <[hidden email]> wrote: > >> This irked me when I was writing the miserable thing. There should be a general facility that can inform a morph about the dimensions of the screen, which can tell that morph that the screen's dimensions have changed, without using stepping. > > Aside from the #screenSizeChanged (or whatever) event, would it make sense to trigger a #morphScaleChanged when a morph is rescaled (e.g. to the taskbar)? > > Or would it make more sense to > drawOn: aCanvas withScale: aScale > as a morph could have multiple views, at different scales? > > I favor the latter. > $0.02, > -KenD > > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
On Fri, 1 Nov 2013 02:45:25 -0700
Casey Ransberger <[hidden email]> wrote: > Thanks for digging deep, Ah! No wonder I'm covered with dirt and mud. ;) _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
In reply to this post by KenDickey
On 10/31/2013 6:17 PM, Ken Dickey wrote:
> On Wed, 30 Oct 2013 12:22:47 -0700 > Casey Ransberger<[hidden email]> wrote: > >> This irked me when I was writing the miserable thing. There should be a general facility that can inform a morph about the dimensions of the screen, which can tell that morph that the screen's dimensions have changed, without using stepping. > Aside from the #screenSizeChanged (or whatever) event, would it make sense to trigger a #morphScaleChanged when a morph is rescaled (e.g. to the taskbar)? > > Or would it make more sense to > drawOn: aCanvas withScale: aScale > as a morph could have multiple views, at different scales? > > I favor the latter. > $0.02, > -KenD > Hi Ken, This is the kind of stuff I'd like to make possible in Morphic 3. There could be various views (Displays) on the same World or subworlds of it. We need to come up with a design that makes this easy. Right now, the #drawOn: message doesn't need a scale, because the coordinate transformation from the Morph's to Display's is built into the Canvas. Please take a look at ivars transformations, currentTransformation, and cti in FormCanvas. (This was the hardest part of making each morph have its own coordinate system, as it is right now in Cuis, even if scaling doesn't work properly yet). Maybe a good solution would be to have different Canvases for each display. Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
KenD> >
> > Or would it make more sense to > > drawOn: aCanvas withScale: aScale > > as a morph could have multiple views, at different scales? Juan Vuletich> > Right now, the #drawOn: message doesn't need a scale, because the > coordinate transformation from the Morph's to Display's is built into > the Canvas. The idea was that the morph being rendered might present a different display at a different resolution/scale. Hence the need for a scale argument. An analog clock, when small, is harder to read than the digital equivalent. Google Earth uses different images as resolutions change, ... Anyway, not our problem this week. Cheers, -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
Hi Ken,
On 11/2/2013 11:48 PM, Ken.Dickey wrote: > KenD> > >>> Or would it make more sense to >>> drawOn: aCanvas withScale: aScale >>> as a morph could have multiple views, at different scales? > Juan Vuletich> >> Right now, the #drawOn: message doesn't need a scale, because the >> coordinate transformation from the Morph's to Display's is built into >> the Canvas. > The idea was that the morph being rendered might present a different display at a different resolution/scale. Hence the need for a scale argument. > > An analog clock, when small, is harder to read than the digital equivalent. Google Earth uses different images as resolutions change, ... > > Anyway, not our problem this week. > > Cheers, > -KenD > Yes, I see. Sometimes something like that will be needed, and that breaks the simplicity and uniformity of the ZUI. This is one of the _really_ interesting problems we'll face once Morphic 3 is out. Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Free forum by Nabble | Edit this page |