- Pharo-dev - lists.pharo.org

Re: [Pharo-project] XML Parser, Monticello and unicode?

by Alexandre Bergel

The solution for now seems to remove this tests. It can be moved into a different package. How does that sound? Cheers, Alexandre On 5 Aug 2010, at 11:37, Norbert Hartl wrote: > I'm trying to port the newest XML Parser from squeaksource to gemstone. In XML-Parser-AlexandreBergel.73 there is a unicode test introduced with a longer unicode xml snippet. From this release on I cannot load or merge anything. > > Besides that the xml snippet looks very strange it loads in pharo but not in gemstone. Unpacking the mcz on the console and examine the content showed that the encoding is indeed weird. I don't know what it is but it is neither ascii nor utf-8. Pharo loaded the snippet into a WideString instance. > > How does monticello handle WideString instances when written to a file? > > Norbert > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 9, 2010

Re: [Pharo-project] XML Parser, Monticello and unicode?

by Alexandre Bergel

> There is no way monticello can handle multi byte strings as it uses latin1 for encoding. Hi Norbert, I often have very large Strings in my tests. Monticello behaves as it should. I haven't seen any problem. The problem you bumped into seems to stem from accented characters. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 9, 2010

Re: [Pharo-project] XML Parser, Monticello and unicode?

by Philippe Marschall

On 08/08/2010 12:14 AM, Norbert Hartl wrote: > > On 07.08.2010, at 20:58, Philippe Marschall wrote: > >> On 07.08.2010 13:08, Norbert Hartl wrote: >>> .... >>> To estimate the possibility to change this I think we should fix this. I scanned all of my cached monticello packages. Most of them are 7bit clean. No problem for them if we change encoding. Besides XML Parser I didn't find any that contain WideString so no problem here. Some of them are latin1 encoded (like Seaside 2.8 or Seaside-InternetExplorer from 3.0). That is the biggest problem because there is no fallback and monticello does not have a version number on file format, right? >>> I think it is still feasible to change this in monticello as the fix for users of older images will be probably only a few lines that you can apply to any version of monticello if I'm not wrong. But the change is not that easy. >> >> We try to be 7bit clean in Seaside. Can you report the methods you have >> trouble with to either the seaside mailing list or the issue tracker [1]? >> > I don't have troubles with any of the seaside methods. It just seems impossible for me to state things clear enough :) There was a real problem. There was WideStrings creeping into the monticello package of XML Parser. There is no way monticello can handle multi byte strings as it uses latin1 for encoding. The latin1 encoded WideStrings cannot be read by gemstone. But the troublesome piece of code has already been removed from the XML Parser package. > > Seaside is not completely 7bit clean. As an example take Seaside-InternetExplorer-lr.6.mcz. There is a sentence "...we have introduced a mechanism to help prevent the untrusted content from compromising your site<92>s security...". The <92> is a RIGHT SINGLE QUOTATION MARK that Microsoft put into the latin1 gap. So I guess this is CP1252 which means it has been copied from a windows system into the squeak image. Yeah, that was copied and pasted from a blog post. My mistake, sorry, will fix it. CP1252 is evil. Cheers Philippe

Aug. 9, 2010

Re: [Pharo-project] Keyboard Shortcuts: Keymapping now loads in Pharo core 1.2

by StÃ©phane Ducasse

Cool! Thanks Sean. I took an evening and look at Keymapper, SVI and KeyBinding based on the image you gave me. and here are my conclusions - SVI seems powerful but too large and complex to me. (this is a complete scriptable editor from what I see) - keyBinder was just a morph or too not really what we are looking for - keymapper looks the most promising :) Stef On Aug 9, 2010, at 12:52 AM, Sean P. DeNigris wrote: > > To get the ball moving, I ported one of the keyboard shortcut packages, > Keymapping, to Pharo. Maybe if we start playing with it, we'll see what > works and what doesn't, and use it to create something great. > > The Metacello configuration is at http://www.squeaksource.com/Keymapping > > Sean > -- > View this message in context: http://forum.world.st/Keyboard-Shortcuts-Keymapping-now-loads-in-Pharo-core… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 9, 2010

Re: [Pharo-project] Early days of an MVP framework

by Gary Chambers

And with a stack layout... (UITheme builder newColumn: { UITheme builder newTabGroup: { 'First page' -> ((UITheme builder newStack: { (UITheme builder newAlphaImage: UITheme current warningIcon help: nil) alpha: 0.5. CircleMorph new hResizing: #spaceFill; vResizing: #spaceFill}) fillStyle: Color red; hResizing: #spaceFill; vResizing: #spaceFill). 'Second page' -> (UITheme builder newPanel fillStyle: Color green; hResizing: #spaceFill; vResizing: #spaceFill)}. (UITheme builder newRow: { UITheme builder newOKButton. UITheme builder newCancelButton}) listCentering: #bottomRight}) extent: 200@300; openInWindow Regards, Gary ----- Original Message ----- From: "Gary Chambers" <gazzaguru2(a)btinternet.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, August 09, 2010 11:30 AM Subject: Re: [Pharo-project] Early days of an MVP framework > This even (to get buttons on right with correct tab key navigation > ordering... > > (UITheme builder > newColumn: { > UITheme builder newTabGroup: { > 'First page' -> (UITheme builder newPanel > fillStyle: Color red; > hResizing: #spaceFill; > vResizing: #spaceFill). > 'Second page' -> (UITheme builder newPanel > fillStyle: Color green; > hResizing: #spaceFill; > vResizing: #spaceFill)}. > (UITheme builder newRow: { > UITheme builder newOKButton. > UITheme builder newCancelButton}) > listCentering: #bottomRight}) > extent: 200@300; > openInWindow > > > Regards, Gary > > ----- Original Message ----- > From: "Gary Chambers" <gazzaguru2(a)btinternet.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, August 09, 2010 11:07 AM > Subject: Re: [Pharo-project] Early days of an MVP framework > > >> Any Morph can use a layoutPolicy. >> Available are >> none (position based) >> Prorportional (frame/fractions/offsets) >> Table (overly complex too) >> Row (one of mine, quicker for simple rows) >> Stack (mine, overlay morphs on top of each other) >> >> TEasilyThemed provides some methods like... >> >> newRow: {aMorph, anotherMorph} >> newColumn: >> >> Something like this works... >> >> (UITheme builder >> newColumn: { >> UITheme builder newPanel >> fillStyle: Color red; >> hResizing: #spaceFill; >> vResizing: #spaceFill. >> UITheme builder newRow: { >> UITheme builder newOKButton. >> UITheme builder newCancelButton}}) >> extent: 200@300; >> openInHand >> >> (can use openInWindow also)... >> >> Rather busy today, hope this helps in the meantime... >> >> Regards, Gary >> >> ----- Original Message ----- >> From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> >> To: <pharo-project(a)lists.gforge.inria.fr> >> Sent: Sunday, August 08, 2010 11:46 PM >> Subject: [Pharo-project] Early days of an MVP framework >> >> >>> Gary, >>> >>> I was on an unstoppable roll (salvaged early on by Andreas' bitblt >>> coaching), until I needed to repeat a "complex" GUI component and >>> wanted/insisted on doing so with some reuse. Seaside gives us >>> components on web pages; we need them for GUI code too. I tried turning >>> my presenter-like structures into factories that would add morphs to a >>> single shell, but it fell apart when it came time to set the framing >>> values. I was not particularly interested in fixing it, because if I >>> could do that, I would simply build proper composite widgets using the >>> fix. >>> >>> The problem appears to be in SystemWindow, which does some incredibly >>> complicated things, all of which (correct me if I am wrong) would be >>> unnecessary if only there were a good set of layout managers. I can get >>> very simple-minded about things, but it would make a whole lot more >>> sense to me to create rows and columns of widgets, adding splitters >>> between them until the whole things behaves as intended, rather than >>> writing code (present only in a top-level shell) that tries to split >>> things up into rows using its own judgment. Not good. I realize you >>> did not create the situation, and have done wonders to make it work far >>> better than when you found it. >>> >>> Some time ago, I built an emulated widget framework for Dolphin, which I >>> needed because the combination of Dolphin's view resources and Windows >>> itself was too slow for what I was trying to do. That project included >>> a somewhat strange set of layout classes, but the basics are present, >>> and it is not Object Arts' IP. I ported the classes to Pharo and did >>> some work on stub View and Presenter classes that I had added to Pharo >>> largely to passify my code that I was importing from Dolphin. The >>> layouts think in terms of emulated widgets, and I see no reason to >>> change their minds: I might want to replicate the framework. However, >>> dynamic typing and a couple of extra methods allow them to work with >>> just about anything. My goals are modest. Being able to compose rows >>> and columns would do a lot for me. Add splitters and the ability to fix >>> the size of some items, and I could almost anything I would need. >>> >>> View class>>example >>> | row column dot square out shell | >>> dot := ( Form dotOfSize:100 ) asFormOfDepth:32. >>> square := ( Form squareOfSize:100 ) asFormOfDepth:32. >>> out := Array writeStream. >>> >>> row := ContainerView row. >>> 2 timesRepeat:[ >>> column := row addSubview:ContainerView column. >>> 2 timesRepeat:[ >>> out nextPut:( >>> column addSubview:ImageView new >>> ). >>> ]. >>> ]. >>> >>> out contents with:{ dot copy. square copy. square copy. dot copy. } >>> do:[ :view :form | >>> view morph image:form. >>> ]. >>> >>> row rectangle:( 0@0 extent:400@400 ). >>> row layout. >>> >>> shell := StandardWindow labelled:'Hello MVP'. >>> ^shell addMorph:row morph frame:( 0@0 extent:1@1 ); yourself. >>> >>> >>> The above code produces an array of dots and squares, as intended. One >>> quirk is that the grid does not resize as the shell resizes, a >>> consequence of my not having hooked it up to resize events. I might get >>> some interesting meltdowns once I begin to do that =:0 I used your >>> PanelMorph as the "view" associated with ContainerView. What, >>> ContainView isn't a view??? No. The code is biased toward Morphic, but >>> hopefully the same code should extend to wx, GTK, etc. Dolphin's views >>> have a handle instance variable to control the external resource; these >>> views have an instance variable pointing to their morph. Handling of >>> sub views works pretty much as in Dolphin: any view/morph can have >>> children, but adding them is "legal" only for composites. >>> >>> Most systems I have seen treat coordinates relative to the parent/owner, >>> but not Morphic. I remember seeing plans to make the change, but >>> nothing after that. The view instances provide a natural place to fix >>> things, so I took the plunge. If we switch to some other graphical >>> realization, we can simply remove the the transformation. >>> >>> Are the existing splitters as strange as SystemWindow? By that I mean, >>> would it be reasonable to add them between other morphs and look for >>> events from them, or will they have to be replaced? I will eventually >>> need splitters, but I could initially live without them if I can get >>> reliable composition where I need it. >>> >>> There are very few view classes at present. MorphView can wrap almost >>> anything, so it might be better to create a rich set of presenters >>> instead. Dolphin's view resources are going to be interesting to >>> replace. There are some complexities that I suspect are in deference to >>> Windows, and some that might be avoidable. For our purposes, it might >>> be enough to use SIXX to serialize a bunch of message sends and gzip the >>> results to save memory. Another option might be to rely on class >>> methods; having full closures won't hurt; they might allow sufficient >>> hooking that resources in the Dolphin sense won't even be necessary. >>> The desire for them quickly arises because views get realized in places >>> know nothing about how the views should be configured; at least I think >>> that is what happened to me after just a couple of hours. I am far less >>> interested in having a graphical view editor than I am in being able to >>> write **GOOD** code that assembles things as I want. If the result >>> happens to allow a graphical editor too, so much the better. >>> >>> Any interest? >>> >>> Bill >>> >>> >>> ----------------------------- >>> >>> View >>> MorphViev >>> ImageView >>> ContainerView >>> >>> ViewGadgetLayoutAbstract >>> ScrollerGadgetLayout >>> NullViewGadgetLayout >>> FixedStretchFixedGadgetLayout >>> ProportionalGadgetLayout >>> PreferredExtentsGadgetLayout >>> GridGadgetRowsLayout >>> VerticalListLayout >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 9, 2010

Re: [Pharo-project] Early days of an MVP framework

by Gary Chambers

This even (to get buttons on right with correct tab key navigation ordering... (UITheme builder newColumn: { UITheme builder newTabGroup: { 'First page' -> (UITheme builder newPanel fillStyle: Color red; hResizing: #spaceFill; vResizing: #spaceFill). 'Second page' -> (UITheme builder newPanel fillStyle: Color green; hResizing: #spaceFill; vResizing: #spaceFill)}. (UITheme builder newRow: { UITheme builder newOKButton. UITheme builder newCancelButton}) listCentering: #bottomRight}) extent: 200@300; openInWindow Regards, Gary ----- Original Message ----- From: "Gary Chambers" <gazzaguru2(a)btinternet.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, August 09, 2010 11:07 AM Subject: Re: [Pharo-project] Early days of an MVP framework > Any Morph can use a layoutPolicy. > Available are > none (position based) > Prorportional (frame/fractions/offsets) > Table (overly complex too) > Row (one of mine, quicker for simple rows) > Stack (mine, overlay morphs on top of each other) > > TEasilyThemed provides some methods like... > > newRow: {aMorph, anotherMorph} > newColumn: > > Something like this works... > > (UITheme builder > newColumn: { > UITheme builder newPanel > fillStyle: Color red; > hResizing: #spaceFill; > vResizing: #spaceFill. > UITheme builder newRow: { > UITheme builder newOKButton. > UITheme builder newCancelButton}}) > extent: 200@300; > openInHand > > (can use openInWindow also)... > > Rather busy today, hope this helps in the meantime... > > Regards, Gary > > ----- Original Message ----- > From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> > To: <pharo-project(a)lists.gforge.inria.fr> > Sent: Sunday, August 08, 2010 11:46 PM > Subject: [Pharo-project] Early days of an MVP framework > > >> Gary, >> >> I was on an unstoppable roll (salvaged early on by Andreas' bitblt >> coaching), until I needed to repeat a "complex" GUI component and >> wanted/insisted on doing so with some reuse. Seaside gives us components >> on web pages; we need them for GUI code too. I tried turning my >> presenter-like structures into factories that would add morphs to a >> single shell, but it fell apart when it came time to set the framing >> values. I was not particularly interested in fixing it, because if I >> could do that, I would simply build proper composite widgets using the >> fix. >> >> The problem appears to be in SystemWindow, which does some incredibly >> complicated things, all of which (correct me if I am wrong) would be >> unnecessary if only there were a good set of layout managers. I can get >> very simple-minded about things, but it would make a whole lot more sense >> to me to create rows and columns of widgets, adding splitters between >> them until the whole things behaves as intended, rather than writing code >> (present only in a top-level shell) that tries to split things up into >> rows using its own judgment. Not good. I realize you did not create the >> situation, and have done wonders to make it work far better than when you >> found it. >> >> Some time ago, I built an emulated widget framework for Dolphin, which I >> needed because the combination of Dolphin's view resources and Windows >> itself was too slow for what I was trying to do. That project included a >> somewhat strange set of layout classes, but the basics are present, and >> it is not Object Arts' IP. I ported the classes to Pharo and did some >> work on stub View and Presenter classes that I had added to Pharo largely >> to passify my code that I was importing from Dolphin. The layouts think >> in terms of emulated widgets, and I see no reason to change their minds: >> I might want to replicate the framework. However, dynamic typing and a >> couple of extra methods allow them to work with just about anything. My >> goals are modest. Being able to compose rows and columns would do a lot >> for me. Add splitters and the ability to fix the size of some items, and >> I could almost anything I would need. >> >> View class>>example >> | row column dot square out shell | >> dot := ( Form dotOfSize:100 ) asFormOfDepth:32. >> square := ( Form squareOfSize:100 ) asFormOfDepth:32. >> out := Array writeStream. >> >> row := ContainerView row. >> 2 timesRepeat:[ >> column := row addSubview:ContainerView column. >> 2 timesRepeat:[ >> out nextPut:( >> column addSubview:ImageView new >> ). >> ]. >> ]. >> >> out contents with:{ dot copy. square copy. square copy. dot copy. } >> do:[ :view :form | >> view morph image:form. >> ]. >> >> row rectangle:( 0@0 extent:400@400 ). >> row layout. >> >> shell := StandardWindow labelled:'Hello MVP'. >> ^shell addMorph:row morph frame:( 0@0 extent:1@1 ); yourself. >> >> >> The above code produces an array of dots and squares, as intended. One >> quirk is that the grid does not resize as the shell resizes, a >> consequence of my not having hooked it up to resize events. I might get >> some interesting meltdowns once I begin to do that =:0 I used your >> PanelMorph as the "view" associated with ContainerView. What, >> ContainView isn't a view??? No. The code is biased toward Morphic, but >> hopefully the same code should extend to wx, GTK, etc. Dolphin's views >> have a handle instance variable to control the external resource; these >> views have an instance variable pointing to their morph. Handling of sub >> views works pretty much as in Dolphin: any view/morph can have children, >> but adding them is "legal" only for composites. >> >> Most systems I have seen treat coordinates relative to the parent/owner, >> but not Morphic. I remember seeing plans to make the change, but nothing >> after that. The view instances provide a natural place to fix things, so >> I took the plunge. If we switch to some other graphical realization, we >> can simply remove the the transformation. >> >> Are the existing splitters as strange as SystemWindow? By that I mean, >> would it be reasonable to add them between other morphs and look for >> events from them, or will they have to be replaced? I will eventually >> need splitters, but I could initially live without them if I can get >> reliable composition where I need it. >> >> There are very few view classes at present. MorphView can wrap almost >> anything, so it might be better to create a rich set of presenters >> instead. Dolphin's view resources are going to be interesting to >> replace. There are some complexities that I suspect are in deference to >> Windows, and some that might be avoidable. For our purposes, it might be >> enough to use SIXX to serialize a bunch of message sends and gzip the >> results to save memory. Another option might be to rely on class >> methods; having full closures won't hurt; they might allow sufficient >> hooking that resources in the Dolphin sense won't even be necessary. The >> desire for them quickly arises because views get realized in places know >> nothing about how the views should be configured; at least I think that >> is what happened to me after just a couple of hours. I am far less >> interested in having a graphical view editor than I am in being able to >> write **GOOD** code that assembles things as I want. If the result >> happens to allow a graphical editor too, so much the better. >> >> Any interest? >> >> Bill >> >> >> ----------------------------- >> >> View >> MorphViev >> ImageView >> ContainerView >> >> ViewGadgetLayoutAbstract >> ScrollerGadgetLayout >> NullViewGadgetLayout >> FixedStretchFixedGadgetLayout >> ProportionalGadgetLayout >> PreferredExtentsGadgetLayout >> GridGadgetRowsLayout >> VerticalListLayout >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 9, 2010

Re: [Pharo-project] Early days of an MVP framework

by Gary Chambers

Another example (adoptPaneColor is required if not opened in a window it seems or the tab label 'button' background is not recomputed properly to fit the text). (UITheme builder newColumn: { UITheme builder newTabGroup: { 'First page' -> (UITheme builder newPanel fillStyle: Color red; hResizing: #spaceFill; vResizing: #spaceFill). 'Second page' -> (UITheme builder newPanel fillStyle: Color green; hResizing: #spaceFill; vResizing: #spaceFill)}. (UITheme builder newRow: { UITheme builder newCancelButton. UITheme builder newOKButton}) listDirection: #rightToLeft}) extent: 200@300; openInHand; adoptPaneColor Regards, Gary ----- Original Message ----- From: "Gary Chambers" <gazzaguru2(a)btinternet.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, August 09, 2010 11:07 AM Subject: Re: [Pharo-project] Early days of an MVP framework > Any Morph can use a layoutPolicy. > Available are > none (position based) > Prorportional (frame/fractions/offsets) > Table (overly complex too) > Row (one of mine, quicker for simple rows) > Stack (mine, overlay morphs on top of each other) > > TEasilyThemed provides some methods like... > > newRow: {aMorph, anotherMorph} > newColumn: > > Something like this works... > > (UITheme builder > newColumn: { > UITheme builder newPanel > fillStyle: Color red; > hResizing: #spaceFill; > vResizing: #spaceFill. > UITheme builder newRow: { > UITheme builder newOKButton. > UITheme builder newCancelButton}}) > extent: 200@300; > openInHand > > (can use openInWindow also)... > > Rather busy today, hope this helps in the meantime... > > Regards, Gary > > ----- Original Message ----- > From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> > To: <pharo-project(a)lists.gforge.inria.fr> > Sent: Sunday, August 08, 2010 11:46 PM > Subject: [Pharo-project] Early days of an MVP framework > > >> Gary, >> >> I was on an unstoppable roll (salvaged early on by Andreas' bitblt >> coaching), until I needed to repeat a "complex" GUI component and >> wanted/insisted on doing so with some reuse. Seaside gives us components >> on web pages; we need them for GUI code too. I tried turning my >> presenter-like structures into factories that would add morphs to a >> single shell, but it fell apart when it came time to set the framing >> values. I was not particularly interested in fixing it, because if I >> could do that, I would simply build proper composite widgets using the >> fix. >> >> The problem appears to be in SystemWindow, which does some incredibly >> complicated things, all of which (correct me if I am wrong) would be >> unnecessary if only there were a good set of layout managers. I can get >> very simple-minded about things, but it would make a whole lot more sense >> to me to create rows and columns of widgets, adding splitters between >> them until the whole things behaves as intended, rather than writing code >> (present only in a top-level shell) that tries to split things up into >> rows using its own judgment. Not good. I realize you did not create the >> situation, and have done wonders to make it work far better than when you >> found it. >> >> Some time ago, I built an emulated widget framework for Dolphin, which I >> needed because the combination of Dolphin's view resources and Windows >> itself was too slow for what I was trying to do. That project included a >> somewhat strange set of layout classes, but the basics are present, and >> it is not Object Arts' IP. I ported the classes to Pharo and did some >> work on stub View and Presenter classes that I had added to Pharo largely >> to passify my code that I was importing from Dolphin. The layouts think >> in terms of emulated widgets, and I see no reason to change their minds: >> I might want to replicate the framework. However, dynamic typing and a >> couple of extra methods allow them to work with just about anything. My >> goals are modest. Being able to compose rows and columns would do a lot >> for me. Add splitters and the ability to fix the size of some items, and >> I could almost anything I would need. >> >> View class>>example >> | row column dot square out shell | >> dot := ( Form dotOfSize:100 ) asFormOfDepth:32. >> square := ( Form squareOfSize:100 ) asFormOfDepth:32. >> out := Array writeStream. >> >> row := ContainerView row. >> 2 timesRepeat:[ >> column := row addSubview:ContainerView column. >> 2 timesRepeat:[ >> out nextPut:( >> column addSubview:ImageView new >> ). >> ]. >> ]. >> >> out contents with:{ dot copy. square copy. square copy. dot copy. } >> do:[ :view :form | >> view morph image:form. >> ]. >> >> row rectangle:( 0@0 extent:400@400 ). >> row layout. >> >> shell := StandardWindow labelled:'Hello MVP'. >> ^shell addMorph:row morph frame:( 0@0 extent:1@1 ); yourself. >> >> >> The above code produces an array of dots and squares, as intended. One >> quirk is that the grid does not resize as the shell resizes, a >> consequence of my not having hooked it up to resize events. I might get >> some interesting meltdowns once I begin to do that =:0 I used your >> PanelMorph as the "view" associated with ContainerView. What, >> ContainView isn't a view??? No. The code is biased toward Morphic, but >> hopefully the same code should extend to wx, GTK, etc. Dolphin's views >> have a handle instance variable to control the external resource; these >> views have an instance variable pointing to their morph. Handling of sub >> views works pretty much as in Dolphin: any view/morph can have children, >> but adding them is "legal" only for composites. >> >> Most systems I have seen treat coordinates relative to the parent/owner, >> but not Morphic. I remember seeing plans to make the change, but nothing >> after that. The view instances provide a natural place to fix things, so >> I took the plunge. If we switch to some other graphical realization, we >> can simply remove the the transformation. >> >> Are the existing splitters as strange as SystemWindow? By that I mean, >> would it be reasonable to add them between other morphs and look for >> events from them, or will they have to be replaced? I will eventually >> need splitters, but I could initially live without them if I can get >> reliable composition where I need it. >> >> There are very few view classes at present. MorphView can wrap almost >> anything, so it might be better to create a rich set of presenters >> instead. Dolphin's view resources are going to be interesting to >> replace. There are some complexities that I suspect are in deference to >> Windows, and some that might be avoidable. For our purposes, it might be >> enough to use SIXX to serialize a bunch of message sends and gzip the >> results to save memory. Another option might be to rely on class >> methods; having full closures won't hurt; they might allow sufficient >> hooking that resources in the Dolphin sense won't even be necessary. The >> desire for them quickly arises because views get realized in places know >> nothing about how the views should be configured; at least I think that >> is what happened to me after just a couple of hours. I am far less >> interested in having a graphical view editor than I am in being able to >> write **GOOD** code that assembles things as I want. If the result >> happens to allow a graphical editor too, so much the better. >> >> Any interest? >> >> Bill >> >> >> ----------------------------- >> >> View >> MorphViev >> ImageView >> ContainerView >> >> ViewGadgetLayoutAbstract >> ScrollerGadgetLayout >> NullViewGadgetLayout >> FixedStretchFixedGadgetLayout >> ProportionalGadgetLayout >> PreferredExtentsGadgetLayout >> GridGadgetRowsLayout >> VerticalListLayout >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 9, 2010

Re: [Pharo-project] Early days of an MVP framework

by Gary Chambers

Any Morph can use a layoutPolicy. Available are none (position based) Prorportional (frame/fractions/offsets) Table (overly complex too) Row (one of mine, quicker for simple rows) Stack (mine, overlay morphs on top of each other) TEasilyThemed provides some methods like... newRow: {aMorph, anotherMorph} newColumn: Something like this works... (UITheme builder newColumn: { UITheme builder newPanel fillStyle: Color red; hResizing: #spaceFill; vResizing: #spaceFill. UITheme builder newRow: { UITheme builder newOKButton. UITheme builder newCancelButton}}) extent: 200@300; openInHand (can use openInWindow also)... Rather busy today, hope this helps in the meantime... Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <pharo-project(a)lists.gforge.inria.fr> Sent: Sunday, August 08, 2010 11:46 PM Subject: [Pharo-project] Early days of an MVP framework > Gary, > > I was on an unstoppable roll (salvaged early on by Andreas' bitblt > coaching), until I needed to repeat a "complex" GUI component and > wanted/insisted on doing so with some reuse. Seaside gives us components > on web pages; we need them for GUI code too. I tried turning my > presenter-like structures into factories that would add morphs to a single > shell, but it fell apart when it came time to set the framing values. I > was not particularly interested in fixing it, because if I could do that, > I would simply build proper composite widgets using the fix. > > The problem appears to be in SystemWindow, which does some incredibly > complicated things, all of which (correct me if I am wrong) would be > unnecessary if only there were a good set of layout managers. I can get > very simple-minded about things, but it would make a whole lot more sense > to me to create rows and columns of widgets, adding splitters between them > until the whole things behaves as intended, rather than writing code > (present only in a top-level shell) that tries to split things up into > rows using its own judgment. Not good. I realize you did not create the > situation, and have done wonders to make it work far better than when you > found it. > > Some time ago, I built an emulated widget framework for Dolphin, which I > needed because the combination of Dolphin's view resources and Windows > itself was too slow for what I was trying to do. That project included a > somewhat strange set of layout classes, but the basics are present, and it > is not Object Arts' IP. I ported the classes to Pharo and did some work > on stub View and Presenter classes that I had added to Pharo largely to > passify my code that I was importing from Dolphin. The layouts think in > terms of emulated widgets, and I see no reason to change their minds: I > might want to replicate the framework. However, dynamic typing and a > couple of extra methods allow them to work with just about anything. My > goals are modest. Being able to compose rows and columns would do a lot > for me. Add splitters and the ability to fix the size of some items, and > I could almost anything I would need. > > View class>>example > | row column dot square out shell | > dot := ( Form dotOfSize:100 ) asFormOfDepth:32. > square := ( Form squareOfSize:100 ) asFormOfDepth:32. > out := Array writeStream. > > row := ContainerView row. > 2 timesRepeat:[ > column := row addSubview:ContainerView column. > 2 timesRepeat:[ > out nextPut:( > column addSubview:ImageView new > ). > ]. > ]. > > out contents with:{ dot copy. square copy. square copy. dot copy. } do:[ > :view :form | > view morph image:form. > ]. > > row rectangle:( 0@0 extent:400@400 ). > row layout. > > shell := StandardWindow labelled:'Hello MVP'. > ^shell addMorph:row morph frame:( 0@0 extent:1@1 ); yourself. > > > The above code produces an array of dots and squares, as intended. One > quirk is that the grid does not resize as the shell resizes, a consequence > of my not having hooked it up to resize events. I might get some > interesting meltdowns once I begin to do that =:0 I used your PanelMorph > as the "view" associated with ContainerView. What, ContainView isn't a > view??? No. The code is biased toward Morphic, but hopefully the same > code should extend to wx, GTK, etc. Dolphin's views have a handle > instance variable to control the external resource; these views have an > instance variable pointing to their morph. Handling of sub views works > pretty much as in Dolphin: any view/morph can have children, but adding > them is "legal" only for composites. > > Most systems I have seen treat coordinates relative to the parent/owner, > but not Morphic. I remember seeing plans to make the change, but nothing > after that. The view instances provide a natural place to fix things, so > I took the plunge. If we switch to some other graphical realization, we > can simply remove the the transformation. > > Are the existing splitters as strange as SystemWindow? By that I mean, > would it be reasonable to add them between other morphs and look for > events from them, or will they have to be replaced? I will eventually > need splitters, but I could initially live without them if I can get > reliable composition where I need it. > > There are very few view classes at present. MorphView can wrap almost > anything, so it might be better to create a rich set of presenters > instead. Dolphin's view resources are going to be interesting to replace. > There are some complexities that I suspect are in deference to Windows, > and some that might be avoidable. For our purposes, it might be enough to > use SIXX to serialize a bunch of message sends and gzip the results to > save memory. Another option might be to rely on class methods; having > full closures won't hurt; they might allow sufficient hooking that > resources in the Dolphin sense won't even be necessary. The desire for > them quickly arises because views get realized in places know nothing > about how the views should be configured; at least I think that is what > happened to me after just a couple of hours. I am far less interested in > having a graphical view editor than I am in being able to write **GOOD** > code that assembles things as I want. If the result happens to allow a > graphical editor too, so much the better. > > Any interest? > > Bill > > > ----------------------------- > > View > MorphViev > ImageView > ContainerView > > ViewGadgetLayoutAbstract > ScrollerGadgetLayout > NullViewGadgetLayout > FixedStretchFixedGadgetLayout > ProportionalGadgetLayout > PreferredExtentsGadgetLayout > GridGadgetRowsLayout > VerticalListLayout > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 9, 2010

Re: [Pharo-project] Keyboard Shortcuts: Keymapping now loads in Pharo core 1.2

by Tim Mackinnon

On 2010-08-08 23:52:45 +0100, Sean P. DeNigris said: > To get the ball moving, I ported one of the keyboard shortcut packages, > Keymapping, to Pharo. Maybe if we start playing with it, we'll see what > works and what doesn't, and use it to create something great. > > The Metacello configuration is at http://www.squeaksource.com/Keymapping > > Sean That's awesome - I want to have a look before ESUG (I recall you're going - so maybe we can get some interest on this), as I'm quite keen to get some better shortcuts for the more used refactorings (like extract method, extract temp, inline temp...) - so then the experience becomes more like using eclipse. I'm also keen to get some additional keystrokes for things like - delete line, indent line/selection etc. - so hopefully this can support that as well. Tim

Aug. 9, 2010

Re: [Pharo-project] TextMorph without being able to be edited?

by StÃ©phane Ducasse

Yes! On Aug 9, 2010, at 11:07 AM, Fernando olivero wrote: > Try NewTextMorph! > > t := NewTextMorph new. > t > borderWidth: 1; > borderColor: Color red; > color: Color white; > padding: 5 ; > readOnly: true; > autoFit: true ; > text: 'I present my text as read only ' asText ; > openInWorld. > > Fernando > On Aug 7, 2010, at 12:26 PM, Carla F. Griggio wrote: > >> Hi again, everyone! >> >> I think this might be really really silly, but I couldn't find a way to show a TextMorph without the ability to edit it's text. >> If I use a StringMorph to show a paragraph, it looks horrible, but if I use a TextMorph and click on it, a blue border appears and I'm able to edit the text, I don't want that to happen. >> >> Is there another morph for showing text that only shows text and nothing else? Or a property of TextMorph that I'm missing? >> >> >> Thanks! >> Carla >> <ATT00001..txt> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 9, 2010