[webif] Version 1.0.8 Released

The overlay window when you do something in package management closes itself before you can read anything.

It has to be a bug because a similar mechanism is fine in the Foxsat HDR custom firmware. (Same browser, Chrome, the most commonly used browser.)

(Not fixed in 1.0.9.)
It's not a bug, it's a deliberate feature, as documented in the initial post from af123, Dialogue boxes dismiss themselves when no errors are encountered.
 
It has to be a bug because a similar mechanism is fine in the Foxsat HDR custom firmware. (Same browser, Chrome, the most commonly used browser.)
That isn't a valid assumption.. the two web interfaces share common ancestry but diverged a long time ago.
 
It's not a bug, it's a deliberate feature, as documented in the initial post from af123, Dialogue boxes dismiss themselves when no errors are encountered.


Just seen that now. Thanks.

Consistency would be a good thing, though.
 
Consistency would be a good thing, though.
We are not talking about Humax maintaining consistency over it's range of products, (which it doesn't by the way), we are talking about af123 writing the CFW for the HDR-fox T2 and Raydon writing the CFW for the Foxsat. We've seen the result of code written by committee in the shape of YouView and what a dog's breakfast that turned out to be
 
Maybe they should hang around long enough to see there are no errors.


I totally agree. If there are errors in the dialogue code, rather than the dialogue contents, then you don't get to see what is going on. These dialogues often disappear immediately, and you have to trust that nothing went wrong. (eg, your browser, or anti-virus, closing them or some bug in their code.)

We are not talking about Humax maintaining consistency over it's range of products, (which it doesn't by the way), we are talking about af123 writing the CFW for the HDR-fox T2 and Raydon writing the CFW for the Foxsat. We've seen the result of code written by committee in the shape of YouView and what a dog's breakfast that turned out to be


An option in Settings, then?

Persistent dialogues Yes/No

It's bad enough us old fogies having to cope with the Foxsat HDR having its documentation embedded in its web interface, and the HDR Fox T2 not having that, without having to cope with minor GUI variations in what at first sight look like similar interfaces. :confused:
 
But why do you want to check the disappearing dialogue for error? I thought AF123 said that they only disappear if there are NO ERRORS!
 
It's bad enough us old fogies having to cope with the Foxsat HDR having its documentation embedded in its web interface, and the HDR Fox T2 not having that, without having to cope with minor GUI variations in what at first sight look like similar interfaces. :confused:
Well I could always remove the documentation from the Foxsat web interface I suppose.:rolleyes:
 
Well I could always remove the documentation from the Foxsat web interface I suppose.:rolleyes:


Your icons flow better than in the T2 web interface, which has a large bald patch on the right! :eek:
 
But why do you want to check the disappearing dialogue for error? I thought AF123 said that they only disappear if there are NO ERRORS!
Because the dialogue box appears at all. If it could be prevented from appearing if there are no errors, that would be different.
 
But at least you know it is doing something, if it just displayed nothing until it had finished people might start pushing buttons thinking it had stalled ...
 
I know what you are saying, but the human element of the man-machine interface requires certain phychological factors to be accommodated to make it a smooth experience. For example, a progress bar which shows a gradual progression to 100% and then disappears is fine, but if the progress is so fast that the progress bar flashes onto the screen and off again it is unnerving for the user. There needs to be time for the user to register what it says, otherwise the typical reaction will be "what the heck was that?".
 
Auto-dismissing dialog boxes if there is no error after a fixed amount of time would seem to be a sensible thing to do.
Now all we have to argue about is the timeout. I would suggest 5 seconds.
 
Back
Top