dnrops
/
gimp
mirror of https://github.com/GNOME/gimp.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
gimp/libgimp/gimpvectorloadproceduredial...

177 lines
6.4 KiB
C
Raw Normal View History

libgimp: new GimpVectorLoadProcedureDialog widget. As expected, it is made to reuse shared code for every GimpVectorLoadProcedure. In particular, they all need to choose dimensions to load at, so we are sharing a same GimpResolutionEntry widget logic everywhere now. I am in fact still very unsure about the code logic for this widget by the way for these reasons: * It still puts too much emphasis on the "resolution" (pixel density) part, which makes people believe it's important, while they should in fact choose the pixel dimensions most of the time and not care about the pixel density. * Right now we can't break ratio (which in fact was already impossible in most vector format plug-ins we had). Do we want to add a chain and allow this? * If we consider the pixel density as the one we want to set the document with (which may not be the same thing as the one from when we load the document), we also want to break link between width/height dimensions and pixel density. Right now we can't (updating one field updates the others too). * There is always this issue of precision with pixel density vs. pixel dimensions because we don't necessarily find the same values when computing from one side to another because of lack of precision and this confuses people. * Finally there is the question of multi-page documents (e.g. PDF) where the chosen dimensions are the document dimensions whereas each page may have a different size which has to be recomputed independently and this got me off-by-one errors. I think I'll need to review a bit the logic, but I'll do once I've ported all the vector format load plug-ins first to see the most common usages.
2024-04-24 04:27:26 +08:00
/* GIMP - The GNU Image Manipulation Program
* Copyright (C) 1995 Spencer Kimball and Peter Mattis
*
* gimpvectorloadproceduredialog.c
* Copyright (C) 2024 Jehan
*
* 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 3 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, see <https://www.gnu.org/licenses/>.
*/
#include "config.h"
#include <gegl.h>
#include <gtk/gtk.h>
#include "libgimpwidgets/gimpwidgets.h"
#include "gimp.h"
#include "gimpui.h"
#include "gimpvectorloadproceduredialog.h"
#include "gimpresolutionentry-private.h"
#include "libgimp-intl.h"
struct _GimpVectorLoadProcedureDialogPrivate
{
/* TODO: add thumbnail support from the file. */
GFile *file;
};
libgimp: new fill_start() and fill_end() class method for GimpProcedureDialog. Instead of filling default GUI for a specific type of plug-in procedure in fill_list(), we add 2 methods: * fill_start() is ensured to run once (and only once) before any fill_list() code runs. * fill_end() is ensured to run once (and only once) after all fill_list() ran. This takes care of 2 kind of GUI bugs which we could have: 1. First if no explicit fill were run (i.e. neither gimp_procedure_dialog_fill() nor gimp_procedure_dialog_fill_list() were ever run), then the default interface would not be added to the dialog. Yet this case could happen when we don't want anything else but the default GUI (this will be the case in the upcoming file-wmf-load GUI). 2. Second if at the opposite, you fill several times fill functions (I hadn't thought of this, but noticed some already started to do this in our ported plug-ins), we obviously don't want the default GUI to be added several times either.
2024-04-24 20:00:54 +08:00
static void gimp_vector_load_procedure_dialog_fill_list (GimpProcedureDialog *dialog,
GimpProcedure *procedure,
GimpProcedureConfig *config,
GList *properties);
static void gimp_vector_load_procedure_dialog_fill_start (GimpProcedureDialog *dialog,
GimpProcedure *procedure,
GimpProcedureConfig *config);
libgimp: new GimpVectorLoadProcedureDialog widget. As expected, it is made to reuse shared code for every GimpVectorLoadProcedure. In particular, they all need to choose dimensions to load at, so we are sharing a same GimpResolutionEntry widget logic everywhere now. I am in fact still very unsure about the code logic for this widget by the way for these reasons: * It still puts too much emphasis on the "resolution" (pixel density) part, which makes people believe it's important, while they should in fact choose the pixel dimensions most of the time and not care about the pixel density. * Right now we can't break ratio (which in fact was already impossible in most vector format plug-ins we had). Do we want to add a chain and allow this? * If we consider the pixel density as the one we want to set the document with (which may not be the same thing as the one from when we load the document), we also want to break link between width/height dimensions and pixel density. Right now we can't (updating one field updates the others too). * There is always this issue of precision with pixel density vs. pixel dimensions because we don't necessarily find the same values when computing from one side to another because of lack of precision and this confuses people. * Finally there is the question of multi-page documents (e.g. PDF) where the chosen dimensions are the document dimensions whereas each page may have a different size which has to be recomputed independently and this got me off-by-one errors. I think I'll need to review a bit the logic, but I'll do once I've ported all the vector format load plug-ins first to see the most common usages.
2024-04-24 04:27:26 +08:00
G_DEFINE_TYPE_WITH_PRIVATE (GimpVectorLoadProcedureDialog, gimp_vector_load_procedure_dialog, GIMP_TYPE_PROCEDURE_DIALOG)
#define parent_class gimp_vector_load_procedure_dialog_parent_class
static void
gimp_vector_load_procedure_dialog_class_init (GimpVectorLoadProcedureDialogClass *klass)
{
GimpProcedureDialogClass *proc_dialog_class;
proc_dialog_class = GIMP_PROCEDURE_DIALOG_CLASS (klass);
libgimp: new fill_start() and fill_end() class method for GimpProcedureDialog. Instead of filling default GUI for a specific type of plug-in procedure in fill_list(), we add 2 methods: * fill_start() is ensured to run once (and only once) before any fill_list() code runs. * fill_end() is ensured to run once (and only once) after all fill_list() ran. This takes care of 2 kind of GUI bugs which we could have: 1. First if no explicit fill were run (i.e. neither gimp_procedure_dialog_fill() nor gimp_procedure_dialog_fill_list() were ever run), then the default interface would not be added to the dialog. Yet this case could happen when we don't want anything else but the default GUI (this will be the case in the upcoming file-wmf-load GUI). 2. Second if at the opposite, you fill several times fill functions (I hadn't thought of this, but noticed some already started to do this in our ported plug-ins), we obviously don't want the default GUI to be added several times either.
2024-04-24 20:00:54 +08:00
proc_dialog_class->fill_start = gimp_vector_load_procedure_dialog_fill_start;
proc_dialog_class->fill_list = gimp_vector_load_procedure_dialog_fill_list;
libgimp: new GimpVectorLoadProcedureDialog widget. As expected, it is made to reuse shared code for every GimpVectorLoadProcedure. In particular, they all need to choose dimensions to load at, so we are sharing a same GimpResolutionEntry widget logic everywhere now. I am in fact still very unsure about the code logic for this widget by the way for these reasons: * It still puts too much emphasis on the "resolution" (pixel density) part, which makes people believe it's important, while they should in fact choose the pixel dimensions most of the time and not care about the pixel density. * Right now we can't break ratio (which in fact was already impossible in most vector format plug-ins we had). Do we want to add a chain and allow this? * If we consider the pixel density as the one we want to set the document with (which may not be the same thing as the one from when we load the document), we also want to break link between width/height dimensions and pixel density. Right now we can't (updating one field updates the others too). * There is always this issue of precision with pixel density vs. pixel dimensions because we don't necessarily find the same values when computing from one side to another because of lack of precision and this confuses people. * Finally there is the question of multi-page documents (e.g. PDF) where the chosen dimensions are the document dimensions whereas each page may have a different size which has to be recomputed independently and this got me off-by-one errors. I think I'll need to review a bit the logic, but I'll do once I've ported all the vector format load plug-ins first to see the most common usages.
2024-04-24 04:27:26 +08:00
}
static void
gimp_vector_load_procedure_dialog_init (GimpVectorLoadProcedureDialog *dialog)
{
dialog->priv = gimp_vector_load_procedure_dialog_get_instance_private (dialog);
dialog->priv->file = NULL;
libgimp: new fill_start() and fill_end() class method for GimpProcedureDialog. Instead of filling default GUI for a specific type of plug-in procedure in fill_list(), we add 2 methods: * fill_start() is ensured to run once (and only once) before any fill_list() code runs. * fill_end() is ensured to run once (and only once) after all fill_list() ran. This takes care of 2 kind of GUI bugs which we could have: 1. First if no explicit fill were run (i.e. neither gimp_procedure_dialog_fill() nor gimp_procedure_dialog_fill_list() were ever run), then the default interface would not be added to the dialog. Yet this case could happen when we don't want anything else but the default GUI (this will be the case in the upcoming file-wmf-load GUI). 2. Second if at the opposite, you fill several times fill functions (I hadn't thought of this, but noticed some already started to do this in our ported plug-ins), we obviously don't want the default GUI to be added several times either.
2024-04-24 20:00:54 +08:00
}
static void
gimp_vector_load_procedure_dialog_fill_start (GimpProcedureDialog *dialog,
GimpProcedure *procedure,
GimpProcedureConfig *config)
{
GtkWidget *content_area;
GtkWidget *res_entry;
content_area = gtk_dialog_get_content_area (GTK_DIALOG (dialog));
/* Resolution */
res_entry = gimp_prop_resolution_entry_new (G_OBJECT (config),
"width", "height", "pixel-density",
"physical-unit");
gtk_box_pack_start (GTK_BOX (content_area), res_entry, FALSE, FALSE, 0);
gtk_widget_show (res_entry);
GIMP_PROCEDURE_DIALOG_CLASS (parent_class)->fill_start (dialog, procedure, config);
libgimp: new GimpVectorLoadProcedureDialog widget. As expected, it is made to reuse shared code for every GimpVectorLoadProcedure. In particular, they all need to choose dimensions to load at, so we are sharing a same GimpResolutionEntry widget logic everywhere now. I am in fact still very unsure about the code logic for this widget by the way for these reasons: * It still puts too much emphasis on the "resolution" (pixel density) part, which makes people believe it's important, while they should in fact choose the pixel dimensions most of the time and not care about the pixel density. * Right now we can't break ratio (which in fact was already impossible in most vector format plug-ins we had). Do we want to add a chain and allow this? * If we consider the pixel density as the one we want to set the document with (which may not be the same thing as the one from when we load the document), we also want to break link between width/height dimensions and pixel density. Right now we can't (updating one field updates the others too). * There is always this issue of precision with pixel density vs. pixel dimensions because we don't necessarily find the same values when computing from one side to another because of lack of precision and this confuses people. * Finally there is the question of multi-page documents (e.g. PDF) where the chosen dimensions are the document dimensions whereas each page may have a different size which has to be recomputed independently and this got me off-by-one errors. I think I'll need to review a bit the logic, but I'll do once I've ported all the vector format load plug-ins first to see the most common usages.
2024-04-24 04:27:26 +08:00
}
static void
gimp_vector_load_procedure_dialog_fill_list (GimpProcedureDialog *dialog,
GimpProcedure *procedure,
GimpProcedureConfig *config,
GList *properties)
{
libgimp: new fill_start() and fill_end() class method for GimpProcedureDialog. Instead of filling default GUI for a specific type of plug-in procedure in fill_list(), we add 2 methods: * fill_start() is ensured to run once (and only once) before any fill_list() code runs. * fill_end() is ensured to run once (and only once) after all fill_list() ran. This takes care of 2 kind of GUI bugs which we could have: 1. First if no explicit fill were run (i.e. neither gimp_procedure_dialog_fill() nor gimp_procedure_dialog_fill_list() were ever run), then the default interface would not be added to the dialog. Yet this case could happen when we don't want anything else but the default GUI (this will be the case in the upcoming file-wmf-load GUI). 2. Second if at the opposite, you fill several times fill functions (I hadn't thought of this, but noticed some already started to do this in our ported plug-ins), we obviously don't want the default GUI to be added several times either.
2024-04-24 20:00:54 +08:00
GList *properties2 = NULL;
GList *iter;
libgimp: new GimpVectorLoadProcedureDialog widget. As expected, it is made to reuse shared code for every GimpVectorLoadProcedure. In particular, they all need to choose dimensions to load at, so we are sharing a same GimpResolutionEntry widget logic everywhere now. I am in fact still very unsure about the code logic for this widget by the way for these reasons: * It still puts too much emphasis on the "resolution" (pixel density) part, which makes people believe it's important, while they should in fact choose the pixel dimensions most of the time and not care about the pixel density. * Right now we can't break ratio (which in fact was already impossible in most vector format plug-ins we had). Do we want to add a chain and allow this? * If we consider the pixel density as the one we want to set the document with (which may not be the same thing as the one from when we load the document), we also want to break link between width/height dimensions and pixel density. Right now we can't (updating one field updates the others too). * There is always this issue of precision with pixel density vs. pixel dimensions because we don't necessarily find the same values when computing from one side to another because of lack of precision and this confuses people. * Finally there is the question of multi-page documents (e.g. PDF) where the chosen dimensions are the document dimensions whereas each page may have a different size which has to be recomputed independently and this got me off-by-one errors. I think I'll need to review a bit the logic, but I'll do once I've ported all the vector format load plug-ins first to see the most common usages.
2024-04-24 04:27:26 +08:00
libgimp: new fill_start() and fill_end() class method for GimpProcedureDialog. Instead of filling default GUI for a specific type of plug-in procedure in fill_list(), we add 2 methods: * fill_start() is ensured to run once (and only once) before any fill_list() code runs. * fill_end() is ensured to run once (and only once) after all fill_list() ran. This takes care of 2 kind of GUI bugs which we could have: 1. First if no explicit fill were run (i.e. neither gimp_procedure_dialog_fill() nor gimp_procedure_dialog_fill_list() were ever run), then the default interface would not be added to the dialog. Yet this case could happen when we don't want anything else but the default GUI (this will be the case in the upcoming file-wmf-load GUI). 2. Second if at the opposite, you fill several times fill functions (I hadn't thought of this, but noticed some already started to do this in our ported plug-ins), we obviously don't want the default GUI to be added several times either.
2024-04-24 20:00:54 +08:00
for (iter = properties; iter; iter = iter->next)
libgimp: new GimpVectorLoadProcedureDialog widget. As expected, it is made to reuse shared code for every GimpVectorLoadProcedure. In particular, they all need to choose dimensions to load at, so we are sharing a same GimpResolutionEntry widget logic everywhere now. I am in fact still very unsure about the code logic for this widget by the way for these reasons: * It still puts too much emphasis on the "resolution" (pixel density) part, which makes people believe it's important, while they should in fact choose the pixel dimensions most of the time and not care about the pixel density. * Right now we can't break ratio (which in fact was already impossible in most vector format plug-ins we had). Do we want to add a chain and allow this? * If we consider the pixel density as the one we want to set the document with (which may not be the same thing as the one from when we load the document), we also want to break link between width/height dimensions and pixel density. Right now we can't (updating one field updates the others too). * There is always this issue of precision with pixel density vs. pixel dimensions because we don't necessarily find the same values when computing from one side to another because of lack of precision and this confuses people. * Finally there is the question of multi-page documents (e.g. PDF) where the chosen dimensions are the document dimensions whereas each page may have a different size which has to be recomputed independently and this got me off-by-one errors. I think I'll need to review a bit the logic, but I'll do once I've ported all the vector format load plug-ins first to see the most common usages.
2024-04-24 04:27:26 +08:00
{
libgimp: new fill_start() and fill_end() class method for GimpProcedureDialog. Instead of filling default GUI for a specific type of plug-in procedure in fill_list(), we add 2 methods: * fill_start() is ensured to run once (and only once) before any fill_list() code runs. * fill_end() is ensured to run once (and only once) after all fill_list() ran. This takes care of 2 kind of GUI bugs which we could have: 1. First if no explicit fill were run (i.e. neither gimp_procedure_dialog_fill() nor gimp_procedure_dialog_fill_list() were ever run), then the default interface would not be added to the dialog. Yet this case could happen when we don't want anything else but the default GUI (this will be the case in the upcoming file-wmf-load GUI). 2. Second if at the opposite, you fill several times fill functions (I hadn't thought of this, but noticed some already started to do this in our ported plug-ins), we obviously don't want the default GUI to be added several times either.
2024-04-24 20:00:54 +08:00
gchar *propname = iter->data;
if (g_strcmp0 (propname, "width") == 0 ||
g_strcmp0 (propname, "height") == 0 ||
g_strcmp0 (propname, "keep-ratio") == 0 ||
g_strcmp0 (propname, "prefer-native-dimensions") == 0 ||
g_strcmp0 (propname, "pixel-density") == 0 ||
g_strcmp0 (propname, "physical-unit") == 0)
/* Ignoring the standards args which are being handled by fill_start(). */
continue;
properties2 = g_list_prepend (properties2, propname);
libgimp: new GimpVectorLoadProcedureDialog widget. As expected, it is made to reuse shared code for every GimpVectorLoadProcedure. In particular, they all need to choose dimensions to load at, so we are sharing a same GimpResolutionEntry widget logic everywhere now. I am in fact still very unsure about the code logic for this widget by the way for these reasons: * It still puts too much emphasis on the "resolution" (pixel density) part, which makes people believe it's important, while they should in fact choose the pixel dimensions most of the time and not care about the pixel density. * Right now we can't break ratio (which in fact was already impossible in most vector format plug-ins we had). Do we want to add a chain and allow this? * If we consider the pixel density as the one we want to set the document with (which may not be the same thing as the one from when we load the document), we also want to break link between width/height dimensions and pixel density. Right now we can't (updating one field updates the others too). * There is always this issue of precision with pixel density vs. pixel dimensions because we don't necessarily find the same values when computing from one side to another because of lack of precision and this confuses people. * Finally there is the question of multi-page documents (e.g. PDF) where the chosen dimensions are the document dimensions whereas each page may have a different size which has to be recomputed independently and this got me off-by-one errors. I think I'll need to review a bit the logic, but I'll do once I've ported all the vector format load plug-ins first to see the most common usages.
2024-04-24 04:27:26 +08:00
}
libgimp: new fill_start() and fill_end() class method for GimpProcedureDialog. Instead of filling default GUI for a specific type of plug-in procedure in fill_list(), we add 2 methods: * fill_start() is ensured to run once (and only once) before any fill_list() code runs. * fill_end() is ensured to run once (and only once) after all fill_list() ran. This takes care of 2 kind of GUI bugs which we could have: 1. First if no explicit fill were run (i.e. neither gimp_procedure_dialog_fill() nor gimp_procedure_dialog_fill_list() were ever run), then the default interface would not be added to the dialog. Yet this case could happen when we don't want anything else but the default GUI (this will be the case in the upcoming file-wmf-load GUI). 2. Second if at the opposite, you fill several times fill functions (I hadn't thought of this, but noticed some already started to do this in our ported plug-ins), we obviously don't want the default GUI to be added several times either.
2024-04-24 20:00:54 +08:00
properties2 = g_list_reverse (properties2);
GIMP_PROCEDURE_DIALOG_CLASS (parent_class)->fill_list (dialog, procedure, config, properties2);
g_list_free (properties2);
libgimp: new GimpVectorLoadProcedureDialog widget. As expected, it is made to reuse shared code for every GimpVectorLoadProcedure. In particular, they all need to choose dimensions to load at, so we are sharing a same GimpResolutionEntry widget logic everywhere now. I am in fact still very unsure about the code logic for this widget by the way for these reasons: * It still puts too much emphasis on the "resolution" (pixel density) part, which makes people believe it's important, while they should in fact choose the pixel dimensions most of the time and not care about the pixel density. * Right now we can't break ratio (which in fact was already impossible in most vector format plug-ins we had). Do we want to add a chain and allow this? * If we consider the pixel density as the one we want to set the document with (which may not be the same thing as the one from when we load the document), we also want to break link between width/height dimensions and pixel density. Right now we can't (updating one field updates the others too). * There is always this issue of precision with pixel density vs. pixel dimensions because we don't necessarily find the same values when computing from one side to another because of lack of precision and this confuses people. * Finally there is the question of multi-page documents (e.g. PDF) where the chosen dimensions are the document dimensions whereas each page may have a different size which has to be recomputed independently and this got me off-by-one errors. I think I'll need to review a bit the logic, but I'll do once I've ported all the vector format load plug-ins first to see the most common usages.
2024-04-24 04:27:26 +08:00
}
/* Public Functions */
GtkWidget *
gimp_vector_load_procedure_dialog_new (GimpVectorLoadProcedure *procedure,
GimpProcedureConfig *config,
GFile *file)
{
GtkWidget *dialog;
gchar *title;
const gchar *format_name;
const gchar *help_id;
gboolean use_header_bar;
g_return_val_if_fail (GIMP_IS_VECTOR_LOAD_PROCEDURE (procedure), NULL);
g_return_val_if_fail (GIMP_IS_PROCEDURE_CONFIG (config), NULL);
g_return_val_if_fail (gimp_procedure_config_get_procedure (config) ==
GIMP_PROCEDURE (procedure), NULL);
/*g_return_val_if_fail (G_IS_FILE (file), NULL);*/
format_name = gimp_file_procedure_get_format_name (GIMP_FILE_PROCEDURE (procedure));
if (! format_name)
{
g_critical ("%s: no format name set on file procedure '%s'. "
"Set one with gimp_file_procedure_set_format_name()",
G_STRFUNC,
gimp_procedure_get_name (GIMP_PROCEDURE (procedure)));
return NULL;
}
/* TRANSLATORS: %s will be a format name, e.g. "PNG" or "JPEG". */
title = g_strdup_printf (_("Load %s Image"), format_name);
help_id = gimp_procedure_get_help_id (GIMP_PROCEDURE (procedure));
g_object_get (gtk_settings_get_default (),
"gtk-dialogs-use-header", &use_header_bar,
NULL);
dialog = g_object_new (GIMP_TYPE_VECTOR_LOAD_PROCEDURE_DIALOG,
"procedure", procedure,
"config", config,
"title", title,
"help-func", gimp_standard_help_func,
"help-id", help_id,
"use-header-bar", use_header_bar,
NULL);
GIMP_VECTOR_LOAD_PROCEDURE_DIALOG (dialog)->priv->file = file;
g_free (title);
return dialog;
}