- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN] Alternative view of a system browser

by Camillo Bruni

We will have almost exactly that browser, very soon in Pharo :) I built an internal FileSystem which eventually will be used for versioning. Using the standard FileBrowser from Pharo on the internal FS delivers a very similar experience (albeit less code focused) as your example :) On 2012-07-21, at 08:55, Fernando Olivero wrote: > Hi, nice work. Looking forward to play with it. > Is it similar to the Newspeak browser? Where methods expand in place. > > Fernando > > > On Wed, Jul 18, 2012 at 7:36 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> I do not have a connection to look at it. >> But I LOVE the idea. I love the idea that we can prototype fast new tools and rethink how processesâ¦. >> Spec is one way to enable that. For example I love the GlamourInspector and it would be great to rewrite it with Spec. >> Thanks a lot. >> Stef >> >> On Jul 17, 2012, at 3:12 PM, Goubier Thierry wrote: >> >>> I believe that the traditional SystemBrowser of Smalltalk of old has been made unusable by the amount of code (and structure) you find in today's Smalltalk images. >>> >>> So this is to show you an alternative, a different way to browse through packages / classes and methods and code. This is Spec-based. >>> >>> https://picasaweb.google.com/lh/photo/ic_fRnBXXdyqbiJ5NRP9YtMTjNZETYmyPJy0l… >>> >>> What is missing / targeted ? >>> * Drag and drop reorganisation of the tree as preferred / or as package / category reuse. >>> * A good search facility in the tree. It is already keyboard navigation friendly (since the tree view is). >>> * Most / All menu methods of a complete System Browser. I'm planning on reusing the OmniBrowser command structure as much as possible (to make it faster). >>> * Funny ideas on how to use the tree structure : group / selection display, queries, metrics ... >>> ** There is probably a lot more to be done here, but it would probably require Mondrian or other graph visualisation tools. >>> >>> Expect the code sometime by the end of the week, in a Pharo 2.0 / Pharo 1.4 version. >>> >>> 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 >>> >>> >> >> >

July 22, 2012

Re: [Pharo-project] athens for strikefonts

by Tudor Girba

For the time being, StrikeFonts are the default fonts in Pharo. Given that it is the default it is used in practice all the time, and thus if we want Athens to be adopted easily we need support for the default case. The other solution is to change the default fonts, but this implies that we need to rethink how we distribute it, too, and I guess this will take a while. Cheers, Doru On 22 Jul 2012, at 16:40, Alexandre Bergel wrote: > Hi Doru, > > I am missing why StrikeFonts is so important for Moose. Is it the font used in all other the system? > > Cheers, > Alexandre > > > On Jul 22, 2012, at 5:00 AM, Tudor Girba wrote: > >> Hi Igor, >> >> First of all, how was your holidays? :) >> >> A while ago, you said that supporting StrikeFonts would not be that difficult. For me it would be important to have this support in order to have a smooth transition to Athens even without Cairo. >> >> So, what would it take for this support to happen? >> >> Cheers, >> Doru >> >> >> On 11 Jul 2012, at 09:04, Tudor Girba wrote: >> >>> Aha. Ok. I will wait. >>> >>> Doru >>> >>> >>> On Wed, Jul 11, 2012 at 8:43 AM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> Good idea if possible. >>>> Igor like me is on vacation until 19 of july. >>>> >>>> On Jul 10, 2012, at 7:07 AM, Tudor Girba wrote: >>>> >>>>> Hi Igor, >>>>> >>>>> I just wanted to ask: is the little fix of having Athens work with StrikeFont still on the roadmap :)? >>>>> >>>>> As I mentioned before, this would make the adoption easier, because we can switch the Athens even with the regular CogVMs. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "It's not what we do that matters most, it's how we do it." >>>>> >>>>> >>>> >>>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >> >> -- >> www.tudorgirba.com >> >> "In a world where everything is moving ever faster, >> one might have better chances to win by moving slower." >> >> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- www.tudorgirba.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

July 22, 2012

Re: [Pharo-project] athens for strikefonts

by Alexandre Bergel

Hi Doru, I am missing why StrikeFonts is so important for Moose. Is it the font used in all other the system? Cheers, Alexandre On Jul 22, 2012, at 5:00 AM, Tudor Girba wrote: > Hi Igor, > > First of all, how was your holidays? :) > > A while ago, you said that supporting StrikeFonts would not be that difficult. For me it would be important to have this support in order to have a smooth transition to Athens even without Cairo. > > So, what would it take for this support to happen? > > Cheers, > Doru > > > On 11 Jul 2012, at 09:04, Tudor Girba wrote: > >> Aha. Ok. I will wait. >> >> Doru >> >> >> On Wed, Jul 11, 2012 at 8:43 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> Good idea if possible. >>> Igor like me is on vacation until 19 of july. >>> >>> On Jul 10, 2012, at 7:07 AM, Tudor Girba wrote: >>> >>>> Hi Igor, >>>> >>>> I just wanted to ask: is the little fix of having Athens work with StrikeFont still on the roadmap :)? >>>> >>>> As I mentioned before, this would make the adoption easier, because we can switch the Athens even with the regular CogVMs. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "It's not what we do that matters most, it's how we do it." >>>> >>>> >>> >>> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > > -- > www.tudorgirba.com > > "In a world where everything is moving ever faster, > one might have better chances to win by moving slower." > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 22, 2012

[Pharo-project] [update 2.0] #20231

by Marcus Denker

20231 ----- Issue 6405: [ENH]: Clean MCCacheRepository http://code.google.com/p/pharo/issues/detail?id=6405 Issue 6299: MNU: FileReference class>>methodPassed: http://code.google.com/p/pharo/issues/detail?id=6299 Issue 6171: Methods from Trait have nil category http://code.google.com/p/pharo/issues/detail?id=6171 Issue 6074: Make ChangeSet rely on SystemAnnouncer instead of SystemChangeNotifier http://code.google.com/p/pharo/issues/detail?id=6074 -- Marcus Denker -- http://marcusdenker.de

July 22, 2012

Re: [Pharo-project] fuelized test failures

by StÃ©phane Ducasse

nice explanation. Indeed I really liked IS but fuel is the way to go :) On Jul 22, 2012, at 11:11 AM, Marcus Denker wrote: > > On Jul 22, 2012, at 10:00 AM, StÃ©phane Ducasse wrote: > >> I love that scenario :) >> This is great that powerful tools let us imagine and build solutions that would not be possible >> before. Power to imaginationâ¦ >> > And it is an example for a building block that helps to build things. Things that are *impossible* > without it. > > Another way to view Fuel is that of a scientific experiment: We empirically study the existing > (ImageSegment). Without pre-concived notions to replace it! (We actually thought ImageSegments > would turn out to be the greatest thing ever and just needed some documentation/more understandable > implementation). > -> You study the existing > -> You claim that you can do better > -> You do better. > > And then the next step is *extremeley* importnat: > > -> You prove that it is better for real by *replacing* ALL the existing subsystems that do the same. > > That last part is very essential: in the end, you often see that it is actually not that easy. > > So *replacing* is important. The other thing important is to realize that it enables things that are impossible > without. > > There are people that claim that instead of Pharo, what we should have done is to just do our research on > top of an unchanged Squeak. (While not even trying to improve Squeak itself). > > But I really wonder... just project Pharo some more years in the Future. Will that what we will be able to do > even be *thinkable* in the context of an unchanged Squeak 3.8? > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > >

July 22, 2012

[Pharo-project] [update 2.0] #20230

by Marcus Denker

20230 ----- Issue 6432: fix date and time parsing http://code.google.com/p/pharo/issues/detail?id=6432 Issue 3665: asStringOrText should invoke asString http://code.google.com/p/pharo/issues/detail?id=3665 Issue 6414: Failing Test on Mac: FileDialogWindowTest.testIssue6406 http://code.google.com/p/pharo/issues/detail?id=6414 -- Marcus Denker -- http://marcusdenker.de

July 22, 2012

Re: [Pharo-project] fuelized test failures

by Marcus Denker

On Jul 22, 2012, at 10:00 AM, StÃ©phane Ducasse wrote: > I love that scenario :) > This is great that powerful tools let us imagine and build solutions that would not be possible > before. Power to imaginationâ¦ > And it is an example for a building block that helps to build things. Things that are *impossible* without it. Another way to view Fuel is that of a scientific experiment: We empirically study the existing (ImageSegment). Without pre-concived notions to replace it! (We actually thought ImageSegments would turn out to be the greatest thing ever and just needed some documentation/more understandable implementation). -> You study the existing -> You claim that you can do better -> You do better. And then the next step is *extremeley* importnat: -> You prove that it is better for real by *replacing* ALL the existing subsystems that do the same. That last part is very essential: in the end, you often see that it is actually not that easy. So *replacing* is important. The other thing important is to realize that it enables things that are impossible without. There are people that claim that instead of Pharo, what we should have done is to just do our research on top of an unchanged Squeak. (While not even trying to improve Squeak itself). But I really wonder... just project Pharo some more years in the Future. Will that what we will be able to do even be *thinkable* in the context of an unchanged Squeak 3.8? Marcus -- Marcus Denker -- http://marcusdenker.de

July 22, 2012

Re: [Pharo-project] athens for strikefonts

by Tudor Girba

Hi Igor, First of all, how was your holidays? :) A while ago, you said that supporting StrikeFonts would not be that difficult. For me it would be important to have this support in order to have a smooth transition to Athens even without Cairo. So, what would it take for this support to happen? Cheers, Doru On 11 Jul 2012, at 09:04, Tudor Girba wrote: > Aha. Ok. I will wait. > > Doru > > > On Wed, Jul 11, 2012 at 8:43 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Good idea if possible. >> Igor like me is on vacation until 19 of july. >> >> On Jul 10, 2012, at 7:07 AM, Tudor Girba wrote: >> >>> Hi Igor, >>> >>> I just wanted to ask: is the little fix of having Athens work with StrikeFont still on the roadmap :)? >>> >>> As I mentioned before, this would make the adoption easier, because we can switch the Athens even with the regular CogVMs. >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "It's not what we do that matters most, it's how we do it." >>> >>> >> >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

July 22, 2012

Re: [Pharo-project] Customizing the Caret of a PluggableTextMorph

by StÃ©phane Ducasse

Phil Sorry for the state of the system. We are cleaning slowly. Now what would be good is that if you could enhance the class comments. Igor started to write a new paragraph (or text representation) I guess that he needs some help/feedback. Igor should be back from holiday so ping him please :). Stef > Ah, the morass into which I am currently digging... > > Well, if we look at it for a while, it becomes a tad clearer. > > PluggableTextMorph is just a shell for a TextMorph. > > The TextMorph basically displays a Text (which can be styled with TextAttributes) > > When moving into edition, there is an editor known by the TextMorph but this is not an editor like I understood it, but rather a helper object that will come handy with TextMorph>>handleInteraction: interactionBlock > > Inside handleInteraction, there is that editor and paragraph and then a call to interaction blockValue. > > And the interactionBlock is containing a bunch of various things that delegate the real editing work to the editor. > > Like in aTextMorph>>handleInteraction: [editor mouseUp: evt] > > If you then look into the editor (mostly SmalltalkEditor right now in the image), you see a quite large method for that mouseUp: evt handling. And lots of other things. > > There should be a cleanup occuring in the Editor -> TextEditor -> SmalltalkEditor hierarchy. > > The TextEditor knows a bit too much and I am currently implementing a child of TextEditor to have a simple, clean editor that does only the basics for my purpose. Once I am please with it, it may become an interesting child of Editor (maybe the TextEditor itself, with TextEditor renamed to something else (for example, TextEditor has something with codeCompletionAround). > > TextEditor and friends do have a ton of class side methods with all the commands, keystrokes, and menu entries. Very important to grasp how that works. > > The TextMorph>>editorClass returns the editor class to use. Currently the SmalltalkEditor (yikes!) > > If gets taken in TextMorph>>installEditorToReplace: priorEditor, where we get editor := self editorClass forMorph: self. > > digging further, we get TextEditor>>forMorph: aMorph returning > > ^self basicNew initWithMorph: aMorph. > > and ... we'll get there! ... TextEditor>>initWithMorph: aMorph > > super initialize. > morph := aMorph. > self resetState. > > So, we now have both linked. > > That dance occurs everytime we get something occuring to the TextMorph. > > >>handleEvent: anEvent will do anEvent sendTo: self and then the usual: > > evt sendTo: anObject, which will handle the event with ^anObjject handleMouseUp, donw, ... > > That is where we get back to the self handleInteraction: evt which calls the [editor mouseUp: evt] through the TextMorph handleInteraction. > > An interesting bit occurs with the TextMorph>>yellowActivity; shiftKeyState for the menus (and the PragmaMenuBuilder and strings like 'smalltalkMenu' looking into SmallTalk editor for menu entries (Class side, yellowButtonMenu and shifted friend). > > That's it for editor, except we need to say a word on its lifecyle: > > It gets created and destroyed all the time: created with TextMorph>>hasFocus, going away with keyBoardFocusChange > > > Then for Paragraph, just realize that Paragraphis something to be used like; > > Paragraph new > compose: text "Coming from the TextMorph" > style: textStyle copy "always copy these beasties" > from: 1 > in (0@0 extent: extX@extY); > adjustRightX; > ... > > So, the Paragraph is composing the text into an area, taking into account the styles that are in the text The TextStyle is the default style, it can be overriden by some TextAttribute. > > And that's where the TextMorph>>drawOn: aCanvas comes into play. > > if will invoke Canvas>>paragraph: which will draw the text. > > This will lead us to CharacterScanner and friends (CompositionScanner) and TextComposer depending on it. > > look for composeLineFrom: to: .... or composeAllLines. > > This will call Paragraph>>composeAll > > ^self multiComposeLinesFrom: firstCharIndex > to: text size > delta: 0 > into: OrderedCollection new "Ah, there we will end up into" > priorLines: Array new > atY: container top. > > > So, it may be interesting to see how Paragraph works, but paragraph has nothing to do with Editor. > > Paragraph renders the text if an editing change has to be shown display wise. But doesn't know about the Editor. > > TextMorph uses TextMorph>>updateFromParagraph and >>fit to do the stuff. > > In CharacterScanner you can find interesting display code: > > CharacterScanner>>basicScanCharactersFrom: startIndex > to: stopIndex > in: sourceString > rightX: rightX > stopConditions: stops "this one still a tad foggy to me" > kern: kernDelta > > There is a primitive rendering a char down there. This is all for StrikeFont. I don't know how TrueType is supported but there are > > As you are doing Vim keystrokes, check TextMorph>>basicKeyStroke that does the same dance as the mouse events but invokes > > self handleInteraction: [editor keystroke evt] > self updateFromParagraph. > super keystroke: evt. > > So, hope this makes it all a bit clearer. > > All of the PluggableTextMorph story builds upon all of the above to ensure a scrolling window and widget pluggability. Which I do not care at this point since I am designing a specific UI for a game. > > Phil > > 2012/7/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Jul 16, 2012, at 9:38 PM, Sean P. DeNigris wrote: > > > For VimPharo, I want to have a different cursor depending on whether a tool > > is in insert or normal mode. > > > > I tried a handful of ways, but they all failed or worked > > partially/inconsistently. Here's some of them: > > * add the state to the paragraph, but the entire paragraph gets replaced > > during the life of the tool, so the state gets lost > > * add the state to the editor, but the situation is the same > > * add the state to PluggableTextMorph, override and access it from > > TextMorphForEditView>>updateFromParagraph. This was an extreme PITA and got > > me very acquainted with the emergency evaluator. It "worked", but only after > > using the arrows a bit. > > > > Does anyone have any idea where I might hook in? > > > > <rant>I find the whole text system very confusing. What the heck does a > > paragraph know about insertion points?? A view has one paragraph object, > > even if there are several paragraphs (as understood by the rest of humanity > > as a block of text with breaks between the adjoining ones. Editors and > > Paragraphs are thrown out and replaced on a whim. I'm finding it very hard > > to understand and modify</rant> > > I got burned by that when I worked on my botanics envâ¦. > it was terrible. > > > > > Thanks, > > Sean > > > > -- > > View this message in context: http://forum.world.st/Customizing-the-Caret-of-a-PluggableTextMorph-tp46402… > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > > >

July 22, 2012

Re: [Pharo-project] Brain storming request: Semantic zooming for Roassal

by StÃ©phane Ducasse

Zooming is interesting and since Athens canvas is opening the vectorial space we should definitively try. I have serious doubt that this can of modeling will go anyway. It may be a fun master or bachelor topics. Now I would like to be able to build the same with Pharo: clean event nice support for zoom and we are getting closer and closer. Stef On Jul 19, 2012, at 10:33 PM, Alexandre Bergel wrote: > Hi! > > I've just found this video: > http://cel.inf.usi.ch/index.php?action=gallery > > I am not sure I really want to program a tetris that way, but the tool they have is interesting. It intensively use zooming in and out. When you zoom in, you see different objects and when you zoom out they disappear or they change their visual representation. > > For Roassal, we are thinking about adding new graphical elements when a particular height of the camera is reached. The elements will then disappear when the camera is getting altitude. However, it looks a bit simple in my opinion. Is there any compelling scenario for a better mechanism? > > Is there anything else you guys want to see in this zooming ability? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

July 22, 2012