Hi all,

Could you tell me if you also experience this annoying behavior, or if it's only me?

https://bugs.kde.org/show_bug.cgi?id=335852

I very much rely on the appearance of my desktop remaining identical through reboots (spatial memory).

Lately this feature is quite broken. For instance, Kmail always open full screen no matter what. So does System-Settings, for no reason that I can see. And not they do not have window manager rules attached to them. I just mention that because maybe it's related.

Thanks,
Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, January 11, 2021 09:59:57 AM inkbottle wrote:

Hi all,

Could you tell me if you also experience this annoying behavior, or if it's only me?

https://bugs.kde.org/show_bug.cgi?id=335852

I very much rely on the appearance of my desktop remaining identical
through reboots (spatial memory).

Lately this feature is quite broken. For instance, Kmail always open full screen no matter what. So does System-Settings, for no reason that I can
see. And not they do not have window manager rules attached to them. I
just mention that because maybe it's related.

Are you addressing only the behavior of Okular, or are you referring to the behavior of some other apps as well?

I don't reboot very often, but Okular is problematic in that, if I'm viewing a .pdf from the web (this in Wheezy and Jessie), the .pdf content is stored in .tmp (or something similar), the problem being that on a reboot, .tmp (or whereever the .pdf content is stored) gets wiped out (at least by default, on my system).

So, obviously, at that point there is no (easy, or built in) way for Okular to restore the content. (Okular would have to keep track of the original URL and reload it, and I don't think that capability is built into Okular at this
point in time -- I guess it would be a nice to have feature, but I don't know if anybody is interested in doing something like that.

Aside: I guess, also, without thinking about it, somebody (any user) could build sort of a bash (?) "wrapper" around Okular to do something along those lines -- i.e., instead of invoking Okular to view a .pdf, you'd invoke a bash script which would store the URL somewhere safe before invoking Okular to display the .pdf. That script would also have to be invoked when closing a .pdf to remove that URL from the safe storage location. )

I don't know whether if I was viewing a .pdf from my "permanent" disk storage behavior would be any different / better. I rarely, if ever do that. (I wish .pdfs would just go away (along with all the Microsoft "document" formats.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, January 11, 2021 4:41:49 PM CET rhkramer@gmail.com wrote:

On Monday, January 11, 2021 09:59:57 AM inkbottle wrote:

Hi all,

Could you tell me if you also experience this annoying behavior, or if
it's
only me?

https://bugs.kde.org/show_bug.cgi?id=335852

I very much rely on the appearance of my desktop remaining identical through reboots (spatial memory).

Lately this feature is quite broken. For instance, Kmail always open full screen no matter what. So does System-Settings, for no reason that I can see. And not they do not have window manager rules attached to them. I
just mention that because maybe it's related.

Are you addressing only the behavior of Okular, or are you referring to the behavior of some other apps as well?

I don't reboot very often, but Okular is problematic in that, if I'm viewing a .pdf from the web (this in Wheezy and Jessie), the .pdf content is stored in .tmp (or something similar), the problem being that on a reboot, .tmp
(or whereever the .pdf content is stored) gets wiped out (at least by default, on my system).

So, obviously, at that point there is no (easy, or built in) way for Okular to restore the content. (Okular would have to keep track of the original
URL and reload it, and I don't think that capability is built into Okular
at this point in time -- I guess it would be a nice to have feature, but I don't know if anybody is interested in doing something like that.

Aside: I guess, also, without thinking about it, somebody (any user) could build sort of a bash (?) "wrapper" around Okular to do something along those lines -- i.e., instead of invoking Okular to view a .pdf, you'd invoke a
bash script which would store the URL somewhere safe before invoking Okular to display the .pdf. That script would also have to be invoked when
closing a .pdf to remove that URL from the safe storage location. )

I don't know whether if I was viewing a .pdf from my "permanent" disk
storage behavior would be any different / better. I rarely, if ever do
that. (I wish .pdfs would just go away (along with all the Microsoft "document" formats.)

No, what you are describing is unrelated with the issue considered here. You should certainly formulate that issue of yours through a new question, either here, or in general channel.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)