June 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Styling a Pharo UI application

by Nicolas Passerini

In the last couple of years I have participated in building quite a few web applications and we always have put a lot of emphasis in the user experience, navigation, in having pretty styled widgets, visual effects, smoth transitions, drag & drop, etc. Sometimes we used some out of the box styling or guidelines such as twitter bootstrap or google's material UI, others just bare javascript and css. I think it makes a lot of sense to be careful about this stuff if you want that your users feel comfortable and want to use your application. Many times a user *buys* your software because of it looking *modern *and often it is better to have less features that are comfortable to use instead of lots of features but that are difficult to find or understand. I have learnt the importance of having a *good* web designer (or even better a UX expert). That said, and even when Pharo has evolved a lot in the last few years, I think that there is still room to improve and much to gain both in Morphic as in Spec or Glamour (I do not have experience with Bric widgets). I think it would be wonderful to be able to combine the power and simplicity of Smalltalk with a UI that allows the flexibility that I can achieve in web applications. It is not enough to say "it is possible", it has to be easy, understandable, robust, well documented. A little example: drag & drop has been possible in javascript + css since a lot of time ago, but 10 o 15 years ago, when someone asked me for dnd, I always tried to avoid it. "Yes I can do it, but it will take a lot of time, and it will never *feel *like the dnd you are used to in your host OS." Now tools evolved and my perspective changed a lot about this kind of *goodies*, I even empower my designers to include that kind of stuff, we can do it fast, it is easy, think about the best UX and we will figure out how to build it. I think that it would be great to achieve the same level of confidence in Pharo. On Sat, Jun 25, 2016 at 9:54 PM, Tommaso Dal Sasso < tommaso.dalsasso(a)gmail.com> wrote: > Just a couple of thoughts from the last days coding GUI in Pharo: > > I don't think that the Spec vs. Morphic vs. Bric has really to do with > "ugliness". > True, the Glamour team is doing an amazing work with providing an > interface that is more pleasing and friendly, but the point for me is not > how Spec or Morphic look. I don't use a library because its widgets look > cool, I use it because the tools I build with it fit in the system i.e., > they look like the rest of the system and respect its settings (provided > that borders, spacing and alignment of the labels are aligned). How the > system and your application look like, is responsibility of a theme manager. > > The beauty that I am looking for as a developer for has to do with the > code and the API. I consider important how fast I am able to prototype a > working example --in this Spec is excellent-- and how much I can extend the > code to refine my application --in this Spec is really hard to use--. > > These last days I spent a lot of time with Morphic and later with Bric. > What I noticed is that Morphic is *really* powerful, but to define a > minimal working example you have to write a lot of code to take care of the > details. On the other hand, Bric abstracts many of these details, allowing > for a more pleasant looking result in less time. > > I now understand why I hear saying a lot that Morphic got out of hand: you > have so many options that one is not not able anymore to discern the > essential ones from the once-in-a-lifetime settings. Since our main source > of documentation comes from inspecting the code, and iterate over a list of > methods requires a human at least linear time (who knows if we can improve > this), a class like Morph becomes a nightmare. > Tommaso > > > > On 25/06/16 16:45, Peter UhnÃ¡k wrote: > > > > On Sat, Jun 25, 2016 at 2:12 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > >> >> >> On Jun 24, 2016, at 19:00, Yuriy Tymchuk < <yuriy.tymchuk(a)me.com> >> yuriy.tymchuk(a)me.com> wrote: >> >> >> [â¦] >> >> I know that we donât have designers to inverted something cool, but what >> GT teem did is they took Google material design guidelines and implemented >> widgets in Pharo, so if I use them it will be pleasant to the userâs eye. >> Otherwise we are saying how cool Pharo is and how good we are, but a random >> Android developer can build nicer interface because they have this sexy >> widgets. >> >> >> Just to understand: are you saying that a better set of underlying >> widgets for Spec would solve the âuglinessâ issue for you? >> > > Then this would not a Spec issue, but Morphic/Bloc one. > > >> >> And yes, in the end for me the big turn off with Spec is the direct >> example with Tommaso. You know that something is wrong, so you want to >> change the size of a font. And then you ask on the mailing list and it >> turns out that itâs not that easy and you have to either hack something, or >> submit patch to Specâ¦ In the end Iâve decided to use plain morphic because >> at least there I can change whatever I want. >> >> >> So, again to understand: you want to be able to change the font size of >> any widget from within the application, ignoring the System preference >> settings? >> > > You should be able to do that even now with #whenBuiltDo: > > But it's true that Spec doesn't really have any API for styling, and if > something is customizable (some colors for some widgets, some other > options), it is quite haphazard, similarly for drag and drop (there was a > brief discussion about this about a month ago, but we don't have a solution) > > >

June 25, 2016

Re: [Pharo-users] Styling a Pharo UI application

by Tommaso Dal Sasso

Just a couple of thoughts from the last days coding GUI in Pharo: I don't think that the Spec vs. Morphic vs. Bric has really to do with "ugliness". True, the Glamour team is doing an amazing work with providing an interface that is more pleasing and friendly, but the point for me is not how Spec or Morphic look. I don't use a library because its widgets look cool, I use it because the tools I build with it fit in the system i.e., they look like the rest of the system and respect its settings (provided that borders, spacing and alignment of the labels are aligned). How the system and your application look like, is responsibility of a theme manager. The beauty that I am looking for as a developer for has to do with the code and the API. I consider important how fast I am able to prototype a working example --in this Spec is excellent-- and how much I can extend the code to refine my application --in this Spec is really hard to use--. These last days I spent a lot of time with Morphic and later with Bric. What I noticed is that Morphic is *really* powerful, but to define a minimal working example you have to write a lot of code to take care of the details. On the other hand, Bric abstracts many of these details, allowing for a more pleasant looking result in less time. I now understand why I hear saying a lot that Morphic got out of hand: you have so many options that one is not not able anymore to discern the essential ones from the once-in-a-lifetime settings. Since our main source of documentation comes from inspecting the code, and iterate over a list of methods requires a human at least linear time (who knows if we can improve this), a class like Morph becomes a nightmare. Tommaso On 25/06/16 16:45, Peter UhnÃ¡k wrote: > > > On Sat, Jun 25, 2016 at 2:12 PM, Johan Fabry <jfabry(a)dcc.uchile.cl > <mailto:jfabry@dcc.uchile.cl>> wrote: > > > >> On Jun 24, 2016, at 19:00, Yuriy Tymchuk <yuriy.tymchuk(a)me.com >> <mailto:yuriy.tymchuk@me.com>> wrote: > > [â¦] > >> I know that we donât have designers to inverted something cool, >> but what GT teem did is they took Google material design >> guidelines and implemented widgets in Pharo, so if I use them it >> will be pleasant to the userâs eye. Otherwise we are saying how >> cool Pharo is and how good we are, but a random Android developer >> can build nicer interface because they have this sexy widgets. > > Just to understand: are you saying that a better set of underlying > widgets for Spec would solve the âuglinessâ issue for you? > > > Then this would not a Spec issue, but Morphic/Bloc one. > > >> And yes, in the end for me the big turn off with Spec is the >> direct example with Tommaso. You know that something is wrong, so >> you want to change the size of a font. And then you ask on the >> mailing list and it turns out that itâs not that easy and you >> have to either hack something, or submit patch to Specâ¦ In the >> end Iâve decided to use plain morphic because at least there I >> can change whatever I want. > > So, again to understand: you want to be able to change the font > size of any widget from within the application, ignoring the > System preference settings? > > > You should be able to do that even now with #whenBuiltDo: > > But it's true that Spec doesn't really have any API for styling, and > if something is customizable (some colors for some widgets, some other > options), it is quite haphazard, similarly for drag and drop (there > was a brief discussion about this about a month ago, but we don't have > a solution)

June 25, 2016

Re: [Pharo-users] Fogbugz 13260 reappears?

by Nicolai Hess

issue 18615 <https://pharo.fogbugz.com/f/cases/18615/Can-not-access-named-temp-vector-fr…> Can not access named temp vector from within optimized block scope put a fix (with a new test case for this issue) in the inbox. 2016-06-24 23:22 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > Can you try if this is working with this change (attach .st) > I'll open an issue and do some more tests. > > > > 2016-06-24 21:56 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > >> Hi Nicolai, >> >> On Fri, Jun 24, 2016 at 09:15:41PM +0200, Nicolai Hess wrote: >> > >> > >> > 2016-06-24 20:57 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: >> > >> > Hi All, >> > >> > I'm currently regularly hitting an issue with the debugger where >> > inspecting a temporary variable shows the string "error obtaining >> field >> > value" rather than the actual value. >> > >> > >> > I am not sure if this is the same error. We had a couple of issues with >> reading >> > different kinds of variables in the debugger, >> > and some fix work for one access and introduces new issues for other >> kinds of >> > variables :( >> > >> > Most things are working now, but we have still an issue in Pharo 6.0 >> with block >> > local vars in optimized blocks (case 17343) >> > But I think this one is a different issue. >> > Before we open a new issue, it would be good if I can reproduce this >> one. >> > Give me some time ( or some hints) what I need to reproduce this) >> >> Thanks for your reply. >> >> I've created a class that reproduces the problem: >> >> >> 'From Pharo5.0 of 16 April 2015 [Latest update: #50757] on 24 June 2016 >> at 9:51:07.97744 pm'! >> Object subclass: #AKGDebuggerBug >> instanceVariableNames: '' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'AKG-Bugs'! >> >> !AKGDebuggerBug methodsFor: 'demo' stamp: 'AlistairGrant 6/24/2016 21:49'! >> method1 >> "AKGDebuggerBug new method1" >> self method2: [ 'hello world' ].! ! >> >> !AKGDebuggerBug methodsFor: 'demo' stamp: 'AlistairGrant 6/24/2016 21:50'! >> method3: aBlock >> >> | result | >> >> [ result := aBlock value ] value. >> ^result.! ! >> >> !AKGDebuggerBug methodsFor: 'demo' stamp: 'AlistairGrant 6/24/2016 21:50'! >> method2: aBlock >> | result | >> [ result := aBlock numArgs = 1 >> ifTrue: [ aBlock value: self ] >> ifFalse: [ aBlock value ] ] value. >> ^ result! ! >> >> >> Debugging "AKGDebuggerBug new method1" and stepping through to where >> result is assigned in method2: will trigger the problem. >> >> Note that modifying method1 to call method3: will not reproduce the >> problem. >> >> >> Thanks, >> Alistair >> >> >> >

June 25, 2016

Re: [Pharo-users] Styling a Pharo UI application

by Dimitris Chloupis

Forgot to add that I am slowly building my own API that will make it easier for me to create specific custom elements, for example I have created glow buttons (glow when you hover the mouse over it and when activated). On Sat, Jun 25, 2016 at 7:50 PM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > because that is how styling works, you define how the GUI should look > instead of opting for a generic look and because if you dont decide for the > font size , user is unlikely that will bother with setting and options > > he probably end up saying > > "No thanks, next please" > > Of course that does not mean you should not give users some freedom of > choice. > > Yuriy I see now your point and I agree, an API that makes it easy to style > your GUI is more than welcomed indeed. Of course that have made me wonder > that maybe is better to take my GUI to something like bootstrap or QT and > leave Pharo for the logic stuff. > > On Sat, Jun 25, 2016 at 5:53 PM kmo <voxkmp(a)gmail.com> wrote: > >> Why would anyone think that a developer would/ not /want to be able to >> change >> the font size? >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Styling-a-Pharo-UI-application-tp4902498p4903255.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >>

June 25, 2016

Re: [Pharo-users] Styling a Pharo UI application

by Dimitris Chloupis

because that is how styling works, you define how the GUI should look instead of opting for a generic look and because if you dont decide for the font size , user is unlikely that will bother with setting and options he probably end up saying "No thanks, next please" Of course that does not mean you should not give users some freedom of choice. Yuriy I see now your point and I agree, an API that makes it easy to style your GUI is more than welcomed indeed. Of course that have made me wonder that maybe is better to take my GUI to something like bootstrap or QT and leave Pharo for the logic stuff. On Sat, Jun 25, 2016 at 5:53 PM kmo <voxkmp(a)gmail.com> wrote: > Why would anyone think that a developer would/ not /want to be able to > change > the font size? > > > > -- > View this message in context: > http://forum.world.st/Styling-a-Pharo-UI-application-tp4902498p4903255.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

June 25, 2016

Image freezes on Linux if it was previously saved on Windows

by Maximiliano Tabacman

Hi. I am not sure if this issue is known, or what files to provide to help fix it.In the latest image (60112, but my guess is that this will happen with all Pharo 6 images) if I download a clean latest image, start Pharo on Windows, save the image, then copy it to a Linux environment, and try to start it, the image freezes even before displaying the workspace (I get an unresponsive black and white box in Linux, only killable through xkill command).I am sure this did not happen back with Pharo 5.If I output "./pharo Image.image > log.txt" I end up with a huge file since there seems to be an infinite loop while trying to determine the FileStore to use. The first lines of this output file, before going into the loop, are: out of memory /home/theUser/Downloads/Pharo6/pharopharo VM version: 5.0 #1 Tue Jun 21 12:37:33 CEST 2016 gcc 4.6.3 [Production Spur ITHB VM]Built from: CoInterpreter VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016With: StackToRegisterMappingCogit VMMaker.oscog-HolgerHansPeterFreyther.1880 uuid: 16138eb3-2390-40f5-a6c8-15f0494936f8 Jun 21 2016Revision: https://github.com/pharo-project/pharo-vm.git Commit: 9638b0190a9fc01479bfb752becd96edfd253c8c Date: 2016-06-21 12:29:26 +0200 By: GitHub <noreply(a)github.com> Jenkins build #594Build host: Linux pharo-linux 3.2.0-31-generic-pae #50-Ubuntu SMP Fri Sep 7 16:39:45 UTC 2012 i686 i686 i386 GNU/Linuxplugin path: /home/theUser/Downloads/Pharo6/ [default: /home/theUser/Downloads/Pharo6/] C stack backtrace & registers:*./pharo[0x80c133c]./pharo(error+0x17)[0x80c1547]./pharo[0x809a26c]./pharo[0x809a301]./pharo[0x809a53d]./pharo[0x809bf13]./pharo[0x80a6b61]./pharo[0x80ae4ca]./pharo[0x80ae6ba]./pharo[0x80af07f]./pharo[0x80afcf4]./pharo(ceSendsupertonumArgs+0x1d8)[0x80b0098][0x990008d][0x990de03][0x99090af][0x9900b70][0x990dda3][0x990de03][0x99090af][0x9900b40][0xffe95808] Smalltalk stack dump:0xffe9e9f8 I MacStore class(Class)>subclassesDo: 0xa3393f0: a(n) MacStore class0xffe9ea14 M MacStore class(Behavior)>allSubclassesDo: 0xa3393f0: a(n) MacStore class0xffe9ea34 M [] in UnixStore class(Behavior)>allSubclassesDo: 0xa339380: a(n) UnixStore class0xffe9ea58 M Array(SequenceableCollection)>do: 0x9ded798: a(n) Array0xffe9ea7c I UnixStore class(Class)>subclassesDo: 0xa339380: a(n) UnixStore class0xffe9ea98 M UnixStore class(Behavior)>allSubclassesDo: 0xa339380: a(n) UnixStore class0xffe9eab8 M [] in DiskStore class(Behavior)>allSubclassesDo: 0xa339310: a(n) DiskStore class0xffe9eadc M Array(SequenceableCollection)>do: 0x9ded710: a(n) Array0xffe9d7c8 I DiskStore class(Class)>subclassesDo: 0xa339310: a(n) DiskStore class0xffe9d7e4 M DiskStore class(Behavior)>allSubclassesDo: 0xa339310: a(n) DiskStore class0xffe9d800 M DiskStore class>activeClass 0xa339310: a(n) DiskStore class0xffe9d81c M DiskStore class>currentFileSystem 0xa339310: a(n) DiskStore class0xffe9d834 M DiskStore class>current 0xa339310: a(n) DiskStore class0xffe9d84c M DiskStore class>delimiter 0xa339310: a(n) DiskStore class0xffe9d864 M DiskStore(FileSystemStore)>delimiter 0x9deb478: a(n) DiskStore0xffe9d884 M DiskStore(FileSystemStore)>pathFromString: 0x9deb478: a(n) DiskStore0xffe9d8a4 M DiskStore>defaultWorkingDirectory 0x9deb478: a(n) DiskStore0xffe9d8bc M FileSystem>initializeWithStore: 0x9deb488: a(n) FileSystem0xffe9d8dc M FileSystem class>store: 0xa2e2978: a(n) FileSystem class0xffe9d8f8 M DiskStore class>currentFileSystem 0xa339310: a(n) DiskStore class ... and so on...from #currentFileSystem to #store: and again... Thanks for any feedback and/or insight on how I should proceed to avoid this from happening, or what bug should I monitor to know when this might be fixed.

June 25, 2016

Re: [Pharo-users] Styling a Pharo UI application

by Peter UhnÃ¡k

On Sat, Jun 25, 2016 at 2:12 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > > > On Jun 24, 2016, at 19:00, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > [â¦] > > I know that we donât have designers to inverted something cool, but what > GT teem did is they took Google material design guidelines and implemented > widgets in Pharo, so if I use them it will be pleasant to the userâs eye. > Otherwise we are saying how cool Pharo is and how good we are, but a random > Android developer can build nicer interface because they have this sexy > widgets. > > > Just to understand: are you saying that a better set of underlying widgets > for Spec would solve the âuglinessâ issue for you? > Then this would not a Spec issue, but Morphic/Bloc one. > > And yes, in the end for me the big turn off with Spec is the direct > example with Tommaso. You know that something is wrong, so you want to > change the size of a font. And then you ask on the mailing list and it > turns out that itâs not that easy and you have to either hack something, or > submit patch to Specâ¦ In the end Iâve decided to use plain morphic because > at least there I can change whatever I want. > > > So, again to understand: you want to be able to change the font size of > any widget from within the application, ignoring the System preference > settings? > You should be able to do that even now with #whenBuiltDo: But it's true that Spec doesn't really have any API for styling, and if something is customizable (some colors for some widgets, some other options), it is quite haphazard, similarly for drag and drop (there was a brief discussion about this about a month ago, but we don't have a solution)

June 25, 2016

Re: [Pharo-users] Pharo 5, seaside 3.2 and magritte 3

by francescoagati

moved to seaside list. Thanks -- View this message in context: http://forum.world.st/Pharo-5-seaside-3-2-and-magritte-3-tp4902903p4903257.… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 25, 2016

Re: [Pharo-users] Styling a Pharo UI application

by kmo

Why would anyone think that a developer would/ not /want to be able to change the font size? -- View this message in context: http://forum.world.st/Styling-a-Pharo-UI-application-tp4902498p4903255.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 25, 2016

Re: [Pharo-users] Styling a Pharo UI application

by Johan Fabry

> On Jun 24, 2016, at 19:00, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: [â¦] > I know that we donât have designers to inverted something cool, but what GT teem did is they took Google material design guidelines and implemented widgets in Pharo, so if I use them it will be pleasant to the userâs eye. Otherwise we are saying how cool Pharo is and how good we are, but a random Android developer can build nicer interface because they have this sexy widgets. Just to understand: are you saying that a better set of underlying widgets for Spec would solve the âuglinessâ issue for you? Because, fundamentally this should be doable. (Now we would need somebody to actually do it, thatâs another question :-/ ) > And yes, in the end for me the big turn off with Spec is the direct example with Tommaso. You know that something is wrong, so you want to change the size of a font. And then you ask on the mailing list and it turns out that itâs not that easy and you have to either hack something, or submit patch to Specâ¦ In the end Iâve decided to use plain morphic because at least there I can change whatever I want. So, again to understand: you want to be able to change the font size of any widget from within the application, ignoring the System preference settings? -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org <http://emailcharter.org/> . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

June 25, 2016