Hide Forgot
Description of problem: Session saving with configuring xosview with +cpus and -int and setting "on all desktops" (8 in my case) fails to save the xosview settings. Version-Release number of selected component (if applicable): basesystem-10.0-8.fc19.noarch How reproducible: Happens all the tim. Steps to Reproduce: 1.enter "xosview +cpus -int" 2.set to occupy "all desktops" 3.save the session 4.exit the current session 5.start a new session 6.all known (to me) settings appear to have been saved but xosview reverts to unmodified settings Actual results: see description above. Expected results: see description above. Additional info: xosview-1.15-1.fc19.x86_64
It's rather the other way round, xosview fails to save its state upon session saving.
How is this supposed to work? xosview don't have any state as such. xosview is using X RESOURCES to set default options. To set +cpus -int, use: echo "xosview*cpuFormat: all" >> ~/.Xdefaults echo "xosview*int: False" >> ~/.Xdefaults xrdb < ~/.Xdefaults Then start: xosview
It's all described here: http://www.x.org/releases/X11R7.7/doc/libSM/SMlib.html
Thanks for link, this is out of scope. George R. Goffe, please contact xosview upstream here: https://github.com/hills/xosview if you want this fixed. In Fedora context I am setting won't fix, sorry.
Guys, Are you telling me that RedHat will no longer pursue bugs with Fedora distributions? I'm looking for a general rule here. You put the packages together but when they break, I'm on my own? Sometimes, RedHat makes code changes, are they supported? Thanks, George...
Sorry, I can't answer anything about Red Hat, Fedora is a community driven project. I think reading the FAQ will help you understand how things work: http://fedoraproject.org/wiki/FAQ
The thing is, what you reported is not a bug at all, you're requesting a new feature. Such requests are best sent directly to the upstream developers.
Kevin, My point is that this used to work with fedora 16 x86_64 and it's related KDE. Now it does NOT. Regards, George...
Kevin, I just sent this email to Mark, current(?) owner/maintainer for xosview. Can re-open this one please? Please accept my apologies for not getting back to you sooner about this. I have a freshly installed and updated Fedora 16 x86_64 system and a version of xosview installed therein. Testing shows that the KDE on that system and the xosview on that system does remember it's invocation parameters AND it's desktop placement (i.e. 1) where in the display it's located at "save session" time AND 2) it's multiple desktop presence settings). The source rpm for this xosview can be procured at: http://archive.fedoraproject.org/pub/archive/fedora/linux/updates/16/SRPMS/xosview-1.12-1.fc16.src.rpm. So. It appears that either this is a KDE regression or bug and/or an xosview regression and/or bug. I think that the Fedora people sometimes modify "normal" code for various reasons and make those changes available to Fedora systems. I would hope that they also contact the author(s) and/or maintainer(s) so that their changes can be incorporated in the mainstream of the package(s) they are modifying. Do you need anything else from me? Regards, George...
I have some "latest" and GREATEST testing news... I got the git version of xosview built it on a test FC 16 as xosview.git and ran it with "+cpus and -int", moved it elsewhere on the desktop, turned on "all desktops" and saved the session. When I restarted the desktop... xosview.git was EXACTLY where I placed it and had retained the "all desktops" setting and had remembered the # of cpus too. What this testing tells me is that there's a regression in KDE session saving.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
please try latest in f28 if it works for you. Feel free to reopen it if the issue still shows up. thanks