Menu
▾
▴
squeak-vmdev — CVS-related Virtual Machine Development Issues
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(54) |
Jun
(3) |
Jul
|
Aug
(23) |
Sep
(33) |
Oct
(14) |
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
|
Jul
|
Aug
(15) |
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
(1) |
Feb
|
Mar
(26) |
Apr
(130) |
May
(5) |
Jun
|
Jul
(21) |
Aug
(3) |
Sep
(24) |
Oct
(10) |
Nov
(37) |
Dec
(2) |
| 2005 |
Jan
(30) |
Feb
(15) |
Mar
(4) |
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
(2) |
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(10) |
| 2007 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Yoshiki O. <Yos...@ac...> - 2004-10-08 01:46:16
|
Andreas, > Please, keep it simple. The question at hand was whether we need to > distinguish between various (potentially differing) encodings or not. Has > this question be sufficiently answered? Ah, yes. read-only attribute is ok, and different encodings for file names, clipboard, and keyboard input (and default system encoding for file contents) is necessary. -- Yoshiki |
|
From: Andreas R. <and...@gm...> - 2004-10-05 02:00:24
|
Hi Guys, Please, keep it simple. The question at hand was whether we need to distinguish between various (potentially differing) encodings or not. Has this question be sufficiently answered? Cheers, - Andreas ----- Original Message ----- From: "Yoshiki Ohshima" <Yos...@ac...> To: "Squeak VM Developers" <squ...@li...> Sent: Monday, October 04, 2004 5:32 PM Subject: Re: [Squeak-VMdev] Proposal: VM string encoding > Bert, > >> Okay. But how should the VM know which one is actually in use? I don't >> know any system call to get a character set. > > It is often the case that there is no perfectly reliable way. > Reading the environment variables that the IM and window systems use > is the common way. > > (Did I write EUC for clipboard? The native encoding was > "x-compound-text"...) > >> >> Or can the encoding differ for distinct clipboard accesses or filename >> >> uses? If the latter, then a VM attribute would not be optimal. >> > >> > For file name, it has to be set in the earlier stage of VM >> > invocation, but the clipboard and keyboard input can be set later. >> > So, potentially read-write VM attributes would do it. >> >> ... so why would we need to *set* it if it's constant? Can't the >> conversion happen on the image side? > > Yes, it does and it doesn't have to be a read-write attribute. (Note > the word "potentially".) But if the VM and underlying system support, > both X Compound Text and UTF-8 for clipboard encoding, it would be > nice if we can explicitly set to use UTF-8 so that wider set of > characters can be handled. > > I admit that setting the encoding concept could introduce more > headache, though... > > -- Yoshiki > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out > more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Squeak-VMdev mailing list > Squ...@li... > https://lists.sourceforge.net/lists/listinfo/squeak-vmdev > |
|
From: Yoshiki O. <Yos...@ac...> - 2004-10-05 00:35:28
|
John and Bert, > > Hi, have you tried altering the Info.plist in the Squeak VM ? > > > > key is SqueakEncodingType > > value right now is macintosh > > > > but could it be > > ShiftJIS > > or > > UTF-8 Ah, I think this is how the VM distributed in the japanese distribution for Mac. My understanding must have been obsolete. -- Yoshiki |
|
From: Yoshiki O. <Yos...@ac...> - 2004-10-05 00:35:27
|
Bert, > Okay. But how should the VM know which one is actually in use? I don't > know any system call to get a character set. It is often the case that there is no perfectly reliable way. Reading the environment variables that the IM and window systems use is the common way. (Did I write EUC for clipboard? The native encoding was "x-compound-text"...) > >> Or can the encoding differ for distinct clipboard accesses or filename > >> uses? If the latter, then a VM attribute would not be optimal. > > > > For file name, it has to be set in the earlier stage of VM > > invocation, but the clipboard and keyboard input can be set later. > > So, potentially read-write VM attributes would do it. > > ... so why would we need to *set* it if it's constant? Can't the > conversion happen on the image side? Yes, it does and it doesn't have to be a read-write attribute. (Note the word "potentially".) But if the VM and underlying system support, both X Compound Text and UTF-8 for clipboard encoding, it would be nice if we can explicitly set to use UTF-8 so that wider set of characters can be handled. I admit that setting the encoding concept could introduce more headache, though... -- Yoshiki |
|
From: John M M. <jo...@sm...> - 2004-10-04 02:49:31
|
On Oct 3, 2004, at 2:51 AM, Bert Freudenberg wrote: >>> key is SqueakEncodingType >>> value right now is macintosh >>> >>> but could it be >>> ShiftJIS >>> or >>> UTF-8 > > And this is a single global value applying to all operations, right? I > just grep'ed for gCurrentVMEncoding and it seems to be used all over > the place. > > - Bert - Yes but if you look closer you'll see it's only used for file name operations. -- ======================================================================== === John M. McIntosh <jo...@sm...> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
|
From: Bert F. <be...@im...> - 2004-10-03 09:51:53
|
Am 03.10.2004 um 02:02 schrieb John M McIntosh: > On Oct 2, 2004, at 11:29 AM, Bert Freudenberg wrote: > >> Hmm, can't comment on that ... John? > > Well I did, but it only went to Yoshiki Okay. I just noticed Yoshiki is subscribed here, too, so we do not need to cc: him. > Begin forwarded message: > >> From: John M McIntosh <jo...@sm...> >> Hi, have you tried altering the Info.plist in the Squeak VM ? >> >> key is SqueakEncodingType >> value right now is macintosh >> >> but could it be >> ShiftJIS >> or >> UTF-8 And this is a single global value applying to all operations, right? I just grep'ed for gCurrentVMEncoding and it seems to be used all over the place. - Bert - |
|
From: John M M. <jo...@sm...> - 2004-10-03 00:03:51
|
On Oct 2, 2004, at 11:29 AM, Bert Freudenberg wrote: >> > > Hmm, can't comment on that ... John? Well I did, but it only went to Yoshiki Begin forwarded message: > From: John M McIntosh <jo...@sm...> > Date: October 1, 2004 8:29:48 PM PDT > To: Yoshiki Ohshima <Yos...@ac...> > Subject: Re: [Squeak-VMdev] Proposal: VM string encoding > > Hi, have you tried altering the Info.plist in the Squeak VM ? > > key is SqueakEncodingType > value right now is macintosh > > but could it be > ShiftJIS > or > UTF-8 -- ======================================================================== === John M. McIntosh <jo...@sm...> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |
|
From: Bert F. <be...@im...> - 2004-10-02 18:30:35
|
Am 02.10.2004 um 02:47 schrieb Yoshiki Ohshima: > Bert, > >>> We'll need a way to use possibly different encodings for: >>> >>> * File name >>> * clipboard >>> * keyboard input >>> and possibly >>> * default system encoding >>> >>> Assigning 1006 through 1008 would be good. >> >> Can you describe the circumstances when these encodings are different >> from the default encoding? > > It is rather typical in this part of the world on Unices. Older > systems tend to use EUC and newer ones usually trys to use Unicode, > but often those are mixed in one environment and possibly all > combinations can exist. Okay. But how should the VM know which one is actually in use? I don't know any system call to get a character set. > I don't know too much about Mac, but as far > as I know, it has different set of file access APIs and none of them > is good enough to be used exclusively. That is why (as far as I > heard) the Japanese Squeak running on Mac OS X cannot use the Japanese > image file name because at first the VM uses the MacRoman version of > file name. Hmm, can't comment on that ... John? >> Are they at least constant over a session? > > Yes. We can assume this. okay ... >> Or can the encoding differ for distinct clipboard accesses or filename >> uses? If the latter, then a VM attribute would not be optimal. > > For file name, it has to be set in the earlier stage of VM > invocation, but the clipboard and keyboard input can be set later. > So, potentially read-write VM attributes would do it. ... so why would we need to *set* it if it's constant? Can't the conversion happen on the image side? - Bert - |
|
From: Yoshiki O. <Yos...@ac...> - 2004-10-02 00:49:44
|
Bert, > > We'll need a way to use possibly different encodings for: > > > > * File name > > * clipboard > > * keyboard input > > and possibly > > * default system encoding > > > > Assigning 1006 through 1008 would be good. > > Can you describe the circumstances when these encodings are different > from the default encoding? It is rather typical in this part of the world on Unices. Older systems tend to use EUC and newer ones usually trys to use Unicode, but often those are mixed in one environment and possibly all combinations can exist. I don't know too much about Mac, but as far as I know, it has different set of file access APIs and none of them is good enough to be used exclusively. That is why (as far as I heard) the Japanese Squeak running on Mac OS X cannot use the Japanese image file name because at first the VM uses the MacRoman version of file name. > Are they at least constant over a session? Yes. We can assume this. > Or can the encoding differ for distinct clipboard accesses or filename > uses? If the latter, then a VM attribute would not be optimal. For file name, it has to be set in the earlier stage of VM invocation, but the clipboard and keyboard input can be set later. So, potentially read-write VM attributes would do it. -- Yoshiki |
|
From: Bert F. <be...@im...> - 2004-10-01 21:32:58
|
Am 29.09.2004 um 01:33 schrieb Yoshiki Ohshima: > Hello, > > At Tue, 28 Sep 2004 12:20:03 +0200, > Bert Freudenberg wrote: >> >> Folks, >> >> I discussed this with Michael a bit and we came up with this proposal: >> >> * Add a new system attribute 1006 returning a string describing the >> expected VM string encoding (http://minnow.cc.gatech.edu/squeak/314). >> * Values are "UTF-8", "macintosh", "ISO-8859-1", etc. (exact spelling >> as in http://www.iana.org/assignments/character-sets). >> * If attribute 1006 is not supported, assume "macintosh". >> >> Using an attribute instead of a primitive seems simpler than a new >> primitive. >> >> I'm not sure but I think it's possible to have filesystem-specific >> file >> name encodings under Unix. If neccessary, we should add a primitive to >> FilePlugin to answer the encoding for a particular directory, using >> the >> same values as described above. Anyway, we probably can leave that to >> later. > > We'll need a way to use possibly different encodings for: > > * File name > * clipboard > * keyboard input > and possibly > * default system encoding > > Assigning 1006 through 1008 would be good. Can you describe the circumstances when these encodings are different from the default encoding? Are they at least constant over a session? Or can the encoding differ for distinct clipboard accesses or filename uses? If the latter, then a VM attribute would not be optimal. - Bert - |
|
From: Yoshiki O. <Yos...@ac...> - 2004-09-28 23:34:17
|
Hello, At Tue, 28 Sep 2004 12:20:03 +0200, Bert Freudenberg wrote: > > Folks, > > I discussed this with Michael a bit and we came up with this proposal: > > * Add a new system attribute 1006 returning a string describing the > expected VM string encoding (http://minnow.cc.gatech.edu/squeak/314). > * Values are "UTF-8", "macintosh", "ISO-8859-1", etc. (exact spelling > as in http://www.iana.org/assignments/character-sets). > * If attribute 1006 is not supported, assume "macintosh". > > Using an attribute instead of a primitive seems simpler than a new > primitive. > > I'm not sure but I think it's possible to have filesystem-specific file > name encodings under Unix. If neccessary, we should add a primitive to > FilePlugin to answer the encoding for a particular directory, using the > same values as described above. Anyway, we probably can leave that to > later. We'll need a way to use possibly different encodings for: * File name * clipboard * keyboard input and possibly * default system encoding Assigning 1006 through 1008 would be good. I like the symbolic name idea, and vm attribute sounds good to me. Thank you for the proposal. I once signed up to implement it, but didn't quite get my hands on it. -- Yoshiki |
|
From: Bert F. <be...@im...> - 2004-09-28 13:42:53
|
Glad to hear that :) One thing I forgot to mention against our proposal was that a new=20 primitive would allow the VM to know it's dealing with a new image. Old=20= images could still be delivered the macintosh encoding they expect. But=20= maybe the VM could detect that through other means. Don't know if=20 that's even a real issue. - Bert - Am 28.09.2004 um 14:50 schrieb Andreas Raab: > Sounds good to me. > > Cheers, > - A. > > ----- Original Message ----- From: "Bert Freudenberg" <be...@im...> > To: <squ...@li...> > Cc: "Michael R=FCger" <mi...@im...>; "Yoshiki Ohshima"=20 > <Yos...@ac...> > Sent: Tuesday, September 28, 2004 3:20 AM > Subject: [Squeak-VMdev] Proposal: VM string encoding > > > Folks, > > I discussed this with Michael a bit and we came up with this proposal: > > * Add a new system attribute 1006 returning a string describing the > expected VM string encoding (http://minnow.cc.gatech.edu/squeak/314). > * Values are "UTF-8", "macintosh", "ISO-8859-1", etc. (exact spelling > as in http://www.iana.org/assignments/character-sets). > * If attribute 1006 is not supported, assume "macintosh". > > Using an attribute instead of a primitive seems simpler than a new > primitive. > > I'm not sure but I think it's possible to have filesystem-specific = file > name encodings under Unix. If neccessary, we should add a primitive to > FilePlugin to answer the encoding for a particular directory, using = the > same values as described above. Anyway, we probably can leave that to > later. > > - Bert - > > Am 27.09.2004 um 02:54 schrieb Andreas Raab: > >> John, >> >> We talked about this in the past - we need to do something to figure=20= >> out what the primitives expect in their stringy interfaces (file=20 >> names, clipboard, etc). I'm still in favour of having a primitive=20 >> which answers the VM's expected encoding and defaults to MacRoman=20 >> (which is indeed what I think most VMs actually use). After which we=20= >> can start playing with using UTF8 or Latin1 or whatever else (I could=20= >> easily imagine that an Eastern European VM uses a different encoding=20= >> than a Far East VM). >> >> Cheers, >> - Andreas >> >> PS. I bought a Really, Really Good (tm) coffee maker today. It's just=20= >> unbelievable how good coffee can be (heh, heh). >> >> ----- Original Message ----- From: "John M McIntosh"=20 >> <jo...@sm...> >> To: "The general-purpose Squeak developers list"=20 >> <squ...@li...> >> Sent: Sunday, September 26, 2004 3:43 PM >> Subject: Re: umlaute in squeak? >> >> >> I think for this we need cut/copy/paste primitives that understand >> unicode >> Yell louder, I'm sure it exists in the OS api, just no-one has looked >> at it yet... >> This would imply that m17n would need to handle things. I'd think one >> could change the methods to >> figure out if the VM supports unicode cut/copy/paste and do the right >> thing... >> >> Perhaps one could even be convinced to allow for other types of data=20= >> on >> the clipboard (pictures?) >> >> On Sep 26, 2004, at 11:18 AM, Bert Freudenberg wrote: >> >>> Yep, there are still some open ends in m17n, mostly VM related. For=20= >>> example, cut and paste from external sources shredders umlauts=20 >>> (tested on Win and Mac), and file names in the file list do not look=20= >>> right (although, on the Mac at least they can still be accessed). >>> >>> - Bert - >>> >>> Am 26.09.2004 um 19:26 schrieb Martin Kuball: >>> >>>> Hi! >>>> >>>> After some digging in the source code I found the problem. I'm=20 >>>> using a >>>> utf8 locale and that produces 2 byte characters for the special >>>> german characters. But the vm uses only the 1st byte. This explains >>>> why I always see the same character for different umlaut = characters. >>>> They always have the same 1st byte and differ only in the 2nd byte. >>>> >>>> I will try to work out a solution (other than changing the locale, >>>> because I think it should work out of the box in as many=20 >>>> environments >>>> as possible) >>>> >>>> Martin >>>> >>>> >>>> Am Monday 20 September 2004 11:12 schrieb danil a. osipchuk: >>>>> Hi, Martin >>>>> >>>>> It seems that you are using unix vm. I've solved the issue by >>>>> editing sqUnixX11.c and setting there: >>>>> static x2sqKey_t x2sqKey=3D x2sqKeyInput; >>>>> (it's x2sqKeyPlain by default in sources on Ian site). I also have >>>>> built some fonts from TTF (russian in my case). >>>>> After rebuilding vm I've got squeak with russian fonts. >>>>> I hope that things will be less complicated when m17n project will >>>>> be included in core Squeak. Also, there are a plenty of German >>>>> squeakers here - may be they will point the shortest path. >>>>> Danil >>>>> >>>>>> Am Saturday 18 September 2004 23:13 schrieb Bernhard Pieber: >>>>>>> Martin Kuball <Mar...@we...> wrote: >>>>>>>> Is it possible to enter non 7bit characters like german umlaute >>>>>>>> into squeak text fields? When I type one of these (s=DDS...) I >>>>>>>> only get an A with a ~ above it. >>>>>>> >>>>>>> What do you mean by squeak text fields? I just tried it in a >>>>>>> workspace in 3.7 and 3.8alpha and there it works. Which version >>>>>>> of Squeak and which font did you use? >>>>>> >>>>>> With text field I mean any morph where you can enter text. I = tried >>>>>> with the new 3.7full and the standard font. By the way it has >>>>>> never worked for me. I even tried the Windows version once but it >>>>>> showed the same behaviour. >>>>>> >>>>>> Martin |
|
From: Andreas R. <and...@gm...> - 2004-09-28 12:51:24
|
Sounds good to me. Cheers, - A. ----- Original Message -----=20 From: "Bert Freudenberg" <be...@im...> To: <squ...@li...> Cc: "Michael R=FCger" <mi...@im...>; "Yoshiki Ohshima"=20 <Yos...@ac...> Sent: Tuesday, September 28, 2004 3:20 AM Subject: [Squeak-VMdev] Proposal: VM string encoding Folks, I discussed this with Michael a bit and we came up with this proposal: * Add a new system attribute 1006 returning a string describing the expected VM string encoding (http://minnow.cc.gatech.edu/squeak/314). * Values are "UTF-8", "macintosh", "ISO-8859-1", etc. (exact spelling as in http://www.iana.org/assignments/character-sets). * If attribute 1006 is not supported, assume "macintosh". Using an attribute instead of a primitive seems simpler than a new primitive. I'm not sure but I think it's possible to have filesystem-specific file name encodings under Unix. If neccessary, we should add a primitive to FilePlugin to answer the encoding for a particular directory, using the same values as described above. Anyway, we probably can leave that to later. - Bert - Am 27.09.2004 um 02:54 schrieb Andreas Raab: > John, > > We talked about this in the past - we need to do something to figure ou= t=20 > what the primitives expect in their stringy interfaces (file names,=20 > clipboard, etc). I'm still in favour of having a primitive which answer= s=20 > the VM's expected encoding and defaults to MacRoman (which is indeed wh= at=20 > I think most VMs actually use). After which we can start playing with=20 > using UTF8 or Latin1 or whatever else (I could easily imagine that an=20 > Eastern European VM uses a different encoding than a Far East VM). > > Cheers, > - Andreas > > PS. I bought a Really, Really Good (tm) coffee maker today. It's just=20 > unbelievable how good coffee can be (heh, heh). > > ----- Original Message ----- From: "John M McIntosh"=20 > <jo...@sm...> > To: "The general-purpose Squeak developers list"=20 > <squ...@li...> > Sent: Sunday, September 26, 2004 3:43 PM > Subject: Re: umlaute in squeak? > > > I think for this we need cut/copy/paste primitives that understand > unicode > Yell louder, I'm sure it exists in the OS api, just no-one has looked > at it yet... > This would imply that m17n would need to handle things. I'd think one > could change the methods to > figure out if the VM supports unicode cut/copy/paste and do the right > thing... > > Perhaps one could even be convinced to allow for other types of data on > the clipboard (pictures?) > > On Sep 26, 2004, at 11:18 AM, Bert Freudenberg wrote: > >> Yep, there are still some open ends in m17n, mostly VM related. For=20 >> example, cut and paste from external sources shredders umlauts (tested= =20 >> on Win and Mac), and file names in the file list do not look right=20 >> (although, on the Mac at least they can still be accessed). >> >> - Bert - >> >> Am 26.09.2004 um 19:26 schrieb Martin Kuball: >> >>> Hi! >>> >>> After some digging in the source code I found the problem. I'm using = a >>> utf8 locale and that produces 2 byte characters for the special >>> german characters. But the vm uses only the 1st byte. This explains >>> why I always see the same character for different umlaut characters. >>> They always have the same 1st byte and differ only in the 2nd byte. >>> >>> I will try to work out a solution (other than changing the locale, >>> because I think it should work out of the box in as many environments >>> as possible) >>> >>> Martin >>> >>> >>> Am Monday 20 September 2004 11:12 schrieb danil a. osipchuk: >>>> Hi, Martin >>>> >>>> It seems that you are using unix vm. I've solved the issue by >>>> editing sqUnixX11.c and setting there: >>>> static x2sqKey_t x2sqKey=3D x2sqKeyInput; >>>> (it's x2sqKeyPlain by default in sources on Ian site). I also have >>>> built some fonts from TTF (russian in my case). >>>> After rebuilding vm I've got squeak with russian fonts. >>>> I hope that things will be less complicated when m17n project will >>>> be included in core Squeak. Also, there are a plenty of German >>>> squeakers here - may be they will point the shortest path. >>>> Danil >>>> >>>>> Am Saturday 18 September 2004 23:13 schrieb Bernhard Pieber: >>>>>> Martin Kuball <Mar...@we...> wrote: >>>>>>> Is it possible to enter non 7bit characters like german umlaute >>>>>>> into squeak text fields? When I type one of these (s=DDS...) I >>>>>>> only get an A with a ~ above it. >>>>>> >>>>>> What do you mean by squeak text fields? I just tried it in a >>>>>> workspace in 3.7 and 3.8alpha and there it works. Which version >>>>>> of Squeak and which font did you use? >>>>> >>>>> With text field I mean any morph where you can enter text. I tried >>>>> with the new 3.7full and the standard font. By the way it has >>>>> never worked for me. I even tried the Windows version once but it >>>>> showed the same behaviour. >>>>> >>>>> Martin ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Squeak-VMdev mailing list Squ...@li... https://lists.sourceforge.net/lists/listinfo/squeak-vmdev |
|
From: Bert F. <be...@im...> - 2004-09-28 10:19:57
|
Folks, I discussed this with Michael a bit and we came up with this proposal: * Add a new system attribute 1006 returning a string describing = the=20 expected VM string encoding (http://minnow.cc.gatech.edu/squeak/314). * Values are "UTF-8", "macintosh", "ISO-8859-1", etc. (exact = spelling=20 as in http://www.iana.org/assignments/character-sets). * If attribute 1006 is not supported, assume "macintosh". Using an attribute instead of a primitive seems simpler than a new=20 primitive. I'm not sure but I think it's possible to have filesystem-specific file=20= name encodings under Unix. If neccessary, we should add a primitive to=20= FilePlugin to answer the encoding for a particular directory, using the=20= same values as described above. Anyway, we probably can leave that to=20 later. - Bert - Am 27.09.2004 um 02:54 schrieb Andreas Raab: > John, > > We talked about this in the past - we need to do something to figure=20= > out what the primitives expect in their stringy interfaces (file=20 > names, clipboard, etc). I'm still in favour of having a primitive=20 > which answers the VM's expected encoding and defaults to MacRoman=20 > (which is indeed what I think most VMs actually use). After which we=20= > can start playing with using UTF8 or Latin1 or whatever else (I could=20= > easily imagine that an Eastern European VM uses a different encoding=20= > than a Far East VM). > > Cheers, > - Andreas > > PS. I bought a Really, Really Good (tm) coffee maker today. It's just=20= > unbelievable how good coffee can be (heh, heh). > > ----- Original Message ----- From: "John M McIntosh"=20 > <jo...@sm...> > To: "The general-purpose Squeak developers list"=20 > <squ...@li...> > Sent: Sunday, September 26, 2004 3:43 PM > Subject: Re: umlaute in squeak? > > > I think for this we need cut/copy/paste primitives that understand > unicode > Yell louder, I'm sure it exists in the OS api, just no-one has looked > at it yet... > This would imply that m17n would need to handle things. I'd think one > could change the methods to > figure out if the VM supports unicode cut/copy/paste and do the right > thing... > > Perhaps one could even be convinced to allow for other types of data = on > the clipboard (pictures?) > > On Sep 26, 2004, at 11:18 AM, Bert Freudenberg wrote: > >> Yep, there are still some open ends in m17n, mostly VM related. For=20= >> example, cut and paste from external sources shredders umlauts=20 >> (tested on Win and Mac), and file names in the file list do not look=20= >> right (although, on the Mac at least they can still be accessed). >> >> - Bert - >> >> Am 26.09.2004 um 19:26 schrieb Martin Kuball: >> >>> Hi! >>> >>> After some digging in the source code I found the problem. I'm using=20= >>> a >>> utf8 locale and that produces 2 byte characters for the special >>> german characters. But the vm uses only the 1st byte. This explains >>> why I always see the same character for different umlaut characters. >>> They always have the same 1st byte and differ only in the 2nd byte. >>> >>> I will try to work out a solution (other than changing the locale, >>> because I think it should work out of the box in as many = environments >>> as possible) >>> >>> Martin >>> >>> >>> Am Monday 20 September 2004 11:12 schrieb danil a. osipchuk: >>>> Hi, Martin >>>> >>>> It seems that you are using unix vm. I've solved the issue by >>>> editing sqUnixX11.c and setting there: >>>> static x2sqKey_t x2sqKey=3D x2sqKeyInput; >>>> (it's x2sqKeyPlain by default in sources on Ian site). I also have >>>> built some fonts from TTF (russian in my case). >>>> After rebuilding vm I've got squeak with russian fonts. >>>> I hope that things will be less complicated when m17n project will >>>> be included in core Squeak. Also, there are a plenty of German >>>> squeakers here - may be they will point the shortest path. >>>> Danil >>>> >>>>> Am Saturday 18 September 2004 23:13 schrieb Bernhard Pieber: >>>>>> Martin Kuball <Mar...@we...> wrote: >>>>>>> Is it possible to enter non 7bit characters like german umlaute >>>>>>> into squeak text fields? When I type one of these (s=DDS...) I >>>>>>> only get an A with a ~ above it. >>>>>> >>>>>> What do you mean by squeak text fields? I just tried it in a >>>>>> workspace in 3.7 and 3.8alpha and there it works. Which version >>>>>> of Squeak and which font did you use? >>>>> >>>>> With text field I mean any morph where you can enter text. I tried >>>>> with the new 3.7full and the standard font. By the way it has >>>>> never worked for me. I even tried the Windows version once but it >>>>> showed the same behaviour. >>>>> >>>>> Martin |
|
From: Tim R. <ti...@su...> - 2004-09-14 04:19:51
|
In message <200...@bi...>
Ned Konz <ne...@bi...> wrote:
> > and FormCanvas>flushDisplay
> > which again talks to Display rather than the target form.
>
> And isn't called, and should be removed.
Easy :-) Even I can do that.
>
> > It's understandable that this might be done with only a single window,
> > though it seems a waste of time when the target form is not the Display.
>
> But forceDamageToScreen and flushDisplay are only used (should only be used,
> anyway) when it's clear that we're rendering to the Display.
If it's that important perhaps it would be better to have a subclass
(DisplayCanvas) that knows this. FormCanvas really ought to be what it
claims to be, a canvas for displaying upon a Form.
Whilst digging in to how remove Display dependency from FormCanvas
I find some oddness. One of the methods using Display is
FormCanvas>showAt: pt invalidRects: updateRects
| blt |
blt _ (BitBlt current toForm: Display)
sourceForm: form;
combinationRule: Form over.
updateRects do:
[:rect |
blt sourceRect: rect;
destOrigin: rect topLeft + pt;
copyBits]
and clearly this is a time wasting no-op when 'form' == Display. It
might possibly be a strange way of forcing out the damage rectangles
via BitBlts use of #showDisplayBits? It's obviously a touch more useful
when form ~= Display but if that is the case why would we want to blit
to Display anyway?
#showAt:invalidRects: is only really sent by
WorldState>displayWorld:submorphs: and then only if deferredUpateMode
is false.
That in turn depends upon #doDeferredUpdatingFor: which seems
like mostly work that could be done at some initialisation stage rather
than check every update cycle? In particular it uses
PasteUpMorph disableDeferredUpdates ifTrue: [^ false].
which appears to be a dead path these days. The only method that might
set this to false is PasteUpMorph class>disableDeferredUpdate: which is
a) tagged as old, Dan's, and from context possibly related to his
weathermachine hardware
b) commented in such as way as to define itself as redundant. To whit,
explaining that deferring is used by Morphic to do a sort of
double-buffering and that direct-write screens would use a different
canvas with a buffer. Thus no need for the classvar etc.... Maybe it's
so old it predates the full usage of the VM update flag?
Thinking of said flag, I spotted a number of comments that infer that
somebody assumed that it was a platform specific primitive, which it
isn't. #primitiveDeferDisplayUpdates has no conenction to any platform
setting or function. It _could_ have if that was really intended.
WorldState>doDeferredUpdatingFor: and
WiWPasteUpMorph>doDeferredUpdating are two such cases.
DisplayScreen>deferUpdates also comments
" If this underlying platform doesc not support deferred updates, this
primitive will fail"
which is silly since the prim always suceeds (unless the arg is
non-boolean) and deferred updates are always claimed to be supported;
another test in each of the doDeferred* mentioned before can be dropped.
If we could allow ourselves to update the prim to return the previous
value itself we could drop a silly method and a classvar in
DisplayScreen.
Later in doDeferredUpdatingFor: we have a tacky test for whether the
canvas is a FormCanvas on Display. If aWorld == World and the canvas is
not a FormCanvas etc, we set it to so be. Couldn't this be better done
in an init method? Likewise the later line for MVC stuff. This is
actually a problem if we want to use a FormCanvas with a form ~=
Display since it will get reset the first time we try updating it!
Should this sort of side-effecting be done here? We're getting way past
my knowledge of how all this convoluted spaghetti works.
So, deferredUpdateMode is almost certain to be true. If it is always
true, the 'canvas showAt:... could be dropped completely and the issue
of wastefully displaying Display on Display avoided completely rather
than just by accident.
Sheesh, all that for one method. On to the next one.
tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
Programmer: One who is too lacking in people skills to be a software engineer.
|
|
From: Ned K. <ne...@bi...> - 2004-09-11 05:49:20
|
On Friday 10 September 2004 10:17 pm, Tim Rowledge wrote: > > Remember too that we may be rendering to something that isn't making > > pixels. For instance, consider PDF output, or Postscript output, or the > > various OS-level (like Mac OS/X (or OS/2)) graphics APIs where you can > > cleanly render higher-level objects than pixels. > > Isn't that why one would have PSCanvas etc? I'm not going to claim to > have much cleu about the care and feeding of canvases but that seems > like the intent. Absolutely. It's just that we need to make the Canvases write-only. -- Ned Konz http://bike-nomad.com |
|
From: Tim R. <ti...@su...> - 2004-09-11 05:18:27
|
In message <200...@bi...>
Ned Konz <ne...@bi...> wrote:
> On Friday 10 September 2004 10:28 am, Tim Rowledge wrote:
> > =A0So any
> > VM that buffers the window has to actually handle the paint events an=
d
> > not pass them up, and we have to remember not to put anything in the
> > image that relies on getting those events. That's all I meant when
> > refering to portability.
>=20
> Remember too that we may be rendering to something that isn't making pi=
xels.=20
> For instance, consider PDF output, or Postscript output, or the various=
=20
> OS-level (like Mac OS/X (or OS/2)) graphics APIs where you can cleanly =
render=20
> higher-level objects than pixels.
Isn't that why one would have PSCanvas etc? I'm not going to claim to
have much cleu about the care and feeding of canvases but that seems
like the intent.=20
> Now that I'm looking at Cairo I think that what is needed is:
>=20
> * maintain separate context information about each display surface
> * VM reports damage rects to image (with, of course, information about =
which=20
> display surface they're for)
> * VM reports size/visibility changes for display surfaces
> * image manages damage rects
> * Canvases are write-only and support high-level operations (like Cairo=
or the=20
> PDF or Postscript imaging model; not too far from what we have now exce=
pt for=20
> the concept of 'current position')
> * display surfaces may be write-only; some (e.g. Form) may not be, as n=
eeded.
> * maybe a higher-level interface to OS windowing API, but this should b=
e kept=20
> separate from the display surface API (i.e. we should not be dealing wi=
th=20
> Window or Screen directly as a display surface, just with the parts tha=
t get=20
> drawn on)
> * I/O events are associated with higher-level objects like Windows.
Sounds very plausible to me. Rather like VW actually.=20
tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
A)bort, R)etry or S)elf-destruct?
|
|
From: Tim R. <ti...@su...> - 2004-09-11 05:13:32
|
In message <020b01c4977e$497f27c0$6d5450d9@R22>
"Andreas Raab" <and...@gm...> wrote:
> Yup, but that isn't a problem. Not reporting paint events is equivalent to
> being the front-most window which is a very common situation. I wouldn't
> expect any trouble here.
Well I guess we'll see as we try it out. Let's just remember that for
certain OSs being active and not in front is pretty common.
The good news is that I have a plugin that let's me create a window
(though I don't quite seem to get the initial size I expect), display
into it and update it. It's amazing what fun you can have if you create
several windows and give them all the same id because you forgot to
increment the 'unique id' counter....
The bad news is it took me several hours longer than it should have
because I got persuaded to 'give the grass a quick mow'. It isn't
actually so quick to mow TWO F*^&*^ING ACRES of the stuff. Grr. And it
rained on me.
tim
PS two acres is about a hectare for those metric persons reading this.
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
"Wibble" said Pooh, the stress beginning to show.
|
|
From: Ned K. <ne...@bi...> - 2004-09-10 21:51:35
|
On Friday 10 September 2004 10:28 am, Tim Rowledge wrote: > =A0So any > VM that buffers the window has to actually handle the paint events and > not pass them up, and we have to remember not to put anything in the > image that relies on getting those events. That's all I meant when > refering to portability. Remember too that we may be rendering to something that isn't making pixels= =2E=20 =46or instance, consider PDF output, or Postscript output, or the various=20 OS-level (like Mac OS/X (or OS/2)) graphics APIs where you can cleanly rend= er=20 higher-level objects than pixels. That we occasionally need to read back pixels for operations like doing scr= een=20 captures or to make shadow forms for hit testing isn't much of a reason to= =20 clutter the rest of the API with the ability to do this. Clearly, we can ju= st=20 render to a separate bitmap for those cases. We can ignore roundCornersOf: given a graphics model (like Cairo) that=20 actually knows how to draw round rectangles. Now that I'm looking at Cairo I think that what is needed is: * maintain separate context information about each display surface * VM reports damage rects to image (with, of course, information about whic= h=20 display surface they're for) * VM reports size/visibility changes for display surfaces * image manages damage rects * Canvases are write-only and support high-level operations (like Cairo or = the=20 PDF or Postscript imaging model; not too far from what we have now except f= or=20 the concept of 'current position') * display surfaces may be write-only; some (e.g. Form) may not be, as neede= d. * maybe a higher-level interface to OS windowing API, but this should be ke= pt=20 separate from the display surface API (i.e. we should not be dealing with=20 Window or Screen directly as a display surface, just with the parts that ge= t=20 drawn on) * I/O events are associated with higher-level objects like Windows. =2D-=20 Ned Konz http://bike-nomad.com |
|
From: Andreas R. <and...@gm...> - 2004-09-10 21:38:25
|
Tim, > The obvious corollary is that if paint events only pass the damage > rectangle up to the image, then ioShowDisplay is called to move pixels > to the buffer and that is it. No actual displaying to glass. If I left > in the code to report the damage area I'd get a nice loop :-) So any > VM that buffers the window has to actually handle the paint events and > not pass them up, and we have to remember not to put anything in the > image that relies on getting those events. That's all I meant when > refering to portability. Yup, but that isn't a problem. Not reporting paint events is equivalent to being the front-most window which is a very common situation. I wouldn't expect any trouble here. > John mentioned that OSX is double buffering the windows so it might be > an issue for him. And I hear the M$ is making big changes in their > graphics model for this avalon thingy; maybe they'll require apps to > report damage areas and only display pixels during a paint event handler > critical block? I'd be surprised to see this. But it wouldn't be hard to work around these restrictions in a way that uses the same model. > Well of course, but portability includes across time not just current > platforms. If M$/Apple does something dramatic in a future OS release > you'll be just as happy that we spent time on it as I want to be now - > probably more so because you (as in win32 vm) have millions of probably > screaming users whereas I only have a thousand or two to pacify. That's why I'm in favour of the simplest model possible ;-) Cheers, - Andreas |
|
From: Tim R. <ti...@su...> - 2004-09-10 17:31:08
|
> > > This (the effect of wanting to use BalloonCanvas etc) is > > > actually one of the reasons why a distinction of the > > > responsibilities of drawing protocol (Canvas) vs. display > > > surface (Window) can be advantageous. > > > > Yes, I rather thought that was the intention but it is, shall we say a > > litle muddied at the moment as you mention above. I was imagining a > > litle cleanup of FormCanvas so that either a DisplayScreen or a > > DisplayHostWindow (our current subclass of DisplayScreen that knows > > it's host window handle in some abstract fashion) would work. > > Sounds like an excellent idea to me. OK, I'll see if I can untangle enough to make a crack at it. > > > > The way I'd do it is to completely ignore fullDisplayUpdate and friends. > > > Just send the paint events to Squeak and let *it* deal with it. The only > > > place where we move bits from here (Form) to there (Window) is in > > > #forceToScreen: - e.g., the sequence would look like: > [...] > > > > Well this might work in many cases but I see some worries. > > > > For example it isn't actually true that "The only place where we > > move bits from here (Form) to there (Window) is in #forceToScreen:" > > since that ain't how RISC OS does it. > > Well, maybe not but forceToScreen: indeed calls (via > primitiveShowDisplayRect via displayBitsOf) ioShowDisplay (which does move > the bits) and my point is that this is the only place where this is > required. Ah - cross purposes here. On ROS ioShowDisplay doesn't put pixels to glass; it _does_ move them from Form to window-backing-pixmap, doing the endian/RGB->BGR transform on the way. Actual pixels to glass is done when a paint event is processed. ioShowDisplay tells the OS that a certain area has been dirtied and thus triggers the paint event at the next handleEvents opportunity. That's the split that was annoying me - ioShowDisplay gives us a handle to the Sq bitmap so it is possible to grab pixels directly and send them to glass if that is how your OS works. At paint-event time we don't have a convenient handle to the Sq bitmap _unless_ we make the assumption that it must be Display. Which is of course a bad assumption as soon as we have multiple windows. The obvious corollary is that if paint events only pass the damage rectangle up to the image, then ioShowDisplay is called to move pixels to the buffer and that is it. No actual displaying to glass. If I left in the code to report the damage area I'd get a nice loop :-) So any VM that buffers the window has to actually handle the paint events and not pass them up, and we have to remember not to put anything in the image that relies on getting those events. That's all I meant when refering to portability. John mentioned that OSX is double buffering the windows so it might be an issue for him. And I hear the M$ is making big changes in their graphics model for this avalon thingy; maybe they'll require apps to report damage areas and only display pixels during a paint event handler critical block? [snip] > > The portion of interest from the paint event is the invalidated region. > Everything else is (AFAIK) irrelevant on pretty much any platform. While > there are additional contexts that may be passed along one should be able to > recreate them from the information we have (this is true of Windows for > sure). You've made my point for me. I hope there is no problem but I remember that there used to be and thus we need to remember the issue before charging off down a box canyon. That's all. > > I'm sure some people must think " why does he bother with this weird > > OS" but it's good for everyone to have some heterogeneity around - it > > keeps us honest about portability. And besides, oneday RISC OS will be > > the predominant OS and all other feeble pretenders will have to kneel > > in submission rant, rave..... > > Everything to keep you happy, Tim ;-) Well of course, but portability includes across time not just current platforms. If M$/Apple does something dramatic in a future OS release you'll be just as happy that we spent time on it as I want to be now - probably more so because you (as in win32 vm) have millions of probably screaming users whereas I only have a thousand or two to pacify. tim -- Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim Strange OpCodes: XI: Execute Invalid op-code |
|
From: Andreas R. <and...@gm...> - 2004-09-10 09:35:40
|
> > Correct. Unfortunately the current Canvas protocol is > > (how shall we say...) historically grown ;-) IOW, it > > doesn't really provide the neat high-level abstraction > > that we'd like to have. > > So any chance of that being improved anytime (very) soon? Soon yes. Very soon probably no. > > This (the effect of wanting to use BalloonCanvas etc) is > > actually one of the reasons why a distinction of the > > responsibilities of drawing protocol (Canvas) vs. display > > surface (Window) can be advantageous. > > Yes, I rather thought that was the intention but it is, shall we say a > litle muddied at the moment as you mention above. I was imagining a > litle cleanup of FormCanvas so that either a DisplayScreen or a > DisplayHostWindow (our current subclass of DisplayScreen that knows > it's host window handle in some abstract fashion) would work. Sounds like an excellent idea to me. > > The way I'd do it is to completely ignore fullDisplayUpdate and friends. > > Just send the paint events to Squeak and let *it* deal with it. The only > > place where we move bits from here (Form) to there (Window) is in > > #forceToScreen: - e.g., the sequence would look like: [...] > > Well this might work in many cases but I see some worries. > > For example it isn't actually true that "The only place where we > move bits from here (Form) to there (Window) is in #forceToScreen:" > since that ain't how RISC OS does it. Well, maybe not but forceToScreen: indeed calls (via primitiveShowDisplayRect via displayBitsOf) ioShowDisplay (which does move the bits) and my point is that this is the only place where this is required. > I have to (currently and I'd like to > change it) do the actual bit moving from Display to an OS pixmap at > ioShowDisplay time along with telling the OS that the area has been > dirtied. Sure - and that's precisely what forceToScreen: asks you to do ;-) > Which makes the second worry; the potential delay and disconnect > between the paint event and the redraw. Given the potential for > scheduling to delay the eventual forceToScreen it could be out of date > - say another window has been brought to front in the meantime. Does > the OS in question actually blit really straight to glass, or is there > some clipping area set when the paint event was sent? It may simply not > be a problem for those GUIs where the active window is at the top but I > suspect it could be a pain in some cases. Basically I'm wondering if > there is some context in the paint event that would need to be dealt > with. IIRC this was a real issue in older VW vms because of some > windows detail that got in the way. Hopefully it has all gone now. The portion of interest from the paint event is the invalidated region. Everything else is (AFAIK) irrelevant on pretty much any platform. While there are additional contexts that may be passed along one should be able to recreate them from the information we have (this is true of Windows for sure). > I also have the practical problem that when I did have handling for > 'draw right now dammit' things got very slow. As long as we can allow > the VM to handle paints if it wants to I can do something for now and > see about changes later. That's what we have forceDisplayUpdate for ;-) Some renaming might be in order but the Windows VM had done this for years and forceDisplayUpdate was introduced for the precise reason to force a synchcronous update of display. > I'm sure some people must think " why does he bother with this weird > OS" but it's good for everyone to have some heterogeneity around - it > keeps us honest about portability. And besides, oneday RISC OS will be > the predominant OS and all other feeble pretenders will have to kneel > in submission rant, rave..... Everything to keep you happy, Tim ;-) Cheers, - Andreas |
|
From: Tim R. <ti...@su...> - 2004-09-10 01:00:34
|
In message <01af01c496b6$167fe030$b200a8c0@R22>
"Andreas Raab" <and...@gm...> wrote:
[snip]
> Correct. Unfortunately the current Canvas protocol is (how shall we say...)
> historically grown ;-) IOW, it doesn't really provide the neat high-level
> abstraction that we'd like to have.
So any chance of that being improved anytime (very) soon?
> > Probably WorldState should talk to its canvas instead of assuming Display.
>
> Likely yes.
I imagine making Form cope with force.... (doing nothing?) would let us
clean that up.
>
> > All canvases understand "forceToScreen: rect"; this should be used
> instead.
>
> Yes. It might also be interesting to check out Tweak's displayWorld
> implementation - here all of the Display related operations are routed
> through CWorldPlayer's display variable (and display really could be any
> kind of drawable surface such as a window).
Hmm, ok since Tweak is our current 'getting paid' target that is more
important.
>
> > > b) Which canvas to use? It looks like FormCanvas is the best candidate
> > > already in the system. We could subclass to make the assorted force...
>
> That's what I would do (and have done - see CTransformCanvas).
>
> > > messages go to our host window DisplayScreen analogues but then
> > > BalloonCanvas and other subclasses of FormCanvas would need sometinhg
> > > done. If I've understood it, we could consider changing FormCanvas to
> > > send all those force... messages to 'form' instead and then the 'form'
> > > could be an instance of HostWindow and we pass them on to the
> > > HostWindowPlugin. I looked at some ofthe PluggableCanvas classes but
> > > they all seem a bit ugly to me.
>
> This (the effect of wanting to use BalloonCanvas etc) is actually one of the
> reasons why a distinction of the responsibilities of drawing protocol
> (Canvas) vs. display surface (Window) can be advantageous.
Yes, I rather thought that was the intention but it is, shall we say a
litle muddied at the moment as you mention above. I was imagining a
litle cleanup of FormCanvas so that either a DisplayScreen or a
DisplayHostWindow (our current subclass of DisplayScreen that knows
it's host window handle in some abstract fashion) would work.
> By the end of the
> day, if you have a native window which has a form to display all you need is
> to vector forceToScreen: and getCanvas appropriately (not counting the
> various fixes in the rest of the system).
Never come across getCanvas before but it seems plausible. Not exactly
widely implemented in the standard system so it doesn't jump out as
important. And it seems a bit of a onetrick pony as well - nobody ever
gets anything other than a FormCanvas out of it! (normal 3.7 image)
[snip]
> > > windows. How else might one handle paint type OS events?
>
> The way I'd do it is to completely ignore fullDisplayUpdate and friends.
> Just send the paint events to Squeak and let *it* deal with it. The only
> place where we move bits from here (Form) to there (Window) is in
> #forceToScreen: - e.g., the sequence would look like:
> * Drawing in Squeak
> -> calls forceToScreen:
> -> copies bits into Window
> * Paint event in VM
> -> generates paint event for Squeak
> -> calls forceToScreen: to restore invalidated portion
Well this might work in many cases but I see some worries.
For example it isn't actually true that "The only place where we move
bits from here (Form) to there (Window) is in #forceToScreen:" since
that ain't how RISC OS does it. I have to (currently and I'd like to
change it) do the actual bit moving from Display to an OS pixmap at
ioShowDisplay time along with telling the OS that the area has been
dirtied. Then next time I get a paint event I blit the appropriate area
from the pixmap to the glass. Costs me a shadow copy of the Bitmap for
the Display (and any other windows we open) but makes it very cheap to
handle paints. Since can paints come at a furious rate in RISC OS (where
the active window can be anywhere in the stack of windows) this has
some value.
Which makes the second worry; the potential delay and disconnect
between the paint event and the redraw. Given the potential for
scheduling to delay the eventual forceToScreen it could be out of date
- say another window has been brought to front in the meantime. Does
the OS in question actually blit really straight to glass, or is there
some clipping area set when the paint event was sent? It may simply not
be a problem for those GUIs where the active window is at the top but I
suspect it could be a pain in some cases. Basically I'm wondering if
there is some context in the paint event that would need to be dealt
with. IIRC this was a real issue in older VW vms because of some
windows detail that got in the way. Hopefully it has all gone now.
I also have the practical problem that when I did have handling for
'draw right now dammit' things got very slow. As long as we can allow
the VM to handle paints if it wants to I can do something for now and
see about changes later.
I'm sure some people must think " why does he bother with this weird
OS" but it's good for everyone to have some heterogeneity around - it
keeps us honest about portability. And besides, oneday RISC OS will be
the predominant OS and all other feeble pretenders will have to kneel
in submission rant, rave.....
tim
--
Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim
How was Thomas J. Watson buried? 9 edge down.
|
|
From: Andreas R. <and...@gm...> - 2004-09-09 21:44:07
|
Hi Tim,
> > a) WTF are canvasss used? So far as I can work out the WorldState has a
> > canvas which is a FormCanvas on the Display.
>
> Canvas is a protocol that is used to draw things. We have different Canvas
> types for different purposes, from rendering on Forms directly, to
> transmitting drawing commands remotely, to creating Postscript.
Correct. Unfortunately the current Canvas protocol is (how shall we say...)
historically grown ;-) IOW, it doesn't really provide the neat high-level
abstraction that we'd like to have.
> > So far so good but they
> > also seem to be used in a few other places and that confuses me because
> > ther is a good bit of code that looks like it very explicitly wants
> > Display to be the target form. See for example
> > WorldState>forceDamageToScreen which explicitly does Dispaly
> > forceDamageToScreen rather than form....
>
> Probably WorldState should talk to its canvas instead of assuming Display.
Likely yes.
> All canvases understand "forceToScreen: rect"; this should be used
instead.
Yes. It might also be interesting to check out Tweak's displayWorld
implementation - here all of the Display related operations are routed
through CWorldPlayer's display variable (and display really could be any
kind of drawable surface such as a window).
> > b) Which canvas to use? It looks like FormCanvas is the best candidate
> > already in the system. We could subclass to make the assorted force...
That's what I would do (and have done - see CTransformCanvas).
> > messages go to our host window DisplayScreen analogues but then
> > BalloonCanvas and other subclasses of FormCanvas would need sometinhg
> > done. If I've understood it, we could consider changing FormCanvas to
> > send all those force... messages to 'form' instead and then the 'form'
> > could be an instance of HostWindow and we pass them on to the
> > HostWindowPlugin. I looked at some ofthe PluggableCanvas classes but
> > they all seem a bit ugly to me.
This (the effect of wanting to use BalloonCanvas etc) is actually one of the
reasons why a distinction of the responsibilities of drawing protocol
(Canvas) vs. display surface (Window) can be advantageous. By the end of the
day, if you have a native window which has a form to display all you need is
to vector forceToScreen: and getCanvas appropriately (not counting the
various fixes in the rest of the system).
> Have you looked at ExternalScreen and ExternalForm?
Bad examples for this case. Native windows are *much* simpler.
> > c) Once we have a canvas talking to the HostWindowPlugin, we open a
> > host window, display something on it, force the damage to screen (well,
> > window) and it's supposed to appear on the glass. Many of us need to
> > process pixels and we have that code in the VM so we can leverage that
> > with (probably) a few mods to factor it not to assume getting the
> > Display oop from specialObjectsArray. Pretty soon the OS is going to
> > send in a paint/expose type event for that window and current code will
> > fail. All the copies of platform code I have (a bit old but probably
> > not horribly out of date) handle a paint by calling fullDisplayUpdate
> > (Ian has a nice little optimisation to use any paint event clipping
> > rectangle) which explcitly gets the bitmap from the Display oop.
> > Clearly this isn't going to do any updating of other windows. As it
> > happens, RISC OS is ok with this due to a side effect of how I have to
> > keep a backing bitmap for each window. All I have to do is map from the
> > incoming window handle to the actual host bitmap and display some of
> > that. No problem except for the 'waste' of memory. If you want to get
> > the latest bits from inside ObjectMemory we will need a map from host
> > window handle to squeak bitmap oop. Easy way is to have an array held
> > by specialObjects that has the oops of the bitmaps used by all open host
> > windows. How else might one handle paint type OS events?
The way I'd do it is to completely ignore fullDisplayUpdate and friends.
Just send the paint events to Squeak and let *it* deal with it. The only
place where we move bits from here (Form) to there (Window) is in
#forceToScreen: - e.g., the sequence would look like:
* Drawing in Squeak
-> calls forceToScreen:
-> copies bits into Window
* Paint event in VM
-> generates paint event for Squeak
-> calls forceToScreen: to restore invalidated portion
Cheers,
- Andreas
|
|
From: Ned K. <ne...@bi...> - 2004-09-09 20:36:41
|
On Thursday 09 September 2004 1:05 pm, Tim Rowledge wrote: > (Mostly to Andreas but it affects several people and probably interests > more) > > John passed on to me (briefly, on a bad cellphone link, so excuse any > misunderstandings) the comment about hooking into the > forceDamageToScreen/forceDisplayUpdate instead of into the > displayBitsOfLeftTopRightBottom end of copyBits (et al.). Excellent > suggestion; it avoids the unpleasantness of how to check to see if this > is a Display or host window within a rather common operation. > > (For other people, my first and actually functional hack, was to extend > displayBitsOfLeftTopRightBottom such that any bitblt to a host window > would trigger the ioShowDisplay mechanism just as Display does now. It > works great but meant adding a hopefully-fast way to check for > 'destination is some kind of host window'. Ugly, limits you to one > class etc but it does make it really simple to display stuff on the > extra windows since any bitblt at all with the window as a dest will > cause an update immediately) > > Moving the window updating to a plugin call attached to > forceDamageToScreen means it can work with the Canvas mechanism. > However, I have queries about some details her since I have no prior > experience with doing anything to canvases. > > a) WTF are canvasss used? So far as I can work out the WorldState has a > canvas which is a FormCanvas on the Display. Canvas is a protocol that is used to draw things. We have different Canvas types for different purposes, from rendering on Forms directly, to transmitting drawing commands remotely, to creating Postscript. Assuming that a Canvas is anything in particular is asking for trouble. I am making a new kind of Canvas that is an interface to the Cairo library; Cairo provides back-ends for host window display surfaces, for bitmaps in memory, for PDF output, and for OpenGL textures. > So far so good but they > also seem to be used in a few other places and that confuses me because > ther is a good bit of code that looks like it very explicitly wants > Display to be the target form. See for example > WorldState>forceDamageToScreen which explicitly does Dispaly > forceDamageToScreen rather than form.... Probably WorldState should talk to its canvas instead of assuming Display. All canvases understand "forceToScreen: rect"; this should be used instead. It is likely that we'd want to have a World that lives in some other kind of Canvas. > and FormCanvas>flushDisplay > which again talks to Display rather than the target form. And isn't called, and should be removed. > It's understandable that this might be done with only a single window, > though it seems a waste of time when the target form is not the Display. But forceDamageToScreen and flushDisplay are only used (should only be used, anyway) when it's clear that we're rendering to the Display. > b) Which canvas to use? It looks like FormCanvas is the best candidate > already in the system. We could subclass to make the assorted force... > messages go to our host window DisplayScreen analogues but then > BalloonCanvas and other subclasses of FormCanvas would need sometinhg > done. If I've understood it, we could consider changing FormCanvas to > send all those force... messages to 'form' instead and then the 'form' > could be an instance of HostWindow and we pass them on to the > HostWindowPlugin. I looked at some ofthe PluggableCanvas classes but > they all seem a bit ugly to me. Have you looked at ExternalScreen and ExternalForm? > c) Once we have a canvas talking to the HostWindowPlugin, we open a > host window, display something on it, force the damage to screen (well, > window) and it's supposed to appear on the glass. Many of us need to > process pixels and we have that code in the VM so we can leverage that > with (probably) a few mods to factor it not to assume getting the > Display oop from specialObjectsArray. Pretty soon the OS is going to > send in a paint/expose type event for that window and current code will > fail. All the copies of platform code I have (a bit old but probably > not horribly out of date) handle a paint by calling fullDisplayUpdate > (Ian has a nice little optimisation to use any paint event clipping > rectangle) which explcitly gets the bitmap from the Display oop. > Clearly this isn't going to do any updating of other windows. As it > happens, RISC OS is ok with this due to a side effect of how I have to > keep a backing bitmap for each window. All I have to do is map from the > incoming window handle to the actual host bitmap and display some of > that. No problem except for the 'waste' of memory. If you want to get > the latest bits from inside ObjectMemory we will need a map from host > window handle to squeak bitmap oop. Easy way is to have an array held > by specialObjects that has the oops of the bitmaps used by all open host > windows. How else might one handle paint type OS events? > > d) my knuckles hurt. enough > > tim > -- > Tim Rowledge, ti...@su..., http://sumeru.stanford.edu/tim > Useful random insult:- Afraid she'll void her warranty if she thinks too > much. > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Squeak-VMdev mailing list > Squ...@li... > https://lists.sourceforge.net/lists/listinfo/squeak-vmdev -- Ned Konz http://bike-nomad.com |
13 messages has been excluded from this view by a project administrator.
