enaml and deferred_call

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

enaml and deferred_call

Lee Taylor
I have a simple application that has a main window with two push
buttons.  One is enable and the other is not.  When One is pushed I want
button Two to be enabled.  This works as expected.  If I add a call to
create a subwindow when One is pushed, then button Two is not enabled
until the main window is minimized and restored.  But if I created the
other window with a call to deferred_call, it works as expected.

The call to deferred_call seems kludgy to me.  Is this the expected
behavior or is there a better solution?

I am using enaml 6.8 on linux.  For testing I have found it necessary to
move the original window before pushing button One since the subwindow
will be created overlapping the main window.  Then exposing or moving
the main window will cause button Two to be enabled.

Lee Taylor


_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev

subwindow1.enaml (725 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: enaml and deferred_call

John Wiggins
Howdy,
Using deferred_call here is not really what you want. I would recommend using 'session.add_window()' instead. I've attached a version of your file that works on 0.6.8. If this is new code which you are developing, I strongly recommend that you look at the most current version of enaml, which is being maintained by Chris Colbert <https://github.com/nucleic/enaml>.

-- John





On Oct 5, 2013, at 3:00 AM, Lee Taylor <[hidden email]> wrote:

> I have a simple application that has a main window with two push buttons.  One is enable and the other is not.  When One is pushed I want button Two to be enabled.  This works as expected.  If I add a call to create a subwindow when One is pushed, then button Two is not enabled until the main window is minimized and restored.  But if I created the other window with a call to deferred_call, it works as expected.
>
> The call to deferred_call seems kludgy to me.  Is this the expected behavior or is there a better solution?
>
> I am using enaml 6.8 on linux.  For testing I have found it necessary to move the original window before pushing button One since the subwindow will be created overlapping the main window.  Then exposing or moving the main window will cause button Two to be enabled.
>
> Lee Taylor
>
> <subwindow1.enaml>_______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev

subwindow1_fixed.enaml (700 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: enaml and deferred_call

Lee Taylor
On 10/07/13 06:46, John Wiggins wrote:

> Using deferred_call here is not really what you want. I would recommend
> using 'session.add_window()' instead. I've attached a version of your
> file that works on 0.6.8.

I tried the attached version and it did not fix my problem.

                 c_win = ContentWindow(main, title='Child Window')
                 session.add_window(c_win)

There is a comment in enaml/examples/widgets/popup_windows.enaml:
When a window is created without a parent, its lifetime is tied to that
of the session. That is, it is a free living top level window. In order
for such windows to be used, they be associated with a session. This is
done by calling the `add_window` method on the session, and passing it
the newly constructed window instance.

The way I read this, since I have main as the first argument to
ContentWindow, then add_window does not do anything.  Is that correct?


> If this is new code which you are developing,
> I strongly recommend that you look at the most current version of enaml,
> which is being maintained by Chris Colbert
> <https://github.com/nucleic/enaml>.

I looked at this repository and have several questions.  It seems that
all new development on enaml is now done by Nucleic Development Team
since Chris Colbert has left Enthought.  The version at nucleic/enaml is
listed as 0.8.1.  Does this replace the Enthought version?

I also noticed that Traits has been replaced by Atom. How do I mix
Traits and enaml?  Do I need to use enthought/traits-enaml: A library to
facilitate interoperation of Traits with Enaml >= 0.7.

Are there plans to include the nucleic version in Canopy?  Is there a
roadmap on the web somewhere I can reference?

Thanks,
Lee Taylor



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: enaml and deferred_call

Didrik Pinte-2
On 8 October 2013 23:55, Lee Taylor <[hidden email]> wrote:

> On 10/07/13 06:46, John Wiggins wrote:
>
>> Using deferred_call here is not really what you want. I would recommend
>> using 'session.add_window()' instead. I've attached a version of your
>> file that works on 0.6.8.
>
> I tried the attached version and it did not fix my problem.
>
>                  c_win = ContentWindow(main, title='Child Window')
>                  session.add_window(c_win)
>
> There is a comment in enaml/examples/widgets/popup_windows.enaml:
> When a window is created without a parent, its lifetime is tied to that
> of the session. That is, it is a free living top level window. In order
> for such windows to be used, they be associated with a session. This is
> done by calling the `add_window` method on the session, and passing it
> the newly constructed window instance.
>
> The way I read this, since I have main as the first argument to
> ContentWindow, then add_window does not do anything.  Is that correct?
>
>
>> If this is new code which you are developing,
>> I strongly recommend that you look at the most current version of enaml,
>> which is being maintained by Chris Colbert
>> <https://github.com/nucleic/enaml>.
>
> I looked at this repository and have several questions.  It seems that
> all new development on enaml is now done by Nucleic Development Team
> since Chris Colbert has left Enthought.  The version at nucleic/enaml is
> listed as 0.8.1.  Does this replace the Enthought version?

The repo at Enthought contains version 0.6 which is in use in some of
our customer project. Until we have migrated them to the new 0.7/0.8,
we will need to keep this repo alive. Officially the latest enaml
version is 0.8 and maintained by Nucleic.

> I also noticed that Traits has been replaced by Atom. How do I mix
> Traits and enaml?  Do I need to use enthought/traits-enaml: A library to
> facilitate interoperation of Traits with Enaml >= 0.7.

Yes, you have to use traits-enaml to make Traits talk with Enaml widgets.

> Are there plans to include the nucleic version in Canopy?  Is there a
> roadmap on the web somewhere I can reference?

They are definitely plans to have the latest enaml in the Canopy
repositories but no publicized roadmap.

HTH.

-- Didrik
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: enaml and deferred_call

Lee Taylor
On 10/09/13 00:01, Didrik Pinte wrote:

> On 8 October 2013 23:55, Lee Taylor <[hidden email]> wrote:
>> On 10/07/13 06:46, John Wiggins wrote:
>>
>>> Using deferred_call here is not really what you want. I would recommend
>>> using 'session.add_window()' instead. I've attached a version of your
>>> file that works on 0.6.8.
>>
>> I tried the attached version and it did not fix my problem.
>>
>>                   c_win = ContentWindow(main, title='Child Window')
>>                   session.add_window(c_win)
>>

I tried this change on enaml-8.1 and it cannot find session:
     session.add_window(c_win)
NameError: name 'session' is not defined

Looking at enaml/application.py, all of the session code has been removed.

             clicked ::
                 print "pushed one"
                 main.enable_button = True
                 ContentWindow(main, title='Child Window')

This enables the button using 8.1, but the new window does not appear.
None of the examples create an additional window. Any guidance?


>> Are there plans to include the nucleic version in Canopy?  Is there a
>> roadmap on the web somewhere I can reference?
>
> They are definitely plans to have the latest enaml in the Canopy
> repositories but no publicized roadmap.

I just wanted to make sure that I would be using an 'official' version.

Thanks,
Lee Taylor

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: enaml and deferred_call

Lee Taylor
In reply to this post by Didrik Pinte-2
On 10/09/13 00:01, Didrik Pinte wrote:

> On 8 October 2013 23:55, Lee Taylor <[hidden email]> wrote:
>> On 10/07/13 06:46, John Wiggins wrote:
>>
>>> Using deferred_call here is not really what you want. I would recommend
>>> using 'session.add_window()' instead. I've attached a version of your
>>> file that works on 0.6.8.
>>
>> I tried the attached version and it did not fix my problem.
>>
>>                   c_win = ContentWindow(main, title='Child Window')
>>                   session.add_window(c_win)
>>

Using enaml 0.8.1, this worked:

                 ContentWindow(main, title='Child Window').show()

Lee Taylor


_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev