enaml: any plans for editable ItemView?

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

enaml: any plans for editable ItemView?

Matthew Scott
Are there thoughts/plans yet for incorporating editable item views in enaml?

I see that there is support for list, tree, and table views that conform to an ItemView protocol, but I don't see any mention of editors.

We are evaluating enaml for near-term and projected long-term usefulness, we are trying to hit pain points sooner rather than later.  No editable table view is one pain point, but I can sympathize with a lack of an API for that at this stage of the project.

Any thoughts on a direction we could explore in the near-term?

My dream table view would let me override the cell drawing and geometry, as well as editors -- much like Qt itself lets you, but using the great enaml DSL.  Example: In some cells I'd like to include a button, aligned with the right side of the cell.  Clicking the button would bring up some sort of lookup table (that's another topic!).  In other cells I'd like to choose the editor widget:  validating line editor, combo box, etc.

Thanks,

-- 
Matthew Scott
ElevenCraft Inc.
http://11craft.com/


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

Re: enaml: any plans for editable ItemView?

Robert Kern
On Fri, Jun 22, 2012 at 4:17 AM, Matthew Scott <[hidden email]> wrote:

> Are there thoughts/plans yet for incorporating editable item views in enaml?
>
> I see that there is support for list, tree, and table views that conform to
> an ItemView protocol, but I don't see any mention of editors.
>
> We are evaluating enaml for near-term and projected long-term usefulness, we
> are trying to hit pain points sooner rather than later.  No editable table
> view is one pain point, but I can sympathize with a lack of an API for that
> at this stage of the project.
>
> Any thoughts on a direction we could explore in the near-term?

Standard text editing should be available, though I admit we haven't
exercised it much.

https://github.com/enthought/enaml/blob/master/enaml/core/item_model.py#L17
https://github.com/enthought/enaml/blob/master/enaml/core/item_model.py#L594
https://github.com/enthought/enaml/blob/master/enaml/core/item_model.py#L907

> My dream table view would let me override the cell drawing and geometry, as
> well as editors -- much like Qt itself lets you, but using the great enaml
> DSL.  Example: In some cells I'd like to include a button, aligned with the
> right side of the cell.  Clicking the button would bring up some sort of
> lookup table (that's another topic!).  In other cells I'd like to choose the
> editor widget:  validating line editor, combo box, etc.

Custom painting is heavily tied to the toolkit API, so you may need to
subclass the component to drop down to Qt to do that.

We are investigating an API for doing "pure Enaml" item delegates. It
will probably take some experimentation, and it's not at the very top
of our priority list at the moment. But we can probably hack up a
Qt-only subclass as a proof of concept that we can iterate on. Let us
know if you have the spare cycles to help us dig into that.

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

Re: enaml: any plans for editable ItemView?

Chris Colbert


On Fri, Jun 22, 2012 at 5:49 AM, Robert Kern <[hidden email]> wrote:
On Fri, Jun 22, 2012 at 4:17 AM, Matthew Scott <[hidden email]> wrote:
> Are there thoughts/plans yet for incorporating editable item views in enaml?
>
> I see that there is support for list, tree, and table views that conform to
> an ItemView protocol, but I don't see any mention of editors.
>
> We are evaluating enaml for near-term and projected long-term usefulness, we
> are trying to hit pain points sooner rather than later.  No editable table
> view is one pain point, but I can sympathize with a lack of an API for that
> at this stage of the project.
>
> Any thoughts on a direction we could explore in the near-term?

Standard text editing should be available, though I admit we haven't
exercised it much.

https://github.com/enthought/enaml/blob/master/enaml/core/item_model.py#L17
https://github.com/enthought/enaml/blob/master/enaml/core/item_model.py#L594
https://github.com/enthought/enaml/blob/master/enaml/core/item_model.py#L907

> My dream table view would let me override the cell drawing and geometry, as
> well as editors -- much like Qt itself lets you, but using the great enaml
> DSL.  Example: In some cells I'd like to include a button, aligned with the
> right side of the cell.  Clicking the button would bring up some sort of
> lookup table (that's another topic!).  In other cells I'd like to choose the
> editor widget:  validating line editor, combo box, etc.

Custom painting is heavily tied to the toolkit API, so you may need to
subclass the component to drop down to Qt to do that.

We are investigating an API for doing "pure Enaml" item delegates. It
will probably take some experimentation, and it's not at the very top
of our priority list at the moment. But we can probably hack up a
Qt-only subclass as a proof of concept that we can iterate on. Let us
know if you have the spare cycles to help us dig into that.


Custom item painting at the toolkit level is going to become more difficult once we move to the asynchronous apis:

If you are working with the application in-process, it is something we could expose. But obviously, you wont' have direct access to the toolkit widget when running the UI out of process. However, some of ideas John was proposing would be adaptable to the message passing approach we are using to implement the asynchronous UIs. One idea we were tossing around was the ability to send arbitrary metadata to a client. In that case you could send it whatever you want, with the knowledge that it ties you to a specific client implementation.

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

Re: enaml: any plans for editable ItemView?

Chris Colbert


On Fri, Jun 22, 2012 at 9:37 AM, Chris Colbert <[hidden email]> wrote:


On Fri, Jun 22, 2012 at 5:49 AM, Robert Kern <[hidden email]> wrote:
On Fri, Jun 22, 2012 at 4:17 AM, Matthew Scott <[hidden email]> wrote:
> Are there thoughts/plans yet for incorporating editable item views in enaml?
>
> I see that there is support for list, tree, and table views that conform to
> an ItemView protocol, but I don't see any mention of editors.
>
> We are evaluating enaml for near-term and projected long-term usefulness, we
> are trying to hit pain points sooner rather than later.  No editable table
> view is one pain point, but I can sympathize with a lack of an API for that
> at this stage of the project.
>
> Any thoughts on a direction we could explore in the near-term?

Standard text editing should be available, though I admit we haven't
exercised it much.

https://github.com/enthought/enaml/blob/master/enaml/core/item_model.py#L17
https://github.com/enthought/enaml/blob/master/enaml/core/item_model.py#L594
https://github.com/enthought/enaml/blob/master/enaml/core/item_model.py#L907

> My dream table view would let me override the cell drawing and geometry, as
> well as editors -- much like Qt itself lets you, but using the great enaml
> DSL.  Example: In some cells I'd like to include a button, aligned with the
> right side of the cell.  Clicking the button would bring up some sort of
> lookup table (that's another topic!).  In other cells I'd like to choose the
> editor widget:  validating line editor, combo box, etc.

Custom painting is heavily tied to the toolkit API, so you may need to
subclass the component to drop down to Qt to do that.

We are investigating an API for doing "pure Enaml" item delegates. It
will probably take some experimentation, and it's not at the very top
of our priority list at the moment. But we can probably hack up a
Qt-only subclass as a proof of concept that we can iterate on. Let us
know if you have the spare cycles to help us dig into that.


Custom item painting at the toolkit level is going to become more difficult once we move to the asynchronous apis:

If you are working with the application in-process, it is something we could expose. But obviously, you wont' have direct access to the toolkit widget when running the UI out of process. However, some of ideas John was proposing would be adaptable to the message passing approach we are using to implement the asynchronous UIs. One idea we were tossing around was the ability to send arbitrary metadata to a client. In that case you could send it whatever you want, with the knowledge that it ties you to a specific client implementation.


It seems some clarification is in order on what I just mentioned:

There is currently strong demand to be able to run Enaml UI's out-of-process or in a browser. In order to make this possible, the communication channels between Enaml widgets and the GUI toolkit widgets need to be rearchitected to be asynchronous and streamable.

At the same, we still want to be able to run the GUI in-process and not pay the serialization costs. So, what we are making on that feature branch is a way to do this. GUI's that run in-process will still be asynchronous, but this will be largely transparent to the user. i.e. the interaction between user code and Enaml component attributes will be synchronous.

What this does mean, however, is that "toolkit_widget" cannot be part of the form "this works everywhere" api. Because if you are running the GUI remotely, you obviously have no handle to the toolkit widget. You also won't know whether you client is a Qt process or a web browser. 

In the interest of practicality, there will be api's exposed for doing custom local things, or custom remote things. That is, for a local application, there will still be api's for supplying custom toolkit widgets to handle a certain thing, and for remote applications there will be ways to send client-specific metadata to customize behavior.

Hope that clears things up.

Chris

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

feature-async and custom toolkit widgets (was Re: enaml: any plans for editable ItemView?)

Matthew Scott
In reply to this post by Chris Colbert
Thanks for sharing information about 'feature-async'.  Any tips for someone interested in tracking this branch?

Also, would it be correct for me to summarize the ongoing work roughly as follows?

- Qt, Wx, and eventually Web all become asynchronous toolkits
- Bidirectional message passing is used, e.g. for a PushButton component
    - send a message to toolkit  (label = 'OK')
    - receive a message from toolkit  (clicked)
- For performance, Qt and Wx have special cases for direct data access when in-process

Going from these assumptions, I'm picturing your "arbitrary metadata" scenario in this way, using a "FlashingPushButton" as an example of placing such flashing behavior on the client  instead of the server:

- Create a FlashingPushButton(PushButton) component
- Give it extra 'flashing' and 'flash_hz' attributes
- For each supported toolkit, we now need to create a corresponding flashing button control using the toolkit's native timer APIs
- When component's extra attributes are set, it propagates them to the toolkit by way of message passing (or direct access if in-process GUI)
- The toolkit control, upon receiving messages updating the extra attributes, will update button state and control native timer APIs

-- 
Matthew Scott
ElevenCraft Inc.
http://11craft.com/

On Friday, June 22, 2012 at 08:37, Chris Colbert wrote:

If you are working with the application in-process, it is something we could expose. But obviously, you wont' have direct access to the toolkit widget when running the UI out of process. However, some of ideas John was proposing would be adaptable to the message passing approach we are using to implement the asynchronous UIs. One idea we were tossing around was the ability to send arbitrary metadata to a client. In that case you could send it whatever you want, with the knowledge that it ties you to a specific client implementation.


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

Re: feature-async and custom toolkit widgets (was Re: enaml: any plans for editable ItemView?)

John Wiggins
On Fri, Jun 22, 2012 at 1:03 PM, Matthew Scott <[hidden email]> wrote:

> Thanks for sharing information about 'feature-async'.  Any tips for someone
> interested in tracking this branch?
>
> Also, would it be correct for me to summarize the ongoing work roughly as
> follows?
>
> - Qt, Wx, and eventually Web all become asynchronous toolkits
> - Bidirectional message passing is used, e.g. for a PushButton component
>     - send a message to toolkit  (label = 'OK')
>     - receive a message from toolkit  (clicked)
> - For performance, Qt and Wx have special cases for direct data access when
> in-process

That's definitely my understanding.

> Going from these assumptions, I'm picturing your "arbitrary metadata"
> scenario in this way, using a "FlashingPushButton" as an example of placing
> such flashing behavior on the client  instead of the server:
>
> - Create a FlashingPushButton(PushButton) component
> - Give it extra 'flashing' and 'flash_hz' attributes
> - For each supported toolkit, we now need to create a corresponding flashing
> button control using the toolkit's native timer APIs
> - When component's extra attributes are set, it propagates them to the
> toolkit by way of message passing (or direct access if in-process GUI)
> - The toolkit control, upon receiving messages updating the extra
> attributes, will update button state and control native timer APIs

All of this checks out, except for the direct access part.

!!! Keep in mind, the direct access API has not been fleshed out yet. !!!

I think for features that only work in-process, information will still
be passed to the toolkit as messages. The distinction is that
in-process messages will not be serialized, so they can contain
objects which are not able to be serialized.

HTH,

-- John

> --
> Matthew Scott
> ElevenCraft Inc.
> http://11craft.com/
>
> On Friday, June 22, 2012 at 08:37, Chris Colbert wrote:
>
> If you are working with the application in-process, it is something we could
> expose. But obviously, you wont' have direct access to the toolkit widget
> when running the UI out of process. However, some of ideas John was
> proposing would be adaptable to the message passing approach we are using to
> implement the asynchronous UIs. One idea we were tossing around was the
> ability to send arbitrary metadata to a client. In that case you could send
> it whatever you want, with the knowledge that it ties you to a specific
> client implementation.
>
>
>
> _______________________________________________
> 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: feature-async and custom toolkit widgets (was Re: enaml: any plans for editable ItemView?)

Chris Colbert
In reply to this post by Matthew Scott
On Fri, Jun 22, 2012 at 2:03 PM, Matthew Scott <[hidden email]> wrote:
Thanks for sharing information about 'feature-async'.  Any tips for someone interested in tracking this branch?


This feature branch is less than a week old. I'm running full out (when possible) trying to get it up to speed, so your best bet for  now is to just watch the commit logs. We will make an announcement for testing/review before merging it to mainline. When you see the examples starting to be updated on that branch, you'll know things are close.


Also, would it be correct for me to summarize the ongoing work roughly as follows?

- Qt, Wx, and eventually Web all become asynchronous toolkits

I'd like to drop support for Wx, barring a gigantic community outcry. It is a very painful toolkit to work with, and it wastes a lot of my time. It certainly won't be supported in the beginning of this port.
 
- Bidirectional message passing is used, e.g. for a PushButton component
    - send a message to toolkit  (label = 'OK')
    - receive a message from toolkit  (clicked)

Correct.
 
- For performance, Qt and Wx have special cases for direct data access when in-process


Not necessarily direct (async message passing will still be used) but the serialization step will be skipped.

Going from these assumptions, I'm picturing your "arbitrary metadata" scenario in this way, using a "FlashingPushButton" as an example of placing such flashing behavior on the client  instead of the server:

- Create a FlashingPushButton(PushButton) component
- Give it extra 'flashing' and 'flash_hz' attributes
- For each supported toolkit, we now need to create a corresponding flashing button control using the toolkit's native timer APIs
- When component's extra attributes are set, it propagates them to the toolkit by way of message passing (or direct access if in-process GUI)
- The toolkit control, upon receiving messages updating the extra attributes, will update button state and control native timer APIs


What you describe is the procedure for simply defining a new built-in component. The idea for client specific metadata would be something like this, for an HTML5-specific client.

 enamldef FlashButton(PushButton):
    metadata = {
        'javascript': """
              var button = window.getElementById("foo-button");
              button.animate("background", 10);
        """
    }


In this case, the javascript metadata would be ignored on all clients expect your custom HTML5 client. Again, this is just an idea at this point. But it's the best i've go going so far for a way to specify custom things for a remote client.

For local apps, you have the ability to override/supply your own custom widget classes, just like you do now. But instead of being stuck in a toolkit, they'll be somewhere else that is yet to be decided.




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