Regarding the use case of saving data: That's what confused me as well when I started to work with Glom. You somehow expect the edit/undo/save/load paradigm (is there a better name for that?). Well, since undo and save are missing perhaps one could wrap everything into (database) transactions that get applied when you change windows (or when you click "apply changes"). That would allow undos and perhaps be more fitting to what the user expects?
Another possibility could be a flag for each row (in list view) indicating whether the data in that row is still in a dirty state or whether it was already made persistent. Or use a signal color (yellow, red, ...) for the cell background while editing in the details view, hinting at how the data is only made persistent after finishing editing a cell. The color semantics (for a cell) could then be: * white or blue background: persistent data * red or yellow background: dirty data regards, Michael Am Mittwoch, den 10.06.2009, 11:16 +0200 schrieb Murray Cumming: > Data is saved in the database as soon as you enter it. The structure is > saved to the .glom file as soon as you change it. There is no need to > explictly save anything. I'd welcome suggestions to make that clearer. _______________________________________________ glom-devel-list mailing list glom-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/glom-devel-list
