January 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Spotlight Demo

by Sebastian Sastre

On Jan 6, 2014, at 3:40 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > However, I favor "descriptive" theming (like CSS) rather than > "programmed" theming (like the actual). this raises an interesting point and hard questions: if themes are programmed instead of easily described... Aren't they way more likely to end up being done as a second-class-citizen kind of task by a programmer instead of a first-class work of a focused designer? Do we have designer's feedback before we implement our UIs? If we do, do we listen? are we willing to?

Jan. 6, 2014

Re: [Pharo-dev] XMLParser Problem with SVG

by HernÃ¡n Morales Durand

I vote for don't fetching DTD if you don't need to. See what W3C thinks about DTD fetches: excessive traffic = DDoS attacks http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic/ Cheers, Hernan 2014/1/6 Igor Stasenko <siguctua(a)gmail.com> > Hmm, my only question is about default behavior. > Before it was not using/resolving any DTD links, > and now it is... which means old code which was worked perfectly before, > now will stop to function. > So, maybe its worth to change the default behavior to be backwards > compatible? > Also, i'm not sure if it is good idea to go over a wire for an arbitrary > content you can give to XMLDOMParser, imo this should be disabled by > default, and instructed by user explicitly instead. > > Don't take me wrong: i really like that now we can handle DTD stuff > properly, i'm only doubting current default way of handling it. > > > > On 6 January 2014 12:58, monty <monty.os(a)engineer.com> wrote: > >> You can use the DTDCachingEntityResolver to cache responses: >> >> resolver := DTDCachingEntityResolver new. >> >> then: >> >> (XMLDOMParser onFileNamed: 'lion.svg') >> externalEntityResolver: resolver; >> parseDocument. >> >> or you could just disable validation and external entity resolution >> altogether: >> (XMLDOMParser onFileNamed: 'lion.svg') >> isValidating: false; >> resolvesExternalEntities: false; >> parseDocument. >> >> if you're parsing a string or stream (and you can always create your own >> file stream and give it that), you can do everything with just one message: >> >> XMLDOMParser >> parse: xmlStringOrStream >> usingNamespaces: true; >> validation: false; >> externalEntities: false. >> >> This is all in the documentation for SAXHandler. >> >> ----- Original Message ----- >> From: J.F. Rick >> Sent: 01/06/14 04:37 AM >> To: Pharo Development List >> Subject: Re: [Pharo-dev] XMLParser Problem with SVG >> Monty, thanks. You are right that the latest version of XMLParser fixes >> the parsing problem. I think you just need to upload an updated >> configuration to the MetaRepoForPharo30 to fix this. And, yes, I would like >> to know how to turn DTD parsing off or for it to cache the DTD as it takes >> several seconds to retrieve the DTD for SVG and that gets annoying. Cheers, >> Jeff On Mon, Jan 6, 2014 at 10:18 AM, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> On 06 Jan 2014, at 10:06, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> > >> > >> > >> > On 5 January 2014 15:19, J.F. Rick <self(a)je77.com> wrote: >> > I am trying to use SVG with Athens; however, the XMLParser for Pharo >> 3.0 cannot read normal SVG files that it used to. So, the demo of >> "ASVGMorph fromFile: 'lion.svg'" fails in the XMLParser (i.e., before >> ASVGMorph really does anything to it). It seems to download the DTD file >> from the Internet and then cannot properly parse it. Here is my setup: >> > >> > Up-to-date Pharo 3.0. Added XMLParser from the Configuration Browser. >> > Example file can be found here: >> http://www.thetangentbundle.net/w/images/f/ff/lion.svg >> > The following brings up an error: XMLDOMParser parseFileNamed: >> 'lion.svg' >> > >> > Hmm, why it tries to parse DTD file? It looks like something has >> changed in XMLDOMParser, because it wasn't before, and there is no support >> in SVG parser >> > for that. >> Yes, the parsing of DTDâd is new, Monthy added it recently. >> He says there is a way to turn it off. >> > >> > Cheers, >> > >> > Jeff >> > >> > -- >> > Jochen "Jeff" Rick, Ph.D. >> > http://www.je77.com/ >> > Skype ID: jochenrick >> > >> > >> > >> > -- >> > Best regards, >> > Igor Stasenko. >> >> -- >> Jochen "Jeff" Rick, Ph.D. >> http://www.je77.com/ >> Skype ID: jochenrick >> >> > > > -- > Best regards, > Igor Stasenko. >

Jan. 6, 2014

Athens SVG Import

by J.F. Rick

This message is mainly for Igor, who probably already curses every time he sees my name on the development list. But, perhaps others have had some experience with this as well. I'm still working on moving my touch applications to Athens. I am running into a major problem with icons. My applications tend to have quite a few icons in them. In the old BitBlt versions, I just used forms for the icons. That same approach fails with Athens as form rendering is time consuming. With just ten medium-sized forms open in my AthensWrapMorph, the system starts to crawl. My guess is that form rendering needs to be sped up before Athens can be widely adopted. Using the form as a paint, while flexible, seems pretty intense. Anyway, for most of my applications, switching over to vector-based graphics would be a better choice as it would allow for me to more easily scale to different screen sizes. So, I was excited to try the SVG import. Now that the XMLParser is working, I am running into some problems with the SVG import code. It seems that it doesn't support some of the features that an SVG export from Illustrator produces. I was wondering if I could get some help there. First, Illustrator tends to spit out SVGs that use #reflectedCubicBezier curves, which is not yet implemented. Second, I found a small bug in ASPathConverter>>readPoint The "self skipBlanks" has to be changed to "self skipBlanksAndComma" or multiple points cannot be read in sequence. Third, while ASPathConverter supports vLineTo: and hLineTo:, AthensCairoPathBuilder does not. I tried implementing these myself but they apparently don't work the way I thought they should. Here are two examples of the kind of SVG files I would like to read: button-swapShapes.svg<http://home.cc.gatech.edu/je77/uploads/1/button-swapShapes.svg> - This one fails because of vLineTo: and hLineTo: button-erase.svg <http://home.cc.gatech.edu/je77/uploads/1/button-erase.svg> - This one fails because of reflectedCubicBezier curves. Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Jan. 6, 2014

Re: [Pharo-dev] Spotlight Demo

by Esteban A. Maringolo

Theming should be orthogonal to the widget, so subclassing isn't an option. But making it so isn't trivial either. However, instead of subclassing, each widget might have a theme, to which it could delegate it's rendering, or fallback to the default "theme" in case no custom theming has been defined. However, I favor "descriptive" theming (like CSS) rather than "programmed" theming (like the actual). Regards, Esteban A. Maringolo 2014/1/6 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Now in the car I was thinking > > > if each Widget acts as a factory and theme are subclasses. > - each widget should have/inherit a factory system (may be not good) > - to change a theme we will have to get instance of different widget subclasses (so it is not good). > > So I like the theme as strategy approach we should try on another widget. > > Stef > > >> Ok I read >> >> >> UITheme would act as a theme factory. >> and each widget delegate to the Themer associated to themselve and the current theme >> >> So subclasse of UITheme can propose different themer for the same widget. >> >> Now since the themer is a separate class (from the morph it means that you must have all the hooks to customise it). >> So why not. >> I was also thinking that a widget could be an âabstractâ class whose subclasses implement the themes. >> >> Then you would create a widget like that >> >> >> SpolightItemMorph forThemer: UITheme blue >> and it would create an instance of a subclas SpotligherBluerItemMorph. >> >> Did you try this design? >> >> Stef > >

Jan. 6, 2014

Re: [Pharo-dev] Spotlight Demo

by StÃ©phane Ducasse

Now in the car I was thinking if each Widget acts as a factory and theme are subclasses. - each widget should have/inherit a factory system (may be not good) - to change a theme we will have to get instance of different widget subclasses (so it is not good). So I like the theme as strategy approach we should try on another widget. Stef > Ok I read > > > UITheme would act as a theme factory. > and each widget delegate to the Themer associated to themselve and the current theme > > So subclasse of UITheme can propose different themer for the same widget. > > Now since the themer is a separate class (from the morph it means that you must have all the hooks to customise it). > So why not. > I was also thinking that a widget could be an âabstractâ class whose subclasses implement the themes. > > Then you would create a widget like that > > > SpolightItemMorph forThemer: UITheme blue > and it would create an instance of a subclas SpotligherBluerItemMorph. > > Did you try this design? > > Stef

Jan. 6, 2014

Re: [Pharo-dev] Spotlight Demo

by StÃ©phane Ducasse

Ok I read UITheme would act as a theme factory. and each widget delegate to the Themer associated to themselve and the current theme So subclasse of UITheme can propose different themer for the same widget. Now since the themer is a separate class (from the morph it means that you must have all the hooks to customise it). So why not. I was also thinking that a widget could be an âabstractâ class whose subclasses implement the themes. Then you would create a widget like that SpolightItemMorph forThemer: UITheme blue and it would create an instance of a subclas SpotligherBluerItemMorph. Did you try this design? Stef

Jan. 6, 2014

Re: [Pharo-dev] Spotlight Demo

by StÃ©phane Ducasse

On 06 Jan 2014, at 17:24, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I am not sure I understand. You tried to load Spotlight? And you got the error in Spotlight, or in any text? sorry I had to run to catch a kid I did: Gofer new smalltalkhubUser: 'girba' project: 'GPlay'; package: 'ConfigurationOfSpotter'; load. (Smalltalk globals at: #ConfigurationOfSpotter) loadStable then SpotlightCompletionExample open then type string and remove character by chracter and the last one crashes completely the system Stef > > Cheers, > Doru > > > > On Mon, Jan 6, 2014 at 4:47 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I tried in latest 3.0 the example and I get a DNU > > error: 'Some code is setting text attributes length not matching the string size']. > > when I remove character. > > stef > > On 06 Jan 2014, at 00:19, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi again, >> >> I added a first shot at theming. The idea is simple: >> - we have one method in UITheme called spotterThemer that simply returns a SpotterThemer, and >> - all Spotter/Spotlight specific rendering methods are in SpotterThemer >> >> I think this should be the design to follow for all morphs. I blogged about it in more details here: >> http://www.humane-assessment.com/blog/a-pharo-refactoring-story-adding-them… >> >> >> You can get the code from here: >> Gofer new >> smalltalkhubUser: 'girba' project: 'GPlay'; >> package: 'Spotlight'; >> disablePackageCache; >> load >> >> In summary, something like: >> >> SpotlightItemMorph>>onSelected >> self color: (Color r: 0.2627 g: 0.4588 b: 0.9333). >> >> becomes: >> >> SpotlightItemMorph>>onSelected >> self theme spotterThemer configureSelectedItemMorph: self >> >> And the default SpotterThemer says: >> >> SpotterThemer>>configureSelectedItemMorph: aMorph >> aMorph color: (Color r: 0.2627 g: 0.4588 b: 0.9333) >> >> >> What do you think? >> >> Cheers, >> Doru >> >> >> >> >> On Sun, Jan 5, 2014 at 9:26 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi Sean, >> >> I just tested it. It works just great. >> >> First, would it be Ok with you to move the project to a more public place (like http://www.smalltalkhub.com/#!/~PharoExtras) so that others can contribute easier? >> >> Second, I created a configuration with a development and stable version. You can find it here: >> Gofer new >> smalltalkhubUser: 'girba' project: 'GPlay'; >> package: 'ConfigurationOfSpotter'; >> load. >> (Smalltalk globals at: #ConfigurationOfSpotter) >> loadStable >> >> And in the MetaRepoForPharo30 so that you can load it from the Configuration Browser. Please note that I named the configuration Spotter, because there already exists a ConfigurationOfSpotlight for the widget of Esteban. Would it be Ok to change the name of the classes, too, to avoid confusion? >> >> Third, I think we should not mix the morph with the global shortcut. I understand this is convenient, but these should pretty much be different projects. Is that Ok with you? >> >> Fourth, I would like to theme this morph, too :). With this occasion, I would like to try a slightly different design for handling the theme code. I will follow up on this in another mail. >> >> Doru >> >> >> On Sat, Jan 4, 2014 at 5:42 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> I'm happy for now. As a general purpose completion option, I'd say we're >> officially at version 1.0. No obvious bugs, and provides the basic features >> I'd want. >> >> As for replacing the existing Spotlight, I've decided to eat my own dog food >> and use the new tool in my images: >> *** n.b., if you load the Spotlight package now, it will override the >> global Spotlight shortcut >> >> p.s. Steph, I added packages to the example for you ;) â¦ >> <http://forum.world.st/file/n4734153/Screen_Shot_2014-01-04_at_11.18.57_AM.p…> >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Spotlight-Demo-tp4733076p4734153.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Jan. 6, 2014

Re: [Pharo-dev] Can we override == in Pharo ?

by Igor Stasenko

On 6 January 2014 14:21, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 6 janv. 2014, at 13:30, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > > > You may need to do this if you are using proxies. > > The fact that #== is not sent is actually really useful for proxies. > Because if #== were intercepted by the proxy and forwarded to the target > then there is no straightforward way to make the distinction between two > proxies on the same object. > And if messing with identity breaks all weak maps used for caching proxies. > > right.. proxies are for obvious reasons quite closely related to identity problematics, and in this regard, changing the #== gives more troubles than it solves, because if you want to have a way to distinguish between proxy and non-proxy, identity is a way to do it, but if there's no way to do identity comparison, then you broke :) > > > > Alexandre > > > > > > On Jan 6, 2014, at 8:52 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > >> > >> > >> > >> On 6 January 2014 10:56, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > >> Hello, > >> > >> here I have a class > >> > >> A>>== > >> ^ true > >> > >> Now: > >> a := A new. > >> b := A new. > >> a == b "Answers false" > >> a perform: #== with: b "Answers true" > >> > >> Do I have to remove the usage of the byte code for #== in the compiler > to be able to override == ? > >> > >> > >> may i ask why you need to override it? > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > -- Best regards, Igor Stasenko.

Jan. 6, 2014

Re: [Pharo-dev] Browser focus issue?

by Sebastian Sastre

similar thing happens with cmd-f to find class after clicking in the packages list If you open a browser and first thing you do is press cmd-f it allows you to find a class? (here isn't reacting even after clicking on a package) On Jan 6, 2014, at 2:22 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > strange :) > > Ben > > On 06 Jan 2014, at 13:16, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >> yeah, with the same result >> >> sounds like the keyboard events aren't observed so it won't react (mouse is ok) >> >> >> >> >> >> On Jan 6, 2014, at 1:41 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> >>> did you try cmd+x, cmd+m >>> >>> Ben >>> >>> On 06 Jan 2014, at 08:39, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >>> >>>> Hi guys, >>>> >>>> I'm using the code browser and selecting methods and often I click select a method, lets say for refactoring, and press cmd-x and nothing happens. >>>> >>>> Sounds like a key events focus issue >>>> >>>> sebastian >>>> >>>> o/ >>>> >>>> >>>> Pharo #30668 >>>> >>>> >>> >> >

Jan. 6, 2014

Re: [Pharo-dev] XMLParser Problem with SVG

by Igor Stasenko

Hmm, my only question is about default behavior. Before it was not using/resolving any DTD links, and now it is... which means old code which was worked perfectly before, now will stop to function. So, maybe its worth to change the default behavior to be backwards compatible? Also, i'm not sure if it is good idea to go over a wire for an arbitrary content you can give to XMLDOMParser, imo this should be disabled by default, and instructed by user explicitly instead. Don't take me wrong: i really like that now we can handle DTD stuff properly, i'm only doubting current default way of handling it. On 6 January 2014 12:58, monty <monty.os(a)engineer.com> wrote: > You can use the DTDCachingEntityResolver to cache responses: > > resolver := DTDCachingEntityResolver new. > > then: > > (XMLDOMParser onFileNamed: 'lion.svg') > externalEntityResolver: resolver; > parseDocument. > > or you could just disable validation and external entity resolution > altogether: > (XMLDOMParser onFileNamed: 'lion.svg') > isValidating: false; > resolvesExternalEntities: false; > parseDocument. > > if you're parsing a string or stream (and you can always create your own > file stream and give it that), you can do everything with just one message: > > XMLDOMParser > parse: xmlStringOrStream > usingNamespaces: true; > validation: false; > externalEntities: false. > > This is all in the documentation for SAXHandler. > > ----- Original Message ----- > From: J.F. Rick > Sent: 01/06/14 04:37 AM > To: Pharo Development List > Subject: Re: [Pharo-dev] XMLParser Problem with SVG > Monty, thanks. You are right that the latest version of XMLParser fixes > the parsing problem. I think you just need to upload an updated > configuration to the MetaRepoForPharo30 to fix this. And, yes, I would like > to know how to turn DTD parsing off or for it to cache the DTD as it takes > several seconds to retrieve the DTD for SVG and that gets annoying. Cheers, > Jeff On Mon, Jan 6, 2014 at 10:18 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > On 06 Jan 2014, at 10:06, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > > > > > > On 5 January 2014 15:19, J.F. Rick <self(a)je77.com> wrote: > > I am trying to use SVG with Athens; however, the XMLParser for Pharo 3.0 > cannot read normal SVG files that it used to. So, the demo of "ASVGMorph > fromFile: 'lion.svg'" fails in the XMLParser (i.e., before ASVGMorph really > does anything to it). It seems to download the DTD file from the Internet > and then cannot properly parse it. Here is my setup: > > > > Up-to-date Pharo 3.0. Added XMLParser from the Configuration Browser. > > Example file can be found here: > http://www.thetangentbundle.net/w/images/f/ff/lion.svg > > The following brings up an error: XMLDOMParser parseFileNamed: 'lion.svg' > > > > Hmm, why it tries to parse DTD file? It looks like something has changed > in XMLDOMParser, because it wasn't before, and there is no support in SVG > parser > > for that. > Yes, the parsing of DTDâd is new, Monthy added it recently. > He says there is a way to turn it off. > > > > Cheers, > > > > Jeff > > > > -- > > Jochen "Jeff" Rick, Ph.D. > > http://www.je77.com/ > > Skype ID: jochenrick > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick > > -- Best regards, Igor Stasenko.

Jan. 6, 2014