January 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Detect when Pharo loses focus

by Torsten Bergmann

That is not supported by default (at least not on Win). Since you switch to another window/process usually this should not be intercepted/prevented by an application. But it is doable using a hook: http://stackoverflow.com/questions/1161053/capturing-keystrokes-without-foc… http://stackoverflow.com/questions/1346689/how-do-i-trap-windows-key-alttab… Bye T. > Gesendet: Montag, 13. Januar 2014 um 12:50 Uhr > Von: "roberto.minelli(a)usi.ch" <roberto.minelli(a)usi.ch> > An: Pharo-dev <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Detect when Pharo loses focus > > I wasnât able to find something like that. > > There is MorphLostFocus, bit is not triggered by World. And not triggered when Pharo loose focus. > > Cheers, > R > > On Jan 13, 2014, at 12:00 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > > > Did World trigger a keyboard focus lost announcement? > > > > Ben > > > > On 13 Jan 2014, at 06:49, roberto.minelli(a)usi.ch wrote: > > > >> Hi guys, > >> > >> I am trying to detect when a user switches her focus from Pharo to another app. > >> > >> In short Iâd like to know when the user switches (i.e., atl+tab) from the Pharo application to another application, losing focus from the development. > >> > >> I looked into Morphic and I was able to tell when the mouse goes outside the Pharo window. > >> Unfortunately this technique does not work when the user uses alt+tab to switch to another app, since the last mouse event is not outside the Pharo window. > >> > >> Any suggestion where to look? > >> > >> Thanks in advance, > >> R > > > > >

Jan. 13, 2014

Re: [Pharo-dev] Pharo 3.0 not responding to mouse or keyboard after launch

by Marcus Denker

On 13 Jan 2014, at 13:10, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: > My friend, you need to believe :)... > > Ok, so with Cuis the image hangs (unresponsive to input) when the clock goes forward. With Pharo 2.0 (just checked), It might be better to check in Pharo3â¦ there where changes e.g. 7444 Synchronizing DateAndTime with system OS date and time https://pharo.fogbugz.com/f/cases/7444 Marcus

Jan. 13, 2014

Re: [Pharo-dev] Pharo 3.0 not responding to mouse or keyboard after launch

by Andres Valloud

(of course, make sure you're online when you re-enable automatic time keeping so that NTP bumps the clock backwards... if not, do it manually) On 1/13/14 4:10 , Andres Valloud wrote: > My friend, you need to believe :)... > > Ok, so with Cuis the image hangs (unresponsive to input) when the clock > goes forward. With Pharo 2.0 (just checked), the image hangs when the > clock goes backwards. To verify, simply create a new process that > periodically writes something to the Transcript, such as > > p := [ > [ > (Delay forSeconds: 1) wait. > Transcript cr; show: Time now seconds printString > ] repeat > ] newProcess. > p resume > > then go to the system settings panel, time section, uncheck the > automatic time keeping, bump the clock up by one minute, save (note the > skew in the Transcript output), then re-enable automatic time keeping, > make sure the settings are saved... and now the image is unresponsive. > Alt+. does nothing etc. Wait one minute. After that time, you will get > a debugger and things will start happening again. > > If you can't immediately reproduce it, I really suspect that if you play > with the time for a bit you will get some weird behavior too. > > On 1/13/14 1:18 , Esteban Lorenzano wrote: >> Hi Andres, >> >> Pharo (Cuis) does not exitâ¦ I suppose you are talking about the vm from Pharo, used with a Cuis imageâ¦ can you confirm that same problem exists in pharo-vm with pharo-image? >> >> Esteban >> >> On 13 Jan 2014, at 09:37, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: >> >>> Try the following on OS X... >>> >>> 1. Launch Pharo (Cuis). >>> >>> 2. Go to the System Settings time panel. >>> >>> 3. Disable automatic time updates. >>> >>> 4. Bump the clock forward by 1 minute. >>> >>> 5. Check whether Pharo is still responsive (in the case of Cuis, it's frozen). >>> >>> 6. Wait one minute. >>> >>> 7. Check whether Pharo is still responsive (in the case of Cuis, it's responsive again). >>> >>> >>> As a variation, disable automatic time updates, then bump the clock backwards by 1 minute. Things still work. Then re-enable automatic time updates. When the clock goes forward, the prediction is that Pharo (Cuis) will be frozen for 1 minute. >>> >>> If this repeats for you, then also look at /var/log/system.log and see how many entries are there for NTP. If you see that NTP periodically adjusts the clock forward, then you can also expect that Pharo (Cuis) will periodically be frozen for as much time as NTP (and, on OS X 10.9, pacemaker) bumps the clock forward. >>> >>> I can reproduce this behavior on OS X 10.9 with a modern Cog VM and Cuis images. >>> >>> On 1/13/14 0:22 , Sven Van Caekenberghe wrote: >>>> Hi Andres, >>>> >>>> Could you describe in some detail how to make something clearly fail related to this issue ? >>>> >>>> There have been mysterious time(r) related problems in the past, it would be good to follow up on something concrete and repeatable. >>>> >>>> Thx, >>>> >>>> Sven >>>> >>>> On 12 Jan 2014, at 04:41, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: >>>> >>>>> Somewhat related only, but FYI something I've noticed with Cog VMs is that if you bump the computer clock forward by e.g. 30 seconds then Cuis remains frozen for 30 seconds. Under the assumption that Cuis and Pharo are close enough, and considering that alt+. does not bring up a debugger while the image remains frozen, I can't help asking whether the VM is setting up OS alarms at a certain wall clock hour instead of setting up timers that expire after N time has elapsed (irrespective of the wall clock). If the VM is setting up alarms at wall clock hours, then I'd strongly suggest changing that behavior because of NTP, time zone adjustments, etc. >>>>> >>>>> BTW, I found this because apparently Mavericks isn't keeping time that great and NTP frequently changes the clock by ~2 seconds. >>>>> >>>>> On 1/11/14 19:29 , Martin McClure wrote: >>>>>> I'm beginning to suspect that delays are not expiring at the OS level >>>> >>>> . >>>> >>> >> >> >> . >> > > . >

Jan. 13, 2014

Re: [Pharo-dev] ZeroConf on ubuntu linux

by Sven Van Caekenberghe

On 13 Jan 2014, at 13:04, Michael J. Forster <mike(a)sharedlogic.ca> wrote: > On 14-01-13 12:27 AM, Sven Van Caekenberghe wrote: > [...] >> It might be needed for portability, but who says "those platforms aren't implementing mktemp(3) exactly", against which spec ? > > > Hi Sven, > > It's the library function mktemp(3), not the command mktemp(1), that specifies the template length, and it conforms to both BSD and POSIX: > > http://man7.org/linux/man-pages/man3/mktemp.3.html > http://www.openbsd.org/cgi-bin/man.cgi?sektion=3&query=mktemp > > Accordingly, "mktemp -d foo.XXXXXX" should work on all POSIX/BSD platforms, and it does on my various FreeBSD, OpenBSD, Slackware, and Ubuntu boxes. Likewise, "mktemp -d foo.XXXXX" _could_ fail, and it does on three of my boxes. OK, than we better change the script. Camillo, where do we change this best ? > Cheers, > > Mike > > -- > Michael J. Forster, B.Sc. (Hons.), B.Sc. > COO, Programmer > Shared Logic Inc. >

Jan. 13, 2014

Re: [Pharo-dev] Pharo 3.0 not responding to mouse or keyboard after launch

by Andres Valloud

My friend, you need to believe :)... Ok, so with Cuis the image hangs (unresponsive to input) when the clock goes forward. With Pharo 2.0 (just checked), the image hangs when the clock goes backwards. To verify, simply create a new process that periodically writes something to the Transcript, such as p := [ [ (Delay forSeconds: 1) wait. Transcript cr; show: Time now seconds printString ] repeat ] newProcess. p resume then go to the system settings panel, time section, uncheck the automatic time keeping, bump the clock up by one minute, save (note the skew in the Transcript output), then re-enable automatic time keeping, make sure the settings are saved... and now the image is unresponsive. Alt+. does nothing etc. Wait one minute. After that time, you will get a debugger and things will start happening again. If you can't immediately reproduce it, I really suspect that if you play with the time for a bit you will get some weird behavior too. On 1/13/14 1:18 , Esteban Lorenzano wrote: > Hi Andres, > > Pharo (Cuis) does not exitâ¦ I suppose you are talking about the vm from Pharo, used with a Cuis imageâ¦ can you confirm that same problem exists in pharo-vm with pharo-image? > > Esteban > > On 13 Jan 2014, at 09:37, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: > >> Try the following on OS X... >> >> 1. Launch Pharo (Cuis). >> >> 2. Go to the System Settings time panel. >> >> 3. Disable automatic time updates. >> >> 4. Bump the clock forward by 1 minute. >> >> 5. Check whether Pharo is still responsive (in the case of Cuis, it's frozen). >> >> 6. Wait one minute. >> >> 7. Check whether Pharo is still responsive (in the case of Cuis, it's responsive again). >> >> >> As a variation, disable automatic time updates, then bump the clock backwards by 1 minute. Things still work. Then re-enable automatic time updates. When the clock goes forward, the prediction is that Pharo (Cuis) will be frozen for 1 minute. >> >> If this repeats for you, then also look at /var/log/system.log and see how many entries are there for NTP. If you see that NTP periodically adjusts the clock forward, then you can also expect that Pharo (Cuis) will periodically be frozen for as much time as NTP (and, on OS X 10.9, pacemaker) bumps the clock forward. >> >> I can reproduce this behavior on OS X 10.9 with a modern Cog VM and Cuis images. >> >> On 1/13/14 0:22 , Sven Van Caekenberghe wrote: >>> Hi Andres, >>> >>> Could you describe in some detail how to make something clearly fail related to this issue ? >>> >>> There have been mysterious time(r) related problems in the past, it would be good to follow up on something concrete and repeatable. >>> >>> Thx, >>> >>> Sven >>> >>> On 12 Jan 2014, at 04:41, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: >>> >>>> Somewhat related only, but FYI something I've noticed with Cog VMs is that if you bump the computer clock forward by e.g. 30 seconds then Cuis remains frozen for 30 seconds. Under the assumption that Cuis and Pharo are close enough, and considering that alt+. does not bring up a debugger while the image remains frozen, I can't help asking whether the VM is setting up OS alarms at a certain wall clock hour instead of setting up timers that expire after N time has elapsed (irrespective of the wall clock). If the VM is setting up alarms at wall clock hours, then I'd strongly suggest changing that behavior because of NTP, time zone adjustments, etc. >>>> >>>> BTW, I found this because apparently Mavericks isn't keeping time that great and NTP frequently changes the clock by ~2 seconds. >>>> >>>> On 1/11/14 19:29 , Martin McClure wrote: >>>>> I'm beginning to suspect that delays are not expiring at the OS level >>> >>> . >>> >> > > > . >

Jan. 13, 2014

Re: [Pharo-dev] ZeroConf on ubuntu linux

by Michael J. Forster

On 14-01-13 12:27 AM, Sven Van Caekenberghe wrote: [...] > It might be needed for portability, but who says "those platforms aren't implementing mktemp(3) exactly", against which spec ? Hi Sven, It's the library function mktemp(3), not the command mktemp(1), that specifies the template length, and it conforms to both BSD and POSIX: http://man7.org/linux/man-pages/man3/mktemp.3.html http://www.openbsd.org/cgi-bin/man.cgi?sektion=3&query=mktemp Accordingly, "mktemp -d foo.XXXXXX" should work on all POSIX/BSD platforms, and it does on my various FreeBSD, OpenBSD, Slackware, and Ubuntu boxes. Likewise, "mktemp -d foo.XXXXX" _could_ fail, and it does on three of my boxes. Cheers, Mike -- Michael J. Forster, B.Sc. (Hons.), B.Sc. COO, Programmer Shared Logic Inc.

Jan. 13, 2014

Re: [Pharo-dev] Do you want to accept???????? Discard???????

by Esteban Lorenzano

On 13 Jan 2014, at 12:56, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > On Jan 13, 2014, at 4:21 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Please do, Sebastian, start discussing about ways to improve the basic UI, you seem to have an interest in the subject. It will of course be quite hard with so many opinions. > > Yeah, I get what you mean but that's hard only if we stay speculating on opinions instead of experiments and tests and data. > > One or two experiments solves any UI dispute in an afternoon (ok maybe two). > > The least I can do is to help our community to get our discussion started. > > Probably as a naive attempt towards those experiments. > > So question, I am the only one interested in an improved Pharo user experience? of course not :) > > sebastian > > o/ > >

Jan. 13, 2014

Re: [Pharo-dev] Do you want to accept???????? Discard???????

by Sebastian Sastre

On Jan 13, 2014, at 4:21 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Please do, Sebastian, start discussing about ways to improve the basic UI, you seem to have an interest in the subject. It will of course be quite hard with so many opinions. Yeah, I get what you mean but that's hard only if we stay speculating on opinions instead of experiments and tests and data. One or two experiments solves any UI dispute in an afternoon (ok maybe two). The least I can do is to help our community to get our discussion started. Probably as a naive attempt towards those experiments. So question, I am the only one interested in an improved Pharo user experience? sebastian o/

Jan. 13, 2014

Re: [Pharo-dev] Detect when Pharo loses focus

by roberto.minelli＠usi.ch

I wasnât able to find something like that. There is MorphLostFocus, bit is not triggered by World. And not triggered when Pharo loose focus. Cheers, R On Jan 13, 2014, at 12:00 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > Did World trigger a keyboard focus lost announcement? > > Ben > > On 13 Jan 2014, at 06:49, roberto.minelli(a)usi.ch wrote: > >> Hi guys, >> >> I am trying to detect when a user switches her focus from Pharo to another app. >> >> In short Iâd like to know when the user switches (i.e., atl+tab) from the Pharo application to another application, losing focus from the development. >> >> I looked into Morphic and I was able to tell when the mouse goes outside the Pharo window. >> Unfortunately this technique does not work when the user uses alt+tab to switch to another app, since the last mouse event is not outside the Pharo window. >> >> Any suggestion where to look? >> >> Thanks in advance, >> R >

Jan. 13, 2014

Re: [Pharo-dev] [FEEDBACK] Install Pharo on Windows

by kilon alios

works like a charm here, Win7 64 bit. It even sees my pre existing images which I downloaded with another pharolauncher. On Mon, Jan 13, 2014 at 12:38 PM, Erwan Douaille <douailleerwan(a)gmail.com>wrote: > Hi ! > > I just try it, works well on windows 8.1 ;) > Pharo launcher is very impressive ! Great job :) > > > 2014/1/7 <btc(a)openinworld.com> > > Damien Cassou wrote: >> >>> Hi, >>> >>> I've just made an executable file for installing Pharo on Windows (in >>> program files, with a shortcut in the Start menu...). Please try >>> it and report problems: >>> >>> https://ci.inria.fr/pharo-contribution/job/PharoLauncher-Win-Package/ >>> lastSuccessfulBuild/artifact/pharo-ci/pharo_installer.exe >>> >>> >> Thats great Damien. I installed and ran it without a hitch. I installed >> as a "Standard User" "Ben" which UAC then asked for to upgrade credentials >> to my admin account "BenAdmin" to perform the install. >> It picked up my existing images using Pharo. I updated the templates, >> created and launched a new image. It even kept my the template list >> between restarts of Pharo Launcher with the preference "Templates cleared >> at startup" disabled - which is very cool. >> Now from the Start menu > All Programs > Pharo folder >> I felt a bit awkward clicking on Pharo when I knew it was actually >> PharoLauncher. I think it would be good to keep the distinction between >> Pharo the programming environment and PharoLauncher the application. >> People should not be developing their own applications inside Pharo >> Launcher, but should be developing inside Pharo images started from Pharo >> Launcher. >> >> The folder and file security settings look good and tight - for the image >> and changes files the Users group has Read & Execute only with no Write >> permissions. However I'm mildly concerned that changes in the image (such >> as setting the debug flag and opening tools) persist - and also mildly >> annoyed with myself that I can't work out how its happening. Attila Magyar >> wrote: >> >>> Tried it and worked fine on Windows 7. Though, I had few issues with the >>> launcher. >>> >>> When I right click on an empty area of the Existing Images panel (and >>> there >>> is no image selected or the pane is empty), I got a MessageNotUnderstood: >>> receiver of buildWithSpec is nil. >>> >>> >> >> A fix is to change TreeModel>>menu:shifted: >> from... >> (self allowMenuOnNoItem not and: [ self selectedItems isEmpty ]) >> ifTrue: [ ^ nil ]. >> >> to... >> (self allowMenuOnNoItem not and: [ self selectedItems isEmpty ]) >> ifTrue: [ ^ MenuModel new ]. >> >> but I am not sure of the wider implications, or if a bug should be logged >> for Launcher or Spec. >> >> gotta run now, so other people can sleep. >> cheers -ben >> >> After I renamed an image, I got a DirectoryDoesNotExist with a path >>> pointing >>> to the old directory. But I can't reproduce it anymore. >>> >>> >>> >>> >>> >> >> >> > > > -- > Best regards, > > Douaille Erwan <douaille.erwan(a)gmail.com> >

Jan. 13, 2014