November 2013 - Pharo-users

Roadmap

by Bahman Movaqar

Hi all, I tried to find some up-to-date information regarding SMP in Pharo to no avail. Actually, I couldn't find any roadmap documents on the website. I'd appreciate if someone could share a pointer/link here. TIA, -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)

Nov. 12, 2013

Re: [Pharo-users] Spec - Layout behaviour when resizing

by Bahman Movaqar

On 11/12/2013 17:29, Benjamin wrote: >>> On 11 Nov 2013, at 20:08, Bahman Movaqar <Bahman(a)BahmanM.com >>> <mailto:Bahman@BahmanM.com> >>> <mailto:Bahman@BahmanM.com>> wrote: >>> >>>> >>>> When a window is resized, every Row/ColumnLayoutdistributes the width >>>> and height evenly among any widget or nested layouts it contains. In >>>> turn, widgets try to fill as much space as possible. Therefore after >>>> resizing text box and button have become so huge and the space >>>> between the radio buttons has increased so much. >>>> Is that correct? >>> >>> Itâs correct in the sense it is expected regarding to the layout you >>> use :) >>> >>>> If yes, I have a couple of points to mention: >>>> >>>> 1. A text box, specially in the case of TextModel and >>>> TextInputFieldModel, where it's basically a single line entry >>>> (ENTER is not allowed), should not change height (growing width >>>> is understandable and desired). The height of a text box >>>> (specially a single line one) should only be calculated based on >>>> the font family and font size. >>>> >>> TextModel is for more that one line :) >>> TextInputField could eventually be forced to be one line, but I think >>> itâs too much of a restriction. >> >> I am 100% sure I didn't tell TextInputField to accept one line. It >> doesn't accept ENTER and I don't understand how a "multi-line" text >> entry widget can work without accepting new line character :-) >> Yes, TextInputField wraps the text but that's doesn't count as >> multi-line entry :-) More importantly it is unexpected behaviour from >> user's PoV; I have never seen a single text entry widget wrap the text. >> >> Or maybe I'm doing something wrong? > > I do not understand sorry :( Put in other words: 1. The default behaviour (if there's any other behaviour) of a text box in Spec, doesn't accept ENTER. A multi-line text entry without ENTER doesn't make sense, no? 2. The default behaviour of a Spec text box, wraps the text entered if the length exceeds the display length of the widget. This is very unorthodox and wrong *from user's perspective*. > >> >>> >>>> 1. >>>> >>>> >>>> >>>> 2. A button should not change height and width, unless specifically >>>> mentioned otherwise. >>>> >>> Why ? >> >> Because if the button changes height/width it loses the visual element >> which users use to recognise buttons across a screen. Just like a >> single-line text entry, a button's height, if not manually set, is >> determined only by the font family and font size. >> And regarding changing the button width, I've very rarely seen >> applications that resize their buttons when the screen is resized. >> Usually people put constraints over this. I'm not stating that this >> definitely should be some UI framework's internal mehcanism. Perhaps a >> simple method like `isCalculatedSize: aBoolean` with a TRUE default is >> enough. > > Thatâs true changing the size is often not desired. > > Adding a flag can be a solution :) > But as it brings some more complexity in the layouting ( which is already > quite too complex and too big) it was not considered until now :) Makes sense. > >> >>>> 3. It's not usually desirable that the spacing between radio buttons >>>> change. >>>> >>> Thatâs true :) >>> But how to know that two radio buttons are close one to the other ? >> >> Right. That's the reason radio button groups are, AFAIK, always >> implemented as widgets. > > Yes, but morphic do not do that :P > Myabe I should introduce a model for that, and have my own > encapsulation :) Perfect idea. And along with some documentation please :-D > >> >>> >>>> 4. Usually there's a way to specify how to distribute the >>>> width/height between layouts and widgets inside a layout (usually >>>> based on a percentage). >>>> >>> There in spec as well :) >>> You can have a look at: >>> add:origin:corner:offsetOrigin:offsetCorner: >>> >> Hmm...couldn't figure out the logic. Though it seems simple when >> looking at the code :-) > > Here you entrer in some twilight zone :P > > add:origin:corner:offsetOrigin:offsetCorner: > > > This screen shows an origin in x0,y0 and a corner in x1,y1. > Their values are between 0 and 1, and represent a _proportional_ value > of the container. By the gods! How was I supposed to know the values were supposed to be 0><1 !? :-) Thank you for this tip! > > Then, each of this corners can be shifted in x and y by a _fixed_ > value (in pixels) So basically `add: #buttonGreet origin: 0.3(a)0.2 corner: 0.7(a)0.5 offsetOrigin: 0@0 offsetCorner: 0@0` would add a button in a center'ish position within its container, right? I wonder what am I doing wrong since it has no effect whatsoever? Thanks, -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)

Nov. 12, 2013

How to add tabs in Nautilus

by kilon alios

I see in the top right side dropdown menu that there is an option to create a window goup which basically add the current instance of Nautilus in a tab but I dont know hot to add other tabs to it. It would be cool to have multiple tabs for each class selection and not to have to open a new window for each one. So how I add other tabs ?

Nov. 12, 2013

Re: [Pharo-users] Who uses poolDictionaries? New class template cleanup

by Camille Teruel

+1 On 12 nov. 2013, at 16:39, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > Hi all, > > I am preparing slides for a course. I came to the typical: > > Number subclass: #Complex > instanceVariableNames: 'real imaginary' > classVariableNames: '' > poolDictionaries: '' > category: 'ComplexNumbers' > > Which made me think: Who uses poolDictionaries? I suspect extremely few of us. > > Why not add this to Class: > Class>>subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames category: aSymbol > ^self subclass: aSymbol > instanceVariableNames: instVarNames > classVariableNames: classVarNames > poolDictionaries: '' > category: aSymbol > > And have the new class template as follows? > > Object subclass: #NameOfSubclass > instanceVariableNames: '' > classVariableNames: '' > category: 'Kernel-Classes' > > It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but I dislike having to explain it to students. > > Greetings, > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > >

Nov. 12, 2013

Who uses poolDictionaries? New class template cleanup

by Johan Fabry

Hi all, I am preparing slides for a course. I came to the typical: Number subclass: #Complex instanceVariableNames: 'real imaginary' classVariableNames: '' poolDictionaries: '' category: 'ComplexNumbers' Which made me think: Who uses poolDictionaries? I suspect extremely few of us. Why not add this to Class: Class>>subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames category: aSymbol ^self subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames poolDictionaries: '' category: aSymbol And have the new class template as follows? Object subclass: #NameOfSubclass instanceVariableNames: '' classVariableNames: '' category: 'Kernel-Classes' It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but I dislike having to explain it to students. Greetings, ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Nov. 12, 2013

Re: [Pharo-users] Add menu item to Nautilus context menu on selected packages?

by Benjamin

It is :) And I would even say it is not complicated :P Here is an example from Nautilus AbstractNautilusUI class>>packagesMenu: aBuilder <contextMenu> <nautilusGlobalPackageMenu> | package target | target := aBuilder model. (package := target selectedPackage) ifNil: [ ^ target ]. (aBuilder item: #'Browse scoped') keyText: 'b, s' if: Nautilus useOldStyleKeys not; action: [ target restrictedBrowsePackage ]; order: 1000; help: 'Open a browser on a restricted view'; withSeparatorAfter. :) Ben On 12 Nov 2013, at 15:41, MartinW <wm(a)fastmail.fm> wrote: > Hi, > i have a tool that works on packages. > So far i added a wizard to the world menu, but i would rather add a menu > item to the Nautilus context menu on selected packages - is this possible? > > Best regards, > Martin. > > > > -- > View this message in context: http://forum.world.st/Add-menu-item-to-Nautilus-context-menu-on-selected-pa… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Nov. 12, 2013

Add menu item to Nautilus context menu on selected packages?

by MartinW

Hi, i have a tool that works on packages. So far i added a wizard to the world menu, but i would rather add a menu item to the Nautilus context menu on selected packages - is this possible? Best regards, Martin. -- View this message in context: http://forum.world.st/Add-menu-item-to-Nautilus-context-menu-on-selected-pa… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Nov. 12, 2013

Re: [Pharo-users] Spec - Layout behaviour when resizing

by Benjamin

On 12 Nov 2013, at 04:11, Bahman Movaqar <Bahman(a)BahmanM.com> wrote: > On 11/11/2013 22:52, Benjamin wrote: >> I do not get the image, but I know what happened :) > > Oops! Corrected that. No problem :) > >> >> On 11 Nov 2013, at 20:08, Bahman Movaqar <Bahman(a)BahmanM.com >> <mailto:Bahman@BahmanM.com>> wrote: >> >>> >>> When a window is resized, every Row/ColumnLayoutdistributes the width >>> and height evenly among any widget or nested layouts it contains. In >>> turn, widgets try to fill as much space as possible. Therefore after >>> resizing text box and button have become so huge and the space >>> between the radio buttons has increased so much. >>> Is that correct? >> >> Itâs correct in the sense it is expected regarding to the layout you >> use :) >> >>> If yes, I have a couple of points to mention: >>> >>> 1. A text box, specially in the case of TextModel and >>> TextInputFieldModel, where it's basically a single line entry >>> (ENTER is not allowed), should not change height (growing width >>> is understandable and desired). The height of a text box >>> (specially a single line one) should only be calculated based on >>> the font family and font size. >>> >> TextModel is for more that one line :) >> TextInputField could eventually be forced to be one line, but I think >> itâs too much of a restriction. > > I am 100% sure I didn't tell TextInputField to accept one line. It > doesn't accept ENTER and I don't understand how a "multi-line" text > entry widget can work without accepting new line character :-) > Yes, TextInputField wraps the text but that's doesn't count as > multi-line entry :-) More importantly it is unexpected behaviour from > user's PoV; I have never seen a single text entry widget wrap the text. > > Or maybe I'm doing something wrong? I do not understand sorry :( > >> >>> 1. >>> >>> >>> >>> 2. A button should not change height and width, unless specifically >>> mentioned otherwise. >>> >> Why ? > > Because if the button changes height/width it loses the visual element > which users use to recognise buttons across a screen. Just like a > single-line text entry, a button's height, if not manually set, is > determined only by the font family and font size. > And regarding changing the button width, I've very rarely seen > applications that resize their buttons when the screen is resized. > Usually people put constraints over this. I'm not stating that this > definitely should be some UI framework's internal mehcanism. Perhaps a > simple method like `isCalculatedSize: aBoolean` with a TRUE default is > enough. Thatâs true changing the size is often not desired. Adding a flag can be a solution :) But as it brings some more complexity in the layouting ( which is already quite too complex and too big) it was not considered until now :) > >>> 3. It's not usually desirable that the spacing between radio buttons >>> change. >>> >> Thatâs true :) >> But how to know that two radio buttons are close one to the other ? > > Right. That's the reason radio button groups are, AFAIK, always > implemented as widgets. Yes, but morphic do not do that :P Myabe I should introduce a model for that, and have my own encapsulation :) > >> >>> 4. Usually there's a way to specify how to distribute the >>> width/height between layouts and widgets inside a layout (usually >>> based on a percentage). >>> >> There in spec as well :) >> You can have a look at: >> add:origin:corner:offsetOrigin:offsetCorner: >> > Hmm...couldn't figure out the logic. Though it seems simple when > looking at the code :-) Here you entrer in some twilight zone :P add:origin:corner:offsetOrigin:offsetCorner: This screen shows an origin in x0,y0 and a corner in x1,y1. Their values are between 0 and 1, and represent a _proportional_ value of the container. Then, each of this corners can be shifted in x and y by a _fixed_ value (in pixels) Ben > The best case I could get was a button with fixed width but a variable > height. Could you please help me out a bit here? > > -- > Bahman Movaqar (http://BahmanM.com) > > ERP Evaluation, Implementation & Deployment Consultant > PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) > >

Nov. 12, 2013

Re: [Pharo-users] NBOpenGL on Pharo 3.0

by StÃ©phane Ducasse

Richard you should have a look at ROASSAL 3d because ronie improved the shadder part (no more assembler) and his code should be split in two and one part should go to NBOpenGL. Now he is experiencing some problem with NBOpenGL on windows as you. NativeBoost does not work on 64 bits. Yet but igor is really busy finishing the texteditor (and I can tell you that he does not have fun there). So it is important that you help because we are FULL and sorry about that but really FULL. Ronie will visit us in January and share an office with igor. Stef > Hi > > CodeCity, the project I am working on is based on NBOpenGL. > I'd like to start working on it using Pharo 3, but it seems that NBOpenGL does not work yet with Pharo 3.0. > > I downloaded from jenkins the latest image with Pharo 3 and tried to execute the following code on Windows 7, 64 bits: > > GLTTRenderingDemo new openInWorld. > > but I get a 'No suitable implementation found for initializing OpenGL context for your platform'. > It seems that NBGLContextDriver does not have a subclass for Windows 64bits. Did I omit something? > > Cheers > Ricky >

Nov. 12, 2013

NBOpenGL on Pharo 3.0

by Richard Wettel

Hi CodeCity, the project I am working on is based on NBOpenGL. I'd like to start working on it using Pharo 3, but it seems that NBOpenGL does not work yet with Pharo 3.0. I downloaded from jenkins the latest image with Pharo 3 and tried to execute the following code on Windows 7, 64 bits: GLTTRenderingDemo new openInWorld. but I get a 'No suitable implementation found for initializing OpenGL context for your platform'. It seems that NBGLContextDriver does not have a subclass for Windows 64bits. Did I omit something? Cheers Ricky

Nov. 12, 2013