Hi,
> There were recent patches touching these path creation routines
that could very well have introduced odd behavior.
Just do a:
git log util/getstyle.c
to see that there were patches touching these precise areas.
Yeah, the one I mentioned was the only one that looked odd to me.
However, it was clearly the right thing to do, all that system()-based
stuff was clunky and had to go. I'll try to confirm this hunch tomorrow
just to be sure.
If that turns out to be wrong, I'll try to locally revert the odder
commits to getstyle.c, too, before patching things. They aren't too
many. Maybe the bug was inconspicuously introduced by a more trivial
patch that can be reverted without causing much harm, or fixed more easily.
It seems to me that a much cleaner solution is to relocate
/long/path/to/file.png to themeDir/assets/file.png. The only problem
this seems to have is that a theme creator may use files with the
same name, but located in different places, and getstyle would
either have to rename these automatically (not too difficult) or
bork and warn the user (trivial, but possibly annoying to use).
If you're copying the files to themeDir/assets then why is this
a problem for getstyle? Why would it care about other files elsewhere?
Note that I haven't read the code, so this is just a "common sense"
type of question.
If the theme uses a pixmap at /home/user/Documents/brushedmetal.png and
a background image at /home/user/Pictures/wallpapers/brushedmetal.png,
relocating them with their full path under themeDir/, as
themeDir/home/user/Documents/brushedmetal.png and
themeDir/home/user/Pictures/wallpapers/brushedmetal.png will be fine.
However, trying to blindly relocate them to
themeDir/assets/brushedmetal.png won't do. They may have the same name,
but that doesn't mean they're necessarily the same file (one may be a
small 64x64 px tile, the other may be a wallpaper), so overwriting one
with the other is not the correct choice. getstyle should either fix
this automatically (by renaming one of the files after the relocation)
or complain about it.
It's the only likely reason I can think of for relocating files with
full path (I have done it in the past, too, just in order to not
recursively mkdir stuff). It is, however, a very remote cornercase; in
fact, I doubt it's being handled correctly right now, too, as I don't
see how findCopyFile could discriminate between two identically-named
files at different paths; since that seems to have worked fine for 6-12
years now, it's fair to conclude that it's woefully uncommon.
Alex
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
