Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
An idea for a new widget
I'm not sure how practical it would be to take this one. It's one of those things that it's easy to draw on a white board but probably a lot of devils in a lot of details, and definitely the first iteration couldn't begin to be all that it could eventually be. But, one thing that keeps coming up as something that could be useful, but difficult in the IV is a tabular control, i.e. rows and columns, each cell of which is a live value that is kept up to date.

It comes up in various ways. If you wanted to show a list of your security areas or zones and a few pieces of information about each one, or your irrigation zones or programs and some status on each. Or power consumption channels and a small number of values related to each one. 

There are lots of situations where it would be desirable. I've been thinking of how one might do that in a way that's not crazily difficult to implement (for me or for driver writers who would have to make that information available.)

Driver Support

For the driver writer, the obvious thing I think is that I would provide them with a class that they can use to manage that information. So, they would indicate that they want X number of rows, and then add the number of columns they want, and the type information for each one. And they could then subsequently update any cell, or row at a time to keep the data updated.

I would maintain the data internally and manage changes in a way that would allow that object to serve up only data that has changed since the last time a particular client asked for it, so that this scheme could support efficient polling by IV clients. It would provide a method that will return any changes since a given point, formatted in a way that is appropriate for the widget's need, so the driver would just pass on the request to the tabular object and return whatever he gives back.

We'd define a standard driver backdoor call that any driver could handle, passing incoming queries for data to this object which would bundle up the data and the driver would return it. So the burden on the driver would be fairly minimal.  The backdoor call would have a query type that indicates it's one of these types of tabular queries, and the data value would indicate which such tabular data set the caller is interested in, so that a driver could provide multiple such sets. There would be another one that would get design time info only (rows, columns, column data types and column titles.)

The short of it is that it wouldn't be much effort on the part of drivers to maintain such tabular data and serve it up.

IV Support

On the IV side, it would be a widget that you would associate with a driver, and you'd indicate the data value name (the name of the set you want to get.) The widget would query information about that data set, and let you set the width of each column interactively. 

The sticky part is the height. Obviously we'd want it to be scrollable vertically in order to get to all of the rows without having to be literally tall enough to show them all. I think that requiring it to fit horizontally is not too onerous and would be a good simplification for me. But clearly it has to be scrollable. That's always tricky but doable. It might be best to initially just do a non-scrollable one to start.

At viewing time, the widget would get the initial full batch of data and display it, then periodically poll the driver for changes and update those cells that have changed. Obviously, a static table could be achieved by just never returning any changes, so a driver could provide a table of info about its configuration or something that would only ever change if the driver was reconfigured or forced to reload configuration or some such.

Various other complications could be involved if, say, one person wants this set of columns and another wants that set of columns. We don't want to force the driver to redundantly store data for multiple views. So one longer term change could be to allow the IV widget to only query a subset of columns. Just ignoring columns wouldn't be to much more work, but doing it efficiently, i.e. never querying columns it's not going to display, would be a good bit more, since now it has to always be passing in some sort of query map or something.

Another complication is how do you do deal with the number of rows changing. I think that, initially, it would be reasonably to say that we would only support fixed row counts, or they'd only change if the driver was reconfigured which would force the widget to completely reset itself anyway. I.e. your security zones or irrigation zones aren't going to change on the fly, that's driver configuration stuff.

And another one would be, I want to use an image for this cell instead of text. Clearly that would be very desirable, but it would require considerably more configuration, so maybe something that would be left for V2 or something.

Another would be column title headers, which is actually an annoying tedious thing to deal with since it means that the whole area of the widget isn't the data area, so all calculations get much more complicated wrt to scrolling and cell placement. Initially you could just do your own as separate widgets. As long as the design time widget shows the outline of where the cells are, you can easily place your own titles and have complete control over how they look. That might be best long term really. Row titles would just be part of the tabular data, i.e. probably the first column of the rows, and put there by the driver.

It might also serve as the basis for TV channel scheduling displays as well. To really be useful that might require some more additions, I dunno. But even in the basic form it could probably be used for this. 

I figure when clicked you'd get an OnClick event that tells you the row/column clicked on and the value in the clicked cell, so that you could do something in response. That would be a simple bit of extra code that could make it far more useful.

So, basically that's the idea. Of course it took me only a handful of paragraphs to describe it, but it will be a lot of work to do. So I just wonder how much people would want such a thing to know if it's worth doing. Obviously there are a lot of ways it COULD be used, but the question is, how many people really NEED such a thing, relative to other things that could be gotten in the same amount of time. 

I'm guessing it's a couple weeks worth of work for a basic implementation.
Dean Roddey
Explorans limites defectum
One thing I'd forgotten about is our ability to do dynamic content generation (see the docs for the Overlay widget.) With a little more flexibility, it could actually handle most of the scenarios I mentioned above really. It would need a little more power in terms of the search/replace operation that occurs. Right now it can handle generating multiple instances of the template, one per a list of provided monikers (i.e. one instance for each device of the same type.) Or, it can generate multiple instances of the template that references a single field, and it just updates the field for each one from the provided list.

If it could replace multiple fields in the layout template, with values from a list, then it could do most of what I was talking above with what we already have. Ultimately I don't think the performance would be any worse overall. And, the big win is that things I mentioned above like I want an image for this cell, become a non-issue because you provide the layout template and can put the widgets in it you want.

So I'll have to think about that a bit and how to expand that guy to make it more powerful.
Dean Roddey
Explorans limites defectum
Will this be good to use for something like a TV guide?
Nest|Harmony|Neeo|LG TV|Smarthings|
Only in a very minimal way. And, as I mentioned above, it might not even be necessary to do it, because the dynamic content generation stuff probably can do this stuff, if it just gets some improvements.
Dean Roddey
Explorans limites defectum
(03-13-2017, 01:16 PM)Dean Roddey Wrote: Only in a very minimal way. And, as I mentioned above, it might not even be necessary to do it, because the dynamic content generation stuff probably can do this stuff, if it just gets some improvements.

Are there any other new widgets that are wanted by the community.  Maybe a poll to determine whats wanted more and then use that as a guide as to which should be done first.

For me, I would like to see a gauge widget, and some better graphing widgets
Mykel Koblenz
Illawarra Smart Home
I think you can do a google gauge with thingspeak, I haven't looked at it in a bit though.
Nest|Harmony|Neeo|LG TV|Smarthings|

Possibly Related Threads…
Thread Author Replies Views Last Post
  Video Widget znelbok 67 38,866 04-12-2017, 04:08 PM
Last Post: Dean Roddey
  Idea for a different kind of event processing mechanism Dean Roddey 0 1,613 03-20-2017, 09:29 AM
Last Post: Dean Roddey
  Web browser widget Trioxide 7 5,512 02-25-2017, 06:30 AM
Last Post: Trioxide
  IV Admin Screens, or my latest stupidly complex idea IVB 0 1,932 07-26-2016, 05:56 PM
Last Post: IVB
  Slider Widget potts.mike 1 2,111 04-19-2016, 04:59 PM
Last Post: Dean Roddey
  Field Incr/Decr Button Widget khill 15 7,853 05-17-2015, 01:04 PM
Last Post: dlmorgan999
  Overlay in an Overlay triggered by Widget Deane Johnson 4 3,830 11-09-2014, 10:29 AM
Last Post: Deane Johnson
  new widget, scheduled event modifier willplaice 2 2,233 01-14-2013, 01:33 PM
Last Post: willplaice
  Web Widget Usage SamVimes2 11 4,979 09-20-2012, 04:23 AM
Last Post: kfly
  Automatically refresh web image widget in RIVA? standon 8 4,552 02-26-2012, 08:45 AM
Last Post: kfly

Forum Jump:

Users browsing this thread: 1 Guest(s)