This produces a more-native dialog on Windows and macOS, plus it enables
portals in Flatpak so we don't need to request special permission to
access the file system.
/*
* purple
*
* Purple is the legal property of its developers, whose names are too numerous
* to list here. Please refer to the COPYRIGHT file distributed with this
* source distribution.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02111-1301 USA
*
*/
#ifdef HAVE_CONFIG_H
#include<config.h>
#endif
#include<string.h>
#include<stdio.h>
#include<stdlib.h>
#include<sys/types.h>
#include<glib.h>
#include"internal.h"
#include"prefs.h"
#include"debug.h"
#include"util.h"
staticPurplePrefsUiOps*prefs_ui_ops=NULL;
struct_PurplePrefCallbackData{
PurplePrefCallbackfunc;
gpointerdata;
guintid;
void*handle;
void*ui_data;
char*name;
};
structpref_cb{
PurplePrefCallbackfunc;
gpointerdata;
guintid;
void*handle;
void*ui_data;
char*name;
};
/* TODO: This should use PurpleValues? */
structpurple_pref{
PurplePrefTypetype;
char*name;
union{
/* 'generic' is kind of ugly. We use it as an elegant way to refer to
the value of this pref when calling callback functions. We could
use 'boolean' or 'integer' or any other field... but it feels
mildly cleaner to use a gpointer. Maybe it would be best to use a