Re: [gimp-devel] Tablet Testing Needed!
So. Finally I could do some test with my Intuos A5 and my Artpad II. Garry R. Osgood ([EMAIL PROTECTED]) wrote: > 4. With pen still in hand, move to the interior of the selection region. > 5. Press down and move the pen (this activates init_edit_selection() >and Edit Select tool methods that over-ride the rectangular select >tool-set. also, the pause reference count is incremented in the >currently active Selection object; gimp_undo_freeze() had already >been invoked in a rectangular tool method context) a. Confirm: Move >cross icon appears. (if Cursor Mode is "Tool Icon") > > 6. If you have a Wacom Intuos tablet (and Grapphire too, I believe) you >have a right mouse button emulator on the pen body. Such a button >is often on pens of other models as well. Press this right mouse button >emulator now. > > 7. Do you obtain a right mouse button Image menu? Please report "yes" or "no" >to this news group, plus your tablet model and X Input device driver >(If you know). I have a Wacom Intuos attached to an SGI O2, and the driver >is the Wacom Tablet Driver for Intuos tablets Version 4.4.0 (SGI) Notebook, Celeron 333, XFree86 3.3.6, Intuos A5: I get a context menu. For the misbehaviour I do not need to be inside the selection. If I make a selection, select e.g. a paint-tool, paint someting (in- or outside the selection) and while pressing the pen down press the "right mousebutton" a menu pops up. When selecting something (e.g. tearing the menu off) the marching ants die. When opening a new image they are alive for the new image. This also happens without the "AlwaysCore" mode. Then the mousepointer does not move with the tablet. Setting the Mode of the pen to "Window" lets gimp draw its own cursor, the tablet is mapped to the image window. Create a selection, select a paint tool and move the core pointer to the image, using the mouse. Then use the pen to paint something and press the right button of the pen. The menu will open. Selecting something makes the ants die. The Artpad II is interesting too: IIRC the protocol is a little bit fuzzy about the difference between tapping on the tablet and pressing the right button vs. the eraser side of the pen. The XFree86-Driver starts switching between the Pen and the Eraser very fast. Sometimes the ants die, sometimes not. The behaviour is unclear. > I get a right mouse button Image menu, as if I had pressed the (actual) > right mouse button in ungrabbed gdk_pointer mode. Had I omitted steps > 1.a - 1.e and followed the remaining steps with either the mouse or the > pen (Device status shows "Core Pointer" active), the generation of a right > mouse button Image menu does not occur after step 5 "press down and move...". > With the pen pointer (or left mouse button) pressed, the right mouse button > appears to be ignored. I can confirm this. Additionally pressing the right button of the mouse when the pen is pressed onto the tablet will also be ignored. > I would like to obtain a sense of how widespread this phenomenon > is. Marc Lehmann reported to this list that he observed it on Simon > Budig's machine at Systems'99, but not his own, and I believe Simon > has a tablet/driver/machine quite different from an SGI O2. [See Re: > Gimp help docs thread]] It is possible that the graphire Marc had is more similiar to the Artpad than to the Intuos. I will dig a little bit in the XFree86-Driver. Hopefully we can fix this in a sensible manner. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Call for hackers: GIMP-GIFT integration
Hi, I am the maintainer of the GIFT, the GNU Image Finding Tool. The GIFT was programmed as part of the Viper project. When Viper was accepted as GNU package (under the condition that we commit to furnishing some more docs), we renamed it GIFT. The GIFT enables you to search for images by their content. This means you do not have to annotate (i.e. put keywords on) the images to do similarity searches on them. GIFT is a server framework that communicates with the outside world using an XML-based communication protocol, MRML. This protocol is simple and extensible. Currently, the only MRML compliant client for the GIFT is SnakeCharmer, mainly written by Zoran Pecenovic from EPFLausanne. This client is written in JAVA, and Zoran and I are currently working on fixing the last glitches we experience with Kaffe. It runs decently on JAVA. This is nice, as we can use this pair for web demos like: http://viper.unige.ch/demo.html (this demo might be down, as we are currently changing our server hardware). This we already find quite cool :-) What we would like to have: -- Cooler, however, we would find a tight integration into the GIMP. Just imagine doing query by example (QBE) from the GIMP: take the current image/layer from the GIMP, and do some QBE by operating some popup menu. This would allow for query-by-sketch etc. . Imagine more: such an MRML client would enable you to query GIFTs everywhere. Imagine this http://gimp-savvy.com/PHOTO-ARCHIVE/index.html with content-based indexing. Imagine querying this with the GIMP, without leaving the GIMP, and directly downloading images you have found as layers into the GIMP. What would be to do: --- We have already some Perl routines that support XML (=> MRML). What would be needed would be to get inspired by SnakeCharmer and create a neat GIMP plugin. The other part that still needs quite an amount of improvement is the treatment of images that are new to the collection. Indexing is too slow to be done on the fly, but I guess we would find a solution for that if there is a GIMP plugin. Do you have any thoughts about that? Is there any volunteer, or volunteer group? I would be happy to help in taking the decision. Cheers, Wolfgang -- Wolfgang Müller, assistant-doctorant Group Home Page: http://vision.unige.ch/ Viper's new name is: The GIFT. The GIFT is the GNU Image Finding Tool! Get it at: ftp://ftp.gnu.org/gnu/gift/
Re: Python-Plugin for Gimp - what happened?
On Mon, Nov 13, 2000 at 03:30:35PM +0100, Simon Budig <[EMAIL PROTECTED]> wrote: > will not be build, even with --enable-python. > > Is there a special reason for the need of the latest automake features? Simply put, automake cannot build anything python-related and cannot built anything perl-related as well. Just like gettext, the non-C/C++-support is nonexistant. At the time the python plug-in was added to the source, it's autrhor told me that the python patches for automake would be part of the next automake release (1.5), maybe it's time to check the automaqke cvs and simply reequire automake-1.5-pre or something. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Python-Plugin for Gimp - what happened?
Hi all. I'd like to know what happened to the Pygimp-Plugin. There is a strange comment in Makefile.in: # This has been modified slightly. The Makefile.am file has been moved to # Makefile.am.14 because it uses some non standard extensions. This should # be resolved when automake-1.5 comes out. I guess, the non-existance of Makefile.am is the reason why the plugin will not be build, even with --enable-python. Is there a special reason for the need of the latest automake features? I have no clue about these tools, so could someone please help? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Tablet Testing Needed!
Garry R. Osgood ([EMAIL PROTECTED]) wrote: > I was delighted this weekend to uncover a cause to #10498: "Marching > Ants die untimely deaths" which has been pestering me for sometime > now. Whoo ho! > I would like to obtain a sense of how widespread this phenomenon > is. Marc Lehmann reported to this list that he observed it on Simon > Budig's machine at Systems'99, but not his own, and I believe Simon > has a tablet/driver/machine quite different from an SGI O2. [See Re: > Gimp help docs thread]] I have at the moment no tablet available so i cannot try to reproduce this now. I definitely will try this tomorrow. But the Machine at the systems was an Intel-Machine with 128 MB Ram. The tablet was an Intuos A5 with serial connector plus lots of different pens (3 intuos Pens, 2 Stroke pens, 1 Airbrush, 1 4D-Mouse, 1 inking pen), the X-Server was a 3.3.6 XFree86. Thanks for hunting in this area! Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Tablet Testing Needed!
Hi,
I was delighted this weekend to uncover a cause to #10498: "Marching
Ants die untimely deaths" which has been pestering me for sometime
now. The immediate cause stems from the pause count in the Selection
structure being incremented more often than being
decremented. [selection.c CVS-1.6 selection_pause() L. 590,
selection_resume() L. 600, selection_start() L. 627]
The underlying cause to the asymmetry is a bit troubling, for which I
will need some testing help on a wider range of hardware. It appears
that when the Wacom Tablet device is active, it is possible to
originate a right mouse button event to bring forth an application
menu, for example, even when the pressure point is active (and
functioning somewhat like the left mouse button). In particular, this
behavior undermines some assumptions implicit in init_edit_selection()
and edit_selection_release() about actually seeing a left button
release. [edit_selection.c CVS 1.34]. which assumes, (mostly
correctly, perhaps) that once a gdk_pointer_grab() has been performed,
it darn-tootin' *will* see the left button release to unwind the
selection pause count and the gimp_undo_freeze() among other
interesting things.
More about that later, first I would like tablet users [and not just
Wacom tablet users] to perform a nice little torture test on their
Gimp and post results here to determine how widespread this difficulty
may be. (I think any 1.1.2x Gimp version will do, as pertinent code
areas have not changed much lately)
0. Start Gimp. New Image (Cntl-N).
[Optional: ->Preferences->Image Windows->Cursor Mode is "Tool Icon"]
1. Activate the tablet device.
a. ->Dialog->Device Status... (handy device monitor)
b. ->Dialog->Input Devices...
c. Select your tablet device (mine is named "wacom", yours may differ)
d. Switch your tablet device Mode: to "Screen"
e. Confirm: your device should add itself to the "Device Status"
display picked in step 1.a. but be inactive ("pushed out" label)
2. Pick up your pen and bring it in proximity to the drawing tablet
a. Confirm: your device should become active ("pushed in" label)
3. Conveniently, the Rectangular Select Tool is already active. Make a
selection with it.
a. Confirm: Marching Ants appear around the selection border.
4. With pen still in hand, move to the interior of the selection region.
5. Press down and move the pen (this activates init_edit_selection()
and Edit Select tool methods that over-ride the rectangular select tool-set.
also, the pause reference count is incremented in the currently active
Selection object; gimp_undo_freeze() had already been invoked
in a rectangular tool method context)
a. Confirm: Move cross icon appears. (if Cursor Mode is "Tool Icon")
6. If you have a Wacom Intuos tablet (and Grapphire too, I believe) you
have a right mouse button emulator on the pen body. Such a button
is often on pens of other models as well. Press this right mouse button
emulator now.
7. Do you obtain a right mouse button Image menu? Please report "yes" or "no"
to this news group, plus your tablet model and X Input device driver
(If you know). I have a Wacom Intuos attached to an SGI O2, and the driver
is the Wacom Tablet Driver for Intuos tablets Version 4.4.0 (SGI)
I get a right mouse button Image menu, as if I had pressed the (actual)
right mouse button in ungrabbed gdk_pointer mode. Had I omitted steps
1.a - 1.e and followed the remaining steps with either the mouse or the
pen (Device status shows "Core Pointer" active), the generation of a right
mouse button Image menu does not occur after step 5 "press down and move...".
With the pen pointer (or left mouse button) pressed, the right mouse button
appears to be ignored.
In getting a right mouse button menu (Device status shows "wacom" and it is
active), all manner of mischief is now possible, undermining the assumptions
about pointer state underlying edit_selection code. This appears to range
from:
A. no mischief at all (the right mouse button emulator is immediately
released: no menu selection is made)
B. some mischief (The button release event is missed if a menu selection
occurs. Nothing ever decrements the Selection object reference count
and -- unbalanced -- the selection remains paused until application
exit: Bug #10498)
C. Great Mischief (If the pointer moves outside the Gimp Image window after
step 5 "press down and move the pen..." then it appears that the
specialized edit-selection tool remains in control well after its designers
intended: it's edit_selection_button_release() method does not get called
in a timely fashion, gimp_undo_thaw() is not immediately called
either, so undo events can be lost if the user proceeds with further
image manipulation.
I would like to obtain a sense of how widespread this phenomenon
is. Marc Lehmann reported to this list that he observed it on Simon
Budig's machine at Systems'99, but not his own, and I belie
Re: Bug#60647: acknowledged by developer (gimp swap / temp files belong in $TMPDIR or /tmp if $TMPDIR is unset)
On Sun, Nov 12, 2000 at 09:38:03PM -0500, Brian Ristuccia <[EMAIL PROTECTED]> wrote: > To those on gimp-developer: > > My gripe is that gimp ignores $TMPDIR, the default location is in my home > directory which is on a slow NFS mount, and specifying /tmp is unsafe. Yes, it's almost always better to follow the standard... -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
