[Gimp-developer] Things left to do with gfig.
Hi, As you may know the gfig plug-in was in bad shape, and I've been working on it for a few weeks. Still, there are some issues. I've tried to make a list (ordered by severity): 1 Major. 1.1 deleting an object, by using the delete tool or even undo mess up the current_style variable and can cause a crash on the next object creation. This will be easier to fix when 3.2 and 3.3 will be done. 2 Normal. 2.1 The undo button should be moved to the toolbar. 2.2 The 'select object' tool seems useless, and might be removed. 2.3 Find out how the gradient fill is supposed to work (it is unimplemented for now), or remove it from the filling choice. 3 Cleanups. 3.1 gfig should use glist in some places instead of reimplementing its own structures (DAllObjs, DObjpoints), undos and styles would also benefit to use something else than a static array. 3.2 dobject is used as an abstract class for every kind of objects (arc, line, bezier, etc.) This should be redone using the gobject system. 3.3 the style class should also be derived from a gobject, so it can be easily refcounted. 3.4 use our coding standards all over the place. 4 Tests. As I focus only on some points, I certainly missed some important parts/bugs. For instance, I haven't try to test the saving and loading code. As I said, 1.1 is the major problem for now. Depending on the time we have I would like to have 3.2 and 3.3 fixed before dealings with 1, but it isn't really necessary. All the points in 2 are very easy to fix once it has been decided how to fix them. I'm currently working on 3.1. Any help is of course welcome, but please contact me here or on #gimp before coding anything, to avoid duplicate work. Regards, DindinX -- [EMAIL PROTECTED] You cannot produce a baby in one month by impregnating nine women. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Things left to do with gfig.
David Odin wrote: [...] 2 Normal. 2.1 The undo button should be moved to the toolbar. 2.2 The 'select object' tool seems useless, and might be removed. 2.3 Find out how the gradient fill is supposed to work (it is unimplemented for now), or remove it from the filling choice. [...] All the points in 2 are very easy to fix once it has been decided how to fix them. I'd like to work on them as soon as things are decided. Karine ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparing gimp speed
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 (or not).[1] Since this does not lead to any particular improvement for userspace, without having a patched kernel, it does at least have the advantage of buffers in the kernel to be allocated from highmem first. If you need to address more than the typical limits (1, 2 or 3 GiB) per process, you will need to write a kernel module that communicates with userspace through some syscall or device. In case you want to see some real improvement, have a look at [2] which contains an (probably outdated) patch to have a real 4 GiB available for userspace. [1] http://www.skynet.ie/%7Emel/projects/vm/guide/html/understand/ understand-html.html, chapters 3.4 and 10. [2] http://lwn.net/Articles/39283/ Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] comparing gimp speed
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 having stuff more modular so one can choose which method to use and throw out unneeded stuff, thus saving memory. The mmap idea for instance would be a potential memory saver since the implementation is much smaller than the tile cacheing/swapping code we have now and could be configured to either use space for a swapfile or use the system swap instead. Unfortunately it would need some tuning to get decent performance, but since we do not have any plugging facilities here at the moment the point is moot. In any case people are working on making everything much more modular and thus remove the resource need for functionality which is not used. Granted, the abstraction and the use of GTK+ 2.x were a huge loss at first but they paid off for normal users already and will do so even more in future, also for low-end machines and special uses like headless use. Interestingly, while there seems to be some demand, it's really a seldom event that someone mentions those requirements and even more rare that someone affected by it works on it. So people, step up show some participation! Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] Selection to brush/pattern/whatever in menus...
On Fri, Nov 12, 2004 at 02:41:41PM -0800, miriam clinton (iriXx) wrote: Carol Spears wrote: hi, i am really glad that you stuck with this list. since making this excellent decision, might i direct you to this document: http://www.gimp.org/mail_lists.html and ask that you at least strip the mail the way they ask. they ask me to improve my hardware to work with them, but there are or could be people who are reading this list who store the mails or what have you where size is important. you took classes on how to use this software? or self-educated? Oh and yes, for the record, I picked these tools up and used them - my mother was a painter, not a graphic designer. I learnt the tools in about 30mins. Compared to the GIMP which I still havent got my head around hence my wanting to contribute - better to contribute than to whinge! this is very nice. i dont think that it answered my question though. very nice to be raised in a loving environment with access to many tools and such. gimp was developed by people of all sorts. some had this sort of upbringing and access and some didnt. congratulations to you for deserving all this or whatever. my question, and i could have been more specific, was more about the software you use and the computer you use it on. classes in adobe/macromedia and experience with preinstalled operating systems is what i was looking for exactly. software will never be simple enough for people who need formal training in it. operating systems are difficult to install. i hear complaints from anyone who needs to install any operating system. i really am trying to determine if this is the case with you. if you are used to macintosh, there is a chance that you are used to having everything installed for you and TheGIMP and its fellow free apps might always be out of your grasp. none of this is personal. access is a nice thing. not having access and being able to get this stuff free and legal like is another thing. both are blessings or gifts from life? direct questions: did you have classes in using the software you are comfortable with? pay for books or tutoring? have you even been able to install an operating system on a computer you are in charge of? thanks, carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: new gfig [Re: [Gimp-developer] canvas background options]
Hi Alan, Alan Horkan wrote: On Sun, 14 Nov 2004, David Odin wrote: and as I already said before, using the 2.0 version of gfig would mean to at least port the old version to the HIG standards, I was suggesting shipping the old unmodified version because it was more stable. I just wanted to point out that the 2.0 API is completely backwards compatible from 2.2 to 2.0. That means that you can simply copy the old 2.0 gfig from lib/gimp/2.0/plug-ins to lib/gimp/2.2/plug-ins and it will work just fine. For a user installation, you might want to check, but I believe that plug-ins in the $HOME/.gimp-2.2/plug-ins directory are loaded before the global ones, so copying lib/gimp/2.0/plug-ins/gfig there would do the same job for an unprivileged user. Personally I'm happy to see someone working on gfig. I wasn't aware dindinx was working on it, and given the track record he's built up, I'm sure that the plug-in will be very stable and much more usable in short order. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
