Input Generator - Side Preview

Comments

• Thomas@discuss.avogadro.cc ⁨19⁩ ⁨hours⁩ ago

  A static screen picture does not provide as much user experience as the «the real thing» because screen estate (still) varies by outer dimension (14", 15", etc) and pixel density. This is the reason why I propose that this thread adds a link to GitHub; similar to the continuous builds now to a set of artifacts/builds of an Avogadro2 prototype with such an adjustable lateral pane. This would provide an opportunity to collect a feel of the two approaches in comparison and by e.g., November 15th the interested may cast their vote.

  original

  • ghutchis@discuss.avogadro.cc ⁨18⁩ ⁨hours⁩ ago

    Sure, that’s a good idea. I’ll see if I can get a show / hide button hooked in and submit a pull request.

    original
• brockdyer03@discuss.avogadro.cc ⁨22⁩ ⁨hours⁩ ago

  Part of the problem I have experienced with the input generator dialog is that there’s essentially zero options for resizing. If there are a lot of input options, the part where you actually set options is as tall as the tallest page, which leads to problems. If it could be made scrollable, that would make resizing easier and could really cut down the default size of the dialog. Additionally, the preview should always be scrollable and should never set the size of the dialog box.

  If everything becomes scrollable and resizeable, there shouldn’t be any problems with dialog size.

  original

  • ghutchis@discuss.avogadro.cc ⁨21⁩ ⁨hours⁩ ago

    Resizable sounds good. Same thing with hide / show of the preview. I don’t like the idea of a scrollable form though.

    From my perspective if there’s so many options on the form that it needs to scroll - then we need to think more carefully about the organization of the options (e.g., can we hide / show some of them, move into more tabs, etc.)

    For example, adding some limited syntax:

    "enabledWhen": { "key": "repeat", "equals": true }
    "visibleWhen": { "key": "Calculation Type", "in": ["TD-DFT", "EOM-CCSD"] }
    

    So in the ORCA example above, should we move “Solvent” to a new tab? Or maybe “Print Level” and “Print Molecular Orbitals” belong on a tab.

    And the solvent model is disabled until the user selects a solvent.

    original

    • brockdyer03@discuss.avogadro.cc ⁨18⁩ ⁨hours⁩ ago

      From my perspective if there’s so many options on the form that it needs to scroll - then we need to think more carefully about the organization of the options (e.g., can we hide / show some of them, move into more tabs, etc.)

      When I was designing the ORCA input generator, I was extra careful to only make the most common options available on the Basic tab. The other tabs I wanted to include as much as possible (ideally support everything ORCA has to offer, however unrealistic that goal may be), but the idea was to put the most common options at the top of the tab and then start to group things by common concept.

      For example, adding some limited syntax:

      "enabledWhen": { "key": "repeat", "equals": true }
      "visibleWhen": { "key": "Calculation Type", "in": ["TD-DFT", "EOM-CCSD"] }
      

      This syntax would be very useful and would very much help to clean up the tabs. I also would find a lot of utility out of a toggle somewhere that is along the lines of Show/Hide Advanced Options [x], which can help to filter down things that aren’t necessarily going to fall into “show when <cond>”.

      I still think that no matter what there will come a point where being able to scroll is useful, not in the least because Qt seems to want a fixed window size for all tabs and doesn’t seem to dynamically adapt to the current tab if the tab isn’t scrollable.

      So in the ORCA example above, should we move “Solvent” to a new tab? Or maybe “Print Level” and “Print Molecular Orbitals” belong on a tab.

      And the solvent model is disabled until the user selects a solvent.

      From what I recall, I had already filtered down the solvent list by quite a lot when I put it in the Basic tab. There’s a whole host of other solvents that are available in ORCA that didn’t make the cut, but should go into another tab.

      Regarding “Print Level” and “Print Molecular Orbitals”, I think those belong on the main tab since those are part of the simple input keywords for ORCA and are highly relevant for users of Avogadro (e.g. not printing orbitals means you can’t render them in Avo2).

      In general I think we agree that there should be a smart/minimal selection of options in the basic tab, but I also think that due to limitations of Qt and the desire to be able to support 1) resizing and 2) more comprehensive support of input options, we need to at least allow for scrolling.

      original
    • ghutchis@discuss.avogadro.cc ⁨21⁩ ⁨hours⁩ ago

      Maybe I should rephrase this.

      The challenge is that many comp. chem programs have a gazillion options. Most people use maybe 10-20% of them.

      So the point is to provide some limited options up-front in a “basic view” that works even for new students - and let others find more options as-needed.

      IMHO, WebMO does a nice job of this. The default tab for selecting options focuses on the basics, with tabs for other options.

      So my concern with “oh, it’s scrollable” is that we’re showing so many options a user is overwhelmed with all the options on one page. It indicates we should be hiding and showing things dynamically, or creating more tabs to help organize the options.

      original