Re: [Gimp-developer] Tags on presets.

2009-08-24 Thread David Gowers
On Mon, Aug 24, 2009 at 3:28 PM, Martin Nordholtsense...@gmail.com wrote:

 I immediately thought of Akira Shirakawa's proposition to move a
 majority of paint tool options into the concept of brushes. IMO doing
 that and using the already existing tagging for brushes would simplify
 the user interface and also the user experience.

 I have also thought a bit on how to clean up the concept of brushes, and in
 my mind, we could do it like this:

 We make a brush be just a bitmap/svg/whatever (possibly also an
 animation). Note that a brush would not even have a spacing as the current
 GIMP gbr brushes.

Right, so what you call a brush here is really more like a 'tip shape'
(assuming that tip shapes can change over time, which seems
reasonable)
definitely +1 on the transferral of spacing -- that illogicality is
really annoying of having that lone option there.
This would mean that we would also need to transfer the concept of
ranks -- that is, a tip shape could specify what ranks it specified,
and the actual meaning of those ranks would be specified in the other
part you specified (the one I'm tempted to call 'tool tip')
Mind you, I'm not sure that the flexibility of GIH brushes is a good
tradeoff for the increase in complexity introduced by essentially
multidimensional arrays of brush images; If it is, then it would help
a lot to have a better way to lay them out (layer grouping
functionality sounds like a good fit here -- one grouping level per
rank.


 A brush preset is a brush + dynamics, and this is actually what the user
 typically picks. If we would have tags for brush presets, we would be one
 step closer to make brush options be part of the brush, so to speak.

.. and I can't help thinking of this as a 'tool tip' :)

This sounds like the best idea yet on this subject.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Tags on presets.

2009-08-24 Thread Alexia Death
On Mon, Aug 24, 2009 at 8:58 AM, Martin Nordholts ense...@gmail.com wrote:

 I have also thought a bit on how to clean up the concept of brushes, and
 in my mind, we could do it like this:

Ive also thought of this.


 We make a brush be just a bitmap/svg/whatever (possibly also an
 animation). Note that a brush would not even have a spacing as the
 current GIMP gbr brushes.


I would call this part stamp or tip. Essentially it would be a
deffinition of the bitmap stamped on the canvas, possibly in form vector
shape.

As to removing spacing from the brush... I believe the default value should
come from the stamp(along with the base size for vector shapes), just
because whats sane for one stamp is not sane for another. Its entirely
dependent on the image in question and its intended use. IT can be optional,
but possible to specify. Perhaps in some formats via a use of a custom meta
data field.


 A brush preset is a brush + dynamics, and this is actually what the
 user typically picks. If we would have tags for brush presets, we would
 be one step closer to make brush options be part of the brush, so to speak.


I can only agree with this if default spacing is part of the brush. If that
is the case, then yes, it would be great. However, I see little point in
differentiating between brush presets and tool presets in general. Having a
dock for listing tool presets and tagging them just like any other resource
would make things a lot easier in a uniform way for ALL tools.

-- 
--Alexia
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] The inside of the active image window doesn't seem to be part of gimp-2.6.exe

2009-08-24 Thread SHIRAKAWA Akira
SHIRAKAWA Akira wrote:
[...]
 It appears that when I hover the pen cursor inside the active image 
 window (where you draw, etc), tablet drivers don't recognize the area to 
 be part of GIMP anymore.

By the way, it appears that the 2.7 development Windows Build (which I 
downloaded from the GIMP-Windows project page) solved this problem.

-- 
SHIRAKAWA Akira
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Tags on presets.

2009-08-24 Thread Martin Nordholts
On 08/24/2009 11:51 AM, Alexia Death wrote:
 A brush preset is a brush + dynamics, and this is actually what the
 user typically picks. If we would have tags for brush presets, we would
 be one step closer to make brush options be part of the brush, so to
 speak.


 I can only agree with this if default spacing is part of the brush. If
 that is the case, then yes, it would be great.

If you by brush mean tip shape + dynamics then I agree. I don't 
think we should use any custom format for the tip shape; PNG or SVG 
should do fine.

  / Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Tags on presets.

2009-08-24 Thread Alexia Death
On Monday 24 August 2009 18:59:53 Martin Nordholts wrote:
 On 08/24/2009 11:51 AM, Alexia Death wrote:
  A brush preset is a brush + dynamics, and this is actually what the
  user typically picks. If we would have tags for brush presets, we
  would be one step closer to make brush options be part of the brush, so
  to speak.
 
 
  I can only agree with this if default spacing is part of the brush. If
  that is the case, then yes, it would be great.

 If you by brush mean tip shape + dynamics then I agree. I don't
 think we should use any custom format for the tip shape; PNG or SVG
 should do fine.

Svg supports custom metadata. I see no problem in supporting a value for it.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Best Gimp Script-Fu Tutorials

2009-08-24 Thread jEsuSdA 8)
El Viernes, 21 de Agosto de 2009 15:57:02 sweeyt escribió:
 Hi,
 I have bookmarked all my favorite Gimp Script-Fu Tutorials at
 http://www.gimp.wisdomplug.com/category/Scrpt-Fu-Writing

Great collection!
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Support for SpaceNavigator

2009-08-24 Thread Sven Neumann
Hi,

On Sun, 2009-08-23 at 15:52 +0200, Håvard Tørring wrote:

 It took me a little while to dig through the various layers, but I
 think I am approaching something that might end up as useful. One
 problem is that the events that are generated are qued up if the
 actions does not perform fast enough. The SpaceNavigator outputs a lot
 of events, and especially the zooming actions are slow. This means
 that with just a brief touch of the spacenavigator, the zoom level
 jumps from minimum to maximum.
 
 I think that it does not make any sense to que up the events from this
 device. Are there any way I can prevent this? Is there any way to know
 if there are pending actions? This could be used to avoid sending new
 actions as long as the previous ones are still pending.

I don't think the actions are queued up. What is more likely is that the
events are queuing up. So what should be done is implementing event
compression on the incoming events. Instead of reading them one-by-one
and creating an action from every incoming event, the linux-input module
should read all the available events from the queue and compress them.
If a number of relative events on the same axis are following each
other, this can be combined into a single relative event with the sum of
all event values. From a series of absolute events all events but the
last can be discarded.

For illustration, here's some code from a different project that does
something similar (though somewhat simpler):


gsize   bytes_read = 0;
struct input_event  buf[8];

if (g_io_channel_read_chars (io,
 (gchar *) buf, sizeof (buf),
 bytes_read,
 NULL) == G_IO_STATUS_NORMAL)
  {
const struct input_event *event;

const gint num   = (bytes_read /
sizeof (struct input_event));
gint   value = 0;
gint   i;

for (event = buf, i = 0; i  num; event++, i++)
{
if (event-type == EV_REL 
event-code == REL_X)
value += event-value;
}

if (value)
; // process the compressed event here
}


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] The inside of the active image window doesn't seem to be part of gimp-2.6.exe

2009-08-24 Thread Sven Neumann
Hi,

On Mon, 2009-08-24 at 14:32 +0200, SHIRAKAWA Akira wrote:
 SHIRAKAWA Akira wrote:
 [...]
  It appears that when I hover the pen cursor inside the active image 
  window (where you draw, etc), tablet drivers don't recognize the area to 
  be part of GIMP anymore.
 
 By the way, it appears that the 2.7 development Windows Build (which I 
 downloaded from the GIMP-Windows project page) solved this problem.

Interesting. I don't think we changed anything related in our code.


Sven


___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] The inside of the active image window doesn't seem to be part of gimp-2.6.exe

2009-08-24 Thread SHIRAKAWA Akira
Sven Neumann wrote:

 Interesting. I don't think we changed anything related in our code.

I've checked again and the 2.6.7 version behaves correctly as well, now.
I haven't made any changes to my system or tablet drivers since I first 
reported this problem.

I think this improvement could be probably due to some changes to the 
GTK+ libraries, which are included with GIMP Windows installers.

-- 
SHIRAKAWA Akira
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Tags on presets.

2009-08-24 Thread Martin Nordholts
On 08/24/2009 06:42 PM, Alexia Death wrote:
 If you by brush mean tip shape + dynamics then I agree. I don't
 think we should use any custom format for the tip shape; PNG or SVG
 should do fine.

 Svg supports custom metadata. I see no problem in supporting a value for it.

If we define a tip shape to be a dump bitmap/vector graphics, then it 
can be problematic (in terms of software maintainability and cleanness 
in design) to also read dynamics data from tip shape data files.

Everything depends on how we define the concepts.

  / Martin

-- 

My GIMP Blog:
http://www.chromecode.com/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Tags on presets.

2009-08-24 Thread SHIRAKAWA Akira
Martin Nordholts wrote:
 If we define a tip shape to be a dump bitmap/vector graphics, then it 
 can be problematic (in terms of software maintainability and cleanness 
 in design) to also read dynamics data from tip shape data files.
 
 Everything depends on how we define the concepts.

I think this is the main problem.
In my opinion the brush should either:

- Be *only* the tip shape and nothing else (leaving dynamics, brush 
settings, etc, to tool options, and therefore, tool presets).

- Include most, if not all, tool and brush options/settings, define the 
tip shape, its behavior, etc, like I proposed a few weeks ago. Brush 
presets would work as tool presets.

Right now we have an unintuitive hybrid: some settings are defined by 
tool settings, some by brush settings.

-- 
SHIRAKAWA Akira
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] Gimp 2.7.0 Text Tool Crashes (built using MinGW/windows)

2009-08-24 Thread BugByteMan
Hello,

Has anybody tried the text tool in Gimp 2.7.0 on windows?

The program crashes with the following error:

Pango:ERROR:pangowin32.c:###:pango_win32_font_finalize: assertion failed: 
(win32font-fontmap != NULL)

Steps to reproduce:

  1. Run gimp-2.7.0
  2. Create new image (Ctrl+N)
  3. Select Text Tool (T)
  4. Click on canvas

Thanks,
BugByteMan


  
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Gimp 2.7.0 Text Tool Crashes (built using MinGW/windows)

2009-08-24 Thread SorinN
I can confirm that
With the previous 2.7 build for windows text tool work ok


2009/8/25 BugByteMan bugbyte...@yahoo.com:
 Hello,

 Has anybody tried the text tool in Gimp 2.7.0 on windows?

 The program crashes with the following error:

 Pango:ERROR:pangowin32.c:###:pango_win32_font_finalize: assertion failed: 
 (win32font-fontmap != NULL)

 Steps to reproduce:

   1. Run gimp-2.7.0
   2. Create new image (Ctrl+N)
   3. Select Text Tool (T)
   4. Click on canvas

 Thanks,
 BugByteMan



 ___
 Gimp-developer mailing list
 Gimp-developer@lists.XCF.Berkeley.EDU
 https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer




-- 
Nemes Ioan Sorin
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer