History not saved anymore since 0.96.0 release #32
Comments
|
The only fix i found so far was to simply revert https://repo.or.cz/wmaker-crm.git/commit/85169642ca004c75464aa4f803bc0df11bb151cf and thus return this specific function in src/dialog.c to the former state of 0.95.9 and recompile 0.96.0. This restored the expected behaviour. undo_appinfo_history_function.txt Since this particular commit in turn appears to be related to https://repo.or.cz/wmaker-crm.git/commit/bd38778bef37da56705a2066e8181ec7dc3984a5 it would probably be a good idea if someone with actual knowledge of the code could recheck if the history breakage might not actually be caused within this area. Just guessing, maybe it is more than just the history function that might be negatively affected? |
|
On Mon, 21 Aug 2023 at 3:19:31 -0700, Window Maker Live wrote:
The only fix i found so far was to simply revert https://repo.or.cz/wmaker-crm.git/commit/85169642ca004c75464aa4f803bc0df11bb151cf and thus return this specific function in src/dialog.c to the former state of 0.95.9 and recompile 0.96.0. This restored the expected behaviour.
[undo_appinfo_history_function.txt](https://github.com/window-maker/wmaker/files/12395002/undo_appinfo_history_function.txt)
Since this particular commit in turn appears to be related to https://repo.or.cz/wmaker-crm.git/commit/bd38778bef37da56705a2066e8181ec7dc3984a5 it would probably be a good idea if someone with actual knowledge of the code could recheck if the history breakage might not actually be caused within this area.
Just guessing, maybe it is more than just the history function that might be negatively affected?
What is the result of
echo $XDG_STATE_HOME
in your computer?
|
|
In pristine 0.96.0, prior to undoing the mentioned commit, $XDG_STATE_HOME was not set and thus empty. The prior location of the already existing history files was ignored nonetheless. Defining XDG_STATE_HOME via ~/.xsessionrc to a location created for testing doesn't make any difference: |
|
On Mon, 21 Aug 2023 at 5:05:00 -0700, Window Maker Live wrote:
In pristine 0.96.0, prior to undoing the mentioned commit, $XDG_STATE_HOME was not set and thus empty. The prior location of the already existing history files were ignored nonetheless.
Defining XDG_STATE_HOME via ~/.xsessionrc to a location created for testing this doesn't make any difference: An existing $XDG_STATE_HOME is simply ignored and no history files are written or even read.
What is the result of
grep PACKAGE_TARNAME *
in the wmaker directory after compilation?
In particular, in the config.log and config.h files.
|
|
[root]/srv/src/WindowMaker-0.96.0/wmaker-0.96.0 # grep -s PACKAGE_TARNAME * |
|
On Mon, 21 Aug 2023 at 3:19:31 -0700, Window Maker Live wrote:
The only fix i found so far was to simply revert
https://repo.or.cz/wmaker-crm.git/commit/85169642ca004c75464aa4f803bc0df11bb151cf
and thus return this specific function in src/dialog.c to the former
state of 0.95.9 and recompile 0.96.0. This restored the expected
behaviour.
I found a different culprit in
a0b283a (WUtil: Be more strict about base directory for wmkdirhier())
as it was restricting the creation of directories to GNUstep/{Defaults,Library}
but the history is saved in GNUstep/.AppInfo/WindowMaker/History
Can you test the current #master branch in the repository? I am a bit puzzled
by your observation above. That commit doesn't seem to be related.
Note that you have to make sure you have updated the wmaker libraries when
testing this.
|
Please just ignore my former claim that reversion of the commit for in src/dialog.c would resolve the issue, because it actually didn't. As it turned out, only reading the former history files was re-enabled by this, but not appending to nor creating newer history files worked. It is a bad habit of mine to look for culprits and jump to too early conclusions. I apologize for having pointlessly added to the confusion. Now for the good news (and a caveat): After completely recompiling and reinstalling wmaker with the corrected WINGs/proplist.c included, this indeed completely resolved the perceieved symptoms. Not only can be read and appended to former history files, even if no 'GNUstep/.AppInfo/WindowMaker/' exists yet it is created on the fly. Now for the caveat: Thanks! |
Upgrading from 0.95.9 to 0.96.0 apparently broke the incredibly useful history saving feature.
As in following example, while already existing entries are still properly available, executing new commands does not append any entries to the associated "$HOME/GNUstep/.AppInfo/WindowMaker/History.execute" anymore:
%A(Execute...,Type command to execute,execute)
It doesn't matter whether "$HOME/GNUstep/" is created from built-in defaults or if a pre-existing configuration is used.
Switching back to the former release version currently resumes expected normal functioning of history.
The text was updated successfully, but these errors were encountered: