Deleting uploaded files?

[lciscon]

This has to be a user error or something with my configuration. I don't see how to delete uploaded gcode files through the TouchUI file interface. There is no trashcan icon when you swipe left on the file. Am I missing something obvious?

FYI I tried doing a search for this already, but could not find anything applicable.

[freddotu]

I had noted the same thing and accidentally swiped to the left during a different movement. This unhides the trash can and other icons.

[lciscon]

Just to be clear: yes I know that swiping left exposes the icons. The point is that there is no trash can icon:

[lciscon]

Sorry I didn't mean to close the thread.

[lciscon]

Any thoughts? This seems like a critical issue.

[stale]

This issue has been automatically marked as inactive because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lciscon]

I would appreciate some input or suggestions on this issue. As I say this is a critical capability for the proper use of the system.

[stale]

This issue has been automatically marked as inactive because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[BillyBlaze]

Sorry for the long delay and thanks for reporting, I'll have a look at this in the upcoming release.

[lciscon]

FYI I built a new image completely from scratch using the latest versions of everything (octoprint, TouchUI, plugins, etc.) and the delete button is there. I suspect a user or file permissions error of some sort. I'm going to try removing and re-creating the user profile from scratch to see if that fixes it.

[BillyBlaze]

Thanks for the update. After looking into this issue, it's OctoPrint that will check file permissions and hide the button if it's unable to delete a file.

If there is an issue with this feature, then you need to address this in OctoPrint. If it's a TouchUI problem then please let me know!

[lciscon]

I was able to reproduce this issue on a brand-new install by simply toggling the TouchUi on/off in a browser window. In non-TouchUI mode we can delete the file:

When I turn on TouchUI in the same session the delete icon is missing:

[lciscon]

Ok the problem is actually that ALL trashcan icons (i.e. class="fa fa-trash") are missing from the TouchUI interface. The button is still actually there and works. If you press the blank space where the trashcan icon would be it does delete the file.

You can verify this by going to any screen where the trashcan icon should appear:

[lciscon]

Ok I figured it out. It appears the Bed Level Visualizer plugin is somehow changing the "fa-trash-o" class to point to a blank icon. If I uninstall or even just disable that plugin, the icon reappears in TouchUI. It took a LOT of experimentation to figure this out.

Here is my (rough) theory: It appears that many plugins define the font awesome less styles for their own use using exactly the same class names (e.g. "fa-trash-o"). So depending on the loading order of the plugins, if one of them changes the definition of something (e.g. by changing the trash icon to point to a blank icon) it affects ALL plugins that use that class.

I'm going to close this issue out here and go yell at them instead...

[jneilliii]

So the issue here is the use of fontawesome 5 library in my plugins. I have included the v4 shim that is supposed to resolve this issue, but I'd be more than willing to patch that shim file to resolve this conflict with TouchUI unless @BillyBlaze has a better idea?

[jneilliii]

@BillyBlaze, doing a quick debugging before heading out and it looks like TouchUI's css file is specifying the font-family here which is causing the icon to not show if I'm not mistaken. That is causing fontawesome 5 free assignment to be overwritten when loaded. Let me know what you think.

[jneilliii]

I think I have a possible solution by adding !important to my v4 shim file for this icon. My local testing seems to work.

[BillyBlaze]

@jneilliii, thanks for all the info. That font-family definition needs to be removed. I think its a left-over when I bundled a newer fontawesome before.

[lciscon]

Ok his fix works, so technically this is closed.

IMHO it seems to me that ANY plugin that uses Fontawesome V5 could conceivably create the same conflict unless they happen to add that same flag. Net net TouchUI is pointing to one (or more) Fontawesome unicode value(s) that no longer exist in V5. And given the overlapping class definitions, with the right startup sequence there can be a conflict. Perhaps the best solution is to upgrade TouchUI to V5??? Dunno.

[jneilliii]

I think like what @BillyBlaze said would resolve the conflict for any plugins with fontawesome 5 assuming they also include the standard v4 shim file. As he mentioned, since fontawesome 4 is now bundled with OctoPrint there is no need for those declarations within TouchUI, and realistically no need to include the fontawesome library in his plugin either I don't think.

[lciscon]

Ok I'm good with whatever works ;-)

[BillyBlaze]

Yeah, its exactly like @jneilliii said. I am only going to support whats is in the core of OctoPrint. If I need to support all this edge cases then the code-base will be unmaintainble.

Also I will re-open this issue as a reminder for myself for the next release

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.