Dialogue Sub-Views

Involved development of the OpenMW construction set.
User avatar
sirherrbatka
Posts: 2121
Joined: 07 Aug 2011, 17:21

Re: Dialogue Sub-Views

Post by sirherrbatka » 13 Mar 2014, 16:58

is wrong. That is an off-by-one error.
I understood it ;-)
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. :oops:

Regarding other issue, can we emit data changed signal when deleting record? I think we should.

User avatar
Zini
Posts: 5134
Joined: 06 Aug 2011, 15:16

Re: Dialogue Sub-Views

Post by Zini » 13 Mar 2014, 17:13

Define "deleting records".

Do you mean flag a record as deleted? In this case a data changed signal is emitted already.

But if you mean erase a record from the collection, then the answer is no. There are other signals for that (with the word 'rows' in it).

User avatar
sirherrbatka
Posts: 2121
Joined: 07 Aug 2011, 17:21

Re: Dialogue Sub-Views

Post by sirherrbatka » 13 Mar 2014, 18:50

You were right.

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.

Otherwise it is complete.

User avatar
Zini
Posts: 5134
Joined: 06 Aug 2011, 15:16

Re: Dialogue Sub-Views

Post by Zini » 13 Mar 2014, 20:05

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?

User avatar
sirherrbatka
Posts: 2121
Joined: 07 Aug 2011, 17:21

Re: Dialogue Sub-Views

Post by sirherrbatka » 13 Mar 2014, 20:47

hmmm, i forgot about this – and I just started to think that i did a good job here :lol:

I think we need to add a menu here. Extra buttons is not any option. Besides: we will have consistent behavior between both tables and edit subview.

I will not have lot of time to work on it in next few days, though. :(

User avatar
Zini
Posts: 5134
Joined: 06 Aug 2011, 15:16

Re: Dialogue Sub-Views

Post by Zini » 13 Mar 2014, 20:58

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.

But no worry. We are not in a hurry here.

User avatar
sirherrbatka
Posts: 2121
Joined: 07 Aug 2011, 17:21

Re: Dialogue Sub-Views

Post by sirherrbatka » 13 Mar 2014, 21:31

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.

Tarius
Posts: 574
Joined: 24 Oct 2011, 19:29

Re: Dialogue Sub-Views

Post by Tarius » 14 Mar 2014, 00:06

A cluttered menu is better than less usability when it comes to widely known and used functions.
I am a bigger fan of tons of control rather than taking the "user-friendly" approach.
-Okulo

User avatar
Zini
Posts: 5134
Joined: 06 Aug 2011, 15:16

Re: Dialogue Sub-Views

Post by Zini » 14 Mar 2014, 09:33

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.

User avatar
sirherrbatka
Posts: 2121
Joined: 07 Aug 2011, 17:21

Re: Dialogue Sub-Views

Post by sirherrbatka » 14 Mar 2014, 11:38

Very well, let it be. I will work on that next week.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest