Well, I see your image above, but the link in my system isn't showing anything . . . it's OK, I'll fiddle with it later . . . .
But, just to repeat I appreciate the speed of the response to a relatively "minor" issue . . . over on launchpad a number of us have reported a problem with grub2 with a bug report filed . . . and seemingly many months later it is not responded to, yet alone resolved . . . a much more "serious" problem as far as functionality goes . . . can being kicked down the road, etc. So, thanks again on the fast response . . . not used to that . . . on many other forums, etc.
You're welcome. It is something any one of us could contribute a fix with the know-how, I just happened to be passing by and it seemed a quick 5 minute task.
There's loads of different people maintaining different packages - for instance, I'm a developer of Ubuntu MATE "in-house" apps and website, but I don't get involved with other projects (GRUB, MATE, Ubuntu, etc). There ain't developers from those projects that hang around in this forum, but it should reach the relevant maintainers on Launchpad in the wider Ubuntu community.
Seems like this might be a "MATE" problem?? I just booted up my Manjaro 20.01 MATE partition in an older laptop . . . and the GNOME logo is also no where to be found . . . it's just the infinite Black deep space background . . . not Black & White . . . . The MATE logo is instantly operational . . . but it just isn't as amusing as the Floating Feets . . . bubbling around. Next day or so I'll see if I can get the U-MATE 18.04 live DVD booted up and copy and/or drag the svg file over and get it installed in the various MATE systems in which the Feets are . . . dysfunctional . . . .
Yeah this doesn't make sense. Where does the GNOME logo cock up which requires repair of the library?
This isn't necessarily a regression issue, but hot damn does it feel like one. If a change to the kernel breaks a previously-functional system, then it's a kernel issue. If a library breaks a previously-functional file, then it's a library issue and the library needs to be fixed, not the image, because this probably isn't the only SVG where a library update makes it non-functional.
You should close that request @lah7 or revert its changes and figure out what's making the image not load. Linus would rip you a new one for what you did.
non_space, you might try downloading the gnome-logo-white.svg by looking at the page that lah7 posted - and right click on the empty page selecting View Page Source. Another page opens.
Copy that page's contents to an empty file created on your desktop entitled "gnome-logo-white.svg" and you will have the desired working (that is functional) logo to copy to /usr/share/pixmaps/
It took a little head scratching to figure this out. Good luck.
Thanks for going into the details . . . I'm in Tumbleweed MATE right now and the Floating Feet screensaver is also busted here, so since it's all a MATE issue I tried to fiddle with it in TW.
This time when I clicked on lah7's link there was a foot there and I followed your advice and copied the code into an empty file and tried to give it the file name, but it said, "name already in use," but the system created a new "paint brush" file on the desktop that has a working image of the foot. I tried to "copy to" but that only gives me "home" or "desktop" . . . I tried to drag the new image over to the GUI "usr/share/pixmap" window and it showed "do you want to replace?" and I clicked replace, but then it says "denied" . . . didn't seem to give me a change to enter admin password. I also tried to trash the non-functioning old svg file, but that is greyed out . . . .
Assuming that I have to "su" into something, but I don't know how I would run a command to "mv" the new desktop "gnome-logo-white.svg" file into the "pixmap" directory??? Series of commands?? I'm mostly a GUI operator, but this seems like it would have to be done via console??
I would guess an SVG library on newer distros considers the old 7+ year old SVG as invalid. It had additional DOCTYPE syntax which is not necessary in SVGs these days.
Too many tools couldn't open the file - GitHub, MATE EOM and Inkscape, so I would consider the SVG as invalid to start with - but the library may had ignored and "it just worked" in the past?
For all the struggles getting the file, it probably was just how the browsers deals with them - it is a white SVG you can't see, and don't always behave like images. SVGs are just text files, the F12 developer tools shows the syntax.
Not to be "argumentative" . . . but if it's the "SVG" part that is causing the problem, why is that the "mate-logo-white.svg" is operational in the "Floating MATE" screensaver??
PS: Got the last of the four MATE DEs switched over to the new Feets logo . . . very happy to have the working Floating Feets in all of my MATE environments . . . . : - )))
SVG files are a subset of XML. In this case, gnome-logo-white.svg was actually invalid.
<!DOCTYPE svg PUBLIC '-//W3C//DTD SVG 1.0//EN'
'http://www.w3.org/TR//REC-SVG-0904/DTD/svg10.dtd'>
isn't strictly needed, but the xmlns attribute seems to be invalid:
xmlns='http://www.w3.org/2/svg'
Both URLs don't point to a valid spec (at least, if they did, then not any more)
mate-logo-white.svg on the other hand was exported in Inkscape and (still) follows the standard - it's already using this recognised xmlns "namespace":
![[Original] gnome-logo-white.svg](https://github.com/mate-desktop/mate-screensaver/blob/master/data/images/gnome-logo-white.svg?short_path=b8ee84d){kind=link}