On Tue, 19 Apr 2016 at 0:45:04 +0300, Alexandru Lazar wrote: > >>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.
I see now, thanks for clarifying. > getstyle should either fix this automatically (by renaming one of the > files after the relocation) or complain about it. I think it should not "fix" this automatically. Suppose you rename it. Are you going to rename it to what? We should avoid surprises. In the unlikely event that one has two different files with the same name in creating a theme, we should better just complain about it and refuse to do crazy stuff to work around this. > 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. Indeed. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
