[Gimp-developer] how to use status bar?
Hi, I've been trying to come up with a way to get the clone tool to show a message in the status area saying Ctrl-click to set source whenever the source needs to be set. It isn't easy, because gimp_paint_tool_oper_update() is not written to handle the status area in a cooperative way. Here is an approach that I think will work, and I would like to get an opinion on whether it is the right thing to do, or whether there is a better way. Suggested approach: 1) Add a status_msg field to GimpPaintTool, which will normally be NULL. 2) In gimp_paint_tool_oper_update, use status_msg if it is non-null, otherwise use the existing code to create a status message. 3) Add an oper_update callback to the clone tool, which sets or unsets status_msg as appropriate before chaining up. Best, -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
On Mon, 14 Feb 2005 03:06:33 +0100, Sven Neumann [EMAIL PROTECTED] wrote: The discussion about the design of the file-chooser widget is off-topic since we are not in the position to change it. Waaait, we're you advocating a few days ago that we follow the burning GTK edge because, after all, it's the Gimp ToolKit and so we can ensure that GTK continues to support the GIMP's needs? Rockwalrus ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
On Tue, Feb 15, 2005 at 02:59:55PM -0500, Nathan Summers [EMAIL PROTECTED] wrote: On Sun, 13 Feb 2005 20:53:17 +0100, Marc A. Lehmann [EMAIL PROTECTED] wrote: For example, you can switch between dynamic keybindigs and mnemonic use via preferences, but the 2.x dynamic keybindings are not as useful as the 1.2 DKB were, and I do not think that penalizing people who prefer that way (remember, it once was a killer feature of the gimp, just as shell-like tab completion in the file dialog was) is reasonable. Out of curiosity, why do you find the 2.x dynamic keybindings not as useful? Mostly because they need to be set in a different place (e.g. image menu) then where they are used (e.g. layers dialog) and the shortcuts are not being shown (Which is bad because I often change them depending on my needs). That is what I meant by penalizing. A minor point is that I need to organize my already-crowded keybindings better because they are global, whereas before I ctrl-d could mean duplicate image or layer, depending on the context (I am used to focus-follows-mouse so this didn't bug me the least, but apperently it did bug many others, so the change improve dusability for the masses or so :). I call this minor because it's just that: a minor nuisance, and I guess very difficult to make switchable via a preferences item. And of course very minor is that I need to enable it, but that's sth. I don't need to do very often :- -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] how to use status bar?
I've been trying to come up with a way to get the clone tool to show a message in the status area saying Ctrl-click to set source whenever the source needs to be set. Maybe when the cursor needs to be set, instead of displaying the (/) [NO] cursor, clicking could do something useful like setting the source. I propose adding a checkbox called Select source to the clone tool dialog under Image Source. The box should be auto-checked when the source needs to be set, and auto-unckecked each time the source is set. If it needs to be set, it should probably be grayed and checked until the source is set. The crosshair stamp cursor would be good as when ctrl is being held down in place of the (/) [NO] cursor. This would help: 1. New users to learn quicker (experimenting more likely to do something interesting) 2. Advanced users to work quicker (1 less action required when starting) 3. Disabled users (don't need to hold the key while clicking) _-T ___ Speed up your surfing with Juno SpeedBand. Now includes pop-up blocker! Only $14.95/month -visit http://www.juno.com/surf to sign up today! ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and multiple processors
On Sun, 13 Feb 2005 22:10:21 +0100, Sven Neumann [EMAIL PROTECTED] wrote:
Also tried to port the code to GThreadPool but it turned out to be not
as trivial as I expected. The current code blocks until all threads
are returned and it is not trivial to implement this behaviour with
GThreadPool. So this part, the more interesting part of the TODO, is
still open.
I don't want to put more time into this, but I think it would
definitely make sense to introduce a thread pool to cut down the
number of thread creations. Any volunteers?
Here's a solution that would work: (note, untested code, error
checking and unintersting stuff omitted for clarity, etc)
Calling code:
struct SynchStuff {
GThreadPool *pool;
GCond *cond;
GMutex *mutex;
} synch;
typedef struct SynchStuff SynchStuff;
synch.cond = g_cond_new();
synch.mutex = g_mutex_new();
/* create an exclusive threadpool */
synch.pool = g_thread_pool_new(gimp_thread_func, synch, ...);
/* make sure that all the tasks are in the queue before checking if
queue is empty.
*/
g_mutex_lock(synch.mutex);
for (/* each task */ ...) {
g_thread_pool_push(sych.pool, task, );
}
/* alll threads are now launched. allow threads to test queue for emptiness
* and wait for signal that all tasks are complete */
g_cond_wait (synch.cond, synch.mutex);
/* all tasks are now complete */
g_mutex_unlock(synch.mutex);
void gimp_thread_func(GimpTaskData *task, SynchStuff *synch) {
/* process task */
.
.
.
/* wait until all tasks have been queued */
g_mutex_lock(synch-mutex);
if (g_thread_pool_get_num_threads(synch-pool) == 1)
g_cond_signal(synch-cond, synch-mutex);
g_mutex_unlock(mutex);
}
We could also try to talk the glib developers into including
g_thread_pool_join, which would block until the task pool is empty.
It would be nice if the GThreadPool API were modelled on OpenMP to the
extent possible, which I admit is not really stellar because of the
compiler modifications OpenMP requires. But perhaps some of what
OpenMP does with compiler modifications we can do with macros.
Rockwalrus
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and multiple processors
On Tue, 15 Feb 2005 16:29:00 -0500, Nathan Summers [EMAIL PROTECTED] wrote: if (g_thread_pool_get_num_threads(synch-pool) == 1) correction: I meant if (g_thread_pool_get_num_threads(synch-pool) == 1 g_thread_pool_unprocessed(synch-pool) == 0) although the first test is sufficient if n(tasks) = n(threads) Rockwalrus ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
Hi, Nathan Summers [EMAIL PROTECTED] writes: The discussion about the design of the file-chooser widget is off-topic since we are not in the position to change it. Waaait, we're you advocating a few days ago that we follow the burning GTK edge because, after all, it's the Gimp ToolKit and so we can ensure that GTK continues to support the GIMP's needs? I don't really see the relationship. But anyway, you certainly read up on the file-chooser discussions. so you know that after a long discussion a particular design for the dialog had been accepted and has since then been implemented by the GTK+ developers. No fundamental change to this design will be made without the approval of the person who made the design in the first place. So, if you want to see an entry being added to this dialog, you need to talk to that person. Given the fact however that adding an entry to the dialog would ruin the now very nice keyboard navigation offered by it, I am pretty sure that such a change is not going to happen. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: file chooser performance
Hi, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: After updating to debian's 2.6.2-2, I made a few tests (with gedit, though, which should have similar performance). Are you using the gnomevfs file-chooser backend of the or the one that comes with GTK+? That would be a rather important detail about your system. The symptoms you describe sound like a weakness of GtkFileSystemUnix, or even the xdgmime implementation that it is using. One thing you could try is to move away /usr/share/mime/magic. If that file is not available, no magic probing should be performed on your files. It would also be a good idea to look at gtk+/gtk/xdgmime/xdgmime.c. There's a FIXME in that code that looks somewhat related. strace'ing gedit shows that the only change seems to be that instead of reading 128k of every file, only 8k is being read. One obvious problem is that it first stat's all files _then_ reads them, which is quite inefficient even for local filesystems. Are you sure that it reads _every_ file? That doesn't sound like you are using xdgmime since that would only open the file if it can't determine the filetype from the extension. You are probably using gnomevfs and there have been quite some performance improvements been done to this code lately. Perhaps try a more recent version of libgnomeui? I also did not quite understand the comparison you did above. What application is it that reads 128k of every file and which one reads only 8k of data? However, the detected content types are not even being displayed. Seemingly, they are not used at all, so the obvious improvement, as for the gimp file save dialog, would be to not gather costly data that is not being used or displayed (at least by default). Sorry, but the MIME types are being used to choose the icons to display in the file list so you cannot argue that the information would not be used at all. I agree though that I would prefer a fast MIME type detection over a more accurate one. Using filename extensions should be good enough here. Nevertheless, this is all supposed to happen asynchronously. There is probably a bug in that code but here's what the file dialog is supposed to do when you change folders: 1. starts a 0.5 second timer 2. slurps as much of the folder as it can 3. if the timer triggers, the model is set on the treeview; subsequent files are added as they come in 4. if it finishes loading before the timer triggers, the model is set on the treeview If the current path is not the same as the path for set_uri(), then it remembers the uri you want, changes folders, and selects the uri when it finishes loading the folder. (This is based on an excerpt from a discussion we had yesterday in the gtk+ developers meeting.) There's a bug report about file-chooser performance problems but I am not quite sure if you are actually seeing the same problem. Bug #166601 (http://bugzilla.gnome.org/show_bug.cgi?id=166601) appears to be a problem in the gnomevfs file-chooser backend. What you said about your strace doesn't seem to fit the straces attached there. But I haven't looked at the straces in all detail yet. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and multiple processors
Hi,
Nathan Summers [EMAIL PROTECTED] writes:
Here's a solution that would work: (note, untested code, error
checking and unintersting stuff omitted for clarity, etc)
Yes, that would most probably work.
struct SynchStuff {
GThreadPool *pool;
GCond *cond;
GMutex *mutex;
} synch;
typedef struct SynchStuff SynchStuff;
I don't think we need a SynchStuff struct though. These can very well
be global static variables. The thread pool will be kept around for
the whole lifetime of gimp anway.
Sven
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] for those of you who enjoyed camp
http://www.whatthehack.org/ Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] floating layers
hello, lately i am noticing a new thing about gimp behavior. if i try to New Layer a floating layer that has been pasted onto a mask, gimp refuses with an error message. for my limited understanding of the reason for floating layers to still exist, this behavior tells me that the need for them has gone. if gimp can tell the difference between a drawable or an image -- and it obviously does, there is no need for this floating step. also, since you cannot see the layer while it is floating, there is no positioning that can be done. can floating layers go away now? the arguments for them have ceased to have meaning. carol ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] floating layers
Hi, Carol Spears wrote: if i try to New Layer a floating layer that has been pasted onto a mask, gimp refuses with an error message. This is not new behaviour. for my limited understanding of the reason for floating layers to still exist, this behavior tells me that the need for them has gone. This is the only behaviour which justifies floating selections, actually. if gimp can tell the difference between a drawable or an image Actually, it's the difference between a GimpLayer and a GimpLayerMask (which are both drawables). can floating layers go away now? the arguments for them have ceased to have meaning. What UI do you suggest? 1) If we are pasting a selection which was made from a layer then create a new layer 2) If we are pasting a selection which was made from a mask or a channel, create a floating selection, but don't display it in the layers dialog, and only allow anchor selection Does that sound like what you would like to happen? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
