As for mTable->rowCount() failing, the most likely reason would be that you don't have a valid table in the first place. If that is not the problem, then you have to produce a stack backtrace, so we can see where exactly the crash is happening.
Sorry for bothering. It was my fault. After carefully inspecting stacktrace i realised that it was fault of recurrency in my function. After creating new variant of those functions i don't get segfaults.
Regarding other issue, can we emit data changed signal when deleting record? I think we should.
The last thing that needs to be done is delelting records. Honestly i don't think it is really needed. If it is needed i will be able to do this in next few days.
There is actually a substantial number of additional functions that might be useful. Basically everything from the context menu that is specific to a single record. That would be:
- delete
- clone (we may skip this one, because it would require an additional input field and isn't really specific to a single record; there are two involved instead)
- revert (for most types)
- view (for a few types)
- preview (for a few types, still WIP in my preview branch)
I am not entirely sure what to do about these. Adding them would clutter up the interface more. But not having them would result in poor usability. Let's say you want to view a cell that you are currently edit in a dialogue. Without these functions you would first have to locate the cell in the cell table and then choose view in the context menu.
Maybe we can add these functions via small buttons in the same row as the prev/next buttons? I would suggest using icons instead of text to label the buttons, so they also work properly in windows that are not very wide. Maybe even the prev/next button labels should be replaced with icons?
Why aren't extra buttons an option? I strongly disagree with a menu. That would have to be a context menu and a context menu that has a whole subview (potentially a whole window) as context would be weird and unintuitive.
because we would have to squish next, prev and 4 other buttons. 6 buttons will look rather cluttered. next and prev buttons are navigational buttons, the rest is same as in the context menu of the table and clearly does not belong to the navigational group.
I disagree about the squishing statement. To be useful the dialogue subview has the have a certain width. If we use small icons (square, as big as the current buttons are high) instead of the text as labels for the buttons, there will be plenty of horizontal space. There will even be enough space for dividing navigational and editing buttons into two separate groups.
Of course that assume we can find suitable metaphors for these buttons, that do not require a large icon (and therefore a large button). Delete should be obvious (red cross). Prev/Next would suggest some kind of arrow. Not so sure about the others. If we can't find anything that is reasonably clear, we may have to take the menu-route anyway.
btw. I am slightly weired out about me promoting a button bar over a menu system. Normally I would favour the menu, because it uses no space for controls and leaves all the screen real estate for content. But then, we already have a button bar, so I guess the argument about saving on screen real estate is irrelevant.