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
Re: new gfig [Re: [Gimp-developer] canvas background options]
On Sun, 14 Nov 2004, David Odin wrote: > Date: Sun, 14 Nov 2004 21:28:44 +0100 > From: David Odin <[EMAIL PROTECTED]> > To: Alan Horkan <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: new gfig [Re: [Gimp-developer] canvas background options] > > On Sun, Nov 14, 2004 at 07:13:32PM +, Alan Horkan wrote: > > > > It might help you to understand my negativity when I explain that the > > underlying instability of windows doesn't do the gimp any favours. When > > binaries are available windows is the easiest platform to test on and in a > > way the instability of the platform is actually helpful for testing. I > > have tried to compile the gimp serveral times during 2.1 but rather than > > asking even more questions here and needing to chase down and compile lots > > of little dependancies and parts of the toolchain I dont have I waited > > for more releases to try again (until eventually there was a windows > > binary I could test with). > > > So, you're telling us you haven't yet tried the current cvs version of > gfig, yet asking us to use the 2.0 one? I have tried the version in gimp 2.2 pre1 > I haven't seen any bug-report for this. I'm am aware of some bugs in > gfig and I have told the mailing list about them. May be you could take > the time to check if your crashes and mines are related? I will try, but I only have a working copy of gimp 2.2 pre1 on my home machine. > One bug is very easy to trigger: draw a line, erase it, draw another > line. Don't tell me this takes too much time to check. Working at home, verify the bug reoccurs and bringing it takes time. I use the computers available to me and they dont lend themselves to keeping up to date and I've never had much luck compiling the gimp from CVS (but that is just me, I'm not claiming it is difficult if you know what you are doing, have admin rights on your machine and a fast internet connection). I'll try and look at a CVS version of gfig this week, but it is painfully difficult for me to get this organised. > new gfig has some issues and I've tried to list them on this very > mailing-list. If you can list more, please list them in the correct > thread. Will do. > 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. To be nominally HIG compliant would require some adjustment of the old dialog. To meet the spirit of the HIG and provide a more user friendly does require the valuable work you are doing. If gfig is not frozen and will be shipping a more stable and up to date version than was in gimp 2.2 pre1 then that would be a different matter entirely. I would much prefer to see your version (with a few improvements) to be the one included when gimp 2.2 is released. - Alan H. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: new gfig [Re: [Gimp-developer] canvas background options]
On Sun, Nov 14, 2004 at 07:13:32PM +, Alan Horkan wrote: > > It might help you to understand my negativity when I explain that the > underlying instability of windows doesn't do the gimp any favours. When > binaries are available windows is the easiest platform to test on and in a > way the instability of the platform is actually helpful for testing. I > have tried to compile the gimp serveral times during 2.1 but rather than > asking even more questions here and needing to chase down and compile lots > of little dependancies and parts of the toolchain I dont have I waited > for more releases to try again (until eventually there was a windows > binary I could test with). > So, you're telling us you haven't yet tried the current cvs version of gfig, yet asking us to use the 2.0 one? > My comments [1] were very restrained, I did say it had potential. The new > SDI application style inteface for Gfig will be very good as it is an > easier way to present all the features that Gfig managed to cram into the > old dialog style of interface. The Gfig had crashed several times > (reproducably and in different places) I haven't seen any bug-report for this. I'm am aware of some bugs in gfig and I have told the mailing list about them. May be you could take the time to check if your crashes and mines are related? > and if I recall correctly it crashed badly enough to take the rest of > the gimp down with it. I really doubt it. > Feedback takes time, and I haven't gotten around to checking if the > problems are known issues or writing a detailed explaination of how to > reproduce them or otherwise tracking them down. One bug is very easy to trigger: draw a line, erase it, draw another line. Don't tell me this takes too much time to check. > I have started to David Odin offlist about it further. The mail you send me only shown you're not following the current gfig development as gfig *does* already use a GtkUIManager toolbar. > > [1] The new Gfig is definately is a bit rough around the edges. It has a > lot of potential though. It really should be reverted to the old usuable > ugly but stable version for the 2.2 release. new gfig has some issues and I've tried to list them on this very mailing-list. If you can list more, please list them in the correct thread. 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, and to update to the new apis. I don't volonteer to do this, but if you can come up with such a beast I will consider to compare both versions. Regards, DindinX -- [EMAIL PROTECTED] A conscience is what hurts when all your other parts feel so good. ___ 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 Horkan <[EMAIL PROTECTED]> writes: > It might help you to understand my negativity when I explain that > the underlying instability of windows doesn't do the gimp any > favours. When binaries are available windows is the easiest > platform to test on and in a way the instability of the platform is > actually helpful for testing. Perhaps I am just too stupid but I can't make any sense out of these words. No matter how hard I try. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
new gfig [Re: [Gimp-developer] canvas background options]
On Sun, 14 Nov 2004, Sven Neumann wrote: > Date: Sun, 14 Nov 2004 00:31:13 +0100 > From: Sven Neumann <[EMAIL PROTECTED]> > To: Alan Horkan <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: [Gimp-developer] canvas background options > > Hi, > > Alan Horkan <[EMAIL PROTECTED]> writes: > > > I was unable to get to use the gimp 2.1 series until recently. I > > cannot provide feedback only when it suits your timetable. When I > > pointed out problems with 2.0 you gave out to me for not mentioning > > them during the 1.3 cycle so I am making my points before 2.2 is > > released. > > A couple of days before 2.2 is released and a long time after the > feature set and the user interface has been frozen. Not a very good > timing. But of course we are always open for suggestions. > > Even though it seems rather useless, let me point you to bug #142996 Thank you that is intersting and helpful, I had not seen that report before. I didn't realise there was a context menu on the old button. I never would have accidentally discovered context menu with such a tiny context target area. > > (I really hope Gfig will be rolled back as the developer working on > > it has previously suggested, it is definately not ready for 2.2) > > We have another developer working on it at the moment and he's > contributing his free time for the task of finishing the changes to > GFig that Bill started. This comment of yours (and you did the same > comment on gnomedesktop.org) is discouraging, nothing else. Please try > to avoid this in the future. It might help you to understand my negativity when I explain that the underlying instability of windows doesn't do the gimp any favours. When binaries are available windows is the easiest platform to test on and in a way the instability of the platform is actually helpful for testing. I have tried to compile the gimp serveral times during 2.1 but rather than asking even more questions here and needing to chase down and compile lots of little dependancies and parts of the toolchain I dont have I waited for more releases to try again (until eventually there was a windows binary I could test with). My comments [1] were very restrained, I did say it had potential. The new SDI application style inteface for Gfig will be very good as it is an easier way to present all the features that Gfig managed to cram into the old dialog style of interface. The Gfig had crashed several times (reproducably and in different places) and if I recall correctly it crashed badly enough to take the rest of the gimp down with it. Feedback takes time, and I haven't gotten around to checking if the problems are known issues or writing a detailed explaination of how to reproduce them or otherwise tracking them down. I have started to David Odin offlist about it further. - Alan H. [1] The new Gfig is definately is a bit rough around the edges. It has a lot of potential though. It really should be reverted to the old usuable ugly but stable version for the 2.2 release. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] fresh cvs gimp-gap and cvs gimp-2.2 crash
On Fri, Nov 12, 2004 at 11:03:01PM +0100, Popolon wrote: > fresh cvs gimp-gap dosn't compile anymore with gimp-2.0. > > I tried to compile it with fresh cvs (today cvs) That's OK, but it > definitivly crash with unknown symbols, is there anything special to do, > for using it? > i am compiling this plug-in successfully with cvs gimp. is this possible for you to try? > I compiled it with > > --enable-gdkpixbuf-pview --disable-libmpeg3 > > configure options. > can i ask the reason to use --enable-gdkpixbuf-pview ? an this might be the problem. thumbnails have changed a lot between the two gimps. i am not sure how gap makes its thumbnails without this option enabled, but i have thumbnails in two cases when i run gap. for the video navigator and also for Animation Playback (that seems to come from gimp source and not gap). let me know how it goes without gdkpixbug-pview if you are able to try it. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
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: [Gimp-developer] Things left to do with gfig.
On Sun, Nov 14, 2004 at 01:29:58PM +0100, Karine Proot wrote:
> 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.
>
2.1 should really happen. (I would very much appreciate a patch for
this).
2.2 should be fixed the right way, so the selected object can become
the current one (it doesn't seems to work atm). So my point of
view is that the select object tool should stay.
2.3 is only a matter of calling the right function in
gfig-dialog.c:paint_layer_fill() to use a shapeburst gradient fill
since it is the only gradient fill that doesn't need a direction.
Then again, I would appreciate a patch or even a direct commit
since I don't intend to change this function in a near future.
Regards,
DindinX
--
[EMAIL PROTECTED]
i;main(b,v)char**v;{char t1['e'],t2['e'],*p;strcpy(t2,v[1]);while(strlen
(t2)<50){puts(strcpy(t1,t2));for(p=t2;t1[i];p+=2)for(*p=49,p[1]=t1[i];t1
[++i]==p[1];(*p)++);*p=i=0;}}
___
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 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] 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] 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
[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
