System Morphs in OSWindows
Locked
 
|
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. 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. 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. - 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). - 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. - 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). 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. 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 |
|
|
2015-05-29 20:42 GMT+02:00 Matthieu Lacaton <[hidden email]>:
It works on windows (apart from the known issue, no text input in the mainwindow and inappropiate window position). |
|
|
Okay, thanks for the feedback ! The inappropriate window position is just because for some reasons Linux count 0@0 with the decorations whereas windows count it without the decorations so I should probably make them appear at 20@20 or something like that.2015-05-29 22:31 GMT+02:00 Nicolai Hess <[hidden email]>:
|
|
|
2015-05-29 22:47 GMT+02:00 Matthieu Lacaton <[hidden email]>:
you can set the position option "undefined" and the window will be place somewhere, but with fully visible decoration
If there aren't any decorations, why does it have a titlebar?
No need to, the cause is already found and I proposed a solution. Losing keyboard after instanciation of the OSSDL2Driver
|
|
|
In reply to this post by Matthieu
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 <[hidden email]> 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 |
|
|
- 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. > > |
|
|
I think it would be better to name these for their function rather 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 (Nautilus external openInOnPackage: nil) 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 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 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. How will the existing World paradigm play into this? Will external 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 <[hidden email]>:
|
|
|
Oh by the way for some reasons, the quality of the video is really crappy if you watch it directly from Dropbox but if you download it, it is much better. I don't know why :/ 2015-05-30 10:16 GMT+02:00 Matthieu Lacaton <[hidden email]>:
|
|
|
In reply to this post by Matthieu
On Sat, May 30, 2015 at 4:16 PM, Matthieu Lacaton
<[hidden email]> 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 <[hidden email]>: >> >> >> - 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. >>> >>> >> >> > |
|
|
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 <[hidden email]>:
|
|
|
On Sun, May 31, 2015 at 1:10 AM, Matthieu Lacaton
<[hidden email]> wrote: > I am not sure I understand the first part of your mail. On Windows I often use dual-screen (two normal size screens). Typically an application's <Maximise> button maximises to a single screen only. So I need to manually resize the window to get with Pharo to cover both screens. Other applications** tend to provide two windows, so that each can be <Maximised> to a screen each. It seems SDL provides the potential to do this, but your example shows each tool being opened in its own native window. It could be good for Pharo to have a native window per screen, so that Pharo tools opened within that window. For example, from a browser in a second (SDL) window, do <senders> will bring up that tool in the same window as the browser. But others may prefer every tool open in its own native window. So do whatever is easiest first. cheers -ben > 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 <[hidden email]>: >> >> On Sat, May 30, 2015 at 4:16 PM, Matthieu Lacaton >> <[hidden email]> 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 <[hidden email]>: >> >> >> >> >> >> - 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. >> >>> >> >>> >> >> >> >> >> > >> > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |