On 17 Feb, Austin Donnelly wrote:
> I've been meaning to find a way to update the menu item to include the
> filter name so you can get a better idea what will happen, eg:
> Filter->Repeat Last (blur IIR)
> or something.
Great idea. In case you don't have the time to implement it please fil
On 13 Feb, Marc Lehmann wrote:
> When Daniel and I did our profiling just after the gimpcon we found
> that the bottleneck were not really the paint functions but small
> things like repeatedly calling methods like drawable_bpp which were
> just one line and similar cases. We commited to do a lot
On 7 Feb, Raphael Quinet wrote:
> Since the GIMP/GNOME bug database has moved to bugzilla.gnome.org, the
> administrative options have changed. On the old bugs.gnome.org, it
> was possible for me to change the status of some bugs easily, but now
> I cannot change the status, affected OS, priori
On 7 Feb, Sven Neumann wrote:
>> Hm, generating a lookup table and getting the pressure from there
>> instead directly from the driver would be trivial to implement and
>> seems like a worthy feature to me.
> What driver are you speaking about?
The standard Intuos Win driver.
> The cod
On 6 Feb, David A. Bartold wrote:
> I think a better solution would be a definable pressure curve, much
> like Wacom's Windows driver has. That'd probably be a feature of the
> general mechanism you described and perhaps what you have in mind.
Hm, generating a lookup table and getting the pr
On 3 Feb, Sven Neumann wrote:
>> has the wishlist for features for gimp 1.4/2.0 been started?? If so
>> where can I find it/add to it?
> The source tree contains a file TODO which is a collection of ideas
> that have come up over the years. Actually the file should not be
> called TODO, but pr
On 14 Jan, Jens Christian Restemeier wrote:
> I recently got a bug report for QBist, and in turn made a new version.
> What is the easiest way to get it into CVS-Gimp ? I made a patch, but
> the patches directory on ftp.gimp.org doesn's seem to be cleaned for 2
> years, and the latest CVS version
On 9 Jan, Christopher Curtis wrote:
>> Patchsets also have a big problem which timecop already
>> noticed: They don't contain binary files or patches to
>> such and thus a patched tree might miss quite a few important
>> files after a while. xdelta wouldn't cause that particular
>> problem
On 6 Jan, Sven Neumann wrote:
> The other ideas seem to be good suggestions. I think we should
> set up a web-forum where we collect ideas and suggestions like
> this.
What about the bugtracker? It's much mightier now and a good place to
keep things.
--
Servus,
Daniel
On 5 Jan, Bennett Keith Portnet wrote:
> Sorry to bug you, I found you name and email address in the GIMP files !
> I downloaded the GIMP 1.2.0 (for Windows ?!) from Tucows.
> It has been uncompressed into a file on my hard drive.
> (I am running Windows NT)
> NOW WHAT DO I DO TO GET IT RUNNIN
On 1 Jan, Laramie Leavitt wrote:
> I have ported a part of my iscissors patch from 1.1.25 to gimp 1.2.
> All this patch does is add a livewire boundary to the iscissors tool,
> and an option in the tool options to turn it on and off.
Yay! This is way cool. I'll checkin your changes to the new
On 28 Dec, Tino Schwarze wrote:
> Without having looked at the code - what do we need that many FDs for?!
> We don't need to open all palettes at once, do we?
The code for the brushes, gradients and the palettes is (was?)
really nasty. But the file descriptors are closed after the complete
pa
On 26 Dec, Garry R. Osgood wrote:
> The tarballs and patch-sets are really meant for end-users
> who prefer to compile from source, but don't otherwise
> desire to get involved in maintenance and so don't have
> a strong motivation to keep a bleeding-edge source tree
> around. Patch sets are publ
On 27 Dec, [EMAIL PROTECTED] wrote:
> You know since you take time to answer my posts, I might as well too.
> Compared to your "limited" 64k how does 9600 that disconnects every 5
> minutes sound to you? And the fact that downloading something like a
> full gimp 1.2.0 would take close to 2 or 3
On 26 Dec, [EMAIL PROTECTED] wrote:
>> Why not use CVS and tags? Makes life much easier for both sides.
> Because
> a) my bandwidth is limited
> b) most importantly, my time is limited.
> Therefore, downloading a 200k patch is a lot easier than getting a
> cvs-able gimp tree that I can updat
On 26 Dec, [EMAIL PROTECTED] wrote:
> I am not supposed to download 10mb of source code, I have been
> patching up since like 1.1.20, no way, you can provide a good patch
> from 1.1.32 to 1.2.0.
Why not use CVS and tags? Makes life much easier for both sides.
--
Servus,
Daniel
On 13 Dec, Sven Neumann wrote:
> gnome-cvs can not do this for us (because it only has all-or-nothing
> permissions), we need to look for another CVS server. Eventually our
> employer convergence could help, I'll ask.
I can offer you a server on a decent connection as well.b
--
Servus,
On 14 Dec, Sven Neumann wrote:
> Please keep in mind that the main intention of our proposal has been
> to better distribute work between core and plug-in developers by
> seperating the source trees during development. Perhaps this scheme
> could be translated to distribution too, but it does not
pyright 1995-1999 by Frederic Lepied, France. <[EMAIL PROTECTED]>
* Copyright 2000 by Daniel Egger, Germany. <[EMAIL PROTECTED]>
*
* Modified for Linux USB by MATSUMURA Namihiko.
* FrñÅñÓic Lepied <[EMAIL PROTECTED]>.
* Additional changes by Brion Vibber <[EMAIL PRO
On 6 Nov, Sven Neumann wrote:
> If you want me to change the helpbrowser, I need a detailed list of
> the changes that are necessary.
just the changes we talked about: Removal of the HTML navigation bar
and using the supplied links in this bars for the buttons in the
helpbrowser.
--
Servu
On 5 Nov, Tuomas Kuosmanen wrote:
>> Just curious: Is anyone able to get the brush dialog by
>> doubleclicking the brush in the toolbox using a graphicstablet?
>
> Dunno, I have it always open :)
It works now... I fixed the driver so probably it was a problem in
there
--
Servus,
On 5 Nov, Austin Donnelly wrote:
> Is it generally known that mouse-down and waiting on brushes and
> patterns pops up a larger preview window showing the whole
> brush/pattern if it's larger than the preview?
> Do many users discover this themselves, or are they ignorant of the
> fact?
Just
On 4 Nov, Garry R. Osgood wrote:
> Given the nearness of 1.2 release, the Gimp Help Team (bex, Piers
> Cornwell, Daniel Eggers apologies if I missed the other contributors)
> started a separate gimp-help project last July, and not integrate with
> the main tree until help stuff is reasonably s
On 1 Nov, Federico Mena Quintero wrote:
> You could say that it is a major piece of brokenness for the GIMP not
> to do garbage collection around buggy plug-ins or scripts, but I know
> this is nontrivial to fix.
It's quite annoying but trivial to crash the GIMP using the SANE
plugin... :(
-
On 28 Oct, Tuomas Kuosmanen wrote:
> No clue. Is this a "they want someone to do a demo" or "who the heck
> is going to do a gimp demo there??"
BTW: I'm going to show GIMP at the COMDEX in Las Vegas at the SuSE
booth
--
Servus,
Daniel
On 4 Oct, Marco Lamberto wrote:
> Ok, you're right, but why everything worked fine till gimp 1.1.24 (the
> last RPM I've built through the "standard" gimp.spec)? I don't think
> that dropping the RPM support or a clean and easy way for RPMming the
> GIMP is a good choice (none would use the "pre
On 3 Oct, COUTIER Eric wrote:
> I am just an user but can i make a suggestion ? There's 25 buttons on
> the Gimp Toolbar and sometime, it's not easy to find the good one in
> all these buttons. I suggest to arrange buttons by "groups", separated
> with spaces, to respect "7 items" ergonomy stand
On 1 Oct, Marc Lehmann wrote:
>> I haven't fixed yet the GIMP Perl plugins installation, please could
>> anyone fix it or tell me a workaround?
> The README.perl suggests PREFIX= for just this case. Daniel Egger
> could probably get more info as he works for suse and
On 1 Oct, Marco Lamberto wrote:
> I've got a little trouble while rebuilding the rpm of gimp 1.1.26,
> when running the "make prefix={a_new_prefix} install" it tries to
> install into "/usr" discarding the "prefix" and "PREFIX" values. I
> should update someting or someone has forgotten somethin
On 29 Sep, Garry R. Osgood wrote:
>> I cannot reproduce this bug under any circumstances here on i386
>> while it crashes Kevin's machine hard. Should the dialog block while
>> a update is running? Just asking because it does here and elsewhere
>> not
> I reproduce it here on both the l
On 28 Sep, Alejandro Forero Cuervo wrote:
> Could someone please help me? Where should I look at? I am
> unfamiliar with Gimp's code, as you can see.
GIMPs scripting features are all plugins, thus you should see
pluins/script-fu and plugin/perl how they implement thing and whether
you can
On 28 Sep, Steinar H. Gunderson wrote:
> H... Since the JPEG previewing mess originally was made by me,
> I've just got a side note: libjpeg is rather unstable at low
> qualities. Of course, if this happens with HQ too, it is a GIMP bug,
> and not a libjpeg bug.
I cannot reproduce this bug
On 28 Sep, Paul Wagland wrote:
> First up, I hope that this is the right place to report this bug.
> Second thing: This is a great product. You guys should be proud of
> yourselves!
We are, hehe :) Now back to bussiness... :)
> I have no reason to believe that steps 1-2 make sweet rafoosl
On 26 Sep, Tim Mooney wrote:
> You need to quote the '*.c', it's getting expanded by the shell before
> it ever gets fed to find. :-)
Actually that's not the problem since there are no *.c files in the
directory I started the search in...
Anita:/mnt2/src/gimp # find -name *.c
./libgimp/gimps
On 26 Sep, Tim Mooney wrote:
>> Grepped through the source and couldn't find any C++ style
>> comments...
> cc: Error: lighting_ui.c, line 387: Invalid statement. (badstmt)
> // GtkWidget *spinbutton;
> --^
> This is from 1.1.26/plug-ins/Lighting. I haven't made the build
> proceed any far
On 26 Sep, Tim Mooney wrote:
> I'll try build 1.1.26 or some subsequent release on the platforms I
> have access to, but whoever does pre-release builds (Yosh?) should see
> if there's a way to make your compiler (gcc?) warn/error on C++ style
> comments. Every single point build of gimp for the
On 13 Aug, Tom Rathborne wrote:
> Corel's PhotoPaint program is a full GIMP-like paint program and
> people seemed to be having a lot of fun with it. I agree that it would
> get messy - the stuff I saw on the screen was obviously the result of
> a bunch of clashing artists. I think the full power
On 6 Aug, Kevin Turner wrote:
> gimp-help/whysgml.txt states that we are going to go through all the
> bother of writing well-formed XML files (e.g. being strict about
> always using closing tags, etc), but that we won't be actually marking
> the files as XML. If you have a grudge against xml,
On 4 Aug, Michael Natterer wrote:
> Just go ahead and populate this directory. In the first time we'll
> take care of committing the generated help files into gimp. Once the
> build system is working (hopefully soon) we can include gimp-help as a
> virtual module into the gimp CVS tree.
We'll
Hiho!
I'm actually asking myself where we should place the new docs
in the CVS.
It seems we have two choices:
1) Put them in help parallel to the other files
2) Create a new directory for them until everything (automatic creation
of HTML docs and indexing) is working good enough for produ
On 2 Aug, Garry R. Osgood wrote:
>> If you have any further comments about the help system, please submit
>> them to this list so we can make any necessary changes.
> Have you worked out submission procedures? (i.e., drafts to you, you
> check in?)
We're working on this issue. Since we have R
On 2 Aug, Piers Cornwell wrote:
> We have drawn up a concept of how the new help system will be layed
> out and work, and made a few sample files to show that it works. The
> basic system will be, for the first time, a proper user manual which
> explains such things as the concept behind layers,
On 1 Aug, Tuomas Kuosmanen wrote:
> Gimp-perl works just fine on debian woody with "normal" stuff. Both on
> my intel desktop box and on my powerpc laptop. No problems. Except for
> the i8n stuff in plug-ins/perl/po/ that sometimes seems to get cvs
> conflicts ( the << stuff) in the files (c
On 30 Jul, Sven Neumann wrote:
>> Sorry, this page hasn't been written in yet. Would you
>> like to read this help in instead?
> As you might have noticed the creators of the help system have already
> thought about that. The current help-system does not yet support
> multi-language help f
On 30 Jul, Robert L Krawitz wrote:
> Pardon? Just because a version is not officially released doesn't
> mean it doesn't exist, does it?
> For this purpose, I would say it does (mean that it does not exist).
> Especially since it isn't even a formal snapshot (which egcs was doing
> for a
file, or should always be in seperate
> files? For instance, should information about using the plug-in
> non-interactively not be displayed in the same file as the rest, to
> avoid exposing the user to "scary pdb stuff"?
What about letting the user choose that?
> See: http://
On 30 Jul, Marc Lehmann wrote:
>> No need to get insulting.
> It's pure fact. You keep claiming all sorts of funny things that you
> yourself should have known long before you started posting about it.
Ok Marc, it's enough. I will not continue this useless flamewar!
In real life you sometim
On 30 Jul, Marc Lehmann wrote:
> It's you who is unprof(f)essional. You were and are totally wrong with
> your today's claim about gcc -- claiming some not-yet-existant
> version of gcc causes problems on your machine.
Pardon? Just because a version is not officially released doesn't mean
it d
On 30 Jul, Marc Lehmann wrote:
> i would really appreciate if you would finally start thinking, as this
> is not the first time you claim things that are sooo obviously broken
> :(
No need to get insulting. Spend your time fixing the plugin instead.
This would be more helpful for you and me. I
On 30 Jul, Andrew J Fortune wrote:
> I didn't say that the Perl scripting tool didn't work for me. I said
> that I couldn't find it on GIMP's menus.
If you can't find the scripts in the menus they're either not correctly
installed or couldn't register themself because of troubles. In this
cas
On 29 Jul, Sven Neumann wrote:
> Sorry Daniel, but don't we don't need that kind of FUD here. If
> gimp-perl is still not working for you, please let us know exactly
> what kind of problems you experience with it. I have the expression
> that gimp-perl works quite good on most installations.
So
On 30 Jul, Andrew J Fortune wrote:
> I currently have the latest developers' version of GIMP (v1.1.24). Can
> someone tell me if Perl scripting is still available ? (...there used
> to be any entry called "Perl-FU" on the Xtns menu).
Perl normally should be there. But since the Perl plugin has
On 23 Jul, Charles Iliya Krempeaux wrote:
> OK, I'll do that (eventually). But my point is, if X Windows isn't
> available on every Mac system... or at least if they can't get it
> for free... then it is worth porting the GIMP (and GTK+, GDK, etc) to
> the native MacOS API.
I'm not against a p
On 23 Jul, Charles Iliya Krempeaux wrote:
> Will it be free? Will it be a standard part of MacOS?
> (Or is it something Mac users will have to pay for?)
Sorry, I have got no details handy. Read about it on slashdot or
somewhere. Have a look at the usual MAC places to get info about that...
-
On 20 Jul, somnorici wrote:
> I set the undo levels to zero and loaded an image. 9376 by 11488
> pixels grayscale is 107,711,488 bytes. My display depth is 16 bits. It
> didn't take long to link this with the swap file, which after
> loading the image was 292,421,632 bytes, plus the 32 megs of t
On 21 Jul, blue wrote:
> i will try and compile this today and see if i have the same
> problems. have you tried compiling one of the 1.2 versions?
I suggested him to try the latest stable glib and gtk+ version
as well as the latest unsatble GIMP because it work compile and
work a lot nicer o
On 21 Jul, Michael Natterer wrote:
> I guess that Gtk+ and Gimp will run more or less automatically
> on MacOS X' BSD API once there is an X server, so there should
> be no need to "port" it.
A X server for MacOS is due to be released by Apple, soon
--
Servus,
Daniel
On 20 Jul, Jason T. Slack wrote:
> I use Metrowerks, but not Powerplant, I am used to straight C already.
> Does Gimp run on Linux PPC or just x86?
Gimp runs fine on any >16bit machine. If there problems they're mostly
caused by some scary compilers
--
Servus,
Daniel
On 10 Jul, Sven Neumann wrote:
> Noone can stop you from releasing patches (or a patched gimp) however.
Yeah, just do that... but beware... :)
> Don't get me wrong: Any help is greatly appreciated and we will be
> very happy to incorparate your changes into the 1.3 development branch
> once we
On 1 Jul, GregStar wrote:
> Can anybody told me where I can find the German version of GIMP for
> Linux???
At the same place you at which you'll find the English version...
It's there since somewhen in 1.1.x ...
--
Servus,
Daniel
On 26 Jun, Adam D. Moss wrote:
> Two immediately noticable ones are:
> 1) moving a layer with the move tool is broken, no longer
> tracks pointer after first 'settle' of motion.
> 2) ctrl-q to quit brings up the 'something modified, really
> quit?' dialog but the 'okay' button then makes the
On 26 Jun, DrMartin.Weber wrote:
> I took several months' time to compare nearly all available color
> quantization algorithms. Shurely GIMP's Median Cut is good but not the
> best. SQC (http://www-dbv.cs.uni-bonn.de/quant/) is really the best
> one available and it is also fast. I have some code
On 25 Jun, Marc Lehmann wrote:
>> He and Raster are going to meet next week and then they'll think
>> about possible solutions for this conflict.
> Don't they think this is demanding some _action_ (like reverting that
> patch)? "meet next week" and "possible solutions" sounds, well, not
> ver
Hiho!
I talked to Christian Kreibich, the author of the codemixture and he
told me that it was a mistake to publish the code in this form and
that he'll undo that step.
He and Raster are going to meet next week and then they'll think about
possible solutions for this conflict.
--
Servus,
On 25 Jun, Sven Neumann wrote:
> I agree with this opinion and would be happy if we could set up a
> short email that we send to the Imlib2 people signed by some of the
> people owning the copyright of the affected code. Since it seems not
> necessary to involve Peter and Spencer at this point, s
On 25 Jun, Nick Lamb wrote:
> It "appeared" courtesy of someone identified only as "cK", hopefully
> those working on Imlib2 will know that handle (though who knows,
> it doesn't look like an expertly managed project to me, maybe anyone
> can get CVS write privs) and remove their write privs.
T
On 14 Jun, Sven Neumann wrote:
> app/pixel_region.c 1.20
> app/paint_core.c 1.90 app/paint_core.h 1.30
> app/undo.c 1.60
> and couldn't see any problems. I could reproduce the crash after
> reverting all those changes, so it seems the problem is elsewhere.
Okay, traced this problem further.
On 14 Jun, Sven Neumann wrote:
> app/pixel_region.c 1.20
> app/paint_core.c 1.90 app/paint_core.h 1.30
> app/undo.c 1.60
> and couldn't see any problems. I could reproduce the crash after
> reverting all those changes, so it seems the problem is elsewhere.
ME TOO. GIMP tries to free unexist
On 13 Jun, Daniele Medri wrote:
> My idea is.. to create a db (..probably with PostgreSQL) to manage all
> the label of gimp, script-fu, gimp-plugin e make a coherent work
> with these labels for translation. A php-interface could be a nice
> add-on that i want to.
Talk to Marc, he showed somet
On 7 Jun, Nick Matsakis wrote:
> I'm working on a research project involving real time image processing
> on video streams. I need an image processing library, and so wondered
> whether the gimp might fit my needs. I have two questions which will
> help me determine if this is indeed the case.
On 7 Jun, Sven Neumann wrote:
> As profiling the Gimp shows, there's the need and room for
> optimization. Marc and Daniel did work on this last weekend
> and hopefully we will soon see those changes in CVS.
I'd be very glad I you could apply this patches I'll send them to
you soon
-
On 23 May, Nick Lamb wrote:
> Having just come back from WWW9 I'm pretty enthusiastic about SVG
> right now. I can't see the point in continuing to use Flash once there
> are vendors clambering over each other to produce the best SVG
> plug-in and (since it's free) it will be built-in on Mozilla
On 4 May, Uwe Koloska wrote:
> But there was a problem during "make install". In plug-ins/perl/po it
> says:
>
> cp cs.gmo /opt/Gnome/share/locale/cs/LC_MESSAGES/gimp-perl.mo
> cp: cs.gmo: No such file or directory
> make: [install-po] Error 1 (ignored)
>
> the same for all
On 10 Apr, Marc Lehmann wrote:
> Maybe you are not aware that glibc2 is installed only on a minority of
> operating systems.
Where's the point? gettext is also available outside of glibc2.
> That means that we won't be able to use the native gettext
> implementation, but always build our own
On 9 Apr, Marc Lehmann wrote:
> Distributing the .mo files means you need gnu gettext on your system
> anyway, so I do not really see the point.
You have to have gettext, indeed, but you don't have to have the tools!
That's a big difference. gettext itself is a part of glibc2 and if
you comp
On 8 Apr, Marc Lehmann wrote:
> Yes, I got the impression from all what I was told:
> a) msgmerge is not checked for by gettext itself
> b) binary .mo files are being distributed with the gimp
> Since I was no gettext expert, I just ate it. But now we know better:
> a) is wrong, since msgme
On 3 Apr, Raphael Quinet wrote:
> Unfortunately, many systems have msgfmt but do not have msgmerge.
> This is the default under Solaris (at least for Solaris 2.5.1, 2.6 and
> Solaris 7) and under SuSE Linux (unless you install the dev rpm that
> contains msgmerge).
I'll check this; if it's tr
On 1 Apr, Marc Lehmann wrote:
> I think using optional(!) tags (which will be more verbose) will be
> even more useful: Not much added strain on the programmer, not much
> strain on translators (we need one more translator for the en
> mapping).
Please note that adding "tags" to the messages w
On 30 Mar, Stanislav Brabec wrote:
> I18n wishes:
>
> -- Please do anything with the fact, that main panel menu with default
>GTK theme can contain exactly 15 letters. Too few for three items
> inmost languages.
What exactly would you suggest? That's actually a matter for t
On 25 Mar, Blue Lang wrote:
> A lot of laptops, especially running linux @ 1024x768, will only
> support 8 bit depth. Dunno if it matters to ya or not. :P Gimping on
> the plane, ahh.
Really? But that's not a limitation of the notebook I hope...
The techniques used in notebook LCD's allow norm
On 10 Mar, Raphael Quinet wrote:
> P.S.: I identified this problem when I tried to start an old version
> of the Gimp in order to check why the "Frosty" script was not
> giving the same results as in 1.0. If anybody knows why this
> logo script does not produce the same effects
On 2 Mar, jens reimer wrote:
> i have a problem compiling the cvs versions of gimp:
> After starting the autogen.sh there is no Makefile.in in /intl.
> If i try to start ./configure manually sed is missing this file also.
> What is wrong with it?
The files in /intl are produced by gettextize.
On 26 Feb, Kelly Lynn Martin wrote:
> It will also force us to develop tools for the separate compilation of
> plugins and develop a plugin interface that is versionable
The first one is definitely a need but "a plugin interface that is
versionable"? We do have versioned libraries ensurin
On 25 Feb, Sven Neumann wrote:
> Don't waste your time at that. I already did that and I tried to
> explain you why there is no way to hook into that place since GTK+
> creates the submenu on the fly. At the time we create the tearoff
> menu, the submenu is already created. But when the submenu i
On 25 Feb, Sven Neumann wrote:
> Which is exactly what I proposed at the end of my last mail. Despite
> that I proposed to build up the menu-structure (actually only the
> strings) in a hash-table before actually creating it.
For a new translation function I guess?
> Would be much
> faster the
On 24 Feb, Sven Neumann wrote:
> On the first thought the idea looks promising, but I fear it is
> not that easy. GTK+ wants to create the menu using the orginal
> strings.
Yes. That's why I thought of ripping off a slice from both the
translation AND the original.
Consider this:
Plugin wa
On 23 Feb, Ludovic Poitou wrote:
> SunOS bondi 5.8 Generic sun4u sparc SUNW,Ultra-5_10
> UltraSPARC-IIi
> But I haven't compiled with the 64 bit flag on !
> A simple program like this :
> main(){
> printf("%d\n", sizeof(unsigned char *));
> }
Do the plugins work for you? We've got dozen
On 24 Feb, Sven Neumann wrote:
> Eek, yes of course, that does not work any more. There are
> two ways to solve this: Either we search in the gimp domain
> if the lookup of the menupath failed (like we used to do (*))
> or we move the dummies into the plugins. I prefer the latter,
> since it is
rrect my typoes... :)
> "The i18n solution"(TM) is a registered trademark owned by Daniel
> Egger
Hey Sven, come on...
--
Servus,
Daniel
Hiho!
Would it make sense to you to enable keyboard access to
the menuentries in the toolbox?
I find it quite irritating that I can't get the File dialog
with Alt-F resp. Alt-D (German Datei). At least for beginners
not yet familiar with the shortcuts or the do-it-yourself-
shortcut-system
On 23 Feb, Sven Neumann wrote:
> One of us defintely works too much and too fast.
Uhm, but who? I think its you... :))
Sven, you are doing great work
> I have just checked
> in a working solution which gets rid of the annoying
> iterate-through-all-domains problem.
Great
> Sorry, b
On 23 Feb, Sven Neumann wrote:
>> I sent a newer patch in my last mail. It should do everything we
>> need for now.
> No, it will most likely crash the Gimp (explanation of the usage
> of GSList in a private mail)
No, it won't. Since g_slist_append COULD change the value of the
the beginni
On 23 Feb, Sven Neumann wrote:
> No, that won't work. Of course you need to hook somewhere into
> plug_in.c or at least use the plug_in_defs list. Otherwise plug-ins
> won't be able to register their domain on the first call.
Of course you are right, just a braino.
>> The only thing missing no
On 23 Feb, Sven Neumann wrote:
> gimp_plugin_add_locale_domain (gchar *domain_name,
> gchar *domain_path)
> and can only be called in the query function of a plug-in. The
> domain_path may optionally be NULL. Proposals for a better name are
> welcome.
I'd recommen
On 23 Feb, Sven Neumann wrote:
> I hate to note that, but hopefully this will teach the one who applied
> that patch in request of someone else, to check patches more
> carefully before applying them. If you want to know who is ment here,
> read the ChangeLog. But I think you already guessed it..
On 23 Feb, Sven Neumann wrote:
> You will find the patch at
> http://sven.gimp.org/files/locale_parse.patch.
OK, looks fine to me. I changed my files accordingly.
libgimp/gimpdomain.* is now futile. And the gimpgettext.* file
were changed to support that scheme. I added a few lines to
your m
On 23 Feb, Tuomas Kuosmanen wrote:
> I get this gdk error:
> Gdk-ERROR **: BadDrawable (invalid Pixmap or Window parameter)
> serial 37493 error_code 9 request_code 14 minor_code 0
> ** WARNING **: wire_read: unexpected EOF (plug-in crashed?)
> the it burns to ashes. However it might be r
On 23 Feb, Sven Neumann wrote:
> Ok, one shouldn't just bitch about other people's code, so here is my
> patch that adds an optional locale_domain and locale_path to the
> plugin structure and extends the pluginrc code to read and write that
> information from/into the pluginrc. This code is obvi
On 23 Feb, Sven Neumann wrote:
> Huh? Daniel, stop spreading FUD and read the code. The parser in
> gimprc is actually pretty flexible.
No, it isn't. It supposes a fixed order and fixer number of arguments
(except the pdbargs of course), that anything but flexible.
A tag based system on let's
On 23 Feb, Sven Neumann wrote:
> The core would then have to try to bindtextdomain() to all
> possible paths until success (or total failure if no message
> catalog was found).
You can't find out whether bindtextdomain failed or not. The only
way to get the information whether a catalog is ava
1 - 100 of 232 matches
Mail list logo
