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

47 lines
1.8 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
*
* gimpexportproceduredialog.h
* 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/>.
*/
#if !defined (__GIMP_UI_H_INSIDE__) && !defined (GIMP_COMPILATION)
#error "Only <libgimp/gimpui.h> can be included directly."
#endif
#ifndef __GIMP_VECTOR_LOAD_PROCEDURE_DIALOG_H__
#define __GIMP_VECTOR_LOAD_PROCEDURE_DIALOG_H__
G_BEGIN_DECLS
/* For information look into the C source or the html documentation */
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
#define GIMP_TYPE_VECTOR_LOAD_PROCEDURE_DIALOG (gimp_vector_load_procedure_dialog_get_type ())
G_DECLARE_FINAL_TYPE (GimpVectorLoadProcedureDialog, gimp_vector_load_procedure_dialog, GIMP, VECTOR_LOAD_PROCEDURE_DIALOG, GimpProcedureDialog)
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
GtkWidget * gimp_vector_load_procedure_dialog_new (GimpVectorLoadProcedure *procedure,
GimpProcedureConfig *config,
GimpVectorLoadData *extracted_data,
GFile *file);
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_END_DECLS
#endif /* __GIMP_VECTOR_LOAD_PROCEDURE_DIALOG_H__ */