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

352 lines
15 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"
libgimp, libgimpwidgets: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for GimpProcedureDialog… … and its subclasses, as well as for GimpDialog.
2024-07-13 17:36:05 +08:00
struct _GimpVectorLoadProcedureDialog
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, libgimpwidgets: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for GimpProcedureDialog… … and its subclasses, as well as for GimpDialog.
2024-07-13 17:36:05 +08:00
GimpProcedureDialog parent_instance;
GFile *file;
GimpVectorLoadData *extracted_data;
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, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
static void gimp_vector_load_procedure_dialog_fill_start (GimpProcedureDialog *dialog,
GimpProcedure *procedure,
GimpProcedureConfig *config);
static void gimp_vector_load_procedure_dialog_fill_list (GimpProcedureDialog *dialog,
GimpProcedure *procedure,
GimpProcedureConfig *config,
GList *properties);
static void gimp_vector_load_procedure_dialog_preview_allocate (GtkWidget *gtk_image,
GtkAllocation *allocation,
GimpVectorLoadProcedureDialog *dialog);
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, libgimpwidgets: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for GimpProcedureDialog… … and its subclasses, as well as for GimpDialog.
2024-07-13 17:36:05 +08:00
G_DEFINE_TYPE (GimpVectorLoadProcedureDialog, gimp_vector_load_procedure_dialog, GIMP_TYPE_PROCEDURE_DIALOG)
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
#define parent_class gimp_vector_load_procedure_dialog_parent_class
static void
gimp_vector_load_procedure_dialog_class_init (GimpVectorLoadProcedureDialogClass *klass)
{
libgimp, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
GimpProcedureDialogClass *proc_dialog_class = GIMP_PROCEDURE_DIALOG_CLASS (klass);
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
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)
{
libgimp, libgimpwidgets: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for GimpProcedureDialog… … and its subclasses, as well as for GimpDialog.
2024-07-13 17:36:05 +08:00
dialog->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)
{
libgimp, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
GimpVectorLoadProcedureDialog *vector_dialog = GIMP_VECTOR_LOAD_PROCEDURE_DIALOG (dialog);
GtkWidget *content_area;
GtkWidget *top_hbox;
GtkWidget *main_vbox;
GtkWidget *res_entry;
GtkWidget *label;
gchar *text = NULL;
gchar *markup = 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
content_area = gtk_dialog_get_content_area (GTK_DIALOG (dialog));
libgimp, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
main_vbox = gtk_box_new (GTK_ORIENTATION_VERTICAL, 2);
gtk_box_pack_start (GTK_BOX (content_area), main_vbox, FALSE, FALSE, 0);
gtk_widget_show (main_vbox);
top_hbox = gtk_box_new (GTK_ORIENTATION_HORIZONTAL, 4);
gtk_box_pack_start (GTK_BOX (main_vbox), top_hbox, FALSE, FALSE, 0);
gtk_widget_show (top_hbox);
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
/* Resolution */
res_entry = gimp_prop_resolution_entry_new (G_OBJECT (config),
"width", "height", "pixel-density",
"physical-unit");
libgimp, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
gtk_box_pack_start (GTK_BOX (top_hbox), res_entry, FALSE, FALSE, 0);
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
gtk_widget_show (res_entry);
libgimp, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
/* Preview */
libgimp, libgimpwidgets: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for GimpProcedureDialog… … and its subclasses, as well as for GimpDialog.
2024-07-13 17:36:05 +08:00
if (vector_dialog->file)
libgimp, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
{
GtkWidget *image;
image = gtk_image_new ();
g_signal_connect (image, "size-allocate",
G_CALLBACK (gimp_vector_load_procedure_dialog_preview_allocate),
dialog);
gtk_box_pack_start (GTK_BOX (top_hbox), image, FALSE, FALSE, 0);
gtk_widget_show (image);
}
libgimp, libgimpwidgets: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for GimpProcedureDialog… … and its subclasses, as well as for GimpDialog.
2024-07-13 17:36:05 +08:00
if (vector_dialog->extracted_data)
libgimp, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
{
libgimp, libgimpwidgets: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for GimpProcedureDialog… … and its subclasses, as well as for GimpDialog.
2024-07-13 17:36:05 +08:00
if (vector_dialog->extracted_data->exact_width && vector_dialog->extracted_data->exact_height)
libgimp, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
{
/* TRANSLATORS: the %s is a vector format name, e.g. "SVG" or "PDF",
* followed by 2D dimensions with unit, e.g. "200 inch x 400 inch"
*/
text = g_strdup_printf (_("Source %s file size: %%.%df %s × %%.%df %s"),
gimp_file_procedure_get_format_name (GIMP_FILE_PROCEDURE (procedure)),
libgimp, libgimpwidgets: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for GimpProcedureDialog… … and its subclasses, as well as for GimpDialog.
2024-07-13 17:36:05 +08:00
gimp_unit_get_digits (vector_dialog->extracted_data->width_unit),
gimp_unit_get_abbreviation (vector_dialog->extracted_data->width_unit),
gimp_unit_get_digits (vector_dialog->extracted_data->height_unit),
gimp_unit_get_abbreviation (vector_dialog->extracted_data->height_unit));
markup = g_strdup_printf (text, vector_dialog->extracted_data->width, vector_dialog->extracted_data->height);
libgimp, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
}
libgimp, libgimpwidgets: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for GimpProcedureDialog… … and its subclasses, as well as for GimpDialog.
2024-07-13 17:36:05 +08:00
else if (vector_dialog->extracted_data->correct_ratio)
libgimp, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
{
gdouble ratio_width = 0.0;
gint ratio_width_digits = 0;
gdouble ratio_height = 0.0;
gint ratio_height_digits = 0;
libgimp, libgimpwidgets: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for GimpProcedureDialog… … and its subclasses, as well as for GimpDialog.
2024-07-13 17:36:05 +08:00
if (vector_dialog->extracted_data->width_unit == vector_dialog->extracted_data->height_unit)
libgimp, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
{
libgimp, libgimpwidgets: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for GimpProcedureDialog… … and its subclasses, as well as for GimpDialog.
2024-07-13 17:36:05 +08:00
ratio_width = vector_dialog->extracted_data->width;
ratio_height = vector_dialog->extracted_data->height;
Issue #8900 and #9923: reimplementing GimpUnit as a proper class. This fixes all our GObject Introspection issues with GimpUnit which was both an enum and an int-derived type of user-defined units *completing* the enum values. GIR clearly didn't like this! Now GimpUnit is a proper class and units are unique objects, allowing to compare them with an identity test (i.e. `unit == gimp_unit_pixel ()` tells us if unit is the pixel unit or not), which makes it easy to use, just like with int, yet adding also methods, making for nicer introspected API. As an aside, this also fixes #10738, by having all the built-in units retrievable even if libgimpbase had not been properly initialized with gimp_base_init(). I haven't checked in details how GIR works to introspect, but it looks like it loads the library to inspect and runs functions, hence triggering some CRITICALS because virtual methods (supposed to be initialized with gimp_base_init() run by libgimp) are not set. This new code won't trigger any critical because the vtable method are now not necessary, at least for all built-in units. Note that GimpUnit is still in libgimpbase. It could have been moved to libgimp in order to avoid any virtual method table (since we need to keep core and libgimp side's units in sync, PDB is required), but too many libgimpwidgets widgets were already using GimpUnit. And technically most of GimpUnit logic doesn't require PDB (only the creation/sync part). This is one of the reasons why user-created GimpUnit list is handled and stored differently from other types of objects. Globally this simplifies the code a lot too and we don't need separate implementations of various utils for core and libgimp, which means less prone to errors.
2024-07-26 02:55:21 +08:00
if (vector_dialog->extracted_data->width_unit == gimp_unit_pixel () ||
vector_dialog->extracted_data->width_unit == gimp_unit_percent ())
libgimp, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
ratio_width_digits = ratio_height_digits = 0;
else
libgimp, libgimpwidgets: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for GimpProcedureDialog… … and its subclasses, as well as for GimpDialog.
2024-07-13 17:36:05 +08:00
ratio_width_digits = ratio_height_digits = gimp_unit_get_digits (vector_dialog->extracted_data->width_unit);
libgimp, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
}
Issue #8900 and #9923: reimplementing GimpUnit as a proper class. This fixes all our GObject Introspection issues with GimpUnit which was both an enum and an int-derived type of user-defined units *completing* the enum values. GIR clearly didn't like this! Now GimpUnit is a proper class and units are unique objects, allowing to compare them with an identity test (i.e. `unit == gimp_unit_pixel ()` tells us if unit is the pixel unit or not), which makes it easy to use, just like with int, yet adding also methods, making for nicer introspected API. As an aside, this also fixes #10738, by having all the built-in units retrievable even if libgimpbase had not been properly initialized with gimp_base_init(). I haven't checked in details how GIR works to introspect, but it looks like it loads the library to inspect and runs functions, hence triggering some CRITICALS because virtual methods (supposed to be initialized with gimp_base_init() run by libgimp) are not set. This new code won't trigger any critical because the vtable method are now not necessary, at least for all built-in units. Note that GimpUnit is still in libgimpbase. It could have been moved to libgimp in order to avoid any virtual method table (since we need to keep core and libgimp side's units in sync, PDB is required), but too many libgimpwidgets widgets were already using GimpUnit. And technically most of GimpUnit logic doesn't require PDB (only the creation/sync part). This is one of the reasons why user-created GimpUnit list is handled and stored differently from other types of objects. Globally this simplifies the code a lot too and we don't need separate implementations of various utils for core and libgimp, which means less prone to errors.
2024-07-26 02:55:21 +08:00
else if (vector_dialog->extracted_data->width_unit != gimp_unit_pixel () && vector_dialog->extracted_data->height_unit != gimp_unit_pixel () &&
vector_dialog->extracted_data->width_unit != gimp_unit_percent () && vector_dialog->extracted_data->height_unit != gimp_unit_percent ())
libgimp, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
{
libgimp, libgimpwidgets: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for GimpProcedureDialog… … and its subclasses, as well as for GimpDialog.
2024-07-13 17:36:05 +08:00
ratio_width = vector_dialog->extracted_data->width / gimp_unit_get_factor (vector_dialog->extracted_data->width_unit);
ratio_height = vector_dialog->extracted_data->height / gimp_unit_get_factor (vector_dialog->extracted_data->height_unit);
libgimp, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
Issue #8900 and #9923: reimplementing GimpUnit as a proper class. This fixes all our GObject Introspection issues with GimpUnit which was both an enum and an int-derived type of user-defined units *completing* the enum values. GIR clearly didn't like this! Now GimpUnit is a proper class and units are unique objects, allowing to compare them with an identity test (i.e. `unit == gimp_unit_pixel ()` tells us if unit is the pixel unit or not), which makes it easy to use, just like with int, yet adding also methods, making for nicer introspected API. As an aside, this also fixes #10738, by having all the built-in units retrievable even if libgimpbase had not been properly initialized with gimp_base_init(). I haven't checked in details how GIR works to introspect, but it looks like it loads the library to inspect and runs functions, hence triggering some CRITICALS because virtual methods (supposed to be initialized with gimp_base_init() run by libgimp) are not set. This new code won't trigger any critical because the vtable method are now not necessary, at least for all built-in units. Note that GimpUnit is still in libgimpbase. It could have been moved to libgimp in order to avoid any virtual method table (since we need to keep core and libgimp side's units in sync, PDB is required), but too many libgimpwidgets widgets were already using GimpUnit. And technically most of GimpUnit logic doesn't require PDB (only the creation/sync part). This is one of the reasons why user-created GimpUnit list is handled and stored differently from other types of objects. Globally this simplifies the code a lot too and we don't need separate implementations of various utils for core and libgimp, which means less prone to errors.
2024-07-26 02:55:21 +08:00
ratio_width_digits = ratio_height_digits = gimp_unit_get_digits (gimp_unit_inch ());
libgimp, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
}
if (ratio_width != 0.0 && ratio_height != 0.0)
{
/* TRANSLATOR: the %s is a vector format name, e.g. "SVG" or "PDF". */
text = g_strdup_printf (_("Source %s file's aspect ratio: %%.%df × %%.%df"),
gimp_file_procedure_get_format_name (GIMP_FILE_PROCEDURE (procedure)),
ratio_width_digits, ratio_height_digits);
markup = g_strdup_printf (text, ratio_width, ratio_height);
}
}
libgimp, libgimpwidgets: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for GimpProcedureDialog… … and its subclasses, as well as for GimpDialog.
2024-07-13 17:36:05 +08:00
else if (vector_dialog->extracted_data->width != 0.0 && vector_dialog->extracted_data->height != 0.0)
libgimp, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
{
text = g_strdup_printf (_("Approximated source %s file size: %%.%df %s × %%.%df %s"),
gimp_file_procedure_get_format_name (GIMP_FILE_PROCEDURE (procedure)),
libgimp, libgimpwidgets: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for GimpProcedureDialog… … and its subclasses, as well as for GimpDialog.
2024-07-13 17:36:05 +08:00
gimp_unit_get_digits (vector_dialog->extracted_data->width_unit),
gimp_unit_get_abbreviation (vector_dialog->extracted_data->width_unit),
gimp_unit_get_digits (vector_dialog->extracted_data->height_unit),
gimp_unit_get_abbreviation (vector_dialog->extracted_data->height_unit));
markup = g_strdup_printf (text, vector_dialog->extracted_data->width, vector_dialog->extracted_data->height);
libgimp, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
}
}
if (markup == NULL)
{
/* TRANSLATOR: the %s is a vector format name, e.g. "SVG" or "PDF". */
text = g_strdup_printf (_("The source %s file does not specify a size!"),
gimp_file_procedure_get_format_name (GIMP_FILE_PROCEDURE (procedure)));
markup = g_strdup_printf ("<i>%s</i>", text);
}
label = gtk_label_new (NULL);
gtk_label_set_markup (GTK_LABEL (label), markup);
gtk_label_set_justify (GTK_LABEL (label), GTK_JUSTIFY_CENTER);
gtk_box_pack_start (GTK_BOX (main_vbox), label, TRUE, TRUE, 4);
gtk_widget_show (label);
g_free (text);
g_free (markup);
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
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
}
libgimp, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
static void
gimp_vector_load_procedure_dialog_preview_allocate (GtkWidget *gtk_image,
GtkAllocation *allocation,
GimpVectorLoadProcedureDialog *dialog)
{
libgimp, libgimpwidgets: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for GimpProcedureDialog… … and its subclasses, as well as for GimpDialog.
2024-07-13 17:36:05 +08:00
if (dialog->file)
libgimp, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
{
GimpProcedure *procedure = NULL;
GimpValueArray *retval;
GimpPDBStatusType status;
g_object_get (dialog, "procedure", &procedure, NULL);
retval = gimp_procedure_run (procedure,
libgimp, libgimpwidgets: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for GimpProcedureDialog… … and its subclasses, as well as for GimpDialog.
2024-07-13 17:36:05 +08:00
"file", dialog->file,
"width", allocation->height,
"height", allocation->height,
libgimp, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
"keep-ratio", TRUE,
NULL);
status = g_value_get_enum (gimp_value_array_index (retval, 0));
if (status == GIMP_PDB_SUCCESS)
{
GimpImage *image;
GdkPixbuf *preview;
image = g_value_get_object (gimp_value_array_index (retval, 1));
preview = gimp_image_get_thumbnail (image,
gimp_image_get_width (image),
gimp_image_get_height (image),
GIMP_PIXBUF_SMALL_CHECKS);
gtk_image_set_from_pixbuf (GTK_IMAGE (gtk_image), preview);
gimp_image_delete (image);
}
gimp_value_array_unref (retval);
}
}
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 */
libgimp, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
/**
* gimp_vector_load_procedure_dialog_new:
* @procedure: the associated #GimpVectorLoadProcedure.
* @config: a #GimpProcedureConfig from which properties will be
* turned into widgets.
* @extracted_data: (nullable): the extracted dimensions of the file to load.
* @file: (nullable): a [iface@Gio.File] to load the preview from.
*
* Creates a new dialog for @procedure using widgets generated from
* properties of @config.
*
* @file must be the same vector file which was passed to the
* [callback@Gimp.RunVectorLoadFunc] implementation for your plug-in. If you pass any
* other file, then the preview may be wrong or not showing at all. And it is
* considered a programming error.
*
* As for all #GtkWindow, the returned #GimpProcedureDialog object is
* owned by GTK and its initial reference is stored in an internal list
* of top-level windows. To delete the dialog, call
* gtk_widget_destroy().
*
* Returns: (transfer none): the newly created #GimpVectorLoadProcedureDialog.
*/
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
GtkWidget *
gimp_vector_load_procedure_dialog_new (GimpVectorLoadProcedure *procedure,
GimpProcedureConfig *config,
libgimp, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
GimpVectorLoadData *extracted_data,
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
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);
libgimp, plug-ins: GimpVectorLoadProcedureDialog will have thumbnail and… … native dimensions/ratio display by default. Also adding gimp_vector_load_procedure_extract_dimensions() public function allowing plug-ins to query the native size or ratio of a vector file.
2024-06-09 00:37:38 +08:00
g_return_val_if_fail (file == NULL || G_IS_FILE (file), NULL);
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
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);
libgimp, libgimpwidgets: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for GimpProcedureDialog… … and its subclasses, as well as for GimpDialog.
2024-07-13 17:36:05 +08:00
GIMP_VECTOR_LOAD_PROCEDURE_DIALOG (dialog)->file = file;
GIMP_VECTOR_LOAD_PROCEDURE_DIALOG (dialog)->extracted_data = extracted_data;
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_free (title);
return dialog;
}