Disclaimer: I don't really know the Morph & Bloc architectures. Just a
few comments from a user perspective.
On Sat, May 30, 2015 at 2:42 AM, Matthieu Lacaton
<matthieu.laca...@gmail.com> wrote:
> Hello everybody,
>
> Lately I've tried to use OSWindow to display some "system morphs" in
> external windows.
> I thought it could be handy mainly for people working on multiple displays
> so they could open a debuguer in a display while seeing the results in
> another one for example or many other cases.
This is great +1000.
>
> I've developped a prototype and if you are interested you can find it by
> loading OSWindow + OSWindow-SDL2-Canvases :
>
> Gofer it
> smalltalkhubUser: 'Pharo' project: 'OSWindow';
> package: 'OSWindow-Core';
> package: 'OSWindow-SDL2';
> package: 'OSWindow-SDL2-Canvases';
> load.
>
>
> Inside there is only support for Nautilus, Playground and Transcript.
> To launch them you can evaluate the following commands:
>
> Nautilus openInOSWindowOnPackage: nil.
> GTPlayground openInOSWindow.
> ThreadSafeTranscript openInOSWindow.
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.
>
> They are not really functionnal because I only implemented some things here
> and there.
> What you can probably use are :
> - The little boxes on the topleft.
> - Shortcuts but there is probably a bug so you can only use "alt" on Linux.
> - Right click menus only in Nautilus and in the three top panes.
> - The printIt popper Morph in the Playground should work too.
> - There is some persistence but only when you "save and quit". If you save
> and then quit without saving the windows won't persist.
>
> If you want to try it feel free to try eveything you want but keep in mind
> that :
>
> - It is very buggued (especially the menus)
> - It is probably unstable so try it in a dedicated image :p
> - Many things are not doable and will result in weird behaviours or bugs
> - The code is probably very bad
> - I've coded it on Linux and the last time I tried it on windows it didn't
> work well at all so it probably won't work on windows. I don't know for mac.
>
> That being said, I am willing to start again and to do it properly "for
> real" but for Bloc instead of Morphic and this is the reason of this mail.
> As I am very new to all this and very unexperimented, I'd like to have your
> insight about some things and maybe a bit of help too :p
>
> First, to start on a solid basis I need to find the best possible
> architecture / pattern to develop it.
> The first requirements I can think of are the following :
>
> - The user must be able to chose if he wants to open these Morphs in the
> world or in external windows.
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.
> - It should not be too difficult for him to open them in external windows (a
> button or an option or a shortcut, I don't really know but it is not really
> cool to evaluate a command line).
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.
> - It needs to be robust and evolutive. It means that, for example, if
> Nautilus was to change it should still be able to be opened in an external
> window without much trouble. If a whole new tool was to be added into Pharo
> it should be able to be opened in an external window without much trouble
> too.
> - 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?
> - 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).
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.
>
> So do you have any idea how I could structure the code to meet these
> requirements ?
> One idea was to use the strategy pattern to change between the world and an
> external window.
> But what could be the best way to "plug" this code to Bloc ?
> Maybe we could create some sort of a virtual "Bloc-Space" that would be
> dedicated to open all the OSWindow Morphs ?
>
> In my opinion the OSWindow is just another possible container to display the
> Morphs so it should not interfere with their underlaying mechanisms.
> If you look a bit at my prototype code, I took many shortcuts to take
> decisions based of some window events but I think it is plain bad. The
> events should just be relayed to the Morphs and the Morphs (their
> controller) should be responsible for taking a decision and controling the
> window.
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?
>
>
>
> All in all, if you have any idea to help me do something clean it would be
> much appreciated (It will still be intern-code though but maybe I can make
> it not THAT bad :p)
>
> Thanks a lot,
>
> Matthieu
