GNOME Bugzilla – Bug 754452
Refactoring of GimpFileDialog
Last modified: 2018-05-24 15:36:44 UTC
So I thought one of the major setback for the save/export troll is that people have a hard time seeing how it makes sense since all the dialogs are the same. I have refactored GimpFileDialog as a parent class which should not be created as such, but always by creating child classes. I have created 3 children: GimpOpenDialog, GimpSaveDialog and GimpExportDialog. This allows us to have a much clearer code at what is common to all our file dialogs (to have a similar look) and what is specific, instead of drowning ourselves in hundreds of if/else statements for every subcase. See branch origin/GimpFileDialog-refactoring that I just pushed. - Commit 3bfb605 is the base refactoring (no change of functionnality). - Commit 0188b30: I made the file dialog state management into a class method, allowing each child dialog to save different kind of data in a single session. As an example, the GimpSaveDialog now saves the usage of the compatibility mode (if an image has never been saved yet, it will be checked by default if we checked it in a previous save; otherwise the per-image compatibility mode is used). - Commit f31767b: I added a "Scale Image for Export" feature into the GimpExportDialog, allowing users to rescale their exported image (making it really obvious what is the different between save and export by the way) without touching the original. This is also the start of what people call a "Save for Web" feature, I believe. I am already thinking of various other features (crop, color space change, even any GEGL op could be set at export time).
Created attachment 310489 [details] Scale for export Oh and a small screenshot to show the scale feature (shrink by default, you can expand it, same as you can expand the "Select File Type") in the Export dialog.
Looks nice, but should make better use of screen space - the width/height on the left, PPI on the right.
> Looks nice, but should make better use of screen space - the width/height on the left, PPI on the right. I actually reused an existing widget (the one from the "Scale Image" dialog, which explains why it's basically the same UI), though it would be quite easy to change. Why I didn't care about the space waste though (obviously I noticed it too), was that I imagine we would have other features and they would then go on the right. This is more like a first step towards the save/export redesigning than a finale UI.
First 2 commits pushed: commit 829f5ec3d686764fe738fd6b6d2c506995f010a9 Author: Jehan <jehan@girinstud.io> Date: Tue Sep 1 13:49:59 2015 +0200 app: GimpFileDialog state saving now implemented as a class method. By default, it only saves the current file filter, but it allows a child to implement its own state. It has been implemented by GimpSaveDialog to save the preferred compatibility mode as well. commit b17e1b1cfc1b80e9bd0b6d3ecd385b0d71329718 Author: Jehan <jehan@girinstud.io> Date: Mon Aug 31 20:57:37 2015 +0200 app: split GimpFileDialog into Gimp(Open|Save|Export)Dialog subclasses. The code refactoring allows better readability which will allow in turn to add more complex specific features making good use of the save/export split concept. Last commit (now commit 9b20d97) is on hold until some more thinking of how to better do things.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/749.