pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Brown <gkbr...@mac.com>
Subject Re: new DesktopApplicationContext
Date Sun, 28 Jun 2009 14:09:29 GMT
We intentionally don't provide access to the frame, since, in general,  
a Pivot application shouldn't need to be aware of the specific  
application context in which it is running. Providing access to the  
frame would be analogous to giving an application in a Windows VM  
access to the VMware Workstation instance in which it is running. It's  
just not a use case that the Pivot platform attempts to address.

That said, we don't preclude doing something like this. I think this  
is a good example of when you might want to create your own concrete  
subclass of ApplicationContext. That way, you are free to do whatever  
you like with your containing frame.


On Jun 27, 2009, at 5:05 PM, Edgar Merino wrote:

> I need to access the frame directly, along with some of its  
> properties, for
> example I have one application where I had to made the frame  
> undecorated, so
> I had to implement listeners to minimize/maximize/close the  
> application. For
> this I needed to have access to the frame. Even if the
> DesktopApplicationContext stays like it is right now, it would be  
> good to
> have access to the frame directly (or think of a way to implement the
> functionality described above).
> Edgar Merino
> 2009/6/27 Greg Brown <gkbrown@mac.com>
>> The main reason I modified the existing DesktopApplicationContext was
>>> because I needed to set some properties on the HostFrame that were  
>>> not
>>> possible with the current implementation.
>> Can you be more specific? What properties did you need access to?
>>  I still haven't really thought on what I need to implement the wtkx
>>> visualizer
>> You may want to consider creating a "WTK Visualizer" instead and  
>> providing
>> an implementation for WTKXSerializer#writeObject() (or something  
>> along those
>> lines).

View raw message