Closed dernhelm7 closed 7 years ago
I'm interested in such a project, what you are looking for is something like http://dojotoolkit.org/reference-guide/1.8/dojox/grid/DataGrid.html ?
Yes, that's exactly the sort of output we're looking for! Up till now we've been using wxPython and its Grid module to produce it.
Can you do a feature listing, since you may know it better than me, and maybe sketch out the desired API ?
Sure! I should have it tomorrow. Thank you for being willing to help!
Here is a rough sketch of the API in stubbed-out class format, and a feature list: https://github.com/dernhelm7/sketches
What do you think of the structure? Any suggestions? I'm not very familiar with Kivy yet, so my assumptions may be off.
I will request kivy maintainers if this can go into kivy, in the meantime I will study the sketches you made available.
The ListView examples in a new working pull request, https://github.com/kivy/kivy/pull/765, include one called list_kv.py and one called list_composite.py. Both of these illustrate something grid-like, or you will hopefully see the potential. The ListView class itself is dependent on an adapter such as ListAdapter and DictAdapter.
I haven't looked at specifics yet, but I can imagine that we could build a sibling widget to ListView, GridView(AbstractView), probably using DictAdapter, that has properties and methods supporting a row-column grid, grid cells, boundary styling, and so on, with a cell-selection system by row-column index. ListView itself doesn't yet have a Divider (horizontal) yet, so there is basic work to be done. A GridAdapter could be made, if DictAdapter doesn't have what is needed.
Totally agree on this.
GridLayout is different than a real GridView with headers, filters etc. This feature require the PR from Jeff, because its PR include enough abstraction to the data to be able to build a real GridView.
@geojeff I think that would be also a good exercise to see if adapters can fit on this use case :) And if not, how we can include it. (but not on the same PR of course.)
Mathieu
Le 26/10/2012 00:32, Jeff Pittman a écrit :
The ListView examples in a new working pull request, kivy/kivy#765 https://github.com/kivy/kivy/issues/765, include one called list_kv.py and one called list_composite.py. Both of these illustrate something grid-like, or you will hopefully see the potential. The ListView class itself is dependent on an adapter such as ListAdapter and DictAdapter.
I haven't looked at specifics yet, but I can imagine that we could build a sibling widget to ListView, GridView(AbstractView), probably using DictAdapter, that has properties and methods supporting a row-column grid, grid cells, boundary styling, and so on, with a cell-selection system by row-column index. ListView itself doesn't yet have a Divider (horizontal) yet, so there is basic work to be done. A GridAdapter could be made, if DictAdapter doesn't have what is needed.
— Reply to this email directly or view it on GitHub https://github.com/kivy/kivy/issues/763#issuecomment-9796824.
I can definitely see the potential! Amirouche, what's your take on this? I'm still looking through the code...
Wow--@geojeff, you've already done a ton. I'm just getting used to github and I don't know your project like you do, so please, let me know what I can most productively help in working on!
I've started a separate experimental branch for the grid work at https://github.com/geojeff/kivy/tree/uix-gridview. So far, just a start, trying out a dictionary-based approach. The present GridView/GridAdapter is row-centric -- it is essentially a list view still. Now, to change out the selection machinery of GridAdapter, so that it handles more than just row-selection -- also selection by column, selection by grid cell. This probably means that it will go from GridAdapter(ListAdapter) to GridAdapter(Adapter), with the selection-handling code of ListAdapter getting retooled for grid needs. GridCell presently subclasses Button, but haven't yet looked at whether this will be good for borders and border styling.
Looks good. I am amazed at how quickly you're getting this together! I could quibble with some of the api, (get_data_item_for_grid_cell for example; couldn't this be get_cell_value?) but I'm nowhere near being able to produce something like this, so I'm not complaining! We initially tried a GridLayout with buttons, and found it rather slow to display. Labels were faster, but impractical to get the cell value from. Your adapter/view model seems like it might eliminate that issue by not attempting to display all the data at once; populating only the area in view. (I think that's what you're doing; I'd have to look more carefully to be sure.)
I've gotten a better grasp of kivy over the last few days, so I'll see what I can figure out regarding grid Button-cell borders and styling.
get_data_item() is the name of the method in ListAdapter/DictAdapter that returns the data associated with a "row" view, a list item view instance for ListAdapter/DictAdapter.
The present design of GridAdapter still uses the "row" concept, and a class, called GridRow. GridRow is the counterpart of CompositeListItem in lists. The "row" concept is retained because of the way scrolling works to request row views with get_view(index).
The GridCell view class is instantiated by the GridRow view class. The data dictionary for GridAdapter has row_keys and col_keys, such that the data associated with a grid row is data[row_key], and the data for a grid cell is data[row_key][col_key].
With the addition of grid cells, and needing to get data specifically associated with a cell vs. a row, get_data_item() in ListAdapter/DictAdapter was renamed get_data_item_for_row() in GridAdapter, to distinguish from get_data_item_for_grid_cell().
Since the gridview work is tagged on to the listview work, still under evaluation and in a bit of flux, it is best now to keep to similar naming conventions, but refining can be done later. Whatever we do, it helps to have a distinction in the naming to know when you are working with a "data item" vs. the view representing it. For example, in writing this reply, I realized that the name of a new method in GridAdapter called grid_cell() is ambiguous, so it was renamed to grid_cell_view(). And yes, after the dust settles, we can rename get_data_item_for_grid_cell() to your grid_cell_value(), or maybe grid_cell_data(), and we can do the renaming across ListAdapter/DictAdapter/GridAdapter for coherence.
And, I've done nothing at all done yet on Button borders and styling, so learning what you can there will help. qua-non posted a link in irc to http://css-tricks.com/understanding-border-image/, which might trigger some ideas.
Jeff
On Nov 1, 2012, at 9:42 AM, dernhelm7 wrote:
Looks good. I am amazed at how quickly you're getting this together! I could quibble with some of the api, (get_data_item_for_grid_cell for example; couldn't this be get_cell_value?) but I'm nowhere near being able to produce something like this, so I'm not complaining! We initially tried a GridLayout with buttons, and found it rather slow to display. Labels were faster, but impractical to get the cell value from. Your adapter/view model seems like it might eliminate that issue by not attempting to display all the data at once; populating only the area in view. (I think that's what you're doing; I'd have to look more carefully to be sure.)
I've gotten a better grasp of kivy over the last few days, so I'll see what I can figure out regarding grid Button-cell borders and styling.
— Reply to this email directly or view it on GitHub.
Thank you for the breakdown, and clarifying the theory behind the current grid structure; that makes great sense. And thanks for the link! Looks like some nice stuff there. I'll see what I can come up with.
Not sure if Github notifies you of additions to pre-existing pull requests, but I added to my previous pull request some basic grid border settings. Tried using the built in border image stuff, but it seemed a but clunky for a grid (didn't play well with resizing, overly complex setup for the end user) so I tried another method. The background itself provides nice bordering, without adding overhead, and it's flexible.
I am just learning this end of working with pull requests. Perhaps because I already merged your earlier pull request (https://github.com/geojeff/kivy/commit/59fa393e724aec37d2b28c49264e8e4d81cb14e4), additional commits won't show up (and if true, you would need to do a new PR I think).
There were Windows line endings in the python file in your PR. Perhaps getting set up with the Kivy commit hook (make hook on http://kivy.org/docs/contribute.html) will address that. But since you are doing PRs to this branch on my repo, it might not take effect. So, perhaps it is an editor setting for saves?
Thanks for the help.
On Nov 4, 2012, at 7:38 PM, dernhelm7 wrote:
Not sure if Github notifies you of additions to pre-existing pull requests, but I added to my previous pull request some basic grid border settings. Tried using the built in border image stuff, but it seemed a but clunky for a grid (didn't play well with resizing, overly complex setup for the end user) so I tried another method. The background itself provides nice bordering, without adding overhead, and it's flexible.
— Reply to this email directly or view it on GitHub.
Ah, okay! I think you'll have to close the pull request you merged before Github will allow me to create another one. (When I tried it informed me that I already had a pull request.)
I'll see what I can do about the line endings/make hook when I'm back on the Windows machine! Thanks for letting me know. :-)
I think even if merged, the pull request is updated and can be merged again…
I've updated my .gitattributes file to automatically take care of line endings, as per https://help.github.com/articles/dealing-with-line-endings. That's committed, so the line endings should be good.
@geojeff -- I'm looking at the implementation in the gridview example, and wondering what the rational is behind 'runTouchApp', and using a GridLayout behind the GridView? Does it have an advantage over the following example:
from kivy.uix.gridview import GridView
from kivy.app import App
class Grid(App):
def build(self):
return GridView(cols = 10, rows = 100)
if __name__ == '__main__':
Grid().run()
I've also started a new data grid project. It has some functionalities added already. I'm now simplifying the code to be implemented in projects as a widget.
Follow this link: https://github.com/pedrodgcouto/kivy.data_grid
Thank you for working on this GridView capability, it will be most helpful. I'm wondering, what is the status of the effort anyways? Has there been any recent movement on getting it rolled into the master branch?
Up. Need database table editor too. There are Russian-speaking developers exists?
@vital-fadeev, exist :)
Since it is 2015 and kivy 1.9 is out, this feature requested from 2012 was supposed to be in the 2.0.0 roadmap. I just want to make sure this feature is not being ignored. Some users still want this feature to be done, especially this feature is there in QT and GTK.
BTW, @pedrodgcouto, thanks for your work.
it's a simple datagrid : https://github.com/namkazt/Kivy-Datagrid-plugin
So, will this still become a part of Kivy?
I need to link a MySQL database to a Kivy grid. So I'm watching this thread too...
We are closing some of the stale issues, please create a new issue/pr if you'd like to work on this feature, or get in touch with us on #kivy-dev.
Kivy is brilliant. We'd like to use it for a warehouse management program we're building in python, but Kivy's GridLayout functionality is minimal...and we display a lot of grids. We'd like to build a more comprehensive grid module that's geared towards displaying data. Is there anyone working on grids already that we could help, or anyone interested in helping us accomplish this?
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.