August 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Loading platform-specific code

by Sean P. DeNigris

In working on ExternalWebBrowser, I got thinking about loading platform-specific (i.e. Mac/Windows) code. ExternalWebBrowser does a check in a class>>initialization, and only installs a library that is required for operation on Macs, if the image is running on a Mac. Something about this feels wrong. I want to be able to put my image and a VM on a USB key and bring it to a client, who may be running on Windows (gasp!), and run the image. It's easy enough to bring or download a VM, but ExternalWebBrowser is now locked in "Mac-mode." In a service with equivalent Windows/Unix-specific requirements, it might be difficult (or impossible) to get it to work. It seems to me better to either: * install all such requirements right off the bat (for one thing - you probably have an internet connection to download them) * or, put a lazy initialization for it, so the first time the functionality is used, the packages are installed. I guess this would depend on there being a single access point to all the platform code. What do you all think? Thanks. Sean -- View this message in context: http://forum.world.st/Loading-platform-specific-code-tp2318610p2318610.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 9, 2010

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

by Alexandre Bergel

> the problem is not large strings but strings that contain characters with asciiValue > 255. The strings then become WideStrings and that is the problem. Jaayer removed the problematic method and after that (thanks again) I could read the monticello package again. And btw. I ported the newest source to gemstone already. Ok Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 9, 2010

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

by Sean P. DeNigris

StÃ©phane Ducasse wrote: > > 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 :) > That was my experience, which is why I put keymapping forward. Although, I thought the ability of KeyBinder to use arbitrary blocks as "shortcuts" was interesting. And, I *love* VI bindings, so SVI is cool for people like me to install and use, just maybe not suitable for a system package. 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.

Aug. 9, 2010

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

by Norbert Hartl

On 09.08.2010, at 15:00, Alexandre Bergel wrote: >> 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. > Alexandre, the problem is not large strings but strings that contain characters with asciiValue > 255. The strings then become WideStrings and that is the problem. Jaayer removed the problematic method and after that (thanks again) I could read the monticello package again. And btw. I ported the newest source to gemstone already. Norbert

Aug. 9, 2010

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