Re: [Gimp-developer] New feature inquiry.
On 07/12/04 13:39, Øyvind Kolås wrote: On Sun, 11 Jul 2004 13:46:09 -0400, Fredrik Alstromer [EMAIL PROTECTED] wrote: Hi all! The idea has been inspired by photoshop's effect layers, and the basic concept would be plugins that registers a new layer type. When sampled, the plugin is more or less simply executed, and the results are cached until any layer below the programmable layer has been modified. Layer modes and opacity are applied as if it was a normal layer, along with any layer mask. You actually want even more,. you want to be able to group layers and apply an effect to the group, instead of all layers below. An extensive example with an upside down layer list (should actually be flippable by just using a proxying GtkTreeModel), where the entire image contents is generated using procedural plugins and effects is at: http://freedesktop.org/~pippin/aluminium/screenshots/bauxite/2004-06-20b.png And we want it rendered using glitz! http://freedesktop.org/Software/glitz ... but seriously, does anyone think it's possible to offload processing to the GPU? Is that part of the GEGL pipe goals? I didn't see anything at the site in the docs ... Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp usability tests
On 04/27/04 09:25, Juhana Sadeharju wrote: -Crop rectangle can be resized only from two corner points; in a large image with zoom-in, only what may be visible is the edge of the crop rectangle, but the edge cannot be grabbed and dragged (which would desirable); likewise, only the move-corner may be visible and thus the rectangle cannot be resized Would it be possible to solve this issue by placing transient corners on the image? By this I mean: leave the four corners as-is, but if the visible image does not contain two corners (one of which is move, the other must be resize) to place transient or psudo-corner grippies on the extremes on the visible crop selection? IE: you've zoomed in on a portion of the selection so that the only thing visible is the vertical selection bar, no corners. A grippie appears at the top of the visible screen as though there were a corner grippie that allows horizontal resizing. A similar grippie appears at the bottom allowing horizontal moving. Similar but complimentary for verticals. Would this be hard to implement? regards, Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] TheMark Shuttleworth offer)
On 03/21/04 15:01, [EMAIL PROTECTED] wrote: One of the ideas that I believe Sven raised on irc, was that there should be a minimal and trivial interface to the PDB that is not based on any particular language but just consists of: gimp_foo -bar 3 -baz yellow Perhaps I'm being extremely dense, but couldn't there be an interface: gimp -cmdfile filename Surely notepad can handle funny characters and the name of the file is completely up to you so you can make it as shell-friendly as you'd like. GIMP could have some extra code to handle text mode files, but that's about all that would be needed ... Chris -- He who despairs over an event is a coward, but he who holds hopes for the human condition is a fool. -- Albert Camus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] TheMark Shuttleworth offer)
On 03/22/04 00:45, Kevin Myers wrote: Perhaps I'm being extremely dense, but couldn't there be an interface: gimp -cmdfile filename I think that the existing --batch option is equivalent Ah, hmm. For some reason I had gathered that this option took the script on the commandline, which is where the metacharacter problem lie. I'll go back to my hovel and keep quiet, obviously never have used it. Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Allow Maximise in Dialogs, like in Paint ShopPro 8
On 08/17/03 15:04, Alan Horkan wrote: On Sun, 17 Aug 2003, Sven Neumann wrote: On Sun, 2003-08-17 at 19:05, Alan Horkan wrote: The problem is that to resize the windows you need to grab the window edge and drag, so this useful and worthwhile feature is wasted. If a window can be resized then it really should have the Maximise Window decoration (with the rare exception of a few message dialogs). (Similarly you there should probably be a minimise icon for any of the non modal dialogs). We certainly don't fiddle with the window decorations. It's entirely the fault of your WM. Bet you Five Euro Havoc Pennington will disagree and that the GIMP should be setting additional hints or suchlike. For what it's worth, kwm (the KDE window manager) puts the maximize button on every dialog that I tried, except for the new image dialog - even dialogs that are menu tear-offs. Maximizing the menu tearoff does not actually maximize it though, which makes sense to me, given how most of the other dialogs resize themselves when maximized. Though I don't see this as being much of an issue personally, the KDE window manager handles it as you seem to expect. Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Version Summary (was:: [Gimp-developer] tentative GIMP 2.0 releaseplans)
On 07/20/03 06:49, Sven Neumann wrote: A few people expressed that they dislike the version number, other liked it. We went through all the arguments a few times and finally decided that we want to go for 2.0. Firstly, I have no control over the version number and there's no point arguing with a wall - I simply did this for my own sanity. I went through the list archives, and have tallied what people publicly 'decided' should be the next version. Here is the list: [1] david gowers[implicit] 1.4 [2] Marc A. Lehmann [start of subject] 1.4 [3,4] Raphaël Quinet1.4 [5] Guillermo S. Romero 1.6 or 1.8 [6] Michael J. Hammel 1.4 - [7] Tino Schwarze 1.4 [8] Sven Neumann2.0 [9] Branko Collin 1.6 or 1.8 [10] Christopher W. Curtis 1.5 [11] Shlomi Fish1.4 - [12] Robert L Krawitz not-2.0 [13] Owen [sqrt(2)] 1.4[142...] [14] Patrick McFarlan not-2.0 [15] David Neary2.0 [16] Henrik Brix Andersen 2.0 - [17] Adam D. Moss 8.0 [18] Steinar H. Gunderson 1.4 [19] Nathan Carl Summers1.4 [20] Jakub Steiner 1.4 [21] Daniel Egger 1.4 - [22] Marco Wessel XP [23] Joao S. O. Bueno 1.4 [24] wolfgang 1.4 [24] Carol Spears 1.4 Since this isn't a vote, I'm not tallying any numbers, and there may be 20,000 people all saying they want 2.0 in the July archives; however, these are not yet online so I can't scan them. Chris References: [1]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008711.html [2]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008713.html [3]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008800.html [4]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008769.html [5]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008715.html [6]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008716.html [7]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008719.html [8]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008728.html [9]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008745.html [10]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008806.html [11]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008808.html [12]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008749.html [13]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008737.html [14]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008750.html [15]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008759.html [16]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008827.html [17]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008828.html [18]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008760.html [19]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008761.html [20]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008762.html [21]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008832.html [22]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008768.html [23]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008776.html [24]http://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008785.html ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tentative GIMP 2.0 release plans
On 07/19/03 20:56, Carol Spears wrote: Having the ./gimp-1.3/plug-ins is problematic to me. The rest of gimp names use hyphens as wisely as you can expect, but not this one area. Aha ... well, doing a quick search with 'dict,' it knows about plug-in and refers plugin to plug-in automagically, However, being a lazy or ignorant American (pick one only, please) I say plugin. Mr Curtis, you seem to be quick with the English rules, perhaps you would like to help edit gimp documentation as it comes in. Sadly I have led you astray; however, I would be more than happy and reasonably willing to proof incoming documentation. I sent a couple [minor] patches/suggestions to the GUM authors before it went final. Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tentative GIMP 2.0 release plans
On 07/19/03 13:10, Carol Spears wrote: I also will not write any English documentation until I can afford to buy that book that explains the English rules about hyphens. I'm not sure what book or what hyphens you are talking about, but the Elements of Style is in the public domain. Here are some links for you: http://www.bartleby.com/141/ specifically http://www.bartleby.com/141/strunk.html#8 http://www.cs.vu.nl/~jms/doc/elos.pdf There are other resouces available on the web. http://owl.english.purdue.edu/handouts/grammar/g_hyphen.html http://lingua.kie.utu.fi/dbergen/AAW/Lesson%205/punctuation1.htm etc. I would think that any poorly done english documentation is better than none, and people might help to fix documentation more than they would strive to write it. Getting started is always hardest... regards, Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tentative GIMP 2.0 release plans
On 07/19/03 13:10, Carol Spears wrote: I also will not write any English documentation until I can afford to buy that book that explains the English rules about hyphens. Also, I'm not heard of this, but it sounds like it may pertain more to British English (I'm under the impression that Elements of Style is an American made thing): http://www.bartleby.com/116/ It's called The King's English by H. W. Forler. It also has a section on hyphens: http://www.bartleby.com/116/405.html regards again, Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf [Re: Gimp-developer Digest, Vol10, Issue 18]
On 07/17/03 19:41, Alan Horkan wrote: On Thu, 17 Jul 2003, Christopher Curtis wrote: even resemble XML. My PREAMBLE is valid XML. If they implement what they have written, they don't even bother with things like closing tags or putting parameters in quotes. A preamble, which is effectively full XML file, a boundry then more information which is effectively another file. Two files in one file, sounds like an ad-hoc container to me. As interesting as what I said was, I don't see how your comment logically follows. Anyway ... I only used Winzip as an example, there are several programs which can recover parts of zip files, so repairing damaged zip files is possible (although I cant guess how difficult it is do it). This is something that shouldn't really be an issue. The ZIP format keeps the list of files at the end, so that if the file is clipped, the directory is lost, and you can recreate it by scanning the archive for delimiters. The reason it can be repared at all is because the most likely thing to get lost is the meta-information. So, after some research, I've decided that ar is a fine container format. My only conribution, which you may take as you will, would be to specify that the first entry in the archive is the descriptive catalog. Naturally I'm thinking the XML snippet I stated earlier, sans the data offset thing. The advantage to this is that you can detect if the file is corrupt, and you have two ways or accessing data: via meta-information only, or via the actual data entry. This means there's no need to scan through the archive to find its contents, and means that you can read the file using more and it works fine (as long as the XML file is uncompressed). The downside to using 'ar', really, is that WinZip doesn't support it. I haven't verified this - I hope a Windows user can do so for us. Just for reference, attached below is a CP of an ar archive I just made: bash-2.05b$ echo 1 file1 bash-2.05b$ echo 2 file2 bash-2.05b$ ar r myar.xcf file* bash-2.05b$ (echo --; cat myar.xcf; echo --) -- !arch file1/ 1058492021 1000 1000 100644 2 ` 1 file2/ 1058492025 1000 1000 100644 2 ` 2 -- Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: new-xcf
On 07/16/03 20:26, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: - maybe there is a need to have a gimp-specific file format, especially when you want to store the image data in a non-trivial way to speed up access. - maybe there is a need to have a nicely defined exchange format for complex images (xml + data is nicer than the ad-hoc design of miff). If we really are in brainstorming mode here, following the suggestions listed above, how about a format something like the following, which is essentially just an XML preamble, followed by raw binary data: gimp type=image version=1.0 nameMy Example Image/name authorChristopher W. Curtis/author descriptionA big, purple, E/description date format=logical2003/07/18/date copyright2003 FSF, All Rights Reserved/copyright layer name=Background mode=overlay opacity=0% dimensions width=800 height=600 / origin x=0 y=0 / data offset=2000 format=RGBA bpp=12 / /layer [...] /gimp \000\000\000 [...] \000 until file offset=2000 raw binary data The nice thing about this is that it should be fully parseable by XML parsers (up until the first NULL [1 is required, the rest are optional buffer space for those too lazy to do math]), it is completely human readable and very descriptive, highly extensible, and fully functional. You can add an encoding= or compression= option, specifying none, bzip2, or whatever, or even format= and jpg (at the layer mode, making the dimension, etc. tags optional; you'd still need data offset, etc.) The other nice thing is that you can just read the header, and load the rest of the layers on demand (for other 'preview' tools or what have you), and it can be used for other items as well. Instead of type=image you can have type=brush, etc. Maybe even add an attribute like thumbnail format=jpg offset=12580 /. Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plugin/Script/gimp source code:How do I drawa vertical line with just a click of a button?
On 06/01/03 15:02, [EMAIL PROTECTED] wrote: I have been cracking my head for the past day trying to think of a way to draw a vertical line with just a simple click of the mouse. On my image, I have two horizontal lines, I want a tool that will allow me to just click anywhere between these two lines and draw a vertical line(width of 1 pixel) connecting both horizontal lines. Well, what you want to do is click on the first point, then hold down the shift key and click on the second point. For more accuracy, and even something of a preview, you can drag the rulers onto the image right where the line should be. If you really want to use a script, this should be very straightforward. A quick google search for gimp script example brings up this informative looking site: http://pingus.seul.org/~grumbel/gimp/script-fu/script-fu-tut.html rgds, Chris -- He who despairs over an event is a coward, but he who holds hopes for the human condition is a fool. -- Albert Camus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] + restoring mouse position after use cornernavigation tool
On 11/26/02 08:56, Sven Neumann wrote: Hi, Christopher W. Curtis [EMAIL PROTECTED] writes: On 11/25/02 06:23, Sven Neumann wrote: position using plain GDK, but I think there's still no way to warp the pointer to a different screen location. It's been quite some time since I've done any X programming, but I recall having a function that would bound the pointer within a box. Should this exist, you could bound the cursor and then release it, perhaps after a motion event (I'm not sure how immediately the bounding event happened). :-\ please keep in mind that we don't do any X programming here; we need a GDK equivalent. IIRC, you can confine the pointer into a GdkWindow when calling gdk_pointer_grab(). However I did not understand your argumentation above. Are you saying that we should try to warp the pointer by using this functionality? I think should is too strong a word. You said that there was no way to do it. Well, this might be a way. An ugly hack, perhaps, but a way. If you really wanted to do it and had no other means to ... Whether or not this *should* be done I'll leave up to you. Chris ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
