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 » 08 Mar 2014, 16:03

oh no. We can't do that for the comboboxes. Empty Qvariant toBool will give us false, just like in case of 0. It may work for text values, though…

Can we consider allowing returning data despite non-matching role?

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

Re: Dialogue Sub-Views

Post by Zini » 08 Mar 2014, 16:29

Of course you use isValid to check for non-empty QVarants and not the various toX functions.

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

Re: Dialogue Sub-Views

Post by sirherrbatka » 08 Mar 2014, 17:34

not that obvious to me. ;-)

I decided that we don't need the id edit field (it is redundant to the panel title). At this point both viewing and editing works but i'm not sure if it is a good code and a good idea. Can I ask for a review of my branch? I would like to know your opinion on this solution.

https://github.com/sirherrbatka/openmw/tree/dialogoue3

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

Re: Dialogue Sub-Views

Post by Zini » 08 Mar 2014, 19:07

Looks mostly okay. We still need to come to a conclusion about what to do with non-editable fields.

I don't think not displaying the ID is a good idea. Its an essential piece of information. And for sake of completeness we should consider making it a drag-source. And then we need to enable fields as drop target where applicable.
Also, please do not reply on the ID being the first column.

Depending on how the non-editable fields handled, we may consider handling all fields the same way while an edit lock is active.

That's all I can think of for now.

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

Re: Dialogue Sub-Views

Post by sirherrbatka » 08 Mar 2014, 19:31

I don't think not displaying the ID is a good idea. Its an essential piece of information. And for sake of completeness we should consider making it a drag-source.
ok, no problem. I will tray to find way for dragging later.
And then we need to enable fields as drop target where applicable.
hmmmmm, i hope it won't be hard.
We still need to come to a conclusion about what to do with non-editable fields.
I think we can display icon with the status next to the edit widget. Lock for locked, changed for changed, and not-changed for not-changed.

Thank you for your time. :)

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

Re: Dialogue Sub-Views

Post by sirherrbatka » 09 Mar 2014, 18:53

ok, qt wizards. I can't make those widgets correct size and it is vevy annoying.
http://wstaw.org/m/2014/03/09/zrzut90.png

I tried to set the size policy, change maximum size and minimum size. Only changing minimum size seems to have any effect on the widget. At this point i think i should dive into creation of those widgets (i have to do this anyway) but maybe somebody have any idea?

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

Re: Dialogue Sub-Views

Post by sirherrbatka » 10 Mar 2014, 13:37

since i got no answer i just hacked something on my own:
http://wstaw.org/m/2014/03/10/zrzut92.png

Despite disabled widgets, does it look fine?

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

Re: Dialogue Sub-Views

Post by Zini » 10 Mar 2014, 14:05

Not really. The text in the disabled widgets is barely readable. I suspect there is no way around using regular labels instead.

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

Re: Dialogue Sub-Views

Post by sirherrbatka » 10 Mar 2014, 14:16

Despite disabled widgets
:roll:

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

Re: Dialogue Sub-Views

Post by Zini » 10 Mar 2014, 14:38

This sentence can be interpreted in more than one way ;)

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests