- Pharo-dev - lists.pharo.org

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

by Peter UhnÃ¡k

Is it possible to disable it then? Because opening Spotter is muscle memory for me so I will open it by accident sooner or later. Thanks, Peter On Sat, Aug 29, 2015 at 1:01 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Is it possible that opening Spotter has corrupted the image? > > > Yes, Spotter corrupts image :( I thinks it is somehow connected with usage > of defer: by Spotter to schedule code execution in UI thread from > background thread (to perform callback in UI thread) that is not compatible > in Bloc world. Bloc introduces new Alarm mechanism, so defer: is > depreciated and I suppose Alarm are not completely compatible with old > morphic mechanism. > > Sadly, but Spotter must not be opened in Bloc otherwise image dies > > Cheers, > Alex > > On Sat, Aug 29, 2015 at 12:56 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> I did use it and I know it froze after that... >> but now it happens even without using Spotter. >> >> Is it possible that opening Spotter has corrupted the image? >> >> Peter >> >> On Sat, Aug 29, 2015 at 12:35 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> >> wrote: >> >>> 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

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

by Aliaksei Syrel

> > Is it possible that opening Spotter has corrupted the image? Yes, Spotter corrupts image :( I thinks it is somehow connected with usage of defer: by Spotter to schedule code execution in UI thread from background thread (to perform callback in UI thread) that is not compatible in Bloc world. Bloc introduces new Alarm mechanism, so defer: is depreciated and I suppose Alarm are not completely compatible with old morphic mechanism. Sadly, but Spotter must not be opened in Bloc otherwise image dies Cheers, Alex On Sat, Aug 29, 2015 at 12:56 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > I did use it and I know it froze after that... > but now it happens even without using Spotter. > > Is it possible that opening Spotter has corrupted the image? > > Peter > > On Sat, Aug 29, 2015 at 12:35 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> > wrote: > >> 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

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

by Peter UhnÃ¡k

I did use it and I know it froze after that... but now it happens even without using Spotter. Is it possible that opening Spotter has corrupted the image? Peter On Sat, Aug 29, 2015 at 12:35 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > 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

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