August 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Unresponsive Bloc/Brick UI

by Aliaksei Syrel

Hi Peter, Do you use Spotter while in Bloc? Cheers, Alex On Sat, Aug 29, 2015 at 12:32 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi, > > I've been playing with the latest Brick tools, however after about a > minute or two the UI always becomes completely unresponsive. I cannot move > anything nor do anything. If I press <cmd>+<dot> > this shows in my terminal... but the UI is still unresponsive. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > User Interrupt > BlMouseButtonOutsideEventListener(BlEventListener)>>handleEvent: > BlMouseButtonOutsideEventListener(BlEventListener)>>handleEvent: > BlMouseButtonOutsideEventListener(BlEventListener)>>handleEvent: > BlMouseButtonOutsideEventListener(BlEventListener)>>handleEvent: > BlMorphicCompatibleBlocSpace(BlBlocSpace)>>handleEvent: > BlMorphicCompatibleBlocSpace(BlBlocSpace)>>sendEventToSpace: > > BlMorphicEventListenerRecord(BlEventListener)>>privateRemoveEventListener:fromOwner:previousInChain: > > BlMouseButtonOutsideEventListener(BlEventListener)>>privateRemoveEventListener:fromOwner:previousInChain: > > BlMouseButtonOutsideEventListener(BlEventListener)>>privateRemoveEventListener:fromOwner:previousInChain: > > BlMouseButtonOutsideEventListener(BlEventListener)>>privateRemoveEventListener:fromOwner:previousInChain: > > BlMouseButtonOutsideEventListener(BlEventListener)>>privateRemoveEventListener:fromOwner:previousInChain: > > BlMouseButtonOutsideEventListener(BlEventListener)>>privateRemoveEventListener:fromOwner:previousInChain: > > BlMouseButtonOutsideEventListener(BlEventListener)>>privateRemoveEventListener:fromOwner:previousInChain: > > BlMouseButtonOutsideEventListener(BlEventListener)>>privateRemoveEventListener:fromOwner:previousInChain: > > BlMouseButtonOutsideEventListener(BlEventListener)>>privateRemoveEventListener:fromOwner:previousInChain: > > BlMouseButtonOutsideEventListener(BlEventListener)>>privateRemoveEventListener:fromOwner:previousInChain: > BlMorphicCompatibleBlocSpace(BlBlocSpace)>>removeEventListener: > [ :sp | sp removeEventListener: self ] in > BlMorphicEventListenerRecord(BlGlobalEventListener)>>unplug in Block: [ :sp > | sp removeEventListener: self ] > BlockClosure>>cull: > BlMorphicEventListenerRecord(BlGlobalEventListener)>>spaceDo: > BlMorphicEventListenerRecord(BlGlobalEventListener)>>unplug > BlMorphicEventListenerRecord>>handleEvent: > BlMouseButtonOutsideEventListener(BlEventListener)>>handleEvent: > BlMouseButtonOutsideEventListener(BlEventListener)>>handleEvent: > BlMouseButtonOutsideEventListener(BlEventListener)>>handleEvent: > BlMouseButtonOutsideEventListener(BlEventListener)>>handleEvent: > BlMouseButtonOutsideEventListener(BlEventListener)>>handleEvent: > BlMouseButtonOutsideEventListener(BlEventListener)>>handleEvent: > BlMouseButtonOutsideEventListener(BlEventListener)>>handleEvent: > BlMouseButtonOutsideEventListener(BlEventListener)>>handleEvent > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Anyone has any idea? This is the original image I've been playing with > https://drive.google.com/file/d/0B-bMBVDOi3oTdll3dGJValVIenc/view > > Thanks, > Peter >

Aug. 29, 2015

Unresponsive Bloc/Brick UI

by Peter UhnÃ¡k

Hi, I've been playing with the latest Brick tools, however after about a minute or two the UI always becomes completely unresponsive. I cannot move anything nor do anything. If I press <cmd>+<dot> this shows in my terminal... but the UI is still unresponsive. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ User Interrupt BlMouseButtonOutsideEventListener(BlEventListener)>>handleEvent: BlMouseButtonOutsideEventListener(BlEventListener)>>handleEvent: BlMouseButtonOutsideEventListener(BlEventListener)>>handleEvent: BlMouseButtonOutsideEventListener(BlEventListener)>>handleEvent: BlMorphicCompatibleBlocSpace(BlBlocSpace)>>handleEvent: BlMorphicCompatibleBlocSpace(BlBlocSpace)>>sendEventToSpace: BlMorphicEventListenerRecord(BlEventListener)>>privateRemoveEventListener:fromOwner:previousInChain: BlMouseButtonOutsideEventListener(BlEventListener)>>privateRemoveEventListener:fromOwner:previousInChain: BlMouseButtonOutsideEventListener(BlEventListener)>>privateRemoveEventListener:fromOwner:previousInChain: BlMouseButtonOutsideEventListener(BlEventListener)>>privateRemoveEventListener:fromOwner:previousInChain: BlMouseButtonOutsideEventListener(BlEventListener)>>privateRemoveEventListener:fromOwner:previousInChain: BlMouseButtonOutsideEventListener(BlEventListener)>>privateRemoveEventListener:fromOwner:previousInChain: BlMouseButtonOutsideEventListener(BlEventListener)>>privateRemoveEventListener:fromOwner:previousInChain: BlMouseButtonOutsideEventListener(BlEventListener)>>privateRemoveEventListener:fromOwner:previousInChain: BlMouseButtonOutsideEventListener(BlEventListener)>>privateRemoveEventListener:fromOwner:previousInChain: BlMouseButtonOutsideEventListener(BlEventListener)>>privateRemoveEventListener:fromOwner:previousInChain: BlMorphicCompatibleBlocSpace(BlBlocSpace)>>removeEventListener: [ :sp | sp removeEventListener: self ] in BlMorphicEventListenerRecord(BlGlobalEventListener)>>unplug in Block: [ :sp | sp removeEventListener: self ] BlockClosure>>cull: BlMorphicEventListenerRecord(BlGlobalEventListener)>>spaceDo: BlMorphicEventListenerRecord(BlGlobalEventListener)>>unplug BlMorphicEventListenerRecord>>handleEvent: BlMouseButtonOutsideEventListener(BlEventListener)>>handleEvent: BlMouseButtonOutsideEventListener(BlEventListener)>>handleEvent: BlMouseButtonOutsideEventListener(BlEventListener)>>handleEvent: BlMouseButtonOutsideEventListener(BlEventListener)>>handleEvent: BlMouseButtonOutsideEventListener(BlEventListener)>>handleEvent: BlMouseButtonOutsideEventListener(BlEventListener)>>handleEvent: BlMouseButtonOutsideEventListener(BlEventListener)>>handleEvent: BlMouseButtonOutsideEventListener(BlEventListener)>>handleEvent ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Anyone has any idea? This is the original image I've been playing with https://drive.google.com/file/d/0B-bMBVDOi3oTdll3dGJValVIenc/view Thanks, Peter

Aug. 29, 2015

Re: [Pharo-dev] GLMPresentation and actions

by Andrei Chis

Hi, On Thu, Aug 27, 2015 at 10:08 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Glamour experts, > > There are methods in GLMPresentation like > > #act:icon:entitled: > #act:icon:on:entitled: > > adding an action but (unfortunately) these methods do not return the > action itself but the presentation instead. > But the presentation itself is the receiver of the message so the sender > already has access to > it anyway. > > Not returning the created action makes it hard to access the action > afterwards to send > additional messages to it (like #condition: or other). > > One would have to implement a > > #act:icon:entitled:condition: > > and other flavours - ending up in a lot of method variations. > Yes, currently that is the way to do it. > > Example: in CatalogBrowser>>defineAllRepositoriesInMCBrowserButton: > I have access to the list (a presentation) and I can use > #act:icon:entitled: to add an action button > but have no access to the action added afterwards. > > Should we change these methods to return the action and also > GLMPresentation>>#addAction: > to return the action: > > addAction: anAction > > ^self actions addLast: anAction > > This way it would be similar to a collection: if you add an element you > get it in return. > > IMHO this would prevent adding more and more "flavour" messages in the > future. What do you > think. > The entire scripting API from Glamour is based on sending multiple message sends that return #yourself to the presentation object. Changing #addAction: would break that. Now more or less, the current messages for adding actions to a presentation are shortcuts for common cases. If you need to configure an action differently you could bypass this API add add it directly either using #dynamicActions: or #addAction: > > Also: I would like the action buttons in CatalogBrowser to be only enabled > when > an item in the list (presentation) is selected. How can I do that? > There is a #condition: for an action but that is the condition for > the button > to be there. There is no updating #enabledWhen: or other. > Currently there is no direct support for this. We usually added actions that should only be available when a item is selected in a context menu as selectionActions. Still having the possibility to enable/disable actions is useful so could you open a bug/feature request :) Cheers, Andrei > > Thanks > T. > > >

Aug. 29, 2015

Re: [Pharo-dev] OSX code signing

by Marcus Denker

> On 29 Aug 2015, at 05:11, Ben Coman <btc(a)openinworld.com> wrote: > > On Fri, Aug 28, 2015 at 7:24 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: >> On 28-08-15 11:00, Marcus Denker wrote: >> >>>> 3. For a "portable" app (e.g. on USB stick) push the app down one >>>> folder, so rather than putting the Win/Lin executables inside the OSX >>>> app, the top level folder contains folders Windows, Linux, Common, and >>>> the app. >>> >>> >>> No, I would retire that concept. (I know some people love it, but I think >>> it does >>> not fit into days world where the OS installs Apps). >> >> >> I strongly disagree. It is very useful to be able to carry a complete >> environment with me that is useable wherever I am. We will run into a lot >> less problems with it once we move to 64 bit. >> > > Two cases benefit from a portable app: > People who want it can put work into it. I will not. I want installers for Windows, Mac and Linux, with the scheme that I described. Marcus

Aug. 29, 2015

Re: [Pharo-dev] [Playground] Getting contents from the cloud?

by Ben Coman

On Fri, Aug 28, 2015 at 9:08 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > On Fri, Aug 28, 2015 at 2:32 PM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: >> >> vonbecmann wrote >> > GREAT!!!!! >> >> Yes, isn't it!? >> >> >> vonbecmann wrote >> > (what a dummy!) >> >> Not at all. We are terrible at documenting all our amazing features. How >> would one guess that besides the fact that Spotter can do everything but >> open your beer bottle? > > > I found it when exploring spotter extension methods... > > The problem is that we want to strike a balance between "no information" and > "information overload", which is quite hard, because everyone has different > preferences and features are added and removed almost daily to at least one > of tools you use. > > So here easy discoverability is in my eyes more important than > documentation. > E.g. opening inspector on all spotter methods is even easier than googling a > website where the documentation/list of features may or may not be. > > Plus this doesn't impose extra cost on the developer, as the source acts as > documentation. > > Of course this doesn't always apply... > > Peter Perhaps presenting an inform message "Paste link into Spotter" when the <publish to cloud> button is pressed would not be too intrusive? cheers -ben

Aug. 29, 2015

Re: [Pharo-dev] OSX code signing

by Ben Coman

On Fri, Aug 28, 2015 at 7:24 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > On 28-08-15 11:00, Marcus Denker wrote: > >>> 3. For a "portable" app (e.g. on USB stick) push the app down one >>> folder, so rather than putting the Win/Lin executables inside the OSX >>> app, the top level folder contains folders Windows, Linux, Common, and >>> the app. >> >> >> No, I would retire that concept. (I know some people love it, but I think >> it does >> not fit into days world where the OS installs Apps). > > > I strongly disagree. It is very useful to be able to carry a complete > environment with me that is useable wherever I am. We will run into a lot > less problems with it once we move to 64 bit. > Two cases benefit from a portable app: 1. In a corporate environment environment where systems are locked down preventing any software from being installed, PortableApps [1] are a lifesaver (even if in this case only portable across Windows machines). I use them *all* the time. Our IT support guys who are the only ones with permissions to install app are busy and I need tools as they arise, not in three days time. In our case, this is the difference between someone doing a taste-testing Pharo immediately when their interest is aroused, or not, because having to do forms and justify *why* they need it is too much friction, especially when the *why* is "I only want to *play* with it for a couple of hours, when I should be doing something else". It adds one small barrier [1] to adoption by a large market of potential *paying* customers. Actually PBE & UPBE describe how Pharo doesn't need to install into system areas - and I think that is beneficial to keep. An alternative could that the Pharo installer gives the option to install into either System or User area, much like Google Chrome does.. http://googlesystem.blogspot.com.au/2013/10/chromes-system-level-installer-… 2. I think there was a lot of value in PBE having a portable zip to download locked to match the paper document. UPBE installation instructions currently refers to http://pharo.org/download -- but that will shift over time to Pharo 5. As much as the intent would be for UPBE to track Pharo releases, the reality of limited resources is that updating might be delayed, so it would be good for the installation instructions to point to a consistent image. Alternatively, the current download page might be copied to http://pharo.org/pharo4-pbe and remain untouched when Pharo 5 is released. Then the documentation just refers to that location for download and installation instructions. [1] http://portableapps.com/ Actually we could get some additional exposure by slotting Pharo in there. I know I tend to browse these available apps to "try them" and I assume others would do the same. [2] http://www.joelonsoftware.com/articles/fog0000000052.html cheers -ben

Aug. 29, 2015

Re: [Pharo-dev] Fwd: [Pharo-users] [ann] brick on top of bloc - preview

by stepharo

> In HTML5, Z-depth is pretty exclusively used as a mechanism to > determine Z-order in the HTML / CSS separation. Normally, the order of > HTML determines the Z-order. But, Z-order is really a style thing, > rather than a composition thing. So, specifying the Z-depth allows you > to override standard behavior in the style sheet. This is not > necessary in a true object-based GUI where graphical objects are more > self contained and can easily determine their own Z-order. > > I doubt we will see general purpose adoption of any 2D interface that > will rely on Z-depth for anything besides determining Z-order. For > instance, the example of shadow size seems interesting but runs into > usability problems quickly. Let's say that you have element A with a > larger shadow to indicate that it is above element B with a smaller > shadow. That seems great. What happens if element B is selected and > brought to the forefront? Does A's shadow go down in size? If so, that > breaks the normal shadow analogy. If not, it would seem that the > shadows would just keep growing bigger each time a new element is > brought to the front. For limited general-purpose applications (e.g., > a larger shadow for an object currently being dragged), you don't need > Z-depth info. For specialized applications where a Z-depth might make > sense (I can't even think of one), there's little problem adding such > functionality to custom widgets. So, my recommendations is to stay > away from trying to implement Z-depth as a fundamental component of a > 2D interface. The benefit is minimal and largely theoretical. + 1 Stef

Aug. 28, 2015

Re: [Pharo-dev] Fwd: [Pharo-users] [ann] brick on top of bloc - preview

by Ferlicot D. Cyril

Le 28/08/2015 17:56, Peter UhnÃ¡k a Ã©crit : > I am getting a strange FastTable error... > > I downloaded latest gtoolkit5 build (#166; uses Pharo #50248), but when > I open System Browser no classes are visible, if I click on the empty > space I get an error > > > in the zip provided by Aliaksei it works fine (Pharo #50222, build unknown). > > Peter > > Seems to be related to https://pharo.fogbugz.com/f/cases/16267/Fasttable-isn-t-visible-in-athens-i… -- Cheers Cyril Ferlicot-Delbecque

Aug. 28, 2015

Re: [Pharo-dev] Fwd: [Pharo-users] [ann] brick on top of bloc - preview

by Peter UhnÃ¡k

I am getting a strange FastTable error... I downloaded latest gtoolkit5 build (#166; uses Pharo #50248), but when I open System Browser no classes are visible, if I click on the empty space I get an error in the zip provided by Aliaksei it works fine (Pharo #50222, build unknown). Peter On Fri, Aug 28, 2015 at 3:33 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > This should be fixed in the last version (50286) > > On Fri, Aug 28, 2015 at 10:34 AM, S Krish < > krishnamachari.sudhakar(a)gmail.com> wrote: > >> Getting an error on loading bloc: >> >> Using base Pharo 4.0 with Pharo 5 image / changes. >> >> [image: Inline image 1] >> >> On Fri, Aug 28, 2015 at 1:41 PM, Richard Wettel <wettel(a)gmail.com> wrote: >> >>> Great job! Works well. Thank you! >>> >>> cheers >>> Ricky >>> >>> On Fri, Aug 28, 2015 at 4:16 AM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>>> On Fri, Aug 28, 2015 at 8:34 AM, J.F. Rick <self(a)je77.com> wrote: >>>> > On Wed, Aug 26, 2015 at 11:45 PM Ben Coman <btc(a)openinworld.com> >>>> wrote: >>>> >> >>>> >> So morphic has a Z-order but I think not a Z-depth. Is that be >>>> >> something we should be aiming for? >>>> > >>>> > >>>> > In HTML5, Z-depth is pretty exclusively used as a mechanism to >>>> determine >>>> > Z-order in the HTML / CSS separation. Normally, the order of HTML >>>> determines >>>> > the Z-order. But, Z-order is really a style thing, rather than a >>>> composition >>>> > thing. So, specifying the Z-depth allows you to override standard >>>> behavior >>>> > in the style sheet. This is not necessary in a true object-based GUI >>>> where >>>> > graphical objects are more self contained and can easily determine >>>> their own >>>> > Z-order. >>>> > >>>> > I doubt we will see general purpose adoption of any 2D interface that >>>> will >>>> > rely on Z-depth for anything besides determining Z-order. For >>>> instance, the >>>> > example of shadow size seems interesting but runs into usability >>>> problems >>>> > quickly. Let's say that you have element A with a larger shadow to >>>> indicate >>>> > that it is above element B with a smaller shadow. That seems great. >>>> What >>>> > happens if element B is selected and brought to the forefront? Does >>>> A's >>>> > shadow go down in size? If so, that breaks the normal shadow analogy. >>>> If >>>> > not, it would seem that the shadows would just keep growing bigger >>>> each time >>>> > a new element is brought to the front. For limited general-purpose >>>> > applications (e.g., a larger shadow for an object currently being >>>> dragged), >>>> > you don't need Z-depth info. For specialized applications where a >>>> Z-depth >>>> > might make sense (I can't even think of one), there's little problem >>>> adding >>>> > such functionality to custom widgets. So, my recommendations is to >>>> stay away >>>> > from trying to implement Z-depth as a fundamental component of a 2D >>>> > interface. The benefit is minimal and largely theoretical. >>>> > >>>> > Cheers, >>>> > >>>> > Jeff >>>> >>>> Thats a fair argument, thanks Jeff. I guess if someone wanted >>>> different size shadows for different z-order, a fixed distance between >>>> levels could be simulated with all windows shuffling down when a >>>> window is brought to the top. >>>> cheers -ben >>>> >>>> >>> >> > > > -- > -- > Marcus Denker -- denker(a)acm.org > http://www.marcusdenker.de >

Aug. 28, 2015

[pharo-project/pharo-core] 72a419: 50287

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 72a419d7da8ac1f43c0b8a7923662bfcc0c97b60 https://github.com/pharo-project/pharo-core/commit/72a419d7da8ac1f43c0b8a79… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-28 (Fri, 28 Aug 2015) Changed paths: R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50286.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50287.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50286.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50287.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Support.package/Model.class/definition.st A System-Support.package/Model.class/instance/as yet unclassified/announcer.st Log Message: ----------- 50287 16410 Add announceur (and not announcer) to Model https://pharo.fogbugz.com/f/cases/16410 http://files.pharo.org/image/50/50287.zip

Aug. 28, 2015