Devo12 wide screen configurable GUI (intermediate

Separating the main page config from the model config will cause more unpredictable results when sharing configs, especially if it is only partially separated...

I'm not agains that, just would like to warn.

An other example is the box contents for the different protocols: the throttle channel (which I always used to show) will differ, so it is hard to make the main page config generic...

While I thikn it is cool to be able to move items around on the Tx, I'm not yet convinced it is a requirement. If we could load a pre-defined template from the filesystem, users could do their layout on the PC if they didn't like any of the pre-defined templates. The interface to defining them will likely be kludgey enough on the Tx for it to be worthwhile to do on th ePC if possible anyhow.
Or maybe we only support this ability on the Devo12 and not the others.

I am more concerned with how to display the configuration. Today you have a list of everything that is configured on 3 pages. this makes it easy to see what is in the src boxes or graphs or toggles all at once. If we allow configuration of this (as Rbe's code does today, and would be worse with this proposal) we need some way of configuring the value. Today (in Rbe's code) when you select an item from the preview, it shows the cfg for it. we could use that model but you lose a lot of visibility. We could also have a scrollbox containing all items and values and when you select one, it highlights on the preview.

Another options would be to choose the src type from a spinbox (src, toggle, graph, etc), and then show all configs of that type on one page (again, highlighting the proper box in the preview as appropriate). this may provide an interface closer to the current deviation release and give more info to the user.

FYI, with the x/y solution, I would enable placement of each individual toggle, graph, and trim so that it is possible to come upith more interesting layouts (like 4 toggles in a square) than we have today. but this again means you potentially only see one toggle at a time.

The compatibility issue is actually quite hard to achieve (this is true with Rbe's interface as well). I think when switching between Tx types, we need to reload the default GUI. This means you would need to reconfigure the display if moving from a devo12 to devo8. That isn't ideal, but I don't really see any way around it.
I guess we could map the sources for each control type into the 1st available on the new Tx layout. I'm not sure that would work very well though.

Here's what i was thinking:
define the front page via a structure which looks something like:we have an array of 'n' items matching this structure (based on the Tx screen)
the main_page becomes very easy, as it is just an iteration over this structure and dropping the items at the relevant place.

filling the structure from an ini file is also trivial as we just populate it in order

the configurable GUI part is more interesting. I think I'd start with a page to layout the elements where we have a 1:1 display with a menu on the header. The menu would allow me to select one of the element types (small-box, big-box, bar-graph, toggle, trim, joystick, but not icon since this is mandatory and must always be present) and then to place it. clicking on an existing item would let me move it or remove it.
I'm not sure we need a pulldown (though it would be cool if it works); a set of icons representing each of the element types may be sufficient.
I'd want to be able to see the x,y coordinate of the currently selected icon on the header as well. Having the ability to do some sort of alignment would be nice, but I'm not sure it is necessary.

I'd expect the display to indicate the elemment type and src, although that may not be possible for the toggle and bargraph elements since they are so small.

To configure the elements, I'm really not sure. I've thought about a couple solutions:
1) have a dialog popup from the positioning screen to edit the elements
2) have a separate screen to configure the elements

either way, I'd want to be able to see all of the elements of a given type at once (so I could configure all of the box elements at once, or all of the graph elements..much like the current deviation page). The Dialog box is probably too limited to support this feature today, though we might be able to embed a scrollable into it to solve that. Of course, the scrollable is not currently ported to the 320x240 screen so that might also need to be done (the scrollable is a widget I built for the 128x64 screen. It is a fully automated scroll window which can embed other widgets...something like a listbox but with widgets inside)

the spacers will likely be going away.
having a new 'string' element type would be possible though with my current proposal.

after implementing about 3/4 of the code needed for my above idea, I figured out it will use too much memory for the devo7e. So I've gone back to a olution more similar to Rbe's branch as far as the structure goes.

Here is the branch I made:
bitbucket.org/PhracturedBlue/deviation-newgui

What it can do:
you can layout widgets using x,y locations, from the ini file (the syntax may change)

What it can't do:
build devo10/7e
bargraphs are broken
no way to confgure the display except through the ini file
no conversion from the old models
limited number of elements
doesn't have wide-screen support
none of Rbe's new elemet types
I didn't remove the (now useless) page configuratiuon code

The main purpose was to define the main screen in a flexible way such that we can plug elements into the structure and have the display work properly.

Rbe, you should look at it to understand the pagecfg.h (specifically PageCfg2)
The code assumes all elements are 'packed'. I.e. we stop iterating over elements of a given type as soon as we find one that is undefined. An item is undefined when its y position is 0 (though that may change)

I will likely start porting your new elements over to it next. I want to design the interface on the devo8 and extend it up to the devo12 rather than the other way around, because it is usually easier to extend then to scale-down.

Yes, as I said, I started with theunion approach of a superset object. The problem is that the GUI widgets also need to be a superset then, and so you are constrained by the largest widget. So it is a tradeoff of max_widget_count * larget_widget_size vs max_num_boxes*bow_widget_size+max_num_bars*bar_widget_size +...

My initial analysis says that the latter will take up less RAM.

Switching the structure wouldn't be too hard to do though. I already wrote ~75% of the code.

For now, I'm going with it as is though.

I implemented a crude configuration page for the widget layout to see how well it works. Widgets are moved only via the spinboxes. It actually isn't that bad to do it this way if the drag-n-drop doesn't work out. I want to see if I can add a GUI_MoveWidget which won't result in redrawing the entire page as that would hep a lot.

I'm running out of time for today, but I have made more progress on the configuration gui.

I can now move all elements with the physical buttons. I am no longer convinced that drag-n-drop is really necessary given how the code is working now.
The thing that is still missing is the ability to configure the elements.

My current plan is to add a scrollable to the dialog widget and to populate it with all elements of the selected type when 'ENT' is pressed.

FYI, here's what it looks like at the moment:

Ok, I've added the element configuration menu. I had to rework the dialog handling to getthe scrollable to embed, but I'm pretty happy with the result:
Devo12:


Devo12 with config dialog:


There are still a few issues, the biggest of which is that I don't have room for the page-change icons on the Devo8 page. I also want to spend time to see if I can improve the element-move performance.

I've placed the devo12 emulator here if anyone wants to try it:
bitbucket.org/PhracturedBlue/deviation-newgui/downloads

Rbe, please don't take offense that I went my own way. I was all set to merge your changes when I realized that a setup like this would likely make thing much more intuitive.

There is still more to do, and I would absolutely encourage you to keep up the good work to help improve Deviation.