+1
Stef On Mar 31, 2010, at 9:29 AM, Marcus Denker wrote: > > On Mar 31, 2010, at 9:25 AM, John M McIntosh wrote: > >> Well 5.0 is still in Alpha. >> Feedback is slow, so the issue is how to drive acceptance? >> > > I suggest to release 1.0 with the altest 4er Mac VM, than advacate 5.0 for 1.1. > > Marcus > >> The problem with the 64bit VM with 32bit images is that all the plugins have to be recompiled. Mind I did do the FreeType one. >> However I was thinking that we could run the 5.0 VM in 32bit mode and use the existing plugins to minimize impact. >> >> On 2010-03-30, at 11:46 PM, Stéphane Ducasse wrote: >> >>> John >>> >>> it is really important that 1.0 is working very well so we can start pushing 5.0 for 1.1. >>> Now >>> who is using 5.0 ? >>> what are the problem left? I got some glitches like not been able to open two images but this was >>> at the beginning. Now I thought that 5.0 was not officially out. >>> >>> Stef >>> >>> >>> On Mar 29, 2010, at 9:47 PM, John M McIntosh wrote: >>> >>>> Frankly in all of this perhaps we should consider the use of the Version 5. 0 macintosh cocoa VM running in 32bit mode? >>> >> >> -- >> =========================================================================== >> John M. McIntosh <[hidden email]> Twitter: squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> =========================================================================== >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by johnmci
On Mar 31, 2010, at 9:25 33AM, John M McIntosh wrote:
Here's a little feedback on the building-from-svn part (for rev 193, not sure if you plan on consolidating that with the 5.0 releases or not, in that case just ignore the last part): - MainWindow.xib is included in resources for both PureObjC targets , it is not needed, and causes an error if you try to build without the iPhone libs installed. (i.e. a "vanilla" xcode install) - SqueakOSXAppDelegate.m complains sqSqueakOSXInfoPlistInterface is undeclared, adding #import "sqSqueakOSXInfoPlistInterface.h" fixes it, not sure if you feel that's the approriate place though. - the #error THIS IS BROKEN... labelled code could be written as attached, to work with width/height which are non-multiples of four. (in short, save dividedWidth/Height as floats, as per their definitions, and use the rounded value of end- start coords as width/height instead. ) After that, it still won't work, of course :) It seems the underlying bitmap is not updated when a resize occurs, and there's still a multiple-of-four error somewhere (e.g. my stored window size was 1133x761, but the underlying bitmap for opened window seemed to be 1132x761, which leads to a tilted initial view) Cheers, Henry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project OSXNSViewsetFrame.zip (1K) Download Attachment |
Thank you very much for the work. Given your efforts I proceeded to spend a couple of hours again today to resolve the problem. I took a slightly different approach and made a number of changes to properly deal with the window size not working properly when the size is not a multiple of four. .
I've checked these changes into the V5 tree. You should check out the current source and see what changed. It does draw the window properly now even when the window size is not a multiple of 4. However there is some work to resolve what to do when the window is in live resize. What happens now is that it appears to display pixels from video memory as it's attempting to resize the window size. I'm not quite sure exactly *why* it's wrong yet. One of the problems is that the window size changes, but the display buffer in squeak doesn't change right away. It's possible we may have to show a snapshot of the screen surface when the resize starts, then update it after the resize terminates. On the other hand the side effect is interesting, as long as it doesn't crash it's not high on the list to fix. On 2010-03-31, at 6:07 AM, Henrik Johansen wrote: sqSqueakOSXInfoPlistInterface.h -- =========================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project smime.p7s (3K) Download Attachment |
Free forum by Nabble | Edit this page |