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

Re: [Pharo-dev] System Morphs in OSWindows

by Matthieu Lacaton

I am not sure I understand the first part of your mail. But as for the Raspberry application it should be possible to do it with OSWindow since SDL library seems to be supported on Raspberry. You just have to use your normal Pharo environment for your standard sized screen and you open an OSWindow with your chosen application displayed inside for your embedded LCD screen. I don't know about hardware limitations though. 2015-05-30 17:33 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > On Sat, May 30, 2015 at 4:16 PM, Matthieu Lacaton > <matthieu.lacaton(a)gmail.com> wrote: > >> I think it would be better to name these for their function rather > >> than the package: > >> Nautilus openInExternalWindowOnPackage: nil. > >> GTPlayground external openInExternalWindow. > >> ThreadSafeTranscript external openInExternalWindow. > >> > >> I don't know if its a workable idea, but maybe something like > >> Nautilus external openInOSWindowOnPackage: nil. > >> GTPlayground external openInOSWindow. > >> ThreadSafeTranscript external openInOSWindow. > > > > > > It is a workable idea, we just need to agree on a syntax. > > > > > >> Also good would be if an existing Morph could be moved to an external > >> window. From a menu choice would be entirely sufficient, but > >> super-bonus points for being able to drag it. This might also > >> facilitate a usage like this (but again not sure if thats a desirable > >> paradigm)... > > > > > > > >> > >> (Nautilus external openInOnPackage: nil) moveToExternalWindow. > >> (GTPlayground external openInOSWindow) moveToExternalWindow. > >> (ThreadSafeTranscript external openInOSWindow) moveToExternalWindow. > > > > > > This should be possible but I see two different ways of doing so : > > > > - First we could keep the same Morph and dynamically change some of its > > features to match the requirements of an external window ( for example > the > > action done when clicking on the close / expand / reduce boxes are not > the > > same but there are other differences). Then we remove it from the World > and > > open it in an OSWindow. > > - Or we could "save the state of the Morph" then delete it and directly > open > > a new one suited for external window. I've quoted "save the state of the > > Morph" because if this option is chosen it will need to be refined. > > > > As for the "drag it outside part" I am sure it could be done. Currently > when > > you are dragging a Morph, as soon as the HandMorph goes out of the World, > > when you release the mouse button the Morph goes back at its initial > place > > so we could just change this behavior to make it move to an external > window > > instead. But to be more flexible,maybe we could just keep both behavior > and > > chose between one and the other by pressing a hotkey while dragging the > > Morph. > > > > BTW, I've recorded a short video to show you what it is possible to do > with > > the new SDL version (it should also illustrate what I told Nicolai > earlier) > > : > > > > https://www.dropbox.com/s/m27aa0flanocnlr/OSWindowMorph.mkv?dl=0 > > > > As you can see if you put the Morph inside the boundaries of the World, > it > > seems as if it was actually opened in the world (put aside some > differences > > like the fonts etc. but this is only due to the Athens rendering of > Morphs > > and it won't matter in Bloc). > > For now it is heavily buggued (you can't opened two windows like that > > without crashing the VM :/) but SDL 2.0.4 is still in developement so I > > won't work more on it until it is released. > > > > > >> Where we have for example Meta-O-O to open a browser, it could be > >> Meta-E-O to open in an external window. > >> Also, a hotkey could be held down when opening from a menu - similar > >> paradigm to web browsers between opening a new tab or opening a new > >> window. > > > > > > Yeah that's a good idea. For the moment when opening from a menu the left > > and right clicks have the same behavior so it could even be something > like > > left click => world and right click => external window. > > > > > >> As well a Preference so that this can be set globally. A multitude of > >> open windows could be handled with a menu item in the task bar "Close > >> all > external windows". > >> > >> btw, I presume Morphs in these windows would still appear in the task > >> bar as usual. > > > > > > I am not sure about that because as OS - Windows they appear in the > taskbar > > of your OS and you can already manage them from here. > > Sure one option is to have a native window for every Morph. The other > is to have only a WorldMorph as a native window holding other Morphs. > I'm not sure which one I'd prefer, but I'd sure like the option of the > latter. An example use-case... Torsten's recent video of Pharo on > Raspberry Pie... not sure if the hardware is up to it, but it would be > great to have a Pharo application displaying on a low resolution > embedded LCD screen, with a normal development environment on a > standard sized screen running off the same Pie. > cheers -ben > > > > > > >> How will the existing World paradigm play into this? Will external > >> windows be part of the same World? Or maybe the existing World can > >> have another level below it called like World-Screen? > > > > > > The existing World paradigm will probably change with Bloc I guess. At > first > > I thought that all these windows could be part of the same Bloc-space and > > that this Bloc-space would be dedicated to held external windows but I > > really need to speak with Alain about that. > > > > Many thanks for your feedback and ideas ! > > > > Cheers, > > > > Matthieu > > > > 2015-05-30 8:16 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> > >> > >> - If possible I'd like not to have to modify any Bloc code. If it is not > >> possible then as little as possible. > >> > >>> What is the aversion here? Bloc is still developing and since its > >>> semantics are based on old-Morphic maybe this use-case is not > >>> considered. Adding this use-case may be an opportunity to make the > >>> overall system architecture simpler instead of needing workarounds. > >>> To what degree would Bloc already support this? > >> > >> > >> What matthieu wants to say is that opening a window in an external > sufrace > >> should > >> not impose to have some hacks into bloc and alain agrees with that and > >> will modify the > >> bloc architecture to handle separate native windows. > >>>> > >>>> - These windows should be persistent but maybe not exactly like > morphs. > >>>> It > >>>> could be a button that the user needs to press in the window to toggle > >>>> the > >>>> persistence on and off (a bit like in the world menu to stick it to > the > >>>> world if you see what I mean). > >> > >> > >> I'm not sure that you want to have that behavior. Open windows should be > >> persisted. > >> > >>> As well a Preference so that this can be set globally. A multitude of > >>> open windows could be handled with a menu item in the task bar "Close > >>> all > external windows". > >>> > >>> btw, I presume Morphs in these windows would still appear in the task > >>> bar as usual. > >>> > >>> > >> > >> > > > >

May 30, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] f6306b: 50075

by Esteban Lorenzano

weird, I donât :P > On 30 May 2015, at 18:25, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > Hum. I still have the issue on the version 50077 > http://puu.sh/i65bE/841f437d7d.png > > On 30 May 2015 at 18:20, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> thats fixed already, in version 50077 >> >> Esteban >> >>> On 30 May 2015, at 18:16, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: >>> >>> 15631 Change PluggableTextMorph in comment pane into a >>> RubScrolledTextMorph via RubScrolledTextModel: >>> >>> The comment pane have the text in black on the Dark Theme. Do we open >>> an issue to have the fonts in white on the dark theme in Rubric ? >>> >>> On 30 May 2015 at 10:21, GitHub <noreply(a)github.com> wrote: >>>> Branch: refs/heads/5.0 >>>> Home: https://github.com/pharo-project/pharo-core >>>> Commit: f6306b7d4c4b6efe1384e2c455ee4ac70e4e0d28 >>>> https://github.com/pharo-project/pharo-core/commit/f6306b7d4c4b6efe1384e2c4… >>>> Author: Jenkins Build Server <board(a)pharo-project.org> >>>> Date: 2015-05-30 (Sat, 30 May 2015) >>>> >>>> Changed paths: >>>> M FreeType.package/FT2Handle.class/class/class initialization/initialize.st >>>> A FreeType.package/FT2Handle.class/class/system startup/shutDown_.st >>>> M FreeType.package/FT2Handle.class/class/system startup/startUp_.st >>>> M Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/asserting/assertSelectedCompiledMethod.st >>>> M Nautilus.package/AbstractNautilusUI.class/definition.st >>>> A Nautilus.package/AbstractNautilusUI.class/instance/build ui text/buildNewCommentText.st >>>> M Nautilus.package/AbstractNautilusUI.class/instance/code panel/buildCodePanelWithCommentOnRight.st >>>> A Nautilus.package/AbstractNautilusUI.class/instance/newcomment/newCommentTextModel.st >>>> A Nautilus.package/AbstractNautilusUI.class/instance/newcomment/updateCommentWith_.st >>>> A Nautilus.package/AbstractNautilusUI.class/instance/newcomment/whenTextUpdatedInCommentPane_.st >>>> M Nautilus.package/NautilusUI.class/instance/accessing/selectedClassWithoutChangingSelection_.st >>>> M Nautilus.package/NautilusUI.class/instance/private/unselectClass.st >>>> M Nautilus.package/NautilusUI.class/instance/private/updateOnClassSelection.st >>>> R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50074.st >>>> A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50075.st >>>> R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50074.st >>>> A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50075.st >>>> M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st >>>> M Text-Edition.package/SimpleEditor.class/class/as yet unclassified/initializeCmdKeyShortcuts.st >>>> M Text-Edition.package/SimpleEditor.class/class/as yet unclassified/initializeShiftCmdKeyShortcuts.st >>>> M Text-Edition.package/SmalltalkEditor.class/class/keyboard shortcut tables/initializeCmdKeyShortcuts.st >>>> M Text-Edition.package/TextEditor.class/class/keyboard shortcut tables/initializeBasicCmdKeyShortcuts.st >>>> M Text-Edition.package/TextEditor.class/class/keyboard shortcut tables/initializeBasicShiftCmdKeyShortcuts.st >>>> >>>> Log Message: >>>> ----------- >>>> 50075 >>>> 15630 Remove duplicate shortcut definition (TextEditors actionMap vs KM) >>>> https://pharo.fogbugz.com/f/cases/15630 >>>> >>>> 15637 Fixed nautilus tests >>>> https://pharo.fogbugz.com/f/cases/15637 >>>> >>>> 15633 FT2Handle needs to cleanUp on exit, not on startup >>>> https://pharo.fogbugz.com/f/cases/15633 >>>> >>>> 15631 Change PluggableTextMorph in comment pane into a RubScrolledTextMorph via RubScrolledTextModel >>>> https://pharo.fogbugz.com/f/cases/15631 >>>> >>>> http://files.pharo.org/image/50/50075.zip >>>> >>>> >>> >>> >>> >>> -- >>> Cheers >>> Cyril Ferlicot >>> >> >> > > > > -- > Cheers > Cyril Ferlicot >

May 30, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] f6306b: 50075

by Cyril Ferlicot

Hum. I still have the issue on the version 50077 http://puu.sh/i65bE/841f437d7d.png On 30 May 2015 at 18:20, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > thats fixed already, in version 50077 > > Esteban > >> On 30 May 2015, at 18:16, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: >> >> 15631 Change PluggableTextMorph in comment pane into a >> RubScrolledTextMorph via RubScrolledTextModel: >> >> The comment pane have the text in black on the Dark Theme. Do we open >> an issue to have the fonts in white on the dark theme in Rubric ? >> >> On 30 May 2015 at 10:21, GitHub <noreply(a)github.com> wrote: >>> Branch: refs/heads/5.0 >>> Home: https://github.com/pharo-project/pharo-core >>> Commit: f6306b7d4c4b6efe1384e2c455ee4ac70e4e0d28 >>> https://github.com/pharo-project/pharo-core/commit/f6306b7d4c4b6efe1384e2c4… >>> Author: Jenkins Build Server <board(a)pharo-project.org> >>> Date: 2015-05-30 (Sat, 30 May 2015) >>> >>> Changed paths: >>> M FreeType.package/FT2Handle.class/class/class initialization/initialize.st >>> A FreeType.package/FT2Handle.class/class/system startup/shutDown_.st >>> M FreeType.package/FT2Handle.class/class/system startup/startUp_.st >>> M Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/asserting/assertSelectedCompiledMethod.st >>> M Nautilus.package/AbstractNautilusUI.class/definition.st >>> A Nautilus.package/AbstractNautilusUI.class/instance/build ui text/buildNewCommentText.st >>> M Nautilus.package/AbstractNautilusUI.class/instance/code panel/buildCodePanelWithCommentOnRight.st >>> A Nautilus.package/AbstractNautilusUI.class/instance/newcomment/newCommentTextModel.st >>> A Nautilus.package/AbstractNautilusUI.class/instance/newcomment/updateCommentWith_.st >>> A Nautilus.package/AbstractNautilusUI.class/instance/newcomment/whenTextUpdatedInCommentPane_.st >>> M Nautilus.package/NautilusUI.class/instance/accessing/selectedClassWithoutChangingSelection_.st >>> M Nautilus.package/NautilusUI.class/instance/private/unselectClass.st >>> M Nautilus.package/NautilusUI.class/instance/private/updateOnClassSelection.st >>> R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50074.st >>> A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50075.st >>> R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50074.st >>> A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50075.st >>> M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st >>> M Text-Edition.package/SimpleEditor.class/class/as yet unclassified/initializeCmdKeyShortcuts.st >>> M Text-Edition.package/SimpleEditor.class/class/as yet unclassified/initializeShiftCmdKeyShortcuts.st >>> M Text-Edition.package/SmalltalkEditor.class/class/keyboard shortcut tables/initializeCmdKeyShortcuts.st >>> M Text-Edition.package/TextEditor.class/class/keyboard shortcut tables/initializeBasicCmdKeyShortcuts.st >>> M Text-Edition.package/TextEditor.class/class/keyboard shortcut tables/initializeBasicShiftCmdKeyShortcuts.st >>> >>> Log Message: >>> ----------- >>> 50075 >>> 15630 Remove duplicate shortcut definition (TextEditors actionMap vs KM) >>> https://pharo.fogbugz.com/f/cases/15630 >>> >>> 15637 Fixed nautilus tests >>> https://pharo.fogbugz.com/f/cases/15637 >>> >>> 15633 FT2Handle needs to cleanUp on exit, not on startup >>> https://pharo.fogbugz.com/f/cases/15633 >>> >>> 15631 Change PluggableTextMorph in comment pane into a RubScrolledTextMorph via RubScrolledTextModel >>> https://pharo.fogbugz.com/f/cases/15631 >>> >>> http://files.pharo.org/image/50/50075.zip >>> >>> >> >> >> >> -- >> Cheers >> Cyril Ferlicot >> > > -- Cheers Cyril Ferlicot

May 30, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] f6306b: 50075

by Esteban Lorenzano

thats fixed already, in version 50077 Esteban > On 30 May 2015, at 18:16, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > 15631 Change PluggableTextMorph in comment pane into a > RubScrolledTextMorph via RubScrolledTextModel: > > The comment pane have the text in black on the Dark Theme. Do we open > an issue to have the fonts in white on the dark theme in Rubric ? > > On 30 May 2015 at 10:21, GitHub <noreply(a)github.com> wrote: >> Branch: refs/heads/5.0 >> Home: https://github.com/pharo-project/pharo-core >> Commit: f6306b7d4c4b6efe1384e2c455ee4ac70e4e0d28 >> https://github.com/pharo-project/pharo-core/commit/f6306b7d4c4b6efe1384e2c4… >> Author: Jenkins Build Server <board(a)pharo-project.org> >> Date: 2015-05-30 (Sat, 30 May 2015) >> >> Changed paths: >> M FreeType.package/FT2Handle.class/class/class initialization/initialize.st >> A FreeType.package/FT2Handle.class/class/system startup/shutDown_.st >> M FreeType.package/FT2Handle.class/class/system startup/startUp_.st >> M Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/asserting/assertSelectedCompiledMethod.st >> M Nautilus.package/AbstractNautilusUI.class/definition.st >> A Nautilus.package/AbstractNautilusUI.class/instance/build ui text/buildNewCommentText.st >> M Nautilus.package/AbstractNautilusUI.class/instance/code panel/buildCodePanelWithCommentOnRight.st >> A Nautilus.package/AbstractNautilusUI.class/instance/newcomment/newCommentTextModel.st >> A Nautilus.package/AbstractNautilusUI.class/instance/newcomment/updateCommentWith_.st >> A Nautilus.package/AbstractNautilusUI.class/instance/newcomment/whenTextUpdatedInCommentPane_.st >> M Nautilus.package/NautilusUI.class/instance/accessing/selectedClassWithoutChangingSelection_.st >> M Nautilus.package/NautilusUI.class/instance/private/unselectClass.st >> M Nautilus.package/NautilusUI.class/instance/private/updateOnClassSelection.st >> R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50074.st >> A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50075.st >> R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50074.st >> A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50075.st >> M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st >> M Text-Edition.package/SimpleEditor.class/class/as yet unclassified/initializeCmdKeyShortcuts.st >> M Text-Edition.package/SimpleEditor.class/class/as yet unclassified/initializeShiftCmdKeyShortcuts.st >> M Text-Edition.package/SmalltalkEditor.class/class/keyboard shortcut tables/initializeCmdKeyShortcuts.st >> M Text-Edition.package/TextEditor.class/class/keyboard shortcut tables/initializeBasicCmdKeyShortcuts.st >> M Text-Edition.package/TextEditor.class/class/keyboard shortcut tables/initializeBasicShiftCmdKeyShortcuts.st >> >> Log Message: >> ----------- >> 50075 >> 15630 Remove duplicate shortcut definition (TextEditors actionMap vs KM) >> https://pharo.fogbugz.com/f/cases/15630 >> >> 15637 Fixed nautilus tests >> https://pharo.fogbugz.com/f/cases/15637 >> >> 15633 FT2Handle needs to cleanUp on exit, not on startup >> https://pharo.fogbugz.com/f/cases/15633 >> >> 15631 Change PluggableTextMorph in comment pane into a RubScrolledTextMorph via RubScrolledTextModel >> https://pharo.fogbugz.com/f/cases/15631 >> >> http://files.pharo.org/image/50/50075.zip >> >> > > > > -- > Cheers > Cyril Ferlicot >

May 30, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] f6306b: 50075

by Cyril Ferlicot

15631 Change PluggableTextMorph in comment pane into a RubScrolledTextMorph via RubScrolledTextModel: The comment pane have the text in black on the Dark Theme. Do we open an issue to have the fonts in white on the dark theme in Rubric ? On 30 May 2015 at 10:21, GitHub <noreply(a)github.com> wrote: > Branch: refs/heads/5.0 > Home: https://github.com/pharo-project/pharo-core > Commit: f6306b7d4c4b6efe1384e2c455ee4ac70e4e0d28 > https://github.com/pharo-project/pharo-core/commit/f6306b7d4c4b6efe1384e2c4… > Author: Jenkins Build Server <board(a)pharo-project.org> > Date: 2015-05-30 (Sat, 30 May 2015) > > Changed paths: > M FreeType.package/FT2Handle.class/class/class initialization/initialize.st > A FreeType.package/FT2Handle.class/class/system startup/shutDown_.st > M FreeType.package/FT2Handle.class/class/system startup/startUp_.st > M Nautilus-Tests.package/PackageTreeNautilusTest.class/instance/asserting/assertSelectedCompiledMethod.st > M Nautilus.package/AbstractNautilusUI.class/definition.st > A Nautilus.package/AbstractNautilusUI.class/instance/build ui text/buildNewCommentText.st > M Nautilus.package/AbstractNautilusUI.class/instance/code panel/buildCodePanelWithCommentOnRight.st > A Nautilus.package/AbstractNautilusUI.class/instance/newcomment/newCommentTextModel.st > A Nautilus.package/AbstractNautilusUI.class/instance/newcomment/updateCommentWith_.st > A Nautilus.package/AbstractNautilusUI.class/instance/newcomment/whenTextUpdatedInCommentPane_.st > M Nautilus.package/NautilusUI.class/instance/accessing/selectedClassWithoutChangingSelection_.st > M Nautilus.package/NautilusUI.class/instance/private/unselectClass.st > M Nautilus.package/NautilusUI.class/instance/private/updateOnClassSelection.st > R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50074.st > A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50075.st > R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50074.st > A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50075.st > M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > M Text-Edition.package/SimpleEditor.class/class/as yet unclassified/initializeCmdKeyShortcuts.st > M Text-Edition.package/SimpleEditor.class/class/as yet unclassified/initializeShiftCmdKeyShortcuts.st > M Text-Edition.package/SmalltalkEditor.class/class/keyboard shortcut tables/initializeCmdKeyShortcuts.st > M Text-Edition.package/TextEditor.class/class/keyboard shortcut tables/initializeBasicCmdKeyShortcuts.st > M Text-Edition.package/TextEditor.class/class/keyboard shortcut tables/initializeBasicShiftCmdKeyShortcuts.st > > Log Message: > ----------- > 50075 > 15630 Remove duplicate shortcut definition (TextEditors actionMap vs KM) > https://pharo.fogbugz.com/f/cases/15630 > > 15637 Fixed nautilus tests > https://pharo.fogbugz.com/f/cases/15637 > > 15633 FT2Handle needs to cleanUp on exit, not on startup > https://pharo.fogbugz.com/f/cases/15633 > > 15631 Change PluggableTextMorph in comment pane into a RubScrolledTextMorph via RubScrolledTextModel > https://pharo.fogbugz.com/f/cases/15631 > > http://files.pharo.org/image/50/50075.zip > > -- Cheers Cyril Ferlicot

May 30, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 443652: 50064

by Ben Coman

On Mon, May 25, 2015 at 5:17 PM, GitHub <noreply(a)github.com> wrote: > > Log Message: > ----------- > 50064 > 15605 Update Rubric > https://pharo.fogbugz.com/f/cases/15605 > > http://files.pharo.org/image/50/50064.zip > I feel we have a hole in our process where integration of external packages is a bit opaque. Presumably there can be several Issues encompassed by one "Update External Package" integration, but how do we find which they are? Ideally all such issues would be automatically listed (maybe being attached as sub-case to integrated-Issue, or maybe by being marked "fixed upstream" and listed the integrated-issue.) Perhaps as a stop gap the comment on the integrated Slice/Configuration could be shown in this log. At least a chance to manually list several integrated imaged. P.S. I know this infrastructure usually falls to Esteban and he seems plenty busy with important stuff at the moment, so please just consider this low priority feedback. cheers -ben

May 30, 2015

Re: [Pharo-dev] monticello problems

by Bernardo Ezequiel Contreras

it's the same as this https://pharo.fogbugz.com/f/cases/15476/Duplicated-repositories-in-monticel… On Sat, May 30, 2015 at 12:39 PM, Ben Coman <btc(a)openinworld.com> wrote: > This has been for a while, even in Pharo 4 I think. I *assumed* it was by > design and I was just learning to live with it. > cheers -ben > > On Sat, May 30, 2015 at 6:07 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> Hi, >> >> Iâm having a lot of problems with monticello lately. >> And it is not just the change of MCLazyVersionInfo (that affects just the >> history). >> >> Now, looks like packages are keeping their own private list of >> repositories. Look at the example: >> >> >> >> >> Notice the âAllâ selection. Now see with âPackageâ selected: >> >> >> And it is breaking not just my nerves, but a lot of tools, etc. >> >> So, I donât know it this was on purpose to avoid repositories pollutionâ¦ >> but this is a bug or a bad change :) >> >> Can you confirm the problem? >> >> Esteban >> > > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

May 30, 2015

Re: [Pharo-dev] monticello problems

by Ben Coman

This has been for a while, even in Pharo 4 I think. I *assumed* it was by design and I was just learning to live with it. cheers -ben On Sat, May 30, 2015 at 6:07 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > Iâm having a lot of problems with monticello lately. > And it is not just the change of MCLazyVersionInfo (that affects just the > history). > > Now, looks like packages are keeping their own private list of > repositories. Look at the example: > > > > > Notice the âAllâ selection. Now see with âPackageâ selected: > > > And it is breaking not just my nerves, but a lot of tools, etc. > > So, I donât know it this was on purpose to avoid repositories pollutionâ¦ > but this is a bug or a bad change :) > > Can you confirm the problem? > > Esteban >

May 30, 2015

Re: [Pharo-dev] System Morphs in OSWindows

by Ben Coman

On Sat, May 30, 2015 at 4:16 PM, Matthieu Lacaton <matthieu.lacaton(a)gmail.com> wrote: >> I think it would be better to name these for their function rather >> than the package: >> Nautilus openInExternalWindowOnPackage: nil. >> GTPlayground external openInExternalWindow. >> ThreadSafeTranscript external openInExternalWindow. >> >> I don't know if its a workable idea, but maybe something like >> Nautilus external openInOSWindowOnPackage: nil. >> GTPlayground external openInOSWindow. >> ThreadSafeTranscript external openInOSWindow. > > > It is a workable idea, we just need to agree on a syntax. > > >> Also good would be if an existing Morph could be moved to an external >> window. From a menu choice would be entirely sufficient, but >> super-bonus points for being able to drag it. This might also >> facilitate a usage like this (but again not sure if thats a desirable >> paradigm)... > > > >> >> (Nautilus external openInOnPackage: nil) moveToExternalWindow. >> (GTPlayground external openInOSWindow) moveToExternalWindow. >> (ThreadSafeTranscript external openInOSWindow) moveToExternalWindow. > > > This should be possible but I see two different ways of doing so : > > - First we could keep the same Morph and dynamically change some of its > features to match the requirements of an external window ( for example the > action done when clicking on the close / expand / reduce boxes are not the > same but there are other differences). Then we remove it from the World and > open it in an OSWindow. > - Or we could "save the state of the Morph" then delete it and directly open > a new one suited for external window. I've quoted "save the state of the > Morph" because if this option is chosen it will need to be refined. > > As for the "drag it outside part" I am sure it could be done. Currently when > you are dragging a Morph, as soon as the HandMorph goes out of the World, > when you release the mouse button the Morph goes back at its initial place > so we could just change this behavior to make it move to an external window > instead. But to be more flexible,maybe we could just keep both behavior and > chose between one and the other by pressing a hotkey while dragging the > Morph. > > BTW, I've recorded a short video to show you what it is possible to do with > the new SDL version (it should also illustrate what I told Nicolai earlier) > : > > https://www.dropbox.com/s/m27aa0flanocnlr/OSWindowMorph.mkv?dl=0 > > As you can see if you put the Morph inside the boundaries of the World, it > seems as if it was actually opened in the world (put aside some differences > like the fonts etc. but this is only due to the Athens rendering of Morphs > and it won't matter in Bloc). > For now it is heavily buggued (you can't opened two windows like that > without crashing the VM :/) but SDL 2.0.4 is still in developement so I > won't work more on it until it is released. > > >> Where we have for example Meta-O-O to open a browser, it could be >> Meta-E-O to open in an external window. >> Also, a hotkey could be held down when opening from a menu - similar >> paradigm to web browsers between opening a new tab or opening a new >> window. > > > Yeah that's a good idea. For the moment when opening from a menu the left > and right clicks have the same behavior so it could even be something like > left click => world and right click => external window. > > >> As well a Preference so that this can be set globally. A multitude of >> open windows could be handled with a menu item in the task bar "Close >> all > external windows". >> >> btw, I presume Morphs in these windows would still appear in the task >> bar as usual. > > > I am not sure about that because as OS - Windows they appear in the taskbar > of your OS and you can already manage them from here. Sure one option is to have a native window for every Morph. The other is to have only a WorldMorph as a native window holding other Morphs. I'm not sure which one I'd prefer, but I'd sure like the option of the latter. An example use-case... Torsten's recent video of Pharo on Raspberry Pie... not sure if the hardware is up to it, but it would be great to have a Pharo application displaying on a low resolution embedded LCD screen, with a normal development environment on a standard sized screen running off the same Pie. cheers -ben > > >> How will the existing World paradigm play into this? Will external >> windows be part of the same World? Or maybe the existing World can >> have another level below it called like World-Screen? > > > The existing World paradigm will probably change with Bloc I guess. At first > I thought that all these windows could be part of the same Bloc-space and > that this Bloc-space would be dedicated to held external windows but I > really need to speak with Alain about that. > > Many thanks for your feedback and ideas ! > > Cheers, > > Matthieu > > 2015-05-30 8:16 GMT+02:00 stepharo <stepharo(a)free.fr>: >> >> >> - If possible I'd like not to have to modify any Bloc code. If it is not >> possible then as little as possible. >> >>> What is the aversion here? Bloc is still developing and since its >>> semantics are based on old-Morphic maybe this use-case is not >>> considered. Adding this use-case may be an opportunity to make the >>> overall system architecture simpler instead of needing workarounds. >>> To what degree would Bloc already support this? >> >> >> What matthieu wants to say is that opening a window in an external sufrace >> should >> not impose to have some hacks into bloc and alain agrees with that and >> will modify the >> bloc architecture to handle separate native windows. >>>> >>>> - These windows should be persistent but maybe not exactly like morphs. >>>> It >>>> could be a button that the user needs to press in the window to toggle >>>> the >>>> persistence on and off (a bit like in the world menu to stick it to the >>>> world if you see what I mean). >> >> >> I'm not sure that you want to have that behavior. Open windows should be >> persisted. >> >>> As well a Preference so that this can be set globally. A multitude of >>> open windows could be handled with a menu item in the task bar "Close >>> all > external windows". >>> >>> btw, I presume Morphs in these windows would still appear in the task >>> bar as usual. >>> >>> >> >> >

May 30, 2015

Re: [Pharo-dev] untypeable key combination

by Nicolai Hess

2015-05-30 16:01 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Nicolai Hess wrote > > I don't fully understand what to change. > > If Spur will be ready for the next release, why don't we just wait... > I would like to better understand what is the problem and I am sure there is some kind of software pattern to prevent this circular reference situation. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/untypeable-key-combination-tp4794607p4829511.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

May 30, 2015