On Wed, 20 Apr 2016 at 22:52:32 +0300, Alexandru Lazar wrote: > Good evening everyone, > > This took a little longer than expected because something felt a > little off in what was happening (see the P.S. below). The patch I'm > attaching implements the "clean" fix I proposed in this thread. It > relocates assets under <themedir>/assetname. > > The changes are in two functions: > > 1. In findCopyFile, it does wcopy_file(dir, fullPath, file) instead > of wcopy_file(dir, fullPath, fullPath) (where dir is really > <themedir>, fullPath is <full path to file>/file, and file is the > file's name, without the rest of the path). This causes file to be > copied at <themedir>/file, not <themedir>/fullPath. > > 2. On the *other* branches in makeThemePack (i.e. when > strrchr(WMGetFromPLString(file), '/') doesn't return null, which > causes findCopyFile to be called because the full path to the file > is not known), makeThemePack now gets the "new" path before copying > the file, and then calls wcopy_file with the new path as a > destination. > > I have tested this patch on my system as well as I could, but I > would appreciate any additional testing. Needless to say, any > comments are appreciated, too. > > While testing, I did stumble upon something that appears to be an > unrelated bug. I'm not reporting it separately because I'd > appreciate another opinion on it (maybe my patch introduces it in > some manner that escapes me). > > If I save a theme, apply it (causing the assets to be loaded from > the .themed directory, rather than from wherever they're on my > system), then gestyle -p again, it doesn't work. wcopy_file borks > like this: > > WINGs(wcopy_file(findfile.c:441)): error: Could not open input file > "~/GNUstep/Library/WindowMaker/Themes/test.themed/BlueImage.jpeg": > No such file or directory > > The file *does* exist, so the obvious culprit is that ~ doesn't get > expanded to /home/alazar, but I don't understand is why > WMGetFromPLString(file) would return a path that begins with "~" in > the first place. I suspect this problem did not occur back when > copying was done via system() because the shell was expanding the > "~", but that's no longer the case. Besides, the "dirty" fix > (mkdir-ing the whole hierarchy before wcopy_file) would not have > avoided this, either. > > Can anyone find something wrong with this reasoning? > > If not. I'll provide a separate patch for this problem.
I believe you are correct in saying that the problem is the ~ in the path. I will apply your patch now and wait for the other fix, thanks! -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
