GUI
I've checked in a lot of changes in the pages.
However I've changed the skin too (because it is much easier to align boxes, if they are square
).I don't know if you like it, and if not, then how to get the changes without the new skin, but I guess, you can manage it.
Please Log in or Create an account to join the conversation.
I will post a few variants. Now I have an unfinished one:
It has a header, where the shortcuts are, plus the battery and power info.
The content of the white boxes would be configurable, in this case: throttle, pitch, timer, telemetry voltage...
...and another one:
Please Log in or Create an account to join the conversation.
Bitmaps are easier to receipt. But! It can only give a visual warning about the battery level, however different type of batteries can be used: 1s, 2s or 3s LiPo, 4s NiMh, 4s alkaline, etc. They all have different voltage levels for the bars of the indicator, so the voltage reading is useful. The best solution would be if we could automatically detect the battery type, and set the levels accordingly (or at least to allow to set the battery type).PhracturedBlue wrote: Those are both reasonably straight forward but:
* Isnt' the battery bar redundant with the voltage?
OK, don't worry, it's just a mockup! It was quicker to use them, than draw one...PhracturedBlue wrote: * We can't actually use Walkera's images in our library. I need freely available images.
No problem.PhracturedBlue wrote: * One of the limitations of the GUI is that you can't draw transparent objects on top of another object (originally we supported this, but it is very slow, so I disabled it). so you can't have transparent bmps or text on top of another bmp. To achieve the header bar we could:
a) embed it into the background. In that case, all screens would have it.
b) use a 2nd background. That is a lot of ROM to spend in my opinion
c) enhance the GUI further to support this. I have a couple of ideas on what we might do, but it is certainly easier if I don't need to.
IMO the header would be useful on all the other pages too: it could contain the OK/Cancel (or Load/Save/Cancel) buttons, and would separate the page title.
Only difficulty is with those pages, that should be scrollable, because on that the header should remain on top, and only the contents below should scroll...
The font usage is not intentional. I've just used what was selected. No significance...PhracturedBlue wrote: * I don't have fonts that look like that. It'd would be really helpful if you could work on the fonts. It isn't all that difficult to do, but does take some time.
The question was: how do you like the concept?
There could be some more such templates to choose from, and some elements of the templates would be configurable...
EDIT: For example you could change between these main screen layouts with the left/right buttons, but the default layout for the model should be configured in the model data...
Please Log in or Create an account to join the conversation.
Yes, paging is fine too.PhracturedBlue wrote: scrolling is one option, but an easier one (and the one I planned for) is to have multiple 'pages' for each menu. There would be a up/down arrow on each page that would bring up the next page. We probably need a '1-of-n' type text as well. My only concern is that paging will be slow with the buttons. maybe a long-pess up/down could switch to the next page.
Another possibility is to use a listbox-like widget that you can draw inside of, but that only allows the equivalent of pageup/pagedown within it (this is similar to the above but could be for only a specific area on the screen)
The 3rd possibiliy is to use a list-widget where all items are built in rows so that I can advance one row at a time.
The 2nd and 3rd options are both possible, but require some additional work. the 1st option can be done with existing widgets.
You don't even need paging buttons: if you are on the last button and press down or right to step to the next, the program can change to the next page. Of course paging buttons are useful for the pencil, but in this case they should NOT (edit) be in the tab sequence...
If you think about, this automatic paging can be implemented as scrolling, if the pages are overlapping each other except one-two rows of buttons. Every page would have an up and down button on the right side, and you draw some decorational scroll position box between them, and it is done!
I think yes, it is good indeed. I have only some minor complaints about it, most of them are about the menu structure inherited from the 2801. They splitted the functions into model, function and system menu, but they are sometimes in the wrong place, and the separation makes it too complicated to navigate between them.PhracturedBlue wrote: I think they look fine, though perhaps the main screen is too similar to the Devo. but maybe that is just because they got it right.
Furthermore, don't forget, that all our users will come to the deviation fw from the walkera one. It doesn't hurt, if it is something familiar. Makes the learning curve easier...
If you like the long enter for the menu, than it is good enough...PhracturedBlue wrote: I'm also not sure about the shortcut bottons at the top. I think they'd be too small to easily use via touch, and we won't allow button selection with the physical buttons on the main screen (I like your idea of using a long-enter press to enter the menu from the main screen). I owuldn't want to make them much bigfger as they'll strat interfering with the Model name. We would still need a way to get to the menu via the touch-screen, but perhaps a better option would be a single button which could be larger, or even any press on the top-bar.
I have placed three buttons on the header, but we might not need all of them. Even in the original fw you can click on the model name to select a model, and on the picture itself to edit the model (plus on the power indicator to edit the power amplifier, etc), so we will have enough large areas to click on, and the rest of the header could be all entering the menu...
PhracturedBlue wrote: I'm still not convinced about the battery indicator. Don't most folks get 10hrs or so out of a transmitter charge? In which case how often do you care about the transmitter voltage that you need to be able to read it at a glance? I think either text or bitmap, but not both will be sufficient, but it isn't exactly the most important topic.
OK, it's not that important for me either!
If I have to choose, I think the text is more important.
Please Log in or Create an account to join the conversation.
