[Gimp-developer] A plan for GimpRectangleTool
Hello
There are now 24 bugs that have a 2.4 milestone and 6 of these are
related or directly uses the code in app/tools/gimprectangletool.c.
As most of you know the code in there is a mess. In the last few days
I've been thinking about a way to clean up this mess, and I have a plan
I'd like to throw out there in an attempt to synchronize the direction
we are taking the code in.
With the introduction of helper functions like
void gimp_rectangle_tool_constrain_aspect (GimpRectangleTool
*rectangle_tool, gdouble aspect, const gchar *apply_on_x, const gchar
*apply_on_y)
{
/* apply_on_x may be x1, x2 or center_x, same for on_y */
}
and verbose comments and member/variables names, it would be possible to
apply these modifications on the rectangle in different order depending
on the state of GimpRectangleOptions
We would also avoid weaving in different logic on the same line of code,
which currently is what the code in gimp_rectangle_tool_motion is
horribly close to doing.
For a taste of what I mean, checkout this patch:
http://bugzilla.gnome.org/attachment.cgi?id=90541action=view
attached to this bug:
http://bugzilla.gnome.org/show_bug.cgi?id=398183
(CTRL modifier on a selection does not snap the starting corner back...)
It introduces e.g.
void gimp_rectangle_tool_set_other_side_coord (GimpRectangleTool
*rectangle_tool, gint other_side_x, gint other_side_y)
and verbose commenting.
Personally I intend to realize this plan in the following weeks, I just
wanted to throw it out to the mailing list. Partly because, as I said,
to synchronize the direction the code is taking, but also to get
feedback and to avoid clashes with other Big Plans.
- Martin Nordholts
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A plan for GimpRectangleTool
Martin Nordholts ([EMAIL PROTECTED]) wrote:
With the introduction of helper functions like
void gimp_rectangle_tool_constrain_aspect (GimpRectangleTool
*rectangle_tool, gdouble aspect, const gchar *apply_on_x, const gchar
*apply_on_y)
{
/* apply_on_x may be x1, x2 or center_x, same for on_y */
}
Hmm, wouldn't an enum for apply_on_* make more sense?
Bye,
Simon
--
[EMAIL PROTECTED] http://simon.budig.de/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Webdesign is wrong
gcn I agree that the tools should aimed towards top end users not splicing. gcn Gimp's declared aim is to provide tools for creating elements for web gcn design not page layout. Does it really mean I have to use separate program to make few cuts. And how can I make web page without slicing ? -- Pozdrawiam, damianzalewskiMój mail:[EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Webdesign is wrong
On Mon, 25 Jun 2007 00:52:53 +0200, David Marrs [EMAIL PROTECTED] wrote: With a save *selection* for web feature, steps 3) and 4) could probably be omitted altogether for most of the time. well save for web is a plugin but it probably could be extended to save a selection. Sounds like a time saver. Step 5) is often made cumbersome by the fact that the default save destination is the last directory used by the application. Life would be easier if a web images directory could be set in preferences (maybe it can and I don't know about it!). Yes I find this annoying as well. I always end up having to set the destination each time I save something. That may be gtk filechooser (one of my pet hates on linux) rather than gimp directly. Even if I open a file and want to save_as straight away it seem to want to put is somewhere else. The time it takes to log a directory exaserbate this problem as well. It's getting late so I'll leave it there. I think I may follow this email up with a more fundamental description of what a designer is trying to achieve when marking up a concept, if you think it would be useful. Let me know if there are other things you want to know. I'd be interested to follow your progress as you design this feature. Regards, Davidm Some studies were done last year on usage but since the UI is undergoing a major design effort now it's probably a good time to point out anything that holds you back in your work flow. thx. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] APNG support
Hi Sorry I don't know if this is the right list for this message. I was wondering whether there is any interest in having The Gimp support the APNG format? And if so, whether any of the Gimp developers would be willing to write it? The format has been designed to build on PNG, so whatever processing is done on regular PNG files will apply to APNG files and frames. The format also mostly mirrors the features of Animated GIF, so from a GUI point of view any program that works with Animated GIFs will need only minor changes to support all the APNG features. The patch for libpng, to do the decoding, is available here: http://littlesvr.ca/apng/ I can port it to newer/older versions of libpng if you need it. There is also a short tutorial on using the patched libpng to work with animations, including examples: http://littlesvr.ca/apng/tutorial/ I have never worked on The Gimp so I can't write a patch, all I can offer is help with the patched libpng, and to explain the specification if it's confusing. Cheers, Andrew ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A plan for GimpRectangleTool
Simon Budig skrev:
Martin Nordholts ([EMAIL PROTECTED]) wrote:
With the introduction of helper functions like
void gimp_rectangle_tool_constrain_aspect (GimpRectangleTool
*rectangle_tool, gdouble aspect, const gchar *apply_on_x, const gchar
*apply_on_y)
{
/* apply_on_x may be x1, x2 or center_x, same for on_y */
}
Hmm, wouldn't an enum for apply_on_* make more sense?
Bye,
Simon
Well, that will depend on if it will be used similarly to the
gimp_rectangle_tool_set_other_side-family of functions that were in the
patch I linked to, or, perhaps more likely, if it will be used on the
local x1, x2, etc gint:s in gimp_rectangle_tool_motion. I'd prefer the
former but we'll see how the logic in _motion folds out.
- Martin
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Webdesign is wrong
David wrote: peter sikking wrote: can you tell me what you mean with manual work needs to be done? that can help us with our work. Well the most common case is simply selecting a slither of an area to be tiled as a background image. yep, we expect this kind of stuff to be your daily routine. actually right now I am specifying how the selection tools should deal with long, very narrow selections, with the web guys in mind. Sometimes you have to hide a foreground layer before making the selection such as filler text or an image. You will also want to pick a colour with the pipette tool that will be used as the background colour of the element. Most of the background images I deal with are gradients, so the colour I want to use is either the darkest or lightest colour of that gradient. Otherwise you often need to select the right combination of layers. I've already mentioned foreground layers that might need to be hidden. Other times they might need to be isolated. In Photoshop the issue is further complicated by the use of adjustment layers. Transparent gifs or pngs will need to be isolated altogether. Sometimes a background image will be larger than the dimensions of the containing element so the final thing you'd want to do is toggle a layer mask to get the whole image. lot's of layer action to get the right combinations _visible_, that is what we also thought would prelude the cutting of web images. This is the routine I tend to follow when using PS 9: 1) Toggle visibility of layers and masks until I can make a selection of the area I need to save. 2) Select area with marquee tool. Can be very annoying when zoomed in because selection always overshoots when I scroll. PS does not share Gimp's sensitivity when zoomed in. 3) Copy visible. Gimp should probably have a short cut key bound to this operation as it is always required. there we go: visible. what you see is what you export. we are thinking in the same direction. 4) Open new canvas. PS automatically populates the canvas dimensions with those of the paste buffer so this operation isn't as cumbersome as it would be in Gimp, but really it wouldn't be required at all if PS allowed you to edit an image during the next stage. The only editing I ever need to do here is convert background to transparency. sounds to me that this whole new canvas is superfluous. the transparency thing is noted. 5) Save for web. Compare compressed images against original. Adjust for best compromise of size and quality then save. interesting to see Compare compressed images against original, would it be enough to see the compressed one and balance that against the size and what your customer expects? With a save *selection* for web feature, steps 3) and 4) could probably be omitted altogether for most of the time. Step 5) is often made cumbersome by the fact that the default save destination is the last directory used by the application. Life would be easier if a web images directory could be set in preferences (maybe it can and I don't know about it!). yeah, we are seeing that for these individual saves, but also for saving 20 images from a cutting mask in one click, working with fixed and also variable destination directories is part of the game. we need to support you guys there. It's getting late so I'll leave it there. I think I may follow this email up with a more fundamental description of what a designer is trying to achieve when marking up a concept, if you think it would be useful. Let me know if there are other things you want to know. I'd be interested to follow your progress as you design this feature. now it is getting late here too. if you can make that description really fundamental (like in principle for tens of thousands of web graphic designers), and filter your own biases out, then that would be great input for us. but you better be sure it is fundamental ^} thanks, --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Mouse problems using Wacom tablets (was 2.3.18 deletes exif...)
For a long time, nothing has changed in GIMP with respect to XInput devices. So the fact that an upgrade introduced this problem seems to be a strong indication that the problem is elsewhere. I have similar problems using a Genius tablet. Once I used the pen, mouse is no longer detected in the canvas. But I think is a GTK+xorg issue and not Gimp's one, because the same seems to happen in Inkscape. Luis, you should try with inkscape as well (remember to activate the tablet as an input device). Besides of that, the device driver for my Genius tablet seems to be completely broken for GTK apps under Ubuntu Feisty Fawn (it worked in the previous version). I think it's a GTK problem and not Xorg's one, because MyPaint works fine, but gimp and inkscape don't. I tried to install Inkscape Fedora RPM, but for some reason the last repository version seems highly broken (at least with my package setup). I should compile it by myself when I have some time (lots of libraries and dependencies). Anyway, your problem description is EXACTLY mine. Did you try disabling the eraser (not the stylus)? In that way, the mouse works (but not the eraser, of course). You should move the stylus to 'activate' the mouse. Is this also the behavior in Inkscape? Thanks, L. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] A few simple patches
filepath.diff adds a 'file path' field to the 'Image Properties'
dialog; I did this after some discussion between gg and myself on the
importance of being able to find out the path easily.
Image_metadata.diff changes the title used by the 'metadata' plugin
for its window. Mainly, it's just so that there are not two different
dialogs both titled 'Image Properties' available.
Maybe the title should be 'File Properties' instead -- but, IMV, this
is ambiguous VS 'Image properties' -- 'metadata' is the more correct
term.
Neither of these patches seem controversial (although they do effect
translations), which is why I posted them here instead of on Bugzilla.
I hope that the ML software doesn't strip off these attachments :)
Index: plug-ins/metadata/interface.c
===
--- plug-ins/metadata/interface.c (revision 22834)
+++ plug-ins/metadata/interface.c (working copy)
@@ -653,7 +653,7 @@
gimp_ui_init (PLUG_IN_BINARY, FALSE);
- mgui.dlg = gimp_dialog_new (_(Image Properties), PLUG_IN_BINARY,
+ mgui.dlg = gimp_dialog_new (_(Image Metadata), PLUG_IN_BINARY,
NULL, 0,
gimp_standard_help_func, EDITOR_PROC,
Index: app/widgets/gimpimagepropview.c
===
--- app/widgets/gimpimagepropview.c (revision 22834)
+++ app/widgets/gimpimagepropview.c (working copy)
@@ -134,6 +134,9 @@
view-filename_label =
gimp_image_prop_view_add_label (table, row++, _(File Name:));
+ view-filepath_label =
+gimp_image_prop_view_add_label (table, row++, _(File Path:));
+
view-filesize_label =
gimp_image_prop_view_add_label (table, row++, _(File Size:));
@@ -329,6 +332,27 @@
}
static void
+gimp_image_prop_view_label_set_filepath (GtkWidget *label,
+ GimpImage *image)
+{
+ const gchar *uri = gimp_object_get_name (GIMP_OBJECT (image));
+
+ if (uri)
+{
+ gchar *name = file_utils_uri_display_name (uri);
+ gchar *path = g_path_get_dirname (name);
+
+ gtk_label_set_text (GTK_LABEL (label), path);
+ g_free (path);
+}
+ else
+{
+ gtk_label_set_text (GTK_LABEL (label), NULL);
+}
+}
+
+
+static void
gimp_image_prop_view_label_set_filesize (GtkWidget *label,
GimpImage *image)
{
@@ -424,6 +448,7 @@
gdoubleunit_factor;
gint unit_digits;
const gchar *desc;
+ const gchar *path;
gchar format_buf[32];
gchar buf[256];
@@ -515,9 +540,13 @@
/* filename */
gimp_image_prop_view_label_set_filename (view-filename_label, image);
+ /* file path */
+ gimp_image_prop_view_label_set_filepath (view-filepath_label, image);
+
/* filesize */
gimp_image_prop_view_label_set_filesize (view-filesize_label, image);
+
/* filetype */
gimp_image_prop_view_label_set_filetype (view-filetype_label, image);
}
Index: app/widgets/gimpimagepropview.h
===
--- app/widgets/gimpimagepropview.h (revision 22834)
+++ app/widgets/gimpimagepropview.h (working copy)
@@ -47,6 +47,7 @@
GtkWidget *resolution_label;
GtkWidget *colorspace_label;
GtkWidget *filename_label;
+ GtkWidget *filepath_label;
GtkWidget *filesize_label;
GtkWidget *filetype_label;
GtkWidget *memsize_label;
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Webdesign is wrong
David Marrs writes: 4) Open new canvas. PS automatically populates the canvas dimensions with those of the paste buffer so this operation isn't as cumbersome as it would be in Gimp, but really it wouldn't be required at all if PS allowed you to edit an image during the next stage. I might have misunderstood this step (I definitely don't follow the comment about PS not letting you edit -- maybe that's a PS issue) but it sounds like if you did a Paste as New in gimp, you wouldn't need to create a new canvas or figure out any dimensions. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
