[Gimp-developer] Advanced GUI for Brush Dynamics
Hi, I am a student at IT-BHU India. I am interested in the project of Advanced GUI for brush dynamics suggested by Alexia Death on the ideas page of GNU image manipulation program.I have already applied for the project.My application goes like this As a GNU image manipulation program user I also feel it would be exciting to add new options to brush dynamics.This project would aim at creating a new GUI for brush dynamics as mentioned on the ideas page but would also add some new options like varying the brush properties like color,size,opacity with time in a loop for every x sec.Other than the size,color,opacity shape of the brush could also be mapped against the parameters like velocity,pressure,time.About my skill set I am good at c++ and familiar to gtk+.I am using it to build interface for my project at school GUI for set-cover problem--The greedy approach and also to simulate tools like calculator paintbox etc I was also asked to write why do i think i would be out of the crowd.I am familiar to gtk+ ,I have used it for a couple of small projects and I am good at c++ so I think I will be cope up with the standards faster.People I really need some comments on this so pls leave some ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] OS X GIMP configure can't find JPEG library
Okay, so I've built all (so far as I can tell) the ports I need using
MacPorts, thanks again to the folks on this list. So I cd in OS X
Terminal to the gimp-2.6.6-dev (my copy of gimp-2.6.6) folder and run
configure.
First it complains I have no TIFF library. Well, I don't use TIFF so I
reran with ./configure --without-libtiff
Result:
checking for jpeg_destroy_decompress in -ljpeg... no
configure: WARNING: *** XJT plug-in will not be built (JPEG library not
found) ***
configure: error:
*** Checks for JPEG library failed. You can build without it by passing
*** --without-libjpeg to configure but you won't be able to use JPEGs then.
I use JPEG images, so that will never do. So I go nosing around.
echo $PATH
per MacPorts gives
/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin
I look at configure, and it's looking for /${exec_prefix}/lib where
/${exec_prefix}=NONE.
jpeglib.h (which does define jpeg_destroy_decompress) is in
/opt/local/include
while /opt/local/lib contains
libjpeg.a
libjpeg.dylib
libjpeg.la
libjpeg.62.dylib
libjpeg.62.0.0
I tried changing configure such that exec_prefix=/opt/local
and re-ran in but got the same error.
Anyone know what's up?
Charles Belov
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GSoC] About 4 days till student application deadline
Michael Schumacher wrote: > Hi, > > there are still a few days left until Friday May 3, 19:00 UTC. Friday APRIL 3, 19:00 UTC, of course -- GIMP > http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Wiki > http://wiki.gimp.org | .de: http://gimpforum.de Plug-ins > http://registry.gimp.org | ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp interface changes
On Tue, Mar 31, 2009 at 8:25 AM, Nathael Pajani wrote: > Hi all! > > The number of lines of code has nothing to do with what is important. > Gnome is a UI > Window managers are UI > GIMP is an Image Manipulation Program > The User interface is here to allow access to it's capabilities as an image > manipulation program. > Or am I mistaken again ? No, but this doesn't negate the idea that the UI is the most important part. If GIMP didn't have it's UI, it would instead be something like ImageMagick. Since people mainly use GIMP in a way that is incompatible with ImageMagick, it's reasonable to conclude that the most significant part of GIMP is it's UI. > Right also. > But once again what in here prevented the designers from creating two tools? They did. And then, they got feedback that said, these tools are too similar, I think they would work better merged. > especially when selections can be summed up using different select tools? > But maybe we should stop arguing on this point, as each argument you try to > bring in is an argument for my point of view, or has no relation to the > point you try to defend. > Maybe I'm having you loosing too much time on these emails. I'm not losing any time, though you often don't seem to understand; whether this is because of a language barrier or simply your own insistence on having a different conversation from everyone else participating in this discussion, I don't know; but be assured that any time wasted, is not mine. >> I can quote Sven as saying that the majority of code in GIMP deals with >> UI, >> and my own investigation of GIMP code confirms this. > I did not investigate, so I'll rely on you, and I can understand this very > well. > But it doesn't make the UI any more important. This is a good point. I addressed it earlier in this email. > Nothing about pressing ENTER in the status bar. (in french at least) > Not before you have clicked somewhere to try getting rid of this polygon > behaviour. If you will not experiment, it hardly seems likely that you would discover anything. >> >> What have you tried to discover it? > > I was told in a previous mail. He is asking, 'When you were looking for this feature, what have you done to discover it?', AFAICS. > > OK > I thought 2.2, 2.4, 2.6, were major releases. (They look like it from > outside, with the new splash and so on). GIMP changes splashes quite frequently. For instance, in the 2.3 development cycle, we went through about 5 different splashes. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp interface changes
Nathael Pajani (g...@nathael.net) wrote: > Right. Because I do not see why there are now two windows at startup. > Yes, you pointed to the wiki explanation already. It seems you are all OK for > this empty unuseful window at Gimp startup Please don't confuse your opinion with facts. This window is useful and why it is useful has been discussed already or is described in the spec. > With screens becoming wider, a vertical toolbox is not too much space wasted, > but that big empty window is here for nothing. You even had to specify what > it > should look like for it not to be mistaken for an image window. This was > impossible with the toolbox window. But the toolbox window cannot fulfil the tasks of the no-image window. For a start it cannot show the proper global menu. > > If the complexity increases logarithmic or linear is not that > > impotent. But I don't understand, why you are trying tu discuss facts. > > Every option is expensive. It costs time in programming, testing, > > documenting, supporting ... > And ? > Gimp is not a "paint". I thought free software were not bound to > create releases in time at the lowest possible cost. Gimp not being "paint" - which in itself is a polemic and not-helpful non-comparison - does not mean that we *have* to make our life harder than necessary. [...] > >> Right and wrong. > >> Right, the UI must not come as an afterthought. > >> But the UI is not the main part of an Image manipulation program, it's > >> here to > >> give access to it's capabilities. > > Have a look into the code, the UI is the biggest part in GIMP. > The number of lines of code has nothing to do with what is important. > Gnome is a UI > Window managers are UI > GIMP is an Image Manipulation Program > The User interface is here to allow access to it's capabilities as an image > manipulation program. > Or am I mistaken again ? Count the numbers of people using gimp as a programmatic backend and compare it to the number of people using gimp via the GUI. Then you have a rough estimate if the UI of Gimp is important or not. (Hint: There is a reason why we recomment imagemagick to people for certain tasks) > > The UI actually is the main part of an Image manipulation program; > NO > > at least, it's the main part of GIMP. > NO again, because you are confusing it's goal, and the number of lines > of code related to each part. Why are you trying to argue against our own perception of the Gimp? Isn't Gimp what the Gimp developers think it is? > > An other reason for keeping the 'New Image' at top is, that it is the > > recommended place from the Gnome HIG. > And ? > Gimp will become GNOME dependent ? > > (And the Apple HIG) > Apple dependent ? I guess we should follow the NHIG - i.e. The Nathael Human Interface Guidelines. Because there is nothing that is researched better. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A very simple feature that would be very nice...
Hi Hadrien, On Tue, Mar 31, 2009 at 5:48 AM, Hadrien G. wrote: > => I'm currently using Microsoft Windows XP as my main OS. Would it help > greatly to get some Linux distro back on my hard drive ? Yes, development is much easier on Linux. > => How does one design the gimp UI ? Are there graphical tools/XML > files/other high-level things to know about ? Or is this hard-coded in some > unit (and, in that case, which unit) ? You can experiment with graphical designing using Glade. But you would need to finally code the GUI manually, since we don't use Glade in GIMP. http://zetcode.com/tutorials/gtktutorial/ might help. > => By the way, could one show me an example of gimp config file saving code, > to know which standard applies here ? > => A proposal is to switch between whole different gimprcs. Is this really > wise ? I mean, shouldn't some settings stay profile-independant, say, those > about memory management, help system, display (especially DPI), color > management, and folders ? That was my proposal for working with gimp as it currently is; of course this is not exactly what is wanted, just what could be done with the current gimp. > I think that one should first plot some boundaries around the profile thing. > What should be included in a profile, and what shouldn't ? > Personnally, I would suggest : > -Toolbox state > -Dockable windows status > -Keyboard shortcuts (maybe) > -Tool options Does this include presets? (see tool-options directory in your personal gimp directory) > -Image window appearance (maybe) Are you talking about whether rulers, menubar, selection, etc.. is shown in the default image window? If so, I think that's stored in gimprc. If you're rather talking about image window position and size, it's stored in sessionrc, along with the dockable windows state. > -Extended input peripheral shortcuts (maybe) Although Photoshop supports switching between sets of keyboard shortcuts (and presumably between sets of peripheral shortcuts), it might be quite confusing to switch between them. I think if you asked Peter, he would say "that's more trouble than it's worth". You might consider including this too: - Device status (found in devicerc) This would mean that when you switched between profiles, it could automatically switch to a sensible tool and sensible brush, colors, etc. > => Should one new config file be created for each profile, and a "profile" > subfolder be added to the .gimp-2.x directory ? In any case, which naming > convention should I use ? I think .gimp-2.x/profiles is probably appropriate. Each profile would almost certainly need to be a subdirectory with multiple config files (eg toolrc, sessionrc, ..) . > => Should this setting be called a profile or workspace ? Profile seems more accurate, to me. > => Where should this be put in GUI to make people know about it ? The > preference dialog is a pretty obvious location, but since this is more > likely to be used as a tool than as a setting, shouldn't there be a specific > dockable window about it ? And should this be added to the default UI or not > ? A dockable would be good while you're developing it; We should probably try to get Peter's input on what a sensible way for it to end up might be. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GSoC] About 4 days till student application deadline
On Tue, Mar 31, 2009 at 12:44 AM, Michael Schumacher wrote: > Remember: deadline is May 3, 19:00 UTC > Deadline for mentor sign up and ranking is May 15, 07:00 UTC May -> April? :) Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] [GSoC] About 4 days till student application deadline
Hi, there are still a few days left until Friday May 3, 19:00 UTC. At that time, the SoC web application will switch student applications to read-only and new applications can't be submitted anymore. This means that: Students: - If you didn't submit your application yet, please do so now. Otherwise all the applications that are already submitted might get a head-start. BTW, a useful suggestion has come up on the #gsoc IRC channel (on Freenode) today: while editing your applications won't be possible after the deadline, the basic functionality of the web application will continue to work. This includes creating documents. If you create one for each of your applications and reference it there, you'll have a convenient way to add and edit information after the deadline. Remember: deadline is May 3, 19:00 UTC Mentors: Please browse the applications that are currently available and comment on them - either public (this makes application editable for the students) or in private if you'd like to request the opinion of other mentors. Would-be mentors & people interested in ranking applications: - Sign up and apply as mentors to GIMP. If you think that I might not be able to recognize your name there, then please post on the gimp-developer list first (I've already rejected two mentor applications because no one was able to identify the people what did try to sign up). If you do mention some possible mentors in either the ideas wiki page or mails, then please make sure that they do know about this. Either get them to sign up or provide me with their mail address, so that I'm able to contact them. I've seen at least two names that aren't appearing on the signed up mentors yet. If you want to help with the application ranking, then sign up as well - no one force you to mentor. Your input will be invaluable, though (neo, mitch, yosh; yes, this is about you :) Deadline for mentor sign up and ranking is May 15, 07:00 UTC Links: -- Timeline: http://socghop.appspot.com/document/show/program/google/gsoc2009/timeline FAQ: http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs GIMP & GEGL ideas page: http://wiki.gimp.org/gimp/SummerOfCode2009ideas Regards, Michael -- GIMP > http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Wiki > http://wiki.gimp.org | .de: http://gimpforum.de Plug-ins > http://registry.gimp.org | ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp interface changes
Hi all! Tobias Jakobs wrote : > On Mon, Mar 30, 2009 at 00:30, Nathael Pajani wrote: >> These are dockable. And we can create as many windows as we want, with >> groups of >> these tabbed inside. This is customization. >> The main menu (http://www.nathael.org/Data/main_menu.jpg) should be dockable >> as >> well. > If you make such suggestions please always say why. Right. Because I do not see why there are now two windows at startup. Yes, you pointed to the wiki explanation already. It seems you are all OK for this empty unuseful window at Gimp startup or when the user closes all image windows to bring back it's desktop space for something else. With screens becoming wider, a vertical toolbox is not too much space wasted, but that big empty window is here for nothing. You even had to specify what it should look like for it not to be mistaken for an image window. This was impossible with the toolbox window. And then, using the toolbox window to open a new image seems OK to me, while using an existing image window is just incoherent. >> But then I do not see the merit behind having an empty window when you start >> gimp, with most menu being empty. >> It's it not being here but still taking up the space that is strange: >> http://www.nathael.org/Data/unused_menu_space.jpg > That is not the space that was used for the menu, but a new space that > was added after removing the menu to indicate that you can drop images > to the toolbox like you can drop images to the "No Image Window" (NIW) So, a duplicate space, and as we can drop in the tool selection part, it's mostly an extension of this space, so taking up space for not much. > If the complexity increases logarithmic or linear is not that > impotent. But I don't understand, why you are trying tu discuss facts. > Every option is expensive. It costs time in programming, testing, > documenting, supporting ... And ? Gimp is not a "paint". I thought free software were not bound to create releases in time at the lowest possible cost. >> Once again, I'll use the kernel as an example here: I won't bother counting >> the >> number of options and the possibilities resulting, I'll just state that it's >> the >> biggest piece of code I have ever seen, and still the most reliable. >> Are kernel programmers "superhero" ? "genius" ? > As a lot of other people already told you, you can't compare the > kernel with GIMP. Just have a look at the number of developers. There > are ~10, perhaps even less, active GIMP developers and no one is paid > for working on GIMP. Ok, I'll drop this comparison. And I won't comment on the number of gimp developers, but try not to have it decreasing further. And Gimp being free software, you can call on contributors... But some seems to wait for it to be a phoenix... >> Another example I'll use as some spoke about it previously: Gnome. I'll not >> bother counting the options you can find in gconf either. Still, gnome is >> stable >> (from my point of view at least, but most will agree) and even if it's not a >> perfect display manager, I think it's a very good one that manages to perform >> it's task. >> And the Gnome example is most accurate, don't try saying the contrary this >> time: >> it uses GTK, and it's also a GNU project. >> > But it's not one program. If you are looking for a programm to compare > GIMP with have a look at OpenOffice, Inkscape, Blender, Krita... Ok, I'll use one of your proposed examples: OpenOffice Won't bother counting the options either. >> Right and wrong. >> Right, the UI must not come as an afterthought. >> But the UI is not the main part of an Image manipulation program, it's here >> to >> give access to it's capabilities. > Have a look into the code, the UI is the biggest part in GIMP. The number of lines of code has nothing to do with what is important. Gnome is a UI Window managers are UI GIMP is an Image Manipulation Program The User interface is here to allow access to it's capabilities as an image manipulation program. Or am I mistaken again ? Even, both parts might be independent and many UI being pluggable to the image manipulation part. >> So designing the UI first is just silly. Both have to be thought in parallel. > Of cause this in reality not an linear process, but an interaction > between the developers, the UI designers and the users. Right. David Gowers wrote: > -- this is what led to the current form of the free-select tool -- but > the whole idea of an application is to provide capabilities to the > user .. the interface should not be dependent in any way on how the > feature is actually implemented, just that the way it's implemented > should be reasonably straightforward and plain. Right also. But once again what in here prevented the designers from creating two tools? especially when selections can be summed up using different select tools? But maybe we should stop arguing on this point, as each argument you try to bring in is an argument for m
Re: [Gimp-developer] A very simple feature that would be very nice...
David Gowers a écrit : Hi Hadrian! On Mon, Mar 30, 2009 at 4:06 PM, Hadrien G. wrote: Hi ! Playing with gimp lately, I've been thinking that it would be nice to be able to save the toolbox state (and maybe other things related to dockable window placement) in profiles. As an example, when I make photo editing, I use different tools that when I draw. Thanks to gimp's system, I can make toolbox changes that reflect those needs. But it's pretty long to play with the toolbox, and as there's no "save" button available to save my changes, I don't do that that often. I think it's a bit sad. Saving windows state would have the same purpose : being able to quickly switch between different workspaces that are useful for different works, while keeping a clean UI for each work... Until that is implemented, you can do something like this by creating additional personal .gimp-2.x directories from copies of your base one, one for each UI configuration, and specifying which gimprc to use when running gimp (example commandline: "gimp --gimprc ~/.gimp-2.7-photoedit/gimprc"). Once you've done that, just customize the UI accordingly for each profile. Then everything is ready and you can just create shortcuts or menu items that run a command like "gimp --gimprc ~/.gimp-2.7-photoedit". If you want your suggestion implemented, I suggest doing it yourself. AFAIK it's not too hard, and no developer currently has enough interest in it to implement it themselves. Hope that helps, David Thanks for that suggestion ! I'll try doing my best ;) But since I've never played with gimp's source code, nor with the GTK thing (I've already done a lot of Delphi programming, and know a bit of C++/SDL, but I don't think this will help there...), may I ask for some help here, specifically on the following areas of interest ? => I'm currently using Microsoft Windows XP as my main OS. Would it help greatly to get some Linux distro back on my hard drive ? => How does one design the gimp UI ? Are there graphical tools/XML files/other high-level things to know about ? Or is this hard-coded in some unit (and, in that case, which unit) ? => By the way, could one show me an example of gimp config file saving code, to know which standard applies here ? => A proposal is to switch between whole different gimprcs. Is this really wise ? I mean, shouldn't some settings stay profile-independant, say, those about memory management, help system, display (especially DPI), color management, and folders ? I think that one should first plot some boundaries around the profile thing. What should be included in a profile, and what shouldn't ? Personnally, I would suggest : -Toolbox state -Dockable windows status -Keyboard shortcuts (maybe) -Tool options -Image window appearance (maybe) -Extended input peripheral shortcuts (maybe) => Should one new config file be created for each profile, and a "profile" subfolder be added to the .gimp-2.x directory ? In any case, which naming convention should I use ? => Should this setting be called a profile or workspace ? => Where should this be put in GUI to make people know about it ? The preference dialog is a pretty obvious location, but since this is more likely to be used as a tool than as a setting, shouldn't there be a specific dockable window about it ? And should this be added to the default UI or not ? Thanks ;) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Focus strange behavior
Hi ! One can use the TAB key to hide the tools windows in gimp, but it will only work if the image window has keyboard focus. That mean that if I want to draw something on my picture, i have to : -Select a tool -Click on the image window to give it keyboard focus -Type TAB -Draw What I would expect would be : -Select a tool -Type TAB -Draw Is this behavior made this way on purpose or is it a bug ? Thanks ;) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp interface changes
Hello! On Mon, Mar 30, 2009 at 00:30, Nathael Pajani wrote: > David Gowers a écrit : > > These are dockable. And we can create as many windows as we want, with groups > of > these tabbed inside. This is customization. > The main menu (http://www.nathael.org/Data/main_menu.jpg) should be dockable > as > well. If you make such suggestions please always say why. To add customization because it is technical possible is not an argument. Every new option or new feature must help to reach the product vision. And to do so, every new feature should have an usecase that describes how this feature helps to reach the product vision with this feature. >> To show some perspective on this, you can regard each togglable option >> in the GIMP preferences as a bit in a binary number. In SVN head, this >> binary number is 43 bits long [...] means that there are >> 8,796,093,022,208 combinations of options to test already. >> [] > I cannot agree with you here. If the complexity increases logarithmic or linear is not that impotent. But I don't understand, why you are trying tu discuss facts. Every option is expensive. It costs time in programming, testing, documenting, supporting ... > Once again, I'll use the kernel as an example here: I won't bother counting > the > number of options and the possibilities resulting, I'll just state that it's > the > biggest piece of code I have ever seen, and still the most reliable. > Are kernel programmers "superhero" ? "genius" ? As a lot of other people already told you, you can't compare the kernel with GIMP. Just have a look at the number of developers. There are ~10, perhaps even less, active GIMP developers and no one is paid for working on GIMP. > Tell me, I'm one of them, I'll appreciate :) > Another example I'll use as some spoke about it previously: Gnome. I'll not > bother counting the options you can find in gconf either. Still, gnome is > stable > (from my point of view at least, but most will agree) and even if it's not a > perfect display manager, I think it's a very good one that manages to perform > it's task. > And the Gnome example is most accurate, don't try saying the contrary this > time: > it uses GTK, and it's also a GNU project. > But it's not one program. If you are looking for a programm to compare GIMP with have a look at OpenOffice, Inkscape, Blender, Krita... >>> > Sorry, but the GIMP user interface sucks and that urgently needs to >>> > change. >>> Has there been a survey about this ? >> Alexandre addressed this, but also : 95% of software UIs suck quite >> badly. This is because most often they are simply written as an >> afterthought to the backend: 'oh, we need to make this FOO capacity >> available to the user. What's the easiest way to do that?' rather than >> designing the frontend first and designing the backend so it fits well >> with the frontend. This leads to incoherent UI -- and customization of >> dubious value. > Right and wrong. > Right, the UI must not come as an afterthought. > But the UI is not the main part of an Image manipulation program, it's here to > give access to it's capabilities. Have a look into the code, the UI is the biggest part in GIMP. > So designing the UI first is just silly. Both have to be thought in parallel. Of cause this in reality not an linear process, but an interaction between the developers, the UI designers and the users. > But this is very hard for a project like Gimp, when programmers are more > interested in the backend part and when this part is made up of small parts > added one by one with no global initial view. You are having a wrong assumption here. Most of the GIMP developers are interested in the UI and the "global initial view" is the product vision. >> The recent changes, OTOH, were based on real UI work with users to >> discover what things users most often had trouble with. > I just hope you did not ask users that would like to have a photoshop clone > for > free. > That's why I pasted the points from GimpCon 2006. Users tend to want what they > have with the commercial software. Gimp is not that. The GIMP GUI team made user observations, wrote user scenarios, made a meeting with the developers, community members, documentation writers and more. And one of the rules always was and still is: "GIMP is not Photoshop!" > But then I do not see the merit behind having an empty window when you start > gimp, with most menu being empty. Have a look into the "No image open specification": http://gui.gimp.org/index.php/No_image_open_specification >> And of course, if you don't like that menubar taking up space, you can >> disable it > It's it not being here but still taking up the space that is strange: > http://www.nathael.org/Data/unused_menu_space.jpg That is not the space that was used for the menu, but a new space that was added after removing the menu to indicate that you can drop images to the toolbox like you can drop images to the "No Image Window" (NIW) >>> One s
Re: [Gimp-developer] A very simple feature that would be very nice...
> Von: "Hadrien G." > Playing with gimp lately, I've been thinking that it would be nice to be > able to save the toolbox state (and maybe other things related to > dockable window placement) in profiles. See http://bugzilla.gnome.org/show_bug.cgi?id=151538 IIRC, GIMP can already be run started with different session profiles (see the --session command line parameter). A way to switch sessions from within GIMP may be useful. HTH, Michael -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
