February 2014 - Pharo-users

Re: [Pharo-users] Spec and an application menu

by Goubier Thierry

Le 18/02/2014 09:12, Hilaire Fernandes a Ã©crit : > > > Le 17/02/2014 20:22, kmo a Ã©crit : >> Yes - there's no problem with menus if you use Morphs. Here's an interface >> that uses a ToolDockingBarMorph to implement a menu. >> >> <http://forum.world.st/file/n4744441/PharoScreenshot.3.png> > > > It is already there as Morph: > > UITheme exampleWindowWithToolbars I knew it! Thanks Hilaire. Now I want to try something: populate the menu bar with all possible menu/shortcuts commands defined in my app (i.e. tree node contextual menu, code pane contextual menu, smart-suggestions type commands) to ensure discoverability, in as few lines as possible. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Feb. 18, 2014

Re: [Pharo-users] Spec and an application menu

by Hilaire Fernandes

Le 17/02/2014 21:44, kilon alios a Ã©crit : > > Whats stops you from using Morphic and Spec at the same time ? > Entropy control? -- Dr. Geo http://drgeo.eu

Feb. 18, 2014

Re: [Pharo-users] Spec and an application menu

by Hilaire Fernandes

Le 17/02/2014 20:22, kmo a Ã©crit : > Yes - there's no problem with menus if you use Morphs. Here's an interface > that uses a ToolDockingBarMorph to implement a menu. > > <http://forum.world.st/file/n4744441/PharoScreenshot.3.png> It is already there as Morph: UITheme exampleWindowWithToolbars > > The question is - why can't you do this in Spec? I guess Spec is not mature enough. Frankly, as long as, it is not "feature complete", will people developing application use it? Spec may deserve a planified effort to go through A to Z to make it feature complete to attract developer. -- Dr. Geo http://drgeo.eu

Feb. 18, 2014

Re: [Pharo-users] TextModel and TextInputFieldModel font-size bug?

by HernÃ¡n Morales Durand

I confirm this issue using a vanilla Pharo 3. PluggableTextFieldMorph new openInWindow If you comment last line here it works PluggableTextFieldMorph>>initialize textMorphClass := TextMorphForFieldView. super initialize. " self beDecrypted" which makes me think. Why #beDecrypted? Are text morphs encrypted by default? If not we are wasting cycles there. To me it sounds like you should decrypt when something was encrypted, not just in case. However that does not resolve the issue with TextInputFieldModel. 2014-02-16 10:55 GMT-03:00 kmo <voxkmp(a)gmail.com>: > When I create an interface in Spec with TextModel or TextInputFieldModel, > the > font-size is tiny. Same behaviour in both Windows and Linux. Is this a bug > or have I missed something important? > > <http://forum.world.st/file/n4744094/SmallFont.png> > > > > > > -- > View this message in context: > http://forum.world.st/TextModel-and-TextInputFieldModel-font-size-bug-tp474… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Feb. 18, 2014

Re: [Pharo-users] Writing test for the String class

by Daniela Meneses

Thanks for your help, this was exactly what I needed to keep going. Ohh yeap, I'm looking forward to integrate the test I've been working on to Pharo when I finish.

Feb. 17, 2014

Re: [Pharo-users] Writing test for the String class

by ClÃ©ment Bera

Hello, I believe #correctAgainstDictionary: / correctAgainst: / correctAgainstEnumerator: are API for autocorrection in compiler erros / compiler warnings. For ex, when I type '1 hal' in a workspace I get this window: [image: Images intÃ©grÃ©es 1] and here all the selector proposed (hasPreambleOfRemoval, haltIfNil, ...) are found in a correctAgainst: method. Here the method called was probably something like 'hal' correctAgainst: all the possible selector. If you are in a method editor for a specific class and you write the name of a variable that does not exist, this window will propose you to either create a new variable or choose in a list of existing variable, in this case you would call something like 'incorrectlyWrittenVaName' correctAgainst: allPossibleVariableNameInThisContext. Btw correctAgainst: calls correctAgainst:continuedFrom: lineNumberCorrespondingToIndex: is also for compiler warnings. Basically the compiler detects at which index the compiler warning was triggered, the index being the index of the character when you see a string as a collection of characters that triggered the error. this method returns the line where the error was triggered. It is used on the jenkins console to display 'error at line 10 in method Class>>xxx'. expandMacros I am not sure but it seems that it is used by the refactoring browser to encode some data in a string (for ex it seems that <N means chariot return (cr) while refactoring. For tabDelimitedFieldsDo: you have this example: 'fred charlie elmo 2' tabDelimitedFieldsDo: [:aField | Transcript cr; show: aField] So basically it executes the block for each substring, the substring being separated by tabs. It would be the same if you split the string on each tab, then you get a collection, and iterate over it with a do: and the block as argument. I guess this was a way to encode several strings in one string back in the old time but right now it is not used any more. And well #indexOfWideCharacterFrom: start to: end ... The comment is quite explicit. "Return the index of the first wide character following anIndex" In a String you can have a regular character (there are 256, evaluate 'Character allCharacters' in a workspace). This code detects the first wide character after the index, the index being the character at a specific position when you consider the string as a collection of characters. This is used for Fonts mostly. hope this could help ! Please if you succeed in implementing your tests don't forget to contribute them back to the community we will be glad to integrate them in the Pharo 3/Pharo 4 release. If you don't know how to contribute to pharo just ask. 2014-02-17 21:04 GMT+01:00 Daniela Meneses <daniela11290(a)gmail.com>: > Hi guys: > > I'm working on adding new test for the String class to improve the test > coverage. > Rigth now, the string class has 75,42% of coverage. I found out thanks to > Hapao. > > Well, these ones are methods that I don't understand. what are they used > for? how can I use them? > > > - correctAgainst: continuedFrom: > - correctAgainstDictionary: continuedFrom: > - lineNumberCorrespondingToIndex: > - correctAgainstEnumerator: continuedFrom: > - tabDelimitedFieldsDo: > - expandMacrosWithArguments: > - indexOfWideCharacterFrom: to: > > Please, could you help me to understand them, in order to do write some > test cases? > > > -- > Cheers, > Dani >

Feb. 17, 2014

Re: [Pharo-users] Spec and an application menu

by Sergi Reyner

2014-02-17 20:44 GMT+00:00 kilon alios <kilon.alios(a)gmail.com>: > > " If you constantly have to fall back on Morphs > then you might as well build the whole thing with Morphs." > > Whats stops you from using Morphic and Spec at the same time ? > > It is even possible to use Morphic + Spec + Athens + NBOpenGL + Mars + > .... > I'd say that nothing, but I guess the point is that simplicity and homogeneity are good and desirable. Cheers, Sergi

Feb. 17, 2014

Re: [Pharo-users] Spec and an application menu

by kilon alios

" If you constantly have to fall back on Morphs then you might as well build the whole thing with Morphs." Whats stops you from using Morphic and Spec at the same time ? It is even possible to use Morphic + Spec + Athens + NBOpenGL + Mars + .... personally I am making my own GUI API using Athens and Morphic. Athens for the actual drawing, Morphic for managing the widgets and the events. I could throw some Spec in it as well if I figure out how it works and see that it fits my way of thinking. From what I have read on Spec recent documentation it has an API for making extensions to it so adding new Morphs to it and Widgets is already doable. For me the main problem is that 90% of Pharo methods are not documented. I dont have a problem fighting with a messy library like Morphic , but taking a look at all these methods with no comments and no documentation just viewing the source is a huge waste of time and effort. I found out that its far easier to implement my own GUI API with Athens which at least it comes with a lengthy tutorial and some basic knowledge of Morphic. Its sad to reject a library just because it does not offer much documentation but I have no choice. So I have to disagree , documenting Morphic is far more important than cleaning it up. Because a method you know how to use but is difficult to use is far more useful than a method that is easy to use but you dont know how to use it.

Feb. 17, 2014

Re: [Pharo-users] Detecting open debuggers

by Andrei Chis

MorphicWindowAdapter allInstances select: [:w | (w model isKindOf: WindowModel) and: [ w model model isKindOf: SpecDebugger ] ] Based on "SpecDebugger class>>closeAllDebuggers". Cheers, Andrei On Mon, Feb 17, 2014 at 9:16 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > How to detect debugger windows? In pharo 2.0 I had this > > SystemWindow allSubInstances select: [:each| each model isKindOf: Debugger > ] > > What would be the 3.0 equivalent? > > thanks, > > Norbert > > >

Feb. 17, 2014

Detecting open debuggers

by Norbert Hartl

How to detect debugger windows? In pharo 2.0 I had this SystemWindow allSubInstances select: [:each| each model isKindOf: Debugger ] What would be the 3.0 equivalent? thanks, Norbert

Feb. 17, 2014