Quit and Windows user placement with VW Version 7.10.1 (OS X)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Quit and Windows user placement with VW Version 7.10.1 (OS X)

bernhardHoefner
Hello Group,
is it the normal behavior that "Quit VisualWorks" executed in a Window other than System Launcher does not quit VisualWorks but only the active window?

Is it the normal behavior with OS X that:
"System  Settings - Look And Feel - Window placement - By User" does not work properly:
        - new Browser and some other Windows are further placed automatic
        - mouse arrow does not skip from upper left corner to lower right corner after making first click
        - new windows does not appear at mouse arrow position for "open File Browser"

Does anyone know, how to change that annoying behavior?

Thanks, Bernhard


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Quit and Windows user placement with VW Version 7.10.1 (OS X)

bernhardHoefner
Hi All,
I tried it on MS-Windows, an there is the following behavior:
for 1.: no problem, because there is no menue entry "Quit VisualWorks"
on other Windows than the System Launcher
for 2.: same problem on MS-Windows
for 3.: no problem, works well
for 4.: no problem. works well

Is it only my MAC that makes the problem or is it normal behavior? Or
doesn't bother it others than me?

I am surprised about the inconstistencies because of my first
experiences with Smalltalk 80 in 1990 / 91. We visited Georg Heeg and we
had questions about some behavior of Smalltalk and why some things are
other than we expected. These days we thoght our "problem points" would
be due to the incapacities of the implementation. But every question was
perfectly answered and always there was a good reason, why the
implementation was like it was. We were very impressed about all that
and left with the two ideas, that st80 gives no restrictions and that
really every behavior of the system is well-thought-out. Thats, why I am
surprised about the inconstistencies now.

Regards, Bernhard

Am 18.07.2014 15:58, schrieb Bernhard Höfner:

> Hello Group,
> 1. Is it the normal behavior that "Quit VisualWorks" executed in a Window other than System Launcher does not quit VisualWorks but only the active window?
>
> Is it the normal behavior with OS X that:
> "System  Settings - Look And Feel - Window placement - By User" does not work properly:
> 2. new Browser and some other Windows are further placed automatic
> 3. mouse arrow does not skip from upper left corner to lower right corner after making first click
> 4. new windows does not appear at mouse arrow position for "open File Browser"
>
> Does anyone know, how to change that annoying behavior?
>
> Thanks, Bernhard
>
>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Quit and Windows user placement with VW Version 7.10.1 (OS X)

Niall Ross
Dear Bernhard,
    FWIW, AFAICS it has been that way since 7.6.

That the RB ignores the user-placement setting when opening also occurs
on Windows.  This behaviour started in 7.6 - it respects the
user-placement setting in 7.5 and earlier on both Windows and Mac.  
(This fact causes me to think that very few of our current users choose
user-placement of opening windows.)

Other windows respect the user-placement setting.  The mouse jumps to
the lower-left on Windows from 7.10.1 all the way back.  On Mac, it does
not from 7.10.1 back through 7.6 at least.  (My hasty attempt to test in
7.5 on Mac met problems which might explain why the attempt to move the
mouse to the lower-left corner was abandoned for Mac in 7.6, or might
just be concealing whatever state it had in 7.5.)

On MAC, the response to APPLE+Q is not platform-faithful unless the
VisualLauncher is the active window.  This is true in 7.10.1 back
through 7.5 and probably all the way back.  As you note, quitting the
app on APPLE+Q (or its menu) does not have a precise equivalent on other
platforms, but would be the behaviour expected of any app on Mac.

Nothing to offer here except this info since I'm not much of a UI guy.

             Yours faithfully
                   Niall Ross

> Hi All,
> I tried it on MS-Windows, an there is the following behavior:
> for 1.: no problem, because there is no menue entry "Quit VisualWorks"
> on other Windows than the System Launcher
> for 2.: same problem on MS-Windows
> for 3.: no problem, works well
> for 4.: no problem. works well
>
> Is it only my MAC that makes the problem or is it normal behavior? Or
> doesn't bother it others than me?
>
> I am surprised about the inconstistencies because of my first
> experiences with Smalltalk 80 in 1990 / 91. We visited Georg Heeg and
> we had questions about some behavior of Smalltalk and why some things
> are other than we expected. These days we thoght our "problem points"
> would be due to the incapacities of the implementation. But every
> question was perfectly answered and always there was a good reason,
> why the implementation was like it was. We were very impressed about
> all that and left with the two ideas, that st80 gives no restrictions
> and that really every behavior of the system is well-thought-out.
> Thats, why I am surprised about the inconstistencies now.
>
> Regards, Bernhard
>
> Am 18.07.2014 15:58, schrieb Bernhard Höfner:
>
>> Hello Group,
>> 1. Is it the normal behavior that "Quit VisualWorks" executed in a
>> Window other than System Launcher does not quit VisualWorks but only
>> the active window?
>>
>> Is it the normal behavior with OS X that:
>> "System  Settings - Look And Feel - Window placement - By User" does
>> not work properly:
>>     2. new Browser and some other Windows are further placed automatic
>>     3. mouse arrow does not skip from upper left corner to lower
>> right corner after making first click
>>     4. new windows does not appear at mouse arrow position for "open
>> File Browser"
>>
>> Does anyone know, how to change that annoying behavior?
>>
>> Thanks, Bernhard
>>
>>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Quit and Windows user placement with VW Version 7.10.1 (OS X)

Antony Blakey-5

On 28 Jul 2014, at 0:46, Niall Ross <[hidden email]> wrote:

> Dear Bernhard,
>   FWIW, AFAICS it has been that way since 7.6.
>
> That the RB ignores the user-placement setting when opening also occurs on Windows.  This behaviour started in 7.6 - it respects the user-placement setting in 7.5 and earlier on both Windows and Mac.  (This fact causes me to think that very few of our current users choose user-placement of opening windows.)
>
> Other windows respect the user-placement setting.  The mouse jumps to the lower-left on Windows from 7.10.1 all the way back.  On Mac, it does not from 7.10.1 back through 7.6 at least.  (My hasty attempt to test in 7.5 on Mac met problems which might explain why the attempt to move the mouse to the lower-left corner was abandoned for Mac in 7.6, or might just be concealing whatever state it had in 7.5.)
>
> On MAC, the response to APPLE+Q is not platform-faithful unless the VisualLauncher is the active window.  This is true in 7.10.1 back through 7.5 and probably all the way back.  As you note, quitting the app on APPLE+Q (or its menu) does not have a precise equivalent on other platforms, but would be the behaviour expected of any app on Mac.
>
> Nothing to offer here except this info since I'm not much of a UI guy.

We are considering taking the user-placement option out of OSX and Windows, since that's not platform compliant. On X11 we should pick up the option from the OS if possible.

As far as Cmd-Q goes, there are a number of things we are considering that will impact that:

1. Allowing hierarchic composition of the menu response process, so you can trigger (e.g.) launcher menus in any context; and
2. Allowing the launcher menu on OSX to become the native main menu bar, once again with a hierarchic responder chain; and
3. Allowing menus to be automatically constructed using hierarchically composed command discovery - this could put a Quit item in every window.

These features interact, and in particular, doing #3 may eliminate the need to do #1. Note also that the launcher is an IDE feature, but the concept is applicable to end-user applications.

Of course plans may change - nothing is certain until shipped.

Antony Blakey
--------------------------
Ph: +61 438 840 787

Plurality is not to be assumed without necessity
  -- William of Ockham (ca. 1285-1349)




_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Quit and Windows user placement with VW Version 7.10.1 (OS X)

Karsten Kusche
Hi Anthony,

the CMD-Q problem doesn’t only involve the Menu. The implementation to close the frontmost window, when the VM receives a terminate signal is just plain wrong. 

On Windows it is possible to configure the VM to respond to terminate-requests (ObjectMemory registerObject: aBoolean withEngineFor:’acceptQuitEvents'). 

On the Mac this option is simply ignored and when you try to shut down your mac and the VM receives the termination request, it cancels that request and closes the frontmost window. 
So if you try to shutdown your mac, VisualWorks cancels the shutdown, forcing you to manually quit VisualWorks. Then you need to tell the system again to shutdown. With OS X trying to reopen your applications after a shutdown, the apps that were closed before VisualWorks stopped the shutdown, need to be launched manually. All these problems makes that bug extremely annoying to say the least.

On Linux the 'acceptQuitEvents' option is also ignore, but at least the VM quits when it receives the terminate signal.

Kind Regards
Karsten


-- 
Karsten Kusche - Dipl. Inf. (FH) - [hidden email]
Georg Heeg eK - Köthen
Handelsregister: Amtsgericht Dortmund A 12812 

Am Sonntag, 27. Juli 2014 um 21:29 schrieb Antony Blakey:


On 28 Jul 2014, at 0:46, Niall Ross <[hidden email]> wrote:

Dear Bernhard,
FWIW, AFAICS it has been that way since 7.6.

That the RB ignores the user-placement setting when opening also occurs on Windows. This behaviour started in 7.6 - it respects the user-placement setting in 7.5 and earlier on both Windows and Mac. (This fact causes me to think that very few of our current users choose user-placement of opening windows.)

Other windows respect the user-placement setting. The mouse jumps to the lower-left on Windows from 7.10.1 all the way back. On Mac, it does not from 7.10.1 back through 7.6 at least. (My hasty attempt to test in 7.5 on Mac met problems which might explain why the attempt to move the mouse to the lower-left corner was abandoned for Mac in 7.6, or might just be concealing whatever state it had in 7.5.)

On MAC, the response to APPLE+Q is not platform-faithful unless the VisualLauncher is the active window. This is true in 7.10.1 back through 7.5 and probably all the way back. As you note, quitting the app on APPLE+Q (or its menu) does not have a precise equivalent on other platforms, but would be the behaviour expected of any app on Mac.

Nothing to offer here except this info since I'm not much of a UI guy.

We are considering taking the user-placement option out of OSX and Windows, since that's not platform compliant. On X11 we should pick up the option from the OS if possible.

As far as Cmd-Q goes, there are a number of things we are considering that will impact that:

1. Allowing hierarchic composition of the menu response process, so you can trigger (e.g.) launcher menus in any context; and
2. Allowing the launcher menu on OSX to become the native main menu bar, once again with a hierarchic responder chain; and
3. Allowing menus to be automatically constructed using hierarchically composed command discovery - this could put a Quit item in every window.

These features interact, and in particular, doing #3 may eliminate the need to do #1. Note also that the launcher is an IDE feature, but the concept is applicable to end-user applications.

Of course plans may change - nothing is certain until shipped.

Antony Blakey
--------------------------
Ph: +61 438 840 787

Plurality is not to be assumed without necessity
-- William of Ockham (ca. 1285-1349)




_______________________________________________
vwnc mailing list


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Quit and Windows user placement with VW Version 7.10.1 (OS X)

Antony Blakey-5

On 28 Jul 2014, at 17:08, Karsten Kusche <[hidden email]> wrote:

> Hi Anthony,
>
> the CMD-Q problem doesn’t only involve the Menu. The implementation to close the frontmost window, when the VM receives a terminate signal is just plain wrong.

I know that the menu isn't the issue - it's a VM issue currently, but the point is that it shouldn't be handled in the VM at all (at least on OSX). The ability to allow or deny a termination request must be in the image, not determined by the VM.

Antony Blakey
--------------------------
Ph: +61 438 840 787

Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.
 -- Albert Einstein


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Quit and Windows user placement with VW Version 7.10.1 (OS X)

bernhardHoefner
In reply to this post by Antony Blakey-5
Hi Niall, Antony and Karsten,
thank you for addressing my request. I am sorry to hear that user
placement is planned to be droped on WIN and OSX (the platforms I use).
I liked this user placement from the beginning and I was always
surprised, that this was not offered as an option by these platforms.

Regards, Bernhard


Am 27.07.2014 21:29, schrieb Antony Blakey:

> On 28 Jul 2014, at 0:46, Niall Ross <[hidden email]> wrote:
>
>> Dear Bernhard,
>>    FWIW, AFAICS it has been that way since 7.6.
>>
>> That the RB ignores the user-placement setting when opening also occurs on Windows.  This behaviour started in 7.6 - it respects the user-placement setting in 7.5 and earlier on both Windows and Mac.  (This fact causes me to think that very few of our current users choose user-placement of opening windows.)
>>
>> Other windows respect the user-placement setting.  The mouse jumps to the lower-left on Windows from 7.10.1 all the way back.  On Mac, it does not from 7.10.1 back through 7.6 at least.  (My hasty attempt to test in 7.5 on Mac met problems which might explain why the attempt to move the mouse to the lower-left corner was abandoned for Mac in 7.6, or might just be concealing whatever state it had in 7.5.)
>>
>> On MAC, the response to APPLE+Q is not platform-faithful unless the VisualLauncher is the active window.  This is true in 7.10.1 back through 7.5 and probably all the way back.  As you note, quitting the app on APPLE+Q (or its menu) does not have a precise equivalent on other platforms, but would be the behaviour expected of any app on Mac.
>>
>> Nothing to offer here except this info since I'm not much of a UI guy.
> We are considering taking the user-placement option out of OSX and Windows, since that's not platform compliant. On X11 we should pick up the option from the OS if possible.
>
> As far as Cmd-Q goes, there are a number of things we are considering that will impact that:
>
> 1. Allowing hierarchic composition of the menu response process, so you can trigger (e.g.) launcher menus in any context; and
> 2. Allowing the launcher menu on OSX to become the native main menu bar, once again with a hierarchic responder chain; and
> 3. Allowing menus to be automatically constructed using hierarchically composed command discovery - this could put a Quit item in every window.
>
> These features interact, and in particular, doing #3 may eliminate the need to do #1. Note also that the launcher is an IDE feature, but the concept is applicable to end-user applications.
>
> Of course plans may change - nothing is certain until shipped.
>
> Antony Blakey
> --------------------------
> Ph: +61 438 840 787
>
> Plurality is not to be assumed without necessity
>    -- William of Ockham (ca. 1285-1349)
>
>
>
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Video Player Widget?

Hildebrant, Richard
In reply to this post by Karsten Kusche

Hello,

                Does anyone know about playing video files in a VW application?  Perhaps a video player widget of some sort?  Any info or pointers appreciated.

 

Thanks,

Rick Hildebrant


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Video Player Widget?

David Buck-2
One easy option on Windows is to use ActiveX to embed IE and use that to play a video. 

David Buck


Simberon Incorporated
www.simberon.com



-------- Original message --------
From: "Hildebrant, Richard"
Date:08/27/2014 6:36 PM (GMT-05:00)
To: VWNC
Subject: [vwnc] Video Player Widget?

Hello,

                Does anyone know about playing video files in a VW application?  Perhaps a video player widget of some sort?  Any info or pointers appreciated.

 

Thanks,

Rick Hildebrant


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: Video Player Widget?

Holger Kleinsorgen
In reply to this post by Hildebrant, Richard
Hildebrant, Richard wrote
Hello,
                Does anyone know about playing video files in a VW application?  Perhaps a video player widget of some sort?  Any info or pointers appreciated.
A long time ago, I've published an interafce for VLC (http://www.videolan.org/vlc) in the public repository.
It might or might not still work...
Reply | Threaded
Open this post in threaded view
|

Why does window shrink when moved?

Hildebrant, Richard
In reply to this post by Karsten Kusche

Hello,

                When building a user interface with UIPainter, its window can be sized up to its max, which can be specified in the settings tool.   The window will open to that specified size when it is run, but then shrinks in height a bit when it is moved.  Is there some other setting on the window’s size that I’m missing?  Any suggesting/comments appreciated.

 

Thanks,

Rick Hildebrant


Notice: This email and any attachments may contain proprietary (Draper non-public) and/or export-controlled information of Draper Laboratory. If you are not the intended recipient of this email, please immediately notify the sender by replying to this email and immediately destroy all copies of this email.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc