enaml dockpane woes

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

enaml dockpane woes

Mike Sarahan
Hello,

I'm banging my head trying to separate undesirable behaviors with DockPanes that I see.  I have no idea where to start.  I'm attaching several files that demonstrate the bugs for me.  I hope you are able to just run them to see the symptom.

My system is Windows x64, EPD 7.3, enaml from git head, just pulled.

Thanks for any tips!
Mike

Files: Note that aside from the "ViewToolBar", all other things labeled Toolbar are actually containers.

image_test_OK.enaml:
A reference implementation.  This one works exactly as I expect.

image_test_groupbox.enaml:
If a groupbox is added to my container, the groupbox overlaps with the other buttons in the container.  Additionally, it defeats the minimum-size limiting of the container.  The layout of the buttons is also messed up - the button adjacent to the groupbox is aligned with the top of the groupbox, while all other buttons are aligned with the bottom of the container

image_test_one_dockpane.enaml:
If I comment out either of the dockpanes in this example, the image does not show for the remaining dock pane.

image_test_combobox.enaml:
If a combobox is added to my container, the image for that dockpane is not shown.

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

image_test_groupbox.enaml (8K) Download Attachment
image_test_OK.enaml (8K) Download Attachment
image_test_one_dockpane.enaml (8K) Download Attachment
image_test_combobox.enaml (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: enaml dockpane woes

Chris Colbert



On Sun, Jan 27, 2013 at 10:45 PM, Mike Sarahan <[hidden email]> wrote:
Hello,

I'm banging my head trying to separate undesirable behaviors with DockPanes that I see.  I have no idea where to start.  I'm attaching several files that demonstrate the bugs for me.  I hope you are able to just run them to see the symptom.

My system is Windows x64, EPD 7.3, enaml from git head, just pulled.

Thanks for any tips!
Mike

Files: Note that aside from the "ViewToolBar", all other things labeled Toolbar are actually containers.

image_test_OK.enaml:
A reference implementation.  This one works exactly as I expect.

image_test_groupbox.enaml:
If a groupbox is added to my container, the groupbox overlaps with the other buttons in the container.  Additionally, it defeats the minimum-size limiting of the container.  The layout of the buttons is also messed up - the button adjacent to the groupbox is aligned with the top of the groupbox, while all other buttons are aligned with the bottom of the container


You are mixing constraints here. A GroupBox is also a container, and applies constraints to its children:

    constraints = [
        hbox(save, prev_image, next_image, crop, map_label, group)
    ]
    PushButton: crop:
        text = "Crop cells"
        enabled << controller.image_UI_enabled
    GroupBox: group:
        Label: map_label:
            text = "Characteristic Map:"
        ComboBox: characteristic:
            items = ["Shift", "Height", "Orientation", "Eccentricity"]
            enabled << controller.image_UI_enabled 

`map_label` is getting constrained by the GroupBox as well as the parent of the group box. You can just set the `title` attribute of the GroupBox here instead.

As an aside, how did you figure out that you could inherit identifiers when you subclass from an enamldef? That was an undocumented feature, because I was never quite sure it was a proper thing to have. Some of the experimental work I have going on with augmented scopes removes this "feature". I'll probably expose a different way of getting into the parentclass scope, however.

image_test_one_dockpane.enaml:
If I comment out either of the dockpanes in this example, the image does not show for the remaining dock pane.


That's interesting. My current machine doesn't have Chaco installed, so I can't test this, but I suspect it may have something to do with Qt not liking main windows without a central widget. I'll have to confirm on a different machine. In the meantime, what happens if you just declare an empty Container in the MainWindow for use as the central widget?
 
image_test_combobox.enaml:
If a combobox is added to my container, the image for that dockpane is not shown.


Nothing obvious is jumping out at me here either, I will need to test on a machine tomorrow with Chaco.
 
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: enaml dockpane woes

Mike Sarahan
Regarding the groupbox: thanks, that clears that up well.

Regarding identifier inheritance: I'd say dumb luck.  I certainly wasn't clever about it.  I think I just treated it as I would a python class, and it worked, so I went with it.  My train of thought was that it looked a lot like Traits, but inverted right to left.  Does that make sense?

With the main window idea, here's what I think you meant to try:

(under Main)
    Container:
        pass
    ImageViewDockPane: image_view:
      controller = ImageModel()
      p << main.controller
      title << "Image view"
      dock_area = 'left'
      visible := main.controller.show_image_view

(other dock pane commented out)

The behavior is the same.  If I uncomment the second dock pane, both images are present.  However, with the empty Container, the automatic resizing/filling is not as nice - the images in either plot seem to have a maximum size (not the same size - the one on the right is smaller), and each dock pane hugs their respective sides.  The gap between them grows as the window is enlarged.

Without the empty container, the gap between them stays constant, and the automatic resizing/refilling makes the images fill up to the whole screen (within the limits of maintaining the aspect ratio.)

Thanks for looking into this.
Mike


On Sun, Jan 27, 2013 at 9:13 PM, Chris Colbert <[hidden email]> wrote:



On Sun, Jan 27, 2013 at 10:45 PM, Mike Sarahan <[hidden email]> wrote:
Hello,

I'm banging my head trying to separate undesirable behaviors with DockPanes that I see.  I have no idea where to start.  I'm attaching several files that demonstrate the bugs for me.  I hope you are able to just run them to see the symptom.

My system is Windows x64, EPD 7.3, enaml from git head, just pulled.

Thanks for any tips!
Mike

Files: Note that aside from the "ViewToolBar", all other things labeled Toolbar are actually containers.

image_test_OK.enaml:
A reference implementation.  This one works exactly as I expect.

image_test_groupbox.enaml:
If a groupbox is added to my container, the groupbox overlaps with the other buttons in the container.  Additionally, it defeats the minimum-size limiting of the container.  The layout of the buttons is also messed up - the button adjacent to the groupbox is aligned with the top of the groupbox, while all other buttons are aligned with the bottom of the container


You are mixing constraints here. A GroupBox is also a container, and applies constraints to its children:

    constraints = [
        hbox(save, prev_image, next_image, crop, map_label, group)
    ]
    PushButton: crop:
        text = "Crop cells"
        enabled << controller.image_UI_enabled
    GroupBox: group:
        Label: map_label:
            text = "Characteristic Map:"
        ComboBox: characteristic:
            items = ["Shift", "Height", "Orientation", "Eccentricity"]
            enabled << controller.image_UI_enabled 

`map_label` is getting constrained by the GroupBox as well as the parent of the group box. You can just set the `title` attribute of the GroupBox here instead.

As an aside, how did you figure out that you could inherit identifiers when you subclass from an enamldef? That was an undocumented feature, because I was never quite sure it was a proper thing to have. Some of the experimental work I have going on with augmented scopes removes this "feature". I'll probably expose a different way of getting into the parentclass scope, however.

image_test_one_dockpane.enaml:
If I comment out either of the dockpanes in this example, the image does not show for the remaining dock pane.


That's interesting. My current machine doesn't have Chaco installed, so I can't test this, but I suspect it may have something to do with Qt not liking main windows without a central widget. I'll have to confirm on a different machine. In the meantime, what happens if you just declare an empty Container in the MainWindow for use as the central widget?
 
image_test_combobox.enaml:
If a combobox is added to my container, the image for that dockpane is not shown.


Nothing obvious is jumping out at me here either, I will need to test on a machine tomorrow with Chaco.
 
_______________________________________________
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



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

Re: enaml dockpane woes

Simon Jagoe
I have no problem with any of your examples with enaml 0.6.7. I always see the dock panes that are defined in the file.


On Mon, Jan 28, 2013 at 5:46 AM, Mike Sarahan <[hidden email]> wrote:
Regarding the groupbox: thanks, that clears that up well.

Regarding identifier inheritance: I'd say dumb luck.  I certainly wasn't clever about it.  I think I just treated it as I would a python class, and it worked, so I went with it.  My train of thought was that it looked a lot like Traits, but inverted right to left.  Does that make sense?

With the main window idea, here's what I think you meant to try:

(under Main)
    Container:
        pass
    ImageViewDockPane: image_view:
      controller = ImageModel()
      p << main.controller
      title << "Image view"
      dock_area = 'left'
      visible := main.controller.show_image_view

(other dock pane commented out)

The behavior is the same.  If I uncomment the second dock pane, both images are present.  However, with the empty Container, the automatic resizing/filling is not as nice - the images in either plot seem to have a maximum size (not the same size - the one on the right is smaller), and each dock pane hugs their respective sides.  The gap between them grows as the window is enlarged.

Without the empty container, the gap between them stays constant, and the automatic resizing/refilling makes the images fill up to the whole screen (within the limits of maintaining the aspect ratio.)

Thanks for looking into this.
Mike


On Sun, Jan 27, 2013 at 9:13 PM, Chris Colbert <[hidden email]> wrote:



On Sun, Jan 27, 2013 at 10:45 PM, Mike Sarahan <[hidden email]> wrote:
Hello,

I'm banging my head trying to separate undesirable behaviors with DockPanes that I see.  I have no idea where to start.  I'm attaching several files that demonstrate the bugs for me.  I hope you are able to just run them to see the symptom.

My system is Windows x64, EPD 7.3, enaml from git head, just pulled.

Thanks for any tips!
Mike

Files: Note that aside from the "ViewToolBar", all other things labeled Toolbar are actually containers.

image_test_OK.enaml:
A reference implementation.  This one works exactly as I expect.

image_test_groupbox.enaml:
If a groupbox is added to my container, the groupbox overlaps with the other buttons in the container.  Additionally, it defeats the minimum-size limiting of the container.  The layout of the buttons is also messed up - the button adjacent to the groupbox is aligned with the top of the groupbox, while all other buttons are aligned with the bottom of the container


You are mixing constraints here. A GroupBox is also a container, and applies constraints to its children:

    constraints = [
        hbox(save, prev_image, next_image, crop, map_label, group)
    ]
    PushButton: crop:
        text = "Crop cells"
        enabled << controller.image_UI_enabled
    GroupBox: group:
        Label: map_label:
            text = "Characteristic Map:"
        ComboBox: characteristic:
            items = ["Shift", "Height", "Orientation", "Eccentricity"]
            enabled << controller.image_UI_enabled 

`map_label` is getting constrained by the GroupBox as well as the parent of the group box. You can just set the `title` attribute of the GroupBox here instead.

As an aside, how did you figure out that you could inherit identifiers when you subclass from an enamldef? That was an undocumented feature, because I was never quite sure it was a proper thing to have. Some of the experimental work I have going on with augmented scopes removes this "feature". I'll probably expose a different way of getting into the parentclass scope, however.

image_test_one_dockpane.enaml:
If I comment out either of the dockpanes in this example, the image does not show for the remaining dock pane.


That's interesting. My current machine doesn't have Chaco installed, so I can't test this, but I suspect it may have something to do with Qt not liking main windows without a central widget. I'll have to confirm on a different machine. In the meantime, what happens if you just declare an empty Container in the MainWindow for use as the central widget?
 
image_test_combobox.enaml:
If a combobox is added to my container, the image for that dockpane is not shown.


Nothing obvious is jumping out at me here either, I will need to test on a machine tomorrow with Chaco.
 
_______________________________________________
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



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




--
Simon Jagoe
Enthought Ltd
+44 79 312 11 506
[hidden email]

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

Re: enaml dockpane woes

Mike Sarahan

You see the images in all of the panes?

What platform?

On Jan 28, 2013 9:40 AM, "Simon Jagoe" <[hidden email]> wrote:
I have no problem with any of your examples with enaml 0.6.7. I always see the dock panes that are defined in the file.


On Mon, Jan 28, 2013 at 5:46 AM, Mike Sarahan <[hidden email]> wrote:
Regarding the groupbox: thanks, that clears that up well.

Regarding identifier inheritance: I'd say dumb luck.  I certainly wasn't clever about it.  I think I just treated it as I would a python class, and it worked, so I went with it.  My train of thought was that it looked a lot like Traits, but inverted right to left.  Does that make sense?

With the main window idea, here's what I think you meant to try:

(under Main)
    Container:
        pass
    ImageViewDockPane: image_view:
      controller = ImageModel()
      p << main.controller
      title << "Image view"
      dock_area = 'left'
      visible := main.controller.show_image_view

(other dock pane commented out)

The behavior is the same.  If I uncomment the second dock pane, both images are present.  However, with the empty Container, the automatic resizing/filling is not as nice - the images in either plot seem to have a maximum size (not the same size - the one on the right is smaller), and each dock pane hugs their respective sides.  The gap between them grows as the window is enlarged.

Without the empty container, the gap between them stays constant, and the automatic resizing/refilling makes the images fill up to the whole screen (within the limits of maintaining the aspect ratio.)

Thanks for looking into this.
Mike


On Sun, Jan 27, 2013 at 9:13 PM, Chris Colbert <[hidden email]> wrote:



On Sun, Jan 27, 2013 at 10:45 PM, Mike Sarahan <[hidden email]> wrote:
Hello,

I'm banging my head trying to separate undesirable behaviors with DockPanes that I see.  I have no idea where to start.  I'm attaching several files that demonstrate the bugs for me.  I hope you are able to just run them to see the symptom.

My system is Windows x64, EPD 7.3, enaml from git head, just pulled.

Thanks for any tips!
Mike

Files: Note that aside from the "ViewToolBar", all other things labeled Toolbar are actually containers.

image_test_OK.enaml:
A reference implementation.  This one works exactly as I expect.

image_test_groupbox.enaml:
If a groupbox is added to my container, the groupbox overlaps with the other buttons in the container.  Additionally, it defeats the minimum-size limiting of the container.  The layout of the buttons is also messed up - the button adjacent to the groupbox is aligned with the top of the groupbox, while all other buttons are aligned with the bottom of the container


You are mixing constraints here. A GroupBox is also a container, and applies constraints to its children:

    constraints = [
        hbox(save, prev_image, next_image, crop, map_label, group)
    ]
    PushButton: crop:
        text = "Crop cells"
        enabled << controller.image_UI_enabled
    GroupBox: group:
        Label: map_label:
            text = "Characteristic Map:"
        ComboBox: characteristic:
            items = ["Shift", "Height", "Orientation", "Eccentricity"]
            enabled << controller.image_UI_enabled 

`map_label` is getting constrained by the GroupBox as well as the parent of the group box. You can just set the `title` attribute of the GroupBox here instead.

As an aside, how did you figure out that you could inherit identifiers when you subclass from an enamldef? That was an undocumented feature, because I was never quite sure it was a proper thing to have. Some of the experimental work I have going on with augmented scopes removes this "feature". I'll probably expose a different way of getting into the parentclass scope, however.

image_test_one_dockpane.enaml:
If I comment out either of the dockpanes in this example, the image does not show for the remaining dock pane.


That's interesting. My current machine doesn't have Chaco installed, so I can't test this, but I suspect it may have something to do with Qt not liking main windows without a central widget. I'll have to confirm on a different machine. In the meantime, what happens if you just declare an empty Container in the MainWindow for use as the central widget?
 
image_test_combobox.enaml:
If a combobox is added to my container, the image for that dockpane is not shown.


Nothing obvious is jumping out at me here either, I will need to test on a machine tomorrow with Chaco.
 
_______________________________________________
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



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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: enaml dockpane woes

Simon Jagoe
I tried that in Windows XP and Ubuntu 12.10 both with enaml 0.6.7

I see two DockPanes defined in the code, and in all cases I see an image in them.


On Mon, Jan 28, 2013 at 5:57 PM, Mike Sarahan <[hidden email]> wrote:

You see the images in all of the panes?

What platform?

On Jan 28, 2013 9:40 AM, "Simon Jagoe" <[hidden email]> wrote:
I have no problem with any of your examples with enaml 0.6.7. I always see the dock panes that are defined in the file.


On Mon, Jan 28, 2013 at 5:46 AM, Mike Sarahan <[hidden email]> wrote:
Regarding the groupbox: thanks, that clears that up well.

Regarding identifier inheritance: I'd say dumb luck.  I certainly wasn't clever about it.  I think I just treated it as I would a python class, and it worked, so I went with it.  My train of thought was that it looked a lot like Traits, but inverted right to left.  Does that make sense?

With the main window idea, here's what I think you meant to try:

(under Main)
    Container:
        pass
    ImageViewDockPane: image_view:
      controller = ImageModel()
      p << main.controller
      title << "Image view"
      dock_area = 'left'
      visible := main.controller.show_image_view

(other dock pane commented out)

The behavior is the same.  If I uncomment the second dock pane, both images are present.  However, with the empty Container, the automatic resizing/filling is not as nice - the images in either plot seem to have a maximum size (not the same size - the one on the right is smaller), and each dock pane hugs their respective sides.  The gap between them grows as the window is enlarged.

Without the empty container, the gap between them stays constant, and the automatic resizing/refilling makes the images fill up to the whole screen (within the limits of maintaining the aspect ratio.)

Thanks for looking into this.
Mike


On Sun, Jan 27, 2013 at 9:13 PM, Chris Colbert <[hidden email]> wrote:



On Sun, Jan 27, 2013 at 10:45 PM, Mike Sarahan <[hidden email]> wrote:
Hello,

I'm banging my head trying to separate undesirable behaviors with DockPanes that I see.  I have no idea where to start.  I'm attaching several files that demonstrate the bugs for me.  I hope you are able to just run them to see the symptom.

My system is Windows x64, EPD 7.3, enaml from git head, just pulled.

Thanks for any tips!
Mike

Files: Note that aside from the "ViewToolBar", all other things labeled Toolbar are actually containers.

image_test_OK.enaml:
A reference implementation.  This one works exactly as I expect.

image_test_groupbox.enaml:
If a groupbox is added to my container, the groupbox overlaps with the other buttons in the container.  Additionally, it defeats the minimum-size limiting of the container.  The layout of the buttons is also messed up - the button adjacent to the groupbox is aligned with the top of the groupbox, while all other buttons are aligned with the bottom of the container


You are mixing constraints here. A GroupBox is also a container, and applies constraints to its children:

    constraints = [
        hbox(save, prev_image, next_image, crop, map_label, group)
    ]
    PushButton: crop:
        text = "Crop cells"
        enabled << controller.image_UI_enabled
    GroupBox: group:
        Label: map_label:
            text = "Characteristic Map:"
        ComboBox: characteristic:
            items = ["Shift", "Height", "Orientation", "Eccentricity"]
            enabled << controller.image_UI_enabled 

`map_label` is getting constrained by the GroupBox as well as the parent of the group box. You can just set the `title` attribute of the GroupBox here instead.

As an aside, how did you figure out that you could inherit identifiers when you subclass from an enamldef? That was an undocumented feature, because I was never quite sure it was a proper thing to have. Some of the experimental work I have going on with augmented scopes removes this "feature". I'll probably expose a different way of getting into the parentclass scope, however.

image_test_one_dockpane.enaml:
If I comment out either of the dockpanes in this example, the image does not show for the remaining dock pane.


That's interesting. My current machine doesn't have Chaco installed, so I can't test this, but I suspect it may have something to do with Qt not liking main windows without a central widget. I'll have to confirm on a different machine. In the meantime, what happens if you just declare an empty Container in the MainWindow for use as the central widget?
 
image_test_combobox.enaml:
If a combobox is added to my container, the image for that dockpane is not shown.


Nothing obvious is jumping out at me here either, I will need to test on a machine tomorrow with Chaco.
 
_______________________________________________
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



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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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




--
Simon Jagoe
Enthought Ltd
+44 79 312 11 506
[hidden email]

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

Re: enaml dockpane woes

Mike Sarahan
Just to follow up on this, I tested on a Windows 8 x64 machine.  I had to modify the code to not do the identifier subclassing that Chris mentions above.

I see bizarre, non-deterministic behavior.  With the groupbox example, sometimes I have no images, sometimes I have two, sometimes one...  I have modified this example with Chris' identification of the double constraints issue.

The combobox example is no less random.

The OK example is no less random.

The one_dockpane example now works - sometimes!

I think you see the trend.  I'm attaching updated scripts that no longer inherit ID's.

Can anyone confirm this behavior on a Windows 7 or 8 x64 system?

Thanks,
Mike


On Mon, Jan 28, 2013 at 12:31 PM, Simon Jagoe <[hidden email]> wrote:
I tried that in Windows XP and Ubuntu 12.10 both with enaml 0.6.7

I see two DockPanes defined in the code, and in all cases I see an image in them.


On Mon, Jan 28, 2013 at 5:57 PM, Mike Sarahan <[hidden email]> wrote:

You see the images in all of the panes?

What platform?

On Jan 28, 2013 9:40 AM, "Simon Jagoe" <[hidden email]> wrote:
I have no problem with any of your examples with enaml 0.6.7. I always see the dock panes that are defined in the file.


On Mon, Jan 28, 2013 at 5:46 AM, Mike Sarahan <[hidden email]> wrote:
Regarding the groupbox: thanks, that clears that up well.

Regarding identifier inheritance: I'd say dumb luck.  I certainly wasn't clever about it.  I think I just treated it as I would a python class, and it worked, so I went with it.  My train of thought was that it looked a lot like Traits, but inverted right to left.  Does that make sense?

With the main window idea, here's what I think you meant to try:

(under Main)
    Container:
        pass
    ImageViewDockPane: image_view:
      controller = ImageModel()
      p << main.controller
      title << "Image view"
      dock_area = 'left'
      visible := main.controller.show_image_view

(other dock pane commented out)

The behavior is the same.  If I uncomment the second dock pane, both images are present.  However, with the empty Container, the automatic resizing/filling is not as nice - the images in either plot seem to have a maximum size (not the same size - the one on the right is smaller), and each dock pane hugs their respective sides.  The gap between them grows as the window is enlarged.

Without the empty container, the gap between them stays constant, and the automatic resizing/refilling makes the images fill up to the whole screen (within the limits of maintaining the aspect ratio.)

Thanks for looking into this.
Mike


On Sun, Jan 27, 2013 at 9:13 PM, Chris Colbert <[hidden email]> wrote:



On Sun, Jan 27, 2013 at 10:45 PM, Mike Sarahan <[hidden email]> wrote:
Hello,

I'm banging my head trying to separate undesirable behaviors with DockPanes that I see.  I have no idea where to start.  I'm attaching several files that demonstrate the bugs for me.  I hope you are able to just run them to see the symptom.

My system is Windows x64, EPD 7.3, enaml from git head, just pulled.

Thanks for any tips!
Mike

Files: Note that aside from the "ViewToolBar", all other things labeled Toolbar are actually containers.

image_test_OK.enaml:
A reference implementation.  This one works exactly as I expect.

image_test_groupbox.enaml:
If a groupbox is added to my container, the groupbox overlaps with the other buttons in the container.  Additionally, it defeats the minimum-size limiting of the container.  The layout of the buttons is also messed up - the button adjacent to the groupbox is aligned with the top of the groupbox, while all other buttons are aligned with the bottom of the container


You are mixing constraints here. A GroupBox is also a container, and applies constraints to its children:

    constraints = [
        hbox(save, prev_image, next_image, crop, map_label, group)
    ]
    PushButton: crop:
        text = "Crop cells"
        enabled << controller.image_UI_enabled
    GroupBox: group:
        Label: map_label:
            text = "Characteristic Map:"
        ComboBox: characteristic:
            items = ["Shift", "Height", "Orientation", "Eccentricity"]
            enabled << controller.image_UI_enabled 

`map_label` is getting constrained by the GroupBox as well as the parent of the group box. You can just set the `title` attribute of the GroupBox here instead.

As an aside, how did you figure out that you could inherit identifiers when you subclass from an enamldef? That was an undocumented feature, because I was never quite sure it was a proper thing to have. Some of the experimental work I have going on with augmented scopes removes this "feature". I'll probably expose a different way of getting into the parentclass scope, however.

image_test_one_dockpane.enaml:
If I comment out either of the dockpanes in this example, the image does not show for the remaining dock pane.


That's interesting. My current machine doesn't have Chaco installed, so I can't test this, but I suspect it may have something to do with Qt not liking main windows without a central widget. I'll have to confirm on a different machine. In the meantime, what happens if you just declare an empty Container in the MainWindow for use as the central widget?
 
image_test_combobox.enaml:
If a combobox is added to my container, the image for that dockpane is not shown.


Nothing obvious is jumping out at me here either, I will need to test on a machine tomorrow with Chaco.
 
_______________________________________________
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



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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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

image_test_groupbox.enaml (8K) Download Attachment
image_test_OK.enaml (8K) Download Attachment
image_test_one_dockpane.enaml (8K) Download Attachment
image_test_combobox.enaml (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: enaml dockpane woes

Chris Colbert
I will test his on my Windows 8 VM as soon as I get a free moment. The change with the identifiers was my fault. As far as I know, you are the only known person who found the non-feature. So, sorry for causing you any headaches.

In the interest of honestly, it may not be until Sunday that I get to this, but I will get to it.

Chris


On Wed, Jan 30, 2013 at 10:44 PM, Mike Sarahan <[hidden email]> wrote:
Just to follow up on this, I tested on a Windows 8 x64 machine.  I had to modify the code to not do the identifier subclassing that Chris mentions above.

I see bizarre, non-deterministic behavior.  With the groupbox example, sometimes I have no images, sometimes I have two, sometimes one...  I have modified this example with Chris' identification of the double constraints issue.

The combobox example is no less random.

The OK example is no less random.

The one_dockpane example now works - sometimes!

I think you see the trend.  I'm attaching updated scripts that no longer inherit ID's.

Can anyone confirm this behavior on a Windows 7 or 8 x64 system?

Thanks,
Mike


On Mon, Jan 28, 2013 at 12:31 PM, Simon Jagoe <[hidden email]> wrote:
I tried that in Windows XP and Ubuntu 12.10 both with enaml 0.6.7

I see two DockPanes defined in the code, and in all cases I see an image in them.


On Mon, Jan 28, 2013 at 5:57 PM, Mike Sarahan <[hidden email]> wrote:

You see the images in all of the panes?

What platform?

On Jan 28, 2013 9:40 AM, "Simon Jagoe" <[hidden email]> wrote:
I have no problem with any of your examples with enaml 0.6.7. I always see the dock panes that are defined in the file.


On Mon, Jan 28, 2013 at 5:46 AM, Mike Sarahan <[hidden email]> wrote:
Regarding the groupbox: thanks, that clears that up well.

Regarding identifier inheritance: I'd say dumb luck.  I certainly wasn't clever about it.  I think I just treated it as I would a python class, and it worked, so I went with it.  My train of thought was that it looked a lot like Traits, but inverted right to left.  Does that make sense?

With the main window idea, here's what I think you meant to try:

(under Main)
    Container:
        pass
    ImageViewDockPane: image_view:
      controller = ImageModel()
      p << main.controller
      title << "Image view"
      dock_area = 'left'
      visible := main.controller.show_image_view

(other dock pane commented out)

The behavior is the same.  If I uncomment the second dock pane, both images are present.  However, with the empty Container, the automatic resizing/filling is not as nice - the images in either plot seem to have a maximum size (not the same size - the one on the right is smaller), and each dock pane hugs their respective sides.  The gap between them grows as the window is enlarged.

Without the empty container, the gap between them stays constant, and the automatic resizing/refilling makes the images fill up to the whole screen (within the limits of maintaining the aspect ratio.)

Thanks for looking into this.
Mike


On Sun, Jan 27, 2013 at 9:13 PM, Chris Colbert <[hidden email]> wrote:



On Sun, Jan 27, 2013 at 10:45 PM, Mike Sarahan <[hidden email]> wrote:
Hello,

I'm banging my head trying to separate undesirable behaviors with DockPanes that I see.  I have no idea where to start.  I'm attaching several files that demonstrate the bugs for me.  I hope you are able to just run them to see the symptom.

My system is Windows x64, EPD 7.3, enaml from git head, just pulled.

Thanks for any tips!
Mike

Files: Note that aside from the "ViewToolBar", all other things labeled Toolbar are actually containers.

image_test_OK.enaml:
A reference implementation.  This one works exactly as I expect.

image_test_groupbox.enaml:
If a groupbox is added to my container, the groupbox overlaps with the other buttons in the container.  Additionally, it defeats the minimum-size limiting of the container.  The layout of the buttons is also messed up - the button adjacent to the groupbox is aligned with the top of the groupbox, while all other buttons are aligned with the bottom of the container


You are mixing constraints here. A GroupBox is also a container, and applies constraints to its children:

    constraints = [
        hbox(save, prev_image, next_image, crop, map_label, group)
    ]
    PushButton: crop:
        text = "Crop cells"
        enabled << controller.image_UI_enabled
    GroupBox: group:
        Label: map_label:
            text = "Characteristic Map:"
        ComboBox: characteristic:
            items = ["Shift", "Height", "Orientation", "Eccentricity"]
            enabled << controller.image_UI_enabled 

`map_label` is getting constrained by the GroupBox as well as the parent of the group box. You can just set the `title` attribute of the GroupBox here instead.

As an aside, how did you figure out that you could inherit identifiers when you subclass from an enamldef? That was an undocumented feature, because I was never quite sure it was a proper thing to have. Some of the experimental work I have going on with augmented scopes removes this "feature". I'll probably expose a different way of getting into the parentclass scope, however.

image_test_one_dockpane.enaml:
If I comment out either of the dockpanes in this example, the image does not show for the remaining dock pane.


That's interesting. My current machine doesn't have Chaco installed, so I can't test this, but I suspect it may have something to do with Qt not liking main windows without a central widget. I'll have to confirm on a different machine. In the meantime, what happens if you just declare an empty Container in the MainWindow for use as the central widget?
 
image_test_combobox.enaml:
If a combobox is added to my container, the image for that dockpane is not shown.


Nothing obvious is jumping out at me here either, I will need to test on a machine tomorrow with Chaco.
 
_______________________________________________
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



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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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



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

Re: enaml dockpane woes

Mike Sarahan

No problem. No rush. I just like enaml and want to see it succeed.

Best,
Mike

On Jan 30, 2013 7:48 PM, "Chris Colbert" <[hidden email]> wrote:
I will test his on my Windows 8 VM as soon as I get a free moment. The change with the identifiers was my fault. As far as I know, you are the only known person who found the non-feature. So, sorry for causing you any headaches.

In the interest of honestly, it may not be until Sunday that I get to this, but I will get to it.

Chris


On Wed, Jan 30, 2013 at 10:44 PM, Mike Sarahan <[hidden email]> wrote:
Just to follow up on this, I tested on a Windows 8 x64 machine.  I had to modify the code to not do the identifier subclassing that Chris mentions above.

I see bizarre, non-deterministic behavior.  With the groupbox example, sometimes I have no images, sometimes I have two, sometimes one...  I have modified this example with Chris' identification of the double constraints issue.

The combobox example is no less random.

The OK example is no less random.

The one_dockpane example now works - sometimes!

I think you see the trend.  I'm attaching updated scripts that no longer inherit ID's.

Can anyone confirm this behavior on a Windows 7 or 8 x64 system?

Thanks,
Mike


On Mon, Jan 28, 2013 at 12:31 PM, Simon Jagoe <[hidden email]> wrote:
I tried that in Windows XP and Ubuntu 12.10 both with enaml 0.6.7

I see two DockPanes defined in the code, and in all cases I see an image in them.


On Mon, Jan 28, 2013 at 5:57 PM, Mike Sarahan <[hidden email]> wrote:

You see the images in all of the panes?

What platform?

On Jan 28, 2013 9:40 AM, "Simon Jagoe" <[hidden email]> wrote:
I have no problem with any of your examples with enaml 0.6.7. I always see the dock panes that are defined in the file.


On Mon, Jan 28, 2013 at 5:46 AM, Mike Sarahan <[hidden email]> wrote:
Regarding the groupbox: thanks, that clears that up well.

Regarding identifier inheritance: I'd say dumb luck.  I certainly wasn't clever about it.  I think I just treated it as I would a python class, and it worked, so I went with it.  My train of thought was that it looked a lot like Traits, but inverted right to left.  Does that make sense?

With the main window idea, here's what I think you meant to try:

(under Main)
    Container:
        pass
    ImageViewDockPane: image_view:
      controller = ImageModel()
      p << main.controller
      title << "Image view"
      dock_area = 'left'
      visible := main.controller.show_image_view

(other dock pane commented out)

The behavior is the same.  If I uncomment the second dock pane, both images are present.  However, with the empty Container, the automatic resizing/filling is not as nice - the images in either plot seem to have a maximum size (not the same size - the one on the right is smaller), and each dock pane hugs their respective sides.  The gap between them grows as the window is enlarged.

Without the empty container, the gap between them stays constant, and the automatic resizing/refilling makes the images fill up to the whole screen (within the limits of maintaining the aspect ratio.)

Thanks for looking into this.
Mike


On Sun, Jan 27, 2013 at 9:13 PM, Chris Colbert <[hidden email]> wrote:



On Sun, Jan 27, 2013 at 10:45 PM, Mike Sarahan <[hidden email]> wrote:
Hello,

I'm banging my head trying to separate undesirable behaviors with DockPanes that I see.  I have no idea where to start.  I'm attaching several files that demonstrate the bugs for me.  I hope you are able to just run them to see the symptom.

My system is Windows x64, EPD 7.3, enaml from git head, just pulled.

Thanks for any tips!
Mike

Files: Note that aside from the "ViewToolBar", all other things labeled Toolbar are actually containers.

image_test_OK.enaml:
A reference implementation.  This one works exactly as I expect.

image_test_groupbox.enaml:
If a groupbox is added to my container, the groupbox overlaps with the other buttons in the container.  Additionally, it defeats the minimum-size limiting of the container.  The layout of the buttons is also messed up - the button adjacent to the groupbox is aligned with the top of the groupbox, while all other buttons are aligned with the bottom of the container


You are mixing constraints here. A GroupBox is also a container, and applies constraints to its children:

    constraints = [
        hbox(save, prev_image, next_image, crop, map_label, group)
    ]
    PushButton: crop:
        text = "Crop cells"
        enabled << controller.image_UI_enabled
    GroupBox: group:
        Label: map_label:
            text = "Characteristic Map:"
        ComboBox: characteristic:
            items = ["Shift", "Height", "Orientation", "Eccentricity"]
            enabled << controller.image_UI_enabled 

`map_label` is getting constrained by the GroupBox as well as the parent of the group box. You can just set the `title` attribute of the GroupBox here instead.

As an aside, how did you figure out that you could inherit identifiers when you subclass from an enamldef? That was an undocumented feature, because I was never quite sure it was a proper thing to have. Some of the experimental work I have going on with augmented scopes removes this "feature". I'll probably expose a different way of getting into the parentclass scope, however.

image_test_one_dockpane.enaml:
If I comment out either of the dockpanes in this example, the image does not show for the remaining dock pane.


That's interesting. My current machine doesn't have Chaco installed, so I can't test this, but I suspect it may have something to do with Qt not liking main windows without a central widget. I'll have to confirm on a different machine. In the meantime, what happens if you just declare an empty Container in the MainWindow for use as the central widget?
 
image_test_combobox.enaml:
If a combobox is added to my container, the image for that dockpane is not shown.


Nothing obvious is jumping out at me here either, I will need to test on a machine tomorrow with Chaco.
 
_______________________________________________
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



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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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



_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: enaml dockpane woes

Simon Jagoe

I'll give it a spin tomorrow as well. Don't have access to my "real" development machine until then.

On 31 Jan 2013 04:09, "Mike Sarahan" <[hidden email]> wrote:

No problem. No rush. I just like enaml and want to see it succeed.

Best,
Mike

On Jan 30, 2013 7:48 PM, "Chris Colbert" <[hidden email]> wrote:
I will test his on my Windows 8 VM as soon as I get a free moment. The change with the identifiers was my fault. As far as I know, you are the only known person who found the non-feature. So, sorry for causing you any headaches.

In the interest of honestly, it may not be until Sunday that I get to this, but I will get to it.

Chris


On Wed, Jan 30, 2013 at 10:44 PM, Mike Sarahan <[hidden email]> wrote:
Just to follow up on this, I tested on a Windows 8 x64 machine.  I had to modify the code to not do the identifier subclassing that Chris mentions above.

I see bizarre, non-deterministic behavior.  With the groupbox example, sometimes I have no images, sometimes I have two, sometimes one...  I have modified this example with Chris' identification of the double constraints issue.

The combobox example is no less random.

The OK example is no less random.

The one_dockpane example now works - sometimes!

I think you see the trend.  I'm attaching updated scripts that no longer inherit ID's.

Can anyone confirm this behavior on a Windows 7 or 8 x64 system?

Thanks,
Mike


On Mon, Jan 28, 2013 at 12:31 PM, Simon Jagoe <[hidden email]> wrote:
I tried that in Windows XP and Ubuntu 12.10 both with enaml 0.6.7

I see two DockPanes defined in the code, and in all cases I see an image in them.


On Mon, Jan 28, 2013 at 5:57 PM, Mike Sarahan <[hidden email]> wrote:

You see the images in all of the panes?

What platform?

On Jan 28, 2013 9:40 AM, "Simon Jagoe" <[hidden email]> wrote:
I have no problem with any of your examples with enaml 0.6.7. I always see the dock panes that are defined in the file.


On Mon, Jan 28, 2013 at 5:46 AM, Mike Sarahan <[hidden email]> wrote:
Regarding the groupbox: thanks, that clears that up well.

Regarding identifier inheritance: I'd say dumb luck.  I certainly wasn't clever about it.  I think I just treated it as I would a python class, and it worked, so I went with it.  My train of thought was that it looked a lot like Traits, but inverted right to left.  Does that make sense?

With the main window idea, here's what I think you meant to try:

(under Main)
    Container:
        pass
    ImageViewDockPane: image_view:
      controller = ImageModel()
      p << main.controller
      title << "Image view"
      dock_area = 'left'
      visible := main.controller.show_image_view

(other dock pane commented out)

The behavior is the same.  If I uncomment the second dock pane, both images are present.  However, with the empty Container, the automatic resizing/filling is not as nice - the images in either plot seem to have a maximum size (not the same size - the one on the right is smaller), and each dock pane hugs their respective sides.  The gap between them grows as the window is enlarged.

Without the empty container, the gap between them stays constant, and the automatic resizing/refilling makes the images fill up to the whole screen (within the limits of maintaining the aspect ratio.)

Thanks for looking into this.
Mike


On Sun, Jan 27, 2013 at 9:13 PM, Chris Colbert <[hidden email]> wrote:



On Sun, Jan 27, 2013 at 10:45 PM, Mike Sarahan <[hidden email]> wrote:
Hello,

I'm banging my head trying to separate undesirable behaviors with DockPanes that I see.  I have no idea where to start.  I'm attaching several files that demonstrate the bugs for me.  I hope you are able to just run them to see the symptom.

My system is Windows x64, EPD 7.3, enaml from git head, just pulled.

Thanks for any tips!
Mike

Files: Note that aside from the "ViewToolBar", all other things labeled Toolbar are actually containers.

image_test_OK.enaml:
A reference implementation.  This one works exactly as I expect.

image_test_groupbox.enaml:
If a groupbox is added to my container, the groupbox overlaps with the other buttons in the container.  Additionally, it defeats the minimum-size limiting of the container.  The layout of the buttons is also messed up - the button adjacent to the groupbox is aligned with the top of the groupbox, while all other buttons are aligned with the bottom of the container


You are mixing constraints here. A GroupBox is also a container, and applies constraints to its children:

    constraints = [
        hbox(save, prev_image, next_image, crop, map_label, group)
    ]
    PushButton: crop:
        text = "Crop cells"
        enabled << controller.image_UI_enabled
    GroupBox: group:
        Label: map_label:
            text = "Characteristic Map:"
        ComboBox: characteristic:
            items = ["Shift", "Height", "Orientation", "Eccentricity"]
            enabled << controller.image_UI_enabled 

`map_label` is getting constrained by the GroupBox as well as the parent of the group box. You can just set the `title` attribute of the GroupBox here instead.

As an aside, how did you figure out that you could inherit identifiers when you subclass from an enamldef? That was an undocumented feature, because I was never quite sure it was a proper thing to have. Some of the experimental work I have going on with augmented scopes removes this "feature". I'll probably expose a different way of getting into the parentclass scope, however.

image_test_one_dockpane.enaml:
If I comment out either of the dockpanes in this example, the image does not show for the remaining dock pane.


That's interesting. My current machine doesn't have Chaco installed, so I can't test this, but I suspect it may have something to do with Qt not liking main windows without a central widget. I'll have to confirm on a different machine. In the meantime, what happens if you just declare an empty Container in the MainWindow for use as the central widget?
 
image_test_combobox.enaml:
If a combobox is added to my container, the image for that dockpane is not shown.


Nothing obvious is jumping out at me here either, I will need to test on a machine tomorrow with Chaco.
 
_______________________________________________
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



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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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



_______________________________________________
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


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

Re: enaml dockpane woes

Mike Sarahan
Any update on this?  It is really a problem with my application.  If I can do anything to help re-create/duplicate the bug, please let me know.


On Thu, Jan 31, 2013 at 6:48 AM, Simon Jagoe <[hidden email]> wrote:

I'll give it a spin tomorrow as well. Don't have access to my "real" development machine until then.

On 31 Jan 2013 04:09, "Mike Sarahan" <[hidden email]> wrote:

No problem. No rush. I just like enaml and want to see it succeed.

Best,
Mike

On Jan 30, 2013 7:48 PM, "Chris Colbert" <[hidden email]> wrote:
I will test his on my Windows 8 VM as soon as I get a free moment. The change with the identifiers was my fault. As far as I know, you are the only known person who found the non-feature. So, sorry for causing you any headaches.

In the interest of honestly, it may not be until Sunday that I get to this, but I will get to it.

Chris


On Wed, Jan 30, 2013 at 10:44 PM, Mike Sarahan <[hidden email]> wrote:
Just to follow up on this, I tested on a Windows 8 x64 machine.  I had to modify the code to not do the identifier subclassing that Chris mentions above.

I see bizarre, non-deterministic behavior.  With the groupbox example, sometimes I have no images, sometimes I have two, sometimes one...  I have modified this example with Chris' identification of the double constraints issue.

The combobox example is no less random.

The OK example is no less random.

The one_dockpane example now works - sometimes!

I think you see the trend.  I'm attaching updated scripts that no longer inherit ID's.

Can anyone confirm this behavior on a Windows 7 or 8 x64 system?

Thanks,
Mike


On Mon, Jan 28, 2013 at 12:31 PM, Simon Jagoe <[hidden email]> wrote:
I tried that in Windows XP and Ubuntu 12.10 both with enaml 0.6.7

I see two DockPanes defined in the code, and in all cases I see an image in them.


On Mon, Jan 28, 2013 at 5:57 PM, Mike Sarahan <[hidden email]> wrote:

You see the images in all of the panes?

What platform?

On Jan 28, 2013 9:40 AM, "Simon Jagoe" <[hidden email]> wrote:
I have no problem with any of your examples with enaml 0.6.7. I always see the dock panes that are defined in the file.


On Mon, Jan 28, 2013 at 5:46 AM, Mike Sarahan <[hidden email]> wrote:
Regarding the groupbox: thanks, that clears that up well.

Regarding identifier inheritance: I'd say dumb luck.  I certainly wasn't clever about it.  I think I just treated it as I would a python class, and it worked, so I went with it.  My train of thought was that it looked a lot like Traits, but inverted right to left.  Does that make sense?

With the main window idea, here's what I think you meant to try:

(under Main)
    Container:
        pass
    ImageViewDockPane: image_view:
      controller = ImageModel()
      p << main.controller
      title << "Image view"
      dock_area = 'left'
      visible := main.controller.show_image_view

(other dock pane commented out)

The behavior is the same.  If I uncomment the second dock pane, both images are present.  However, with the empty Container, the automatic resizing/filling is not as nice - the images in either plot seem to have a maximum size (not the same size - the one on the right is smaller), and each dock pane hugs their respective sides.  The gap between them grows as the window is enlarged.

Without the empty container, the gap between them stays constant, and the automatic resizing/refilling makes the images fill up to the whole screen (within the limits of maintaining the aspect ratio.)

Thanks for looking into this.
Mike


On Sun, Jan 27, 2013 at 9:13 PM, Chris Colbert <[hidden email]> wrote:



On Sun, Jan 27, 2013 at 10:45 PM, Mike Sarahan <[hidden email]> wrote:
Hello,

I'm banging my head trying to separate undesirable behaviors with DockPanes that I see.  I have no idea where to start.  I'm attaching several files that demonstrate the bugs for me.  I hope you are able to just run them to see the symptom.

My system is Windows x64, EPD 7.3, enaml from git head, just pulled.

Thanks for any tips!
Mike

Files: Note that aside from the "ViewToolBar", all other things labeled Toolbar are actually containers.

image_test_OK.enaml:
A reference implementation.  This one works exactly as I expect.

image_test_groupbox.enaml:
If a groupbox is added to my container, the groupbox overlaps with the other buttons in the container.  Additionally, it defeats the minimum-size limiting of the container.  The layout of the buttons is also messed up - the button adjacent to the groupbox is aligned with the top of the groupbox, while all other buttons are aligned with the bottom of the container


You are mixing constraints here. A GroupBox is also a container, and applies constraints to its children:

    constraints = [
        hbox(save, prev_image, next_image, crop, map_label, group)
    ]
    PushButton: crop:
        text = "Crop cells"
        enabled << controller.image_UI_enabled
    GroupBox: group:
        Label: map_label:
            text = "Characteristic Map:"
        ComboBox: characteristic:
            items = ["Shift", "Height", "Orientation", "Eccentricity"]
            enabled << controller.image_UI_enabled 

`map_label` is getting constrained by the GroupBox as well as the parent of the group box. You can just set the `title` attribute of the GroupBox here instead.

As an aside, how did you figure out that you could inherit identifiers when you subclass from an enamldef? That was an undocumented feature, because I was never quite sure it was a proper thing to have. Some of the experimental work I have going on with augmented scopes removes this "feature". I'll probably expose a different way of getting into the parentclass scope, however.

image_test_one_dockpane.enaml:
If I comment out either of the dockpanes in this example, the image does not show for the remaining dock pane.


That's interesting. My current machine doesn't have Chaco installed, so I can't test this, but I suspect it may have something to do with Qt not liking main windows without a central widget. I'll have to confirm on a different machine. In the meantime, what happens if you just declare an empty Container in the MainWindow for use as the central widget?
 
image_test_combobox.enaml:
If a combobox is added to my container, the image for that dockpane is not shown.


Nothing obvious is jumping out at me here either, I will need to test on a machine tomorrow with Chaco.
 
_______________________________________________
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



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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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



_______________________________________________
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


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: enaml dockpane woes

Simon Jagoe
Mike,

I'll make some time later today (in an hour or two) to test in Win7 64-bit.


On Thu, Feb 7, 2013 at 4:05 AM, Mike Sarahan <[hidden email]> wrote:
Any update on this?  It is really a problem with my application.  If I can do anything to help re-create/duplicate the bug, please let me know.


On Thu, Jan 31, 2013 at 6:48 AM, Simon Jagoe <[hidden email]> wrote:

I'll give it a spin tomorrow as well. Don't have access to my "real" development machine until then.

On 31 Jan 2013 04:09, "Mike Sarahan" <[hidden email]> wrote:

No problem. No rush. I just like enaml and want to see it succeed.

Best,
Mike

On Jan 30, 2013 7:48 PM, "Chris Colbert" <[hidden email]> wrote:
I will test his on my Windows 8 VM as soon as I get a free moment. The change with the identifiers was my fault. As far as I know, you are the only known person who found the non-feature. So, sorry for causing you any headaches.

In the interest of honestly, it may not be until Sunday that I get to this, but I will get to it.

Chris


On Wed, Jan 30, 2013 at 10:44 PM, Mike Sarahan <[hidden email]> wrote:
Just to follow up on this, I tested on a Windows 8 x64 machine.  I had to modify the code to not do the identifier subclassing that Chris mentions above.

I see bizarre, non-deterministic behavior.  With the groupbox example, sometimes I have no images, sometimes I have two, sometimes one...  I have modified this example with Chris' identification of the double constraints issue.

The combobox example is no less random.

The OK example is no less random.

The one_dockpane example now works - sometimes!

I think you see the trend.  I'm attaching updated scripts that no longer inherit ID's.

Can anyone confirm this behavior on a Windows 7 or 8 x64 system?

Thanks,
Mike


On Mon, Jan 28, 2013 at 12:31 PM, Simon Jagoe <[hidden email]> wrote:
I tried that in Windows XP and Ubuntu 12.10 both with enaml 0.6.7

I see two DockPanes defined in the code, and in all cases I see an image in them.


On Mon, Jan 28, 2013 at 5:57 PM, Mike Sarahan <[hidden email]> wrote:

You see the images in all of the panes?

What platform?

On Jan 28, 2013 9:40 AM, "Simon Jagoe" <[hidden email]> wrote:
I have no problem with any of your examples with enaml 0.6.7. I always see the dock panes that are defined in the file.


On Mon, Jan 28, 2013 at 5:46 AM, Mike Sarahan <[hidden email]> wrote:
Regarding the groupbox: thanks, that clears that up well.

Regarding identifier inheritance: I'd say dumb luck.  I certainly wasn't clever about it.  I think I just treated it as I would a python class, and it worked, so I went with it.  My train of thought was that it looked a lot like Traits, but inverted right to left.  Does that make sense?

With the main window idea, here's what I think you meant to try:

(under Main)
    Container:
        pass
    ImageViewDockPane: image_view:
      controller = ImageModel()
      p << main.controller
      title << "Image view"
      dock_area = 'left'
      visible := main.controller.show_image_view

(other dock pane commented out)

The behavior is the same.  If I uncomment the second dock pane, both images are present.  However, with the empty Container, the automatic resizing/filling is not as nice - the images in either plot seem to have a maximum size (not the same size - the one on the right is smaller), and each dock pane hugs their respective sides.  The gap between them grows as the window is enlarged.

Without the empty container, the gap between them stays constant, and the automatic resizing/refilling makes the images fill up to the whole screen (within the limits of maintaining the aspect ratio.)

Thanks for looking into this.
Mike


On Sun, Jan 27, 2013 at 9:13 PM, Chris Colbert <[hidden email]> wrote:



On Sun, Jan 27, 2013 at 10:45 PM, Mike Sarahan <[hidden email]> wrote:
Hello,

I'm banging my head trying to separate undesirable behaviors with DockPanes that I see.  I have no idea where to start.  I'm attaching several files that demonstrate the bugs for me.  I hope you are able to just run them to see the symptom.

My system is Windows x64, EPD 7.3, enaml from git head, just pulled.

Thanks for any tips!
Mike

Files: Note that aside from the "ViewToolBar", all other things labeled Toolbar are actually containers.

image_test_OK.enaml:
A reference implementation.  This one works exactly as I expect.

image_test_groupbox.enaml:
If a groupbox is added to my container, the groupbox overlaps with the other buttons in the container.  Additionally, it defeats the minimum-size limiting of the container.  The layout of the buttons is also messed up - the button adjacent to the groupbox is aligned with the top of the groupbox, while all other buttons are aligned with the bottom of the container


You are mixing constraints here. A GroupBox is also a container, and applies constraints to its children:

    constraints = [
        hbox(save, prev_image, next_image, crop, map_label, group)
    ]
    PushButton: crop:
        text = "Crop cells"
        enabled << controller.image_UI_enabled
    GroupBox: group:
        Label: map_label:
            text = "Characteristic Map:"
        ComboBox: characteristic:
            items = ["Shift", "Height", "Orientation", "Eccentricity"]
            enabled << controller.image_UI_enabled 

`map_label` is getting constrained by the GroupBox as well as the parent of the group box. You can just set the `title` attribute of the GroupBox here instead.

As an aside, how did you figure out that you could inherit identifiers when you subclass from an enamldef? That was an undocumented feature, because I was never quite sure it was a proper thing to have. Some of the experimental work I have going on with augmented scopes removes this "feature". I'll probably expose a different way of getting into the parentclass scope, however.

image_test_one_dockpane.enaml:
If I comment out either of the dockpanes in this example, the image does not show for the remaining dock pane.


That's interesting. My current machine doesn't have Chaco installed, so I can't test this, but I suspect it may have something to do with Qt not liking main windows without a central widget. I'll have to confirm on a different machine. In the meantime, what happens if you just declare an empty Container in the MainWindow for use as the central widget?
 
image_test_combobox.enaml:
If a combobox is added to my container, the image for that dockpane is not shown.


Nothing obvious is jumping out at me here either, I will need to test on a machine tomorrow with Chaco.
 
_______________________________________________
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



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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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



_______________________________________________
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


_______________________________________________
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




--
Simon Jagoe
Enthought Ltd
+44 79 312 11 506
[hidden email]

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

Re: enaml dockpane woes

Simon Jagoe
Mike,

I can reproduce your problem in Win7 64-bit. I'm not really sure where to look into the cause problem. This is thoroughly in Chris' domain.




On Mon, Feb 11, 2013 at 11:08 AM, Simon Jagoe <[hidden email]> wrote:
Mike,

I'll make some time later today (in an hour or two) to test in Win7 64-bit.


On Thu, Feb 7, 2013 at 4:05 AM, Mike Sarahan <[hidden email]> wrote:
Any update on this?  It is really a problem with my application.  If I can do anything to help re-create/duplicate the bug, please let me know.


On Thu, Jan 31, 2013 at 6:48 AM, Simon Jagoe <[hidden email]> wrote:

I'll give it a spin tomorrow as well. Don't have access to my "real" development machine until then.

On 31 Jan 2013 04:09, "Mike Sarahan" <[hidden email]> wrote:

No problem. No rush. I just like enaml and want to see it succeed.

Best,
Mike

On Jan 30, 2013 7:48 PM, "Chris Colbert" <[hidden email]> wrote:
I will test his on my Windows 8 VM as soon as I get a free moment. The change with the identifiers was my fault. As far as I know, you are the only known person who found the non-feature. So, sorry for causing you any headaches.

In the interest of honestly, it may not be until Sunday that I get to this, but I will get to it.

Chris


On Wed, Jan 30, 2013 at 10:44 PM, Mike Sarahan <[hidden email]> wrote:
Just to follow up on this, I tested on a Windows 8 x64 machine.  I had to modify the code to not do the identifier subclassing that Chris mentions above.

I see bizarre, non-deterministic behavior.  With the groupbox example, sometimes I have no images, sometimes I have two, sometimes one...  I have modified this example with Chris' identification of the double constraints issue.

The combobox example is no less random.

The OK example is no less random.

The one_dockpane example now works - sometimes!

I think you see the trend.  I'm attaching updated scripts that no longer inherit ID's.

Can anyone confirm this behavior on a Windows 7 or 8 x64 system?

Thanks,
Mike


On Mon, Jan 28, 2013 at 12:31 PM, Simon Jagoe <[hidden email]> wrote:
I tried that in Windows XP and Ubuntu 12.10 both with enaml 0.6.7

I see two DockPanes defined in the code, and in all cases I see an image in them.


On Mon, Jan 28, 2013 at 5:57 PM, Mike Sarahan <[hidden email]> wrote:

You see the images in all of the panes?

What platform?

On Jan 28, 2013 9:40 AM, "Simon Jagoe" <[hidden email]> wrote:
I have no problem with any of your examples with enaml 0.6.7. I always see the dock panes that are defined in the file.


On Mon, Jan 28, 2013 at 5:46 AM, Mike Sarahan <[hidden email]> wrote:
Regarding the groupbox: thanks, that clears that up well.

Regarding identifier inheritance: I'd say dumb luck.  I certainly wasn't clever about it.  I think I just treated it as I would a python class, and it worked, so I went with it.  My train of thought was that it looked a lot like Traits, but inverted right to left.  Does that make sense?

With the main window idea, here's what I think you meant to try:

(under Main)
    Container:
        pass
    ImageViewDockPane: image_view:
      controller = ImageModel()
      p << main.controller
      title << "Image view"
      dock_area = 'left'
      visible := main.controller.show_image_view

(other dock pane commented out)

The behavior is the same.  If I uncomment the second dock pane, both images are present.  However, with the empty Container, the automatic resizing/filling is not as nice - the images in either plot seem to have a maximum size (not the same size - the one on the right is smaller), and each dock pane hugs their respective sides.  The gap between them grows as the window is enlarged.

Without the empty container, the gap between them stays constant, and the automatic resizing/refilling makes the images fill up to the whole screen (within the limits of maintaining the aspect ratio.)

Thanks for looking into this.
Mike


On Sun, Jan 27, 2013 at 9:13 PM, Chris Colbert <[hidden email]> wrote:



On Sun, Jan 27, 2013 at 10:45 PM, Mike Sarahan <[hidden email]> wrote:
Hello,

I'm banging my head trying to separate undesirable behaviors with DockPanes that I see.  I have no idea where to start.  I'm attaching several files that demonstrate the bugs for me.  I hope you are able to just run them to see the symptom.

My system is Windows x64, EPD 7.3, enaml from git head, just pulled.

Thanks for any tips!
Mike

Files: Note that aside from the "ViewToolBar", all other things labeled Toolbar are actually containers.

image_test_OK.enaml:
A reference implementation.  This one works exactly as I expect.

image_test_groupbox.enaml:
If a groupbox is added to my container, the groupbox overlaps with the other buttons in the container.  Additionally, it defeats the minimum-size limiting of the container.  The layout of the buttons is also messed up - the button adjacent to the groupbox is aligned with the top of the groupbox, while all other buttons are aligned with the bottom of the container


You are mixing constraints here. A GroupBox is also a container, and applies constraints to its children:

    constraints = [
        hbox(save, prev_image, next_image, crop, map_label, group)
    ]
    PushButton: crop:
        text = "Crop cells"
        enabled << controller.image_UI_enabled
    GroupBox: group:
        Label: map_label:
            text = "Characteristic Map:"
        ComboBox: characteristic:
            items = ["Shift", "Height", "Orientation", "Eccentricity"]
            enabled << controller.image_UI_enabled 

`map_label` is getting constrained by the GroupBox as well as the parent of the group box. You can just set the `title` attribute of the GroupBox here instead.

As an aside, how did you figure out that you could inherit identifiers when you subclass from an enamldef? That was an undocumented feature, because I was never quite sure it was a proper thing to have. Some of the experimental work I have going on with augmented scopes removes this "feature". I'll probably expose a different way of getting into the parentclass scope, however.

image_test_one_dockpane.enaml:
If I comment out either of the dockpanes in this example, the image does not show for the remaining dock pane.


That's interesting. My current machine doesn't have Chaco installed, so I can't test this, but I suspect it may have something to do with Qt not liking main windows without a central widget. I'll have to confirm on a different machine. In the meantime, what happens if you just declare an empty Container in the MainWindow for use as the central widget?
 
image_test_combobox.enaml:
If a combobox is added to my container, the image for that dockpane is not shown.


Nothing obvious is jumping out at me here either, I will need to test on a machine tomorrow with Chaco.
 
_______________________________________________
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



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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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



_______________________________________________
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


_______________________________________________
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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]



--
Simon Jagoe
Enthought Ltd
+44 79 312 11 506
[hidden email]

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

Re: enaml dockpane woes

Mike Sarahan
Thanks Simon.  I think it is somewhere in the layout computation.  I didn't understand before that this computation is not deterministic.

I have improved the behavior a bit by introducing constraints on the container with the buttons.  The problem still shows up, but much less often.  Now it is perhaps 1 in 10-20 runs or less, rather than 1 in 3-5.

I'm attaching an altered example.  The dockpane on the left has the constraint (hug_height) applied on its button container.  The right dockpane does not.  It is rare that the left dockpane fails to show the plot, but I have seen it.

I hope this might help find the problem.

Mike


On Mon, Feb 11, 2013 at 7:02 AM, Simon Jagoe <[hidden email]> wrote:
Mike,

I can reproduce your problem in Win7 64-bit. I'm not really sure where to look into the cause problem. This is thoroughly in Chris' domain.




On Mon, Feb 11, 2013 at 11:08 AM, Simon Jagoe <[hidden email]> wrote:
Mike,

I'll make some time later today (in an hour or two) to test in Win7 64-bit.


On Thu, Feb 7, 2013 at 4:05 AM, Mike Sarahan <[hidden email]> wrote:
Any update on this?  It is really a problem with my application.  If I can do anything to help re-create/duplicate the bug, please let me know.


On Thu, Jan 31, 2013 at 6:48 AM, Simon Jagoe <[hidden email]> wrote:

I'll give it a spin tomorrow as well. Don't have access to my "real" development machine until then.

On 31 Jan 2013 04:09, "Mike Sarahan" <[hidden email]> wrote:

No problem. No rush. I just like enaml and want to see it succeed.

Best,
Mike

On Jan 30, 2013 7:48 PM, "Chris Colbert" <[hidden email]> wrote:
I will test his on my Windows 8 VM as soon as I get a free moment. The change with the identifiers was my fault. As far as I know, you are the only known person who found the non-feature. So, sorry for causing you any headaches.

In the interest of honestly, it may not be until Sunday that I get to this, but I will get to it.

Chris


On Wed, Jan 30, 2013 at 10:44 PM, Mike Sarahan <[hidden email]> wrote:
Just to follow up on this, I tested on a Windows 8 x64 machine.  I had to modify the code to not do the identifier subclassing that Chris mentions above.

I see bizarre, non-deterministic behavior.  With the groupbox example, sometimes I have no images, sometimes I have two, sometimes one...  I have modified this example with Chris' identification of the double constraints issue.

The combobox example is no less random.

The OK example is no less random.

The one_dockpane example now works - sometimes!

I think you see the trend.  I'm attaching updated scripts that no longer inherit ID's.

Can anyone confirm this behavior on a Windows 7 or 8 x64 system?

Thanks,
Mike


On Mon, Jan 28, 2013 at 12:31 PM, Simon Jagoe <[hidden email]> wrote:
I tried that in Windows XP and Ubuntu 12.10 both with enaml 0.6.7

I see two DockPanes defined in the code, and in all cases I see an image in them.


On Mon, Jan 28, 2013 at 5:57 PM, Mike Sarahan <[hidden email]> wrote:

You see the images in all of the panes?

What platform?

On Jan 28, 2013 9:40 AM, "Simon Jagoe" <[hidden email]> wrote:
I have no problem with any of your examples with enaml 0.6.7. I always see the dock panes that are defined in the file.


On Mon, Jan 28, 2013 at 5:46 AM, Mike Sarahan <[hidden email]> wrote:
Regarding the groupbox: thanks, that clears that up well.

Regarding identifier inheritance: I'd say dumb luck.  I certainly wasn't clever about it.  I think I just treated it as I would a python class, and it worked, so I went with it.  My train of thought was that it looked a lot like Traits, but inverted right to left.  Does that make sense?

With the main window idea, here's what I think you meant to try:

(under Main)
    Container:
        pass
    ImageViewDockPane: image_view:
      controller = ImageModel()
      p << main.controller
      title << "Image view"
      dock_area = 'left'
      visible := main.controller.show_image_view

(other dock pane commented out)

The behavior is the same.  If I uncomment the second dock pane, both images are present.  However, with the empty Container, the automatic resizing/filling is not as nice - the images in either plot seem to have a maximum size (not the same size - the one on the right is smaller), and each dock pane hugs their respective sides.  The gap between them grows as the window is enlarged.

Without the empty container, the gap between them stays constant, and the automatic resizing/refilling makes the images fill up to the whole screen (within the limits of maintaining the aspect ratio.)

Thanks for looking into this.
Mike


On Sun, Jan 27, 2013 at 9:13 PM, Chris Colbert <[hidden email]> wrote:



On Sun, Jan 27, 2013 at 10:45 PM, Mike Sarahan <[hidden email]> wrote:
Hello,

I'm banging my head trying to separate undesirable behaviors with DockPanes that I see.  I have no idea where to start.  I'm attaching several files that demonstrate the bugs for me.  I hope you are able to just run them to see the symptom.

My system is Windows x64, EPD 7.3, enaml from git head, just pulled.

Thanks for any tips!
Mike

Files: Note that aside from the "ViewToolBar", all other things labeled Toolbar are actually containers.

image_test_OK.enaml:
A reference implementation.  This one works exactly as I expect.

image_test_groupbox.enaml:
If a groupbox is added to my container, the groupbox overlaps with the other buttons in the container.  Additionally, it defeats the minimum-size limiting of the container.  The layout of the buttons is also messed up - the button adjacent to the groupbox is aligned with the top of the groupbox, while all other buttons are aligned with the bottom of the container


You are mixing constraints here. A GroupBox is also a container, and applies constraints to its children:

    constraints = [
        hbox(save, prev_image, next_image, crop, map_label, group)
    ]
    PushButton: crop:
        text = "Crop cells"
        enabled << controller.image_UI_enabled
    GroupBox: group:
        Label: map_label:
            text = "Characteristic Map:"
        ComboBox: characteristic:
            items = ["Shift", "Height", "Orientation", "Eccentricity"]
            enabled << controller.image_UI_enabled 

`map_label` is getting constrained by the GroupBox as well as the parent of the group box. You can just set the `title` attribute of the GroupBox here instead.

As an aside, how did you figure out that you could inherit identifiers when you subclass from an enamldef? That was an undocumented feature, because I was never quite sure it was a proper thing to have. Some of the experimental work I have going on with augmented scopes removes this "feature". I'll probably expose a different way of getting into the parentclass scope, however.

image_test_one_dockpane.enaml:
If I comment out either of the dockpanes in this example, the image does not show for the remaining dock pane.


That's interesting. My current machine doesn't have Chaco installed, so I can't test this, but I suspect it may have something to do with Qt not liking main windows without a central widget. I'll have to confirm on a different machine. In the meantime, what happens if you just declare an empty Container in the MainWindow for use as the central widget?
 
image_test_combobox.enaml:
If a combobox is added to my container, the image for that dockpane is not shown.


Nothing obvious is jumping out at me here either, I will need to test on a machine tomorrow with Chaco.
 
_______________________________________________
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



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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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



_______________________________________________
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


_______________________________________________
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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]



--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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

dockpane_double_test.enaml (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: enaml dockpane woes

Chris Colbert
Ok, I was wait for Simon's attempt at this. I'll get to this ASAP.


On Mon, Feb 11, 2013 at 10:01 PM, Mike Sarahan <[hidden email]> wrote:
Thanks Simon.  I think it is somewhere in the layout computation.  I didn't understand before that this computation is not deterministic.

I have improved the behavior a bit by introducing constraints on the container with the buttons.  The problem still shows up, but much less often.  Now it is perhaps 1 in 10-20 runs or less, rather than 1 in 3-5.

I'm attaching an altered example.  The dockpane on the left has the constraint (hug_height) applied on its button container.  The right dockpane does not.  It is rare that the left dockpane fails to show the plot, but I have seen it.

I hope this might help find the problem.

Mike


On Mon, Feb 11, 2013 at 7:02 AM, Simon Jagoe <[hidden email]> wrote:
Mike,

I can reproduce your problem in Win7 64-bit. I'm not really sure where to look into the cause problem. This is thoroughly in Chris' domain.




On Mon, Feb 11, 2013 at 11:08 AM, Simon Jagoe <[hidden email]> wrote:
Mike,

I'll make some time later today (in an hour or two) to test in Win7 64-bit.


On Thu, Feb 7, 2013 at 4:05 AM, Mike Sarahan <[hidden email]> wrote:
Any update on this?  It is really a problem with my application.  If I can do anything to help re-create/duplicate the bug, please let me know.


On Thu, Jan 31, 2013 at 6:48 AM, Simon Jagoe <[hidden email]> wrote:

I'll give it a spin tomorrow as well. Don't have access to my "real" development machine until then.

On 31 Jan 2013 04:09, "Mike Sarahan" <[hidden email]> wrote:

No problem. No rush. I just like enaml and want to see it succeed.

Best,
Mike

On Jan 30, 2013 7:48 PM, "Chris Colbert" <[hidden email]> wrote:
I will test his on my Windows 8 VM as soon as I get a free moment. The change with the identifiers was my fault. As far as I know, you are the only known person who found the non-feature. So, sorry for causing you any headaches.

In the interest of honestly, it may not be until Sunday that I get to this, but I will get to it.

Chris


On Wed, Jan 30, 2013 at 10:44 PM, Mike Sarahan <[hidden email]> wrote:
Just to follow up on this, I tested on a Windows 8 x64 machine.  I had to modify the code to not do the identifier subclassing that Chris mentions above.

I see bizarre, non-deterministic behavior.  With the groupbox example, sometimes I have no images, sometimes I have two, sometimes one...  I have modified this example with Chris' identification of the double constraints issue.

The combobox example is no less random.

The OK example is no less random.

The one_dockpane example now works - sometimes!

I think you see the trend.  I'm attaching updated scripts that no longer inherit ID's.

Can anyone confirm this behavior on a Windows 7 or 8 x64 system?

Thanks,
Mike


On Mon, Jan 28, 2013 at 12:31 PM, Simon Jagoe <[hidden email]> wrote:
I tried that in Windows XP and Ubuntu 12.10 both with enaml 0.6.7

I see two DockPanes defined in the code, and in all cases I see an image in them.


On Mon, Jan 28, 2013 at 5:57 PM, Mike Sarahan <[hidden email]> wrote:

You see the images in all of the panes?

What platform?

On Jan 28, 2013 9:40 AM, "Simon Jagoe" <[hidden email]> wrote:
I have no problem with any of your examples with enaml 0.6.7. I always see the dock panes that are defined in the file.


On Mon, Jan 28, 2013 at 5:46 AM, Mike Sarahan <[hidden email]> wrote:
Regarding the groupbox: thanks, that clears that up well.

Regarding identifier inheritance: I'd say dumb luck.  I certainly wasn't clever about it.  I think I just treated it as I would a python class, and it worked, so I went with it.  My train of thought was that it looked a lot like Traits, but inverted right to left.  Does that make sense?

With the main window idea, here's what I think you meant to try:

(under Main)
    Container:
        pass
    ImageViewDockPane: image_view:
      controller = ImageModel()
      p << main.controller
      title << "Image view"
      dock_area = 'left'
      visible := main.controller.show_image_view

(other dock pane commented out)

The behavior is the same.  If I uncomment the second dock pane, both images are present.  However, with the empty Container, the automatic resizing/filling is not as nice - the images in either plot seem to have a maximum size (not the same size - the one on the right is smaller), and each dock pane hugs their respective sides.  The gap between them grows as the window is enlarged.

Without the empty container, the gap between them stays constant, and the automatic resizing/refilling makes the images fill up to the whole screen (within the limits of maintaining the aspect ratio.)

Thanks for looking into this.
Mike


On Sun, Jan 27, 2013 at 9:13 PM, Chris Colbert <[hidden email]> wrote:



On Sun, Jan 27, 2013 at 10:45 PM, Mike Sarahan <[hidden email]> wrote:
Hello,

I'm banging my head trying to separate undesirable behaviors with DockPanes that I see.  I have no idea where to start.  I'm attaching several files that demonstrate the bugs for me.  I hope you are able to just run them to see the symptom.

My system is Windows x64, EPD 7.3, enaml from git head, just pulled.

Thanks for any tips!
Mike

Files: Note that aside from the "ViewToolBar", all other things labeled Toolbar are actually containers.

image_test_OK.enaml:
A reference implementation.  This one works exactly as I expect.

image_test_groupbox.enaml:
If a groupbox is added to my container, the groupbox overlaps with the other buttons in the container.  Additionally, it defeats the minimum-size limiting of the container.  The layout of the buttons is also messed up - the button adjacent to the groupbox is aligned with the top of the groupbox, while all other buttons are aligned with the bottom of the container


You are mixing constraints here. A GroupBox is also a container, and applies constraints to its children:

    constraints = [
        hbox(save, prev_image, next_image, crop, map_label, group)
    ]
    PushButton: crop:
        text = "Crop cells"
        enabled << controller.image_UI_enabled
    GroupBox: group:
        Label: map_label:
            text = "Characteristic Map:"
        ComboBox: characteristic:
            items = ["Shift", "Height", "Orientation", "Eccentricity"]
            enabled << controller.image_UI_enabled 

`map_label` is getting constrained by the GroupBox as well as the parent of the group box. You can just set the `title` attribute of the GroupBox here instead.

As an aside, how did you figure out that you could inherit identifiers when you subclass from an enamldef? That was an undocumented feature, because I was never quite sure it was a proper thing to have. Some of the experimental work I have going on with augmented scopes removes this "feature". I'll probably expose a different way of getting into the parentclass scope, however.

image_test_one_dockpane.enaml:
If I comment out either of the dockpanes in this example, the image does not show for the remaining dock pane.


That's interesting. My current machine doesn't have Chaco installed, so I can't test this, but I suspect it may have something to do with Qt not liking main windows without a central widget. I'll have to confirm on a different machine. In the meantime, what happens if you just declare an empty Container in the MainWindow for use as the central widget?
 
image_test_combobox.enaml:
If a combobox is added to my container, the image for that dockpane is not shown.


Nothing obvious is jumping out at me here either, I will need to test on a machine tomorrow with Chaco.
 
_______________________________________________
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



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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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



_______________________________________________
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


_______________________________________________
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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]



--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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



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

Re: enaml dockpane woes

Chris Colbert
Thanks for your patience Mike.


On Mon, Feb 11, 2013 at 10:11 PM, Chris Colbert <[hidden email]> wrote:
Ok, I was wait for Simon's attempt at this. I'll get to this ASAP.


On Mon, Feb 11, 2013 at 10:01 PM, Mike Sarahan <[hidden email]> wrote:
Thanks Simon.  I think it is somewhere in the layout computation.  I didn't understand before that this computation is not deterministic.

I have improved the behavior a bit by introducing constraints on the container with the buttons.  The problem still shows up, but much less often.  Now it is perhaps 1 in 10-20 runs or less, rather than 1 in 3-5.

I'm attaching an altered example.  The dockpane on the left has the constraint (hug_height) applied on its button container.  The right dockpane does not.  It is rare that the left dockpane fails to show the plot, but I have seen it.

I hope this might help find the problem.

Mike


On Mon, Feb 11, 2013 at 7:02 AM, Simon Jagoe <[hidden email]> wrote:
Mike,

I can reproduce your problem in Win7 64-bit. I'm not really sure where to look into the cause problem. This is thoroughly in Chris' domain.




On Mon, Feb 11, 2013 at 11:08 AM, Simon Jagoe <[hidden email]> wrote:
Mike,

I'll make some time later today (in an hour or two) to test in Win7 64-bit.


On Thu, Feb 7, 2013 at 4:05 AM, Mike Sarahan <[hidden email]> wrote:
Any update on this?  It is really a problem with my application.  If I can do anything to help re-create/duplicate the bug, please let me know.


On Thu, Jan 31, 2013 at 6:48 AM, Simon Jagoe <[hidden email]> wrote:

I'll give it a spin tomorrow as well. Don't have access to my "real" development machine until then.

On 31 Jan 2013 04:09, "Mike Sarahan" <[hidden email]> wrote:

No problem. No rush. I just like enaml and want to see it succeed.

Best,
Mike

On Jan 30, 2013 7:48 PM, "Chris Colbert" <[hidden email]> wrote:
I will test his on my Windows 8 VM as soon as I get a free moment. The change with the identifiers was my fault. As far as I know, you are the only known person who found the non-feature. So, sorry for causing you any headaches.

In the interest of honestly, it may not be until Sunday that I get to this, but I will get to it.

Chris


On Wed, Jan 30, 2013 at 10:44 PM, Mike Sarahan <[hidden email]> wrote:
Just to follow up on this, I tested on a Windows 8 x64 machine.  I had to modify the code to not do the identifier subclassing that Chris mentions above.

I see bizarre, non-deterministic behavior.  With the groupbox example, sometimes I have no images, sometimes I have two, sometimes one...  I have modified this example with Chris' identification of the double constraints issue.

The combobox example is no less random.

The OK example is no less random.

The one_dockpane example now works - sometimes!

I think you see the trend.  I'm attaching updated scripts that no longer inherit ID's.

Can anyone confirm this behavior on a Windows 7 or 8 x64 system?

Thanks,
Mike


On Mon, Jan 28, 2013 at 12:31 PM, Simon Jagoe <[hidden email]> wrote:
I tried that in Windows XP and Ubuntu 12.10 both with enaml 0.6.7

I see two DockPanes defined in the code, and in all cases I see an image in them.


On Mon, Jan 28, 2013 at 5:57 PM, Mike Sarahan <[hidden email]> wrote:

You see the images in all of the panes?

What platform?

On Jan 28, 2013 9:40 AM, "Simon Jagoe" <[hidden email]> wrote:
I have no problem with any of your examples with enaml 0.6.7. I always see the dock panes that are defined in the file.


On Mon, Jan 28, 2013 at 5:46 AM, Mike Sarahan <[hidden email]> wrote:
Regarding the groupbox: thanks, that clears that up well.

Regarding identifier inheritance: I'd say dumb luck.  I certainly wasn't clever about it.  I think I just treated it as I would a python class, and it worked, so I went with it.  My train of thought was that it looked a lot like Traits, but inverted right to left.  Does that make sense?

With the main window idea, here's what I think you meant to try:

(under Main)
    Container:
        pass
    ImageViewDockPane: image_view:
      controller = ImageModel()
      p << main.controller
      title << "Image view"
      dock_area = 'left'
      visible := main.controller.show_image_view

(other dock pane commented out)

The behavior is the same.  If I uncomment the second dock pane, both images are present.  However, with the empty Container, the automatic resizing/filling is not as nice - the images in either plot seem to have a maximum size (not the same size - the one on the right is smaller), and each dock pane hugs their respective sides.  The gap between them grows as the window is enlarged.

Without the empty container, the gap between them stays constant, and the automatic resizing/refilling makes the images fill up to the whole screen (within the limits of maintaining the aspect ratio.)

Thanks for looking into this.
Mike


On Sun, Jan 27, 2013 at 9:13 PM, Chris Colbert <[hidden email]> wrote:



On Sun, Jan 27, 2013 at 10:45 PM, Mike Sarahan <[hidden email]> wrote:
Hello,

I'm banging my head trying to separate undesirable behaviors with DockPanes that I see.  I have no idea where to start.  I'm attaching several files that demonstrate the bugs for me.  I hope you are able to just run them to see the symptom.

My system is Windows x64, EPD 7.3, enaml from git head, just pulled.

Thanks for any tips!
Mike

Files: Note that aside from the "ViewToolBar", all other things labeled Toolbar are actually containers.

image_test_OK.enaml:
A reference implementation.  This one works exactly as I expect.

image_test_groupbox.enaml:
If a groupbox is added to my container, the groupbox overlaps with the other buttons in the container.  Additionally, it defeats the minimum-size limiting of the container.  The layout of the buttons is also messed up - the button adjacent to the groupbox is aligned with the top of the groupbox, while all other buttons are aligned with the bottom of the container


You are mixing constraints here. A GroupBox is also a container, and applies constraints to its children:

    constraints = [
        hbox(save, prev_image, next_image, crop, map_label, group)
    ]
    PushButton: crop:
        text = "Crop cells"
        enabled << controller.image_UI_enabled
    GroupBox: group:
        Label: map_label:
            text = "Characteristic Map:"
        ComboBox: characteristic:
            items = ["Shift", "Height", "Orientation", "Eccentricity"]
            enabled << controller.image_UI_enabled 

`map_label` is getting constrained by the GroupBox as well as the parent of the group box. You can just set the `title` attribute of the GroupBox here instead.

As an aside, how did you figure out that you could inherit identifiers when you subclass from an enamldef? That was an undocumented feature, because I was never quite sure it was a proper thing to have. Some of the experimental work I have going on with augmented scopes removes this "feature". I'll probably expose a different way of getting into the parentclass scope, however.

image_test_one_dockpane.enaml:
If I comment out either of the dockpanes in this example, the image does not show for the remaining dock pane.


That's interesting. My current machine doesn't have Chaco installed, so I can't test this, but I suspect it may have something to do with Qt not liking main windows without a central widget. I'll have to confirm on a different machine. In the meantime, what happens if you just declare an empty Container in the MainWindow for use as the central widget?
 
image_test_combobox.enaml:
If a combobox is added to my container, the image for that dockpane is not shown.


Nothing obvious is jumping out at me here either, I will need to test on a machine tomorrow with Chaco.
 
_______________________________________________
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



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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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



_______________________________________________
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


_______________________________________________
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




--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]



--
Simon Jagoe
Enthought Ltd
<a href="tel:%2B44%2079%20312%2011%20506" value="+447931211506" target="_blank">+44 79 312 11 506
[hidden email]

_______________________________________________
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




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