Re: Image attached
Michael wrote: Theoretically this would resemble the layer without mask That's if you assume that the masking is additive -- actually it's multiplicative. --Adam -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/
Pupus pipeline: what Adam has been doing, etc. etc.
rming to the usual API, they just happen to be one of a small set of black boxes which the step-manager knows how to utilize for its own nefarious gain. So, in this example, pipeline-stress is coming from expose events? The cache-boxes would move to nestle right up under your canvas-box, so the fully-rendered final image would be one pipeline-step away. Now, this can be taken too far. I'm actually a bit uneasy about leaving everything in pipeline-form from image-open through to image-save -- but hey, it's up to you as the higher-level app programmers. I can build the bomb, you can drop it. How would the "pupus" functionality be directly exposed to users? The answer is that it most assuredly WOULD NOT. I do not advocate, in fact I ABHOR the idea that the user should end up drawing a little tree of boxes connected with wires. That's your view as a programmer (and even then there are likely to be a few utility layers of API between you and the raw pupus pipeline constructor when I've had my way), but your responsibility as an application designer is to map a more user-friendly concept (good old layers, images, layer masks, brushes et al) to this back-end. A note on interactive pipeline stages such as brush-painting, smearing etc: There are lots of ways to do this and I'd really like to experiment with them all before commenting. =) Going forward, I have, as usual, very minimal spare time so this message is a (not terribly) compressed view of several months both in the past and future. When I can begin to demonstrate a small GIMP-like app built upon the pupus pipeline I will issue a code-drop. If I can't do that then it's worthless and I give up! For those who have an upcoming holiday, have a good one! See you in January. --Adam -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/
Re: ANNOUNCE: GIMP 1.1.29
Austin Donnelly wrote: On Tuesday, 31 Oct 2000, Manish Singh wrote: GIMP 1.1.29 is out there. This is a release candidate for 1.2. So scream if you see any major brokenness. Uh, well, there's at least: [...] Hmm, I'd be really reluctant to concede that these constitute anything resembling 'major brokenness' (though I too have my personal favourite bugs lately such as enormous help-system omissions and the stickiness-bug when moving layers with a wacom stylus -- these are annoyances rather than showstoppers). Realistically the truly-critical bug list is pretty well-tamed currently but the impetus to fix things has been faltering to match. The tree is in reasonably good shape and a release would hopefully revitalize the development team -- after the first year or so the 1.1.x cycle started to feel more like purgatory than software development! --Adam -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/
Re: strange message on cvs ci
Austin Donnelly wrote Previously, I was using cvs.labs.redhat.com (199.183.24.238) as my CVS server. Now I've moved to cvs.gnome.org (209.116.70.81) and that one works Bah! I've been sitting here thinking that redhat screwed the CVS server for weeks. (I suppose that's not inaccurate, if the darn DNS entry can't be altered.) Hooray, I finally have a fresh GIMP CVS tree... --Adam
Re: IScissors patch.
Laramie Leavitt wrote: 2. Allocate a task to compute values in the background so that the mouse can still be moved while the computation takes place. #2 is the hard part. I can do #1 with the current tile system. Are there any capabilities in the gimp to allow #2? If not, then iscissors probably won't get much better than this patch. You can set up a GTK idle task -- no problem (as long as you're aware of the implications, mainly interactions of any 'unfinished business' with actions of the user which may invalidate that work entirely). Various parts of GIMP, such as the main compositing loop, run as idle-tasks. Is that what you meant? Personally I'm afraid I don't have time to look at this patch any time soon, and I think that this is likely the case for most of the core developers although we'd be interested enough in hearing feedback from this specific patch. This is also a really, really bad time to be proposing an IScissors overhaul -- when 1.3.x is underway I think you'll get a better response. If you consider IScissors to be fundamentally broken (I haven't seen a problem lately but I don't use it much!) then that's another problem altogether, though if it quick'n'dirty fixes won't suffice then I think that at this point IScissors would have to be ditched completely until 1.3.x (I don't think it has to come to that -- do you have any specific complaints with IScissors as they stand?). Thanks! --Adam -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ "Shut up, Donkey. Talking animals have no place in comic strips."
Re: 16 bit Gimp and 1.2 codebase
Mathew Yeates wrote: I'm currently using the experimental Film Gimp with deep image support. It is based on Gimp 1.0.4. What would it take to add the same deep image support to the 1.2 codebase? Yosh? Since no-one else has replied I think I'd just have to say "ain't gonna happen". The 1.1.x codebase has drifted from the HOLLYWOOD GIMP to an unreconcilable degree -- 16-bit support will be part of GIMP 2.0 (ETA summer 2009) or would have to be reimplimented from scratch or otherwise hacked up for 1.3 (unlikely). --Adam -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ "Shut up, Donkey. Talking animals have no place in comic strips."
Re: gimp swapfiles
Fethi BELGHAOUTI wrote: i'm using gimp in network and in --no-interface and --batchmode ! i never exit gimp, and it generate me too many swapfiles ! how can i do to purge ths files without exiting Gimp ? This is a shortcoming in the GIMP swap management -- the size of the swapfile is every byte from the start of the swapfile to the position of the end of the last in-use tile in the swapfile. The swapfiles are trimmed automatically where the last span of the file is 'free' space, but only in this case (no compaction is done when there are large unused regions anywhere but the end of the file). The resulting fragmentation causes some degree of swapfile bloat and thrashing. This fails to impress me but is not going to change at this point (ie. GIMP's general mem/swap handling has already improved greatly since 1.0.x and it would be sort of neat to see 1.2 released before my monitor-radiation-baked eyes fail with old age). You could try looking into the memory access patterns of your scripts themselves -- the order in which you create and destroy resources can have direct bearing on the swapfile usage. You might also want to up your tile cache and/or add more system swapspace so GIMP leans on that to a much greater degree -- I expect that performance would probably be a bit worse in high-mem-usage conditions, but your OS is also probably better at keeping memory defragmented and reclaimed than GIMP's hand-rolled swapsystem is (cop out). -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ "Shut up, Donkey. Talking animals have no place in comic strips."
Re: minor terminology clarification
"Michael J. Hammel" wrote: I've been under the assumption that the term "image window" was changed to "Canvas window" for 1.2. I think you mistakenly credit the GIMP developers with an actual Master Plan. :) ... However, if the terms are to be considered interchangeable then there's no worries. I believe they're interchangable (with minor semantic differences from a core-developer point of view). -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ "Shut up, Donkey. Talking animals have no place in comic strips."
Re: minor inconsistancy in GIF animation options
"Michael J. Hammel" wrote: I just noticed that the Animation Playback specifies a delay of 125 ms for unspecified frame timings, but the Save As GIF dialog defaults to 100 ms. Could the latter be changed to 125 ms so the playback will match the saved file if the defaults are used? I hadn't noticed that -- I'm changing it now. I'm changing the former to 100ms since the latter only works with 100ms- granularity. I may yet reconsider and default both to 200ms. --Adam -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ Hour by hour / Day by day / Love leaks out / And goes away
New bugs in mild profusion.
Hi guys and gals, I've noticed a few regressions and general screwups in current CVS GIMP with just cursory testing. Two immediately noticable ones are: 1) moving a layer with the move tool is broken, no longer tracks pointer after first 'settle' of motion. 2) ctrl-q to quit brings up the 'something modified, really quit?' dialog but the 'okay' button then makes the dialog vanish but GIMP doesn't quit. The 'quit' menu entry gets greyed-out and, well, you can't quit. Admittedly, no-one should want to quit GIMP anyway. --Adam -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ "And the dead audience applauded, and laughed, and their laughter was a strange sound."
Re: New bugs in mild profusion.
[EMAIL PROTECTED] wrote: On 26 Jun, Adam D. Moss wrote: Two immediately noticable ones are: 1) moving a layer with the move tool is broken, no longer tracks pointer after first 'settle' of motion. 2) ctrl-q to quit brings up the 'something modified, really quit?' dialog but the 'okay' button then makes the dialog vanish but GIMP doesn't quit. The 'quit' menu entry gets greyed-out and, well, you can't quit. Admittedly, no-one should want to quit GIMP anyway. Huh? Both of them work just fine here... Right, make that intermittant. -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ "And the dead audience applauded, and laughed, and their laughter was a strange sound."
Re: XCF loader for gdk-pixbuf
Sven Neumann wrote: Hi, Since I've touched app/xcf.[ch] too: I hereby give my permission for anyone to use the portions of xcf.c that I have written under the terms of the LGPL. Oh yeah, same here. -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ "... for a man who flies from his fear may find that he has only taken a short cut to meet it."
recent commit...
* app/cursorutil.c (gtkutil_compress_motion) * app/edit_selection.c (process_event_queue_keys): Guard against gdk_event_get returning NULL (which can happen at least on Win32). I'd kinda like to see this reverted and fixed at the WIN32 GDK level -- if gdk_event_get() fails straight after a gdk_events_pending() succeeds in a single-threaded app then it's not just GIMP that's going to have a problem... ...unless this is documented cross-platform behaviour, of course! Tell me if I missed something. --Adam -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/
Article on UI design in free software.
Not bad. Quite pertinent to GIMP. http://sendmail.net/?feed=interviewkuniavsky Not that I think GIMP's UI is bad (lately) or that we have a particular reason to actively innovate as opposed to more of less cribbing, ahem, someone's UI. --Adam
New menus.
Thanks to those who've been working on the new menu structure -- mitch and sven. The new layout is significantly more intuitive and organised in both the user and developer domains. --Adam -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/
fileops
Just a quick note since I don't have the email which I accidentally sent to Nick but meant to send to the list here with me at work... Since the patch to generate multiple thumbnails went in, the load-image-generate-thumbnail cycle occurs twice when you ask for a single thumbnail. Needless to say, that makes thumbnail generation half as fast. --Adam
