BTW, since we are getting editor dialog we may consider hiding description column on table view. Simply because descriptions are loooooooooooooooong when compared with other strings.
http://wstaw.org/m/2014/03/10/zrzut94.png
Right now dialog chooses qplaintext widget for every display_string longer than 50 chars. I'm not sure if we want to keep this behavior or limit it to the descriptions.
Dialogue Sub-Views
Re: Dialogue Sub-Views
I don't see a reason to exclude descriptions from the tables. If the user does not want to include the descriptions, he can remove them via column filters.
Determining the widget type based on the text length is suboptimal. Among other things this would mean the same field could be represented differently for different records. And I don't even want to get into what happens if you have a short text that is expanded later.
The right thing to do here is to differentiate the Display type further. Display_LongString maybe? Used for descriptions and dialogue text.
Determining the widget type based on the text length is suboptimal. Among other things this would mean the same field could be represented differently for different records. And I don't even want to get into what happens if you have a short text that is expanded later.
The right thing to do here is to differentiate the Display type further. Display_LongString maybe? Used for descriptions and dialogue text.
- sirherrbatka
- Posts: 2159
- Joined: 07 Aug 2011, 17:21
Re: Dialogue Sub-Views
ok, done and done.
http://wstaw.org/m/2014/03/10/zrzut95.png
Strings and enum columns that are not editable are now displayed in QLabels. Those labels replace normal widgets – handling dynamicly disabled fields can be a little bit annoying but is it even needed?
http://wstaw.org/m/2014/03/10/zrzut95.png
Strings and enum columns that are not editable are now displayed in QLabels. Those labels replace normal widgets – handling dynamicly disabled fields can be a little bit annoying but is it even needed?
Re: Dialogue Sub-Views
I don't think we currently have any non-editable fields that are specific to a subset of referenceable records (I presume that is what you mean with dynamic). I doubt this will change in the future.
Looks good overall. Where are we standing now? The field state icon idea of yours? Anything else missing (except for the dialogue mode only fields obviously, for which we don't have columns yet) ?
Looks good overall. Where are we standing now? The field state icon idea of yours? Anything else missing (except for the dialogue mode only fields obviously, for which we don't have columns yet) ?
- sirherrbatka
- Posts: 2159
- Joined: 07 Aug 2011, 17:21
Re: Dialogue Sub-Views
Overall works but i still need to handle referencables (not sure what i'm missing). There is also bug in the class tables: i'm not able to change attributes using table and combobox in the editor is empty initially (though it is possible to change it). Not sure if i broke it or it wasn't working in the first place (compiling from scratch takes awfull lot of time, don't hate me).Where are we standing now?
After dealing with it: next and prev buttons, deleting and so one.
At this point I decided to move it post 1.0. There are more important tasks right now.The field state icon idea of yours?
Re: Dialogue Sub-Views
Changing attributes in the class table works fine here.
- sirherrbatka
- Posts: 2159
- Joined: 07 Aug 2011, 17:21
Re: Dialogue Sub-Views
https://www.dropbox.com/s/ipmgyl9jhxysmws/out.ogv?m=
This is how it is broken for me, to be precise. I will investigate tomorrow.
This is how it is broken for me, to be precise. I will investigate tomorrow.
- sirherrbatka
- Posts: 2159
- Joined: 07 Aug 2011, 17:21
Re: Dialogue Sub-Views
Problem solved. And about the referencables…
it seems that when i try to create dialog view for referencable, opencs attempts to create it for specific referencable type, for instance clothing – that's why it fails.
it seems that when i try to create dialog view for referencable, opencs attempts to create it for specific referencable type, for instance clothing – that's why it fails.
Re: Dialogue Sub-Views
I see. I guess the only way around that is to remap UniversalIds in CSVDoc::View::addSubView (check for individual types and create a new UniversalId using the general refereceable type (Type_Referenceable) instead).
- sirherrbatka
- Posts: 2159
- Joined: 07 Aug 2011, 17:21
Re: Dialogue Sub-Views
this works, thanks. We need to put this into the scroll area or something…
http://wstaw.org/m/2014/03/11/zrzut97.png
http://wstaw.org/m/2014/03/11/zrzut97.png