Skip to content

Made "Feedback" inherit from parent if empty #10

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
richardwilliamson wants to merge 6 commits into
base: master
Choose a base branch
from
Open

Made "Feedback" inherit from parent if empty #10

richardwilliamson wants to merge 6 commits into from

Conversation

@richardwilliamson
Copy link

@richardwilliamson richardwilliamson commented Apr 7, 2016

Not fully there but shows the principle..

Only does the FeedbackPath for now, basically if that’s empty then it pulls the value from the Grid (which is now enabled). Couple of issues though..

  • Haven’t looked at persistence
  • Probably need to split the Getter on feedbackPath() so that it doesn’t change the local value when editPanel is loaded (as that also calls GetFeedbackPath()
  • Haven’t looked at wildcards yet, but am thinking that you could have %c = column, %r = row, %n = cell number

@richardwilliamson
Made "Feedback" inherit from parent if empty
f6a7fdf 
Not fully there but shows the principle
@richardwilliamson
Copy link
Author

richardwilliamson commented Apr 7, 2016

Also, not sure but I think the pairing may need updating once the parent is changed as I think the messages are cached.

Let me know what you think - I'm happy to potter on with this bit if it seems useful!

@MizPlusPlus
Copy link
Member

MizPlusPlus commented Apr 8, 2016

Oh, this is a fantastic idea! Will review the changes when I get some time...

@richardwilliamson
Added in wildcards + should work on all widgets
4afe116 
Added getRawFeedback() to ToyWidget which returns the actual feedback
value for that widget (whereas getFeedback() returns the value that
will be actioned (with wildcards etc processed, or the parent’s if
relevant),

When grid is created tell each widget which row, column and index it is
(zero based)

Added wildcard processing:
{r} will be replaced with the (zero based) row of the widget
{r1} will be replaced with the (one based) row of the widget
{c} will be replaced with the (zero based) column of the widget
{c1} will be replaced with the (one based) column of the widget
{n} will be replaced with the (zero based) index of the widget
{n1} will be replaced with the (one based) index of the widget

I also made the default feedback value of a widget /XX/{n1} for
testing.. begs the question what it should be.

A few things todo/to consider

- Extend the above to work with all OSC fields - extract the wildcard
code so it can be re-used
- Consider default values - maybe default so that Grid has the default
(/XXX/{n}), make the placeholderText on the field in the edit box into
the parent’s value
- Is there a way to also inherit colours etc? Don’t think these would
use any wildcards but would be useful. To complicate matters it would
be good to be able to edit these on a per-row. Well, actually it would
be great if all of this could be per grid, per row or per cell…
- Would be nice to also have an “offset” which can be modified. This
would mean the user can somehow have up/down buttons which modify a
base value - then we could have the wildcards of {oc}, {or}, {on} etc
where these are the cell/column/num plus an offset. We would probably
want a different offset for each one. This would allow the user to
cycle through presets/palletes etc in an eos scenario
@richardwilliamson
Merge remote-tracking branch 'ElectronicTheatreControlsLabs/master' i…
323c26c 
…nto inherit-message-from-parent

# Conflicts:
#	OSCWidgets.xcodeproj/project.pbxproj
#	OSCWidgets/ToyGrid.cpp
#	OSCWidgets/ToyWidget.h
@richardwilliamson
fixed after merging master into branch
a0385a1
@richardwilliamson
Added up/down to widgets and some other stuff
7494e99 
Added an up/down button to the grids. This should probably be optional
but I’m still unsure about best way to adjust grid. The wildcards now
include {pn}, {pc}, {pr} where p is the page number.

I’ve only tested this with Activity and Button widgets, I also haven’t
done anything about persistence.

I would still quite like to be able to inherit per row - this could be
via the edit menu, so you edit activity, or a row, or a widget. The
widget would take it’s value, or the row’s value, or the table’s value.

There is a question though about how to inherit values such as check
boxes (the “local” field for example) where blank does not mean empty..

Hmm, let me know what you think anyway
@richardwilliamson
Made it work properly
9392e89 
- Should now work on all widgets
- Should now work on all applicable fields
- Should now be persistent
@richardwilliamson
Copy link
Author

richardwilliamson commented Apr 16, 2016

Not sure if you've seen my various commits but I think I have got this feature pretty much there (if you like it!) A couple of notes/bugs/todos..

  • Currently, in order to update the (non OSC) label with wildcards, this is checked every time the paint event is called as I don't really understand the whole QT slots thing - I think there would be a better way to do this when the page up/down is changed..
  • Currently the Label is inherited, however this isn't great as it is unlikely (I think) that you would want a grid's label on all the widgets within it - there probably needs to be an extra field in the editGrid
  • Currently the up/down buttons appear on every widget, I think that something like the command widget wouldn't want them - with the other ones I suppose the question is should they always be there, or should the user be able to turn on/off (or, they could only appear if the user has used the {px} wildcard?
  • There is a worry that page up/down could confuse the user into thinking that they can set a manual value to every widget across all the pages.. That is probably just a documentation thing

I have only done basic testing, so there probably are some bugs!

Let me know any thoughts..

@richardwilliamson
Copy link
Author

richardwilliamson commented Apr 16, 2016 •
edited
Loading

Oh, for reference these are the wildcards

     //{r} = the row in the grid (0 based)
    //{r1} = the row in the grid (1 based)
    //{c} = the column in the grid (0 based)
    //{c1} = the column in the grid (1 based)
    //{n} = the number of the item in the grid (0 based)
    //{n1} = the number of the item in the grid (1 based)

    //if any of the above preceded by p (ie{pr}) then the offset version is used

I wonder if the default should be the 1 based option, as this is probably more logical to the user, and there could be an {x0} for each one which sets it to 0 based?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@richardwilliamson @MizPlusPlus