A new release of Cuis is available at http://www.jvuletich.org/Cuis/Index.html . It includes some bugfixes and more cleanup.
Biggest news is a lot of cleanup in the Text system. Gone are the ugly TextConstants pool and the old Paragraph class. TextStyle lost over half its instance variables and over 80% of its methods. I also added a TextEditor to the World menu that is not a Smalltalk Workspace and may be useful especially for end users.
As usual, all the updates starting at #0001 are available separately, and described in http://www.jvuletich.org/Cuis/CategoriesAndChangeSets.txt . This could be useful for users of other Squeak images wanting some of the bug fixes and enhancements included in Cuis.
Comments welcome.
Cheers, Juan Vuletich
2009/8/1 Juan Vuletich juan@jvuletich.org:
A new release of Cuis is available at http://www.jvuletich.org/Cuis/Index.html . It includes some bugfixes and more cleanup.
Biggest news is a lot of cleanup in the Text system. Gone are the ugly TextConstants pool and the old Paragraph class. TextStyle lost over half its instance variables and over 80% of its methods. I also added a TextEditor to the World menu that is not a Smalltalk Workspace and may be useful especially for end users.
As usual, all the updates starting at #0001 are available separately, and described in http://www.jvuletich.org/Cuis/CategoriesAndChangeSets.txt . This could be useful for users of other Squeak images wanting some of the bug fixes and enhancements included in Cuis.
Comments welcome.
A most important thing (as to me), is the possibility to use different text editor class instead of 'buffing' single one, as it was before. We are all witness where buffing leads.
Cheers, Juan Vuletich
Juan Vuletich wrote:
Biggest news is a lot of cleanup in the Text system. Gone are the ugly TextConstants pool and the old Paragraph class. TextStyle lost over half its instance variables and over 80% of its methods. I also added a TextEditor to the World menu that is not a Smalltalk Workspace and may be useful especially for end users.
I very much like what you've done with the editors. Is it correct that TextEditor is effectively protocol compatible with the old TextMorphEditor? If so, what do you think about bringing this into Squeak and phase out TextMorphEditor? Would this be doable or do you foresee any problems due to other changes that you might have done? From what I can see it looks as if this should be possible while preserving all the Unicode and m17n-goodness that I don't want to give up for Squeak. But boy, I would like to finally cut the Gordian knot called ParagraphEditor that ties Morphic and MVC together at the hip ;-)
Cheers, - Andreas
Andreas Raab wrote:
Juan Vuletich wrote:
Biggest news is a lot of cleanup in the Text system. Gone are the ugly TextConstants pool and the old Paragraph class. TextStyle lost over half its instance variables and over 80% of its methods. I also added a TextEditor to the World menu that is not a Smalltalk Workspace and may be useful especially for end users.
I very much like what you've done with the editors. Is it correct that TextEditor is effectively protocol compatible with the old TextMorphEditor? If so, what do you think about bringing this into Squeak and phase out TextMorphEditor? Would this be doable or do you foresee any problems due to other changes that you might have done? From what I can see it looks as if this should be possible while preserving all the Unicode and m17n-goodness that I don't want to give up for Squeak. But boy, I would like to finally cut the Gordian knot called ParagraphEditor that ties Morphic and MVC together at the hip ;-)
:)
I think it can be done. I did not change the protocol. At most I might have removed some methods that are unused on Cuis. I'll try to do it. I'll file my Editor hierarchy in Squeak, add any missing methods (but not those of Controller!). Biggest problem is that I'll have to suffer the pain of the bloat in my mind, and the default font in my eyes :)
If only some brave soul understood that Unicode and m17n should be an optional package and made it be so...
Cheers, Juan Vuletich
Cheers,
- Andreas
Juan Vuletich wrote:
I think it can be done. I did not change the protocol. At most I might have removed some methods that are unused on Cuis. I'll try to do it. I'll file my Editor hierarchy in Squeak, add any missing methods (but not those of Controller!). Biggest problem is that I'll have to suffer the pain of the bloat in my mind, and the default font in my eyes :)
Well, help us! You probably have a standing invitation to become core-dev in your inbox and if not I can get you one ;-)
Cheers, - Andreas
Andreas Raab wrote:
Juan Vuletich wrote:
I think it can be done. I did not change the protocol. At most I might have removed some methods that are unused on Cuis. I'll try to do it. I'll file my Editor hierarchy in Squeak, add any missing methods (but not those of Controller!). Biggest problem is that I'll have to suffer the pain of the bloat in my mind, and the default font in my eyes :)
I guess I was being too optimistic. I honestly tried to do it. First I tried to file in the Editor classes from Cuis. Unfortunately, they are differences that make them incompatible, for example in NewParagraph. Besides, too much methods would be missing. Then I tried the other way. I cloned the existing TextMorphEditor hierarchy, made the superclass of my new ParagraphEditor2 to be object, and started cleaning Undeclared variables, etc. I believe this is the way to do it, because if done carefully, no methods would be missing and no behavior should be broken inadvertently. It would take me between 30 and 40 hours to finish it. I'm sorry, but I can't spend that much time on this.
Well, help us! You probably have a standing invitation to become core-dev in your inbox and if not I can get you one ;-)
I know. Perhaps my anti aliased StrikeFonts could be included in Squeak. I don't know how to handle the creation of instances. Monticello can only handle code, right? No live instances or binary (bmp) files?
Cheers, Juan Vuletich
Cheers,
- Andreas
Juan Vuletich wrote:
I guess I was being too optimistic. I honestly tried to do it. First I tried to file in the Editor classes from Cuis. Unfortunately, they are differences that make them incompatible, for example in NewParagraph.
I did it slightly differently and had no problems: * File out Editor, TextEditor, file those into Squeak. * Make a subclass of TextMorph called TextEditorMorph * Give it the editorClass TextEditor, open it, edit it At this point I had one blow-up resulting from missing NewParagraph>>replaceFrom:to:with:. I added it and everything seemed to work.
I then upped the ante a little and replaced TextMorph>>editorClass with TextEditor. And guess what, it seems to be working quite well, except from a few issues like: * One cannot get rid of text selection by clicking inside the old selection. I'm presuming that this is done for mobile devices but we should have a preference for governing that. * Programming short cuts do not work (browse senders, implementors etc). How are shortcuts expected to work here? Should these be in a subclass? (some advice would be welcome).
Other than that I haven't found any problems whatsoever yet.
I know. Perhaps my anti aliased StrikeFonts could be included in Squeak. I don't know how to handle the creation of instances. Monticello can only handle code, right? No live instances or binary (bmp) files?
We can work this out. In the worst case, initializer methods can carry code as well, along the lines of:
blankForm "Created using: (ByteArray streamContents:[:s| PNGReadWriter putForm: (Form extent: 100@100 depth: 32) onStream: s]) asString base64Encoded. " ^Form fromBinaryStream: ( 'iVBORw0KGgoAAAANSUhEUgAAAGQAAABkCAYAAABw4pVUAAAAnklEQVR4XuXBMQEAAADCoPVP bQsfIJ/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6f z+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8 Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz3c1nKQAAZiW0oUAAAAASUVORK5CYII=' ) base64Decoded asByteArray readStream.
If we stick this into a temporary class that gets deleted in a later update then the overhead is temporary.
Cheers, - Andreas
2009/8/2 Andreas Raab andreas.raab@gmx.de:
Juan Vuletich wrote:
I guess I was being too optimistic. I honestly tried to do it. First I tried to file in the Editor classes from Cuis. Unfortunately, they are differences that make them incompatible, for example in NewParagraph.
I did it slightly differently and had no problems:
- File out Editor, TextEditor, file those into Squeak.
- Make a subclass of TextMorph called TextEditorMorph
- Give it the editorClass TextEditor, open it, edit it
At this point I had one blow-up resulting from missing NewParagraph>>replaceFrom:to:with:. I added it and everything seemed to work.
I then upped the ante a little and replaced TextMorph>>editorClass with TextEditor. And guess what, it seems to be working quite well, except from a few issues like:
- One cannot get rid of text selection by clicking inside the old selection.
I'm presuming that this is done for mobile devices but we should have a preference for governing that.
- Programming short cuts do not work (browse senders, implementors etc). How
are shortcuts expected to work here? Should these be in a subclass? (some advice would be welcome).
Other than that I haven't found any problems whatsoever yet.
I know. Perhaps my anti aliased StrikeFonts could be included in Squeak. I don't know how to handle the creation of instances. Monticello can only handle code, right? No live instances or binary (bmp) files?
We can work this out. In the worst case, initializer methods can carry code as well, along the lines of:
blankForm "Created using: (ByteArray streamContents:[:s| PNGReadWriter putForm: (Form extent: 100@100 depth: 32) onStream: s]) asString base64Encoded. " ^Form fromBinaryStream: ( 'iVBORw0KGgoAAAANSUhEUgAAAGQAAABkCAYAAABw4pVUAAAAnklEQVR4XuXBMQEAAADCoPVP bQsfIJ/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6f z+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8 Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz3c1nKQAAZiW0oUAAAAASUVORK5CYII=' ) base64Decoded asByteArray readStream.
If we stick this into a temporary class that gets deleted in a later update then the overhead is temporary.
Btw, about such overhead.. Recently i'm also added a data blob in a method. And i thought, that it would be cool to not persist the data as a code, but instead put it into the comment. So, a generic method , carrying a data blob could be just:
someData "iVBORw0KGgoAAAANSUhEUgAAAGQAAABkCAYAAABw4pVUAAAAnklEQVR4XuXBMQEAAADCoPVP bQsfIJ/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6f z+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8 Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz3c1nKQAAZiW0oUAAAAASUVORK5CYII= "
in this way given blob is not part of an image, it is a part of source files. And, by having a method source, it is easy to read a data from it. How do you like the idea?
Cheers, - Andreas
Igor Stasenko wrote:
2009/8/2 Andreas Raab andreas.raab@gmx.de:
Juan Vuletich wrote:
I guess I was being too optimistic. I honestly tried to do it. First I tried to file in the Editor classes from Cuis. Unfortunately, they are differences that make them incompatible, for example in NewParagraph.
I did it slightly differently and had no problems:
- File out Editor, TextEditor, file those into Squeak.
- Make a subclass of TextMorph called TextEditorMorph
- Give it the editorClass TextEditor, open it, edit it
At this point I had one blow-up resulting from missing NewParagraph>>replaceFrom:to:with:. I added it and everything seemed to work.
I then upped the ante a little and replaced TextMorph>>editorClass with TextEditor. And guess what, it seems to be working quite well, except from a few issues like:
- One cannot get rid of text selection by clicking inside the old selection.
I'm presuming that this is done for mobile devices but we should have a preference for governing that.
- Programming short cuts do not work (browse senders, implementors etc). How
are shortcuts expected to work here? Should these be in a subclass? (some advice would be welcome).
Other than that I haven't found any problems whatsoever yet.
I know. Perhaps my anti aliased StrikeFonts could be included in Squeak. I don't know how to handle the creation of instances. Monticello can only handle code, right? No live instances or binary (bmp) files?
We can work this out. In the worst case, initializer methods can carry code as well, along the lines of:
blankForm "Created using: (ByteArray streamContents:[:s| PNGReadWriter putForm: (Form extent: 100@100 depth: 32) onStream: s]) asString base64Encoded. " ^Form fromBinaryStream: ( 'iVBORw0KGgoAAAANSUhEUgAAAGQAAABkCAYAAABw4pVUAAAAnklEQVR4XuXBMQEAAADCoPVP bQsfIJ/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6f z+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8 Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz3c1nKQAAZiW0oUAAAAASUVORK5CYII=' ) base64Decoded asByteArray readStream.
If we stick this into a temporary class that gets deleted in a later update then the overhead is temporary.
Btw, about such overhead.. Recently i'm also added a data blob in a method. And i thought, that it would be cool to not persist the data as a code, but instead put it into the comment. So, a generic method , carrying a data blob could be just:
someData "iVBORw0KGgoAAAANSUhEUgAAAGQAAABkCAYAAABw4pVUAAAAnklEQVR4XuXBMQEAAADCoPVP bQsfIJ/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6f z+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8 Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz3c1nKQAAZiW0oUAAAAASUVORK5CYII= "
in this way given blob is not part of an image, it is a part of source files. And, by having a method source, it is easy to read a data from it. How do you like the idea
Interesting! The instance creation code would have to go look for the data in the method comment. I guess it makes sense if the idea is _not_ to remove the data. This might make sense, as someone might remove some font sizes, or convert them to a lower bit depth, and it would be nice to be able to recreate them again. Let's see how much it adds to the changes file.
Cheers, Juan Vuletich
"Igor" == Igor Stasenko siguctua@gmail.com writes:
Igor> someData Igor> "iVBORw0KGgoAAAANSUhEUgAAAGQAAABkCAYAAABw4pVUAAAAnklEQVR4XuXBMQEAAADCoPVP Igor> bQsfIJ/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6f Igor> z+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8 Igor> Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz3c1nKQAAZiW0oUAAAAASUVORK5CYII= Igor> "
How is this different from
someData ^' .... '
other than requiring a lot more confusing magic?
On 02.08.2009, at 21:36, Randal L. Schwartz wrote:
"Igor" == Igor Stasenko siguctua@gmail.com writes:
Igor> someData Igor> "iVBORw0KGgoAAAANSUhEUgAAAGQAAABkCAYAAABw4pVUAAAAnklEQVR4XuXBMQEAAADCoPVP Igor> bQsfIJ/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/ P5/P5fD6f Igor> z+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw +n8/n8/l8 Igor> Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/ P5fD6fz3c1nKQAAZiW0oUAAAAASUVORK5CYII= Igor> "
How is this different from
someData ^' .... '
other than requiring a lot more confusing magic?
Commment ∉ Literals
- Bert -
"Bert" == Bert Freudenberg bert@freudenbergs.de writes:
Bert> Commment ∉ Literals
Yes, I understand that.
To put the data into a comment means some magic has to happen to parse source text to get at the value.
To put the data into a literal means I simply call the method to get the value.
What's the downside of having it as a literal?
I know the downside of having it as a comment: far more mechanism, and thus, more fragile code and maintenance.
On 02.08.2009, at 21:59, Randal L. Schwartz wrote:
"Bert" == Bert Freudenberg bert@freudenbergs.de writes:
Bert> Commment ∉ Literals
Yes, I understand that.
To put the data into a comment means some magic has to happen to parse source text to get at the value.
To put the data into a literal means I simply call the method to get the value.
What's the downside of having it as a literal?
I know the downside of having it as a comment: far more mechanism, and thus, more fragile code and maintenance.
Literals are actual objects in the image.
- Bert -
2009/8/2 Randal L. Schwartz merlyn@stonehenge.com:
"Bert" == Bert Freudenberg bert@freudenbergs.de writes:
Bert> Commment ∉ Literals
Yes, I understand that.
To put the data into a comment means some magic has to happen to parse source text to get at the value.
To put the data into a literal means I simply call the method to get the value.
What's the downside of having it as a literal?
the downside is, that data you holding in a literal is not exactly what you want it to be. And often it needs some additional steps(convesion) to be useful. So, since you anyways needing a conversion , converting from a literal or from a method source code doesn't makes much difference, except that if you keep it in literal - it will add a data bloat to an .image.
I know the downside of having it as a comment: far more mechanism, and thus, more fragile code and maintenance.
-- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
Igor Stasenko wrote:
Btw, about such overhead.. Recently i'm also added a data blob in a method. And i thought, that it would be cool to not persist the data as a code, but instead put it into the comment. So, a generic method , carrying a data blob could be just:
someData "iVBORw0KGgoAAAANSUhEUgAAAGQAAABkCAYAAABw4pVUAAAAnklEQVR4XuXBMQEAAADCoPVP bQsfIJ/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6f z+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8 Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz3c1nKQAAZiW0oUAAAAASUVORK5CYII= "
in this way given blob is not part of an image, it is a part of source files. And, by having a method source, it is easy to read a data from it. How do you like the idea?
You mean like this?
blankForm "iVBORw0KGgoAAAANSUhEUgAAAGQAAABkCAYAAABw4pVUAAAAnklEQVR4XuXBMQEAAADCoPVP bQsfIJ/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6f z+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8 Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz3c1nKQAAZiW0oUAAAAASUVORK5CYII=" ^Form fromBinaryStream: (self class firstPrecodeCommentFor: thisContext method selector) base64Decoded asByteArray readStream
I don't really care. Either way is fine as long as it's one-time use.
Cheers, - Andreas
2009/8/2 Andreas Raab andreas.raab@gmx.de:
Igor Stasenko wrote:
Btw, about such overhead.. Recently i'm also added a data blob in a method. And i thought, that it would be cool to not persist the data as a code, but instead put it into the comment. So, a generic method , carrying a data blob could be just:
someData "iVBORw0KGgoAAAANSUhEUgAAAGQAAABkCAYAAABw4pVUAAAAnklEQVR4XuXBMQEAAADCoPVP bQsfIJ/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6f z+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8 Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz3c1nKQAAZiW0oUAAAAASUVORK5CYII= "
in this way given blob is not part of an image, it is a part of source files. And, by having a method source, it is easy to read a data from it. How do you like the idea?
You mean like this?
yeah..
blankForm "iVBORw0KGgoAAAANSUhEUgAAAGQAAABkCAYAAABw4pVUAAAAnklEQVR4XuXBMQEAAADCoPVP bQsfIJ/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6f z+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8 Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz3c1nKQAAZiW0oUAAAAASUVORK5CYII="
^Form fromBinaryStream: (self class firstPrecodeCommentFor: thisContext method selector) base64Decoded asByteArray readStream
ouch.. this is soo easy! Smalltalk rules! :)
I don't really care. Either way is fine as long as it's one-time use.
Cheers, - Andreas
Andreas Raab wrote:
Juan Vuletich wrote:
I guess I was being too optimistic. I honestly tried to do it. First I tried to file in the Editor classes from Cuis. Unfortunately, they are differences that make them incompatible, for example in NewParagraph.
I did it slightly differently and had no problems:
- File out Editor, TextEditor, file those into Squeak.
- Make a subclass of TextMorph called TextEditorMorph
- Give it the editorClass TextEditor, open it, edit it
At this point I had one blow-up resulting from missing NewParagraph>>replaceFrom:to:with:. I added it and everything seemed to work.
Great!!! My mistake here is that I want to know exactly what behavior I'm modifying. So I turned to the other approach, using clones of the existing classes. That faced me to the need to check perhaps 40 senders for each of about 100 methods that would be modified or removed. Checking 4000 methods is no fun! Good you tried the more reasonable way.
I then upped the ante a little and replaced TextMorph>>editorClass with TextEditor. And guess what, it seems to be working quite well, except from a few issues like:
- One cannot get rid of text selection by clicking inside the old
selection. I'm presuming that this is done for mobile devices but we should have a preference for governing that.
You're right. I'll add a preference for that for Cuis, but as it is done outside TextEditor (in MouseClickState), for Squeak, the best is to just remove it. This is easy. In TextEditor>>mouseDown: remove the line: (oldInterval includes: b stringIndex) ifTrue: [ ^self ].
- Programming short cuts do not work (browse senders, implementors
etc). How are shortcuts expected to work here? Should these be in a subclass? (some advice would be welcome).
I moved them to SmalltalkEditor subclass. I'd not add it to Squeak, as the "proper" refactoring (moving down lots of methods from TextEditor to SmalltalkEditor) is not yet done. So, just fold the 4 class methods from SmalltalkEditor into TextEditor. Or you can load them from TextMorphEditor.
Other than that I haven't found any problems whatsoever yet.
Excellent!
I know. Perhaps my anti aliased StrikeFonts could be included in Squeak. I don't know how to handle the creation of instances. Monticello can only handle code, right? No live instances or binary (bmp) files?
We can work this out. In the worst case, initializer methods can carry code as well, along the lines of:
blankForm "Created using: (ByteArray streamContents:[:s| PNGReadWriter putForm: (Form extent: 100@100 depth: 32) onStream: s]) asString base64Encoded. " ^Form fromBinaryStream: ( 'iVBORw0KGgoAAAANSUhEUgAAAGQAAABkCAYAAABw4pVUAAAAnklEQVR4XuXBMQEAAADCoPVP bQsfIJ/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6f z+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8 Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz3c1nKQAAZiW0oUAAAAASUVORK5CYII=' ) base64Decoded asByteArray readStream.
If we stick this into a temporary class that gets deleted in a later update then the overhead is temporary.
Good idea, thanks! I'll try to build an updated package for Squeak using this.
Cheers, Juan Vuletich
Cheers,
- Andreas
Hi Andreas,
Andreas Raab wrote:
Juan Vuletich wrote:
I know. Perhaps my anti aliased StrikeFonts could be included in Squeak. I don't know how to handle the creation of instances. Monticello can only handle code, right? No live instances or binary (bmp) files?
We can work this out. In the worst case, initializer methods can carry code as well, along the lines of:
blankForm "Created using: (ByteArray streamContents:[:s| PNGReadWriter putForm: (Form extent: 100@100 depth: 32) onStream: s]) asString base64Encoded. " ^Form fromBinaryStream: ( 'iVBORw0KGgoAAAANSUhEUgAAAGQAAABkCAYAAABw4pVUAAAAnklEQVR4XuXBMQEAAADCoPVP bQsfIJ/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6f z+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8 Pp/P5/P5fD6fz+fz+Xw+n8/n8/l8Pp/P5/P5fD6fz3c1nKQAAZiW0oUAAAAASUVORK5CYII=' ) base64Decoded asByteArray readStream.
If we stick this into a temporary class that gets deleted in a later update then the overhead is temporary.
I have the new fonts working in Squeak 3.10.2. All I need to do now is to encode the forms as you say, and upload my stuff.
I've just downloaded http://ftp.squeak.org/current_development/Squeak3.10.2-build/latest/090628-1... and didn't find #base64Encoded and #base64Decoded in it. I guess I need to update to the latest trunk, right?
Are there some step by step guide on how to update from the trunk, and how to later update it with my changes? (I've already followed the directions in my invitation to be a core developer). I haven't used Monticello in the last 4 years or so...
Cheers, Juan Vuletich
Cheers,
- Andreas
Juan Vuletich wrote:
I have the new fonts working in Squeak 3.10.2. All I need to do now is to encode the forms as you say, and upload my stuff.
Wonderful!
I've just downloaded http://ftp.squeak.org/current_development/Squeak3.10.2-build/latest/090628-1... and didn't find #base64Encoded and #base64Decoded in it. I guess I need to update to the latest trunk, right?
This isn't the right starting point. The easiest way to get going is to fetch the image from http://squeakvm.org/win32/release/Squeak-3.10.2-trunk.zip and in there just hit the "Load code from server" button. (I need to find out how to get a version up on squeak.org).
Are there some step by step guide on how to update from the trunk, and how to later update it with my changes? (I've already followed the directions in my invitation to be a core developer). I haven't used Monticello in the last 4 years or so...
Updating from the trunk is easy enough, and assuming that you have a change set, all you need is to file it in and push it back into the trunk. The trunk has been set up so that you can just update after pushing a new version.
Let me know if you have any problems.
Cheers, - Andreas
Andreas Raab wrote:
Juan Vuletich wrote:
I have the new fonts working in Squeak 3.10.2. All I need to do now is to encode the forms as you say, and upload my stuff.
Wonderful!
I've just downloaded http://ftp.squeak.org/current_development/Squeak3.10.2-build/latest/090628-1... and didn't find #base64Encoded and #base64Decoded in it. I guess I need to update to the latest trunk, right?
This isn't the right starting point. The easiest way to get going is to fetch the image from http://squeakvm.org/win32/release/Squeak-3.10.2-trunk.zip and in there just hit the "Load code from server" button. (I need to find out how to get a version up on squeak.org).
Great. Thanks.
Are there some step by step guide on how to update from the trunk, and how to later update it with my changes? (I've already followed the directions in my invitation to be a core developer). I haven't used Monticello in the last 4 years or so...
Updating from the trunk is easy enough, and assuming that you have a change set, all you need is to file it in and push it back into the trunk. The trunk has been set up so that you can just update after pushing a new version.
Let me know if you have any problems.
Ok. I updated my image to latest, loaded the code and tried to update the trunk but I got:
'HTTP/1.1 401 Unauthorized Date: Mon, 03 Aug 2009 17:06:47 GMT Server: Comanche/6.2 (unix) WWW-Authenticate: Basic realm="The Trunk" X-Code-Repository: Squeak Releases Content-type: text/html Content-length: 30 Connection: close<h1>Authentication Failed</h1>'
I sent the mail requesting access today, and it seems I need to wait to be authorized to save. Do I need to wait for a confirmation email telling me I'm able to write?
In any case, if you want to see it right now, just download http://www.jvuletich.org/Squeak/Misc/EnhancedStrikeFonts.zip . I only included DejaVu 9 Book / Bold / Oblique / BoldOblique. This font is great for code. If people wants, I can build any other sizes.
One last question. After loading all the packages, it would be great to evaluate 'StrikeFont installDejaVu'. Is there some way to evaluate it only after all 3 packages are loaded? Knowing the load order would be an option...
Cheers, Juan Vuletich
Cheers,
- Andreas
Juan Vuletich wrote:
Let me know if you have any problems.
Ok. I updated my image to latest, loaded the code and tried to update the trunk but I got:
'HTTP/1.1 401 Unauthorized Date: Mon, 03 Aug 2009 17:06:47 GMT Server: Comanche/6.2 (unix) WWW-Authenticate: Basic realm="The Trunk" X-Code-Repository: Squeak Releases Content-type: text/html Content-length: 30 Connection: close<h1>Authentication Failed</h1>'
I sent the mail requesting access today, and it seems I need to wait to be authorized to save. Do I need to wait for a confirmation email telling me I'm able to write?
You should be able to do that now. Ken has added you to the core-dev group. In order to tell Monticello about the authentication, select the repository "http://source.squeak.org/trunk" and choose "edit repository info" from the context menu. In there, you can give your user name (jmv) and the proper password. That should be all.
In any case, if you want to see it right now, just download http://www.jvuletich.org/Squeak/Misc/EnhancedStrikeFonts.zip . I only included DejaVu 9 Book / Bold / Oblique / BoldOblique. This font is great for code. If people wants, I can build any other sizes.
One last question. After loading all the packages, it would be great to evaluate 'StrikeFont installDejaVu'. Is there some way to evaluate it only after all 3 packages are loaded? Knowing the load order would be an option...
Yes. The load order is defined by the configuration used. If you point Monticello to http://source.squeak.org/trunk and then "browse" update-ar.8.mcm you can see in which order the packages will be updated. If this order is not appropriate for you, then do this: * Make sure your image is updated * Post your packages into the trunk * Browse update-ar.8.mcm * Move the package(s) that you need to change up or down so it's in the right load order * Click on "Update>>Update from Image" in the MCM browser (all packages are now current in the configuration) * Choose "Store" from the MCM browser * Give it the name "update-jmv.9" * Select the trunk repository to save it in This will put a new configuration with a different load order in place.
Cheers, - Andreas
Andreas Raab wrote:
I very much like what you've done with the editors. Is it correct that TextEditor is effectively protocol compatible with the old TextMorphEditor? If so, what do you think about bringing this into Squeak and phase out TextMorphEditor? Would this be doable or do you foresee any problems due to other changes that you might have done? From what I can see it looks as if this should be possible while preserving all the Unicode and m17n-goodness that I don't want to give up for Squeak. But boy, I would like to finally cut the Gordian knot called ParagraphEditor that ties Morphic and MVC together at the hip ;-)
So I did some more investigation (and a few quick experiments the results of which you can find in the trunk) and I am now convinced that we can separate Morphic and MVC and unload MVC in a fully reloadable form. The key is (of course) the text editors. I think the plan for unloading MVC goes as follows:
1) Load the Cuis text editors; start using them. There is some work needed for the usual programming shortcuts and a few fixes here and there (mostly due to the SmalltalkImage current madness) but really we mostly just need to start using them and fix issues as they come up.
2) Create a new category Kernel-Models which include Model, StringHolder, and ValueHolder. Move ParagraphEditor and other Kernel-ST 80 Remnants back into ST80.
3) Fix StringHolder>>codePaneMenu:shifted: not to use ParagraphEditor directly but rather to include an inline version of the method.
At this point I was able to unload MVC. After recompiling the entire system it turned out that most of the Undeclared references were to the various MVC menu classes (PopUpMenu, SelectionMenu, CustomMenu) and FillInTheBlank - all of which are easily replaced by UIManager.
The remaining references need a bit of actual work but I think we're relally talking about less than 100 methods total that need to be looked at. So it's entirely doable.
Question: Anyone interested in helping with this little project? Either by adding keyboard shortcuts to the Cuis editors or by helping fixing references to obsolete MVC references, or by testing the reloading of MVC?
Cheers, - Andreas
Hi Andreas and all!
Andreas Raab wrote: [LOTS of cool stuff]
Question: Anyone interested in helping with this little project? Either by adding keyboard shortcuts to the Cuis editors or by helping fixing references to obsolete MVC references, or by testing the reloading of MVC?
I am trying to spend my little time on DS but I still am tracking squeak-dev closely these days because of all the cool stuff you guys are doing. So I wanted to express my appreciation.
I do think this is a good "bootstrap" for squeak-dev - to integrate some cool and visual stuff from the other forks to show good solid progress. I have already noted that Pharo is trying to keep up with you too :)
And especially from Cuis since Juan is really making an effort to integrate/crossover with the squeak.org "fork".
I will try to get time to at least move over my DS work ontop of current trunk and doing that I will surely be able to at least glance on what is going on and testing it :)
regards, Göran
On 06.08.2009, at 11:46, Göran Krampe wrote:
I am trying to spend my little time on DS
One issue in the trunk dev model with current Monticello is that it's impossible to have my own local "pet" modifications, because when I upload a new package snapshot all my local modifications get submitted. How are others dealing with that? Am I right that delta streams might solve this problem?
- Bert -
Bert Freudenberg wrote:
On 06.08.2009, at 11:46, Göran Krampe wrote:
I am trying to spend my little time on DS
One issue in the trunk dev model with current Monticello is that it's impossible to have my own local "pet" modifications, because when I upload a new package snapshot all my local modifications get submitted. How are others dealing with that? Am I right that delta streams might solve this problem?
When I don't have too many changes to deal with I often do this by opening an MC change browser, reverting the methods I don't want to commit, then commit, then install these methods again. It's a bit awkward but works for situations where you don't have to deal with too many changes. And it fits into the workflow (I only leave the change browser open if I had actually reverted some methods for the commit).
Cheers, - Andreas
On Thu, Aug 6, 2009 at 4:20 AM, Bert Freudenberg bert@freudenbergs.dewrote:
On 06.08.2009, at 11:46, Göran Krampe wrote:
I am trying to spend my little time on DS
One issue in the trunk dev model with current Monticello is that it's impossible to have my own local "pet" modifications, because when I upload a new package snapshot all my local modifications get submitted. How are others dealing with that? Am I right that delta streams might solve this problem?
- Bert -
I keep a personal image with my modifications in it, and commit these local modifications to a scratch repository. When I want to submit something to trunk I open a trunk image, load in the changes I want from the scratch repository or via a change set and the ChangeList and submit from the trunk image. I then merge with the trunk package in my personal image.
Eliot
Hi!
Bert Freudenberg wrote:
On 06.08.2009, at 11:46, Göran Krampe wrote:
I am trying to spend my little time on DS
One issue in the trunk dev model with current Monticello is that it's impossible to have my own local "pet" modifications, because when I upload a new package snapshot all my local modifications get submitted. How are others dealing with that? Am I right that delta streams might solve this problem?
Yeah. :) Indeed one very interesting application of Deltas is a "quilt" like system in which you would track your local changes in Deltas and when you are about to say update the trunk you would unapply the Deltas, update, then reapply.
Before reapplying, the Deltas should in some nice DS UI show you what they think about reapplying them.
regards, Göran
Göran Krampe wrote:
Hi!
Bert Freudenberg wrote:
On 06.08.2009, at 11:46, Göran Krampe wrote:
I am trying to spend my little time on DS
One issue in the trunk dev model with current Monticello is that it's impossible to have my own local "pet" modifications, because when I upload a new package snapshot all my local modifications get submitted. How are others dealing with that? Am I right that delta streams might solve this problem?
Yeah. :) Indeed one very interesting application of Deltas is a "quilt" like system in which you would track your local changes in Deltas and when you are about to say update the trunk you would unapply the Deltas, update, then reapply.
Before reapplying, the Deltas should in some nice DS UI show you what they think about reapplying them.
regards, Göran
Oh, that would be sooo nice to have!
Cheers, Juan Vuletich
Göran Krampe wrote:
I do think this is a good "bootstrap" for squeak-dev - to integrate some cool and visual stuff from the other forks to show good solid progress. I have already noted that Pharo is trying to keep up with you too :)
At some point I want to have a talk about that. It is ineffective to work this way, by scraping (often partial) contributions from elsewhere but I think it's still too early to have this talk. I'll point out though that all the main Pharo contributors have standing invitations to join the core-dev group on source.squeak.org. And the process *is* open; if you see something that you like in Pharo and want to get into Squeak go for it!
Cheers, - Andreas
Hi Andreas!
Andreas Raab wrote:
Andreas Raab wrote:
I very much like what you've done with the editors. Is it correct that TextEditor is effectively protocol compatible with the old TextMorphEditor? If so, what do you think about bringing this into Squeak and phase out TextMorphEditor? Would this be doable or do you foresee any problems due to other changes that you might have done? From what I can see it looks as if this should be possible while preserving all the Unicode and m17n-goodness that I don't want to give up for Squeak. But boy, I would like to finally cut the Gordian knot called ParagraphEditor that ties Morphic and MVC together at the hip ;-)
So I did some more investigation (and a few quick experiments the results of which you can find in the trunk) and I am now convinced that we can separate Morphic and MVC and unload MVC in a fully reloadable form. The key is (of course) the text editors. I think the plan for unloading MVC goes as follows:
- Load the Cuis text editors; start using them. There is some work
needed for the usual programming shortcuts and a few fixes here and there (mostly due to the SmalltalkImage current madness) but really we mostly just need to start using them and fix issues as they come up.
- Create a new category Kernel-Models which include Model,
StringHolder, and ValueHolder. Move ParagraphEditor and other Kernel-ST 80 Remnants back into ST80.
- Fix StringHolder>>codePaneMenu:shifted: not to use ParagraphEditor
directly but rather to include an inline version of the method.
At this point I was able to unload MVC. After recompiling the entire system it turned out that most of the Undeclared references were to the various MVC menu classes (PopUpMenu, SelectionMenu, CustomMenu) and FillInTheBlank - all of which are easily replaced by UIManager.
The remaining references need a bit of actual work but I think we're relally talking about less than 100 methods total that need to be looked at. So it's entirely doable.
Question: Anyone interested in helping with this little project? Either by adding keyboard shortcuts to the Cuis editors or by helping fixing references to obsolete MVC references, or by testing the reloading of MVC?
Cheers,
- Andreas
I'm willing to help. I can fix the issues in the Cuis text editors. Just point me to the last version of the new editors you have, and any instructions on how to update from the latest trunk.
Cheers, Juan Vuletich
Juan Vuletich wrote:
I'm willing to help. I can fix the issues in the Cuis text editors. Just point me to the last version of the new editors you have, and any instructions on how to update from the latest trunk.
Cool. I've posted both Editor and TextEditor from Cuis (verbatim versions), added a DefaultEditorClass to TextMorph, and a preference to control its use. If you go to help>>preferences then search for useNewEditors, you can toggle the use of TextMorphEditor vs. TextEditor.
Also, I think your idea of having an explicit class SmalltalkEditor is a really good idea. It allows us a number of useful choices: For example, for someone shipping an app, you can replace the default morphic text editor class with one that doesn't allow users to evaluate code in the "find" dialog :^) Plus, the SmalltalkEditor could include hooks for syntax highlighting and auto-completion so that Shout and others don't need to patch all these other places.
BTW, I'm not sure what you mean by instructions on how to update from the current trunk. It should "just work". If you are encountering any problems please do report them.
Cheers, - Andreas
Andreas Raab wrote:
Juan Vuletich wrote:
I'm willing to help. I can fix the issues in the Cuis text editors. Just point me to the last version of the new editors you have, and any instructions on how to update from the latest trunk.
Cool. I've posted both Editor and TextEditor from Cuis (verbatim versions), added a DefaultEditorClass to TextMorph, and a preference to control its use. If you go to help>>preferences then search for useNewEditors, you can toggle the use of TextMorphEditor vs. TextEditor.
Also, I think your idea of having an explicit class SmalltalkEditor is a really good idea. It allows us a number of useful choices: For example, for someone shipping an app, you can replace the default morphic text editor class with one that doesn't allow users to evaluate code in the "find" dialog :^) Plus, the SmalltalkEditor could include hooks for syntax highlighting and auto-completion so that Shout and others don't need to patch all these other places.
Exactly :) I will add SmalltalkEditor too then. BTW, if this hierarchy can remain exactly the same as in Cuis it will be much easier for me to finish the refactoring. There is a lot of code in TextEditor that I'll be moving down to SmalltalkEditor. If I can do it just once, and use it both in Cuis and Squeak it would save me a lot of time.
BTW, I'm not sure what you mean by instructions on how to update from the current trunk. It should "just work". If you are encountering any problems please do report them.
Great! I guess I'm not used to things being always there. I was expecting you to have some change set lying around. The trunk is way cool!
I expect to have the new editors working during this weekend.
Cheers, Juan Vuletich
Cheers,
- Andreas
Andreas Raab wrote:
Juan Vuletich wrote:
any instructions on how to update from the latest trunk.
The trunk is way cool!
Agree with that! I've been following all this with interest.
It seems like it might be a good time to update the squeakfoundation.org main page with a pointer:
"Those who want to follow the latest developments can download a <3.11.x VM> and a <trunk image>, start it and hit Load Code Updates! to see the current state of development."
I've been listening and not much else, for a while, and it took a bit to track down what I needed to get up to date - the "stable download" link is still 7179 from 2008, which I guess is what "stable" means! But I really like having an image with one-click tracking to current.
Keep up the good work!
Kevin
Hi Folks,
Andreas Raab wrote:
Juan Vuletich wrote:
I'm willing to help. I can fix the issues in the Cuis text editors. Just point me to the last version of the new editors you have, and any instructions on how to update from the latest trunk.
Cool. I've posted both Editor and TextEditor from Cuis (verbatim versions), added a DefaultEditorClass to TextMorph, and a preference to control its use. If you go to help>>preferences then search for useNewEditors, you can toggle the use of TextMorphEditor vs. TextEditor.
Also, I think your idea of having an explicit class SmalltalkEditor is a really good idea. It allows us a number of useful choices: For example, for someone shipping an app, you can replace the default morphic text editor class with one that doesn't allow users to evaluate code in the "find" dialog :^) Plus, the SmalltalkEditor could include hooks for syntax highlighting and auto-completion so that Shout and others don't need to patch all these other places.
I updated the trunk with fixes to the new Editor hierarchy from Cuis. It is fully functional now.
Cheers, Juan Vuletich
Juan Vuletich wrote:
I updated the trunk with fixes to the new Editor hierarchy from Cuis. It is fully functional now.
I had to add a small compatibility method for making Parser correctVariable: etc. work correctly. Other than that it works great. I'm in favor of making them the default to give them a good workout and root out any issues we haven't noticed yet. If there's a problem we can always switch back. What do you think?
Cheers, - Andreas
On Wed, Aug 05, 2009 at 10:43:15PM -0700, Andreas Raab wrote:
Andreas Raab wrote:
Question: Anyone interested in helping with this little project? Either by adding keyboard shortcuts to the Cuis editors or by helping fixing references to obsolete MVC references, or by testing the reloading of MVC?
I'm definitely interested, though a bit short of time. I'll try to help test the reloading of MVC.
Dave
David T. Lewis wrote:
On Wed, Aug 05, 2009 at 10:43:15PM -0700, Andreas Raab wrote:
Andreas Raab wrote:
Question: Anyone interested in helping with this little project? Either by adding keyboard shortcuts to the Cuis editors or by helping fixing references to obsolete MVC references, or by testing the reloading of MVC?
I'm definitely interested, though a bit short of time. I'll try to help test the reloading of MVC.
Great. BTW, one thing that really needs to be done is a major Project refactoring. I love Projects; I think they are one of the defining properties of Squeak. Unfortunately, they are a bit out of shape right now ;-) What we need to do is to figure out how to refactor projects into something along the lines of:
Project ('parentProject' 'previousProject' 'uiProcess' ...) MVCProject ('controlManager' ...) MorphicProject ('world' ...)
When this is done properly we suddenly have room for a variety of actions that are otherwise difficult to handle: From how to deliver a user interrupt (Project current handleUserInterrupt) over custom subprojects (B3DWonderlandProject) up to per-project namespaces. There is a lot of interesting things that can be done with projects.
I'm not sure if you're up for this or not, but it definitely needs to be done for a completely smooth MVC removal - MVC needs to come with its own kinds of projects so that we can actually transfer between them, host them, etc.
Cheers, - Andreas
Andreas Raab wrote:
David T. Lewis wrote:
On Wed, Aug 05, 2009 at 10:43:15PM -0700, Andreas Raab wrote:
Andreas Raab wrote:
Question: Anyone interested in helping with this little project? Either by adding keyboard shortcuts to the Cuis editors or by helping fixing references to obsolete MVC references, or by testing the reloading of MVC?
I'm definitely interested, though a bit short of time. I'll try to help test the reloading of MVC.
Great. BTW, one thing that really needs to be done is a major Project refactoring. I love Projects; I think they are one of the defining properties of Squeak. Unfortunately, they are a bit out of shape right now ;-) What we need to do is to figure out how to refactor projects into something along the lines of:
Project ('parentProject' 'previousProject' 'uiProcess' ...) MVCProject ('controlManager' ...) MorphicProject ('world' ...)
When this is done properly we suddenly have room for a variety of actions that are otherwise difficult to handle: From how to deliver a user interrupt (Project current handleUserInterrupt) over custom subprojects (B3DWonderlandProject) up to per-project namespaces. There is a lot of interesting things that can be done with projects.
I'm not sure if you're up for this or not, but it definitely needs to be done for a completely smooth MVC removal - MVC needs to come with its own kinds of projects so that we can actually transfer between them, host them, etc.
Cheers,
- Andreas
How do you see Projects trying to maintain their own changes? I removed Projects from Cuis because I don't like them trying to look as if they could isolate changes when they can't. Perhaps some Monticello magic here? Or simply to make Project _not_ to carry any code with them? Then, some indication of what they require from the host image would be in order...
Cheers, Juan Vuletich
Juan Vuletich wrote:
How do you see Projects trying to maintain their own changes? I removed Projects from Cuis because I don't like them trying to look as if they could isolate changes when they can't. Perhaps some Monticello magic here? Or simply to make Project _not_ to carry any code with them? Then, some indication of what they require from the host image would be in order...
I'm not sure. My gut feeling is that the entire notion of "changes" is depending on context. What changes mean in Etoys (scripts represented by S-expressions) is different from what changes mean in Smalltalk hacking and is different what changes could mean in Wonderland scripting. As such I'd say that the notion of changes is something that one needs to deal with at a different level.
From a practical perspective however I'd say that having one change set per project (and the ability to switch between them when changing projects) is quite handy. But if someone were to say let's nuke change sets in projects and require people to switch them manually in the change sorter, I would probably be fine with that, too.
Cheers, - Andreas
Hi!
Just as a sidenote: Deltas in DS do not address Projects at all.
I would listen to arguments in either direction - I never really grokked Projects in this area.
regards, Göran
On Fri, Aug 7, 2009 at 6:04 AM, Juan Vuletich juan@jvuletich.org wrote:
Andreas Raab wrote:
David T. Lewis wrote:
On Wed, Aug 05, 2009 at 10:43:15PM -0700, Andreas Raab wrote:
Andreas Raab wrote:
Question: Anyone interested in helping with this little project? Either by adding keyboard shortcuts to the Cuis editors or by helping fixing references to obsolete MVC references, or by testing the reloading of MVC?
I'm definitely interested, though a bit short of time. I'll try to help test the reloading of MVC.
Great. BTW, one thing that really needs to be done is a major Project refactoring. I love Projects; I think they are one of the defining properties of Squeak. Unfortunately, they are a bit out of shape right now ;-) What we need to do is to figure out how to refactor projects into something along the lines of:
Project ('parentProject' 'previousProject' 'uiProcess' ...) MVCProject ('controlManager' ...) MorphicProject ('world' ...)
When this is done properly we suddenly have room for a variety of actions that are otherwise difficult to handle: From how to deliver a user interrupt (Project current handleUserInterrupt) over custom subprojects (B3DWonderlandProject) up to per-project namespaces. There is a lot of interesting things that can be done with projects.
I'm not sure if you're up for this or not, but it definitely needs to be done for a completely smooth MVC removal - MVC needs to come with its own kinds of projects so that we can actually transfer between them, host them, etc.
Cheers,
- Andreas
How do you see Projects trying to maintain their own changes? I removed Projects from Cuis because I don't like them trying to look as if they could isolate changes when they can't. Perhaps some Monticello magic here? Or simply to make Project _not_ to carry any code with them? Then, some indication of what they require from the host image would be in order...
But if you use a multi-window manager you don't expect the file system to be different underneath every screen. Projects are really useful as is and still use projects even though the bulk of my work is against a Monticello repository. With the change sorter the connection between change set and project is not a hard and fast one anymore and that's a good thing; it can be tedious to switch projects just to add a change elsewhere. But being able to have a collection of windows clustered around some project is great. But I miss tools for them, e.g. a search tool for strings in workspaces across projects, an auto-save-to-files facility for workspaces so I don't lose their contents when my Mac's screen saver locks up and I have to reboot. Sigh.
Cheers, Juan Vuletich
On Thu, Aug 06, 2009 at 10:08:51PM -0700, Andreas Raab wrote:
David T. Lewis wrote:
On Wed, Aug 05, 2009 at 10:43:15PM -0700, Andreas Raab wrote:
Andreas Raab wrote:
Question: Anyone interested in helping with this little project? Either by adding keyboard shortcuts to the Cuis editors or by helping fixing references to obsolete MVC references, or by testing the reloading of MVC?
I'm definitely interested, though a bit short of time. I'll try to help test the reloading of MVC.
Great. BTW, one thing that really needs to be done is a major Project refactoring. I love Projects; I think they are one of the defining properties of Squeak. Unfortunately, they are a bit out of shape right now ;-) What we need to do is to figure out how to refactor projects into something along the lines of:
Project ('parentProject' 'previousProject' 'uiProcess' ...) MVCProject ('controlManager' ...) MorphicProject ('world' ...)
When this is done properly we suddenly have room for a variety of actions that are otherwise difficult to handle: From how to deliver a user interrupt (Project current handleUserInterrupt) over custom subprojects (B3DWonderlandProject) up to per-project namespaces. There is a lot of interesting things that can be done with projects.
I'm not sure if you're up for this or not, but it definitely needs to be done for a completely smooth MVC removal - MVC needs to come with its own kinds of projects so that we can actually transfer between them, host them, etc.
I'll take a look at it for sure, but I'm afraid I'm probably overcommitted at the moment. Best not to count on me for anything big right now.
Dave
On Saturday 01 Aug 2009 3:35:02 am Juan Vuletich wrote:
I also added a TextEditor to the World menu that is not a Smalltalk Workspace and may be useful especially for end users.
I didn't see any Text editor in the World menu or 'open..' menu. I was able to create a new TextMorph and edit it. The selection behavior is unusual. If I select some text and then click outside the morph, the selection hint goes gray instead of vanishing. If I then click back in the selection, the green color hint returns and text stays selected instead of changing to a | cursor.
Is this working as designed?
Subbu
K. K. Subramaniam wrote:
On Saturday 01 Aug 2009 3:35:02 am Juan Vuletich wrote:
I also added a TextEditor to the World menu that is not a Smalltalk Workspace and may be useful especially for end users.
I didn't see any Text editor in the World menu or 'open..' menu. I was able to create a new TextMorph and edit it.
World / open / text editor. Or alternatively 'Stuff'edit.
The selection behavior is unusual. If I select some text and then click outside the morph, the selection hint goes gray instead of vanishing. If I then click back in the selection, the green color hint returns and text stays selected instead of changing to a | cursor.
Is this working as designed?
Yes. But that is due to another change I did. If you hold the button down for a little, you get the right-click menu. This is very useful for PDA and other pen based systems, and it actually mimics the behavior of such systems (at least that of my old WinCE pda).
Cheers, Juan Vuletich
Subbu
On Saturday 01 Aug 2009 6:07:38 pm Juan Vuletich wrote:
K. K. Subramaniam wrote:
I didn't see any Text editor in the World menu or 'open..' menu. I was able to create a new TextMorph and edit it.
World / open / text editor. Or alternatively 'Stuff'edit.
Mea Culpa. I was using an older version :-(.
#edit is a neat idea. It can be consistently applied to any unlocked morph (e.g. LineMorph, PolygonMorph, SketchMorph etc.). Shift-click and edit Halo handle can be tied to this message. The message can be ignored by locked morphs (e.g. labels).
Yes. But that is due to another change I did. If you hold the button down for a little, you get the right-click menu. This is very useful for PDA and other pen based systems, and it actually mimics the behavior of such systems (at least that of my old WinCE pda).
Nice feature. But a hold (tap and wait) is different from a click. Shouldn't the event be handled in TextEditor>>mouseUp: where the waiting time can be checked?
BTW, In PluggableTextMorph>>keystroke: there is a typo "keywtroke" in comments.
Subbu
K. K. Subramaniam wrote:
On Saturday 01 Aug 2009 6:07:38 pm Juan Vuletich wrote:
K. K. Subramaniam wrote:
I didn't see any Text editor in the World menu or 'open..' menu. I was able to create a new TextMorph and edit it.
World / open / text editor. Or alternatively 'Stuff'edit.
Mea Culpa. I was using an older version :-(.
#edit is a neat idea. It can be consistently applied to any unlocked morph (e.g. LineMorph, PolygonMorph, SketchMorph etc.). Shift-click and edit Halo handle can be tied to this message. The message can be ignored by locked morphs (e.g. labels).
Yes. But that is due to another change I did. If you hold the button down for a little, you get the right-click menu. This is very useful for PDA and other pen based systems, and it actually mimics the behavior of such systems (at least that of my old WinCE pda).
Nice feature. But a hold (tap and wait) is different from a click. Shouldn't the event be handled in TextEditor>>mouseUp: where the waiting time can be checked?
It could, I guess. What's the problem with how I did it (in ##waitForSimulatedYellow:event:)?
BTW, In PluggableTextMorph>>keystroke: there is a typo "keywtroke" in comments.
Subbu
Cheers, Juan Vuletich
On Sunday 02 Aug 2009 7:52:57 am Juan Vuletich wrote:
Nice feature. But a hold (tap and wait) is different from a click. Shouldn't the event be handled in TextEditor>>mouseUp: where the waiting time can be checked?
It could, I guess. What's the problem with how I did it (in ##waitForSimulatedYellow:event:)?
I couldn't reset the cursor position using a click on the selection (imagine the whole text is selected. How do I cancel it?). I couldn't reselect a subtext within selection using a drag. If the word "thisisalongword" is selected and you try dragging "long", the selection shortens to "thisisalong". I traced this annoyance to TextEditor>>mouseDown: (oldInterval includes: b stringIndex) ifTrue: [ ^self ].
If the gesture is detected at mouseUp time, then there is no ambiguity between quick click, long click and double-click.
Press-to-popup menu violates principle of least astonishment. If the mouse is moved slightly during a slow click, the menu popups, an item gets picked and the popup disappears in flash leaving no time to see which item got picked.
BTW, when you eliminated scroll bars for fully visible lists and texts, you also eliminated the context menu button at the top :-(.
Subbu
K. K. Subramaniam wrote:
On Sunday 02 Aug 2009 7:52:57 am Juan Vuletich wrote:
Nice feature. But a hold (tap and wait) is different from a click. Shouldn't the event be handled in TextEditor>>mouseUp: where the waiting time can be checked?
It could, I guess. What's the problem with how I did it (in ##waitForSimulatedYellow:event:)?
I couldn't reset the cursor position using a click on the selection (imagine the whole text is selected. How do I cancel it?). I couldn't reselect a subtext within selection using a drag. If the word "thisisalongword" is selected and you try dragging "long", the selection shortens to "thisisalong". I traced this annoyance to TextEditor>>mouseDown: (oldInterval includes: b stringIndex) ifTrue: [ ^self ].
That line of code has this comment above: "If click is inside the selection, do not modify it. This is so the 'tap and wait' gesture (used to bring pop-up menu on pen devices) does not affect selection, allowing to do copy / paste of selection with menu on pen devices."
If you remove that line, then when opening the menu, to do, for example, 'copy', you always lose the selection first.
If the gesture is detected at mouseUp time, then there is no ambiguity between quick click, long click and double-click.
The problem is that click and drag, to select, is done in #mouseMove:, i.e. before #mouseUp:. So the decision on wether to keep the selection unchanged (because a menu request could follow) and allow the user to modify the selection, needs to be done in #mouseDown: / #mouseMove:
Play a bit with the code. If you come up with something that works better, I'd be really happy.
Press-to-popup menu violates principle of least astonishment. If the mouse is moved slightly during a slow click, the menu popups, an item gets picked and the popup disappears in flash leaving no time to see which item got picked.
I agree. But I don't know a better way to do it, and pen computers do it like that.
The only solution I see is to add a preference to enable press-to-menu only if you want it.
BTW, when you eliminated scroll bars for fully visible lists and texts, you also eliminated the context menu button at the top :-(.
That's what the press-to-menu gesture is for, right? They are not hard to add back. But I think it makes no sense to have a scrollbar that has nothing to scroll.
Subbu
Cheers, Juan Vuletich
On Sunday 02 Aug 2009 6:49:15 pm Juan Vuletich wrote:
Play a bit with the code. If you come up with something that works better, I'd be really happy.
Attached is my first stab at it. I have refactored the three mouse event handlers in TextEditor. I still haven't figured out why context menu pops up while the mouse button is still down.
Subbu
Hi Subbu,
K. K. Subramaniam wrote:
On Sunday 02 Aug 2009 6:49:15 pm Juan Vuletich wrote:
Play a bit with the code. If you come up with something that works better, I'd be really happy.
Attached is my first stab at it. I have refactored the three mouse event handlers in TextEditor. I still haven't figured out why context menu pops up while the mouse button is still down.
That's because of MouseClickState. In your code you did not disable it. It is called from #waitForSimulatedYellow:event: .
Subbu
This is my fix. Thanks for bringing up the issue!
Cheers, Juan Vuletich
'From Cuis 1.0 of 31 July 2009 [latest update: #250] on 3 August 2009 at 12:23:12 pm'!
!TextEditor methodsFor: 'events' stamp: 'jmv 8/3/2009 12:19'! mouseDown: evt "An attempt to break up the old processRedButton code into threee phases" | clickPoint b |
oldInterval _ self selectionInterval. clickPoint _ evt cursorPoint. b _ paragraph characterBlockAtPoint: clickPoint.
(paragraph clickAt: clickPoint for: model controller: self) ifTrue: [ self markBlock: b. self pointBlock: b. evt hand releaseKeyboardFocus: self. ^ self ]. evt shiftPressed ifFalse: [ self closeTypeIn. self markBlock: b. self pointBlock: b ]! !
!TextEditor methodsFor: 'events' stamp: 'jmv 8/3/2009 12:13'! mouseMove: evt "Change the selection in response to mouse-down drag"
self pointBlock: (paragraph characterBlockAtPoint: (evt cursorPoint)). self storeSelectionInParagraph! !
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
David T. Lewis -
Eliot Miranda -
Göran Krampe -
Igor Stasenko -
Juan Vuletich -
K. K. Subramaniam -
Kevin -
merlyn＠stonehenge.com