[Gimp-developer] [PATCH] Use Glade + GtkBuilder for file-png.c save_dialog()
From: Martin Nordholts mart...@src.gnome.org
As an experiment, use Glade + GtkBuilder for the save dialog in the
PNG plug-in. The layout is as good as identical. Mnemonics work and
strings are still translated.
---
configure.ac |1 +
plug-ins/Makefile.am |1 +
plug-ins/common/file-png.c| 202 ++---
plug-ins/glade/.gitignore |2 +
plug-ins/glade/Makefile.am|6 +
plug-ins/glade/file-png.glade | 226 +
po-plug-ins/POTFILES.in |1 +
7 files changed, 313 insertions(+), 126 deletions(-)
create mode 100644 plug-ins/glade/.gitignore
create mode 100644 plug-ins/glade/Makefile.am
create mode 100644 plug-ins/glade/file-png.glade
diff --git a/configure.ac b/configure.ac
index 6edf057..2d8229c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2004,6 +2004,7 @@ plug-ins/fractal-explorer/examples/Makefile
plug-ins/gfig/Makefile
plug-ins/gfig/gfig-examples/Makefile
plug-ins/gfig/images/Makefile
+plug-ins/glade/Makefile
plug-ins/gimpressionist/Brushes/Makefile
plug-ins/gimpressionist/Makefile
plug-ins/gimpressionist/Paper/Makefile
diff --git a/plug-ins/Makefile.am b/plug-ins/Makefile.am
index fd62823..b045c92 100644
--- a/plug-ins/Makefile.am
+++ b/plug-ins/Makefile.am
@@ -69,6 +69,7 @@ SUBDIRS = \
flame \
fractal-explorer\
gfig\
+ glade \
gimpressionist \
gradient-flare \
help\
diff --git a/plug-ins/common/file-png.c b/plug-ins/common/file-png.c
index 7f7c86f..faaf0fb 100644
--- a/plug-ins/common/file-png.c
+++ b/plug-ins/common/file-png.c
@@ -1768,21 +1768,35 @@ respin_cmap (png_structp pp,
}
+static GtkWidget *
+toggle_button_init (GtkBuilder *builder,
+const gchar *name,
+gboolean initial_value,
+gboolean*value_pointer)
+{
+ GtkWidget *toggle = NULL;
+
+ toggle = GTK_WIDGET (gtk_builder_get_object (builder, name));
+ gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (toggle), initial_value);
+ g_signal_connect (toggle, toggled,
+G_CALLBACK (gimp_toggle_button_update),
+value_pointer);
+
+ return toggle;
+}
+
static gboolean
save_dialog (gint32image_ID,
gboolean alpha)
{
PngSaveGuipg;
GtkWidget*dialog;
- GtkWidget*table;
- GtkWidget*toggle;
- GtkObject*scale;
- GtkWidget*hbox;
- GtkWidget*button;
+ GtkBuilder *builder;
+ gchar*gladefile;
GimpParasite *parasite;
+ /* Dialog init */
dialog = gimp_export_dialog_new (_(PNG), PLUG_IN_BINARY, SAVE_PROC);
-
g_signal_connect (dialog, response,
G_CALLBACK (save_dialog_response),
pg);
@@ -1790,142 +1804,78 @@ save_dialog (gint32image_ID,
G_CALLBACK (gtk_main_quit),
NULL);
- table = gtk_table_new (10, 3, FALSE);
- gtk_table_set_col_spacings (GTK_TABLE (table), 6);
- gtk_table_set_row_spacings (GTK_TABLE (table), 6);
- gtk_container_set_border_width (GTK_CONTAINER (table), 12);
- gtk_box_pack_start (GTK_BOX (gimp_export_dialog_get_content_area (dialog)),
- table, TRUE, TRUE, 0);
- gtk_widget_show (table);
-
- pg.interlaced = toggle =
-gtk_check_button_new_with_mnemonic (_(_Interlacing (Adam7)));
- gtk_table_attach (GTK_TABLE (table), toggle, 0, 3, 0, 1, GTK_FILL, 0, 0, 0);
- gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (toggle),
-pngvals.interlaced);
- gtk_widget_show (toggle);
-
- g_signal_connect (toggle, toggled,
-G_CALLBACK (gimp_toggle_button_update),
-pngvals.interlaced);
-
- pg.bkgd = toggle =
-gtk_check_button_new_with_mnemonic (_(Save _background color));
- gtk_table_attach (GTK_TABLE (table), toggle, 0, 3, 1, 2, GTK_FILL, 0, 0, 0);
- gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (toggle), pngvals.bkgd);
- gtk_widget_show (toggle);
-
- g_signal_connect (toggle, toggled,
-G_CALLBACK (gimp_toggle_button_update), pngvals.bkgd);
-
- pg.gama = toggle = gtk_check_button_new_with_mnemonic (_(Save _gamma));
- gtk_table_attach (GTK_TABLE (table), toggle, 0, 3, 2, 3, GTK_FILL, 0, 0, 0);
- gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (toggle), pngvals.gama);
- gtk_widget_show (toggle);
-
- g_signal_connect (toggle, toggled,
-G_CALLBACK (gimp_toggle_button_update),
-pngvals.gama);
-
- pg.offs = toggle =
-gtk_check_button_new_with_mnemonic (_(Save layer o_ffset));
- gtk_table_attach (GTK_TABLE (table), toggle, 0, 3, 3, 4, GTK_FILL, 0, 0, 0);
- gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (toggle), pngvals.offs);
- gtk_widget_show (toggle);
-
- g_signal_connect (toggle, toggled,
-
Re: [Gimp-developer] [PATCH] Use Glade + GtkBuilder for file-png.c save_dialog()
Hi, Right now GIMP has virtuall all of the UI imperatively constructed with code. This has a few problems: * Tweaking the UI requires re-building the app * A lot of code duplication * Not very modern The patch I am replying to ports the PNG save dialog to Glade and uses GtkBuilder to construct the UI. The purpose of this change is to introduce declarative construction of UIs in GIMP to give us experience in this area. The benefits of using Glade is: * Tweaking the UI doesn't requires re-bulding the app * Less code * Easier to start using a script language like JavaScript in the core * We make the GIMP code base more modern * UIs can be constructed through drag-and-drop with Glade There are a few things that should be noted: * Translations still works * Mnemonics still works * The tooltip is still there (although only on the spinner, not scale) * We use GtkBuilder, not the deprecated libglade * There is no need for any proprocessing, GtkBuilder reads direct XML * We don't rely on any extra tool, XML files can be written manually And a warning: * Order of XML properties, see GtkAdjustment comment in file-png.glade So, do people think this is a step in the right direction? Personally I do and would like to commit the patch. Opinions? Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Best way to keep up with GIMP from git ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PATCH] Use Glade + GtkBuilder for file-png.c save_dialog()
On 2010-01-07 16:45, Martin Nordholts wrote: [...] The patch I am replying to ports the PNG save dialog to Glade and uses GtkBuilder to construct the UI. The purpose of this change is to introduce declarative construction of UIs in GIMP to give us experience in this area. The benefits of using Glade is: * Tweaking the UI doesn't requires re-bulding the app * Less code * Easier to start using a script language like JavaScript in the core * We make the GIMP code base more modern * UIs can be constructed through drag-and-drop with Glade [...] I'm not expert enough to decide whether using GtkBuilder to construct the UI is a good thing or not, but less code, more flexibility and no need to rebuild the app for interface customization all seem a good thing to me. Are there any disadvantages? Performance issues at start up and during actual program usage? Ideally, would this be limited to dialog windows or, instead, the entire user interface? -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] config - display dependency
Sven Neumann wrote: When we split up the GIMP core into sub-directories, we also split the code into UI and core. You will find a few files in the UI sub-directories that hold nothing but config settings. Since the non-UI GIMP should be able to read the same config files that the UI-enabled GIMP uses, the non-UI code needs to be know about some config settings that are part of the UI. That's why gimp-console needs to link a few files from the non-UI parts of GIMP. Does that mean that these files should be moved to other folders? No, because they are in the right location, close to the code that actually uses them. Does that mean that there is a dependency that needs to be fixed? No, not unless you want to drop the possibility to share config files between the UI-enabled and the non-UI GIMP. We have special-casing on the includes in app/config/gimpdisplayconfig.c by including types not in the module namespace, and we have special casing on the linking in gimp-console by including individual files instead of only module libraries. If we were to move the files to the config module, we could remove this special casing. Isn't it obvoius that this is what we should do? I don't buy the argument that code must be close to the code that uses them. That completely invalidates service layers in an architecture, i.e. layers that provides services to clients in layers above. And exactly how would moving the display config files to the config module drop the possibility to share config files between the UI-enabled and non-UI GIMP? The UI GIMP has access to the non-UI GIMP. Best regards, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PATCH] Use Glade + GtkBuilder for file-png.c save_dialog()
Ideally, would this be limited to dialog windows or, instead, the entire user interface? PiTiVi uses GtkBuilder to do this everywhere, and then uses python after that. Point being that the heavy lifting is still done by GTK+ and GStreamer. GIMP is a significantly larger program, but I don't think hooking up the widgets is all that time intensive here either. As far as I know switching over to using GtkBuilder everywhere would be a feasible thing to do as the heavy lifting is constructing the widgets not joining them together. regards, Stephen. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PATCH] Use Glade + GtkBuilder for file-png.c save_dialog()
Am Donnerstag, 7. Januar 2010 16:45:06 schrieb Martin Nordholts: Right now GIMP has virtuall all of the UI imperatively constructed with code. This has a few problems: [...] The patch I am replying to ports the PNG save dialog to Glade and uses GtkBuilder to construct the UI. The purpose of this change is to introduce declarative construction of UIs in GIMP to give us experience in this area. The benefits of using Glade is: [...] So, do people think this is a step in the right direction? Personally I do and would like to commit the patch. Opinions? The right direction from my point of view. I find Glade a very nice tool to design and manage UIs. A lot of stuff can be done without actually touching the code and there is also less code to maintain since any UI element that is not connected to a callback (i.e. a simple graphical element of the UI) does not need to have any code. Actual code could ideally be limited to just the callbacks plus 3-4 lines for creating the dialog. thus functionality and design would be separated. There is a catch, however, as Gimp's UI library defines several extensions to the Gtk+ library (GimpScaleEntry, GimpPreview). From what I saw in the documentation, this code already implements GtkBuildable (does it ?). But I haven't seen Glade supporting these widgets yet. Startup of Glade applications is a tiny bit slower, though, due to the added i/o and the need to parse the XML, but I feel that this is neglectable on today's hardware. So my conclusion would be that, if Glade is the direction where Gimp development will go, then Glade support for Gimp widgets should come first. regards Torsten signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] On bug 373060 - allow to easily switch to last used tool
I started working on bug 373060 - allow to easily switch to last used tool and ran into design problems, so am I taking this here. I already have a strong idea on what the feature should be https://bugzilla.gnome.org/show_bug.cgi?id=373060 At first, i tried to implement the feature like the swap_color feature inside app/core/gimpcontext.[ch], but on GimpTool. I've made a first patch implementing that straight GimpTool swapping and posted it on bugzilla (see comment #12), but I'm really not satisfied with this : it does only creates a redundant keyboard shortcut, which I really find useless. So I crafted a new user scenario : As a gimp user, I know existing shortcuts, I may even have rearranged them to fit better to my workflow, be more accessible on my kb layout and so on. When I want to switch to the last used tool, I really mean the last tool I found useful and actually used. Not the selection tool I switched on in the meantime to restrict the area I'm painting on, but this red grunge textured paintbrush I used before switching to a corrective tiny round with erase blending mode. Hope you follow my thoughts. The Idea is : - switching to last actual GimpTool is not enough, it's not that useful (wasting a key) and cannot track changes on the same tool's options, that is the part where you tweak your current options to make the tiniest changes, and cannot revert back to your previous options because you did not use another tool. + So, let's make a snapshot of what the user actually uses - tool, colors, brush, pattern, gradient, dynamics, tool options, ... - and keep it somewhere to restore it later. - Then it keeps track of every tool, every tiniest changes if possible to track them, not the useful ones. In a real painting area, that would mean switching back to your glass of fresh diet coke instead of that big blue oiled brush, or switching to the brush you are using with a more orthogonal tilt instead of the red one you just used before. Stupid. + So we don't want to track every changes, we want to allow the user to decide that this tool he is using right now is really useful, and that he wants to restore it exactly as it is. For users who owns a tablet with a stylus+eraser, this feature would just do the same as turning your pen upside down to use the other tool. I quickly described a possible user interaction in comment #13 on bugzilla : - I think this feature should backup and restore a snapshot of the entire active GimpContext, not only the GimpTool. User Interaction : - Keyboard shortcut : shiftX - On first use, the active context is backed up but remains active. - On next uses, the active context is backed up, and previously saved context is restored. This would allow a more complete user-defined tool swapping instead of just swapping different GimpTools back and forth. -- Now I wonder how and where to implement it. The context systems seems more spread and complex than just swapping GimpTools as I did on my first attempt. Furthermore, Mitch pointed out that gimp has had that kind of feature ages ago, and I dug up a related commit from ChangeLog.pre-2-0 : - 2003-02-25 Sven Neumann s...@gimp.org * app/gui/tools-commands.[ch]: removed Swap Contexts functionality. -- Sven, may you remember what was the reason of this removal ? (7 years ago) Wise people, please advise me. Damien. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PATCH] Use Glade + GtkBuilder for file-png.c save_dialog()
On Thu, 2010-01-07 at 16:45 +0100, Martin Nordholts wrote: * We use GtkBuilder, not the deprecated libglade Why are the files still installed in a folder called glade then and use the file extension .glade? Since we have the chance to do this right from the beginning, that should probably be changed. Other than that, using GtkBuilder has been on the TODO for quite a while. So it's nice that someone finally took a step forward and started doing this. We will probably have to improve libgimpwidgets somewhat to allow our custom widgets to be used from GtkBuilder. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] On bug 373060 - allow to easily switch to last used tool
Furthermore, Mitch pointed out that gimp has had that kind of feature ages ago, and I dug up a related commit from ChangeLog.pre-2-0 : - 2003-02-25 Sven Neumann s...@gimp.org * app/gui/tools-commands.[ch]: removed Swap Contexts functionality. -- Sven, may you remember what was the reason of this removal ? (7 years ago) If I remember correctly, we discussed this change on the mailing-list back then. You might be able to find more in the archives. As far as I can see the reason to remove this feature was that no one found it useful. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Finally I get the GIMP Pro
...and seems to be real check please this link : http://www.photo-editor-pro.com/ -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] raw therapee open source ...
an interesting article about the movement of Raw Therapee to GPL. http://www.rawtherapee.com/?mitem=1artid=46 -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] raw therapee open source ...
Hi, can you please stop spamming this mailing-list with your links? Thanks, Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] raw therapee open source ...
sure - first I told you all some peoples sell GIMP giving impression of a Pro piece of software ( that mean money - which mean support and all related things ). Well if you allow this is ok is not my problem. the second spam is about Raw Therapee which move to GPL I was thinking someone on this list will be interested at least for the open source words inside the announce. I can not finish my message without my appreciation for you're kindly notice about the spam that I was in danger to create - who know maybe in the morning my spam length could have some kilometers - well, this way I will go to bed now and the planet is saved. Thanks again for your kindly words and empathy. 2010/1/8 Sven Neumann s...@gimp.org: Hi, can you please stop spamming this mailing-list with your links? Thanks, Sven -- Nemes Ioan Sorin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
