On 22 Feb, Jens Lautenbacher wrote:
> what remains in this case is that things like clear selection (on the
> bg layer) suddenly start to behave differently, depending if there's a
> layer above the background layer or not. Ick.
> I'd vote for always having an alpha layer. seems to be cleaner
>
On 22 Feb, Sven Neumann wrote:
> The file README.i18n in the gimp tree provides more information
> that might be interesting for you.
Uhoh, that reminds me that it's really needed to rewrite that file...
:)
--
Servus,
Daniel
___
Gimp-devel
On 22 Feb, Sven Neumann wrote:
> We'll face one problem if we decide to make alpha the default for all
> images: A lot of fileformats do not understand alpha and you actually
> don't want to save the alpha channel with the image at all if you
> never touched it. One way to solve this would be to
On 23 Feb, Nick Lamb wrote:
>> Does this mean that you agree to ditching all the special code
>> for the 3 and 1 byte case as well? I'd really love to see this
>> changes although as already stated this might introduce a bit
>> memory overhead in case the user didn't use the alpha channel
>>
On 23 Feb, Michael Meeks wrote:
> I don't know what the gimp protocol is - clearly for _massive_
> chunks of data, shared memory is the only way to go. Vladimir has a
> nice CORBA interface for dealing with setting up shmem chunks to do
> this I think for his video editing toy.
ORBi
On 4 Mar, Sven Neumann wrote:
> Oh, that preferences code really sucks. Hope we will be able to redo
> it properly for 1.4 (eventually using gconf ?!). Anyway, thanks for
> the patch, I'll apply it to both branches.
We should really start discussing which dependencies would be
acceptable to
On 6 Mar, Nick Lamb wrote:
>> We should really start discussing which dependencies would be
>> acceptable to introduce. I'd really like to see gconf for
>> configuration files and freetype2 for fontrendering to get rid of
>> the X dependency and the all time sucker "standard font tool". And
On 6 Mar, [EMAIL PROTECTED] wrote:
>> PS: IMHO we should change the policy for patches. Handling them via
>> FTP has never worked that well. Patches should go to the list
>> (preferably with the word [patch] in the subject) or/and to bugzilla.
> Why not use SourceForge to manage patches?
B
On 10 Mar, peter pajak wrote:
> i've installed gimp 1.2.1, works great, but i can not neither open nor
> save a jpeg file, i had all the required components (jpeg-6b included)
> but still does not work. running on freebsd.
Peter, is JPEG listed as file format in the save dialog?
What does "ldd
On 11 Mar, Austin Donnelly wrote:
> Here's a patch that fixes this, relative to the sobel.c that's in
> 1.2.1. Can someone stick this in stable CVS and also merge it with
> the current development head. Thanks!
Good spotting. Applied to HEAD and GIMP1.2 branch
--
Servus,
Daniel
On 11 Mar, Guillermo S. Romero / Familia Romero wrote:
>> I strongly discourage you however from trying to work with current
>> gimp from CVS HEAD. It should become useable again in a few months.
> Who said work? Install 1.3, test a bit ("oh it loads, oh it paints,
> new color selector, booom,
On 15 Mar, Tom Holroyd wrote:
> Please apply this patch, if it hasn't been applied already...
> Setting values[1] causes a segfault.
Strange that this hasn't been discovered before... Sven already
applied the patch...
--
Servus,
Daniel
___
On 15 Mar, Jens Finke wrote:
>> If this is not possible I'd like to ask, if there is a Gnome
>> booth and if they would mind sharing a booth with us.
> Yes, there will be a Gnome booth with nearly the same crew than the
> last year (about 5 people). Joey (the LinuxTag organisator) promised
> me
On 27 Mar, Zachary Beane wrote:
> Are credit cards of a standard size?
Should be. I wouldn't trust sticking them into a machine otherwise.
--
Servus,
Daniel
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mai
On 2 Apr, Sven Neumann wrote:
> it, rebuild gimp and give it a little testing. Once it gets applied,
> we should consider doing a 1.2.2 release probably including the
> updated HTML help files from the gimp-help CVS module.
That would be nice indeed.
--
Servus,
Daniel
On 5 Apr, Kelly Martin wrote:
> Tiles are 64x64 by default, and changing them is a bad idea because it
> makes your .xcf files nontransportable.
Not to forget that this size is more or less hardcoded.
--
Servus,
Daniel
___
Gimp-developer m
On 21 Apr, Mike Kelly wrote:
> A month ago I submitted two bug reports using Bugzilla. To date, they
> remain in the "UNCONFIRMED" state. I've already patched my version of
> GIMP as per bug 52383, so this doesn't really bother me except that it
> seems to me that others might benefit from it.
On 23 Apr, Raphael Quinet wrote:
> This bug report shows that the default owner is
> [EMAIL PROTECTED] We could do that too, and all bug
> reports that are currently assigned to Daniel could be re-assigned to
> the Gimp bugs list.
Agreed.
--
Servus,
Daniel
___
On 25 Apr, Sven Neumann wrote:
>> I am trying to help Daniel (and others, hopefully) by dealing with
>> the bug reports in bugzilla.
> Have you already changed Bugzilla so it sends email about new
> bug-reports and changes to existing bug-reports?
Impossible so far. We first need a [EMAIL PRO
On 26 Apr, Michael Natterer wrote:
> Seems I am not an administrator (or however this is called in Mozilla)
> for the GIMP module. However when we first talked on IRC about moving
> all bugs to Mozilla we talked about adding Daniel, Yosh, Sven and
> myself as the initial administrators.
> So,
On 26 Apr, [EMAIL PROTECTED] wrote:
> I do, however when I spilled out some rights you hadn't had an
> accout... I'll change that later
Interesting, you already had the rights but Sven didn't. I thought it
was the other round.
Anyway. The initial owner of most of the bugs is now [EMAI
On 30 Apr, Allan West wrote:
> The GIMP documentation, which seems to be aimed at single-user Linux
> boxes, suggests setting its "Tile Cache" to half your physical RAM or
> all of your available RAM. This is obviously not appropriate for 30
> concurrent sessions of GIMP. Can anyone provide a rul
On 27 May, Garry R. Osgood wrote:
> I'll be happy (scratch that: "content") to inventory others and
> document them in bugzilla, where they can be tracked.
> Objections?
Great idea.
> Should "Gimp Web" be a tracking project separate from "Gimp" the
> program?
I'd say that a website for an
On 1 Jun, Raphael Quinet wrote:
> Now I see for the first time a comment saying that some old
> unstable release is more stable than 1.2.x, so I am a bit
> surprised... I would like you to elaborate a bit on the
> stability problems of 1.2.x, and if possible to report this
> in bugzilla.
> If
On 2 Jun, Sven Neumann wrote:
> I'd like to see your script or at least have a description of what it
> did so we can try to debug the behaviour you are describing. Using
> memprof it should be possible to find your leaks.
The last time I checked GIMP with memprof it didn't show any unexpected
On 27 Jul, Sven Neumann wrote:
> Please excuse this inconvenience and let's hope the new tarballs
> work for you.
Really bad idea. This means that there are two versions of 1.2.2
floating around; one which build and one that doesn't. I'd REALLY
suggest to update the version number
Servus
Am Fre, 2003-09-12 um 11.25 schrieb Simon Budig:
> It would be nice to have more keys available to the tools. I'd love
> to get the Del-Key working for deletion of nodes in the path tool...
The del key is a bad choice. Quite a few GIMP users have Apple machines
which don't have a del key.
--
Ser
Am Sam, 2003-09-13 um 23.30 schrieb Marco Wessel:
> It is true that the Apple keyboards that used to come with the iMacs, B/W
> G3s and G4s don't have a del key. However, this keyboard has long since
> been replaced with the full-sized keyboard, which does have the key.
Just curious, where is it
Am Sam, 2003-09-13 um 22.38 schrieb Alan Horkan:
> Delete is such a particularly good and obvious keybinding for Deleting
> things
Actually I believe that having both a backspace and a delete key is
confusing in the original wordprocessing meaning; why would one want to
delete a character followi
Am Die, 2003-09-16 um 19.10 schrieb David Neary:
> [EMAIL PROTECTED]
Is this the official new list for the GTP? If so README.i18n should be
changed.
--
Servus,
Daniel
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Am Mit, 2003-09-17 um 13.29 schrieb Sven Neumann:
> > Is this the official new list for the GTP? If so README.i18n should be
> > changed.
> I might have missed something but what exactly do you think needs to
> be changed in README.i18n?
I read in the thread that the GTP contact address is dead,
Am Son, den 16.11.2003 schrieb Roman Joost um 00:46:
> This is the actual structure. I made a "find ./ -type d" in the gimp-help-2
> and removed the CVS directorys:
Agreed. Howver since a few persons are not too happy with the
all-languages-concurrently approach I'd like to hear their opinion
fir
On Nov 22, 2003, at 3:11 pm, Roman Joost wrote:
I moved the "stylesheets" directory into the source root. I will change
it in the next days, after Daniel will give me the ok. No one has
declined the new structure purposal, so i think, that everyone on
gimp-help-2 gave this implicit OK to change it
On Nov 24, 2003, at 12:02 am, Roman Joost wrote:
I tried it with some docs and it rocks. Unfortunately, i'm running into
trouble with the german umlauts. Do you've a solution for keeping the
umlauts ?
We'll switch to UTF-8 which should solve this problem, unless I'm
misunderstanding the issue, of
On Nov 28, 2003, at 11:29 pm, Roman Joost wrote:
I'll remove the entities, which are mapping the german umlauts to the
correct unicode entity (if i'm right). If i understand Daniel
correctly,
we should be able to write normal umlauts with a proper UTF-8 encoding.
It wasn't clear enough for me, wh
Am Mit, den 10.12.2003 schrieb Roman Joost um 22:55:
> With Raymonds help i'm now be able to build the help with UTF-8 encoded
> XML files, which are "xincluded" in the gimp.xml file.
Cool. Incidently I've also been working on this and my Mac really has
troubles when trying to compile such files
Am Mit, den 17.12.2003 schrieb Roman Joost um 21:30:
> 1. Renaming of the current XML files, that the corresponding help ids:
> app/widgets/gimphelp-ids.h. This is mostly done by me. I'll check the
> changes in as soon as possible.
Huh? Probably it's just me being dense...
> 2. Adding X
Am Don, den 18.12.2003 schrieb Roman Joost um 16:10:
> > Huh? Probably it's just me being dense...
> Heh - no. I shouldn't write mails during a lecture ... The existing XML
> files are renamed to the name of the help ids in
> $GIMP/app/widgets/gimphelp-ids.h, eg: airbrush.xml is now:
> tool-airbru
Am Don, den 18.12.2003 schrieb Roman Joost um 15:53:
> Hm.. i didn't had any memory problems with XInclude. If the encoding was
> wrong, the xsltproc throw an error and nothing more ...
I still do, but only under Mac OSX. More annoying with XInclude is that
xsltproc cannot be taught to really loa
Am Fre, den 19.12.2003 schrieb Sven Neumann um 19:55:
> I am pretty sure it loads the DTD from disk if you provide it an XML
> catalog file that shows it where the DTD is found. This file is
> usually called /etc/xml/catalog. See http://xmlsoft.org/catalog.html
I have this catalog file and xsltpr
Am Fre, den 26.12.2003 schrieb Sven Neumann um 21:49:
> there's another thing I forgot to mention that might be worth to look
> into when it comes to GIMP on Mac OS X. The new compositing code that
> Helvetix added already provides the framework for making use of
> Altivec instructions. If someone
On Jan 5, 2004, at 12:49 am, Roman Joost wrote:
3. I made the corresponding changes to the toolbox XML files and the
stylesheets and added three new options:
a) The processor includes the titles up to section3.
b) The processor chunks the documents up to section3 (Before, all the
tools are
On Jan 10, 2004, at 1:45 pm, David Neary wrote:
I hope these kinds of comments aren't out of place. I have
noticed that commits to gimp-help-2 are fairly infrequent, and
tend to affect lots of files. It is better all round if there are
more frequent commits, each one making a distinct change. This
On Jan 10, 2004, at 4:38 pm, David Neary wrote:
It kind of does - it's not changeset oriented in the way that BK
or Arch are, but checking in several files at once is possible,
and cvs2svn manages to make changesets out of commits that happen
with the same comment, at the same time, by the same pe
On Jan 11, 2004, at 11:00 am, raymond ostertag wrote:
cd ../html/C && /usr/bin/xsltproc --xinclude --nonet
../../stylesheets/plainhtml.xsl ../../src/gimp.xml
Attempt to load network entity
http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd
../../src/gimp.xml:6: warning: failed to load external
lt 10101 and libexslt
801
libxslt 10101 was compiled against libxml 20603
libexslt 801 was compiled against libxml 20603
lucy:/sw egger$ xsltproc --version
Using libxml 20602, libxslt 10100 and libexslt 800
xsltproc was compiled against libxml 20602, libxslt 10100 and libexslt
800
libxslt 1010
On Jan 11, 2004, at 3:23 pm, Sven Neumann wrote:
The DTDs are absolutely necessary in order to process the files.
No, they are not. They are needed for some advanced DOM validation
but one can very well process whole books without it.
http://sven.gimp.org/build-xml-catalog-for-debian.sh
Thanks, w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 20, 2004, at 5:48 pm, Sven Neumann wrote:
Well, actually we'd like to add interpolation to the GIMP canvas as
well. At least optionally. Modern computer hardware seems fast enough
to do this, espec
Am Mit, den 21.01.2004 schrieb Adam D. Moss um 20:28:
> > In OSX many applications tend to provide a quick redraw for pannings
> > but start a timer which will refine the display once it was static
> > for a while.
> Hee hee... it's interesting how things can come full-circle.
> GIMP 0.5[34] did
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 31, 2004, at 12:15 pm, Olaf Marzocchi wrote:
I'd like to retranslate GIMP in italian, the current translation
almost sucks.
I searched the main site but I haven't found anything, couls omeone
tell me
how to do it?
Talk to Daniele Medri <[EMAI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 5, 2004, at 5:20 pm, Sven Neumann wrote:
Are there any numbers you can base this statement on? I don't think
this assumption is correct. Not that it would matter much but I doubt
there are more Win32 GIMP users than Linux GIMP users. I'd also li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 5, 2004, at 7:39 pm, Sven Neumann wrote:
FWIW I'm using GIMP 1.2 under OS X and suspect that there might be
a few freaks who do so, too simply because it's easily to install
if there's fink on the machine.
Installing gimp2 should be about as ea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 5, 2004, at 10:35 pm, <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )>
wrote:
It helps to a) avoid antialiasing (small effect) b) use x fonts (big
effect).
Thanks for this tip. I'll try installing some high quality X fonts
(which is sort of an Oxymo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 5, 2004, at 9:26 pm, Sven Neumann wrote:
You will need Darwinports (http://darwinports.opendarwin.org/) but IMO
darwinports is an improvement over fink. Of course your mileage may
vary.
Too complicated to install, at least I did and since I alr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 6, 2004, at 4:32 pm, Sven Neumann wrote:
Checking out a cvs repository and typing "configure; make; make
install" doesn't sound too complicated to me.
It is, especially when it doesn't work out-of-the-box.
Also this is equivalently complicated t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 6, 2004, at 5:12 pm, Tim Mooney wrote:
I haven't played with OS X enough to know, but does its X server
support
the Render extension? If not, that's probably why GTK+ 2 is slower.
number of extensions:28
Apple-DRI
Apple-WM
BIG-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 6, 2004, at 7:25 pm, Kevin Cozens wrote:
While researching Guile as a replacement for Script-Fu,
Guile is a nasty beast. Gnucash is one of the hardest to
compile and keep working applications just because of their
use of guile. I'm not really su
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 7, 2004, at 1:14 am, Tim Mooney wrote:
As I recall, the SIOD that's part of gimp is not a "stock" version of
SIOD, as there were various bugs detected and fixed in SIOD in the
0.99.x
and 1.2.x gimp releases. There *may* be fixes in the gimp's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 11, 2004, at 4:06 pm, Sven Neumann wrote:
Daniel recently posted a list of X extensions supported by the Apple
X11 server. The MIT-SHM extension was part of this list but today I
found that at least in darwinports gtk2 is compiled with the
--dis
On Feb 24, 2004, at 11:13 am, Sven Neumann wrote:
Ugh! I can't find airfare there any cheaper than about US$1500. Has
anyone from the US found a much better deal?
Did you also check flights going to Oslo?
I'd rather check the flights with a slighty longer stay instead.
6 nights and the flights
On Feb 11, 2004, at 10:51 pm, Nathan Carl Summers wrote:
IIRC, didn't early versions of OS X have truly pitiful amounts of
shared
memory available? Perhaps that is the reason.
So now I recompiled GTK 2.2.4 with SHM and I cannot sense any
difference in behaviour. However scrolling in gnumeric is
On Feb 25, 2004, at 10:11 am, Sven Neumann wrote:
Did you increase the shared memory limit? I am not sure what happens
if it the X server hits the limit but I guess it just silently stops
allocating more shared memory.
Err, I know somewhat how to mess with POSIX SHM in applications but
how can I c
On Feb 25, 2004, at 11:27 pm, Daniel Rogers wrote:
sysctl -w kern.sysv.shmmax=41943040
sysctl -w kern.sysv.shmmin=1
sysctl -w kern.sysv.shmmni=320
sysctl -w kern.sysv.shmseg=80
sysctl -w kern.sysv.shmall=10240
DUH! How could I possibly forget about sysctl. That doesn't
seem to work though:
lucy:~
On Feb 25, 2004, at 10:35 am, Mark Shuttleworth wrote:
Image manipulation is one of the key application areas that needs to
be addressed for open source tools to become the mainstream desktop
environment. I'm currently funding a number of different open source
projects, and am considering fundi
On Feb 26, 2004, at 5:38 pm, Daniel Rogers wrote:
Who knows? Who cares? but you do need to edit /etc/rc to see any
effect.
Thanks for the explanation. I did just what you told me and
retested, but it doesn't have any positive impact on the
slowness.
Servus,
Daniel
PGP.sig
Description: T
On Mar 9, 2004, at 10:46 pm, Roman Joost wrote:
If the gimp-help-2 team has nothing against this, it'll be okey for me
to be published on the site.
Certainly fine with me.
Servus,
Daniel
PGP.sig
Description: This is a digitally signed message part
On Mar 10, 2004, at 8:41 pm, Sven Neumann wrote:
Okay, I have some idea how this all might work.
Regarding the "topic not found"-fallback: I think we should
simply add some hidden texts in every language which can be
mapped as fallback. Those are strictly required for every
language and should
On Mar 11, 2004, at 12:09 pm, Sven Neumann wrote:
Because our experience in the pre-releases has shown that it is
extremely difficult to provide a working spec file. And even if we
managed to provide on, it would be specific for a particular
distribution. So we should either provide spec files for
On Mar 11, 2004, at 4:52 pm, Dave Neary wrote:
So who does that leave? I'm not sure what Suse's release schedule is,
but based on the above, the first mainstream distro with GNOME 2.6 in
a release will be either Fedora Core 2 in May, or Mandrake in August
or September. That is, unless Debian de
On Mar 12, 2004, at 1:59 pm, Sven Neumann wrote:
What I dislike about this is that the base for the references in the
XML files is not the directory the XML file is located in. So
there's some special knowledge needed to interpret the references.
I suggest this structure intead:
${gimp
On Mar 14, 2004, at 12:54 pm, Sven Neumann wrote:
Such an image file is kept seperate from the rest of the system. So
there's no chance that whatever library you add there could collide
with other software on the system. Assumed that I understood this
correctly, but that's what I have been told by
On Mar 17, 2004, at 5:53 pm, Aaron Voisine wrote:
Here are the links. It's hosted on a cable modem, so
be gentle.
Now this is really cool!
I'd really appreciate if we could put them somewhere
on the official servers. If not, would it be an option
for you to open a sourceforge project?
Servus,
On 17.03.2004, at 17:53, Aaron Voisine wrote:
I have a self contained application bundle for the gimp
on os x. Would this be of use as a binary download for
the mac? It's only external dependency is that you have
X11.app install somewhere on your system.
I finally came around to test the GIMP.app
On 04.06.2004, at 13:37, Ellen Reitmayr wrote:
7. German translation
- Some words are misleading
We've had many iterations through the translation already and
in many cases (I at least) were not quite sure how to translate
some phrases.
If you could come up with some suggestions I'd certainly
appre
On 04.06.2004, at 17:05, Ellen Reitmayr wrote:
uuu, that's a translation problem!
in english the button says: 'Create Selection from Path'
in german it says: 'Pfad aus Auswahl' (Create Path from Selection)
I think Daniel Egger is the right one to tell that, no?
Any Ger
On 04.06.2004, at 16:20, Carol Spears wrote:
If you could come up with some suggestions I'd certainly
appreciate that.
okay, how does photoshop translate their stuff into german?
I expect they have a highly paid team of artists and
professional translators.
Or do you mean that we should copy their
On 07.06.2004, at 20:04, William Skaggs wrote:
The main reason not to use convmatrix is that internally it always
does a 5x5 convolution, regardless of the matrix entries. This means
it should take almost three times as long as the 3x3 convolution in
blur.c; in fact, a little testing on a 5000 x 1
On 18.07.2004, at 03:07, Christopher W. Curtis wrote:
And we want it rendered using glitz!
http://freedesktop.org/Software/glitz
... but seriously, does anyone think it's possible to offload
processing to the GPU? Is that part of the GEGL pipe goals? I didn't
see anything at the site in the doc
On 22.07.2004, at 23:19, Simon Budig wrote:
We use the gettext library to determine what language the text in our
user interface should be. In fact gettext does all the hard work for
us.
Not quite but almost. :) The choice of language is expressed by
setting environment variables. Those are picked
On 26.07.2004, at 17:12, Roman Joost wrote:
I was digging a bit around in the net to find out, which word is more
used for the Toolbox: "Werkzeugfenster" or "Werkzeugkasten". The most
tutorials I found are using "Werkzeugkasten", even Sven uses
"Werkzeugkasten" in his book. But "Werkzeugfenster" is
On 15.09.2004, at 18:06, William Skaggs wrote:
This is for anybody interested in contributing to the Gimp Help 2 /
User Manual.
Very nice. Can we put that somewhere? The Wiki seems like a nice
place for it.
Servus,
Daniel
PGP.sig
Description: This is a digitally signed message part
On 03.10.2004, at 17:51, Sven Neumann wrote:
We can of course add a gimprc option for the Help button but my
question is if it is a good idea to add such a button per default.
I like your idea very much.
It might make sense to get an opinion from the usability guys
though. Maybe have any suggestion
On 04.10.2004, at 10:28, Sven Neumann wrote:
It might make sense to get an opinion from the usability guys
though. Maybe have any suggestions how to address the potential
issues you've raised.
Who are the usability guys?
Ellen Reitmayr would be a good start. Maybe the Ximian usability
guys or the
On 05.10.2004, at 13:20, Sven Neumann wrote:
authors...". IMO this is acceptable. It would however be interesting
to know how many of the help-ids are already covered in gimp-help-2.
Do such figures exist?
In the gimp-help-2 module there is a docs/makeStatistics.py written
by Roman which is suppose
On 06.10.2004, at 19:45, Tor Lillqvist wrote:
Again this c't magazine asking for permission to put GIMP (for
Windows, presumably) on a CD-ROM. Could some of our German developers
try to tell them once more that they don't have to ask me (or anybody
else) for permission. (And on the other hand, even
On 24.10.2004, at 20:36, Sven Neumann wrote:
The help system has always been designed that way. The problem was
with the way the help pages get generated from the DocBook sources.
During that process empty pages were generated instead of no
pages. Thus, the language fallback in the help system coul
On 30.10.2004, at 15:09, Sven Neumann wrote:
Welcome to Hotel Wilma. You can check out any time you like, but you
can never leave!
Wilma? What happened to hotel California? ;)
Servus,
Daniel
PGP.sig
Description: This is a digitally signed message part
On 12.11.2004, at 01:13, Steve Stavropoulos wrote:
If the OS has better virtual memory than what available to gimp, then
you would want to use that one. In Linux, I think in most cases, you
would want to use the (often in multiple disks) swap partitions/files
available to the OS.
GIMP does tile sw
On 12.11.2004, at 13:12, Sven Neumann wrote:
The operating system imposes a limit on the maximum amount of memory
that can be allocated by a process. IIRC the limit is 3GB on Linux.
Typically the splitting point (user/kernel and peripheral memory)
would be 2:2, but there is a way to easily get 3:1
On 12.11.2004, at 15:51, Sven Neumann wrote:
That allows you to stuff more RAM into your box but you can still only
give up to 4GB to a single process simply because you cannot handle
more than 4GB in a 32bit address space.
You can, but not using the typical APIs. This is pretty important
for datab
On 12.11.2004, at 18:51, Manish Singh wrote:
You can, but not using the typical APIs. This is pretty important
for database stuff
Whose use case is very different than GIMP's. And you do use the
typical
APIs, but the user does have to setup the shmfs on their own. And then
you have to select
On 13.11.2004, at 08:48, Manish Singh wrote:
shm is a special case. I'm talking about allocating highmem
segments.
So, what is the userspace API for this?
AFAIK there's no direct userspace helper to address highmem
segments; one can only map them in the Linux kernel and
provide them to userspace (
On 13.11.2004, at 07:45, Laxminarayan Kamath wrote:
t's a whole bunch of contortions, and all pointless since amd64
hardware is competitively priced these days.
please dont concentrate only on those who can change pcs like shirts,
concentrate on us poor people too. ;)
Actually my focus is on havin
On 06.12.2004, at 19:44, Joao S. O. Bueno Calligaris wrote:
But nowadays, who seriously uses it?
I do. It's not very useful to mask an object in a low
contrast environment but it works perfectly well for
instance to mask an digitally photographed object against
a somewhat distant background to only
On 15.12.2004, at 20:16, William Skaggs wrote:
I've been thinking about three things that are highly desired but
have been waiting for the migration to gegl: support for 16 bits,
layer groups, and procedural layers. It seems to me that all of
them can be achieved in GIMP 2 without major infrastru
On 16.12.2004, at 02:13, Sven Neumann wrote:
The point you are missing is that we can't expect GEGL to mature into
anything useable if we continue to not using it. The only way to make
things happen is to do them. I am certainly not going to accept any
such kludges in GIMP since we should finally g
On 05.01.2005, at 18:27, Dave Neary wrote:
Before people get high-horsey about this, consider that 90% of digital
cameras
have embedded DOS as their OS, and are thus unable to generate files
which are
not 8.3.
I don't think it is pretty safe to assume that FAT support
means that anything close to
On 05.01.2005, at 22:37, Carol Spears wrote:
canon rebel uses DOS.
Possibly only as a bootloader or datashifter.
According to
http://www.alexbernstein.com/wiki/CanonDigitalRebelHacking
the camera has three different processors and it is more than
unlikely that the 80186 compatible processor is used
On 09.01.2005, at 18:39, William Skaggs wrote:
1) New rectangle select tool that allows adjustment of rectangle after
creation. (Implemented in my personal tree with the exception of
keybindings. Implemented as a separate tool, so it can be tested
and improved without losing the standard rect-sel
On 10.01.2005, at 16:52, Jakub Steiner wrote:
Unless I'm being told untruth about the losslessness (soundss great,
doesn't it?), the metaphor of not messing around with negatives isn't
appropriate.
It depends very much on how clever the tools are regarding the
EXIF information; if an image is rotat
1 - 100 of 250 matches
Mail list logo
