Sergey asketh: > Must Spreadsheet QML element be written using Qt C++? >
This is a very interesting exercise, IMHO, and I'm very interested in the results. (Please share as you learn stuff.) In the past, I've written and used many "spread-sheet-widgets". The issues seem to come down to: (1) How many cells are we talking about (how big is the grid)? If "big", I'd assume C++ is the only way to go. (2) What is the "data-model"? (Do you have a database back-end, a grid-of-strings you are reflecting, primitive types or application-specific types, etc.?) (3) (Possibly less relevant), how are you intending the "notifications/updates" to occur in the GUI when the model changes? (Each "cell" is atomic, or a sweeping change for all-cells, handling recursion, etc.) My guess: All-QML should be fine for "small". However, for "big", most historical implementations render a "bitmap" to the screen for all the cells, and create-a-component-on-the-fly when the "cell" is "clicked" on the bitmap. That's because creating a component for each cell was historically resource-prohibitive. Even a 100x100 grid with "buttons" or "text-lines" on X/Motif or Windows was absolutely unusable (too slow/expensive). That should be better today, but you'd be surprised how *quickly* you can't have all-widgets-all-the-time. That *might* be different for QML, which is why (3) notifications/update with declarative-QML might be different. It probably *is* quite a lot better, since QML components are "lighter" with a different rendering mechanism, and they use OpenGL with a separate update/notification engine for the "component" outside the GUI. It's quite possible that we could now *have* the 10Kx10K grid-of-QML-components. That's what I want to understand, and why I was thinking about writing one. (I'd want the back-end in C++, though, so I could expose application-specific types like from hardware.) For example, I've been considering a QML-spreadsheet implementation, because the declarative representation and transitions/rendering pushed to OpenGL could solve a lot of problems, and QML should be able to provide a spreadsheet-interface with much "richer" user-feedback than historical implementations. And, most applications have reasonable need to display "records" or something in a spreadsheet-like interface. > Are there some ready tutorials/demos/examples for it? > I'll bet "no", but maybe (because it would come after the desktop-components in Qt5.1). I'd be very interested in any effort that then *benchmarks* the usability with a grid of 100x100, 1000x1000, 10Kx10K, etc. (That defines the scenario by which the design approach is reasonable.) Is it possible to attach such an element to PyQT4? > I'm sure that no matter the implementation, it should be available to PyQt4 without much trouble. But, I'd assume a spreadsheet-component would have a rich API, so it might have a non-trivial interface/adapter to maintain. The commercial spreadsheet-widgets were historically priced high ($), because they are tricky to "get-right" with a reasonable API, and to ensure it could "scale" to real-world data-set-sizes. IMHO, your "ambition" for how it would be used is quite important as it relates to your design/implementation. For example, if you merely want something 100x100 cells, you could probably do anything, and it would perform fine. --charley
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest