July 2014 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] e5a616: 40103

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: e5a616dc7ed35ef33ddfa7f3c311265509dc8485 https://github.com/pharo-project/pharo-core/commit/e5a616dc7ed35ef33ddfa7f3… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-07-20 (Sun, 20 Jul 2014) Changed paths: M GroupManagerUI.package/DialogGroupManagerUI.class/instance/tree/buildGroupsTree.st M Morphic-Base.package/MorphicModel.class/definition.st R Morphic-Base.package/MorphicModel.class/instance/as yet unclassified/hasYellowButtonMenu.st R Morphic-Base.package/MorphicModel.class/instance/drag and drop/isOpen.st R Morphic-Base.package/MorphicModel.class/instance/geometry/newBounds_.st R Morphic-Base.package/MorphicModel.class/instance/initialization/initialize.st M Morphic-Base.package/MorphicModel.class/instance/initialization/model_accessor_.st M Morphic-Base.package/MorphicModel.class/instance/menu/addCustomMenuItems_hand_.st R Morphic-Base.package/MorphicModel.class/instance/menu/closeToEdits.st A Morphic-Base.package/MorphicModel.class/instance/menu/hasYellowButtonMenu.st R Morphic-Base.package/MorphicModel.class/instance/menu/openToEdits.st R MorphicTests.package/MCPTest.class/instance/tests/testIsMorphicModel.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script103.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40103.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Settings-Tools.package/DebugSystemSettings.class/class/settings/debugSettingsOn_.st R Spec-Debugger.package/SpecDebugger.class/class/settings/defaultLogFileName.st R Spec-Debugger.package/SpecDebugger.class/class/settings/logFileName.st R Spec-Debugger.package/SpecDebugger.class/class/settings/logFileName_.st M System-FilePackage.package/PseudoClass.class/instance/filein%2Ffileout/fileOutDefinitionOn_.st A System-FilePackage.package/TextDiffBuilder.class/class/settings/differatorSettingsOn_.st M System-Support.package/SmalltalkImage.class/definition.st A System-Support.package/SmalltalkImage.class/instance/log/defaultLogFileName.st A System-Support.package/SmalltalkImage.class/instance/log/logFileName.st A System-Support.package/SmalltalkImage.class/instance/log/logFileName_.st M System-Support.package/SmalltalkImage.class/instance/miscellaneous/openLog.st M Tests.package/SmalltalkImageTest.class/instance/helpers/writeToLogWithFileNamed_.st M Tool-Finder.package/MethodFinder.class/instance/initialize/initialize.st Log Message: ----------- 40103 13598 MorphicModel ivar open: not used https://pharo.fogbugz.com/f/cases/13598 13602 SmalltalkImage >> #openLog dependent on Tools https://pharo.fogbugz.com/f/cases/13602 13601 Add in group DNU https://pharo.fogbugz.com/f/cases/13601 13600 DiffereratorSettings --> move to TextDiffBuilder https://pharo.fogbugz.com/f/cases/13600 http://files.pharo.org/image/40/40103.zip

July 20, 2014

Re: [Pharo-dev] UITheme experience (please read) :)

by Nicolai Hess

2014-07-19 23:18 GMT+02:00 stepharo <stepharo(a)free.fr>: > I continued the experiment with PluggableButtonMorph and > - we should remove some duplicated code in UItheme hiearchy :) > - if we do not share behavior in themers (accross widgets) we will > have duplicated code and logic. > The first thing that comes to my mind is the question: What do we try to solve with UITheme, or what is the problem, UITheme is supposed to be the solution? Consistent UI, themed widgets, easy to producing UIs? > > Side note: > > When I see the amount of messages sent to open a morph and the complexity > of the theme in addition > to Morphic intrinsic complexity it is obvious that it cannot be fast. > Far too complex. I started to copy simpleButtonMorph and clean it just to > understand. > I would like to do the same for the widgets but this is a daunting task. > > I really think that Bloc will come to the rescue because simplifying is > not an easy task either. > Polymorph is complex and added a lot of hacks on top (because it was > designed as a layer). > +1 > > Not talking about TextMorph and StringMorph different API. > Simple API like label:font: are bogus. Widgets displaying text should have > font instance variable > I don't think, this is the real problem or that a font instance variable would solve this. This is how a simple StringMorph (or TextMorph) and a Label (as part of a widget) differ. For example: a simple Button. Currently we have that PluggableButtonMorph. It is a Morph with some shape, colour, border, label and behavior. The label is actually a TextMorph to heavyvweight for a simple button label. Anyway. If we move the attributes like background color, border style, label text attributes like font, color and emphasis to the theme manager, what is left for the ButtonMorph? Text contents and behaviour - just that. A UI framework should provide "things" that play exactly this role. ButtonWidget: Hi, I am a Button, give me some Label and Actions. > > I will try to make the XPPluggableButtonMorph works in Pharo30 and > DarkTheme and let you know. > > The code is published in > SD > PetitsBazars/ StefArchitecture something. > > I will continue to split Polymorph and read code around and clean what I > can see. > > Stef > > > > Definitely! > > My post was about the second point. > > Doru > > > On Sat, Jul 19, 2014 at 5:22 PM, stepharo <stepharo(a)free.fr> wrote: > >> Hi doru >> >> I think that there are two points: >> - moving creation API from theme to classes (I'm doing this one to >> also create example of the widgets) >> Smalltalk ui theme newButton.... sucks :) >> - rethinking the theming architecture >> >> Stef >> > +1 A Theme provides attributes for categories like ButtonLabelFont, ButtonLabelColour. But it does not actually provides the Morphs (no ButtonLabelMorph, no CheckBoxMorph). Otherwise I have to call ... theme createX, ... theme createY.... That way the theme manager would play two roles: 1. for the developer: a widget factory 2. for the widgets : a theme manager. Instead the developer needs an UI widget factory, or a widget library. These widgets doesn't need to be Morphs, at least they don't play this role. (Morphs somehow contrary to "constistent UI", they are to powerful). The widgets don't care how to draw themself. They delegate. For example, widgets displaying text. They know to whom they forward. But they don't *hold* the theme dependent attributes - like fonts. Either they or their delegates call the appropriate attribute from the theme manager. So, a ButtonWidget for example, calls its uidelegate to draw himself (my label, my state (active, inactive, selected, pressed ...). The ui delegate calls theme manager for the font, color, emphasis. Yes, this may create a another parallel ui delegate hierarchy next to the widget hierarchy. Maybe all this *can* be implemented within the same class (PluggableButtonMorph), but the crucial point is: I (the app developer) need a consistant API, so that I don't have to deal with all of that. I just want to see this thing that plays the role I am interested in: a Button with some label and some actions. nicolai > >> >> >> On 19/7/14 14:16, Tudor Girba wrote: >> >> Hi Stef, >> >> I do not have time right now to go into details, so take this just as >> an acknowledgment that I have an interest in this topic :). >> >> My initial proposal that I sent to this list a while ago (some details >> are provided here: >> http://www.humane-assessment.com/blog/a-pharo-refactoring-story-adding-them…) >> went exactly in the direction of a ThemeStrategy that I call Themer. We >> used it already for several morphs around Glamour to play with the >> boundaries and it works well. >> >> I still think we need the UITheme but that should only provide a list >> of themers without any implementation. Like that we can package a uniform >> look throughout the whole environment. However, we should still be able to >> override the themer at the level of morph for quick prototyping and custom >> needs. >> >> I will get back to you. >> >> Cheers, >> Doru >> >> >> >> >> On Sat, Jul 19, 2014 at 9:15 AM, stepharo <stepharo(a)free.fr> wrote: >> >>> Hi guys >>> >>> I want to lower the importance of UITheme >>> >>> - first the factory API should be pushed in the respective classes >>> ie: >>> >>> UItheme>>newButtonIn: aThemedMorph for: aModel getState: stateSel >>> action: actionSel arguments: args getEnabled: enabledSel getLabel: labelSel >>> help: helpText >>> "Answer a new button." >>> >>> |b| >>> b := PluggableButtonMorph >>> on: aModel >>> getState: stateSel >>> action: actionSel >>> label: labelSel. >>> b >>> theme: self; >>> label: ' ' font: self buttonFont; >>> update: labelSel; >>> arguments: (args ifNil: [{b}]); >>> getEnabledSelector: enabledSel; >>> cornerStyle: (self buttonCornerStyleIn: aThemedMorph); >>> hResizing: #shrinkWrap; >>> vResizing: #shrinkWrap; >>> setBalloonText: helpText; >>> extent: b minExtent; >>> removeProperty: #theme. >>> ^b >>> >>> >>> should be transformed into >>> >>> PluggableButtonMorph>>newButtonFor: aModel getState: stateSel action: >>> actionSel arguments: args getEnabled: enabledSel label: label help: helpText >>> "Answer a new button." >>> >>> | b | >>> b := self on: aModel getState: stateSel action: actionSel. >>> b >>> arguments: (args ifNil: [{b}]); >>> hResizing: #shrinkWrap; >>> vResizing: #shrinkWrap; >>> label: label ; >>> getEnabledSelector: enabledSel; >>> setBalloonText: helpText; >>> extent: b minExtent; >>> hResizing: #rigid; >>> vResizing: #rigid. >>> ^b >>> >>> >>> Now I do not want to lose the theme so I'm working on that. >>> >>> - second I wanted to experiment with the theming architecture >>> >>> I did the following >>> >>> XPGrowlMorph >>> >>> Object < XPGrowlThemeStrategy >>> parentTheme := UITheme new >>> >>> XPGrowlThemeStrategy < XPGrowlDarkTheme >>> parentTheme := PharoDarkTheme new >>> growFillColor: >>> Color white >>> XPGrowlThemeStrategy < XPGrowlPharo30Theme >>> parentTheme := Pharo30Theme new >>> growFillColor: >>> Color red >>> minTextSize >>> ^ parentTheme minTextSize >>> >>> I did the same with XPSimpleButtonMorph >>> >>> >>> Conclusion: >>> >>> - Do we gain from object inheritance vs class? >>> I do not think that we want to change dynamical the theme chain >>> So I will make the widget strategy class from their theme >>> >>> PharoDarkTheme < XPGrowlDarkTheme >>> >>> Pharo30Theme < XPGrowlPharo30Theme >>> >>> - cons we may have duplicated behavior accross theme => traits? >>> >>> - Do we gain having widgets specific theming strategy >>> - cons this generate a lot of classes >>> so we will see >>> >>> + with inheritance we reuse a lot >>> + probably we can reduce the API of UItheme (see below) >>> >>> >>> - Can we reduce the API of UITheme >>> buttonBorderColor >>> listBorderColor >>> â¦. >>> >>> Yes probably doing >>> >>> Pharo3Theme>>buttonBorderColor >>> >>> => >>> >>> Pharo30ButtonStrategy>>borderColor >>> >>> -> but should be experimented >>> >>> >>> - From a widget point of view, if we want to have possibility to see the >>> same widgets in different theme at the same time >>> this raises the problem of the injection (or recomputation) of the theme >>> values. >>> >> Is there any usecase for "using the same widget with a different theme"? > Example below: >>> We want to specify a theme but the new is calling initialize and the >>> values are computed with a default/current theme. >>> >>> >>> XPGrowlMorph new >>> theme: XPPharo3ThemeStrategy new; >>> label: 'The time' contents: TimeStamp now; >>> skin; >>> openInWorld. >>> >>> XPGrowlMorph new >>> theme: XPDarkThemeStrategy new; >>> label: 'The time' contents: TimeStamp now; >>> openInWorld. >>> >>> => Question is it worth because with a default theme we would have it >>> nearly working. >>> >>> Stef >>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > >

July 20, 2014

Re: [Pharo-dev] Memory limit problems on Windows VM

by Andres Valloud

Does the VM make a single memory allocation to load the image file? On 7/19/14 17:20 , Ben Coman wrote: > Andres Valloud wrote: >> Keep in mind that, depending on how images are loaded, you won't be >> able to load images larger than about 2gb... you might want to test that. > > Can you hint what those scenarios are? > cheers -ben > >> >> On 7/19/14 13:39 , Tudor Girba wrote: >>> Wow! I will certainly try this patch. >>> >>> Doru >>> >>> >>> On Fri, Jul 18, 2014 at 5:15 PM, Oscar E. A. CallaÃº >>> <oscar.apollo(a)gmail.com <mailto:oscar.apollo@gmail.com>> wrote: >>> >>> Well, >>> >>> I fixed the problem by modifying the Pharo.exe file with the 4GB >>> patch program (http://ntcore.com/4gb_patch.php) >>> >>> As mentioned before, I think the best solution is that Pharo vms >>> must be compiled with the flag LARGEADDRESSAWARE, so more memory >>> space is enabled for 64bits Windows OSs. >>> >>> Thanks guys >>> >>> Oscar >>> >>> >>> On Thu, Jul 17, 2014 at 11:03 PM, Andres Valloud >>> <avalloud(a)smalltalk.comcastbiz.net >>> <mailto:avalloud@smalltalk.comcastbiz.net>> wrote: >>> >>> I worked on that switch before, and IIRC it's just a linker >>> switch that marks executables a certain way. So, if you have >>> imagecfg.exe handy... >>> >>> http://support.microsoft.com/__kb/297812 >>> <http://support.microsoft.com/kb/297812> >>> >>> >>> On 7/17/14 19:25 , Oscar E. A. CallaÃº wrote: >>> >>> Well. It seems that Pharo vms must be compiled with that >>> option :/ >>> >>> Cheers >>> >>> >>> On Wed, Jul 16, 2014 at 8:44 PM, <btc(a)openinworld.com >>> <mailto:btc@openinworld.com> >>> <mailto:btc@openinworld.com <mailto:btc@openinworld.com>>> >>> wrote: >>> >>> __ >>> Eliot Miranda wrote: >>> >>> >>> >>> >>> On Wed, Jul 16, 2014 at 2:21 PM, Oscar E. A. CallaÃº >>> <oscar.apollo(a)gmail.com >>> <mailto:oscar.apollo@gmail.com> >>> <mailto:oscar.apollo@gmail.com >>> <mailto:oscar.apollo@gmail.com>__>> wrote: >>> >>> Hi, >>> >>> I'm using Windows 8.1 (update1) 64bits with 4GB >>> of physical >>> RAM. I only need 1.5GB of RAM, so I think I >>> don't need to >>> configure my OS to take /3GB of RAM. >>> >>> >>> Well my experience (and others) is that one can't >>> grow the heap >>> much above 1.1 Gb without using the /3Gb switch on >>> Windows XP. I >>> can't talk for 8.1. But if 8.x also limits memory >>> to 2Gb/process >>> unless the /3Gb switch is in effect then yes, >>> you'll need to use >>> the /3Gb switch. >>> >>> HTH >>> Eliot >>> >>> >>> Cheers >>> >>> On Wednesday, July 16, 2014, Eliot Miranda >>> wrote: >>> >>> Hi Oscar, >>> >>> >>> On Wed, Jul 16, 2014 at 9:11 AM, Oscar E. >>> A. CallaÃº >>> <oscar.apollo(a)gmail.com >>> <mailto:oscar.apollo@gmail.com>> wrote: >>> >>> Hi guys, >>> >>> I'm running some experiments in >>> Pharo. My data >>> is aprox. 1.3GB. When I load my image >>> on Mac, >>> everything works perfectly. But, when I >>> try to load >>> the same image on Windows, I get this >>> error: >>> >>> Unable to commit memory (1326649344 >>> bytes requested) >>> >>> I tried the Pharo VM, cogMT and NBcog >>> with and >>> without the option >>> >>> AddressSpaceLimit = 2048 >>> >>> in the ini file >>> >>> Please help. >>> >>> What OS are you using? Have you read e.g. >>> http://msdn.microsoft.com/en-__us/library/windows/hardware/__dn613959(v=vs.… >>> >>> <http://msdn.microsoft.com/en-us/library/windows/hardware/dn613959(v=vs.85).…> >>> >>> >>> <http://msdn.microsoft.com/en-__us/library/windows/hardware/__dn613959%28v=v… >>> >>> <http://msdn.microsoft.com/en-us/library/windows/hardware/dn613959%28v=vs.85…>>? >>> >>> >>> >>> >>> Here are some additional links... >>> >>> /LARGEADDRESSAWARE (Handle Large Addresses) >>> http://msdn.microsoft.com/en-__us/library/wz223b1z.aspx >>> <http://msdn.microsoft.com/en-us/library/wz223b1z.aspx> >>> >>> Memory Limits for Windows and Windows Server Releases >>> http://msdn.microsoft.com/en-__us/library/windows/desktop/__aa366778(v=vs.8… >>> >>> <http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).a…> >>> >>> I learnt something new reading this article. For Win >>> 8.1 64-bit, the >>> /3GB switch is not applicable or required. However the >>> /LARGEADDRESSAWARE linker option is critical for both >>> 32-bit and >>> 64-bit VMs. Its only the default setting that changes >>> between >>> compiling 32-bit or 64-bit applications. Some >>> extracts... >>> >>> Limits on memory and address space depend on whether >>> the >>> IMAGE_FILE_LARGE_ADDRESS_AWARE value of the >>> LOADED_IMAGE structure >>> and 4-gigabyte tuning (4GT) are in use. >>> IMAGE_FILE_LARGE_ADDRESS_AWARE is set or cleared by >>> using the >>> /LARGEADDRESSAWARE linker option. 4-gigabyte tuning >>> (4GT), also >>> known as application memory tuning, or the /3GB switch, >>> is a >>> technology (**only applicable to 32 bit systems**) that >>> alters the >>> amount of virtual address space available to user mode >>> applications. >>> >>> On x64-bit MS Windows, User-Mode virtual address space >>> for each >>> 32-bit process >>> 4 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE set >>> 2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared >>> (default) >>> >>> On x64-bit MS Windows, User-Mode virtual address space >>> for each >>> 64-bit process >>> 8 TB With IMAGE_FILE_LARGE_ADDRESS_AWARE set (default): >>> 2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared >>> >>> cheers -ben >>> >>> >>> -- >>> best, >>> Eliot >>> >>> >>> >>> >>> -- >>> best, >>> Eliot >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> www.tudorgirba.com <http://www.tudorgirba.com> >>> >>> "Every thing has its own flow" >> >> > > > . >

July 20, 2014

Re: [Pharo-dev] Memory limit problems on Windows VM

by Ben Coman

Andres Valloud wrote: > Keep in mind that, depending on how images are loaded, you won't be > able to load images larger than about 2gb... you might want to test that. Can you hint what those scenarios are? cheers -ben > > On 7/19/14 13:39 , Tudor Girba wrote: >> Wow! I will certainly try this patch. >> >> Doru >> >> >> On Fri, Jul 18, 2014 at 5:15 PM, Oscar E. A. CallaÃº >> <oscar.apollo(a)gmail.com <mailto:oscar.apollo@gmail.com>> wrote: >> >> Well, >> >> I fixed the problem by modifying the Pharo.exe file with the 4GB >> patch program (http://ntcore.com/4gb_patch.php) >> >> As mentioned before, I think the best solution is that Pharo vms >> must be compiled with the flag LARGEADDRESSAWARE, so more memory >> space is enabled for 64bits Windows OSs. >> >> Thanks guys >> >> Oscar >> >> >> On Thu, Jul 17, 2014 at 11:03 PM, Andres Valloud >> <avalloud(a)smalltalk.comcastbiz.net >> <mailto:avalloud@smalltalk.comcastbiz.net>> wrote: >> >> I worked on that switch before, and IIRC it's just a linker >> switch that marks executables a certain way. So, if you have >> imagecfg.exe handy... >> >> http://support.microsoft.com/__kb/297812 >> <http://support.microsoft.com/kb/297812> >> >> >> On 7/17/14 19:25 , Oscar E. A. CallaÃº wrote: >> >> Well. It seems that Pharo vms must be compiled with that >> option :/ >> >> Cheers >> >> >> On Wed, Jul 16, 2014 at 8:44 PM, <btc(a)openinworld.com >> <mailto:btc@openinworld.com> >> <mailto:btc@openinworld.com <mailto:btc@openinworld.com>>> >> wrote: >> >> __ >> Eliot Miranda wrote: >> >> >> >> >> On Wed, Jul 16, 2014 at 2:21 PM, Oscar E. A. CallaÃº >> <oscar.apollo(a)gmail.com >> <mailto:oscar.apollo@gmail.com> >> <mailto:oscar.apollo@gmail.com >> <mailto:oscar.apollo@gmail.com>__>> wrote: >> >> Hi, >> >> I'm using Windows 8.1 (update1) 64bits with 4GB >> of physical >> RAM. I only need 1.5GB of RAM, so I think I >> don't need to >> configure my OS to take /3GB of RAM. >> >> >> Well my experience (and others) is that one can't >> grow the heap >> much above 1.1 Gb without using the /3Gb switch on >> Windows XP. I >> can't talk for 8.1. But if 8.x also limits memory >> to 2Gb/process >> unless the /3Gb switch is in effect then yes, >> you'll need to use >> the /3Gb switch. >> >> HTH >> Eliot >> >> >> Cheers >> >> On Wednesday, July 16, 2014, Eliot Miranda >> wrote: >> >> Hi Oscar, >> >> >> On Wed, Jul 16, 2014 at 9:11 AM, Oscar E. >> A. CallaÃº >> <oscar.apollo(a)gmail.com >> <mailto:oscar.apollo@gmail.com>> wrote: >> >> Hi guys, >> >> I'm running some experiments in >> Pharo. My data >> is aprox. 1.3GB. When I load my image >> on Mac, >> everything works perfectly. But, when I >> try to load >> the same image on Windows, I get this >> error: >> >> Unable to commit memory (1326649344 >> bytes requested) >> >> I tried the Pharo VM, cogMT and NBcog >> with and >> without the option >> >> AddressSpaceLimit = 2048 >> >> in the ini file >> >> Please help. >> >> What OS are you using? Have you read e.g. >> >> http://msdn.microsoft.com/en-__us/library/windows/hardware/__dn613959(v=vs.… >> >> >> <http://msdn.microsoft.com/en-us/library/windows/hardware/dn613959(v=vs.85).…> >> >> >> >> <http://msdn.microsoft.com/en-__us/library/windows/hardware/__dn613959%28v=v… >> >> >> <http://msdn.microsoft.com/en-us/library/windows/hardware/dn613959%28v=vs.85…>>? >> >> >> >> >> Here are some additional links... >> >> /LARGEADDRESSAWARE (Handle Large Addresses) >> http://msdn.microsoft.com/en-__us/library/wz223b1z.aspx >> <http://msdn.microsoft.com/en-us/library/wz223b1z.aspx> >> >> Memory Limits for Windows and Windows Server Releases >> >> http://msdn.microsoft.com/en-__us/library/windows/desktop/__aa366778(v=vs.8… >> >> >> <http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).a…> >> >> I learnt something new reading this article. For Win >> 8.1 64-bit, the >> /3GB switch is not applicable or required. However the >> /LARGEADDRESSAWARE linker option is critical for both >> 32-bit and >> 64-bit VMs. Its only the default setting that changes >> between >> compiling 32-bit or 64-bit applications. Some >> extracts... >> >> Limits on memory and address space depend on whether >> the >> IMAGE_FILE_LARGE_ADDRESS_AWARE value of the >> LOADED_IMAGE structure >> and 4-gigabyte tuning (4GT) are in use. >> IMAGE_FILE_LARGE_ADDRESS_AWARE is set or cleared by >> using the >> /LARGEADDRESSAWARE linker option. 4-gigabyte tuning >> (4GT), also >> known as application memory tuning, or the /3GB switch, >> is a >> technology (**only applicable to 32 bit systems**) that >> alters the >> amount of virtual address space available to user mode >> applications. >> >> On x64-bit MS Windows, User-Mode virtual address space >> for each >> 32-bit process >> 4 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE set >> 2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared >> (default) >> >> On x64-bit MS Windows, User-Mode virtual address space >> for each >> 64-bit process >> 8 TB With IMAGE_FILE_LARGE_ADDRESS_AWARE set (default): >> 2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared >> >> cheers -ben >> >> >> -- >> best, >> Eliot >> >> >> >> >> -- >> best, >> Eliot >> >> >> >> >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com> >> >> "Every thing has its own flow" > >

July 20, 2014

Re: [Pharo-dev] UITheme experience (please read) :)

by stepharo

I continued the experiment with PluggableButtonMorph and - we should remove some duplicated code in UItheme hiearchy :) - if we do not share behavior in themers (accross widgets) we will have duplicated code and logic. Side note: When I see the amount of messages sent to open a morph and the complexity of the theme in addition to Morphic intrinsic complexity it is obvious that it cannot be fast. Far too complex. I started to copy simpleButtonMorph and clean it just to understand. I would like to do the same for the widgets but this is a daunting task. I really think that Bloc will come to the rescue because simplifying is not an easy task either. Polymorph is complex and added a lot of hacks on top (because it was designed as a layer). Not talking about TextMorph and StringMorph different API. Simple API like label:font: are bogus. Widgets displaying text should have font instance variable I will try to make the XPPluggableButtonMorph works in Pharo30 and DarkTheme and let you know. The code is published in SD PetitsBazars/ StefArchitecture something. I will continue to split Polymorph and read code around and clean what I can see. Stef > Definitely! > > My post was about the second point. > > Doru > > > On Sat, Jul 19, 2014 at 5:22 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi doru > > I think that there are two points: > - moving creation API from theme to classes (I'm doing this > one to also create example of the widgets) > Smalltalk ui theme newButton.... sucks :) > - rethinking the theming architecture > > Stef > > > > On 19/7/14 14:16, Tudor Girba wrote: >> Hi Stef, >> >> I do not have time right now to go into details, so take this >> just as an acknowledgment that I have an interest in this topic :). >> >> My initial proposal that I sent to this list a while ago (some >> details are provided here: >> http://www.humane-assessment.com/blog/a-pharo-refactoring-story-adding-them…) >> went exactly in the direction of a ThemeStrategy that I call >> Themer. We used it already for several morphs around Glamour to >> play with the boundaries and it works well. >> >> I still think we need the UITheme but that should only provide a >> list of themers without any implementation. Like that we can >> package a uniform look throughout the whole environment. However, >> we should still be able to override the themer at the level of >> morph for quick prototyping and custom needs. >> >> I will get back to you. >> >> Cheers, >> Doru >> >> >> >> >> On Sat, Jul 19, 2014 at 9:15 AM, stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> Hi guys >> >> I want to lower the importance of UITheme >> >> - first the factory API should be pushed in the respective >> classes >> ie: >> >> UItheme>>newButtonIn: aThemedMorph for: aModel getState: >> stateSel action: actionSel arguments: args getEnabled: >> enabledSel getLabel: labelSel help: helpText >> "Answer a new button." >> >> |b| >> b := PluggableButtonMorph >> on: aModel >> getState: stateSel >> action: actionSel >> label: labelSel. >> b >> theme: self; >> label: ' ' font: self buttonFont; >> update: labelSel; >> arguments: (args ifNil: [{b}]); >> getEnabledSelector: enabledSel; >> cornerStyle: (self buttonCornerStyleIn: aThemedMorph); >> hResizing: #shrinkWrap; >> vResizing: #shrinkWrap; >> setBalloonText: helpText; >> extent: b minExtent; >> removeProperty: #theme. >> ^b >> >> >> should be transformed into >> >> PluggableButtonMorph>>newButtonFor: aModel getState: stateSel >> action: actionSel arguments: args getEnabled: enabledSel >> label: label help: helpText >> "Answer a new button." >> >> | b | >> b := self on: aModel getState: stateSel action: actionSel. >> b >> arguments: (args ifNil: [{b}]); >> hResizing: #shrinkWrap; >> vResizing: #shrinkWrap; >> label: label ; >> getEnabledSelector: enabledSel; >> setBalloonText: helpText; >> extent: b minExtent; >> hResizing: #rigid; >> vResizing: #rigid. >> ^b >> >> >> Now I do not want to lose the theme so I'm working on that. >> >> - second I wanted to experiment with the theming architecture >> >> I did the following >> >> XPGrowlMorph >> >> Object < XPGrowlThemeStrategy >> parentTheme := UITheme new >> >> XPGrowlThemeStrategy < XPGrowlDarkTheme >> parentTheme := PharoDarkTheme new >> growFillColor: >> Color white >> XPGrowlThemeStrategy < XPGrowlPharo30Theme >> parentTheme := Pharo30Theme new >> growFillColor: >> Color red >> minTextSize >> ^ parentTheme minTextSize >> >> I did the same with XPSimpleButtonMorph >> >> >> Conclusion: >> >> - Do we gain from object inheritance vs class? >> I do not think that we want to change dynamical the theme chain >> So I will make the widget strategy class from their theme >> >> PharoDarkTheme < XPGrowlDarkTheme >> >> Pharo30Theme < XPGrowlPharo30Theme >> >> - cons we may have duplicated behavior accross theme => traits? >> >> - Do we gain having widgets specific theming strategy >> - cons this generate a lot of classes >> so we will see >> >> + with inheritance we reuse a lot >> + probably we can reduce the API of UItheme (see below) >> >> >> - Can we reduce the API of UITheme >> buttonBorderColor >> listBorderColor >> â¦. >> >> Yes probably doing >> >> Pharo3Theme>>buttonBorderColor >> >> => >> >> Pharo30ButtonStrategy>>borderColor >> >> -> but should be experimented >> >> >> - From a widget point of view, if we want to have possibility >> to see the same widgets in different theme at the same time >> this raises the problem of the injection (or recomputation) >> of the theme values. >> Example below: >> We want to specify a theme but the new is calling initialize >> and the values are computed with a default/current theme. >> >> >> XPGrowlMorph new >> theme: XPPharo3ThemeStrategy new; >> label: 'The time' contents: TimeStamp now; >> skin; >> openInWorld. >> >> XPGrowlMorph new >> theme: XPDarkThemeStrategy new; >> label: 'The time' contents: TimeStamp now; >> openInWorld. >> >> => Question is it worth because with a default theme we would >> have it nearly working. >> >> Stef >> >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com> >> >> "Every thing has its own flow" > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

July 19, 2014

Re: [Pharo-dev] Memory limit problems on Windows VM

by Tudor Girba

Thanks. I will test that. Doru On Sat, Jul 19, 2014 at 10:41 PM, Andres Valloud < avalloud(a)smalltalk.comcastbiz.net> wrote: > Keep in mind that, depending on how images are loaded, you won't be able > to load images larger than about 2gb... you might want to test that. > > > On 7/19/14 13:39 , Tudor Girba wrote: > >> Wow! I will certainly try this patch. >> >> Doru >> >> >> On Fri, Jul 18, 2014 at 5:15 PM, Oscar E. A. CallaÃº >> <oscar.apollo(a)gmail.com <mailto:oscar.apollo@gmail.com>> wrote: >> >> Well, >> >> I fixed the problem by modifying the Pharo.exe file with the 4GB >> patch program (http://ntcore.com/4gb_patch.php) >> >> As mentioned before, I think the best solution is that Pharo vms >> must be compiled with the flag LARGEADDRESSAWARE, so more memory >> space is enabled for 64bits Windows OSs. >> >> Thanks guys >> >> Oscar >> >> >> On Thu, Jul 17, 2014 at 11:03 PM, Andres Valloud >> <avalloud(a)smalltalk.comcastbiz.net >> <mailto:avalloud@smalltalk.comcastbiz.net>> wrote: >> >> I worked on that switch before, and IIRC it's just a linker >> switch that marks executables a certain way. So, if you have >> imagecfg.exe handy... >> >> http://support.microsoft.com/__kb/297812 >> >> <http://support.microsoft.com/kb/297812> >> >> >> On 7/17/14 19:25 , Oscar E. A. CallaÃº wrote: >> >> Well. It seems that Pharo vms must be compiled with that >> option :/ >> >> Cheers >> >> >> On Wed, Jul 16, 2014 at 8:44 PM, <btc(a)openinworld.com >> <mailto:btc@openinworld.com> >> <mailto:btc@openinworld.com <mailto:btc@openinworld.com>>> >> >> wrote: >> >> __ >> Eliot Miranda wrote: >> >> >> >> >> On Wed, Jul 16, 2014 at 2:21 PM, Oscar E. A. CallaÃº >> <oscar.apollo(a)gmail.com >> <mailto:oscar.apollo@gmail.com> >> <mailto:oscar.apollo@gmail.com >> >> <mailto:oscar.apollo@gmail.com>__>> wrote: >> >> Hi, >> >> I'm using Windows 8.1 (update1) 64bits with 4GB >> of physical >> RAM. I only need 1.5GB of RAM, so I think I >> don't need to >> configure my OS to take /3GB of RAM. >> >> >> Well my experience (and others) is that one can't >> grow the heap >> much above 1.1 Gb without using the /3Gb switch on >> Windows XP. I >> can't talk for 8.1. But if 8.x also limits memory >> to 2Gb/process >> unless the /3Gb switch is in effect then yes, >> you'll need to use >> the /3Gb switch. >> >> HTH >> Eliot >> >> >> Cheers >> >> On Wednesday, July 16, 2014, Eliot Miranda wrote: >> >> Hi Oscar, >> >> >> On Wed, Jul 16, 2014 at 9:11 AM, Oscar E. >> A. CallaÃº >> <oscar.apollo(a)gmail.com >> <mailto:oscar.apollo@gmail.com>> wrote: >> >> Hi guys, >> >> I'm running some experiments in >> Pharo. My data >> is aprox. 1.3GB. When I load my image >> on Mac, >> everything works perfectly. But, when I >> try to load >> the same image on Windows, I get this >> error: >> >> Unable to commit memory (1326649344 >> bytes requested) >> >> I tried the Pharo VM, cogMT and NBcog >> with and >> without the option >> >> AddressSpaceLimit = 2048 >> >> in the ini file >> >> Please help. >> >> What OS are you using? Have you read e.g. >> http://msdn.microsoft.com/en-_ >> _us/library/windows/hardware/__dn613959(v=vs.85).aspx >> <http://msdn.microsoft.com/en- >> us/library/windows/hardware/dn613959(v=vs.85).aspx> >> >> <http://msdn.microsoft.com/en- >> __us/library/windows/hardware/__dn613959%28v=vs.85%29.aspx >> >> <http://msdn.microsoft.com/en- >> us/library/windows/hardware/dn613959%28v=vs.85%29.aspx>>? >> >> >> >> Here are some additional links... >> >> /LARGEADDRESSAWARE (Handle Large Addresses) >> http://msdn.microsoft.com/en-__us/library/wz223b1z.aspx >> >> <http://msdn.microsoft.com/en-us/library/wz223b1z.aspx> >> >> Memory Limits for Windows and Windows Server Releases >> http://msdn.microsoft.com/en-__us/library/windows/desktop/__ >> aa366778(v=vs.85).aspx >> >> <http://msdn.microsoft.com/en-us/library/windows/desktop/ >> aa366778(v=vs.85).aspx> >> I learnt something new reading this article. For Win >> 8.1 64-bit, the >> /3GB switch is not applicable or required. However the >> /LARGEADDRESSAWARE linker option is critical for both >> 32-bit and >> 64-bit VMs. Its only the default setting that changes >> between >> compiling 32-bit or 64-bit applications. Some extracts... >> >> Limits on memory and address space depend on whether the >> IMAGE_FILE_LARGE_ADDRESS_AWARE value of the >> LOADED_IMAGE structure >> and 4-gigabyte tuning (4GT) are in use. >> IMAGE_FILE_LARGE_ADDRESS_AWARE is set or cleared by >> using the >> /LARGEADDRESSAWARE linker option. 4-gigabyte tuning >> (4GT), also >> known as application memory tuning, or the /3GB switch, >> is a >> technology (**only applicable to 32 bit systems**) that >> alters the >> amount of virtual address space available to user mode >> applications. >> >> On x64-bit MS Windows, User-Mode virtual address space >> for each >> 32-bit process >> 4 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE set >> 2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared >> (default) >> >> On x64-bit MS Windows, User-Mode virtual address space >> for each >> 64-bit process >> 8 TB With IMAGE_FILE_LARGE_ADDRESS_AWARE set (default): >> 2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared >> >> cheers -ben >> >> >> -- >> best, >> Eliot >> >> >> >> >> -- >> best, >> Eliot >> >> >> >> >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com> >> >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

July 19, 2014

Re: [Pharo-dev] Memory limit problems on Windows VM

by Andres Valloud

Keep in mind that, depending on how images are loaded, you won't be able to load images larger than about 2gb... you might want to test that. On 7/19/14 13:39 , Tudor Girba wrote: > Wow! I will certainly try this patch. > > Doru > > > On Fri, Jul 18, 2014 at 5:15 PM, Oscar E. A. CallaÃº > <oscar.apollo(a)gmail.com <mailto:oscar.apollo@gmail.com>> wrote: > > Well, > > I fixed the problem by modifying the Pharo.exe file with the 4GB > patch program (http://ntcore.com/4gb_patch.php) > > As mentioned before, I think the best solution is that Pharo vms > must be compiled with the flag LARGEADDRESSAWARE, so more memory > space is enabled for 64bits Windows OSs. > > Thanks guys > > Oscar > > > On Thu, Jul 17, 2014 at 11:03 PM, Andres Valloud > <avalloud(a)smalltalk.comcastbiz.net > <mailto:avalloud@smalltalk.comcastbiz.net>> wrote: > > I worked on that switch before, and IIRC it's just a linker > switch that marks executables a certain way. So, if you have > imagecfg.exe handy... > > http://support.microsoft.com/__kb/297812 > <http://support.microsoft.com/kb/297812> > > > On 7/17/14 19:25 , Oscar E. A. CallaÃº wrote: > > Well. It seems that Pharo vms must be compiled with that > option :/ > > Cheers > > > On Wed, Jul 16, 2014 at 8:44 PM, <btc(a)openinworld.com > <mailto:btc@openinworld.com> > <mailto:btc@openinworld.com <mailto:btc@openinworld.com>>> > wrote: > > __ > Eliot Miranda wrote: > > > > > On Wed, Jul 16, 2014 at 2:21 PM, Oscar E. A. CallaÃº > <oscar.apollo(a)gmail.com > <mailto:oscar.apollo@gmail.com> > <mailto:oscar.apollo@gmail.com > <mailto:oscar.apollo@gmail.com>__>> wrote: > > Hi, > > I'm using Windows 8.1 (update1) 64bits with 4GB > of physical > RAM. I only need 1.5GB of RAM, so I think I > don't need to > configure my OS to take /3GB of RAM. > > > Well my experience (and others) is that one can't > grow the heap > much above 1.1 Gb without using the /3Gb switch on > Windows XP. I > can't talk for 8.1. But if 8.x also limits memory > to 2Gb/process > unless the /3Gb switch is in effect then yes, > you'll need to use > the /3Gb switch. > > HTH > Eliot > > > Cheers > > On Wednesday, July 16, 2014, Eliot Miranda wrote: > > Hi Oscar, > > > On Wed, Jul 16, 2014 at 9:11 AM, Oscar E. > A. CallaÃº > <oscar.apollo(a)gmail.com > <mailto:oscar.apollo@gmail.com>> wrote: > > Hi guys, > > I'm running some experiments in > Pharo. My data > is aprox. 1.3GB. When I load my image > on Mac, > everything works perfectly. But, when I > try to load > the same image on Windows, I get this > error: > > Unable to commit memory (1326649344 > bytes requested) > > I tried the Pharo VM, cogMT and NBcog > with and > without the option > > AddressSpaceLimit = 2048 > > in the ini file > > Please help. > > What OS are you using? Have you read e.g. > http://msdn.microsoft.com/en-__us/library/windows/hardware/__dn613959(v=vs.… > <http://msdn.microsoft.com/en-us/library/windows/hardware/dn613959(v=vs.85).…> > > <http://msdn.microsoft.com/en-__us/library/windows/hardware/__dn613959%28v=v… > <http://msdn.microsoft.com/en-us/library/windows/hardware/dn613959%28v=vs.85…>>? > > > > Here are some additional links... > > /LARGEADDRESSAWARE (Handle Large Addresses) > http://msdn.microsoft.com/en-__us/library/wz223b1z.aspx > <http://msdn.microsoft.com/en-us/library/wz223b1z.aspx> > > Memory Limits for Windows and Windows Server Releases > http://msdn.microsoft.com/en-__us/library/windows/desktop/__aa366778(v=vs.8… > <http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).a…> > I learnt something new reading this article. For Win > 8.1 64-bit, the > /3GB switch is not applicable or required. However the > /LARGEADDRESSAWARE linker option is critical for both > 32-bit and > 64-bit VMs. Its only the default setting that changes > between > compiling 32-bit or 64-bit applications. Some extracts... > > Limits on memory and address space depend on whether the > IMAGE_FILE_LARGE_ADDRESS_AWARE value of the > LOADED_IMAGE structure > and 4-gigabyte tuning (4GT) are in use. > IMAGE_FILE_LARGE_ADDRESS_AWARE is set or cleared by > using the > /LARGEADDRESSAWARE linker option. 4-gigabyte tuning > (4GT), also > known as application memory tuning, or the /3GB switch, > is a > technology (**only applicable to 32 bit systems**) that > alters the > amount of virtual address space available to user mode > applications. > > On x64-bit MS Windows, User-Mode virtual address space > for each > 32-bit process > 4 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE set > 2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared (default) > > On x64-bit MS Windows, User-Mode virtual address space > for each > 64-bit process > 8 TB With IMAGE_FILE_LARGE_ADDRESS_AWARE set (default): > 2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared > > cheers -ben > > > -- > best, > Eliot > > > > > -- > best, > Eliot > > > > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

July 19, 2014

Re: [Pharo-dev] Memory limit problems on Windows VM

by Tudor Girba

Wow! I will certainly try this patch. Doru On Fri, Jul 18, 2014 at 5:15 PM, Oscar E. A. CallaÃº <oscar.apollo(a)gmail.com> wrote: > Well, > > I fixed the problem by modifying the Pharo.exe file with the 4GB patch > program (http://ntcore.com/4gb_patch.php) > > As mentioned before, I think the best solution is that Pharo vms must be > compiled with the flag LARGEADDRESSAWARE, so more memory space is > enabled for 64bits Windows OSs. > > Thanks guys > > Oscar > > > > On Thu, Jul 17, 2014 at 11:03 PM, Andres Valloud < > avalloud(a)smalltalk.comcastbiz.net> wrote: > >> I worked on that switch before, and IIRC it's just a linker switch that >> marks executables a certain way. So, if you have imagecfg.exe handy... >> >> http://support.microsoft.com/kb/297812 >> >> >> On 7/17/14 19:25 , Oscar E. A. CallaÃº wrote: >> >>> Well. It seems that Pharo vms must be compiled with that option :/ >>> >>> Cheers >>> >>> >>> On Wed, Jul 16, 2014 at 8:44 PM, <btc(a)openinworld.com >>> <mailto:btc@openinworld.com>> wrote: >>> >>> __ >>> Eliot Miranda wrote: >>> >>>> >>>> >>>> >>>> On Wed, Jul 16, 2014 at 2:21 PM, Oscar E. A. CallaÃº >>>> <oscar.apollo(a)gmail.com <mailto:oscar.apollo@gmail.com>> wrote: >>>> >>>> Hi, >>>> >>>> I'm using Windows 8.1 (update1) 64bits with 4GB of physical >>>> RAM. I only need 1.5GB of RAM, so I think I don't need to >>>> configure my OS to take /3GB of RAM. >>>> >>>> >>>> Well my experience (and others) is that one can't grow the heap >>>> much above 1.1 Gb without using the /3Gb switch on Windows XP. I >>>> can't talk for 8.1. But if 8.x also limits memory to 2Gb/process >>>> unless the /3Gb switch is in effect then yes, you'll need to use >>>> the /3Gb switch. >>>> >>>> HTH >>>> Eliot >>>> >>>> >>>> Cheers >>>> >>>> On Wednesday, July 16, 2014, Eliot Miranda wrote: >>>> >>>> Hi Oscar, >>>> >>>> >>>> On Wed, Jul 16, 2014 at 9:11 AM, Oscar E. A. CallaÃº >>>> <oscar.apollo(a)gmail.com> wrote: >>>> >>>> Hi guys, >>>> >>>> I'm running some experiments in Pharo. My data >>>> is aprox. 1.3GB. When I load my image on Mac, >>>> everything works perfectly. But, when I try to load >>>> the same image on Windows, I get this error: >>>> >>>> Unable to commit memory (1326649344 bytes requested) >>>> >>>> I tried the Pharo VM, cogMT and NBcog with and >>>> without the option >>>> >>>> AddressSpaceLimit = 2048 >>>> >>>> in the ini file >>>> >>>> Please help. >>>> >>>> What OS are you using? Have you read e.g. >>>> http://msdn.microsoft.com/en-us/library/windows/hardware/ >>>> dn613959(v=vs.85).aspx >>>> <http://msdn.microsoft.com/en-us/library/windows/hardware/ >>>> dn613959%28v=vs.85%29.aspx>? >>>> >>>> >>>> >>> Here are some additional links... >>> >>> /LARGEADDRESSAWARE (Handle Large Addresses) >>> http://msdn.microsoft.com/en-us/library/wz223b1z.aspx >>> >>> Memory Limits for Windows and Windows Server Releases >>> http://msdn.microsoft.com/en-us/library/windows/desktop/ >>> aa366778(v=vs.85).aspx >>> I learnt something new reading this article. For Win 8.1 64-bit, the >>> /3GB switch is not applicable or required. However the >>> /LARGEADDRESSAWARE linker option is critical for both 32-bit and >>> 64-bit VMs. Its only the default setting that changes between >>> compiling 32-bit or 64-bit applications. Some extracts... >>> >>> Limits on memory and address space depend on whether the >>> IMAGE_FILE_LARGE_ADDRESS_AWARE value of the LOADED_IMAGE structure >>> and 4-gigabyte tuning (4GT) are in use. >>> IMAGE_FILE_LARGE_ADDRESS_AWARE is set or cleared by using the >>> /LARGEADDRESSAWARE linker option. 4-gigabyte tuning (4GT), also >>> known as application memory tuning, or the /3GB switch, is a >>> technology (**only applicable to 32 bit systems**) that alters the >>> amount of virtual address space available to user mode applications. >>> >>> On x64-bit MS Windows, User-Mode virtual address space for each >>> 32-bit process >>> 4 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE set >>> 2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared (default) >>> >>> On x64-bit MS Windows, User-Mode virtual address space for each >>> 64-bit process >>> 8 TB With IMAGE_FILE_LARGE_ADDRESS_AWARE set (default): >>> 2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared >>> >>> cheers -ben >>> >>> >>>> -- >>>> best, >>>> Eliot >>>> >>>> >>>> >>>> >>>> -- >>>> best, >>>> Eliot >>>> >>> >>> >>> >> > -- www.tudorgirba.com "Every thing has its own flow"

July 19, 2014

Re: [Pharo-dev] Spotlight2 for Pharo40?

by Tudor Girba

It is working in Pharo 3.0, but it does not get installed as a global shortcut properly, and it requires an override on Morphic. Cheers, Doru On Sat, Jul 19, 2014 at 9:36 PM, stepharo <stepharo(a)free.fr> wrote: > Hi sean and users of Spotlight2 > > I did not tried it yet but I would like to know > - is it working the way you want? > - is it working in 40? > - what about replacing the old one with this one? > > Stef > > -- www.tudorgirba.com "Every thing has its own flow"

July 19, 2014

Re: [Pharo-dev] UITheme experience (please read) :)

by Tudor Girba

Definitely! My post was about the second point. Doru On Sat, Jul 19, 2014 at 5:22 PM, stepharo <stepharo(a)free.fr> wrote: > Hi doru > > I think that there are two points: > - moving creation API from theme to classes (I'm doing this one to > also create example of the widgets) > Smalltalk ui theme newButton.... sucks :) > - rethinking the theming architecture > > Stef > > > > On 19/7/14 14:16, Tudor Girba wrote: > > Hi Stef, > > I do not have time right now to go into details, so take this just as an > acknowledgment that I have an interest in this topic :). > > My initial proposal that I sent to this list a while ago (some details > are provided here: > http://www.humane-assessment.com/blog/a-pharo-refactoring-story-adding-them…) > went exactly in the direction of a ThemeStrategy that I call Themer. We > used it already for several morphs around Glamour to play with the > boundaries and it works well. > > I still think we need the UITheme but that should only provide a list of > themers without any implementation. Like that we can package a uniform look > throughout the whole environment. However, we should still be able to > override the themer at the level of morph for quick prototyping and custom > needs. > > I will get back to you. > > Cheers, > Doru > > > > > On Sat, Jul 19, 2014 at 9:15 AM, stepharo <stepharo(a)free.fr> wrote: > >> Hi guys >> >> I want to lower the importance of UITheme >> >> - first the factory API should be pushed in the respective classes >> ie: >> >> UItheme>>newButtonIn: aThemedMorph for: aModel getState: stateSel action: >> actionSel arguments: args getEnabled: enabledSel getLabel: labelSel help: >> helpText >> "Answer a new button." >> >> |b| >> b := PluggableButtonMorph >> on: aModel >> getState: stateSel >> action: actionSel >> label: labelSel. >> b >> theme: self; >> label: ' ' font: self buttonFont; >> update: labelSel; >> arguments: (args ifNil: [{b}]); >> getEnabledSelector: enabledSel; >> cornerStyle: (self buttonCornerStyleIn: aThemedMorph); >> hResizing: #shrinkWrap; >> vResizing: #shrinkWrap; >> setBalloonText: helpText; >> extent: b minExtent; >> removeProperty: #theme. >> ^b >> >> >> should be transformed into >> >> PluggableButtonMorph>>newButtonFor: aModel getState: stateSel action: >> actionSel arguments: args getEnabled: enabledSel label: label help: helpText >> "Answer a new button." >> >> | b | >> b := self on: aModel getState: stateSel action: actionSel. >> b >> arguments: (args ifNil: [{b}]); >> hResizing: #shrinkWrap; >> vResizing: #shrinkWrap; >> label: label ; >> getEnabledSelector: enabledSel; >> setBalloonText: helpText; >> extent: b minExtent; >> hResizing: #rigid; >> vResizing: #rigid. >> ^b >> >> >> Now I do not want to lose the theme so I'm working on that. >> >> - second I wanted to experiment with the theming architecture >> >> I did the following >> >> XPGrowlMorph >> >> Object < XPGrowlThemeStrategy >> parentTheme := UITheme new >> >> XPGrowlThemeStrategy < XPGrowlDarkTheme >> parentTheme := PharoDarkTheme new >> growFillColor: >> Color white >> XPGrowlThemeStrategy < XPGrowlPharo30Theme >> parentTheme := Pharo30Theme new >> growFillColor: >> Color red >> minTextSize >> ^ parentTheme minTextSize >> >> I did the same with XPSimpleButtonMorph >> >> >> Conclusion: >> >> - Do we gain from object inheritance vs class? >> I do not think that we want to change dynamical the theme chain >> So I will make the widget strategy class from their theme >> >> PharoDarkTheme < XPGrowlDarkTheme >> >> Pharo30Theme < XPGrowlPharo30Theme >> >> - cons we may have duplicated behavior accross theme => traits? >> >> - Do we gain having widgets specific theming strategy >> - cons this generate a lot of classes >> so we will see >> >> + with inheritance we reuse a lot >> + probably we can reduce the API of UItheme (see below) >> >> >> - Can we reduce the API of UITheme >> buttonBorderColor >> listBorderColor >> â¦. >> >> Yes probably doing >> >> Pharo3Theme>>buttonBorderColor >> >> => >> >> Pharo30ButtonStrategy>>borderColor >> >> -> but should be experimented >> >> >> - From a widget point of view, if we want to have possibility to see the >> same widgets in different theme at the same time >> this raises the problem of the injection (or recomputation) of the theme >> values. >> Example below: >> We want to specify a theme but the new is calling initialize and the >> values are computed with a default/current theme. >> >> >> XPGrowlMorph new >> theme: XPPharo3ThemeStrategy new; >> label: 'The time' contents: TimeStamp now; >> skin; >> openInWorld. >> >> XPGrowlMorph new >> theme: XPDarkThemeStrategy new; >> label: 'The time' contents: TimeStamp now; >> openInWorld. >> >> => Question is it worth because with a default theme we would have it >> nearly working. >> >> Stef >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

July 19, 2014