OverlayHD Skin...

[adoxa]

The selection column is always present even if nothing is drawn!

Unlike FC marking is always available (there's no separate selection mode), so the mark is always drawn; the default mark_off.png is blank. I did have a radio-button style (like my previous PVR), but didn't like that, either.

[IanSav]

Hi Adoxa,

Unlike FC marking is always available (there's no separate selection mode), so the mark is always drawn; the default mark_off.png is blank. I did have a radio-button style (like my previous PVR), but didn't like that, either.

What is wrong with the FileCommander UI? Why didn't you use the same UI paradigm and images from FileCommander? Beyonwiz users are used to that look and functionality. It would have made for a more consistent and predictable UI. Arguably you could / should have changed FileCommander to be like MovieSelection if the FileCommander UI is unacceptable. I prefer the FileCommander UI, particularly now that it has had significant improvements.

I am a strong advocate of UI consistency and predictability. The changes to MovieSelection are, in my opinion, a significant inconsistency. There is too much going on and navigation options are compromised.

We each have our own ideas. I try to implement my vision but allow options for others to adapt or adopt the changes to accommodate their preferences. In this case the code is forcing a UI change that I can't fix or work around.

Regards,
Ian.

[adoxa]

What is wrong with the FileCommander UI?

Nothing per se, but neither Peter wanted a modal interface:

[...] It would be great to remove the modality. [...]

[IanSav]

Hi Adoxa,

What is wrong with the FileCommander UI?

Nothing per se, but neither Peter wanted a modal interface:

[...] It would be great to remove the modality. [...]

I feel that the selection mode has its benefits. It allows for the limited number of buttons available on the remote control to be rationally assigned.

Even with the mode less design the screen could be adapted on the fly to support the selection actions.

• As soon as the first file selection is made then add/insert the selection column just like in FileManager.
• If the large progress indicator is in use them switch to the small progress indicator
• Move the icons right the width of the selection column tick box (with a small spacer)
• Reduce the width of the file names by the width used by the selection column
• Even if icon display is off the folder icons are still displayed?!?! Either insert the selection column in front of the folder icons and the blank space to the left of the file names or else remove the folder icons when icon display is off. Then simply insert the selection column in front of the file name text
• For UI visual alignment use the empty and ticked boxes as per FileCommander
• When the selections are done, restore the display as it was before selections were started

Regards,
Ian.

[adoxa]

• As soon as the first file selection is made then add/insert the selection column just like in FileManager.
• Move the icons right the width of the selection column tick box (with a small spacer)
• Reduce the width of the file names by the width used by the selection column

That's how I originally did it. I didn't like it moving when the selection was made and as mentioned previously I didn't like it appearing indented when there was no apparent off mark, and even less when there was an ever-present off radio button. I'm quite happy with how it is now. Indeed, I have to stop myself pressing NEXT or PREV when I want to mark in FC.

[Grumpy_Geoff]

...I'm quite happy with how it is now.

So am I, FWIW

Indeed, I have to stop myself pressing NEXT or PREV when I want to mark in FC.

Yep, that part of the FC interface is poxy.

[IanSav]

Hi Adoxa,

That's how I originally did it. I didn't like it moving when the selection was made and as mentioned previously I didn't like it appearing indented when there was no apparent off mark, and even less when there was an ever-present off radio button. I'm quite happy with how it is now. Indeed, I have to stop myself pressing NEXT or PREV when I want to mark in FC.

I am happy that you like the UI. Now how do I get to skin it the way I want it to look? The always present selection column with no content is a UI problem I want fixed or to fix.

Regards,
Ian.

[IanSav]

Hi Grumpy_Geoff,

...I'm quite happy with how it is now.

So am I, FWIW

What skin are you both actively using?

Indeed, I have to stop myself pressing NEXT or PREV when I want to mark in FC.

Yep, that part of the FC interface is poxy.

If my UI consistency changes get accepted then this may well be changing.

Regards,
Ian.

[adoxa]

I use Full-Metal-Wizard.

Now how do I get to skin it the way I want it to look? The always present selection column with no content is a UI problem I want fixed or to fix.

How do you want it to look? With it shifted when there's marks? i.e. when there's no marks the list is drawn at 50 and there's no mark off icon at all; when there's marks the mark on icon is drawn at 50 and the list moves across (reducing the name). Hm, I guess that could be done if there's no listPos attribute and no mark_off.png. Or maybe check for mark.png, rather than mark_{on,off}.png. And it does have content, either mark_off.png or mark_on.png. I prefer to see nothing if there's no marks, so mark_off.png is empty for the built-in skins.

[IanSav]

Hi Adoxa,

Full-Metal-Wizard and easy-skin-aus-hd are effectively the same skin. OverlayHD is different and has been crafted to be visually significantly more consistent. I try to position all elements within OverlayHD with exacting accuracy to the pixel level. In any case ALL code should be developed to support and allow adjustments by *any* skin. Remember that at some point in time even the default skins may want to change.

For OverlayHD I always want every line to start displaying something at column 50. The selected/unselected icons from FileCommander are only 25 pixels wide. For visual consistency those are the icons I will be using.

Regards,
Ian.

[adoxa]

For OverlayHD I always want every line to start displaying something at column 50. The selected/unselected icons from FileCommander are only 25 pixels wide. For visual consistency those are the icons I will be using.

I did start with those, but they looked awful in that context. My mark icons are only 16 pixels wide. If you want those FC icons use those icons. If you want the on icon but not the off I'll adjust the code. If you want something else you'll have to tell me.

[IanSav]

Hi Adoxa,

I did start with those, but they looked awful in that context. My mark icons are only 16 pixels wide. If you want those FC icons use those icons. If you want the on icon but not the off I'll adjust the code. If you want something else you'll have to tell me.

I will experiment. My point is that the code shouldn't need to change to support most skinning requirements. Using different icons should not require a code change.

Look at how Prl has been changing FileCommander. All of the changes still allow significant control of what is displayed and where it is displayed within the skin alone. The code was written with skinning flexibility in mind.

Regards,
Ian.

[adoxa]

Using different icons should not require a code change.

Huh? It doesn't. It uses whatever the skin has as icons/mark_{on,off}.png. It will require a code change if you only want an on icon without any off icon at all (rather than just a blank one).

[IanSav]

Hi Adoxa,

Using different icons should not require a code change.

Huh? It doesn't. It uses whatever the skin has as icons/mark_{on,off}.png. It will require a code change if you only want an on icon without any off icon at all (rather than just a blank one).

I used the icons from FileCommander and the icons have the right edge clipped. The lines are still being displayed indented by about 50 pixels from the nominated starting point.

I am looking at the code changes in MovieList.py and the default the mark icon width is set to 16 pixels. The mark images are then loaded and the the height checked against the item height to clip the height of the image. The hard coded mark icon width is never reset the width of the actual icon! It looks like the width override MUST be used to make this work.

Why is the existing list data offset by 50 pixels? The original data default offset should be related to the width of the mark icon. This setting requires a specific override but is a setting that shouldn't need to even exist.

Was this code tested for use in contexts other than the preferred implementation in Full-Metal-Wizard? I am surprised that this code was accepted and merged.

Regards,
Ian.

[IanSav]

Hi Adoxa,

You were right about the FileCommander icons not looking very good in this context.

I have created my own icons that conform to the MovieSelection 20 by 20 pixel format. They are still a gray box with and without a green tick but the box edge is now the edge of the image (no blank space around the box) and the green tick now has a black border and the tick is fully contained within the box. These look a lot better. I may even use these in a future FileCommander change. I am attaching the new icons to this message.

These new icons highlight another issue with the code. I can't position the mark icons to the very left of the screen object. It appears to be centred in the list offset width. This is not how all the other objects on the line are placed. The other icons and names are left aligned and the spacing between one item and the next is specifically provided. The current code can not be used to create a clean left aligned list in OverlayHD.

Regards,
Ian.

[adoxa]

I am looking at the code changes in MovieList.py and the default the mark icon width is set to 16 pixels. The mark images are then loaded and the the height checked against the item height to clip the height of the image. The hard coded mark icon width is never reset the width of the actual icon! It looks like the width override MUST be used to make this work.

I just copied what iconsWidth did.

Why is the existing list data offset by 50 pixels? The original data default offset should be related to the width of the mark icon. This setting requires a specific override but is a setting that shouldn't need to even exist.

I wanted the icon drawn before 50, but the list to remain at 50. The way I solved this was to have the list at 0 and add listPos to seemingly move it back to 50. The icon is then drawn its width (markWidth) and space before it.

You were right about the FileCommander icons not looking very good in this context.

There's a first.

The current code can not be used to create a clean left aligned list in OverlayHD.

I'm not sure what you mean. Here's how I do it (well, I would have, if I patched it right):

myway.png (15.95 KiB) Viewed 4989 times

Code: Select all

	<screen name="MovieSelectionListBeyonwiz">
		<widget name="list" position="0,80" size="810,525" backgroundColor="MenuBackground" backgroundColorSelected="MenuSelected" enableWrapAround="1" foregroundColor="MenuText" foregroundColorSelected="MenuTextSelected" scrollbarMode="showOnDemand" transparent="0"
			font="MovieSelectionFont;20" pbarHeight="10" pbarLargeWidth="45" spaceIconeText="5" iconsWidth="25" spaceRight="5" dateWidthScale="9.0" lenWidthScale="4.0" sizeWidthScale="5.0" listPos="50" />

and here's what I think you're after:

yourway.png (16.59 KiB) Viewed 4989 times

Code: Select all

	<screen name="MovieSelectionListBeyonwiz">
		<widget name="list" position="50,80" size="760,525" backgroundColor="MenuBackground" backgroundColorSelected="MenuSelected" enableWrapAround="1" foregroundColor="MenuText" foregroundColorSelected="MenuTextSelected" scrollbarMode="showOnDemand" transparent="0"
			font="MovieSelectionFont;20" pbarHeight="10" pbarLargeWidth="45" spaceIconeText="5" iconsWidth="25" spaceRight="5" dateWidthScale="9.0" lenWidthScale="4.0" sizeWidthScale="5.0" markWidth="20" listPos="25" />

After doing that I'll admit it could be better.

[adoxa]

If what you're really after is no icons when there's no selection and shifting everything across to make room for them when there is a selection I think I could use listPos to do that.

Code: Select all

if listPos == 0:
    if no_selections:
        draw_items(0)
    else:
        draw_mark(0)
        draw_items(markWidth + space)
else:
    draw_mark(listPos - markWidth - space)
    draw_items(listPos)

[Paul_oz53]

Hi Paul,

I'm happy to run OverlayHD 1.66 on the U4 with the 20180729 beta firmware.

Do the new CLE elements exist in that beta and will they conflict?

I have rethought this. I have linked to the new 1.66 here for anyone to try.

There will be an update to 1.67 as soon as Prl's latest FileCommander changes get added to the code in the next beta.

The CutList Editor changes are not there as I am trying to work out what was intended.

Regards,
Ian.

I've installed 1.66 on the U4. There appears to be a couple of bugs to iron out.

A minor gripe is the install step states the Execution progress step but not Execution finished. After waiting a few minutes I exited and restarted the GUI. As it was not clear it had installed, I reinstalled. On the subsequent attempt, the message came up that it is already installed.

Checking the FC screen, I see Help has been added and the "True" icon image is a blue dot. Also, the screen for Menu->YouTube has been redesigned but otherwise appears complete and functional. These were the obvious changes. Anything else is quite subtle.

In Network->DLNA setup, the following screen is not usable to amend setting: miniDLNA setup (Blank screen but not an issue with 1.60 on the T3).

The green tick sits on top of a visible red cross with the TiVo settings, etc. on the previous screen: miniDLNA.

Mountpoints management -> Mountpoint viewer screen: No borders around green ticks? (General observation: Newer screens use the selection box border around green ticks but older screens do not [See Autotimer options]. This is not consistent through the whole interface.)

Cheers,

[adoxa]

I've installed 1.66 on the U4. [...]

A minor gripe is the install step states the Execution progress step but not Execution finished. After waiting a few minutes I exited and restarted the GUI. [...]

1.66 on a T2 with 20180729 (no patches) installed in about 30 seconds.

[Paul_oz53]

I've installed 1.66 on the U4. [...]

A minor gripe is the install step states the Execution progress step but not Execution finished. After waiting a few minutes I exited and restarted the GUI. [...]

1.66 on a T2 with 20180729 (no patches) installed in about 30 seconds.

The only patch I have installed is the loading progress indicator for the U4. Wouldn't expect that to be an issue.

[adoxa]

The only patch I have installed is the loading progress indicator for the U4. Wouldn't expect that to be an issue.

Shouldn't be. If it's convenient, could you remove it, enable debugging, and install again? Of course, you can bet it'll work...

[Paul_oz53]

The only patch I have installed is the loading progress indicator for the U4. Wouldn't expect that to be an issue.

Shouldn't be. If it's convenient, could you remove it, enable debugging, and install again? Of course, you can bet it'll work...

Yep, that's exactly correct.

Last time I installed it over version 1.60. This time I removed it first then installed 1.66 over the FMW skin. No dramas. No point to the logs given it worked.

[adoxa]

FWIW, I had 1.64 installed, FMW active.

[IanSav]

Hi Adoxa,

I am looking at the code changes in MovieList.py and the default the mark icon width is set to 16 pixels. The mark images are then loaded and the the height checked against the item height to clip the height of the image. The hard coded mark icon width is never reset the width of the actual icon! It looks like the width override MUST be used to make this work.

I just copied what iconsWidth did.

I will look at fixing the code later.

Why is the existing list data offset by 50 pixels? The original data default offset should be related to the width of the mark icon. This setting requires a specific override but is a setting that shouldn't need to even exist.

I wanted the icon drawn before 50, but the list to remain at 50. The way I solved this was to have the list at 0 and add listPos to seemingly move it back to 50. The icon is then drawn its width (markWidth) and space before it.

This code does not conform to the way the UI widgets normally work. This solution breaks the line highlighting. Again, I will look at fixing this later.

You were right about the FileCommander icons not looking very good in this context.

There's a first.

I have no problems acknowledging when I make a mistake. Once I recognised the issue it was quick and easy to create a better looking set of icons.

The current code can not be used to create a clean left aligned list in OverlayHD.

I'm not sure what you mean. Here's how I do it (well, I would have, if I patched it right):
myway.png

Code: Select all

	<screen name="MovieSelectionListBeyonwiz">
		<widget name="list" position="0,80" size="810,525" backgroundColor="MenuBackground" backgroundColorSelected="MenuSelected" enableWrapAround="1" foregroundColor="MenuText" foregroundColorSelected="MenuTextSelected" scrollbarMode="showOnDemand" transparent="0"
			font="MovieSelectionFont;20" pbarHeight="10" pbarLargeWidth="45" spaceIconeText="5" iconsWidth="25" spaceRight="5" dateWidthScale="9.0" lenWidthScale="4.0" sizeWidthScale="5.0" listPos="50" />

and here's what I think you're after:
yourway.png

Code: Select all

	<screen name="MovieSelectionListBeyonwiz">
		<widget name="list" position="50,80" size="760,525" backgroundColor="MenuBackground" backgroundColorSelected="MenuSelected" enableWrapAround="1" foregroundColor="MenuText" foregroundColorSelected="MenuTextSelected" scrollbarMode="showOnDemand" transparent="0"
			font="MovieSelectionFont;20" pbarHeight="10" pbarLargeWidth="45" spaceIconeText="5" iconsWidth="25" spaceRight="5" dateWidthScale="9.0" lenWidthScale="4.0" sizeWidthScale="5.0" markWidth="20" listPos="25" />

After doing that I'll admit it could be better.

I strive for pixel perfect alignment of all on screen elements. This is a case where I can not achieve the alignment I desire. I will look at fixing this when I look at the other UI changes I would like to make to this code.

Regards,
Ian.

[adoxa]

[...] This solution breaks the line highlighting. [...]

Ah yes, that was another thing - I didn't want the mark to be highlighted, especially when it's blank.

You were right about the FileCommander icons not looking very good in this context.

There's a first.

I have no problems acknowledging when I make a mistake. [...]

No no, I meant it was the first time I was right.

I strive for pixel perfect alignment of all on screen elements. This is a case where I can not achieve the alignment I desire. I will look at fixing this when I look at the other UI changes I would like to make to this code.

I still don't believe you've told me what you actually want, so I'll just shut up and wait for your patch.

[IanSav]

Hi Paul,

A minor gripe is the install step states the Execution progress step but not Execution finished. After waiting a few minutes I exited and restarted the GUI. As it was not clear it had installed, I reinstalled. On the subsequent attempt, the message came up that it is already installed.

Is this still a problem? I can't reproduce the issue. Once 1.66 is installed you can't reinstall using the GUI, you need to remove OverlayHD and reinstall it again.

Checking the FC screen, I see Help has been added and the "True" icon image is a blue dot.

The HELP button is compliments of Prl's changes to FileCommander.

Yes, the switch icon has had a refresh. Is it okay?

Also, the screen for Menu->YouTube has been redesigned but otherwise appears complete and functional. These were the obvious changes. Anything else is quite subtle.

There are a lot of changes under the covers and a few on top. If things are generally looking "normal" then that is good. If any screens look wrong or don't follow the OverlayHD style I would like the problems and screen captures reported.

In Network->DLNA setup, the following screen is not usable to amend setting: miniDLNA setup (Blank screen but not an issue with 1.60 on the T3).

Can I please have some screen captures with instructions on how to reproduce the issue.

The green tick sits on top of a visible red cross with the TiVo settings, etc. on the previous screen: miniDLNA.

I don't seem to be able to enable the TiVo option on my box. Can you please give me more information about what you are experiencing. (My issue may be due to my new setup engine but it could be an existing bug.)

Mountpoints management -> Mountpoint viewer screen: No borders around green ticks? (General observation: Newer screens use the selection box border around green ticks but older screens do not [See Autotimer options]. This is not consistent through the whole interface.)

In Mountpoints management there are three icons used. The green tick indicates that the mount is active. The red cross indicates that the mount is inactive. The yellow exclamation mark indicates an error condition. These icons are a status report and not a call to action. The ticks in boxes represent an option that has been selected and can optionally be deactivated (like file selection). Think of these boxed icons like checkboxes on a web page. The two sets of icons have different meanings in the UI.

I have the next version of OverlayHD (1.67) ready to go. It has the CutList editor changes, the new FileCommander headings and an improved MovieSelection screen (though it is not as good as I would like it to be - yet). Obviously I will look at the issues you mentioned once I understand them. Other than those issues is there anything in the skin that should stop me releasing it to everyone as an automated update?

Regards,
Ian.

[Paul_oz53]

Hi Paul,

A minor gripe is the install step states the Execution progress step but not Execution finished. After waiting a few minutes I exited and restarted the GUI. As it was not clear it had installed, I reinstalled. On the subsequent attempt, the message came up that it is already installed.

Is this still a problem? I can't reproduce the issue. Once 1.66 is installed you can't reinstall using the GUI, you need to remove OverlayHD and reinstall it again.

No, not a problem for me the second time around. Only happened when I installed it without removing 1.60. The second time I uninstalled the OverlayHD skin before running the install.

Checking the FC screen, I see Help has been added and the "True" icon image is a blue dot.

The HELP button is compliments of Prl's changes to FileCommander.

Yes, the switch icon has had a refresh. Is it okay?

Thanks prl. FC usability is now very much improved.

Re the icon: I do tend to get used to the way things are so sorry to say I prefer the old icon. Mainly because I find it easier to see when I access the machines using Openwebif. At the end of the day, it is a matter of personal preferences.

Also, the screen for Menu->YouTube has been redesigned but otherwise appears complete and functional. These were the obvious changes. Anything else is quite subtle.

There are a lot of changes under the covers and a few on top. If things are generally looking "normal" then that is good. If any screens look wrong or don't follow the OverlayHD style I would like the problems and screen captures reported.

I did not find any other screens that were wrong, apart from the two MiniDLNA screens on the U4.

In Network->DLNA setup, the following screen is not usable to amend setting: miniDLNA setup (Blank screen but not an issue with 1.60 on the T3).

Can I please have some screen captures with instructions on how to reproduce the issue.

The green tick sits on top of a visible red cross with the TiVo settings, etc. on the previous screen: miniDLNA.

I don't seem to be able to enable the TiVo option on my box. Can you please give me more information about what you are experiencing. (My issue may be due to my new setup engine but it could be an existing bug.)

Bear in mind I am testing 1.66 on the U4 and using the T3 for comparison with the current production OverlayHD. I suspect if there is a difference with 1.66 on your T3 to the U4 results, it may have something to do with the way the U4 presents video. I seem to recall some early discussion of that but it has long since gone quiet.

Attached are screenshots of the two screens on the U4 and the T3 for comparison. Access as Menu>>Network>>DLNA Setup. On the U4 both the red cross and green tick are visible but on the T3 it is either / or. If one now presses Menu, the U4 screen is blank, whilst the T3 has the MiniDLNA setup options displayed.

Mountpoints management -> Mountpoint viewer screen: No borders around green ticks? (General observation: Newer screens use the selection box border around green ticks but older screens do not [See Autotimer options]. This is not consistent through the whole interface.)

In Mountpoints management there are three icons used. The green tick indicates that the mount is active. The red cross indicates that the mount is inactive. The yellow exclamation mark indicates an error condition. These icons are a status report and not a call to action. The ticks in boxes represent an option that has been selected and can optionally be deactivated (like file selection). Think of these boxed icons like checkboxes on a web page. The two sets of icons have different meanings in the UI.

OK, that clears up the distinction.

I have the next version of OverlayHD (1.67) ready to go. It has the CutList editor changes, the new FileCommander headings and an improved MovieSelection screen (though it is not as good as I would like it to be - yet). Obviously I will look at the issues you mentioned once I understand them. Other than those issues is there anything in the skin that should stop me releasing it to everyone as an automated update?

Regards,
Ian.

I don't believe so Ian, MiniDLNA aside.

I haven't explored all the screens under Media->Menu but those I did look at were fine (also Media, IMDB, EPG, Timers, Autotimers). I checked nearly all the screens under Menu. These were all OK. The only really obvious change is in the YouTube screens and it worked OK for me with the new skin screens.

Since I bought the Denon AVR, it has the WizTV dongle installed and that is now my preferred YouTube viewer. Consequently, I no longer use the inbuilt version as my primary YouTube source. This is not because of the skin but because the interface on the dongle is full-featured whereas the inbuilt version is not.

[prl]

Checking the FC screen, I see Help has been added ...

The HELP button is compliments of Prl's changes to FileCommander.

Thanks prl. FC usability is now very much improved.

Thanks. There's more to come

Progress on the work on File Commander is logged here.

[IanSav]

Hi Prl,

I don't have a U4. Could you please see if the DLNA issues that Paul is reporting are actually a U4 issue rather than a skin issue?

Regards,
Ian.

[Grumpy_Geoff]

I don't have a U4. Could you please see if the DLNA issues that Paul is reporting are actually a U4 issue rather than a skin issue?

There's no issue with those screens on a U4 running F-M-W.

[prl]

There doesn't seem to be any problem with the MiniDLNA screens for me, U4 with OverlayHD 1.66 and firmware 20180729beta.:

[prl]

I don't have a U4. Could you please see if the DLNA issues that Paul is reporting are actually a U4 issue rather than a skin issue?

There's no issue with those screens on a U4 running F-M-W.

I think the question relates just to IanSav's recent changes to OverlayHD. In the pre-loaded skins, the file that contains the MiniDLNA main screen hasn't changed since early April.

[Paul_oz53]

I don't have a U4. Could you please see if the DLNA issues that Paul is reporting are actually a U4 issue rather than a skin issue?

There's no issue with those screens on a U4 running F-M-W.

I'm beginning to think this has something to do with the first failed attempt to install 1.66 on the U4. FMW and easy-aus are both corrupt on my U4. (BTW - in my earlier post where I say version 1.60, I suspect it is in fact version 1.64 that is running on the T3/T4.)

I'll reflash back to 20180417 and try again.

[Paul_oz53]

You can rest easy Ian.

The problem must have been induced with the original install. It has now been restored to normality.

[IanSav]

Hi,

Thanks to everyone for testing out the DLNA screens.

@Paul, are you getting used to the new switch icon? If you still don't like it then how could I improve it?

Regards,
Ian.

[Paul_oz53]

Hi,

Thanks to everyone for testing out the DLNA screens.

@Paul, are you getting used to the new switch icon? If you still don't like it then how could I improve it?

Regards,
Ian.

Hi Ian.

I can live with the icons. I still prefer the older style which has a greater area coloured blue when selected. If you could make the blue circle larger, that would be a compromise but it's up to you.

Cheers,

[IanSav]

Hi Paul,

I can live with the icons. I still prefer the older style which has a greater area coloured blue when selected. If you could make the blue circle larger, that would be a compromise but it's up to you.

I asked because I wanted to improve the acceptability for everyone. No suggestion or comment will be ignored.

I can make the blue LED larger or I can make the entire top of the switch blue. The reason I changed the icons was because having the switch background change colour looked wrong to me. Do any of the attached versions appear better to you?

Regards,
Ian.

[prl]

The reason I changed the icons was because having the switch background change colour looked wrong to me.

I've seen that convention used in some physical slide switches.

[IanSav]

Hi Prl,

The reason I changed the icons was because having the switch background change colour looked wrong to me.

I've seen that convention used in some physical slide switches.

As have I, and I didn't like it there either. Though the physical and three dimensional aspect of a physical switch did help.

Regards,
Ian.

[Paul_oz53]

Hi Paul,

I can live with the icons. I still prefer the older style which has a greater area coloured blue when selected. If you could make the blue circle larger, that would be a compromise but it's up to you.

I asked because I wanted to improve the acceptability for everyone. No suggestion or comment will be ignored.

I can make the blue LED larger or I can make the entire top of the switch blue. The reason I changed the icons was because having the switch background change colour looked wrong to me. Do any of the attached versions appear better to you?

Regards,
Ian.

At the risk of appearing indecisive, I can live with either. The criteria I use is can I tell at a glance whether it's selected or not. The original draft replacement is a bit small. I do prefer icons to text for this function.

Alternate 1 is an improvement on the draft icon and has the more modern LED feel so I'd be happy to go with that. Being old fashioned, I'm also very happy to use alternate 2 is if that's on offer. The latter is more reminiscent of manual slide switches.

[IanSav]

Hi Paul,

Given that I didn't get the off switch in alternative 1 quite right (I think it is still too dark) I am happy to switch to alternative 2. Consider it done.

Regards,
Ian.

[sub3R]

Hi Ian,

I can’t help much with any comments about your new version of OverlayHD except what I read or see on the forum every now & again (we are away for a few weeks).

My two cents worth about the On/Off buttons; I think the On & Off switch Alternate 2 looks much better than Alternate 1.

In OverlayHD 1.64 I don’t know if the random ‘flashing’ in the corners of the four bottom coloured buttons is something that crept in somehow some time ago & if it can be easily corrected. It appears to be some sort of background video bleed through at the outside of the button corners. For a quality skin like OverlayHD, it just doesn’t look right when it happens. When it happens, it appears worse on the U4/TV combination than on the T2/TV combination.

[IanSav]

Hi Dennis,

The flashing/sparkling around the edges of images is resolved in 1.66+ as a result of changing the alphatest="on" attribute to alphatest="blend" in all images.

Regards,
Ian.

[sub3R]

That’s good to know Ian. Nice work.

[sub3R]

Hi Ian,

I have just updated our U4 & T2 to beta f/w 17.5 20180823 (with OverlayHD 1.64). When running some scripts after this upgrade I noticed that in File Commander the file list header area was blank (no path, permissions etc.). I suspected that this was work in progress in your next version of OverlayHD, so I checked the in-build skins to see if this was the case or if something had gone missing in this latest beta.

When checking this in 'easy-skin-aus-hd' I noticed that the permissions only show, for example, as ‘-rwxr-xr-x’ instead of Octal ‘755’ like the older File Commander version did.

Do you intend to follow suit with OverlayHD & not show the Octal permissions number in the File Commander file list header? The reason I ask is because I find the Octal permissions number easier to see at a glance to tell if a script is currently executable or not, than the way it is now shown in the File Commander file list header of 'easy-skin-aus-hd', & think it would be a shame to lose this.

[prl]

Do you intend to follow suit with OverlayHD & not show the Octal permissions number in the File Commander file list header? The reason I ask is because I find the Octal permissions number easier to see at a glance to tell if a script is currently executable or not, than the way it is now shown in the File Commander file list header of 'easy-skin-aus-hd', & think it would be a shame to lose this.

The skin can show the symbolic mode, octal mode or both in the list header, but there's not a lot of spare space. Previously the content was decided entirely in the code.

I prefer the symbolic view, and I think it's a little less geeky than the octal. The octal mode has also been extended to 4 digits to show the state of the setuid, setgid and sticky bits, though they will be 0 on the large majority of files. The symbolic version also reflects those bits (e.g. 4755, rwsr-xr-x).

I think IanSav has an implementation of the header changes in OverlayHD needed for the new version of File Commander (and for backward compatibility to the old one), but I don't think it's in a release yet.

[Grumpy_Geoff]

...The reason I ask is because I find the Octal permissions number easier to see at a glance to tell if a script is currently executable or not, ...

You shouldn't need to worry about a script not having execute permissions when running it in FileCommander, as prl fixed that a while back.

[IanSav]

Hi Dennis,

I have just updated our U4 & T2 to beta f/w 17.5 20180823 (with OverlayHD 1.64). When running some scripts after this upgrade I noticed that in File Commander the file list header area was blank (no path, permissions etc.). I suspected that this was work in progress in your next version of OverlayHD, so I checked the in-build skins to see if this was the case or if something had gone missing in this latest beta.

I have OverlayHD 1.66 almost ready to go. Unfortunately I am seeing a crash in one of the converters but I can't see a bug in OverlayHD that triggers it. The infoRecBm is poorly written and has no error detection or protection code. I am still investigating. The bug causes a crash when two sequential timers run on the same service and triggers when the second timer in the sequence starts. infoRecBm gets called with a None parameter that it doesn't understand and just crashes. I think the bug may not be in my code but could be in the timer starting pop ups.

When checking this in 'easy-skin-aus-hd' I noticed that the permissions only show, for example, as ‘-rwxr-xr-x’ instead of Octal ‘755’ like the older File Commander version did.

Do you intend to follow suit with OverlayHD & not show the Octal permissions number in the File Commander file list header? The reason I ask is because I find the Octal permissions number easier to see at a glance to tell if a script is currently executable or not, than the way it is now shown in the File Commander file list header of 'easy-skin-aus-hd', & think it would be a shame to lose this.

OverlayHD 1.66 and later show both the symbolic and octal values using the facility that Prl baked into the new code..

Regards,
Ian.

[prl]

...The reason I ask is because I find the Octal permissions number easier to see at a glance to tell if a script is currently executable or not, ...

You shouldn't need to worry about a script not having execute permissions when running it in FileCommander, as prl fixed that a while back.

I'm a little puzzled by the claim, too, because the execute bit is set for octal digits 1, 3, 5 & 7, and though 3 is a slightly unusual combination, write and execute, but not read, the other three are quite sensible combinations.