<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
All of these requests seem to map to what we added to AWT in JDK 9.<br>
We did this because there'd been Apple specific APIs that came in
via the<br>
Apple port but were very iffy in terms of what was supported and it
was<br>
not a good idea to formally export them from the new desktop module.<br>
<br>
The java.awt.Desktop class was enhanced by the java.awt.desktop
package<br>
and all of these things are provided in a platform neutral way.<br>
You just query whether the support is available.<br>
<br>
These can even be used in a mixed AWT/FX application if you want a
solution now,<br>
but FX could have its own version of these.<br>
<br>
Nothing that mentions a platform (please!).<br>
<br>
-phil<br>
<br>
<div class="moz-cite-prefix">On 9/20/22 6:38 AM, Scott Palmer wrote:<br>
</div>
<blockquote type="cite" cite="mid:0D317235-1194-44F0-B989-AC81A5D40C64@gmail.com">
I always understood Alt+F4 as simply being a keyboard shortcut on
Windows for closing the window of the active application. The
same as clicking the close widget. I don’t think there is
anything special about it. As far as being an equivalent to the
macOS Quit action, I don’t think it is quite the same. Does an
application even know the difference between a window closed with
the widget vs. Alt+F4? <span style="caret-color: rgb(0, 0, 0);
color: rgb(0, 0, 0);">CTRL+F4 closes the current document window
or tab - similar to Command-W on macOS. </span>
<div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br>
</span></div>
<div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">I’m
not aware of any special handlers being called on Windows for
these shortcuts other than what is called when the equivalent
close widget is pressed. If I’m wrong about that, then sure, a
quit handler for JavaFX could be wired in to the same
mechanism automatically. Maybe Linux has an equivalent as
well, I don’t know.</span></div>
<div><font color="#000000"><span style="caret-color: rgb(0, 0,
0);"><br>
</span></font></div>
<div><font color="#000000"><span style="caret-color: rgb(0, 0,
0);">While we are at it, custom handling for the ‘About’
menu item in the application menu is also needed, is it not?
</span></font></div>
<div><font color="#000000"><span style="caret-color: rgb(0, 0,
0);"><br>
</span></font></div>
<div><font color="#000000"><span style="caret-color: rgb(0, 0,
0);">For now I’m currently using Jan Gassen’s port of
NSMenuFX to hook into this stuff. </span></font><a href="https://github.com/0x4a616e/NSMenuFX" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/0x4a616e/NSMenuFX</a><font color="#000000"><span style="caret-color: rgb(0, 0, 0);"><br>
</span></font>
<div><font color="#000000"><br>
</font>
<div><br>
<div dir="ltr">Scott</div>
</div>
</div>
</div>
<div dir="ltr"><br>
<blockquote type="cite">On Sep 20, 2022, at 5:55 AM, John
Hendrikx <a class="moz-txt-link-rfc2396E" href="mailto:john.hendrikx@gmail.com"><john.hendrikx@gmail.com></a> wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<p>What about Alt + F4 and Ctrl + F4 on Windows? Alt + F4
closes the application (which works with JavaFX already) and
Ctrl + F4 is supposed to close a single window, but that
doesn't work for JavaFX.</p>
<p>Also very much in favor of Keeping the API platform
neutral, that's just how Java has worked since its
inception.<br>
</p>
<p>--John<br>
</p>
<div class="moz-cite-prefix">On 20/09/2022 06:25, Scott Palmer
wrote:<br>
</div>
<blockquote type="cite" cite="mid:7DF75FDA-F634-4F74-ACDD-B4A8D3FF5634@gmail.com">
Windows applications often have an “Exit” menu item, but
since it isn’t standardized like it is on macOS, calling a
quit handler for it would need to be a manual step - but the
exact same method for the quit handler could be called,
leaving it up to the programmer to continue or not with the
application exit depending on the return value. This manual
coding isn’t a big deal since you would also need to have
some app-specific handling to avoid making an Exit menu item
on macOS, where it would look out of place.
<div><br>
</div>
<div>You could add a standard “requestExit()” method to
Platform that you could manually bind to an Exit menu item
on Windows or Linux, but it would be automatically called
via an internal macOS Quit handler implementation. The
implementation of Platform.requestExit() on *all*
platforms would call a boolean method if one was
registered and then conditionally call Platform.exit()
depending on the return value, the default being to always
exit if nothing was registered. On macOS it would pass on
the value to veto the native Quit handler as needed. <font color="#000000"><span style="caret-color: rgb(0, 0, 0);">I
haven’t checked, does Application.stop() get called on
macOS if you exit via the Quit menu or Command-Q? If
it doesn’t, that’s another benefit. This idea should
probably be opt-in via some API or system property, I
suppose it would have to be if it changes behaviour of
having Application.stop() called in some
circumstances. Or you can just make the setting of the
handler function the “opt-in”.</span></font></div>
<div><font color="#000000"><span style="caret-color: rgb(0,
0, 0);"><br>
</span></font>
<div>Btw, t<span style="caret-color: rgb(0, 0, 0); color:
rgb(0, 0, 0);">his reminds me of the long-standing
request for system tray support, along with with
various other features that have equivalents across
multiple OS’, like showing progress on the dock icon,
or a numbered badge (for notifications, or unread
msgs, etc). I think there are already issues in Jira
for these, maybe just as a general request to support
some features that AWT/Swing has that JFX is still
missing. Most of these features are available on both
Mac and Windows, possibly Linux. It would be
irritating to code to different APIs for each if it
can be avoided, so I agree with going for a
platform-neutral way.</span></div>
<div><font color="#000000"><span style="caret-color:
rgb(0, 0, 0);"><br>
</span></font></div>
<div><font color="#000000"><span style="caret-color:
rgb(0, 0, 0);">Cheers, </span></font></div>
<div><font color="#000000"><span style="caret-color:
rgb(0, 0, 0);"><br>
</span></font>
<div dir="ltr">Scott</div>
<div dir="ltr"><br>
<blockquote type="cite">On Sep 19, 2022, at 8:11 PM,
Kevin Rushforth <a class="moz-txt-link-rfc2396E" href="mailto:kevin.rushforth@oracle.com" moz-do-not-send="true"><kevin.rushforth@oracle.com></a>
wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr"> I don't see us adding 100s of
OS-specific API calls, but even if we did, going
down the path of exposing them as Mac APIs or
Windows APIs, doesn't really seem like the direction
we want to go. Whatever we do needs to balance the
desire to integrate with, e.g., the macOS or Windows
platform with a desire to leave the door open for it
to later be implemented on the other platform(s).
And the most cross-platform way to do that from an
API point of view is by defining API that delivers
the desired functionality in as platform-neutral a
way as possible. It also needs to fit cleanly into
the existing API.<br>
<br>
So in the specific case of a quit handler, we could
define a platform API that an app could call to
register a handler that gets called if the platform
quit menu is selected and is able to cancel the Quit
action(basically, that's what is being proposed). We
could decide to provide some way for an app to query
whether it is supported, but maybe we just don't
need to worry about it in this specific case. We
could just document that it will get called when the
platform quit action is called, if there is such an
action on that platform. Other than maybe mentioning
in the docs that the macOS system menu "quit" action
is an example of an action that would invoke this,
it doesn't need to be platform-specific. One
question to answer is whether we should just put
this in the Platform class (where we have other
similar "global" application state), the Application
class (which has the life-cycle APIs), or somewhere
else (which might make sense if we wanted to define
an analog to the AWT Desktop class, although the
existing Platform class already has some APIs like
this).<br>
<br>
-- Kevin<br>
<br>
<br>
<div class="moz-cite-prefix">On 9/19/2022 1:46 PM,
Andy Goryachev wrote:<br>
</div>
<blockquote type="cite" cite="mid:BL0PR10MB2948F5480A765DD3F0C73B78E54D9@BL0PR10MB2948.namprd10.prod.outlook.com">
<meta name="Generator" content="Microsoft Word 15
(filtered medium)">
<style>@font-face { font-family: "Cambria Math"; }@font-face { font-family: Calibri; }@font-face { font-family: "Times New Roman (Body CS)"; }p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif; }a:link, span.MsoHyperlink { color: blue; text-decoration: underline; }span.EmailStyle19 { font-family: "Courier New", serif; color: windowtext; }.MsoChpDefault { font-size: 10pt; }div.WordSection1 { page: WordSection1; }</style>
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">Thank you, Kevin. Your
insightful feedback always pulls the
discussion in the right direction.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">The initial problem we are
facing is access to Mac menu in general and
additional API specifically. I can see a
possibility of extending the list of APIs
that app devs would want on Mac growing, so
there should be a better way to add them.
Using hacks like com.apple.eawt, or system
properties is probably not the best
solution. Ideally, there should be away
that does not require creative linking of
stub classes on non-Mac platforms, i.e. we
should be able to use a single code base for
all the platforms.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">ConditionalFeature might
work well internally for openjfx, but I
don't think it is a good solution for
actually exposing the platform APIs to the
user.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">So, in order to provide
platform-specific API in such a way that
still allows for a single code base for
multiple platform, and one that potentially
scales to tens or hundreds of API calls, I
see two solutions:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">1. one start starts with a
single entry point, like PlatformAPI,
described earlier.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">2. a lookup-based approach,
where the client code requests a (possibly
fine-grained and narrowly defined)
implementation from the system. For
example:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">IMacMenu impl =
PlatformAPI.lookup(IMacMenu.class);<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">(where IMacMenu is an
interface that, in this example, provides
access to Mac menu, adding shutdown
listeners, and so forth).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">if we are on windows, this
method either returns null or throws an
exception, if we are on Mac, we get a
working instance (a singleton or a new
instance each time, depending on the
circumstances).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">This way we are free to
extend or version the APIs without modifying
the core classes.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">PlatformAPI.isSupported(IMacMenu.class)
might provide a way to see whether the
capability is present.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">The platform-specific
interfaces like IMacMenu might in turn
extend some base interface that provides
introspection into common properties, such
as version, description, possibly a list of
other similar capabilities that the platform
supports (may be a number of earlier
versions?) and so forth.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">What do you think?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">-andy<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">openjfx-dev
<a class="moz-txt-link-rfc2396E" href="mailto:openjfx-dev-retn@openjdk.org" moz-do-not-send="true"><openjfx-dev-retn@openjdk.org></a>
on behalf of Kevin Rushforth <a class="moz-txt-link-rfc2396E" href="mailto:kevin.rushforth@oracle.com" moz-do-not-send="true"><kevin.rushforth@oracle.com></a><br>
<b>Date: </b>Monday, 2022/09/19 at 09:33<br>
<b>To: </b><a class="moz-txt-link-abbreviated
moz-txt-link-freetext" href="mailto:openjfx-dev@openjdk.org" moz-do-not-send="true">openjfx-dev@openjdk.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:openjfx-dev@openjdk.org" moz-do-not-send="true"><openjfx-dev@openjdk.org></a><br>
<b>Subject: </b>Re: Provide Quit handler
for system menu bar<o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt">I like the idea of
looking at this holistically, even if we do
end up adding such features one at a time.<br>
<br>
As for how to expose such an API, I don't
much like the idea of exposing the
underlying platform explicitly unless there
is no viable alternative. A better approach
is one where a feature is optional based on
whether the platform you are running on
supports that feature. Especially given, as
you pointed out, that features that are only
available in one platform today might make
their way into other platforms tomorrow. As
for how to let an application know whether
they can use a particular API, we already
have ConditionalFeature, so adding to that
would be a reasonable thing to consider.<br>
<br>
-- Kevin<br>
<br>
<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">On 9/19/2022 9:06
AM, Andy Goryachev wrote:<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">Greetings!</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">Thank you for proposing a
solution, Florian. I wonder if we should
extrapolate the problem further. Given
the fact that app developers always need
access to platform specific APIs, be it
integration with Mac menu, perhaps we
should consider a way to do so in such a
way that does not require various tricks.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">For example, we might
invent a way to query whether we are
running on a certain platform and get the
corresponding APIs. Let's say the class
is PlatformAPI:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">These methods allow for
querying whether the specific platform
APIs are available</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">PlatformAPI.isWindows();</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">PlatformAPI.isMacOS();</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">PlatformAPI.isLinux(); //
isUnix()? isPosix() ?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">and these will actually
return a service object that provides
access to the APIs, or throws some kind of
exception:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">IWindowsAPI
PlatformAPI.getWindowsAPI();</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">IMacOSAPI
PlatformAPI.getMacOSAPI();</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">the service object
returned by one of these methods might
provide further information about the
platform version, as well as access to
platform-specific APIs.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">Another thought is
perhaps we ought to think about expanding
functionality that became available on
every platform in the XXI century
(example: going to sleep/hibernate).
Possibly external shutdown via Mac menu or
a signal discussed by the OP would be
considered as platform-independent.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">What do you think?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif">-andy</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier
New",serif"> </span><o:p></o:p></p>
<div style="border:none;border-top:solid
#B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">openjfx-dev
<a href="mailto:openjfx-dev-retn@openjdk.org" moz-do-not-send="true">
<openjfx-dev-retn@openjdk.org></a>
on behalf of Florian Kirmaier <a href="mailto:florian.kirmaier@gmail.com" moz-do-not-send="true">
<florian.kirmaier@gmail.com></a><br>
<b>Date: </b>Tuesday, 2022/09/13 at
08:11<br>
<b>To: </b><a href="mailto:openjfx-dev@openjdk.java.net" moz-do-not-send="true" class="moz-txt-link-freetext">openjfx-dev@openjdk.java.net</a>
<a href="mailto:openjfx-dev@openjdk.java.net" moz-do-not-send="true"><openjfx-dev@openjdk.java.net></a><br>
<b>Subject: </b>Provide Quit handler
for system menu bar</span><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Hi Everyone,</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><br>
In one project, we have to handle the
quit-logic for MacOS ourselves,<br>
when the <quit app> menu entry
is used.<br>
As background information - this menu
entry is set in the
class com.sun.glass.ui.mac.MacApplication.<br>
It's basically hard coded. Currently,
in this project, the menu entry
doesn't work in some cases.<br>
<br>
My Solution would be:<br>
<br>
Provide a method
"Platform.setQuiteHandler(Supplier<Boolean>)"<br>
This handler is called when quit
<appname> from the menu is
called.<br>
If the handler returns true, all
windows are closed. Otherwise, nothing
happens.<br>
<br>
It would look like the following:<br>
```<br>
/**<br>
* Sets the handler to be called when
the application is about to quit.<br>
* Currently, this can only happen on
MacOS.<br>
*<br>
* This handler is called, when the
user selects<br>
* the "Quit <appname>" from the
application menu.<br>
* When the provided handler returns
true,<br>
* the application will close all
windows.<br>
* If the handler returns false, the
application will not quit.<br>
*<br>
* @param The new quit handler.<br>
*/<br>
public static void
setQuitHandler(Supplier x) {<br>
...<br>
}<br>
```<br>
I've created a ticket for this topic. <a href="https://bugs.openjdk.org/browse/JDK-8293700" moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8293700</a></span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><br>
I've got a working version for this
change. </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">According to
Kevin Rushforth this need a prior
dicussion on the mailing list.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Any opinion
regarding this?<br>
<br>
I could provide a pullrequest, if
someone is interested.<br>
<br>
Florian Kirmaier</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</blockquote>
<br>
</body>
</html>