November 2013 - Pharo-users

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

by Benjamin

Ben On 12 Nov 2013, at 19:46, btc(a)openinworld.com wrote: > Bahman Movaqar wrote: >> 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? What enter does then ? >> 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*. What is expected ? Which widget of text ? This behaviour is actually Morphic behaviour, not Spec. But anyway, it can/should be fixed/improved :) > I have to support point 2 above. In general terms... > For a single line text box, I would expect it to scroll text horizontally out of view. > I would expect initially at least two lines for a wrapping text box, after which it can be free to grow vertically as needed. > > cheers -ben >> > >> >> >> >>> >> >>>> 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! Everybody should know that :P >> >> > >> > 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? It should do something like this yes :) >> I wonder what am I doing wrong since it has no effect whatsoever? What is the result ? Ben >> >> Thanks, >> >> -- >> Bahman Movaqar (http://BahmanM.com) >> >> ERP Evaluation, Implementation & Deployment Consultant >> PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) >> >> > > >

Nov. 12, 2013

Re: [Pharo-users] How to add tabs in Nautilus

by Benjamin

On 12 Nov 2013, at 19:53, kilon alios <kilon.alios(a)gmail.com> wrote: > hahahaha nicely played man , nicely played :D > > of course I will , but so you know, I dont pay overtime ... now I think about it, I dont pay at all, but thats another matter . > > I would love to see tab in Nautilus , they will definitely sort the windows mess. At least partly. Me too :) Thatâs why I am writing a new one (made with Spec) Otherwise, in full morphic, you will see the pain it is :P Ben > On Tue, Nov 12, 2013 at 8:47 PM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > The easier way is to wait for me to finish the new Nautilus with tabs in it :P > > Ben > > On 12 Nov 2013, at 17:50, kilon alios <kilon.alios(a)gmail.com> wrote: > >> 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] How to add tabs in Nautilus

by kilon alios

hahahaha nicely played man , nicely played :D of course I will , but so you know, I dont pay overtime ... now I think about it, I dont pay at all, but thats another matter . I would love to see tab in Nautilus , they will definitely sort the windows mess. At least partly. On Tue, Nov 12, 2013 at 8:47 PM, Benjamin < Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > The easier way is to wait for me to finish the new Nautilus with tabs in > it :P > > Ben > > On 12 Nov 2013, at 17:50, kilon alios <kilon.alios(a)gmail.com> wrote: > > 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] How to add tabs in Nautilus

by Benjamin

The easier way is to wait for me to finish the new Nautilus with tabs in it :P Ben On 12 Nov 2013, at 17:50, kilon alios <kilon.alios(a)gmail.com> wrote: > 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] Spec - Layout behaviour when resizing

by btc＠openinworld.com

Bahman Movaqar wrote: > 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*. > I have to support point 2 above. In general terms... For a single line text box, I would expect it to scroll text horizontally out of view. I would expect initially at least two lines for a wrapping text box, after which it can be free to grow vertically as needed. cheers -ben > > > >> > >>> > >>>> 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

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

Re: [Pharo-users] SerialPlugin on MacOS

by Bernat Romagosa

Thanks, Esteban. Anything I can do to help, I'm available :) 2013/11/12 Esteban Lorenzano <estebanlm(a)gmail.com> > > On Nov 12, 2013, at 5:58 AM, Bernat Romagosa < > tibabenfortlapalanca(a)gmail.com> wrote: > > I can confirm I still got the same issue after replacing my VM by the > vmLatest found at files.pharo.org/vm/pharo/mac under the name > "Pharo-VM-mac-latest.zip" > > > I will check next week :) > > > When trying to write a byte array to the serial port (aSerialPort > nextPutAll: #[249]), SerialPort fails with a primitiveFailed: primitive > #primWritePortByName:from:startingAt:count: > > The port does open correctly, though. > > > 2013/11/11 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> > >> Thanks guys, >> >> files.pharo.org is down right now >> >> I'll try with a newer VM as soon as it's up again :) >> >> >> 2013/11/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >>> >>> On Nov 9, 2013, at 2:19 PM, Camillo Bruni <camillobruni(a)gmail.com> >>> wrote: >>> >>> > Luc proposed a pull request on github >>> > - got validated by travis >>> > - I integrated it into the master branch >>> > - I pushed the changes to the develop branch >>> > >>> > so the vmLatest should include the fixes >>> >>> I like the process and that esteban releases some steam :) >>> >>> Stef >>> >>> > >>> > On 2013-11-09, at 13:56, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> wrote: >>> >> Esteban >>> >> >>> >> we should organize some sessions where you show to people what you >>> are doing and see how we >>> >> should distribute and share load. >>> >> >>> >> Stef >>> >> >>> >> On Nov 9, 2013, at 12:29 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >>> wrote: >>> >> >>> >>> Hi, >>> >>> >>> >>> it is "stable" but AFAIK it does not includes the latest fix for >>> SerialPlugin. >>> >>> So many things to do when I come back... :) >>> >>> >>> >>> Esteban >>> >>> >>> >>> >>> >>> On Nov 5, 2013, at 8:27 AM, Bernat Romagosa < >>> tibabenfortlapalanca(a)gmail.com> wrote: >>> >>> >>> >>>> Hi Luc, >>> >>>> >>> >>>> Smalltalk vm version reports: >>> >>>> >>> >>>> 'NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: >>> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 >>> >>>> NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: >>> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 >>> >>>> git://gitorious.org/cogvm/blessed.git Commit: >>> 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 >>> By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 >>> >>>> ' >>> >>>> >>> >>>> It's the one listed as "latest" at the downloads section in >>> pharo-project.org >>> >>>> >>> >>>> Cheers, >>> >>>> Bernat. >>> >>>> >>> >>>> >>> >>>> 2013/11/5 Luc Fabresse <luc.fabresse(a)gmail.com> >>> >>>> >>> >>>> >>> >>>> 2013/11/5 Luc Fabresse <luc.fabresse(a)gmail.com> >>> >>>> Hi Bernat, >>> >>>> >>> >>>> Which VM version? >>> >>>> because MacOsX and Linux now use the same C part of the >>> SerialPlugin. >>> >>>> So if it works on Linux, it be the same on OsX. >>> >>>> but I have not tried. >>> >>>> >>> >>>> yes we only use Linux here for serial stuff. >>> >>>> >>> >>>> >>> >>>> do you use the right protName? >>> >>>> >>> >>>> Cheers, >>> >>>> >>> >>>> Luc >>> >>>> >>> >>>> >>> >>>> 2013/11/5 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> >>> >>>> Hi list, >>> >>>> >>> >>>> Developing a multi-platform application is not so easy when you >>> have to deal with hardware it seems... >>> >>>> >>> >>>> So I'm having this PrimitiveFailed error on MacOS, using the latest >>> stable VM listed on the pharo-project website on Pharo20: >>> >>>> >>> >>>> PrimitiveFailed: primitive >>> #primWritePortByName:from:startingAt:count: in SerialPort failed >>> >>>> >>> >>>> The same code works fine both in Gnu/Linux and Win32, so I'm >>> guessing it's a problem with the serial plugin included in this VM. Any >>> ideas? >>> >>>> >>> >>>> Cheers, >>> >>>> Bernat. >>> >>>> >>> >>>> -- >>> >>>> Bernat Romagosa. >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> Bernat Romagosa. >>> >>> >>> >> >>> > >>> > >>> >>> >>> >> >> >> -- >> Bernat Romagosa. >> > > > > -- > Bernat Romagosa. > > > -- Bernat Romagosa.

Nov. 12, 2013

Re: [Pharo-users] SerialPlugin on MacOS

by Esteban Lorenzano

On Nov 12, 2013, at 5:58 AM, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: > I can confirm I still got the same issue after replacing my VM by the vmLatest found at files.pharo.org/vm/pharo/mac under the name "Pharo-VM-mac-latest.zip" I will check next week :) > > When trying to write a byte array to the serial port (aSerialPort nextPutAll: #[249]), SerialPort fails with a primitiveFailed: primitive #primWritePortByName:from:startingAt:count: > > The port does open correctly, though. > > > 2013/11/11 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> > Thanks guys, > > files.pharo.org is down right now > > I'll try with a newer VM as soon as it's up again :) > > > 2013/11/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Nov 9, 2013, at 2:19 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > > Luc proposed a pull request on github > > - got validated by travis > > - I integrated it into the master branch > > - I pushed the changes to the develop branch > > > > so the vmLatest should include the fixes > > I like the process and that esteban releases some steam :) > > Stef > > > > > On 2013-11-09, at 13:56, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Esteban > >> > >> we should organize some sessions where you show to people what you are doing and see how we > >> should distribute and share load. > >> > >> Stef > >> > >> On Nov 9, 2013, at 12:29 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> > >>> Hi, > >>> > >>> it is "stable" but AFAIK it does not includes the latest fix for SerialPlugin. > >>> So many things to do when I come back... :) > >>> > >>> Esteban > >>> > >>> > >>> On Nov 5, 2013, at 8:27 AM, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: > >>> > >>>> Hi Luc, > >>>> > >>>> Smalltalk vm version reports: > >>>> > >>>> 'NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > >>>> NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > >>>> git://gitorious.org/cogvm/blessed.git Commit: 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 > >>>> ' > >>>> > >>>> It's the one listed as "latest" at the downloads section in pharo-project.org > >>>> > >>>> Cheers, > >>>> Bernat. > >>>> > >>>> > >>>> 2013/11/5 Luc Fabresse <luc.fabresse(a)gmail.com> > >>>> > >>>> > >>>> 2013/11/5 Luc Fabresse <luc.fabresse(a)gmail.com> > >>>> Hi Bernat, > >>>> > >>>> Which VM version? > >>>> because MacOsX and Linux now use the same C part of the SerialPlugin. > >>>> So if it works on Linux, it be the same on OsX. > >>>> but I have not tried. > >>>> > >>>> yes we only use Linux here for serial stuff. > >>>> > >>>> > >>>> do you use the right protName? > >>>> > >>>> Cheers, > >>>> > >>>> Luc > >>>> > >>>> > >>>> 2013/11/5 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> > >>>> Hi list, > >>>> > >>>> Developing a multi-platform application is not so easy when you have to deal with hardware it seems... > >>>> > >>>> So I'm having this PrimitiveFailed error on MacOS, using the latest stable VM listed on the pharo-project website on Pharo20: > >>>> > >>>> PrimitiveFailed: primitive #primWritePortByName:from:startingAt:count: in SerialPort failed > >>>> > >>>> The same code works fine both in Gnu/Linux and Win32, so I'm guessing it's a problem with the serial plugin included in this VM. Any ideas? > >>>> > >>>> Cheers, > >>>> Bernat. > >>>> > >>>> -- > >>>> Bernat Romagosa. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Bernat Romagosa. > >>> > >> > > > > > > > > > > -- > Bernat Romagosa. > > > > -- > Bernat Romagosa.

Nov. 12, 2013

State of Flamel?

by Stephan Eggermont

Hi, I have some boring refactorings to do, so wanted to try out Flamel. Loading BleedingEdge in latest 3.0 doesnât work, it hangs. The SmartSuggestions in gisela/Flamel is older than the one in latest. Which combination should work / it would be nice to have a build in contributions? Stephan

Nov. 12, 2013

Re: [Pharo-users] Pharo Source Code

by Ignacio MatÃas Sniechowski

Also, You may want to take a look at Mariano's excellent post on compiling your on VM. http://marianopeck.wordpress.com/tag/vmmaker/ His blog is great and full of very interesting posts (thanks Mariano for sharing all this). cheers N. *Lic. Ignacio Sniechowski, MBA* On Tue, Nov 12, 2013 at 12:23 AM, Bahman Movaqar <Bahman(a)bahmanm.com> wrote: > Could someone please point me to the non-Smalltalk source code for Pharo > --I searched the website but couldn't find anything? > > TIA, > > -- > Bahman Movaqar (http://BahmanM.com) > > ERP Evaluation, Implementation & Deployment Consultant > PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) > >

Nov. 12, 2013

Re: [Pharo-users] Pharo Source Code

by Ignacio MatÃas Sniechowski

Hi What do you mean by non-Smalltalk "source code" for Pharo? :=) Pharo is 100% Smalltalk, you have to take a look at the VM's source code which is compiled and platform specific. There you will find the answers, like i.e. primitive tables, etc. Hope this answer your question. best regards Nacho *Lic. Ignacio Sniechowski, MBA* On Tue, Nov 12, 2013 at 12:23 AM, Bahman Movaqar <Bahman(a)bahmanm.com> wrote: > Could someone please point me to the non-Smalltalk source code for Pharo > --I searched the website but couldn't find anything? > > TIA, > > -- > Bahman Movaqar (http://BahmanM.com) > > ERP Evaluation, Implementation & Deployment Consultant > PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) > >

Nov. 12, 2013

Re: [Pharo-users] SerialPlugin on MacOS

by Bernat Romagosa

I can confirm I still got the same issue after replacing my VM by the vmLatest found at files.pharo.org/vm/pharo/mac under the name "Pharo-VM-mac-latest.zip" When trying to write a byte array to the serial port (aSerialPort nextPutAll: #[249]), SerialPort fails with a primitiveFailed: primitive #primWritePortByName:from:startingAt:count: The port does open correctly, though. 2013/11/11 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> > Thanks guys, > > files.pharo.org is down right now > > I'll try with a newer VM as soon as it's up again :) > > > 2013/11/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> >> On Nov 9, 2013, at 2:19 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >> > Luc proposed a pull request on github >> > - got validated by travis >> > - I integrated it into the master branch >> > - I pushed the changes to the develop branch >> > >> > so the vmLatest should include the fixes >> >> I like the process and that esteban releases some steam :) >> >> Stef >> >> > >> > On 2013-11-09, at 13:56, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >> >> Esteban >> >> >> >> we should organize some sessions where you show to people what you are >> doing and see how we >> >> should distribute and share load. >> >> >> >> Stef >> >> >> >> On Nov 9, 2013, at 12:29 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >> >> >>> Hi, >> >>> >> >>> it is "stable" but AFAIK it does not includes the latest fix for >> SerialPlugin. >> >>> So many things to do when I come back... :) >> >>> >> >>> Esteban >> >>> >> >>> >> >>> On Nov 5, 2013, at 8:27 AM, Bernat Romagosa < >> tibabenfortlapalanca(a)gmail.com> wrote: >> >>> >> >>>> Hi Luc, >> >>>> >> >>>> Smalltalk vm version reports: >> >>>> >> >>>> 'NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: >> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 >> >>>> NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: >> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 >> >>>> git://gitorious.org/cogvm/blessed.git Commit: >> 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 >> By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 >> >>>> ' >> >>>> >> >>>> It's the one listed as "latest" at the downloads section in >> pharo-project.org >> >>>> >> >>>> Cheers, >> >>>> Bernat. >> >>>> >> >>>> >> >>>> 2013/11/5 Luc Fabresse <luc.fabresse(a)gmail.com> >> >>>> >> >>>> >> >>>> 2013/11/5 Luc Fabresse <luc.fabresse(a)gmail.com> >> >>>> Hi Bernat, >> >>>> >> >>>> Which VM version? >> >>>> because MacOsX and Linux now use the same C part of the >> SerialPlugin. >> >>>> So if it works on Linux, it be the same on OsX. >> >>>> but I have not tried. >> >>>> >> >>>> yes we only use Linux here for serial stuff. >> >>>> >> >>>> >> >>>> do you use the right protName? >> >>>> >> >>>> Cheers, >> >>>> >> >>>> Luc >> >>>> >> >>>> >> >>>> 2013/11/5 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> >> >>>> Hi list, >> >>>> >> >>>> Developing a multi-platform application is not so easy when you have >> to deal with hardware it seems... >> >>>> >> >>>> So I'm having this PrimitiveFailed error on MacOS, using the latest >> stable VM listed on the pharo-project website on Pharo20: >> >>>> >> >>>> PrimitiveFailed: primitive >> #primWritePortByName:from:startingAt:count: in SerialPort failed >> >>>> >> >>>> The same code works fine both in Gnu/Linux and Win32, so I'm >> guessing it's a problem with the serial plugin included in this VM. Any >> ideas? >> >>>> >> >>>> Cheers, >> >>>> Bernat. >> >>>> >> >>>> -- >> >>>> Bernat Romagosa. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Bernat Romagosa. >> >>> >> >> >> > >> > >> >> >> > > > -- > Bernat Romagosa. > -- Bernat Romagosa.

Nov. 12, 2013

Re: [Pharo-users] Pharo Source Code

by phil＠highoctane.be

https://github.com/pharo-project/pharo-vm https://github.com/pharo-project/pharo-core (Smalltalk still) https://github.com/SquareBracketAssociates Phil

Nov. 12, 2013

Re: [Pharo-users] ImageMorph scaling

by Sean P. DeNigris

Sean P. DeNigris wrote > How would I get an ImageMorph to automatically resize inside a Spec UI? The following must be called /after/ the ImageMorph is added to the parent... imageMorph addFlexShell hResizing: #spaceFill; vResizing: #spaceFill. The resizing is a bit slow, but it works. HTH... ----- Cheers, Sean -- View this message in context: http://forum.world.st/ImageMorph-scaling-tp4719248p4721219.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Nov. 12, 2013

Pharo Source Code

by Bahman Movaqar

Could someone please point me to the non-Smalltalk source code for Pharo --I searched the website but couldn't find anything? 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/11/2013 22:52, Benjamin wrote: > I do not get the image, but I know what happened :) Oops! Corrected that. > > 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? > >> 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. >> 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. > >> 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 :-) 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