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 12:02:48 +0200, damianzalewski <[EMAIL PROTECTED]> wrote: > 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. > no. Select , cut, paste as new. > > And how can I make web page without slicing ? > I have no idea what you are trying to "slice" or what effect you are trying to achieve but assuming you are trying to design a layout that is capable of adapting to different screen sizes (which you certainly ought to be doing) you will need to be a bit more engenious than just making a 600x800 and chopping it into a few chuncks. This is not the place for a tutorial but you should be able to create the necessary graphic elements by selecting a rectangle , possibly defining a transparency colour and saving in a suitable format. All that is readily available in gimp. The selection tools are now very easy to use precisely and well adapted for this task. /gg ___ 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] APNG support
Hi, On Mon, 2007-06-25 at 10:43 -0400, Andrew Smith wrote: > 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? In my opinion APNG is the wrong approach and it is very unfortunate that the Firefox developers seems to think that APNG supprt is more important than MNG support. But GIMP is modular and nothing keeps you or anyone else from writing a plug-in that adds APNG support to GIMP. Since we aren't going to include or depend on a patched version of libpng, such a plug-in would have to be distributed separately. Sven ___ 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
[Gimp-developer] [Fwd: upgrading GNU packages to GPLv3]
Hi, I am forwarding this mail from the FSF to the developer list for your information and for discussion. Sven --- Begin Message --- Hello GNU Maintainers, Version 3 of the GNU GPL will be released in a few days, which means it is time to start thinking about upgrading the license on GNU packages. We would like every GNU package to upgrade its license for the next release, and to include the new license in its source repository within the next few months. Upgrading is straightforward if your licensing situation is simple. If you're currently licensing work under GPL v2 or later, or LGPL v2.1 or later, with no added exceptions, the job is simple. Put the new version of the license in place of the old one, and change all the notices that talk about the license to refer to "version 3 or later". Be sure to check source code headers, documentation, and any license information in the interactive interfaces of your program. You should not have to change any other text in those notices aside from the numbers. If the license for your software does include exceptions, please write to Brett Smith <[EMAIL PROTECTED]> to discuss how to handle them. Some exceptions may need to be updated -- not to change their policy, but to use the vocabulary of the new licenses, or work properly with the details of their requirements. We're looking for some GNU maintainers who would like to upgrade their packages on June 29 as part of the GPL v3 release event. This will mean working quickly, but the FSF will help if needed. It's not necessary to have any new features or other technical changes -- you can simply relicense your repository and the last release. As redistributors pick it up, they will be adopting our defense against threats such as tivoization and discriminatory patent promises. If you would like to volunteer for the release event, please write to all three of us: Karl Berry <[EMAIL PROTECTED]>, Brett Smith <[EMAIL PROTECTED]> and me. When you make a release with the new license, please email [EMAIL PROTECTED] about the change, and please send an announcement to [EMAIL PROTECTED], even if you normally use another list for announcing new releases. If your GNU package is copyrighted by the FSF but you did not receive an earlier message about the GPLv3 upgrade, please email [EMAIL PROTECTED] so we can send that to you. In general, if you have any questions or concerns about upgrading the license for your project, please write to [EMAIL PROTECTED], which will reach Brett and the rest of the licensing team. Helping GNU maintainers with this change is a top priority for him, and all of us. Thank you, Richard Stallman, Chief GNUisance Karl Berry, Assistant Chief GNUisance Brett Smith, FSF licensing and GPL enforcement --- End Message --- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A few simple patches
Hi, On Tue, 2007-06-26 at 11:58 +0930, David Gowers wrote: > 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. That's already on my TODO but I will probably do it differently than your approach. > 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. The metadata plug-in is unfinished and not supposed to be part of the next stable release anyway. Perhaps it is time that we stop building and installing it. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
