Re: Modifier keys

1999-11-10 Thread Jukka Rajala

Sven Neumann wrote:


 What a perfect mess!! Suggestions on how to make this useful and
 consistent are welcome...

Opinion: I feel it would be reasonable to create unified set of modifier keys...
Shift is always a positive thing (add, copy...) , Ctrl is always the
opposite (remove, cut...) and Alt is always the alternative (different
target...)

For example in the move tool shift+click would create a copy of the current
selection and move it. Ctrl-click would just move the current selection (default
action, even without the modifiers) and Alt-shift/ctrl-click would make the
action to affect the current layer instead of the selection.

This should be consistent thrue-out the whole gimp (including plug-ins) and even
thrue-out the whole GNOME...



--
Jukka Rajala - [EMAIL PROTECTED] - http://www.saunalahti.fi/rjala/





Re: Help System

1999-11-10 Thread Sven Neumann

Hi,

 The idea of a help system as part of GIMP sounded interesting and I had
 hoped to try it out and comment on it but I now discover I won't be able 
 to do so.

There are many things you can do about this: 

- Install the gnome-libs package. This will not change your desktop into 
  a gnome one, but install a set of useful libraries that you will want 
  to use anyway sooner or later. I must admit that this is not a solution
  for non-Linux users as getting gnome-libs to compile is not trivial.

- Grab GtkXmHtml seperately. This is difficult at the moment, but I was 
  told that the gEdit application offers a seperately bundled one.

- Help us to make a seperate version of GtkXmHtml that compiles on a lot
  of setups and fix the Gimp configure script.


Salut, Sven





Re: the ultimate solution to the i18n problem...

1999-11-10 Thread Ian McKellar

On Wed, Nov 10, 1999 at 03:50:56AM +0100, Marc Lehmann wrote:
 On Tue, Nov 09, 1999 at 09:31:05PM -0500, [EMAIL PROTECTED] wrote:
 
  What if _every_ text widget - static labels in particular - was
  clickable and allowed the user to modify the translation and submit it
  to a central server?
 
 If it isn't a central server but a local .rc file (that could be sent in by
 translators) then I would think this sounds very cool.

Local .rc file which can be uploaded to the central server through a dialog
box somewhere.
 
 But it is alos very difficult to implement (I think). It would also belong
 into gtk+.

Yes, it would definately deserve to be part of GTK...
 
  translated, simply alt-rightclick on it in the menu and select
  "French" and enter the translation. The next time anyone in the world
  starts the GIMP it contacts the server and gets the translation.
 
 That's too radical. It would be abused (yes, it would!).

Not nececarilly.

People could be required to GPG sign their uploads, and users could choose
to allow translations signed by certain users.

Ian

-- 
Ian  McKellar | Email: yakk(a)yakk.net   | Web: http://www.yakk.net/
Fax/VoiceMail: +61 (8) 9265 0821 | Home: +61 (8) 9389 9162



Re: Help System

1999-11-10 Thread Austin Donnelly

On Wednesday, 10 Nov 1999, Sven Neumann wrote:

 - Grab GtkXmHtml seperately. This is difficult at the moment, but I was 
   told that the gEdit application offers a seperately bundled one.

If gEdit needs GtkXmHtml, and so does Gimp, does this not mean there's
a real requirement to make GtkXmHtml a standard part of libgtk?

Maybe the time has come to fold GtkXmHtml into the main library.  We
should talk to the gtk people.  Tim, Owen?

Austin



Re: [gimp-devel] Re: Help System

1999-11-10 Thread Tor Lillqvist

 Maybe the time has come to fold GtkXmHtml into the main library. 

Ugh... cough, cough. Have you looked at the GtkXmHTML (or however it
should be capitalized) source code? One would hope GTk+ has higher
standards. Not to mention that the "Gtk" part of the GtkXmHTML name is
quite misleading, there are lots of direct Xlib calls.

--tml



Re: Help System

1999-11-10 Thread Federico Mena Quintero

  - Help us to make a seperate version of GtkXmHtml that compiles on a lot
of setups and fix the Gimp configure script.

Just so you know, GNOME is dropping GtkXmHTML because it is no longer
being maintained and is not very good in general.  Anders is working
on a very nice GtkHTML widget, and the new GNOME help browser will use
it while Mozilla will hopefully be finished somewhere in the next millenium.

The GIMP should really use the GNOME help browser instead of
reinventing the wheel.

  Federico



Re: Help System

1999-11-10 Thread Zach Beane - MINT

On Wed, Nov 10, 1999 at 11:10:14AM -0500, Federico Mena Quintero wrote:
   - Help us to make a seperate version of GtkXmHtml that compiles on a lot
 of setups and fix the Gimp configure script.
 
 Just so you know, GNOME is dropping GtkXmHTML because it is no longer
 being maintained and is not very good in general.  Anders is working
 on a very nice GtkHTML widget, and the new GNOME help browser will use
 it while Mozilla will hopefully be finished somewhere in the next millenium.
 
 The GIMP should really use the GNOME help browser instead of
 reinventing the wheel.

Will it be possible to get just the wheel without the rest of the car?

Zach
-- 
Zachary Beane   [EMAIL PROTECTED]
PGP mail welcome.   http://www.xach.com/pgpkey.txt



Re: Copyright on icons ...

1999-11-10 Thread Tuomas Kuosmanen

On Wed, Nov 03, 1999 at 03:40:39PM +, Lee Willis wrote:
 Just a quick question. What is the copyright status on the icons used in
 the Gimp. The reason that I'm asking is that we'd quite like to use the
 "New Layer" icon from the gimp (Copy attached) on out company site as
 part of a link to produce printer-friendly versions of pages. Is this
 OK?  Credit will of course be given, I presume I just credit the Gimp
 project as a whole, do I also have to provide a link to the GPL?
 


I dont know :) 

To avoid the problem, I thought it was less effort to draw a new 'paper'
icon for you from scratch than to dig up a discussion about the licenses :)


- http://tigert.gimp.org/files/temp/sheet.gif

I place this in the publice domain. Enjoy :)

Greetings

Tuomas Kuosmanen

-- 

.---( t i g e r t @ g i m p . o r g )---.
| some stuff at http://tigert.gimp.org/ |
`---'



Re: I18N

1999-11-10 Thread Daniel . Egger

On  9 Nov, Sven Neumann wrote:

 Daniel Eggert wrote:

 BTW: My name spelled E g g e r without any 't'

 Ok, here's my setup:
 
  glib: uptodate from CVS (1.2 branch)
  gtk+: uptodate from CVS (1.2 branch)
  gimp: uptodate from CVS
  glibc: libc-2.0.7  
 
 Well, my version is glibc is a bit outdated, but internationalisation
 has worked before with this version of the glibc. All I changed was
 Glib, Gtk+ and Gimp.

 Interesting. I'm using the same stuff but didn't experience any
 problems. Hm, did anything in gtk+ change in the last few days?

-- 

Servus,
   Daniel



Re: Re: Tile Cache Size

1999-11-10 Thread Tuomas Kuosmanen

On Tue, Nov 09, 1999 at 11:59:58AM +1000, David Bonnell wrote:
 On Tue, 9 Nov 1999, Ewald R. de Wit wrote:
 
  Anyway, today I went over the Gimp sources and noticed how complicated
  the tile architecture makes things and I couldn't help wondering why
  the heck it was put in. All it seems to do is to give you an order of
  magnitude slower speed when dealing with large images. And large
  images were supposed to be the very reason for a tiling architecture.
  
 I'm afraid I have to agree with you on the performance WRT large images.
 I tried editing a couple of large images yesterday (10MB/600dpi) and it
 was painfully slow (Dual 300MHz PII, 128MB RAM).  I've got a 20MB/1200dpi
 one I want to edit and I'm not looking forward to it!

Getting more than 128MB ram does help. Actually, the more the better. I cant
think of too much. I have 380MB at work and manipulating large scans is
_considerably_ faster than with similar cpu but less ram (which is kinda
obvious anyway) 

Also, like someone pointed out, put as much tile-cache as you have free ram
for gimp.

Sucks to have earthquakes in Taiwan just now kicking ram-prices up.. :( 
Tuomas 

-- 

.---( t i g e r t @ g i m p . o r g )---.
| some stuff at http://tigert.gimp.org/ |
`---'



Re: [gimp-devel] Re: Help System

1999-11-10 Thread Marc Lehmann

On Wed, Nov 10, 1999 at 12:26:58PM +0100, Simon Budig [EMAIL PROTECTED] wrote:
 in the Gnome-Libs, because some people refuse to install gnome
 (I dont know why, but there are those people...)

Here is a good reason: gnome is large. TOO LARGE. And if you do not want
to use the gui it is a big price to pay just for a simple help window.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Modifier keys

1999-11-10 Thread Uwe Koloska

Austin wrote on Tuesday, 09 Nov 1999:
Again, I'd recommend someone finding out what PhotoShop's modifiers
do, and just blatantly copy them.  I have two reasons for this:
   a) people used to PS will like this.
   b) some team at Adobe has already done usability testing -
  we can reuse their work.

I have looked everywhere on the photoshop CD but there is no document
describing the shortcuts in short.  With Photoshop came a reference card and if
someone wants to make it in a ascii table, I can send her/him a picture of it
(but beware: it's in german).

On the Adobe Website I have found a document called crossprod.pdf (214034 Byte)
that show's
CROSS PRODUCT KEYBOARD SHORTCUTS
for Adobe Photoshop 5.0, Adobe Illustrator 8.0 and Adobe PageMaker 6.5

maybe this is a good starting point.  If you can't find this doc at Adobe I can
mail it or ftp it to a common place.

BTW: AFAIS photoshop isn't consitent at all with keybindings -- but I don't use
PS but Gimp ;-))

Yours Uwe

-- 
mailto:[EMAIL PROTECTED]
http://rcswww.urz.tu-dresden.de/~koloska/
----
right now the web page is in german only
but this will change as time goes by ;-)



Re: the ultimate solution to the i18n problem...

1999-11-10 Thread Marc Lehmann

On Wed, Nov 10, 1999 at 06:18:54PM +0800, Ian McKellar [EMAIL PROTECTED] wrote:
  If it isn't a central server but a local .rc file (that could be sent in by
  translators) then I would think this sounds very cool.
 
 Local .rc file which can be uploaded to the central server through a dialog
 box somewhere.

while (on irc) I came to the conclusion the original idea had more hack
value, doing it "on demand" also solves the online/offline problem.

 People could be required to GPG sign their uploads, and users could choose
 to allow translations signed by certain users.

certain users != all users ;-

but I think local modifications (read that as customization) would be nice in
itself. remeber the menu shortcuts? why not set a new ui standard AGAIN?

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Clean up and Re: Help System

1999-11-10 Thread Marc Lehmann

On Thu, Nov 11, 1999 at 01:11:54AM +0100, Olof S Kylander [EMAIL PROTECTED] wrote:
   * All Script in Xtns should be under ZZ-Fu
 (ZZZ == Lang)

I strongly disagree. From a usability perspective this is nonsense. It might
be nice for a user to know whom to blame for the script (but the language
does not help much), but otherwise the user just has to memorize one fact
more.

It's difficult enough to remember wether a plug-in belongs to (e.g.)
xtens/render or xtns/draw. Having to remember the language in which the
plug-in is written (which means _nothing_ to most users) is only an
additional burden.

 all scripts - Gimp's menu structure will be expanded by "two",
 making it even more bulky to work with. The fact that
 small scripts that can be "undo awar"e are placed in non logical place
 (i.e under Script-XX. Makes scripts even more messy to use.

While this is mostly true, some perl scripts are very useful to all users.
the problem is that the expensive of installing gimp-perl to "just" get a few
standard plug-ins is relatively high.

But there are worse things than that...

PS: I have not _yet_ read your whole mail, but I seem to agree with the rest
;)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Tile Cache Size

1999-11-10 Thread Uwe Koloska

Nich Lamb wrote on Die, 09 Nov 1999:
Why does my 7274 x 9985 RGB image (212743Kb of data by my calculations)
result in the creation of a gimpswap which is up to 500Mb in size?

Where do you think can the undo information reside???

Uwe

-- 
mailto:[EMAIL PROTECTED]
http://rcswww.urz.tu-dresden.de/~koloska/
----
right now the web page is in german only
but this will change as time goes by ;-)



Tile cache leaking?

1999-11-10 Thread Nick Lamb


Further to my original observations, here is something more detailed:

Gimp is set to ~24M tile cache, on a 64Mb machine with ~64Mb of swap
The TIFF is enormous (see previous post for exact dimensions) and as a
naive RGB array (3 bytes per pixel) would use ~210Mb of space

Stage --- Size of gimpswap

Fresh gimp, no images  N/A not yet created
Begin loading TIFF 10Mb almost immediately
50% loaded 98Mb
99% loaded 196Mb (just as TIFF loader exits)
Starts displaying  250Mb
50% complete display   380Mb
100% complete display  508Mb

Then, as tigert says, the Gimp continues to trickle data into the swap
file for some time, but only a few Mb per minute.

The TIFF loader created (by my estimate) 210Mb of tiles. There are now
508Mb of tiles on my disk. What is in the 300Mb of tiles which were NOT
created by the TIFF loader?

Suggestions of how to find out are welcome, but a fix is preferred :)

Nick.



Re: Tile Cache Size

1999-11-10 Thread Nick Lamb

On Thu, Nov 11, 1999 at 01:40:28AM +0100, Uwe Koloska wrote:
 Nich Lamb wrote on Die, 09 Nov 1999:
 Why does my 7274 x 9985 RGB image (212743Kb of data by my calculations)
 result in the creation of a gimpswap which is up to 500Mb in size?
 
 Where do you think can the undo information reside???

I would guess that when I actually DO something there will an appropriate
number of additional tiles allocated in the swapfile. Experience agrees.
Give or take tile leaks, which now tigert has mentioned them, explain
this problem very well...

Why? Where do YOU think the undo information goes?

Nick.