fix: handle a missing pardus-xfce-settings without crashing or discarding user config

[ehlinazgumus]

Two places in this library read files from /etc/xdg/pardus/xfce4/... without checking that they are there. Those files come from pardus-xfce-settings, which is not a declared dependency of pardus-lib-xfce or of pardus-xfce-tweaks:

$ apt-cache depends pardus-xfce-tweaks | grep Depends
  Depends: python3-gi
  Depends: python3
  Depends: gir1.2-gtk-3.0
  Depends: gir1.2-xfconf-0
  Depends: pardus-lib-xfce

$ apt-cache rdepends pardus-xfce-settings
  pardus-xfce-desktop
  pardus-xfce-live-settings

So the package is only pulled in by the two desktop meta-packages. Installing XFCE another way — apt install xfce4 — or installing pardus-xfce-tweaks on its own leaves it out.

1. DatetimeManager crashes at import when the defaults are missing

The copy runs in the module body and only checks the destination:

if not os.path.exists(PLUGIN_RC_FILE_PATH):
    os.makedirs(PLUGIN_RC_FILE_DIRECTORY, exist_ok=True)
    shutil.copyfile(ETC_XDG_DATETIME_PATH, PLUGIN_RC_FILE_PATH)

Because it is at module level, the error escapes through pardus-xfce-tweaks'
import and the application dies before its window exists. On Pardus 25.1 with
xfce4 + pardus-xfce-tweaks 0.5.0 installed and pardus-xfce-settings absent:

  File "/usr/share/pardus/pardus-xfce-tweaks/src/MainWindow.py", line 42, in <module>
    import pardus_lib_xfce.DatetimeManager as DatetimeManager
  File "/usr/lib/python3/dist-packages/pardus_lib_xfce/DatetimeManager.py", line 16, in <module>
    shutil.copyfile(ETC_XDG_DATETIME_PATH, PLUGIN_RC_FILE_PATH)
FileNotFoundError: [Errno 2] No such file or directory: '/etc/xdg/pardus/xfce4/panel/datetime-8.rc'

Launched from the applications menu there is no traceback and no window — nothing happens at all.

This PR guards the copy on the source existing and treats a missing config as an empty one, so the datetime plugin settings degrade instead of the whole UI failing to open.

DatetimeManager.restore_default_settings() had the same pattern in a worse form — os.remove() first, copyfile() second — which left the user with no config at all when the source was missing. It now checks first, and drops the remove since copyfile overwrites anyway. It also left config_file_data holding the pre-restore contents, which the next save_file() would write straight back out; that is refreshed now.

2. PanelManager.restore_default_settings() deletes before it checks

xfce4_panel.reset_property("/", True)
subprocess.run(
    """xfce4-panel --quit;
    pkill xfconfd;
    rm -rf ~/.config/xfce4/panel/* ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-panel.xml;
    cp -R /etc/xdg/pardus/xfce4/panel/* ~/.config/xfce4/panel/;
    ...""",
    shell=True,
)

The steps are chained with ;, so a failing cp does not stop anything, and there is no check=True — the removal has already happened by then either way. This PR verifies the defaults are present before touching anything the user owns, keeps a .bak copy since the operation cannot be undone, chains the shell steps with &&, and adds check=True.

In practice issue 1 currently masks this one: without pardus-xfce-settings the application never opens, so the button cannot be reached. The guard is still worth having — the removal is irreversible, and a partially installed or damaged defaults directory would hit the same path.

Testing

DatetimeManager was exercised directly against a temporary HOME:

Case	Before	After
defaults missing, no user config	FileNotFoundError at import	imports, config_file_data == ""
restore_default_settings(), defaults missing	removes user file, then raises	raises first, user file untouched
defaults present	seeds and reads config	unchanged
set() then restore_default_settings()	stale value survives the restore	value reverts to the default

PanelManager was verified at the patch level: with the defaults absent the old code removed the user's configuration, the new code raises FileNotFoundError and leaves it in place.

Neither change has been run end to end against an installed package on a full XFCE session.

A note on packaging

The code fixes stop the failures, but the underlying issue is the missing declaration. pardus-lib-xfce reads files at runtime that only pardus-xfce-settings provides, so debian/control arguably wants a Depends: (or at least Recommends:) on it. I have left that out of this PR since it is a packaging decision for you to make. The same gap exists for pardus-xfce-icon-theme, referenced from pardus-xfce-tweaks' MainWindow.py:714 and :727.