yoelk
commented
9 years ago Hi, I'm so happy I finally have someone to discuss such issues with :) I also had similar thoughts of how to arrange the data on screen. changing screens? 1 or two splitters? I still don't know what would be best. In the meanwhile, I finally figured out how to use the 2 splitters in a reliable way. Someone gave me a hint on my stackoverflow question. you can see the discussion here https://groups.google.com/forum/#!topic/kivy-users/PFBtWjFxmCs.
You wrote a lot, and I kind of lost you there. Do you think you could sketch a small mockup of how you think the GUI should look like? I read in the book that pencil http://pencil.evolus.vn/ should be a handy tool for doing that, so you could use that, or anything else.
Here's another suggestion (let's start marking them): _GUIidea1: The most generic approach would be to let the user decide to how many parts should the screen be divided to, and then what view should be in each of the screens If we choose to split the screen area, I think we have to use splitters or something else like accordions or pagelayouts, but I think the splitters are better.
I'll send you the finished multisplitter code when it works
On Fri, Apr 3, 2015 at 9:51 PM, Snarfums notifications@github.com wrote:
I skimmed over the kivy book, spent some time working with splitters and the issues posted in Issue #8 https://github.com/yoelk/Instrumentino/issues/8 , and skimmed over the kivy "garden" (https://github.com/kivy-garden), etc. to get an idea what kivy currently offers in terms of widgets. I'm wondering if a direct v1 -> v2 UI model will actually be harder (i.e. more code) in kivy than making some design changes to make it more "kivy friendly" (less code).
I'm not sure how you'd feel about this but I am curious if you'll come to the same conclusion. It's just something to think about :)
Basically: Kivy is relatively new and is "mobile/touch friendly" so maybe making changes to the v2 UI layout to make it more "single screen friendly" will result in less work to port it over.
Specifically: After seeing how using using dual splitters works to generate the "three areas on a screen" (both the default splitter behaviours and your splitter code in Issue #8 https://github.com/yoelk/Instrumentino/issues/8 ) in order to make the 3 areas fully resizeable, I'm wondering if the 3 panel screen layout should be simplified to remove the splitters altogether (or maybe just have a dual panel screen with 1 splitter, or use 2 layouts, etc.) as they seem more suited to just split something into 2 areas and not 3. This may ultimately make building and extending the UI "easier".
Given all the above: I'm wondering how much of the current information is actually necessary to have "on screen" at all times. The only thoughts I have at the current moment are:
At minimum make each v1 panel (The Components, The Methods/Sequences, The Commands/Signals) its own independent "full screen" view, then have a common way of switching between views. The benefits of this:
- Make it easier to see all the data in a view (especially for the chart).
- Make each panel able to contain more data than having to scroll/resize.
- Make the user interaction easier (items can be larger and easier to manipulate/select)
- It may make it easier to add more views later since everything (design and code) would be based on swapping between single views. "Multi view" could then be added as another "single view" option for personalized combinations of the standard single views for those who want them or have really large screens.
- Widget sizes, layout, and behaviour could likely be left "the defaults" and not have to be hand coded. The only time you would have to deal with setting widget size and layout would be when trying to fit >1 view on a screen (like with splitter or just 2 side by side layouts ) as the single view would not initially be special-coded for this. However, odds are most views will comfortably fit in 1/2 a screen (they do today, even the chart) with the default kivy layout/packing so putting 2 views in a screen would probably require little or no additional hand configuring. The kivy widget layout file(s) may be greatly simplified as special widget positioning/handling could be less of a concern, and it may "read better" as each view could be it's own independent high level "section" from the others.
If this were done, I could see this occurring:
- The "primary" view screen (the one normally active/loaded first) would be things a user would likely use to actively monitor and manually control. Things like the items in the Components view like the "Stop" button or the ability to manually set things to a value. Today this would literally be the Components panel.
- A permanent menu (just like it is in v1, on top)
- All other views would be selectable from each other.
The problem with this (I believe) is that there is some information on other views you want to see in the primary view or at all times. So maybe make that other view on top/bottom/side (via Splitter?). It would contain important summary data in other views like the "Method/Sequence" panel and the "Command/Signal" panel. Imagine something that just indicates what method + sequence is currently running, maybe what's going to run next, remaining run time, last 5 commands/responses from Arduino, etc. I still think everything ultimately would benefit from being "independent" single screen views, so this "summary" would be it's own single view (not part of the primary) and the combination of it and the primary would be defined and not 'special' from a layout/access/programming sense. Essentially the combination of these two single views would be "the built in example" of how to make a single view contain multiple views.
Also: I personally like the ideas of having "master controls" like the Stop button available at all times, so maybe that would go in the top menu as well so you wouldn't have to switch to the "primary" view to get to it if you happened to be messing around in another view.
Also: Making the views available/selectable could be done in the "cleanest" or "easiest" way possible as kivy permits so they could be implemented as tabs, menu items, models, etc.. Whatever is the easiest to code against. The same goes for building multi-views.
Well, I wrote a lot so I'll leave it at this for now and see if there's any interest in pursuing the v2 UI in this manner.
— Reply to this email directly or view it on GitHub https://github.com/yoelk/Instrumentino/issues/10.
ghost
I skimmed over the kivy book, spent some time working with splitters and the issues posted in Issue #8 , and skimmed over the kivy "garden" (https://github.com/kivy-garden), etc. to get an idea what kivy currently offers in terms of widgets. I'm wondering if a direct v1 -> v2 UI model will actually be harder (i.e. more code) in kivy than making some design changes to make it more "kivy friendly" (less code).
I'm not sure how you'd feel about this but I am curious if you'll come to the same conclusion. It's just something to think about :)
Basically: Kivy is relatively new and is "mobile/touch friendly" so maybe making changes to the v2 UI layout to make it more "single screen friendly" will result in less work to port it over.
Specifically: After seeing how using using dual splitters works to generate the "three areas on a screen" (both the default splitter behaviours and your splitter code in Issue #8 ) in order to make the 3 areas fully resizeable, I'm wondering if the 3 panel screen layout should be simplified to remove the splitters altogether (or maybe just have a dual panel screen with 1 splitter, or use 2 layouts, etc.) as they seem more suited to just split something into 2 areas and not 3. This may ultimately make building and extending the UI "easier".
Given all the above: I'm wondering how much of the current information is actually necessary to have "on screen" at all times. The only thoughts I have at the current moment are:
At minimum make each v1 panel (The Components, The Methods/Sequences, The Commands/Signals) its own independent "full screen" view, then have a common way of switching between views. The benefits of this:
If this were done, I could see this occurring:
The problem with this (I believe) is that there is some information on other views you want to see in the primary view or at all times. So maybe make that other view on top/bottom/side (via Splitter?). It would contain important summary data in other views like the "Method/Sequence" panel and the "Command/Signal" panel. Imagine something that just indicates what method + sequence is currently running, maybe what's going to run next, remaining run time, last 5 commands/responses from Arduino, etc. I still think everything ultimately would benefit from being "independent" single screen views, so this "summary" would be it's own single view (not part of the primary) and the combination of it and the primary would be defined and not 'special' from a layout/access/programming sense. Essentially the combination of these two single views would be "the built in example" of how to make a single view contain multiple views.
Also: I personally like the ideas of having "master controls" like the Stop button available at all times, so maybe that would go in the top menu as well so you wouldn't have to switch to the "primary" view to get to it if you happened to be messing around in another view.
Also: Making the views available/selectable could be done in the "cleanest" or "easiest" way possible as kivy permits so they could be implemented as tabs, menu items, models, etc.. Whatever is the easiest to code against. The same goes for building multi-views.
Well, I wrote a lot so I'll leave it at this for now and see if there's any interest in pursuing the v2 UI in this manner.