October 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 2.0] #20327

by Marcus Denker

20327 ----- Issue 6765: Rename Method Refactoring fails on Override http://code.google.com/p/pharo/issues/detail?id=6765 -- Marcus Denker -- http://marcusdenker.de

Oct. 9, 2012

[Pharo-project] RE : Re: Emacs and Smalltalk code

by Philippe Back

Live coding as experienced in pharo is really superior. It changes everything about how to think about programming. And I am a vi freak lets me tell you. Philippe Back 0478 650 140 Igor Stasenko <siguctua(a)gmail.com> a Ã©crit : On 8 October 2012 21:03, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 8 October 2012 19:22, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 8 October 2012 20:08, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>> On 8 October 2012 19:02, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>>> On 8 October 2012 18:31, Damien Cassou <damien.cassou(a)gmail.com> wrote: >>>>> On Mon, Oct 8, 2012 at 4:51 PM, Oscar E A CallaÃº < oalvarez(a)dcc.uchile.cl> wrote: >>>>>> I'm using Aquamacs (mac UI for emacs) as my default editor. But I have a problem, when trying to read a .st file, I don't get the syntax highlighting (so all is black-&-white). How I can solve this issue? >>>>> >>>>> Pharo/Smalltalk is not meant to be coded in Emacs, you have to use >>>>> Pharo currently (that may change in the future). >>>> >>>> For shame, Damien. Why is Smalltalk not meant to be coded in a text >>>> editor? It is text, after all. Next thing you'll suggest that one >>>> shouldn't use git to store one's code. >>> >>> Alright, OK, I wrote that with at least 50% troll in the mix. (*) >>> There's no reason why one shouldn't be able to use standard text >>> manipulation techniques to hack on Smalltalk code. We simply never >>> bothered doing so, and I dare say that the majority of people on this >>> list are happy not supporting text-using tools. >>> >>> (*) OK, OK, 75%. >>> >> Being told so many times.. People still keep missing the point. >> Smalltalk is not just source code it is environment of live objects. >> Good luck manipulating live objects in emacs. > > Please show me a live object in a Browser. Please. No, not a textual > representation of a computation. Oh, that's right, you are STILL > writing source code prior to compiling. Fail. > Oh come on, do you know that navigating code made by talking to live objects, not searching through whole source text, then doing static analysis (like some IDEs doing)? If you using browser only for typing, then you Fail. >> It is , of course up to you, If you prefer to code in stone age. >> I, personally cannot code outside image, without browser , debugger and such.. > > That's a strawman. I WANT a debugger, I WANT inspectors. I also WANT a > proper top level syntax and the ability to use the thousands of tools > that everyone else in the WHOLE WORLD takes for granted. OK, I've > exceeded my capital letter quota for the day. (Also, clearly you've > never used SLIME. I know this because SLIME lets you do everything you > could want to, because it queries a real live running system to get > its information. And guess how the Lispers store their source code? In > text files, in git. > Yes. I never used SLIME. I even don't know what is it. If you think it is far superior to what we have in pharo, please feel free to open our eyes, and direct us towards better system. > I have seen zero reason in my, er, 13 years of Smalltalk, why we > shouldn't enter source code in a proper text editor, with source > properly stored in files on a disk. Yes, I want to live inside a > running system as much as possible - not all the time, not being > forced to do so because we lack the tools - but as much as possible. > But source code is not a live object, it is text. And text should be > munged by text tools, and stored in text files, and kept in a > text-friendly source control system. > In 13 years, you had plenty of time to change things to meet your demands. Instead, you chosen path of complaining.. you make me laugh :) I can tell you more: things which you miss would be done long ago, if they would be needed so badly. But reality is that they are not. > What else do you think bootstrapping is all about? It's taking some > tiny system, and making a recipe to lift that bootstrap, and that > recipe is not a living object, it is a specification, and it's written > in text. > This is orthogonal. > Smalltalk is wonderful, and the reason I still hack in it is because I > can find nothing else that comes close to its sense of aliveness and > engagement, and I nearly cry when I see the community reject things > because of some strange ideology with the result that we end up lost > in the dark. > Defend your view, find allies, communicate. Contribute your code. And one day you will awake having much better system. Or, if you think we moving into wrong direction, and nothing can help, you can always start own fork (like Juan did with Cuis) and fix things there to meet your standards. Sitting and crying is not a solution. > Anyway. When I have something to show, I'll talk more on this topic. > > frank > >>> frank >>> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

Oct. 9, 2012

Re: [Pharo-project] Global session object?

by Igor Stasenko

On 8 October 2012 17:12, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 08.10.2012 16:35, Igor Stasenko wrote: > > On 8 October 2012 13:41, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no> wrote: > > On 08.10.2012 13:25, Igor Stasenko wrote: > > On 8 October 2012 13:06, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no> wrote: > > On 08.10.2012 13:03, Henrik Sperre Johansen wrote: > > > IMO, lazily checking whether the image has been restarted whenever you > want to do something stinks. > Registering to be notified when image starts/stops is a lot better. > > Not to mention, less error-prone. > Miss one session check that the current session is the right one > somewhere... and everything might blow up if that is the first piece of > functionality used. > > True. > I did not said that my method should replace old. Sometimes lazy > initialization is not what you want. > But having no way to perform lazy initialization is even worse. > > Ah, I just objected to the notion that startup lists inherently stinks, and > took the diametrical view for the sake of argument :) > Yes, lazy initialization has its uses too, but some guidelines/advice* on > when to what those uses are, and when you'd use startUp: registration > instead, is needed I think. > > Notice; in most cases where such cleanup at startup is needed (sockets, > window handles, etc.), additional cleanup is needed when the object goes out > of scope during regular use, and so a registry usually exist. > I will put some more reasons for the sake of discussion & learning. 1. during startup, you have to be very careful about dependencies between services, the errors like using uninitialized service(s) makes image unrecoverable (because VM crashing). For example , putting 'Transcript show: ' before freetype initialized may kill an image, beyond the point of recovery. The hardest part in it, that since everything is late bound, it sometimes really hard to put initialization in right order. And loading any new code in image will also contribute to chaos of interdependencies, unless all developers know that they should not use facility A before facility B is properly initialized. And the only way to do it is to add own checks and one more #startup method, which 'enabling' your service after all dependencies initialized. But the problem is that the longer chain of initialization gets, the more chances that something will go wrong (as well as getting lost in order of dependencies). 2. garbage collection. Yes, you can walk over weak registry to invalidate all handles before they having any chance to be used. Unless during startup, you losing sole reference to object in registry and then VM triggers GC _before_ entering your startup code. As result , finalization code will attempt to free non-existing resources.. Which in most cases also leads to VM crash. So, i would not agree that using lazy-initialization & check before use is more error prone than startup :) > Yes. > > Thus, your startup code isn't usually > X allInstancesDo: #something > but > X weakRegistry allEntriesDo: #someting. > > which stinks a whole lot less. > > in perfect world, yes :) > > But world is imperfect.. > For example, look here: > > FT2Handle>>shutDown: quitting > "we must not save handles (which are pointers) in the image" > self clearRegistry. > FreeTypeFace allInstances do:[:i | > "destroy any faces that are still being referenced" > i isValid > ifTrue:[i destroyHandle]]. > FT2Handle allSubInstances do: [:h | h beNull]. "if some handle was > not registered" > > because of the above, when i pass freetype faces handles to Cairo, > which caching a lot of stuff inside (obviously for performance reasons), > when you save an image, and then try to use Cairo after that (like > rendering text with same font) > an image is crashing. > Which means that "we must not save handles (which are pointers) in the > image" now blocking > me from having nice interoperability with Cairo.. > > Needless to say that destroying handles will force their recreation > after snapshot, since image > continues running and will keep using freetype fonts. > > This is actually the reason why i want to introduce session object(s), > so that i can fix freetype code > to play more nicely with cairo library. > > > I agree with this part from the wiki entry: > "Dolphin does not free external resources on a snapshot. Resources are freed > on shutdown (by registering for the shutdown events) and pointers/handles > are cleared on *startup*. Having worked with it for years, I have gone from > considering it strange to believing it is the correct design." > > Rewriting the shutdown to a startUp: method (conditional on the resuming > parameter) shouldn't be too much work. > > A short analysis of the code reveals: > 1) FT2Face/FT2MemoryFaceData aren't instatiated. > 2) Both FT2Face and FreeTypeExternalMemory instances are both registered in > the FT2Handle registry. (if used in a way which instantiates handle) > 3) FT2Library recreates a new instance based for each call to current, which > may be problematic, but current return values are never kept, just used to > check that FT is present. > > So really, cleaning the entries found in registry is all that's actually > needed at startup. > > Cheers, > Henry > -- Best regards, Igor Stasenko.

Oct. 9, 2012

Re: [Pharo-project] Emacs and Smalltalk code

by Igor Stasenko

On 8 October 2012 22:28, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> Being told so many times.. People still keep missing the point. >>> Smalltalk is not just source code it is environment of live objects. >>> Good luck manipulating live objects in emacs. >> >> Please show me a live object in a Browser. Please. No, not a textual >> representation of a computation. Oh, that's right, you are STILL >> writing source code prior to compiling. Fail. >> >>> It is , of course up to you, If you prefer to code in stone age. >>> I, personally cannot code outside image, without browser , debugger and such.. >> >> That's a strawman. I WANT a debugger, I WANT inspectors. I also WANT a >> proper top level syntax and the ability to use the thousands of tools >> that everyone else in the WHOLE WORLD takes for granted. OK, I've >> exceeded my capital letter quota for the day. (Also, clearly you've >> never used SLIME. I know this because SLIME lets you do everything you >> could want to, because it queries a real live running system to get >> its information. And guess how the Lispers store their source code? In >> text files, in git. > > shhh, that are no objects! how dare you storing smalltalk in git! > >> I have seen zero reason in my, er, 13 years of Smalltalk, why we >> shouldn't enter source code in a proper text editor, with source >> properly stored in files on a disk. Yes, I want to live inside a >> running system as much as possible - not all the time, not being >> forced to do so because we lack the tools - but as much as possible. >> But source code is not a live object, it is text. And text should be >> munged by text tools, and stored in text files, and kept in a >> text-friendly source control system. > > but, but we have the fancied multi-media development environment. > Plus we feature the greatest text editor with shortcuts only 1% of > the developers know. ... and those who know, keep their knowledge in secret :) > >> What else do you think bootstrapping is all about? It's taking some >> tiny system, and making a recipe to lift that bootstrap, and that >> recipe is not a living object, it is a specification, and it's written >> in text. >> >> Smalltalk is wonderful, and the reason I still hack in it is because I >> can find nothing else that comes close to its sense of aliveness and >> engagement, and I nearly cry when I see the community reject things >> because of some strange ideology with the result that we end up lost >> in the dark. > >> Anyway. When I have something to show, I'll talk more on this topic. > please!! -- Best regards, Igor Stasenko.

Oct. 8, 2012

Re: [Pharo-project] Global session object?

by Igor Stasenko

On 8 October 2012 21:39, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Oct 8, 2012, at 4:12 PM, Igor Stasenko wrote: > >> On 8 October 2012 13:39, David T. Lewis <lewis(a)mail.msen.com> wrote: >>> I like your idea, but just so this does not get overlooked: >>> >>> See also [Stack]Interpreter>>getThisSessionID which is used in e.g. >>> OSProcessPlugin>>primitiveGetSession for external resource management. >>> You could move the primitive into the interpreter if you wanted to make >>> it mandatory. >>> >>> This is the same session identifier that is used in the file and socket >>> plugins, so it might have some advantages over using a newly allocated >>> object that would not get allocated until after the plugins are already >>> initialized. But it does need VM support, so your Object new approach is >>> better in that respect. >>> >> >> yes, i saw that. >> The issue with sessionID, generated by VM, that there is a chance of collision: >> >> globalSessionID := 0. >> [globalSessionID = 0] >> whileTrue: [globalSessionID := self >> cCode: 'time(NULL) + ioMSecs()' >> inSmalltalk: [(Random new next * SmallInteger maxVal) asInteger]]. > > how can they collide? I do not see it and it should be obvious. I want to learn :) > They will collide eventually because id is 32-bit number. So, the max what you can have is 2^32 unique ids , after that you collide with existing ids inevitably. But given that 'time(NULL) + ioMSecs()' is far from having good random distribution, the collision probability is far more probable than 1/(2^32). When such collision happens, some objects in your system (which retain previously generated session id) will think that session is not changed, and all bad consequences will come shortly after that :) Still, those objects usually do not live long enough to have collision. And so, existing approach actually is good enough. But still, that's only a probability, while 'Object new' is certainty that you can never collide, and so it is simply better. >> >> while 'Object new' can never collide, no matter what happens :) >> >> Also, according to VM sources, this thing is obsolete, or at least not >> used as it supposedly should be used, >> like in primitive literal: >> >> Interpreter>>primitiveExternalCall >> "Call an external primitive. The external primitive methods >> contain as first literal an array consisting of: >> * The module name (String | Symbol) >> * The function name (String | Symbol) >> * The session ID (SmallInteger) [OBSOLETE] >> * The function index (Integer) in the externalPrimitiveTable >> >> (i don't remember where, i also seen more code, when hacking HydraVM, >> with commented >> sections of code which dealt with session id, but then turned into NOP). >> >> Another question, why session id was not exposed to language by VM >> (your primitive in OSProcess plugin does that, but since plugin is >> optional, the question remains the same). >> >> The proposed change is trivial to introduce and use, but what >> important, it don't requires altering VM. >> Altering VM in order to fix/improve session management, will >> immediately bring new issue: how to play nicely when running images >> which expect such feature to be present, while users (for no good >> reason, of course ;) using old/obsolete VMs to run image. > > Go for it igor. But put a nice comment explaining the Object new > > >> This is yet another thing which demonstrates that the less code you >> put in VM, the less you have to maintain and care less about >> compatibility issues. >> That's why i think that VM should be stupid, contain no complex logic >> and excessive features, only ones >> which having good reason to stay there (either no way how to do same >> thing in language, or gives a nice performance advantage). >> >>> Dave >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Oct. 8, 2012

Re: [Pharo-project] Emacs and Smalltalk code

by Igor Stasenko

On 8 October 2012 21:03, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 8 October 2012 19:22, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 8 October 2012 20:08, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>> On 8 October 2012 19:02, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>>> On 8 October 2012 18:31, Damien Cassou <damien.cassou(a)gmail.com> wrote: >>>>> On Mon, Oct 8, 2012 at 4:51 PM, Oscar E A CallaÃº <oalvarez(a)dcc.uchile.cl> wrote: >>>>>> I'm using Aquamacs (mac UI for emacs) as my default editor. But I have a problem, when trying to read a .st file, I don't get the syntax highlighting (so all is black-&-white). How I can solve this issue? >>>>> >>>>> Pharo/Smalltalk is not meant to be coded in Emacs, you have to use >>>>> Pharo currently (that may change in the future). >>>> >>>> For shame, Damien. Why is Smalltalk not meant to be coded in a text >>>> editor? It is text, after all. Next thing you'll suggest that one >>>> shouldn't use git to store one's code. >>> >>> Alright, OK, I wrote that with at least 50% troll in the mix. (*) >>> There's no reason why one shouldn't be able to use standard text >>> manipulation techniques to hack on Smalltalk code. We simply never >>> bothered doing so, and I dare say that the majority of people on this >>> list are happy not supporting text-using tools. >>> >>> (*) OK, OK, 75%. >>> >> Being told so many times.. People still keep missing the point. >> Smalltalk is not just source code it is environment of live objects. >> Good luck manipulating live objects in emacs. > > Please show me a live object in a Browser. Please. No, not a textual > representation of a computation. Oh, that's right, you are STILL > writing source code prior to compiling. Fail. > Oh come on, do you know that navigating code made by talking to live objects, not searching through whole source text, then doing static analysis (like some IDEs doing)? If you using browser only for typing, then you Fail. >> It is , of course up to you, If you prefer to code in stone age. >> I, personally cannot code outside image, without browser , debugger and such.. > > That's a strawman. I WANT a debugger, I WANT inspectors. I also WANT a > proper top level syntax and the ability to use the thousands of tools > that everyone else in the WHOLE WORLD takes for granted. OK, I've > exceeded my capital letter quota for the day. (Also, clearly you've > never used SLIME. I know this because SLIME lets you do everything you > could want to, because it queries a real live running system to get > its information. And guess how the Lispers store their source code? In > text files, in git. > Yes. I never used SLIME. I even don't know what is it. If you think it is far superior to what we have in pharo, please feel free to open our eyes, and direct us towards better system. > I have seen zero reason in my, er, 13 years of Smalltalk, why we > shouldn't enter source code in a proper text editor, with source > properly stored in files on a disk. Yes, I want to live inside a > running system as much as possible - not all the time, not being > forced to do so because we lack the tools - but as much as possible. > But source code is not a live object, it is text. And text should be > munged by text tools, and stored in text files, and kept in a > text-friendly source control system. > In 13 years, you had plenty of time to change things to meet your demands. Instead, you chosen path of complaining.. you make me laugh :) I can tell you more: things which you miss would be done long ago, if they would be needed so badly. But reality is that they are not. > What else do you think bootstrapping is all about? It's taking some > tiny system, and making a recipe to lift that bootstrap, and that > recipe is not a living object, it is a specification, and it's written > in text. > This is orthogonal. > Smalltalk is wonderful, and the reason I still hack in it is because I > can find nothing else that comes close to its sense of aliveness and > engagement, and I nearly cry when I see the community reject things > because of some strange ideology with the result that we end up lost > in the dark. > Defend your view, find allies, communicate. Contribute your code. And one day you will awake having much better system. Or, if you think we moving into wrong direction, and nothing can help, you can always start own fork (like Juan did with Cuis) and fix things there to meet your standards. Sitting and crying is not a solution. > Anyway. When I have something to show, I'll talk more on this topic. > > frank > >>> frank >>> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

Oct. 8, 2012

Re: [Pharo-project] Emacs and Smalltalk code

by Craig Latta

Hi Frank-- > Please show me a live object in a Browser. Please. No, not a textual > representation of a computation. Oh, that's right, you are STILL > writing source code prior to compiling. Fail. Browsers and debuggers are examples of inspectors, tailored to specialized tasks (e.g., writing methods and manipulating contexts). At a given moment, each inspector provides a interface for communicating with some live object. In the case of a "system browser", that live object is some class. For me, the ability to evaluate impromptu expressions in which "self" is bound to that class is what makes the browser "live". It justifies the claim that this live class is "in" the browser (although I think it makes more sense to think of the class as being "on" the browser, like a person with whom you're chatting is "on" the phone, or Skype, or TV). This communication ability is indispensable, and is what makes livecoding special for me. It manifests itself in many other ways in all the other inspectors we have. We can have useful and enlightening conversations with contexts, methods, collections, etc. etc. > And guess how the Lispers store their source code? In text files, in > git. I have a hard time imagining anyone who has used an interactive Lisp machine not finding this overwhelmingly sad. :) > I have seen zero reason in my, er, 13 years of Smalltalk, why we > shouldn't enter source code in a proper text editor, with source > properly stored in files on a disk. Well, I only need one reason, and it's this: object-aware tools, composed of objects, do a better job of enabling development. The "proper" stuff above just cracks me up! :) "More widespread" or somesuch I can see, but "proper" is a gratuitous expression of personal bias. > ...source code is not a live object, it is text. Surely text need not be a live object, but it can be. If source code and other texts are live objects, they can take on useful behavior, collaborating with other objects in the pursuit of their own munging. > And text should be munged by [external] text tools, and stored in > text files, and kept in a text-friendly source control system. Sure, you could do that. Why is that the only possibility? Also, why can't object memories present themselves as filesystems, and then interact with all those crusty old external text tools? (E.g., interaction via WebDAV[1]) When you take an individual file out of the filesystem which provides its context, you then rely on conventions between people as to how to interpret those files. You're relying on the behavior of those people. I think it's an improvement to endow the artifacts themselves with as much of that behavior as possible. > What else do you think bootstrapping is all about? It's taking some > tiny system, and making a recipe to lift that bootstrap, and that > recipe is not a living object, it is a specification, and it's written > in text. Or it could be a specification expressed in a very small number of objects. Were you this crotchety when they got the metacircular evaluator section of your Lisp class, too? :) > ...I nearly cry when I see the community reject things because of > some strange ideology with the result that we end up lost in the dark. I have a very bright torch; what wrongs need righting? :) -C [1] http://tinyurl.com/7j26wk6 -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547 (no SMS)

Oct. 8, 2012

[Pharo-project] RE : RE : RE : spec + shortcuts

by GOUBIER Thierry

________________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Camillo Bruni [camillobruni(a)gmail.com] Date d'envoi : lundi 8 octobre 2012 23:04 Ã : Pharo-project(a)lists.gforge.inria.fr Objet : Re: [Pharo-project] RE : RE : spec + shortcuts On 2012-10-08, at 22:57, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: >> Well, as long as you're happy with the way Keymapping is integrated in Spec, it's moving forward a bit. But I'm not sure Spec current focusOrder will still work; it may needs to be rewritten using Keymapping. > the keymapping stuff is great, at least for me straight-forward. > It's actually the first time I really have a look at spec ;). > But the whole focus stuff is a bit harder to grasp in your changes... > So I leave that to people who know more about spec than I do. In fact, the focus stuff I did is in 6734. The thing with doing the focus in Keymapping is that the tab and crtl+tab events, when processed by Keymapping, are then considered as handled and not forwarded to the model, making the focusOrder of Spec non working since it takes place at the very end of the keyboard event processing sequence, if I'm not wrong. I'm a bit waiting on a Spec specialist to have a look into that as well :) >> There is something else I discovered when reverting to Morphic instead of Spec is that my Spec-based app seemed to be very memory hungry compared to the Morphic version with the same code and functionality. Old instances of the app seemed to be very hard to garbage collect. > I guess there is a lot to optimize in spec, since it's still quite young... That's true...

Oct. 8, 2012

Re: [Pharo-project] RE : RE : spec + shortcuts

by Camillo Bruni

On 2012-10-08, at 22:57, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > Well, as long as you're happy with the way Keymapping is integrated in Spec, it's moving forward a bit. But I'm not sure Spec current focusOrder will still work; it may needs to be rewritten using Keymapping. the keymapping stuff is great, at least for me straight-forward. It's actually the first time I really have a look at spec ;). But the whole focus stuff is a bit harder to grasp in your changes... So I leave that to people who know more about spec than I do. > There is something else I discovered when reverting to Morphic instead of Spec is that my Spec-based app seemed to be very memory hungry compared to the Morphic version with the same code and functionality. Old instances of the app seemed to be very hard to garbage collect. I guess there is a lot to optimize in spec, since it's still quite young...

Oct. 8, 2012

[Pharo-project] RE : RE : spec + shortcuts

by GOUBIER Thierry

Well, as long as you're happy with the way Keymapping is integrated in Spec, it's moving forward a bit. But I'm not sure Spec current focusOrder will still work; it may needs to be rewritten using Keymapping. There is something else I discovered when reverting to Morphic instead of Spec is that my Spec-based app seemed to be very memory hungry compared to the Morphic version with the same code and functionality. Old instances of the app seemed to be very hard to garbage collect. Thierry ________________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Camillo Bruni [camillobruni(a)gmail.com] Date d'envoi : lundi 8 octobre 2012 22:32 Ã : Pharo-project(a)lists.gforge.inria.fr Objet : Re: [Pharo-project] RE : spec + shortcuts humm ok, that's too much work for me now, plus I cannot know the side-effects. For now I will take your fix in 6736 and create a keymapping only version. like that I can get it integrated this week plus test it. best cami On 2012-10-08, at 21:15, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > Hi Camillo, > > Sorry for not answering earlier; at the moment, I'm on duty and offline during daytime for two weeks :( > > For selecting by hand the focus, you can use takeKeyboardFocus on the model of the widget you want to activate; by default, Morphic selects the first keyboard interested morph. > > However, it may be hard to find the right place to set the keyboard focus after opening the window. I think that Spec should have the equivalent to VisualWorks' postBuildWith: and postOpenWith: (if my memory is right) to make that easier. > > Thierry > > ________________________________________ > De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Camillo Bruni [camillobruni(a)gmail.com] > Date d'envoi : lundi 8 octobre 2012 20:17 > Ã : Pharo-project(a)lists.gforge.inria.fr Development > Objet : [Pharo-project] spec + shortcuts > > I just looked at https://code.google.com/p/pharo/issues/detail?id=6736 > Everything looks more or less ok, the keymapping integration is nice! > > I have one doubt though (and I really don't know anything about spec...). > > How do I explicitly set the default focus when opening an spec UI-item? > >

Oct. 8, 2012