[Gimp-developer] RSS feed for GIMP CVS commits
Hi, available for a few days already, there is an experimental RSS 1.0 feed for commits to GIMP CVS modules: http://www.gimp.org/~rss/gimp-cvs.rdf This feed is generated from emails sent by the GNOME CVS server. I call it experimental because the description of the individual entries should be improved. If anyone is interested, I can give you the perl script that generates the feed and can also provide some sample mails to play with. Currently the feed is being used to generate the list of recent commits at http://developer.gimp.org/changelog.html and the people from macgimp.org have integrated it to their homepage. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp, docbook or apple trees, fruit or seeds
Am Don, 2003-07-24 um 11.01 schrieb Sven Neumann: Even gimp-1.2 can link to anchors already. There is no need for toplevel HTML files for each and every help topic that should be reachable by pressing F1. In theory, the whole help could be in a single file. That would of course not be useful but any granularity should be doable using anchors. This is possible, but using anchors in a file means that last time I looked you cannot render a notice that the help is not available because the help browser would load the file and then jump to the beginning of the document when the anchor doesn't exist. Also it's not good for the user experience when you press F1 on some tool and get a 50 pages document explaining all tools at once, even when the display starts at the right position within the 50 pages. Not to mention that one will need gobs of memory to render such documents because of all the images we already have or intend to have. But yes, giving up granularity to ease maintainance is possible but more like a quick hack than a real solution. I really detest hacks when not doing them for myself because it makes one look rather foolish. -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[Gimp-developer] State of play, and stage 2
Hi again, There are now only about 25 bugs with the -- milestone - thanks to everyone who filtered these, there were several people involved, in the end about 10 people helped filter these bugs in the past couple of days. Thanks guys. Anyway, before this starts sounding too American (apologies to our US friends), there's stage 2 to be handled. http://makeashorterlink.com/?N47413065 This is a list of the bugs now marked with the 1.3.x milestone. Some of these are feature requests which have just been added to the milestone. Others are bugs which have been on this milestone for some time. Yet more are feature requests which have been on the milestone for months or years. Yet again, these need to be filtered. As before, bugs which should be addressed for the stable release should be set to the 2.0 milestone, features which are easy to do (for example with source code attached) or important should stay in this milestone, and other features should be bumped to the Future milestone. Currently, there are 106 bugs in that list. I would like to see it reduced to somewhere around 30 so that we can start actually getting features coded :) So, once again, your help is needed. If you missed them the last time, the instructions are simple. Go to bugzilla.gnome.org. If you don't already have an account there, get one. If you need permissions to modify milestones, please mail me directly. And then pick a bug or two from this list, and if it needs moving, move it to the right place. Thanks again for all your help. Cheers, 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] gimp, docbook or apple trees, fruit or seeds
Hi, Daniel Egger [EMAIL PROTECTED] writes: This is possible, but using anchors in a file means that last time I looked you cannot render a notice that the help is not available because the help browser would load the file and then jump to the beginning of the document when the anchor doesn't exist. The help-browser behaviour for non-existant anchors could probably be changed. I'd have to look into the GtkHTML2 API to give a more definite answer but I think it should be doable. Also it's not good for the user experience when you press F1 on some tool and get a 50 pages document explaining all tools at once, even when the display starts at the right position within the 50 pages. Not to mention that one will need gobs of memory to render such documents because of all the images we already have or intend to have. Noone said we have to use a single file only. But yes, giving up granularity to ease maintainance is possible but more like a quick hack than a real solution. I really detest hacks when not doing them for myself because it makes one look rather foolish. Now I am finally sure that I still don't have the slightest idea of the problems you see and what you imagine as the solution. Would you mind to explain it for me again? In the meantime, I will try to outline the system I am imagining. We would remove all the hardcoded HTML filenames from GIMP and replace them with unique and meaningful identifiers like for example gimp-file-new-dialog. The help files would be written in DocBook/XML and we would assign the same ids as id attributes to the associated content. The DocBook/XML files are then converted to a reasonably fine-grained set of XHTML files and the XSLT processor creates an additional XML file that holds a mapping from id to filenames. Of course multiple ids may point to the same file. The GIMP helpbrowser is then passed the id, it reads the mapping table and loads the HTML file that contains the anchor with the requested id. If the XML file doesn't list the requested id, the help-browser can display a standard page that explains that help for this subject is missing. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp, docbook or apple trees, fruit or seeds
Am Don, 2003-07-24 um 15.37 schrieb Sven Neumann: The help-browser behaviour for non-existant anchors could probably be changed. I'd have to look into the GtkHTML2 API to give a more definite answer but I think it should be doable. It would be great if you could look it up because this is a real must. Noone said we have to use a single file only. I'm not talking about a single file either but about a file per chapter since we cannot change the granularity at will. Now I am finally sure that I still don't have the slightest idea of the problems you see and what you imagine as the solution. Would you mind to explain it for me again? Since my imagined solution would require efforts which are not handable for the shortterm release let us rather focus on you idea and live with the additional maintainace efforts and less user comfort for now. In the meantime, I will try to outline the system I am imagining. We would remove all the hardcoded HTML filenames from GIMP and replace them with unique and meaningful identifiers like for example gimp-file-new-dialog. The help files would be written in DocBook/XML and we would assign the same ids as id attributes to the associated content. Check. The DocBook/XML files are then converted to a reasonably fine-grained set of XHTML files and the XSLT processor creates an additional XML file that holds a mapping from id to filenames. Okay, so the filenames do not matter anymore and we can use automatically generated ideas instead of forcing the XSLT processor to generate a specific set. This is a big plus over the current situation. But how do we generate the mapping file? Since we rely on the docbookxsl stylesheets they would have to output the mapping right after they wrote the transformed output or remember the ids and output at the end. I do not know whether they have this feature and need to check the current situation. If they don't provide this feature (which is quite likely) we'll really have a hard time, because we'll either have to override all transformations to get the recording and output done or we'll have to simulate the automatic generation of filenames in a to-be-written standalone XSLT file to replay the generation of HTML files thus knowing the filenames. But let me look it up first before we worry about how we get it done... Of course multiple ids may point to the same file. The GIMP helpbrowser is then passed the id, it reads the mapping table and loads the HTML file that contains the anchor with the requested id. If the XML file doesn't list the requested id, the help-browser can display a standard page that explains that help for this subject is missing. Check. -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] gimp, docbook or apple trees, fruit or seeds
Hi, Daniel Egger [EMAIL PROTECTED] writes: The help-browser behaviour for non-existant anchors could probably be changed. I'd have to look into the GtkHTML2 API to give a more definite answer but I think it should be doable. It would be great if you could look it up because this is a real must. The API has html_document_find_anchor() which seems to fit our needs just perfectly. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-perl-cvs status
On Wed, Jul 23, 2003 at 03:33:55PM -0400, Carol Spears [EMAIL PROTECTED] wrote: i am going to spend some time at my moms early next week. this might be one of those cool occasions where i can have the perl I got it working with tml's native build, linking msvcrt and cygwin.dll into the same process (does not work, but actually works) I'll check in a README.win32 soon that describes very roughly what I did. *However* you would better allocate a few days to it. Apart from the compile speed (gcc on win32 compiles 5-10times slower on my machine than under linux), you need quite a lot of time selecting the right toolset and gtk version (there are *many* different gtk+ versions). I'd even recommend against it at this stage, and leave it somebody else to prepare a distribution once 2.0 is out.. :) what is the chances that the gimp perl plugins can run be running on my moms window box next monday evening? close to zero. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Custom layer mode combination
Hi, Maybe some of you can remember that, when I joined this list about two months ago, I proposed a programable layer combine mode for the GIMP. The basic idea is that besides the normal addition darken only layer modes, to implement a custom mode. In it, the user gets to type a c-like expression of what to do with the pixel values in each channel when combining the layer. For example: RD=(R2 + R1) /2; GD=G2; BD= B1; will average the red component, pick the green component from the upper layer, and the blue component from the underlying image. Another example: ED=VD 0.5? DARKEN_ONLY : LIGHTEN_ONLY; If the Pixel value is greater than 0.5 (50%), then combine it as in the Darken Only mode, else, use Normal mode. And it also works as a paint mode, so custom paint mode comes as a bonus with this feature. I had little time to fuss with it over the first month, and now I could manage to get some work going on - still only on a few hours per week. I should make it clear that although I'd like to see it in the GIMP, at this time it's not what concerns me. If people think it's a nice feature, it can be made to work in a clean way before August 10th - actually, it already does work in a clean way, just lack features. If no one is interested, I will appreciate help and feedback nonetheless, and once it's finished, I will just publish the patch to a stable version of the GIMP on my page. However, I am getting some results now, so, I'd like to bring the discussion here, for there is a lot there is unknown to me in the GIMP tree. (From here on, this message should be readable by people familiar] to the source code of the gimp. I mean - if you are confused with this, just skip the rest of the mail.) First of all, I have the engine fairly complete in the app/paint-funcs/paint-funcs-generic.h file. Unfortunattely, I am working off-town, and can only recompile my GIMP, and hack it at all on the weekend. And now, I am thinking on a way to get the custom combination data getting to it. For testing, so far,I had hardcoded the combiantion expression on the source file. As far as I have thought, I'd like to feed it through a call in the combine_sub_region() paint-funcs.c function, passing extra data if mode==GIMP_CUSTOM_LAYER_MODE than it passes to the other functions. Actually, it will have to be this way. At the same time the most obvious way to keep track of this data is putting it in image parasites. So, if a layer has got a custom mode, it's mode is attached to it in a parasite. One issue I am having at the moment is that I'cannot figure out how to get the Parasite data from inside the combine_sub_region function - that function doesn't seen to be aware of in which image it is operating. I think that once I have the image id, it's allright to call the parasite functions on the libgimp-base api from within there. One other doubt I have is where to put the ENUMs I need for the operators inside the engine. I can see the easier way is to add them to app/bse/base-enums.h. Is there any problem with it? And, while away from home, I try to get more familiarized with the code through browsing the cross referenced code on the developers page. But that only shows the files up to line 206. Is that correct? Is tehre a way to see the whole code files from that site? So far...any feed back is welcome. Thanks everybody. JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Could someone add the CVS modules to the devel page?
Hi there. The information about the CVS modules on the web is this bit (from http://www.gimp.org/devel_cvs.html ) __ (...) The avalable modules relating to gimp are are: gimp gimp2 (no code here, just holding place for ideas) gimp-data-extras gimp-plugins-unstable glib gtk+ gegl (experimental code for gimp 2.0) There are also several branches in the GIMP cvs tree: the main or HEAD branch is GIMP 1.3 (the development version), the old GIMP 1.0.x is in gimp-1-0, the stable version GIMP 1.2 is in gimp-1-2; and there are a few other experimental branches such as the HOLLYWOOD branch for deep image support. To check out a branch, gimp-1-2 for example, try this commmand line: cvs -z3 co -r gimp-1-2 gimp (...) __ I know from at least gimp-gap and gimp-perl more, maybe there are a couple I have not heard about. Possibly tehre is a fair easy way to know about the modules using CVS itself. But by knowledge on CVS is close to zero. :-( sorry about that. JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Update from the road to 2.0
Hi again all. This is getting amusing, almost... Before you read on, there's an important part that you shouldn't miss about 3 paragraphs down... make sure to read it before you send this to the trashcan/rubbish bin/waste paper basket//dev/null. Understandably, the going has been a little harder on bugs milestoned for 1.3? but we have brought the total down from over 100 to under 80. The list is still available at this URL... http://makeashorterlink.com/?N47413065 We still need to get this list smaller - somewhere around 30 would be workable. Many of these bugs really are low-hanging fruit - there are patches outstanding to be considered and committed in several bugs, several are no longer valid against the 1.3 series, and more are straightforward bug reports which can be moved to the 2.0 target. The tough ones to get rid of are the feature requests which are still valid against the 1.3 series. There is a certain amount of judgement to be made as to whether a feature gets bumped or kept. So if you get a second to help out, there's still some work to be done (oh, by the way, there are now no bugs without a milestone, you guys rock). Now - here's the important bit. There are several features which are definitely going to be considered before the feature freeze. Over the next couple of days I am going to start posting these to the devel list and asking for volunteers to take on the coding. If a given feature is unclaimed, or no-one expresses an interest in it, after 48 hours the bug will be bumped to Future. If someone says they'd like to try to do the bug, they should add a comment saying so to the bug in bugzilla, and change the status of the bug to ASSIGNED (so that it can be filtered from features which are not being worked on). Hopefully this will lead to some features which are actually quite straightforward getting done in the next couple of weeks, and hopefully some of these bugs will be a nice introduction to gimping for some coders who haven't worked on the gimp yet. Thansk for your time, and don't forget, we still need your help. 15 minutes of your time filtering bugs makes a huge difference to someone working on a big feature. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: GIMP 1.3.17
Greetings, color-space voyagers on board GIMP 1.3. We are approaching our target coordinates and will soon go into feature freeze. Please bring your monitors into an upright position and prepare for download. Lately the course has been changed; it was decided that our journey will not go past version 1.4 as was avised in the infamous The Future of The GIMP document. Instead the next stop will be 2.0. This doesn't mean that we will miss our rendezvous with GEGL, only the coordinates were changed. The reason for this change is the fact that although there are some expectations for GIMP version 2.0 that will not be met, GIMP has improved a lot over the last three years and is certainly past the state that was imagined as version 1.4. People got used to refer to GIMP-1.4 as the next stable version and used to think of GIMP-2.0 as the all-singing-all-dancing wonder tool that would rule the world hand in hand with GEGL. This is still our goal but we feel that so much work has gone into the code base since version 1.2, that the time has come for a major version number increment. The application core has been completely restructured and large parts of it have been rewritten. Along with the port to GTK+-2.0, we continued the revamp of the user interface code that was started after GIMP 1.0 was released. The current code base gives us lots of room for further improvements and it should allow a smooth transition to GEGL. But I don't want to talk more on details of future development. We will be discussing this topic on the GIMP Developers Conference that is going to happen in about two weeks (see http://developer.gimp.org/gimpcon.html). The plan is to go into feature freeze during the heat of the camp. We will then start to make pre-releases for 2.0 in regular intervals asking a larger audience to test our code. Hopefully we can get enough testers for all platforms including Mac OS and Win32 to be able to release version 2.0 with support for as many platforms as possible. Before I get hyped away, let me get back to the original subject of this mail. GIMP version 1.3.17 is now available from the FTP server: ftp://ftp.gimp.org/pub/gimp/v1.3/v1.3.17/ and should soon find it's way to your favorite mirror: http://www.gimp.org/download.html There is a chance that you will experience build problems due to the inclusion of a new compositing sub-system that uses MMX and SSE to accelerate common operations in the layer compositing. If you experience such or any other problem with this release, please file a bug-report at http://bugzilla.gnome.org/. But please check beforehand if the problem has already been reported. If you are hit by the mentioned problems with MMX or SSE assembler code, you can fix your build using the --disable-mmx and/or --disable-sse configure options. Below is a list of changes since version 1.3.16. There are some noteable improvements among them. More to come before the freeze... Overview of Changes in GIMP 1.3.17 == - Made the text tool optionally create a path [Sven, Mitch] - Added the ability to reverse gradients to the blend tool [Mitch] - Added dithering to the blend tool [Alastair M. Robinson] - Changed all(?) GIMP-1.4 references to GIMP-2.0 [Sven] - Allow to transform paths using the transform tools [Mitch] - Added a simple CMYK color selector [Sven] - Added naive RGB - CMYK conversion routines [Sven] - Generalized paint tools [Mitch] - Finally a brush-shaped cursor for all paint tools [Mitch] - Started to integrate new composite functions [Helvetix] - Made the style for dockable tabs configurable [Mitch] - Some preparations for text transformations [Sven] - Store grid settings in XCF [Brix] - Redone assembly checks and run-time checks for CPU features [Sven] - Added lots of mnemonics to the menus [Jimmac] - Support for comments in PNG files [Sven] - Constified the libgimp API and adapted all plug-ins [Yosh, Sven] - Cleaned up the brush/font/gradient/pattern selector API [Mitch] - Support for patterns with alpha channel [Bolsh] - Lots of bug fixes Other contributors: Eric Pierce, Joao S. O. Bueno, Tor Lillqvist, Damien Carbery, Maurits Rijk The weather forecast for our next stop, Altlandsberg, announces a hot sunny weekend close to a LovelyLake. Please make sure you are bringing your towel. Happy GIMPing, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
