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

Re: [Pharo-project] TWM warning while loading

by laurent laffont

On Tue, Jan 3, 2012 at 6:58 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > In Pharo 1.4 update: #14261: > (ConfigurationOfTilingWindowManager project version: #bleedingEdge) load > > This package depends on the following classes: > OBBrowser > You must resolve these dependencies before you will be able to load these > definitions: > patchworkUIThemeColor > I've added this extension so OBBrowser has a green color (same as Browser) when using TWM. Now OB is not in Pharo 1.4 anymore so I should update ConfigurationOfTilingWindowManager for Pharo 1.4. Is there a nice way to apply an extension only if the class is here ? Laurent > > > Select Proceed to continue, or close this window to cancel the operation. > > -- > View this message in context: > http://forum.world.st/TWM-warning-while-loading-tp4257854p4257854.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Jan. 4, 2012

Re: [Pharo-project] Tiling Window Manager

by laurent laffont

> > > (Pharo 1.4): > http://magaloma.blogspot.com/2011/07/twm-docking-windows.html > > - tabs: (GroupWindowMorph new openInWindowLabeled: 'Window organizer') > > extent: 400@400 > > - dock: DockingWindowMorph new openInWorld. > > but needs some work to be really nice. > > > These don't work on Pharo 1.3. They open, but do not accept morphs dropped > on them. > Yes, only in Pharo 1.4. If you want to make it work on Pharo 1.3, you should load these changesets before loading TWM: http://code.google.com/p/pharo/issues/detail?id=4391 Laurent > > -- > View this message in context: > http://forum.world.st/Tiling-Window-Manager-tp4226499p4258369.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Jan. 4, 2012

Re: [Pharo-project] Bug Report: 6 of 6: Settings

by S Krish

No. On Tue, Jan 3, 2012 at 9:02 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > But the interface should bark instead of forgetting a change silently > when we open/close a preference (Oups setting) node... > Does it now ? > > Nicolas > > 2012/1/3 S Krish <krishnamachari.sudhakar(a)gmail.com>: > > Thats already there.. > > > > it does show the highlighted background and also a tip on the text area > > below to accept on cr. But as lazy as we are we do not notice hints > obvious > > in the face of habits. > > > > > > On Tue, Jan 3, 2012 at 6:27 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> > >> Mariano Martinez Peck wrote: > >>> > >>> On Tue, Jan 3, 2012 at 1:11 PM, Alain Plantec > >>> <alain.plantec(a)yahoo.com>wrote: > >>> > >>> > >>>> > >>>> Le 03/01/2012 11:57, S Krish a Ã©crit : > >>>> > >>>> This works... > >>>> > >>>>> > >>>>> Guess I should have tried that.. > >>>>> > >>>>> > >>>> > >>>> thanks. > >>>> but you are not the first one to forget to enter a cr. > >>>> > >>>> > >>> > >>> > >>> Yes, I was the first one!!! I remember I have reported the same ;) > >>> > >>> > >> > >> A small thought - the field background might be made to change colour > >> during entry until it is accepted by <cr>. > >> > > > >

Jan. 4, 2012

Re: [Pharo-project] Keyboard navigation and Settings browser

by Alain Plantec

Le 03/01/2012 21:00, Sean P. DeNigris a Ã©crit : > A few observations inspired by using the Settings browser: > > * Is there a way to exclude a submorph from tabbing? In the settings > browser, if you keep tabbing, you eventually focus on the statusView, which > is a text editor, and you start inserting tabs into the text instead of > continuing to navigate in 1.4, the keyboard focus is token by the tree, so that you can directly navigate with the keyboard inside the tree. This is explicitely programmed by sending #takeKeyboardFocus to the tree morph but after the window is opened. (see SettingBrowser>>open) It can be easily changed to make the search field take the focus on open if it is the desired behavior. but I don't know if there is a way to declare the focus owner before opening the window. > > * a disabled text editor should pass keyboard focus on tab instead of > doing nothing (the current behavior) yes it should > > * how do you say which is the default widget? just set the keyboard focus > manually? This would be hard using the Polymorph workflow as in the > examples/Pharocasts/etc. because: > - you'd have to store a reference to the morph instance, so you can set > the focus after the window has been opened (will not work otherwise). > - tools like the Settings browser build the UI in an instance method, so > now a morph would have to be stored in the model - yuck > Dialog window has #defaultFocusMorph. Maybe this should be added to > SystemWindow? I agree > > * EditableDropListMorphs should pass keyboard focus to their contentMorph. > Right now it takes two tabs to activate. The first one just highlights the > EditableDropListMorph, but does not let you type into it yes Cheers Alain > > What do you think? > > Sean > > p.s. this exploration started because I thought it'd be more useful if the > Settings browser opened with the search field active > > -- > View this message in context: http://forum.world.st/Keyboard-navigation-and-Settings-browser-tp4258311p42… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Jan. 3, 2012

Re: [Pharo-project] Tiling Window Manager

by Sean P. DeNigris

laurent laffont wrote > > Actually TWM has these ways for grouping windows: > - worlds: > http://magaloma.blogspot.com/2011/06/multiple-worlds-for-twm.html > Forgot about that! Okay, that is helpful. laurent laffont wrote > > (Pharo 1.4): http://magaloma.blogspot.com/2011/07/twm-docking-windows.html > - tabs: (GroupWindowMorph new openInWindowLabeled: 'Window organizer') > extent: 400@400 > - dock: DockingWindowMorph new openInWorld. > but needs some work to be really nice. > These don't work on Pharo 1.3. They open, but do not accept morphs dropped on them. -- View this message in context: http://forum.world.st/Tiling-Window-Manager-tp4226499p4258369.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 3, 2012

[Pharo-project] Keyboard navigation and Settings browser

by Sean P. DeNigris

A few observations inspired by using the Settings browser: * Is there a way to exclude a submorph from tabbing? In the settings browser, if you keep tabbing, you eventually focus on the statusView, which is a text editor, and you start inserting tabs into the text instead of continuing to navigate * a disabled text editor should pass keyboard focus on tab instead of doing nothing (the current behavior) * how do you say which is the default widget? just set the keyboard focus manually? This would be hard using the Polymorph workflow as in the examples/Pharocasts/etc. because: - you'd have to store a reference to the morph instance, so you can set the focus after the window has been opened (will not work otherwise). - tools like the Settings browser build the UI in an instance method, so now a morph would have to be stored in the model - yuck Dialog window has #defaultFocusMorph. Maybe this should be added to SystemWindow? * EditableDropListMorphs should pass keyboard focus to their contentMorph. Right now it takes two tabs to activate. The first one just highlights the EditableDropListMorph, but does not let you type into it What do you think? Sean p.s. this exploration started because I thought it'd be more useful if the Settings browser opened with the search field active -- View this message in context: http://forum.world.st/Keyboard-navigation-and-Settings-browser-tp4258311p42… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 3, 2012

Re: [Pharo-project] About ConfigurationOfXMLSupport

by Dale Henrichs

Stef, I think that the #stable spec that exists for that package is based on the bet guess at the time ... as better information comes along the #stable spec should be updated ... hopefully the developers themselves would eventually update and maintain the #stable spec ... Dale ----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Thursday, December 29, 2011 2:08:59 PM | Subject: Re: [Pharo-project] About ConfigurationOfXMLSupport | | Then I do not understand how a stable version can be defined as | | stable: spec | <symbolicVersion: #'stable'> | | spec for: #'common' version: '1.2.1'. | spec for: #'gemstone' version: '1.1.8'. | | | Because I would really prefer to get | | stable: spec | <symbolicVersion: #stable> | | spec for: #gemstone version: '1.5'. | spec for: #'squeak' version: '1.4'. | spec for: #'pharo1.0.x' version: '1.5'. | spec for: #'pharo1.1.x' version: '1.5'. | spec for: #'pharo1.2.x' version: #development. | | Because like that we can load it in different versions. | | Am'I wrong? | | Stef | On Dec 29, 2011, at 11:04 PM, StÃ©phane Ducasse wrote: | | > Hi guys | > | > I thought that XMLSupport was about parsing and XMLNode traversal. | > So why the configuration contains references to SIXX and Grease | > Core? | > | > Stef | > | | |

Jan. 3, 2012

[Pharo-project] Call for papers - Science of Computer Programming: Special Issue on "Advances in Dynamic Languages"

by jannik.laval

================================================ Special issue on "Advances in Dynamic Languages" ================================================ Special issue of Elsevier's Science of Computer Programming (SCICO) Context ------- Over recent years we have seen an increased interest in dynamic programming languages such as Smalltalk, Lisp, Scheme, PHP, JavaScript, Self, Python, Ruby, and so on. These languages have taken a prominent role in teaching, web development, scripting, rapid prototyping, tool building, language engineering, and many other domains. For this special issue we invite high-quality papers that focus on novel research related to dynamic programming languages and applications of these languages. We are interested in research that uses dynamic languages in the context of, but not restricted to: - Aspects, aspect Languages and applications. - Ambient intelligence, ubiquitous / pervasive computing and embedded systems. - Compilation technology, optimization, virtual machines. - Language engineering, extensions. - Model-driven engineering / development. - Meta-modeling, reflection and meta-programming. - Programming in the large; design, architectures and components. - Programming environments, browsers, user interfaces, UI frameworks. - Source-code analysis and manipulation (static analysis,refactoring, type inference, metrics). - Testing, eXtreme Programming / practices. - Web services, internet applications, event-driven programming. - Experience reports. The special issue is associated with the Smalltalks 2011 conference. The Smalltalks series of conferences (www.fast.org.ar) is a lively forum on Smalltalk-based software technologies that brings together more than 200 people from both academia and industry for a period of three days. Submission Guidelines --------------------- Papers should be written in English, in PDF-format and should not exceed 25 pages (including references and figures), using the Elsevier journal format. The LaTeX template for this format can be found at http://www.elsevier.com/wps/find/authorsview.authors/latex Papers must be submitted through the EES submission system located at http://ees.elsevier.com/scico/default.asp When reaching the "Article type" step in the submission process, it is important to select "Special issue: Advances in Dynamic Languages". Each paper will be reviewed by at least 3 experts within the domain. The accepted papers will be published in a special edition of Elsevier's Science of Computer Programming. Papers submitted must not have been previously published (at least 30% new material) and must not be under review for publication elsewhere. Papers must strictly adhere to submission guidelines. If you have questions, please send an e-mail to Jannik Laval (jlaval(a)labri.fr) and Andy Kellens (akellens(a)vub.ac.be) Important dates (tentitavely) ----------------------------- - Submission round 1: March 16, 2012 - Feedback round 1: May 17, 2012 - Submission round 2: June 29, 2012 - Feedback round 2 (final notification): August 17, 2012 - Camera ready version: September 14, 2012 Guest editors ------------- Andy Kellens (Vrije Universiteit Brussel, Belgium) Jannik Laval (LaBRI Bordeaux, France)

Jan. 3, 2012

Re: [Pharo-project] Category to be ignored by Monticello?

by Eliot Miranda

Hi Dave, On Tue, Jan 3, 2012 at 10:32 AM, Dave Mason <dmason(a)mason-rose.ca> wrote: > I have some code that generates code on the fly in user classes. I want > them to stay in the image for efficiency reasons, but if the user class > gets saved in Monticello, I don't want the generated code saved. I can > obviously put the methods in some particular category - say > *auto*generated*do*not*save*. But after looking at Monticello for a bit, I > can't find where it decides what to save - if, for example, it ignores > things in other categories. > > Any help appreciated - either "Yes, it ignores *foo*bar* category", or > "Here's where to look in Monticello" > The convention understood by Monticello is that categories that begin with *package- are part of package. e.g. in my image there's a protocol in class Object called "*VMMaker-translation support" that contains extensions on Object that are part of the VMMaker package. The methods there-in are saved only when the VMMaker package is saved, not when the Kernel package (which contains the class Object) is saved. So to arrange that user classes are unaffected it is sufficient to add your code in some invented package, using the above convention, e.g. "*ThisIsNotARealMonticelloPackage-so dont worry about the methods here in" :) When Monticello is used to save the user's code these extensions will be ignored. The would only get saved if one tried to save the ThisIsNotARealMonticelloPackage package. HTH > Thanks ../Dave > -- best, Eliot

Jan. 3, 2012

[Pharo-project] Category to be ignored by Monticello?

by Dave Mason

I have some code that generates code on the fly in user classes. I want them to stay in the image for efficiency reasons, but if the user class gets saved in Monticello, I don't want the generated code saved. I can obviously put the methods in some particular category - say *auto*generated*do*not*save*. But after looking at Monticello for a bit, I can't find where it decides what to save - if, for example, it ignores things in other categories. Any help appreciated - either "Yes, it ignores *foo*bar* category", or "Here's where to look in Monticello" Thanks ../Dave

Jan. 3, 2012