One complaint about Pharo
One of the big issues I have with Pharo is that Iâm stuck on a single screen, unlike Cincom Smalltalk that uses separate OS windows that I can spread over multiple screens. Iâm assuming this is a hard limit in OSX, but itâs a bit annoying. Yes, Self has the same issue, and itâs just as annoying. Dave
Hi, I remember the Mars project (see http://marsonpharo.wordpress.com/2013/09/16/mars-widgets-and-layouts-examples/[1] ) but don't know the current status... Laurent Le jeudi 15 mai 2014, 13:21:25 David Astels a écrit :
One of the big issues I have with Pharo is that Iâm stuck on a single screen, unlike Cincom Smalltalk that uses separate OS windows that I can spread over multiple screens. Iâm assuming this is a hard limit in OSX, but itâs a bit annoying. Yes, Self has the same issue, and itâs just as annoying.
Dave
-------- [1] http://marsonpharo.wordpress.com/2013/09/16/mars-widgets-and-layouts-example...
On Thu, May 15, 2014 at 11:21 AM, David Astels <dastels@icloud.com> wrote:
One of the big issues I have with Pharo is that Iâm stuck on a single screen, unlike Cincom Smalltalk that uses separate OS windows that I can spread over multiple screens. Iâm assuming this is a hard limit in OSX, but itâs a bit annoying. Yes, Self has the same issue, and itâs just as annoying.
Vassili Bykov did native host windows for Windows above Squeak and the Squeak VM in Newspeak. This code could be ported. There was a scheme called "native windows" in Welsh (something "Ffenestri" IIRC) that apparently worked. Esteban Lorenzano has looked at native windows in Pharo and (I think) got something working, right Esteban? There's nothing intrinsic that says native windows can't be done. It's just more maintennance work, and I guess the pressure is not intense enough to bring it about. That single screen has its advantages. It's a very cosy place to be :-) Dave -- best, Eliot
2014-05-15 16:57 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>:
That single screen has its advantages. It's a very cosy place to be :-)
+1 Plus... unless we got independent process/queues per window (like Smalltalk/X [1]) I don't see the advantage from the development standpoint. Regards, [1] In St/X you can kill a window without killing the whole image. Pretty useful if you mess up something :)
I am implementing native window support for Pharo, in the form of OSWindow, using SDL2. This is also requires a custom VM, so its going to take some time. We originally started making OSWindow with Igor, to have a more direct display of graphics to avoid GPU->CPU->GPU frame-buffer round-trip when using OpenGL in Pharo. And also as an opportunity to remove all the graphics code from the VM, which we did for the Linux version. The VM changes includes adding a small check to the VM heartbeat for pending events. If there are pending events, a Semaphore is signaled to wake up a thread(a Process) that handles events in the image side. Igor made this change. The other changes in the VM include the removal of the old graphic code. We already did this cleanup with Igor for the Linux VM. Windows and Mac are next. Currently the work is mostly done for Linux. In Window I could make it work by adding the event check call to the event loop. But when looking to the Windows code, it gives me a huge desire to kill it. OSWindow have the following capabilities: - Native operating system window creation. - Event handling - Support for having different kinds of renderers. As for the renderers, we have: - Form renderer that we used to display the main Pharo window. - OpenGL renderer that provides an OpenGL context. This one requires external bindings for OpenGL, such as the ones in NBOpenGL. Attached is a screenshot of OSWindow with the main Pharo window and OpenGL working. 2014-05-15 16:05 GMT-04:00 Esteban A. Maringolo <emaringolo@gmail.com>:
2014-05-15 16:57 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>:
That single screen has its advantages. It's a very cosy place to be :-)
+1
Plus... unless we got independent process/queues per window (like Smalltalk/X [1]) I don't see the advantage from the development standpoint.
Regards,
[1] In St/X you can kill a window without killing the whole image. Pretty useful if you mess up something :)
yes⦠we have a version of mars that more or less works. Never announced because there is a lot of other âsmall detailsâ to fix, but someone could actually do a desktop app with it. Now⦠there is a difference between making a desktop app and developing with pharo. For desktop apps is most probably that you will want multi windows (even if regularly *you do not use them*, as experience shows: most apps are a single window + dialogs [1][2][3]. Anyway, even if experience says the opposite, you will want many windows). Now, the way pharo is conceived will never work in a multiwindow environment. Just imaging your 10-15 browsers + 5-6 workspaces opened alog with all your other windows (browsers, mails, text editors. terminals, games, whatever). That just cannot work. I have seen this before. People is so used to have it that they *believe* they need it. Just to realise that pharo workflow has nothing to do with a (for example) java workflow. but yes⦠we need to support multiwindows. Not for pharo IDE, but for pharo desktop apps. cheers, Esteban [1] http://upload.wikimedia.org/wikipedia/commons/f/f2/Giancarlo_Mora_Blender_Ju... [2] http://theopensourcery.com/images/javajspEclipse.gif [3] http://microsoft-news.com/wp-content/uploads/2013/10/Outlook-Mail-App-Window... On 15 May 2014, at 22:05, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2014-05-15 16:57 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>:
That single screen has its advantages. It's a very cosy place to be :-)
+1
Plus... unless we got independent process/queues per window (like Smalltalk/X [1]) I don't see the advantage from the development standpoint.
Regards,
[1] In St/X you can kill a window without killing the whole image. Pretty useful if you mess up something :)
yes you are right too. Because I'm realy efficient with my messy single window desktop :) Stef On 15/5/14 23:18, Esteban Lorenzano wrote:
yes⦠we have a version of mars that more or less works. Never announced because there is a lot of other âsmall detailsâ to fix, but someone could actually do a desktop app with it. Now⦠there is a difference between making a desktop app and developing with pharo. For desktop apps is most probably that you will want multi windows (even if regularly *you do not use them*, as experience shows: most apps are a single window + dialogs [1][2][3]. Anyway, even if experience says the opposite, you will want many windows). Now, the way pharo is conceived will never work in a multiwindow environment. Just imaging your 10-15 browsers + 5-6 workspaces opened alog with all your other windows (browsers, mails, text editors. terminals, games, whatever). That just cannot work. I have seen this before. People is so used to have it that they *believe* they need it. Just to realise that pharo workflow has nothing to do with a (for example) java workflow.
but yes⦠we need to support multiwindows. Not for pharo IDE, but for pharo desktop apps.
cheers, Esteban
[1] http://upload.wikimedia.org/wikipedia/commons/f/f2/Giancarlo_Mora_Blender_Ju... [2] http://theopensourcery.com/images/javajspEclipse.gif [3] http://microsoft-news.com/wp-content/uploads/2013/10/Outlook-Mail-App-Window...
On 15 May 2014, at 22:05, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2014-05-15 16:57 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>:
That single screen has its advantages. It's a very cosy place to be :-) +1
Plus... unless we got independent process/queues per window (like Smalltalk/X [1]) I don't see the advantage from the development standpoint.
Regards,
[1] In St/X you can kill a window without killing the whole image. Pretty useful if you mess up something :)
As one begins to expand their work into multiple images, one host window per ends up being the only practical way to keep it managed. On Thu, May 15, 2014 at 1:21 PM, David Astels <dastels@icloud.com> wrote:
One of the big issues I have with Pharo is that Iâm stuck on a single screen, unlike Cincom Smalltalk that uses separate OS windows that I can spread over multiple screens. Iâm assuming this is a hard limit in OSX, but itâs a bit annoying. Yes, Self has the same issue, and itâs just as annoying.
Dave
We fully agree. We will work on - real headless - move to the image the windowing logic (because right now it is encoded in the VM) But this is work. Igor and Ronie did already a good experience and they got it working on Linux. You can play with it and give us feedback. Then we will probably interface with SDL2. On 15/5/14 20:21, David Astels wrote:
One of the big issues I have with Pharo is that Iâm stuck on a single screen, unlike Cincom Smalltalk that uses separate OS windows that I can spread over multiple screens. Iâm assuming this is a hard limit in OSX, but itâs a bit annoying. Yes, Self has the same issue, and itâs just as annoying.
Dave
participants (8)
-
Chris Muller -
David Astels -
Eliot Miranda -
Esteban A. Maringolo -
Esteban Lorenzano -
Laurent Laffont -
Ronie Salgado -
stepharo