Re: [Gimp-developer] Bug Week!

[Michael Schumacher]

On 5 Sep 2003 at 23:23, Tor Lillqvist wrote:

> What do you think, should I perhaps build a fresh Win32 build of GIMP
> 1.3 for the bug week, 

Can't hurt to have this.

> and announce it on gimpwin-users? Or will we get
> overloaded by non-bugs like problems with installing GIMP 1.3 on
> Windows?

Well, installation problems are bugs that indicate the lack of idiot-proof 
documentation. Unfotunately, Win32 users seem to lose the ability to read 
installation instructions at all.

But it is certainly better to find any Win32 specific bugs now than after the 
2.0 release.

HTH,
Michael
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Screenshot plug-in status

[Sven Neumann]

Hi,

Tor Lillqvist <[EMAIL PROTECTED]> writes:

> Henrik Brix Andersen writes:
>  > Using gimp_pixel_rgn_set_row() may work for some images, but since
>  > GdkPixbufs internally have aligned data which may result in padding
>  > garbage inserted between two rows, you will need to use
>  > gdk_pixbuf_get_rowstride() and iterate over the rows one by one.
> 
> But couldn't one at least check if gdk_pixbuf_get_rowstride()
> indicates that there isn't any padding, and in that case use
> gimp_pixel_rgn_set_rect()? At least on my aging PIII-450, the
> difference in speed is huge.

I am surprised that this makes any noticeable difference and I think
it would be worth to check the reason for this. A much simpler
optimization would probably to set a reasonable tile_cache size. At
the moment the new screenshot plug-in fails to do that.


Sven

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] "Ken Burns" style animation tool: standalone or plug-in?

[Tor Lillqvist]

Daniel Rogers writes:
 > hmm, last time I checked, plugins run in a different process space, so
 > setting up callbacks is a bit more difficult than normal.

Well, obviously I meant callbacks using the normal PDB mechanism, and
not directly.

--tml


___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] "Ken Burns" style animation tool: standalone or plug-in?

[Daniel Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tor Lillqvist wrote:
|  > > Should there be some way for plug-ins to register interest in getting
|  > > callbacks when paths nodes are moved/added/deleted, etc?  Other
|
|  > i think that would be useful.
|
| Yup. Any comments from core developers? Would implementing callbacks
| to plug-ins be straightforward, or is there some gotcha? Or should
| plug-ins just poll frequently to see if a path/selection/whatever has
| been edited?
hmm, last time I checked, plugins run in a different process space, so
setting up callbacks is a bit more difficult than normal.  There are a
coupla schemes that could work, including copying the args into shared
memory, and telling the plugin to invoke the process, RMI over a unix
socket, etc, however, the gimp process can't just invoke the callback in
the plugin as though the plugin was a shared lib.
So, to answer your qestions, no, it is not straightfoward, yes, there is
a gotcha but yes, it is possible.
- --
Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/W8Gfad4P1+ZAZk0RAk9LAJ92fqjvOVBg96atQuUWJ5Up1+k/HwCfasm1
SoPKEpyo+/6lRfMxpUHBuC8=
=hrg2
-END PGP SIGNATURE-
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: [Gimp-user] [Fwd: Gimp interface streamlining]

[Willie Sippel]

Hi there.

On Sun, 2003-09-07 at 13:24, Sven Neumann wrote:
> Hi,
> 
> "Adam D. Moss" <[EMAIL PROTECTED]> writes:
> 
> > Willie Sippel wrote:
> > > Check my new mockup, I've changed this. It's available at
> > > http://www.zeitgeistmedia.net/gimp/gimpstreamline2.png .
> > 
> > I rather like the way this is going.
> 
> Well, surely the screenshot looks nice. The question is if this is a
> useable interface that is both intuitive to newbies as well as
> productive for experts. The mockup brings up a couple of good points.
> However none of them are really new. A lot of this is implemented in
> the 1.3 series, some points are scheduled for implementation, some
> were dropped.
> 
> I just want to point out that it doesn't make any sense to say yes or
> no to the mockup. It just raises a couple of ideas that need to be
> discussed (and eventually coded).
> 

These suggestions were never about reinventing the wheel, and most of
these 'enhancements' were inspired by some other, professional
applications - so I think most of them are indeed productive. On the
other hand, I don't know about the newbies. But the problem is - as I
see it right now - , that the Gimp is too 'intuitive' for professionals,
and too 'productive' for newbies.
Don't get me wrong, I really like the Gimp, and especially the way it's
going, e.g. gegl. I really admire the work that is done, and I care for
this project - that's why I wanted to give something back.
My mockups and suggestions are intended as a base for discussing those
aforementioned issues.

The basic question is: For what kind of users is/ was Gimp designed?
Judging by the very advanced technical possibilities and the current
roadmap, I would think the project is aimed at professional users...

I would like this thread to become a pool for suggestions, collecting
ideas to improve the usability of the Gimp, and discuss those changes
with the developers.

So, if someone replies to this thread, explain what suggestions you like
(or dislike) and why, and add your own ideas and concerns.

Thank you.

> 
> Sven
> ___
> Gimp-user mailing list
> [EMAIL PROTECTED]
> http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
-- 
Willie Sippel <[EMAIL PROTECTED]>
[ z ] !

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: "Ken Burns" style animation tool: standalone or plug-in?

[Tor Lillqvist]

> Burton Samograd writes:
>  > You should look at Cinellera. 

 > Tor Lillqvist <[EMAIL PROTECTED]> writes:
 > > Hmm... It was strangely hard to find Cinellera using Google, I

Umm yes, that was because it's spelled Cinelerra, not Cinellera...

Still, I find it odd that neither the heroinewarrior.com or
sourceforge pages, nor the source code, mention any names of the
people (one or several) behind this project. (OK, I don't have a
problem with anonymously written software per se, but the author could
at least document then that he/she prefers to be anonymous.) Written
in C++. Few meaningful comments. Lack of READMEs. Very much Linux and
X11 only, and doesn't seem to have been ported even to other
Unixes. Uses its own GUI toolkit. Doesn't use any auto*
machinery. Seems very much to be the work of a "lone fanatic".

Err, no thanks. I have gotten too accustomed to the programming style
and cooperative community of GTK, GIMP etc.

--tml


___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Bug Week!

[Sven Neumann]

Hi,

Tor Lillqvist <[EMAIL PROTECTED]> writes:

> What do you think, should I perhaps build a fresh Win32 build of GIMP
> 1.3 for the bug week, and announce it on gimpwin-users? Or will we get
> overloaded by non-bugs like problems with installing GIMP 1.3 on
> Windows?

We will very likely do a 1.3.20 release for the bug week and I would
appreciate if we could offer a Win32 build (and packages for other
platforms) based on that release.


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Bug Week!

[Branko Collin]

On 5 Sep 2003, at 23:23, Tor Lillqvist wrote:

> What do you think, should I perhaps build a fresh Win32 build of GIMP
> 1.3 for the bug week, and announce it on gimpwin-users? Or will we get
> overloaded by non-bugs like problems with installing GIMP 1.3 on
> Windows?

We will probably get overloaded with non-bugs and multiple reports of 
real bugs. What's the problem with that?

If there's any triage needed for these, to weed out the doubles, I'd 
be glad to help out.

Any chance, BTW, of fixing that weird floating point GTK bug anytime 
soon? () It's a 
real stopper for me.

-- 
branko collin
[EMAIL PROTECTED]
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: [Gimp-user] [Fwd: Gimp interface streamlining]

[Sven Neumann]

Hi,

"Adam D. Moss" <[EMAIL PROTECTED]> writes:

> Willie Sippel wrote:
> > Check my new mockup, I've changed this. It's available at
> > http://www.zeitgeistmedia.net/gimp/gimpstreamline2.png .
> 
> I rather like the way this is going.

Well, surely the screenshot looks nice. The question is if this is a
useable interface that is both intuitive to newbies as well as
productive for experts. The mockup brings up a couple of good points.
However none of them are really new. A lot of this is implemented in
the 1.3 series, some points are scheduled for implementation, some
were dropped.

I just want to point out that it doesn't make any sense to say yes or
no to the mockup. It just raises a couple of ideas that need to be
discussed (and eventually coded).


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Bug Week!

[Michael Schumacher]

On 4 Sep 2003 at 18:07, Henrik Brix Andersen wrote:

> See you at The GIMP Bug Week!

If this announcement is supposed to attract users, it should be more specific 
about the skills that are required to participate in Bug Week.

Questions like "What version of GIMP will I have to test?" and "I can't code. 
Is this a problem?" come to my mind. 

I think that I know the answers, but discussions on irc have shown that my 
understanding of a bug week seems to be a bit different from what it should be, 
so an official statement would be better.

HTH,
Michael 
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Scale Constrained

[Sven Neumann]

Hi,

Jonathan Bartlett <[EMAIL PROTECTED]> writes:

> I wrote a small but useful script that will scale an image to best fit
> within a constrained size without affecting aspect ratio.

I might miss something obvious, but I think this can be easily
achieved using the existing Scale Image GUI.

> Also on that page is a templated images script, which is really,
> REALLY basic at the moment, but basically allows you to easily
> create image-based templates (think Print Shop).

Please note that the term Template is already taken in GIMP-1.3.
Templates are available in the File-New dialog and can be just an
image size or even point to a template XCF to load.


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] Re: "Ken Burns" style animation tool: standalone or plug-in?

[Tor Lillqvist]

Burton Samograd writes:
 > You should look at Cinellera. 

Hmm... It was strangely hard to find Cinellera using Google, I
actually first found the Slashdot discussion, from which was a link to
the firm's pages. http://heroinewarrior.com/cinelerra.php3 says:

  RECOMMENDED FRONT END SYSTEM [...] Dual 2Ghz Athlon.

  RECOMMENDED RENDERFARM NODE: Single 2.4Ghz Athlon.

Sure.

Sounds way overkill.

--tml


___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Screenshot plug-in status

[Henrik Brix Andersen]

Hi,

On Sat, 2003-09-06 at 09:16, Tor Lillqvist wrote:
> Henrik Brix Andersen writes:
>  > It would be nice if someone on say... win32 ;)... would have a go at
>  > writing the missing win32 part of the select_window() function.
> 
> I get the hint ;-). I'll have a look at it. 

Hehe - was the hint that obvious?

> Grabbing the whole screen with screenshot (without any Win32 specific
> code yet) was *much* slower than with winsnap. It was the image
> transfer phase from the plug-in to GIMP that was a lot slower. I tried
> to change the code to just call gimp_pixel_rgn_set_rect() once, like
> winsnap does, instead of calling gimp_pixel_rgn_set_row() in a
> loop. And it is now much speedier. Do you see any reason why this
> should not be done? (Maybe also call gimp_tile_cache_size(), although
> calling it like winsnap.c does results in black screendumps, oddly
> enough.)

Using gimp_pixel_rgn_set_row() may work for some images, but since
GdkPixbufs internally have aligned data which may result in padding
garbage inserted between two rows, you will need to use
gdk_pixbuf_get_rowstride() and iterate over the rows one by one.

If you can come up with a better (faster?) solution to this problem
please don't hesitate to commit it.

>  > When the win32 specific part of select_window() has been written and
>  > committed I plan to retire the win32 specific winsnap plug-in in favor
>  > of the new screenshot plug-in.
> 
> BTW, shouldn't it be possible to write select_window() using only GDK?
> gdk_pointer_grab() and, hmmm, well I'll think about it.

Unfortunately this doesn't seem to be possible. Believe me, I've tried
:(. Since GDK knows nothing about other programs windows there is no way
of obtaining the window ID (XID or HWND) for these using plain GDK.

I have close to no experience in MS Windows programming, but using Xlib
you can use the subwindow member of the Xevent struct to get the ID of
the window which recieved the event. GDK events structs has no such
member.

> (Wonder why it seems to take so long for messages to go through
> [EMAIL PROTECTED] Two or three days. Sobig.F?)

Nope. Apparently lists.xcf.berkeley.edu is running low on RAM - please
see http://bugzilla.gnome.org/show_bug.cgi?id=121086

Sincerely,
./Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Screenshot plug-in status

[Henrik Brix Andersen]

On Sat, 2003-09-06 at 18:55, Tor Lillqvist wrote:
> Henrik Brix Andersen writes:
>  > Using gimp_pixel_rgn_set_row() may work for some images, but since
>  > GdkPixbufs internally have aligned data which may result in padding
>  > garbage inserted between two rows, you will need to use
>  > gdk_pixbuf_get_rowstride() and iterate over the rows one by one.
> 
> But couldn't one at least check if gdk_pixbuf_get_rowstride()
> indicates that there isn't any padding, and in that case use
> gimp_pixel_rgn_set_rect()? At least on my aging PIII-450, the
> difference in speed is huge.

Well, I guess you could test if (rowstride / 3 == width) and call
_set_rect() instead of _set_row().

Sincerely,
./Brix
-- 
Henrik Brix Andersen <[EMAIL PROTECTED]>

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Screenshot plug-in status

[Tor Lillqvist]

Henrik Brix Andersen writes:
 > Using gimp_pixel_rgn_set_row() may work for some images, but since
 > GdkPixbufs internally have aligned data which may result in padding
 > garbage inserted between two rows, you will need to use
 > gdk_pixbuf_get_rowstride() and iterate over the rows one by one.

But couldn't one at least check if gdk_pixbuf_get_rowstride()
indicates that there isn't any padding, and in that case use
gimp_pixel_rgn_set_rect()? At least on my aging PIII-450, the
difference in speed is huge.

 > Unfortunately this doesn't seem to be possible. Believe me, I've tried
 > :(.

OK, I believe you...

--tml


___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer