Ticket #66 (closed task: fixed)

Opened 11 years ago

Last modified 10 years ago

xuvtools: re-design "Advanced parameter" dialog

Reported by: ne704 [niko@… Owned by: emmenlau
Priority: minor Milestone:
Component: xuvtools Version:
Keywords: xuvtools, xuvtools_gui Cc: developers@…


the "Load" button in the "Advanced" parameters dialog doesn't have any associated function

Change History

Changed 11 years ago by aaron@…

  • status changed from new to closed
  • resolution set to invalid

Of course it has: it loads the saved settings. It is useful if you clicked on defaults or you changed some of the parameters and want to go revert to the saved ones.

Changed 11 years ago by ne704 [niko@…

  • status changed from closed to reopened
  • resolution invalid deleted

This is totally non-intuitive behaviour (no other application of my knowledge acts that way). One could simply click "Close" and the changed parameters would be discarded.

I think if the button has to stay there (it doesn't add functionality), it sould be

a) renamed to something like "Revert to last" b) get a mouseover-explanation

Changed 11 years ago by ne704 [niko@…

  • owner changed from emmenlau to ne704
  • status changed from reopened to new

That's my suggestion for giving the button a name that fits better to its function. I compiled it to see if its size is ok (it is...).

--- /tmp/tmp.EBcJcbRqCE	2009-07-01 00:35:39.000000000 +0200
+++ src/gui/dialogs/advancedparametersdialog.cpp	2009-07-01 00:27:31.666926720 +0200
@@ -593,7 +593,7 @@
     // === Add a load button ============================================
     // ===================================================================
-    loadButton = new QPushButton( tr( "Load" ) );
+    loadButton = new QPushButton( tr( "Revert to saved" ) );
     QObject::connect( loadButton, SIGNAL( clicked( ) ),
         this, SLOT( loadParameters( ) ) );

So from my point of view, we can close this bug again - the only question is, should I commit or do you guys want to stick to the current version?

Sorry if my tone was a bit rude, it wasn't meant to be. I only try to report the pitfalls that appear to a user who is not familiar with the code itself and its steps of evolution (mainly myself in these cases...).



Changed 11 years ago by ne704 [niko@…

After talking to Mario, we decided to commit my suggested change from above (see r2752).

The remaining question is, are there any changes applied temporarily if a user clicks on "Close" (so they are valid for the current session, but not saved in the preferences-file), or are the changes discarded when they are not saved (as I thought in the first place)? Aaron?

Changed 11 years ago by aaron@…

If you modify the parameters, the changes are applied immediately and are thus valid for current session. Notice that the advanced parameter dialog is not modal, which means you can keep it open while you run the stitcher (and actually this is NOT good -- I don't remember why I did it this way). The close button is the same as closing the dialog clicking on the 'x' button on the window title bar. But only leaving this option to close the dialog would be UGLY.

I suggest the following: (1) to make the advanced dialog modal, and (2) to change the text on the test on the 'Default' button to 'Revert to default', in the same way as 'Load' should be changed to 'Revert to saved'.

Changed 11 years ago by aaron@…

Ah, right. When you run some thread, the Advanced Parameters dialog is disabled, so you cannot change anything. So, forget about point (1) before.

Changed 11 years ago by emmenlau

I agree with Niko that the logic of the four buttons is currently not straightforward. It might aid in the confusion that some settings are only used after a restart, so one needs to save the settings and restart the stitcher, or they are lost.

Should we invest some time to think about a safe (and sane) way of applying the settings? In any case this should include a way to warn the user when changes require a restart, and a way to warn the user when changes might be lost. What do you think?

Is there a major software tool that solves the problem in an intuitive way, that we could take as reference?

Changed 11 years ago by aaron@…

The only setting that needs a restart is 'enabling bleaching correction', because this is a temporary workaround and added it lazily, but I could enable it on the fly and then it would behave like everything else. All the rest is applied automatically when you change something. So: if you want to reuse the setting next time you open the stitcher you click on save, if you want to go back to the default values you click on default. If you want to close the dialog you click on save. The only confusing behavior of the dialog is the fact that when you click save it saves also the values from the workflow editor. But actually it was a user who requested it...

Changed 11 years ago by aaron@…

Sorry for the curious misspelling: "If you want to close the dialog you click on CLOSE."

Changed 11 years ago by emmenlau

From the top of my head I would also say that the logfile is also only useful after a restart. This is because (1) all messages from before setting the logfile are lost, and (2) because I would guess that changing the place where the logfile goes to (not disabling, but changing the path) is not possible with output redirection without restart. Disabling a logfile is not possible either, without a restart (we do not close the output file handle, do we?).

Note I have just recalled this from the top of my head. I need to test it on all operating systems. Also I did not check if there are other options that are mainly useful after a restart.

Changed 11 years ago by ne704 [niko@…

Ok, patch for (2) is ready. If the restart-issue still applies, I think we should handle this in a separate bugreport (otherwise it could be hard to keep track of that at a later point, when you have to look for the stuff in a bugreport that started about something different...)

So *if* there are parameters that need a restart, I agree with Mario that this should be stated clearly since it will lead to lots of confused users ;)

Now what I get from Aarons last postings, there is only one such option, which could be identified by some additional text right next to the option itself (at least for the moment - this clearly does not solve the issue regarding future options with similar behaviour, where a general way of handling this would be clearly the preferred one...)

Changed 11 years ago by ne704 [niko@…

committed patch for (2) in r2753

Changed 11 years ago by ne704 [niko@…

Actually I just noticed an inconsistent behaviour of the Close-button. When I enable bleaching correction, then click on "Close", restart the xuvgui, bleaching correction should be still disabled according to Aarons description (since I didn't "Save" the settings) - but it obviously gets saved anyway since it is enabled then...


Changed 11 years ago by aaron@…

Because this is saved into the _gui_ settings -- I told you it is only a temporary solution until we decide that the bleaching correction is usable, and then the whole entry would disappear from the dialog.

Changed 11 years ago by aaron@…

Redirection is applied automatically. You you enable logging it starts logging immediately, if you disable logging is stops logging immediately.

There is only problem (I figured it out when I was trying to figure out the best way to have different log files associated to each project) is that if you disable logging and then re-enable (meaning you redirect to files you already opened by redirection), the stuff you send to the log files gets lost. You cannot redirect twice to the same file.

Changed 11 years ago by ne704 [niko@…

  • keywords xuvtools, xuvtools_gui added; xuvtools removed
  • priority changed from trivial to minor
  • summary changed from xuvtools: more redundant gui-buttons to xuvtools: re-design "Advanced parameter" dialog

As discussed with Mario, I renamed this but into 're-design "Advanced parameter" dialog' which consists of several parts:

(1) address the "search window" vs. "fixed window" issue, to e.g. let the user set the size of the fixed window by absolute values (slider?) and the size of the search window by specifing it in relation to the fixed size (something like "xx pixels smaller than the fixed window")

(2) use a text-field for specifying the logfile (and e.g. a "browse" button next to it to open the file-selection dialog that is currently showing up when the user switches on the "enable logging" checkbox) - this is related to redesigning the logging facility (#74)

(3) re-think about the buttons to behave more like other GUIs (should we have a look at some user interface guidelines?)

(4) what else?

Changed 10 years ago by emmenlau

  • owner changed from ne704 to emmenlau

Changed 10 years ago by emmenlau

  • status changed from new to closed
  • resolution set to fixed

A completely rewritten "Advanced Parameters" dialog has been implemented in revision r3235. Therefore I'm closing this bug now as outdated.

However, it is possible that not all suggestions of this (rather long) bugreport have been implemented. In case of further improvement suggestions, please create a new bug report :-).

Note: See TracTickets for help on using tickets.