Re: [Gimp-developer] Summary of outstanding 1.3 bugs/featurerequests.
Alan Horkan wrote: On Sat, 26 Jul 2003, David Neary wrote: I have been pretty brutal in chopping a bunch of enhancement requests today. What's left in the 1.3 milestone is a few bugs with patches outstanding and about 20 feature requests, most of whioch are claimed by someone or have patches outstanding. It would be a really big help if those in the know could please add the easy-fix keyword whenever they know a bug is easy to fix? A pointer the relevant file in the source code is always a huge help to those of us less familiar with the codebase (and that goes for any project). Agreed. We do use the PATCH keyword for bugs with outstanding patches attached, which goes a lot of the way to what you are asking for. When there isn't a fix, easy-fix should be used for the situation where the fix is described in detail in the comments. I dont know if Count Colours is anywhere in the list of bugs Dave mentioned but the ColorCube Analisys plugin effectively gives this functionality but unfortanately was only available for GIMP 1.2 on windows. This seems like it might be a relatively easy feature to get working but then again I dont really know, and it is probably one of the features that got bumped. Sorry Alan, that's one of the ones I bumped. It could be brought back into the 1.3.x milestone, on the condition that (1) the Colorcube analysis plug-in is GPL, and (2) someone agrees to maintain it. That brings up a major point which should be discussed. One of the big TODO points to come out of the last gimpcon was that plug-in distribution needed a complete reworking. There are several unmaintained plug-ins in the main gimp distribution, and there are several well-maintained plug-ins distributed separately. It would be nice to provide just the core, and have a kind of on-demand plug-in installation process for other plug-ins (kind of like CPAM does for Perl). Of course, someone said this all 2 years ago and no-one took it under their wing. Including plug-ins in the main gimp distribution requires a maintainer. If someone says they will maintain it, then it can go in. The other requirement is that it is of general interest - in the case of the colorcube analysis plug-in I think that can be assumed. So please, feel free to re-badge the Count colors bug as 1.3.x, but in that case, please send a mail to the devel list requesting a maintainer (also, link to the sources from the bug report, if the link is not already there). Thanks, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] writing german online help
On Sun, 27 Jul 2003 12:36:08 +0200 Roman Joost [EMAIL PROTECTED] wrote: But, this is not my main intention here - lets speak about german documentation. I figured out, that the gimp-help will now be written in docbook sgml. Is there a Gimp document style sheet? Owen -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [FEATURE] Add optional motion constraints tothe Move Tool
Jakub Steiner wrote: On Fri, 2003-07-25 at 22:27, David Neary wrote: Hi all, http://bugzilla.gnome.org/show_bug.cgi?id=78730 It would be nice if the Ctrl modifier did for the move tool what it did for other tools and constrained movement to 22.5 degree directions. The feature needs doing. Who wants it? The thing changed in 1.3 and now the Ctrl modifier is used to toggle the behaviour of the tool from pick to move current. So this may only mean using Shift for the constraint. However this is a little inconsistent. I would suggest we go back to how 1.2 was in this particular tool and try to use Shift where Ctrl is being used in 1.3 (I have absolutely no idea how much work this is): Selection tools: --- no change (both Shift and Ctrl toggle the mode) Zoom tool: -- use Shift to toggle in/out. Move tool: -- use Shift to toggle pick/move current use Ctrl for movement constraint Crop tool: -- use Shift to toggle crop/resize perhaps use Ctrl for keeping either 1:1 aspect ratio or the aspec ratio of the whole image (new feature) Transform tools: no change Flip tool: -- use Shift instead of Ctrl Text tool: -- This is a little complicated. Currently if a text layer exists and is selected, one can click on a pixel that has text on it. Now the tool options change the text attributes. Clicking on it again brings up the edit window. Now let's see if this is better: Selecting a text layer with the text tool active will automatically make any changes to the tool optins apply to the text layer. Clicking anywhere on the layer will bring up the edit dialog with the text loaded. A Shift modifier will toggle edit_current/new_text_layer behaviour. Setting default text tool parameters can be done on a non-text layer. I apologise Sven for thinking about this too late :/ Fill tool: -- There's currently no modifier to fill with patterns. Now that we have RGBA patterns and the feature is actually useful ;) it would be nice to have a similar toggle as the select tools. Shift to toggle BG fill and Ctrl to toggle pattern fill. The option dialog could have nice little buttons with a FG rectangle, BG rectangle and active pattern rectangle, just like the selection tools have. Gradient tool: -- Shift could toggle the reverse gradient. Ctrl remains. Clone, Pen, Pencil, Airbrush, Dodgeburn, Blursharpen, Smudge and Eraser: Although Ctrl is used to toggle to picker tool, I'd leave it as it is, since Ctrl is used for constraints after shift is pressed. Ink tool: --- no change How difficult would this be to do? If it's not that difficult, what exactly needs to be done, and are people in agreement that this is a good idea? If so, who's going to do it? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: [Gimp-developer] writing german online help
Am Son, 2003-07-27 um 12.36 schrieb Roman Joost: Okey ... i did a fresh checkout from the gimp-help-2 module and get it to work. I attached a 3 lines patch for the configure.in file, because i was wondering about a program called no, which was used, if no xsltproc is installed on the system. Now its working fine for me and configure do the right thing for me. So, maybe i was a bit confused and fixed, which shouldn't be fixed - do what you want with the patch ;) Maybe you forgot the attachment. But, this is not my main intention here - lets speak about german documentation. I figured out, that the gimp-help will now be written in docbook sgml. XML, not SGML. What do you think, where should i start? Maybe i'll create a new de_DE directory and start writing ... I'm not sure this is the best idea since it will be tricky to keep the English and the German version (at least to some extend) in sync. It's probably the best to combine all languages into the same file distinguishing the languages by lang tags. However I haven't thought much about this since you're the first to bring the topic up. Are there any policies to follow? - Don't mess with the structure - the content needs to compile all the time (i.e. be valid DocBook/XML) - new content has to be submitted to a reviewer before committing (which would be me for German unless someone else steps up (Nomis, Sven, Marc, Mitch?)) I really can't imagine that there was no german manual or a something similar. I hope, i'm able to change this ... Go ahead. If you have anything toss it over to me and I'll get the Module the shape. -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] writing german online help
Am Son, 2003-07-27 um 14.46 schrieb Roman Joost: Sure, but now its attached ... Thanks, applied. I'm glad it works for you; I haven't received much feedback about it. What OS do you have? Hm ... maybe the files will become really big after adding some different languages (e.g. de, cz ...). Sure, but in that case we can still split them up a finer granularity on structure level, say: give every subsection it's own file instead of just every section. I dont know if there is any standard to get the language of the system, but the $LANG environment variable seems a good start for me. So, guess this variable and select the right directory on start. This is a nobrainer and not really related to the question how to organise the sources since they need to be compiled anyway (for now at least). -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] writing german online help
Am Son, 2003-07-27 um 14.25 schrieb Roman Joost: In the gimp-help-2 module dir is a directory called stylesheets and the files in there, lookin for me like stylesheets. I think, yeh - there are document style sheets... Yes, there are transormation stylesheets and some really simple CSS stylesheets. -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] User preference was (Startup Notificationsupport...)
From: Alan Horkan [EMAIL PROTECTED] To: Patrick McFarland [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: [Gimp-developer] Startup Notification support... Date: Sun, 27 Jul 2003 03:27:06 +0100 (BST) MIME-Version: 1.0 On Sat, 26 Jul 2003, Patrick McFarland wrote: On 26-Jul-2003, Daniel Egger wrote: I think the problem is that 1.2 is far more used in productive work because artists and designers are afraid running software which is stamped alpha or beta more than just occasionally. Wrong, Im an artist, and I prefer 1.3 over 1.2. One Swallow does not a summer make. indeed Normal users in general abhor using anything labelled beta, consider your self extraordinary. depends, there's not really any such thing, especially when it comes to linux users, but i agree in general users are scared of software labelled beta or unstable, but most users don't understand the significance of an odd version number ;) and are often quite happy to try out a developers version. and then there are the win32 users who wont use software unless it's got a beta, alpha or internal testing(longhorn (l)users) tag, but wouldn't know where to start with real software. these people don't seem to have any concerns about being beta testers for M$ and think what they do is really 1337... The quality of most proprietary software has even caused users to distrust N.0 release and wait for the first or second service patch. again this depends upon the type of users you refer to, but generally that's true, if they're paying for the software at any rate. If you can build from source then you are probably more developer than user anyway. on linux that's nothing special really, no offence intended, it's simply made really nice and easy to do. While it is great that there are GIMP users willing to make the extra effort to use 1.3 I really hope to see GIMP being used by everyone else. The sooner we stamp out piracy of Adobe Photoshop the bettter :) i'm frequently suggesting 1.3.x to users, and they're often more than willing to give it a try, even if they don't have much *nix knowledge they can generally handle building and installing, which is great to see :) Phil. -- Tell me where is the love in what your prophet has said Man, it sounds to me just like a prison for the walking dead http://www.biggyp.tk/ - GIMP Tutorials and SEAL2 themes http://gug.sunsite.dk/gallery.php?artist=123 - Gallery http://biggyp.deviantart.com/ - Other Gallery Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer _ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] writing german online help
On Sun, Jul 27, 2003 at 02:57:49PM +0200, Daniel Egger wrote: Thanks, applied. I'm glad it works for you; I haven't received much feedback about it. What OS do you have? Debian GNU/Linux (sid - unstable) Sure, but in that case we can still split them up a finer granularity on structure level, say: give every subsection it's own file instead of just every section. k - lets see ... I'm not familiar with the help-xml syntax, but maybe i'm on the right way. For example (gimp-help-2/help/C/toolbox/zoom.xml): lang name=en variablelisttitleOptions/title varlistentrytermOverview/term listitem para The available tool options for Magnify can be accessed by double clicking the Magnify tool icon. /para /listitem /varlistentry /lang lang name=de variablelisttitleOptionen/title Or should the lang specified as an attribute? like: variablelisttitle lang=deOptionen/title Thanks, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: [Gimp-developer] writing german online help
Am Son, 2003-07-27 um 15.23 schrieb Roman Joost: Thanks, applied. I'm glad it works for you; I haven't received much feedback about it. What OS do you have? Debian GNU/Linux (sid - unstable) Ok, no surprise that worked. :) Or should the lang specified as an attribute? like: variablelisttitle lang=deOptionen/title It is an attribute which can be placed on any tag and (hopefully) in any depth. I'd suggest setting it on every first child of sect1s, i.e. sect1 id='introduction-gimp' title lang=enWelcome to The GIMP/title title lang=deWillkommen bei GIMP/title indexterm lang=en primaryThe GIMP/primary secondaryIntroduction/secondary /indexterm indexterm lang=de primaryGIMP/primary secondaryEinfuuml;hrung/secondary /indexterm para lang=en ... /sect1 Have a look at the current CVS version, I translated a few parts for instance in introduction.xml and added the mechanics for the German translation, so if you type make you'll get two directories in C/ plainhtml and plainhtml-de. Please note that every tag not qualified with a language attribute will show up in all languages and content which is qualified in sect1 childs but not translated will show up as empty sections in the index. Also the profiled version spits out some useless warning but apart from that it works fine. -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] writing german online help
Am Son, 2003-07-27 um 16.45 schrieb Carol Spears: you run down failing pathways. i cannot go with you. do the people contributing or trying to contribute get a say? Sure they do. [ Absolutely useless rant deleted ] I've no idea what happened to you in the last months but whatever it is, you REALLY should try to get that fixed before you hit the ground in everyones killfile. Having said this if your next mail contains as little information and as much FUD as the previous 30, I'm not going to reply anymore. I'm thouroughly sick of this crap! -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] writing german online help
On Sun, Jul 27, 2003 at 10:45:50AM -0400, Carol Spears wrote: Roman, i invested money to learn docbook, i suspect it was to keep up a broken system and broken people. i would send you $5 to try to rid yourself of this dependency on docbook, at least for your own sake, try to get a better deal for yourself from prof and docbook authors. i think it destroyed syngin. syngin was beautiful. look at the commit list. what is a good and proper way to say Something stinks so badly and i suspect it is name of stink maker. and not piss anyone off and be clearly understood. carol What can i say - i was wondering what this project needs to get done at first: the managment or a newer gimp-help? I mean - i dont care about the technics to get a good help. I just want to create a help, nothing more. Iam a complete newbie here and dont know what'll the best for a help, rather than for the contributors. If Docbook will be the best to generate a help - okey, i'll write the help in docbook. So, finally - i'll write it in XML as daniel wants. I wanna get the help done, because i've _now_ some spare time and i think _now_ is the best time to _help_ the gimp. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: [Gimp-developer] writing german online help
On Sun, Jul 27, 2003 at 04:08:09PM +0200, Daniel Egger wrote: I'm submitting a little patch for introduction.xml and minor fixes in the plainhtml.de.xsl.in. Some points to consider: 1. The German Umlauts are really annoying. Are there some pre-processors, which checks the umlauts and replaces them with an utf entity (or the predifined HTML umlauts... what else...)? If not, it think i'll write a little script. I forget them every time... 2. How do i create a better patch? I tried: cvs diff -R help/ foobar.patch but it looked nothing suitable for submitting. 3. How do you planed the reviewing process. Should i create a patch, submit this to you and you'll check it in the cvs repository? Maybe it'll be better, that any editor has an cvs access. The reviewing process goes on text crosswise. Everyone is checkin the help from another editor? Thats it so far. Tell me if the introduction.xml is okey and i can go any further. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: [Gimp-developer] writing german online help
okey.. i'll learn that i've to attache that damn file on the mail, when i mention it. .. brr Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] diff -ru /tmp/gimp-help-2/help/C/CVS/Entries help/C/CVS/Entries --- /tmp/gimp-help-2/help/C/CVS/Entries 2003-07-27 19:01:48.0 +0200 +++ help/C/CVS/Entries 2003-07-27 18:39:46.0 +0200 @@ -1,10 +1,10 @@ /.cvsignore/1.1/Sat Jul 27 15:47:32 2002// -/Makefile.am/1.4/Sun Jul 27 14:00:03 2003// -/gimp.xml/1.10/Sun Jul 27 14:00:03 2003// /glossary.xml/1.3/Sun Dec 29 02:50:07 2002// -/introduction.xml/1.6/Sun Jul 27 14:00:03 2003// -/not_yet_written.xml/1.2/Sun Jul 27 14:00:03 2003// D/filters D/images D/legal D/toolbox +/introduction.xml/1.6/Sun Jul 27 15:46:37 2003// +/not_yet_written.xml/1.2/Sun Jul 27 15:46:37 2003// +/Makefile.am/1.4/Sun Jul 27 16:39:46 2003// +/gimp.xml/1.10/Sun Jul 27 16:39:46 2003// diff -ru /tmp/gimp-help-2/help/C/filters/CVS/Entries help/C/filters/CVS/Entries --- /tmp/gimp-help-2/help/C/filters/CVS/Entries 2003-07-27 19:01:48.0 +0200 +++ help/C/filters/CVS/Entries 2003-07-27 16:40:41.0 +0200 @@ -1,2 +1,2 @@ -/filters_introduction.xml/1.2/Sun Nov 3 10:16:33 2002// D/blur +/filters_introduction.xml/1.2/Sun Jul 27 13:19:15 2003// diff -ru /tmp/gimp-help-2/help/C/introduction.xml help/C/introduction.xml --- /tmp/gimp-help-2/help/C/introduction.xml2003-07-27 16:00:03.0 +0200 +++ help/C/introduction.xml 2003-07-27 18:52:34.0 +0200 @@ -27,7 +27,7 @@ zusammengesetzt aus den englischen Worten acronymGNU/acronym oder General Image Manipulation Program, was im Deutschen soviel bedeutet wie Universelles Bildbearbeitungsprogram. acronymGIMP/acronym ist -auml;szlig;uerst vielfauml;ltig einsetzbar fuuml;r eine Vielzahl an +auml;szlig;erst vielfauml;ltig einsetzbar fuuml;r eine Vielzahl an Aufgaben einschlieszlig;lich Photonachbearbeitung, Bildkomposition und -malerei. /para @@ -47,9 +47,26 @@ acronymGPL/acronym provides users with the freedom to access and alter the source code that makes up computer programs. /para + + para lang=de + acronymGIMP/acronym's Stauml;rken liegen vor allem in der freien + Verfuuml;gbarkeit aus vielen Quellen und vielen Plattformen. Die meisten + acronymGNU/acronym/applicationLinux/application Distributionen + benutzen den acronymGIMP/acronym als Standard Anwendung. Auch fuuml;r + andere Betriebssysteme ist der acronymGIMP/acronym erhauml;ltlich, wie zum + Beispiel productnameMicrosoft Windows/productname oder Apples + productnameMac OS X/productname (applicationDarwin/application). + Ein wichtiger Punkt aber ist, dass der acronymGIMP/acronym nicht + Freeware ist. Es ist eine acronymOSS/acronym or Open Source Anwendung, + welche uuml;ber die ulink url='http://www.gnu.org/license/gpl/' + type='http'acronymGPL/acronym Lizenz/ulink vertrieben wird. Die + acronymGPL/acronym gibt den Benutzern die Freiheit auf die Quellen + zugreifen und diese verauml;ndern zu kouml;nnen. + /para sect2 id='introduction-platforms' -title lang=enKnown platforms/title + title lang=enKnown platforms/title + title lang=deVerfuuml;gbare Plattformen/title para lang=en The acronymGIMP/acronym is possibly the most supported image @@ -71,21 +88,58 @@ productnameIRIX/productname, productnameOS/2/productname, and productnameBeOS/productname. -/para - -para lang=en + /para + + para lang=de + acronymGIMP/acronym ist wohl heutzutage das mit am meisten unterstuuml;tzte + Bildbearbeitungsprogramm. Der acronymGIMP/acronym ist erhauml;ltlich und + funktioniert auf folgenden Plattformen: + productnameacronymGNU/acronym/Linux/productname, + productnameApple Mac OS X (Darwin)/productname, + productnameMicrosoft Windows 95, 98, NT4, and 2000/productname, + productnameOpenBSD/productname, + productnameNetBSD/productname, + productnameFreeBSD/productname, + productnameSolaris/productname, + productnameSunOS/productname, + productnameAIX/productname, + productnameHP-UX/productname, + productnameTru64/productname, + productnameDigital UNIX/productname, + productnameOSF/1/productname, + productnameIRIX/productname, + productnameOS/2/productname, and + productnameBeOS/productname. + /para + + para lang=en The acronymGIMP/acronym can be easily ported to other operating systems because of its source code availability. -/para + /para + + para lang=de +Durch seine Quelloffenheit, kann der acronymGIMP/acronym leicht auf +andere Plattformen portiert werden. + /para + /sect2 sect2 id='introduction-help' -title lang=enThe GIMP-Help system/title + title lang=enThe GIMP-Help system/title + title lang=deDas GIMP-Hilfe System/title
Re: [Gimp-developer] writing german online help
Am Son, 2003-07-27 um 19.16 schrieb Roman Joost: 1. The German Umlauts are really annoying. Are there some pre-processors, which checks the umlauts and replaces them with an utf entity (or the predifined HTML umlauts... what else...)? If not, it think i'll write a little script. I forget them every time... Hehe, and you even introduced a typo by trying to fix one of mine. :) Try to convince your Editor to map Umlauts to HTML Entities and you're done. 2. How do i create a better patch? I tried: cvs diff -R help/ foobar.patch but it looked nothing suitable for submitting. If prefer them in unified format (-u), but except for that and a few wrong locations this looks pretty good. 3. How do you planed the reviewing process. Should i create a patch, submit this to you and you'll check it in the cvs repository? Yepp. Maybe it'll be better, that any editor has an cvs access. We certainly can get you one, however I'd like to ensure a consistent typing and markup which is why I'm not too fond of this idea right now. The best way to get your CVS account soon is to flood my mailbox with high quality content so I get annoyed by applying your patches. :) The reviewing process goes on text crosswise. Everyone is checkin the help from another editor? This makes sense once there're more editors. Thats it so far. Tell me if the introduction.xml is okey and i can go any further. Looks good, keep going! -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] writing german online help
Roman Joost wrote: 2. How do i create a better patch? I tried: cvs diff -R help/ foobar.patch but it looked nothing suitable for submitting. All (or most) CVS operations are recursive by default. diff -u gives a unified diff, which is the preferred diff type for the GIMP in general, being quite readable. So cvs diff -u help help.patch should do the trick. To have this option on all the time, add the line diff -u to the file ~/.cvsrc (create the file if there isn't already one). You should probably consider adding the lines update -dP and cvs -z3 -e/usr/bin/emacs too. That's the only one of your questions I have an answer for, though :) Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
[Gimp-developer] Re: Custom layer mode combination
On Saturday 26 July 2003 5:44 am, Adam D. Moss wrote: Joao S. O. Bueno wrote: My idea is that in the end, the custom layer formulas get recorded in a gimp directory, just like brushes and patterns. How are they recorded in the XCF file? (I may have missed that part of the thread.) Parasites. So the only difference to current XCF files would be anm extra layer_mode number. So, a set ofrather itneresting formulas would be shipped with the Gimp (or with the patch). Users won't apply patches -- I doubt that more than a couple of percent of users are even actually building from source (especially for 2.0). yes..that is why I'd be very pleased to see it in 2.0 (but even if I get it ready, it will be so close to freeze date, that maybe the mainteners reject it), or at least for 2.2 . Hey, maybe you can fit into it effect layers. ;] Well, probably not, they are not simple operations to layers below them. Depends if you want to apply filter to the result, which is just the call idea, or to the layer data only, Actually, thta already happens. The formulas are simply. The input operands are the letters describing a channel, followed by 1 if the channel belongs to the image bellow, or 2 if it belongs to the actual layer. And letter+D makes the destiantion channel. So something like: RD=R2*R2; GD=G2*G2; BD=B2*B2; will actually square the values of each channel. Since they are treated as normalized (i.e. from 0 to 1), it's akim to using the curves tool to enhance contrast sharply. (Well, contrast enhancement would be more like a sigmoid function -- what you describe here is basically gamma adjustment for a fixed gamma value.) Ok, gamma them. Sorry, I am not versed in the mathematic fundamentals of thes corrections. However I will implement an exponentiatio operand - so one may use other gammas as well. But it´will have to use F.P. so expect it to be _slow_ . I think that what GSR is really asking for in effect layers is stuff like 'blur layers', 'pixelize layers', etc, which basically is what everyone really wants. :) These require a decorrelation between the positions of pixels of different drawables though -- I made a working prototype of this during 1.1.x and it wasn't pretty. Yes...no way to do taht just hacking in the paint-funcs already existing. On the technical side - I will need to code in some string manipulation now. Are there API's for string deeply hidden ing gtk/gimplib? Not as such -- but if you're using GTK/gimplib then you're already using glib, which has some great string manipulation functions (go look them up). Thanx. I will. :-) --Adam JS -- -- Este e-mail é, exceto pelas partes citadas de outros e-mails, copyright(c) de João Sebastião de Oliveira Bueno. Nenhuma cópia deste e-mail ou parte do mesmo pode existir nas dependências de, ou em posse de funcionários, de associações protetoras de direitos autorais Brasileiras, dos Estados Unidos da América, ou de outros países. Em particular essa exceção do direito de leitura e posse deste e-mail se extende à ABRA, ABPI, ABES, BSA, RIAA e MPAA. Violadores estão infringindo as leis internacionais de direitos autorais e sujeitos às penalidades cabíveis. Você pode re-utilizar, emendar, acrescentar suas palavras e citar e re-enviar qualquer parte do mesmo, desde que essa nota seja preservada e se não pertencer a alguma das entidades supracitadas. --- -- Este e-mail é, exceto pelas partes citadas de outros e-mails, copyright(c) de João Sebastião de Oliveira Bueno. Nenhuma cópia deste e-mail ou parte do mesmo pode existir nas dependências de, ou em posse de funcionários, de associações protetoras de direitos autorais Brasileiras, dos Estados Unidos da América, ou de outros países. Em particular essa exceção do direito de leitura e posse deste e-mail se extende à ABRA, ABPI, ABES, BSA, RIAA e MPAA. Violadores estão infringindo as leis internacionais de direitos autorais e sujeitos às penalidades cabíveis. Você pode re-utilizar, emendar, acrescentar suas palavras e citar e re-enviar qualquer parte do mesmo, desde que essa nota seja preservada e se não pertencer a alguma das entidades supracitadas. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Startup Notification support...
On 26 Jul 2003, at 18:19, Patrick McFarland wrote: On 26-Jul-2003, Daniel Egger wrote: I think the problem is that 1.2 is far more used in productive work because artists and designers are afraid running software which is stamped alpha or beta more than just occasionally. Wrong, Im an artist, and I prefer 1.3 over 1.2. Did you prefer 1.3 in January 2001? -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: (LONG) Problems with the GIMP (was: Re: [Gimp-developer]tentative GIMP 2.0 release plans)
Alan Horkan writes: Any chance of binaries [for Win32] for testing? If you ask nicely, I might be presuaded to zip up what I've got... (Just built it on Win32 for the first time in a while.) And what compiler did you use (wondering if I'll be able to get gtk-wimp to work with the Gimp 1.3 on windows). gcc version 3.2.3 (mingw special 20030504-1) One irritating thing with GIMP on Windows currently is GTK bug #112402, I really need to fix that soon. GIMP's toolbox and some other windows are currently positioned with their title bar exactly off screen. There also seems to be some handle leak when GIMP is starting up and queries all the plug-ins. Also, something needs to be done to #98737 soon. (Perhaps related, I had to start GIMP at least four times before it got past all the plug-ins and wrote out the pluginrc file.) --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: (LONG) Problems with the GIMP (was: Re: [Gimp-developer]tentativeGIMP 2.0 r
From: Tor Lillqvist [EMAIL PROTECTED] To: Alan Horkan [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: (LONG) Problems with the GIMP (was: Re: [Gimp-developer]tentative GIMP 2.0 release plans) Date: Sun, 27 Jul 2003 23:22:07 + Alan Horkan writes: Any chance of binaries [for Win32] for testing? If you ask nicely, I might be presuaded to zip up what I've got... (Just built it on Win32 for the first time in a while.) i'd certainly be very very greatful indeed if you'd do that, please... thnks Phil And what compiler did you use (wondering if I'll be able to get gtk-wimp to work with the Gimp 1.3 on windows). gcc version 3.2.3 (mingw special 20030504-1) One irritating thing with GIMP on Windows currently is GTK bug #112402, I really need to fix that soon. GIMP's toolbox and some other windows are currently positioned with their title bar exactly off screen. There also seems to be some handle leak when GIMP is starting up and queries all the plug-ins. Also, something needs to be done to #98737 soon. (Perhaps related, I had to start GIMP at least four times before it got past all the plug-ins and wrote out the pluginrc file.) --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer _ Sign-up for a FREE BT Broadband connection today! http://www.msn.co.uk/specials/btbroadband ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Startup Notification support...
On 27-Jul-2003, Branko Collin wrote: On 26 Jul 2003, at 18:19, Patrick McFarland wrote: Wrong, Im an artist, and I prefer 1.3 over 1.2. Did you prefer 1.3 in January 2001? Did 1.3 exist in january 2001? -- Patrick Diablo-D3 McFarland || [EMAIL PROTECTED] Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music. -- Kristian Wilson, Nintendo, Inc, 1989 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
