Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use editable_row_callback to determine if row should be editable #195

Merged
merged 21 commits into from
Jul 10, 2018

Conversation

TimShawver
Copy link
Contributor

@TimShawver TimShawver commented May 16, 2018

This is a branch off of the following PR: #191

My reasoning for using a callback function is it's more flexible/powerful and fewer lines of code for us to maintain.

Also I'm thinking ahead to other similar features which we'll want, like have the ability to highlight rows/cells with a background color based on the contents of the rows. For those cases we'll definitely want the ability to do stuff like highlight all rows where an integer is less than zero. With a callback function we can handle that type of comparison, because we'll have the full power of python available to us in the callback, rather than being limited to a subset that we've added support for in the row_edit_conditions grammar.

There's one other small tweak here which is to make it so that columns default to being editable if the editable attribute is not specified when constructing the QgridWidget. This is only an issue when constructing QgridWidget directly so you wouldn't have noticed it if you've just been testing with show_grid.

@TimShawver
Copy link
Contributor Author

@vardaofthevalier sorry about the delay in merging this, I was busy with making qgrid available on Quantopian (see https://www.quantopian.com/posts/qgrid-now-available-in-research-an-interactive-grid-for-sorting-and-filtering-dataframes) and also wanted to some more time to think about how the "setting cell value" piece should work. I'm wondering if we should re-use the editing code path that already exists for editing a cell by double clicking. I'll update this PR with my thoughts once I have some more time to think about it.

@TimShawver TimShawver force-pushed the varda-column-config branch from 7d1a763 to be4044e Compare July 1, 2018 07:56
Tim Shawver added 13 commits July 2, 2018 15:27
…naming of the "cell_edited" event that will be fired as a result of this action.
…ent with the naming scheme of the events API.
…slick grid by default. We use a font-awesome icon instead.
…id to flicker and the kernel to remain in use.
…ed docs for add/remove row API methods. There's now just 'add_row' and 'remove_rows' methods (previously called 'remove_row'). Specify whether an add/remove event came from a button click or an API call.
…a backlog of events that had to be processed, causing scrolling to appear to be really slow. This was especially apparent in hosted environments like Q where latency is more of an issue.
@TimShawver TimShawver merged commit ba639cd into master Jul 10, 2018
@TimShawver TimShawver deleted the varda-column-config branch July 10, 2018 04:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant