Devo12 wide screen configurable GUI (intermediate

I am not sure.
I converted them to icons, but that did not work as I expected. Then I converted them to buttons and this also does not work (at least they are visible but only until redraw; maybe I create them too late and GUI_RemoveHierObjects() clears them...).
But I have changed a lot of things in the code to get the keys working so I am not sure where the problem is. I am working on it, but I had nearly not time at all at the weekend.

The buttons are working now; the icons seem to be overwritten. I am searching...

rbe2012 wrote: ...the icons seem to be overwritten...

Not overwritten, only locally defined...

PB, I've got a new version ready (c0e3510). I have worked hard and did not test all, but the main functionality should be working.
You can move through the elements via keys (UP/DOWN) or with the touchscreen. Changing from elements to cfg with ENTER, back with EXIT. Changing element's type with LEFT/RIGHT.
Not implemented yet: long press ENTER/EXIT for save/cancel.

Please tell me if this is what you imagined.

Redrawing must still be optimized...

PhracturedBlue wrote: Here are the things I've seen so far that still need to be addressed:
* The elements can overlap when changing their type

Yes, it's because only the actual element is redrawn, not the rest. Was working in an earlier version so shall be easy to fix.

* hitting 'Esc' from the edit 'chain' results in the top of the screen being corrupted (Where it says 'Main page config')

There is an invisible element which works as dummy so no other element must be selected. I will find another solution.

* The colors of the element control icons makes it very difficult to see which is selected

I am not the big designer. This was just a quick draw...

* it doesn't seem to be possible to exit from the editor with the buttons (I'd recommend that a single 'esc' from the element chain moves you to the 'save' button, long 'ent' is save (but keep my current selection), and long 'esc' is cancel.

Yep.

You probably know about all of them, but just in case. Again, it is looking really nice now. It is nearly time to merge it I think.

Oops, I have still some points to optimize and very much ugly debug code inside. But in general with the additions mentioned above I have a good feeling too.

Just a few questions:

1. I actually can place the preview on the left or right with a #define. Shall this be configurable individually?
2. I can also display three or four rows for those who want it closer to the Devo8 gui. Again: shall this be configurable or removed?
3. The gui also works identically for the 320x240-screen. Shall this be configurable?
4. The element control icons are placed at the right side actually because I had difficulties to show them. I can draw them again above the corresponding column. What seems better?
5. What about the sequence of the control chain (actually sources, trims, quickpages, element controls)?

So far for now, maybe I will see more when working on it.

I believe, fast shifting up and down with a long press on the arrows does not work actually...

Did you make an emulator file I can download and play with to have a look?

Not yet, give me a few minutes...

Ok, I have uploaded an actual emulator. It is called emu_devo12-2ec142.exe (I kept the rest to avoid that someone loads it on his real tx at the moment...).

Thanks for your hard work, but this version is a bit too messy to evaluate. Carry on and I will wait for something more stable. Also, to tell you the truth, I liked the previous version better....

Hi guys,
good idea; I have thought about that before. But leaving the fixed x-coordinate will make things more complicated. In the end it will surely be possible.
I will have to think more about this.

Some ideas to discuss:
Should we use an 1:1-screen (no reduced preview) with the ability to place elements where they have room? Existing elements could be moved to somewhere else to make room for others...
How should elements be moved? I do not expect that the power of the mcu will suffice to allow real drag'n'drop. I think we could use some kind of "anchor points" (corners or center of element) to place it with the touch pen.
Realizing some alignment seems possible if we show the coordinates somewhere. Or perhaps we can align a selected element to the edge of another.
How should properties be changed? Opening a dialog? Or having two modes - one for designing / positioning... and another for changing properties?

I am actually working to make the keys and the touch screen being usable similarly in all situations and I am quite far, but have less time than expected for programming. It will get better after this weekend, I hope.
But even if I am ready it will have an underlying structure assigned to the columns and rows. Giving them up will have massive impact to the code, but I believe I have divided the code in so much functions that this could be handled. It will also make some things easier if we allow moving only within the free area around an element.

After some more thoughts I imaging it could be good and there were less challenges that I have feared when I first thought about it.
But I need some time to got through it again.
Stay tuned, more tomorrow.

PhracturedBlue wrote: Yeah, I thought about that. I think I'd just provide the x/y coordinate of the element so you can see if it is aligned or not. Using a grid is possible as well though given the variable size of the elements may not work well.
Having an 'align' would be best, but would complicate the code quite a lot.

Just go back to my post 10672 (page 6). Column and Row is exactly the same as x/y coordinates. What I proposed should be very simple.

- You start with an empty preview screen
- Left from it is a "New" button
- You define the function of this element
- Define row and column you want to place it
- Hit "Enter"

Bingo, done.

The little preview screen does not need to have descriptions in the elements. The purpose of the preview is to just show where elements are. By clicking on an element in the preview (or selecting with keys), it moves to the left and shows the settings and what it is.

Leaving the edit screen show the main screen anyway.

For the Devo12, there can be x rows and x columns. Other TX's just have less rows and columns, so you also keep compatibility with other TX's.

This way, you don't need to think about a grid, because there are only a limited number of places where you can place an element. If an element is too big for the space the user want to place it or want to place it on a place, already occupied, a "beep" will indicate it doesn't fit.

I think these proposals are ok.
Laying the positioning of the items to the user's hands is a good idea what makes the code much easier. We should add a function to manually sort overlapping items by z-coordinate (put a specific one to the back).
I do not like much the idea of entering coordinates in some fields. I would prefer a way to place items roughly with the touch screen and move it in fine steps, e.g. with some move buttons. Or with the keys: place it in big steps and switch to finer steps later. There should be no reason why the coordinates shouldn't be shown somewhere; possibly as textselect fields to set them to a specific value.
Another way could be: select an item, select an edge as reference and select another item which is positioned at the reference edge (only changing x-coordinate for vertical reference and y-coord. for horizontal reference).

I have thought about a kind of drop-down-menu to reduce the number on necessary control elements. If we use an 1:1-preview-screen there will be only the header (32pixels high) to place control items - the rest must be used to represent the resulting screen. So a drop-down e.g. for "New" will show a list of insertable elements (where limits can easily be cared for) where the user selects one and places it.
I could imagine a menu structure like this:(*)double/triple toggles: 2/3 toggles placed side by side, all bound to one switch and only one visible at a time (proposal by someone somewhere above)
(+)My proposal is to have two different modes - one for designing the page with placing / deleting elements and changing their type and another for configuring the items. I believe that most people will separate these two steps (ok, in most cases it will be an iterative process with some switches between designing and configuring). We can also implement a "quick switch" with long presses of buttons or items.

I am quite sure I can code such a drop-down menu structure without any real challenge. We could decide if the menu elements should be text buttons or graphical elements.

I like the idea of uncoupling the model config from the main page config. I assume that most users want to have a quite similar main page for similar flight machines - maybe with some additional items for additional features. Personally I will get totally confused if I do not find an expected information at the place where it should be...
With such an approach we could (or let the community) provide templates for the main screen design - it will be interesting to see what people's ideas are.
I would go one step further and let the user decide to use a template in two ways: integrate it as base for a complete new view (so the template is imported and the result is independent from the template) or reference it (so the template can be changed and will have influence on the designs based on this (we should implement a way to save a design as a template and to rework them - in this case the user should be told which of his models use this template so he can decide if he really wants to change it). This could easily be done because we allow to overlap screen items - the template will be the base (in the background) and the additional elements are shown on top.

I have no idea what to do with the 128x64-screen. Essentially I believe that the same mechanisms should work on this screen as well, but I have never looked into the corresponding code. The smaller screen and color resolution will make it probably much harder to show additional menu elements. Maybe this could be solved with different pages - a menu page, a design page (without menu elements) and a config page.