pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edgar Merino <donvo...@gmail.com>
Subject Re: new DesktopApplicationContext
Date Sun, 28 Jun 2009 19:47:45 GMT
    Ok then, I won't mess with DesktopApplicationContext anymore, although I
still think a more object oriented approach should be available to get into
some properties of the windowedHostFrame, instead of passing them as String
parameters, just a suggestion.

Edgar Merino






2009/6/28 Greg Brown <gkbrown@mac.com>

> 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.
>
> Greg
>
>
>
> 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).
>>>
>>>
>>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message