Re: [Gimp-developer] Color spaces and layer blend modes - tool layers
> #1: Add additional color spaces to the color manipulation tools > (HSV/HSL/HSY/RGB/Lab/LMS/CMYK/etc/etc), where appropriate. If by this you mean that one could choose the colour space and the individual channels in which the command or tool is applied, then this is an excellent idea. It would help speed up the image processing workflow, allow for tools to be used with more precision, and in many cases obviate the need for using layers to accomplish processing tasks. Charlie ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] [oli...@first.in-berlin.de: Re: small Wishlist regarding Guides]
hello,
this should have been sent to the list...
so my answer forwarded to here.
- Forwarded message from oli...@first.in-berlin.de -
Date: Sun, 1 Aug 2010 23:40:45 +0200
From: oli...@first.in-berlin.de
To: LightningIsMyName
Subject: Re: [Gimp-developer] small Wishlist regarding Guides
User-Agent: Mutt/1.5.20 (2009-06-14)
Hi,
On Sun, Aug 01, 2010 at 06:42:00PM +0300, LightningIsMyName wrote:
> Hello
>
> > - non-rectangle-bound guides:
> > Guides that can be enabled to have any angle, which means that they do
[...]
> I think we have seen this request already several times and I
> definitely agree it could be useful. Your request made me take a look
> at the code (app/display/gimpdisplayshell-draw.c,
> app/core/gimpimage-guides.c, /app/core/gimpguide.c) and it actually
> seems possible. I'll add it to my to-try list for when I have some
> more time.
Fine :)
[...]
> > - boundary guides, instead of middle.guides:
> > Guides, where the outer boundary of a drawing tool snaps to the guide
> > (instead the middle of the
> > drawing tool snapping to the guide).
> >
> > This would be helpful for drawing in general, and correcting pictures:
> > the color will
> > not pass this line of the guide, which means, you can be sure no color
> > enters a certain region.
>
> This does not seem trivial to code - in fact with how I remember the
> paint core works, this is going to be one very hard hack...
> Also, I think that if the purpose is just to stay inside of the lines
> you can use a selection (create it using the guides and freeform
[...]
The selection does not has the magnetic behaviour as a guide has.
Maybe even a freely definable guide would help here,
or a magnetic selection, or something like this ?!
[...]
> > - Adding Multiple Guides
> > (there is a Script for this on www.meetthegimp.org, but native would be
> > nice)
> >
> > This feature is good for some repetitive tasks, where a lot of Guides
> > will be needed,
> > something like a guide-grid.
>
> Can you give a direct link to the script?
I didn't found the link by myself, but I have the script local on my machine
and can attach it.
It's not writen by me. But I may look for the original link later (or ask the
admin).
> I definitely agree this
> sounds useful - it's worth checking if we can simply include this
> script with GIMP
The GUI/behaviour could be enhanced, and could be more Gimp-like.
But it's already useful and has saved me a lot of time in some tasks.
> (or at least if you give us a link to it, we'll be
> able to write something similar with extra features if needed).
I will attach it here.
I hope attachements are not blocked here.
Ciao,
Oliver
import os
from gimpfu import *
import os.path
import pygtk
import gtk
gettext.install("gimp20-python", gimp.locale_directory, unicode=True)
def debugMessage(Message):
dialog = gtk.MessageDialog(None, 0, gtk.MESSAGE_INFO, gtk.BUTTONS_OK,
Message)
dialog.run()
dialog.hide()
def findMaxDimensionOfImage(Image, Direction):
if (Direction == 0):
limit_value = pdb.gimp_image_height(Image) -1
else:
limit_value = pdb.gimp_image_width(Image) -1
return limit_value
# This defines the class
class addMultipleGuidesDialog:
# Things to do with the image reference
imageRef = 0
def set_imageRef(self,Image):
self.imageRef = Image
def get_imageRef(self):
return self.imageRef
# Things to do with the guides we create
thisGuide = 0
def set_thisGuide(self, guideRef):
self.thisGuide = guideRef
def get_thisGuide(self):
return self.thisGuide
# RadioGroup
radio_group = []
def set_radioGroup(self, radioGroup):
self.radio_group = radioGroup
def get_radioGroup(self):
return self.radio_group
# Adjustment
the_adjustment = 0
def set_adjustment(self, newAdjustment):
self.the_adjustment = newAdjustment;
def get_adjustment(self):
return self.the_adjustment
# Labels (possible to change later for translation purposes)
Labels = ["Horizontal", "Vertical", "Add", "Close", "Remove Last"]
#Labels = ["H", "V", "A", "C"]
def get_Labels(self, labelIndex):
return self.Labels[labelIndex]
# This is a callback function. The data arguments are ignored
# in this example. More on callbacks below.
def hello(self, widget, data=None):
print "Finished"
def findActiveRadioButton(self):
active = [r for r in self.get_radioGroup() if r.get_active()][0]
return active.get_label()
# call back for the Add button
def add_guide(self, widget, Data):
activeLabel = self.findActiveRadioButton()
position = Data.get_value()
if (activeLabel == self.get_Labels(0)):
currentGuide = pdb.gimp_image_add_hguide(self.get_imageRef(),
position)
else:
currentGuide = pdb.gimp_image_add_vguide(self.get_imageRef(),
p
Re: [Gimp-developer] small Wishlist regarding Guides
On 08/01/2010 05:42 PM, LightningIsMyName wrote: > Hello > >> - non-rectangle-bound guides: > > I think we have seen this request already several times and I > definitely agree it could be useful. FYI, here's a bug report with a non-finished patch: https://bugzilla.gnome.org/show_bug.cgi?id=344109 / Martin -- My GIMP Blog: http://www.chromecode.com/ "Automatic tab style and removed tab title bar" ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] pick color anywhere on the screen ? not quite
Hello, I discovered that when using windows it will indeed turn to the regular cursor when you leave GIMP's UI, but the "pick" functionality still works. Click anywhere on the screen - although GIMP's window will loose focus (in favour of the window you clicked on) the right color would still be picked (at least on my windows XP SP3 32). On linux it works perfectly - the GIMP window doesn't even loose the focus. If colour picking still doesn't work (check that if you click out of the window and go back to GIMP, if the foreground color was set to the right color) you are welcome to open a bug report at the GIMP bugzilla https://bugzilla.gnome.org/enter_bug.cgi?product=GIMP ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] pick color anywhere on the screen ? not quite
On Sun, 1 Aug 2010 23:31:00 +0300, Cristian Secară wrote: > [...] > - it does not work on the image itself or GIMP UI, in that a click > anywhere on the image will set the foreground and/or background to > black (has set both at different moments, but could not undesrtand why > the one, or why the other) No, the last part I understand, I clicked accidentally the fg/bg rectangles (but the rest of my message remains true). Cristi -- Cristian Secară http://www.secarica.ro ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] pick color anywhere on the screen ? not quite
Open the colors dialog (Windows -> Dockable Dialogs -> Colors). On the bottom of the panel, there is a button with a screen and an eyedropper over it. The floating tooltip says: Click the eyedropper, then click a color anywhere on your screen to select that color. Is this true on Linux ? (I cannot check) On Windows (Vista 64, GIMP 2.7.1, classic mode UI): - it does not work on the image itself or GIMP UI, in that a click anywhere on the image will set the foreground and/or background to black (has set both at different moments, but could not undesrtand why the one, or why the other) - when the mouse cursor goes off the GIMP UI, the eyedropper turns to normal mouse cursor, thus not being able to pick anything Apart from that, the "select" word is confusing, I think it would be better "pick" instead (assuming it should work as stated here http://docs.gimp.org/en/gimp-dialogs-content.html ) Cristi -- Cristian Secară http://www.secarica.ro ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color spaces and layer blend modes - tool layers
On Sun, Aug 1, 2010 at 1:04 PM, Bill Skaggs wrote: > It would be much better not to use the word "tool"in this way. I agree terminology is going to be difficult. I get the impression you are only thinking about color, but I'm not. Maybe it's clearer if I use the terms "Image layer" and "Blend layer". So our layer tree has an image on the bottom and an image on the top. Where the top image has alpha, the bottom image can been seen through, as it is today. Now, instead of making the layer mode "Multiply" (or 'screen' or 'saturation' or 'lighten' (which have the same issues as color), etc), the user inserts a "Blend Layer" between the images. This "Blend Layer" is a "Multiply" type, and the "Multiply Blend Layer" has properties associated with it. One of these is "Color Space". Further, this "Blend Layer" has a gray(/alpha) mask so that the layer effect may apply to only a portion of the image. Further still, multiple "Blend Layers" may reside between the two images. So for example, picture a bottom layer of a frog sitting on a log. Above that is a "Desaturation Blend Layer" in the HSY color space, making it appear black and white. Above that is "Lighten Blend Layer" that is a graymask of the frog, making only the frog appear slightly puched-out. Above that is a color image layer of a butterfly (or something) near the frog. Your graph now resembles: - [Image]: Butterfly - [Blend]: Lighten (Lab), Frog mask - [Blend]: Desaturate (HSY) - [Image]: Frog on a log I'm thinking that some color tools could become unnecessary if you do this (just create a blend layer and flatten the image...), but I'm not advocating their removal. I'm also thinking that 'layer modes' could be useful when you have multiple blend layers, but they wouldn't be as problematic as they are all gray masks (add, subtract, etc. are all well-defined.) > backward compatibility. If you can find a way to make the Hue/Saturation > tool work better, there's no strong reason it couldn't be put into Gimp. > Changing layer modes that are stored in XCF files is more problematic. I'm not sure where this is coming from, but so it's clear: I think that Hue/Saturation is essentially unfixable. If you want to work in L*a*b space, such ideas don't exist. You would either need a color space selector and a complicated tool, or a tool for each colorspace type. And layer modes go away altogether. Instead you get a "Blend Layer" that performs the operations of the tool, using the color space specified in the properties of this "Blend Layer". And instead of constraining your image using a selection, the "Blend Layer" retains a gray mask indicating the affected pixels. The gray, in this case, replacing (or augmenting) an opacity slider. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] html layers
Am Sonntag, 1. August 2010 schrub Christopher Curtis: [...] > but HTML is a decent way to store stylized text. HTML may be suitable to store basic things like size, font face, color and so on, but it's far from typographic needs like manual kerning, … HTML isn't meant to describe the form of data but the content. In an ideal world all form would be defined with CSS. So better stop dreaming of HTML in GIMP. The best I can think of is an plugin which takes the text layers, throws away all the information it doesn't understand and output the rest as HTML. > Chris Tobias signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color spaces and layer blend modes - tool layers
It would be much better not to use the word "tool"in this way. In Gimp, a tool is an element of the user interface. When the user applies a tool, the end result is to perform a series of operations on the image. Thus, a tool is a user interface element that allows the user to interactively specify a series of operations. What you are talking about storing as part of the image are color operation layers, not tool layers. The flip side is that the way a tool works can be changed without violating backward compatibility. If you can find a way to make the Hue/Saturation tool work better, there's no strong reason it couldn't be put into Gimp. Changing layer modes that are stored in XCF files is more problematic. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] html layers
Alexandre Prokoudine wrote: > On 7/31/10, peter sikking wrote: > >> so there is an explicit 'no' for GIMP as a web design tool. > > You probably meant web programming :) no I really meant the web design job: deciding how all information and interaction is gong to be represented on the page, how the layout handle fluid conditions of resizing browser width and browser font resizing. all the typography and readability. that combined with the 'master' visual design from which all the pages will be produced, at which point all the images for a site will be produced (which is where GIMP comes in). >> there is an explicit 'yes' for GIMP as a production tool for >> all graphics that are used on a website. This does mean that >> there needs to be better support for this, like automated >> cutting and exporting of all the parts from a working canvas, >> much more than the hack-ish slicing we have right now. > > But that would also involve saving information about slicing in XCF or > whatever comes after current XCF, because one really doesn't want to > do all the work over and over again. yep, one or more 'cutting masks' would be part of the file, because the (perhaps overlapping) rectangles where to cut are gonna be different for every file. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] html layers
Lightning wrote: > I don't agree with some of the product vision points as stated in the > UI redesign wiki and by some developers (for example that GIMP is > meant mainly for high end users and less for "simple" users - as we > discussed on IRC yesterday) well, that is a tricky thing to say. It was the core GIMP team that was there at the first LGM, and they were really sure about this. The vision is not my thing, I was only there at that moment to function as a catalyst to get the vision on the table. So it really does not matter whether you or I agree if GIMP should be what is says in the vision. Because it is going to be what it says in the vision anyway. It is going to be UI designed and developed in that way, because GIMP as a project wants to to go there. Anything that gets done in another direction is just a detour and a (ultimately) a waste of time because it will get corrected in the long run. and no, the vision cannot be changed on the hoof, because most of the work that has been done since that first LGM and now would have the be redone. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] html layers
Hello On Sun, Aug 1, 2010 at 7:15 PM, Christopher Curtis wrote: > What format does it save the per-character formatting in? Would HTML > be an option? > > Understanding even a subset of the basic HTML1 tags plus could > likely be a good 80% solution. That's not to say that it's easy > ( the most obvious problem), but HTML is a decent way > to store stylized text. GIMP supports some of the features described in the pango markup - see http://library.gnome.org/devel/pango/stable/PangoMarkupFormat.html. Currently, this includes the following per-character control: Font, Size, Spacing, bold, italic, underline, strikethrough, baseline (raising/lowring the caracter) and when I'll have more time it will also include color. ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] html layers
On Sun, Aug 1, 2010 at 3:40 AM, Martin Nordholts wrote: > Have you tried GIMP from git? It has been made possible to do > per-character formating in text layers there. What format does it save the per-character formatting in? Would HTML be an option? Understanding even a subset of the basic HTML1 tags plus could likely be a good 80% solution. That's not to say that it's easy ( the most obvious problem), but HTML is a decent way to store stylized text. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Color spaces and layer blend modes - tool layers
Hello, Let me start by saying I haven't been following any development builds of GIMP or GEGL, so I may have some false presumptions and I certainly lack some information. That aside, I'd like to ask some broader questions about color spaces. Firstly, some background: the HSY color space appears to be much better than HSL, at least for some color operations. The package "PhotoPNMTools" operate in HSY mode and produce very nice output on their page of sample images. I'm not sure how the operation "Increase saturation 4x" is performed in GIMP, but when I use the Hue-Saturation tool and set Saturation to "100" four times the result is far worse than what is displayed on the sample images page (using GIMP 2.6.8). [ PhotoPNMTools: http://www.13thmonkey.org/~boris/photopnmtools/ ] [ Sample Images: http://www.13thmonkey.org/~boris/photopnmtools/saturation-test.html ] Using the PhotoPNMTools and the flower image, I've set the saturation to 4000 (on a scale of 0..1) and it still looks better than GIMP's output. I've also set the saturation to '2' four times in series. There is a difference between these two images (the saturation at 2 four times and at 4000) but the distorted parts of the image remain fairly consistent, so the algorithm appears to produce very stable results. Next, Windows Vista uses something called the Windows Color System, which uses CIECAM02 LMS space, ratified in 2008. I don't see any tools that work in this space for comparison with HSY, but it seems to be clear that there are a lot of different models of how colors can be displayed and manipulated. [ http://en.wikipedia.org/wiki/CIECAM02 ] My observations, now, are that the layer blend modes chose a color space based on some semi-abritrary criteria, and that this information isn't immediately obvious to the end user. Secondly, tools such as Hue-Saturation are fixed to the HLS color model. My thoughts are that this is too limiting, and I'd like to know what you think about the following: #1: Add additional color spaces to the color manipulation tools (HSV/HSL/HSY/RGB/Lab/LMS/CMYK/etc/etc), where appropriate. #2: Allow a tool configuration layer to appear as a node in a GEGL graph. #3: Remove the concept of explicit layer blend modes. So what we end up with is something like the following: - Image01 - + Layer Group 1 - - Layer Group 2 - - - Top Image - - : Saturation Tool in HSY-space @40% - - - Bottom Image - + Layer Group 3 ... etc. This is probably a very poor example and I'm sure I'm abusing some terminology, but I hope you get the gist of what I'm saying. "Layer Group 2" is an image-tool-image sandwich, which in current GIMP would be two images with a layer blend mode of "Saturation". But this way, instead of a fixed mode, we have something far more configurable. Unlike a layer mode it's not a fixed thing, so it should also be relatively future-proof as new modes or color spaces simply become new options for this tool layer. I expect some people will want to know what this "tool layer" looks like, and I'm thinking it would be something like a simple gray mask, but I'm more interested what people think about the concept at this time. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] small Wishlist regarding Guides
Hello > - non-rectangle-bound guides: > Guides that can be enabled to have any angle, which means that they do > not have to be restricted to be 0 degrees or 90 degrees (being parallel > to the window). > > This feature can be helpful, e.g. when correcting pictures, or for > drawing parallels > that do not fit the 0/90/180/270/360 degree orientation. > > It would be good, to enable/disable this behaviour via toggle box, so > that normal behaviour > will be available and guides can be restricted to classical > window-parallel behaviour. I think we have seen this request already several times and I definitely agree it could be useful. Your request made me take a look at the code (app/display/gimpdisplayshell-draw.c, app/core/gimpimage-guides.c, /app/core/gimpguide.c) and it actually seems possible. I'll add it to my to-try list for when I have some more time. > - boundary guides, instead of middle.guides: > Guides, where the outer boundary of a drawing tool snaps to the guide > (instead the middle of the > drawing tool snapping to the guide). > > This would be helpful for drawing in general, and correcting pictures: the > color will > not pass this line of the guide, which means, you can be sure no color > enters a certain region. This does not seem trivial to code - in fact with how I remember the paint core works, this is going to be one very hard hack... Also, I think that if the purpose is just to stay inside of the lines you can use a selection (create it using the guides and freeform selection) and stroke it on a new layer with a mask which is exactly the selection - I do this all the time. Stroking a selection is usually faster than me painting it by hand, and it's probably more accurate. > - Adding Multiple Guides > (there is a Script for this on www.meetthegimp.org, but native would be > nice) > > This feature is good for some repetitive tasks, where a lot of Guides will > be needed, > something like a guide-grid. Can you give a direct link to the script? I definitely agree this sounds useful - it's worth checking if we can simply include this script with GIMP (or at least if you give us a link to it, we'll be able to write something similar with extra features if needed). ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] html layers
bob wrote: > But I find it an interesting idea that, if it possible to implement in an > image editor, could help smooth the process of designing web application > front-ends. > > Anyway, I'm just putting it out there to you guys to see what you think. It might be possible to provide some form of HTML editing in GIMP via a plug-in (especially once GEGL is more fully a part of GIMP) but I don't see it as something that should be added as an integral part of GIMP. Creating a decent GUI based HTML editor is a non-trivial task. I have yet to see an HTML editor I like better than vi. I have seen HTML editors that will let you link to an external editor when you need to edit an image that will be appearing in a page. If you really want to edit HTML in a program, use a program designed primarily for that purpose and use its hooks to invoke GIMP when you need it rather than trying to make an image editing program capable of doing page layout. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] small Wishlist regarding Guides
Hello, I have a small wishlist regarding Guides. - non-rectangle-bound guides: Guides that can be enabled to have any angle, which means that they do not have to be restricted to be 0 degrees or 90 degrees (being parallel to the window). This feature can be helpful, e.g. when correcting pictures, or for drawing parallels that do not fit the 0/90/180/270/360 degree orientation. It would be good, to enable/disable this behaviour via toggle box, so that normal behaviour will be available and guides can be restricted to classical window-parallel behaviour. - boundary guides, instead of middle.guides: Guides, where the outer boundary of a drawing tool snaps to the guide (instead the middle of the drawing tool snapping to the guide). This would be helpful for drawing in general, and correcting pictures: the color will not pass this line of the guide, which means, you can be sure no color enters a certain region. - Adding Multiple Guides (there is a Script for this on www.meetthegimp.org, but native would be nice) This feature is good for some repetitive tasks, where a lot of Guides will be needed, something like a guide-grid. Ciao, Oliver ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Help with new default resources in 2.8
On Sunday, August 01, 2010 11:45:19 Matjaz L. wrote: > I contacted David Revoy and got a reply. He explained he doesn't feel GIMP > 2.7 is stable enough for regular production work, which would allow him to > develop a good default brush set through actual work. ...snip > It's a sort of a chicken&egg who-came-first problem. > Stable GIMP -> develop stable brush set -> release stable GIMP. I agree with him. Exact dynamics/brush set development is best left after we have the first RC out of the door. But baseline setting can start now. Adding basic simple things that are likely to be keepers and removing stuff we arent going to keep for sure. --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Help with new default resources in 2.8
Hello, I contacted David Revoy and got a reply. He explained he doesn't feel GIMP 2.7 is stable enough for regular production work, which would allow him to develop a good default brush set through actual work. He also said his current brush set made for Chaos&Evolutions DVD probably won't fit directly in GIMP 2.8 due to all the advancements made to the brush engine between 2.6 and 2.8. It's a sort of a chicken&egg who-came-first problem. Stable GIMP -> develop stable brush set -> release stable GIMP. However, he did make a proposal how he imagines a default robust brush set (and by the look of it, it appears very similar to the one made for Chaos&Evolutions). Here's his proposal: http://www.pasteall.org/pic/show.php?id=4866 In addition, I'm giving you a link to his portfolio so you can see what kind of artistic background he's coming from and evaluate how his use-case vs. proposed brush set vs. GIMP product vision relate to one another. http://www.davidrevoy.com/ Regards, Lamoot -- Matjaz L. (via www.gimpusers.com) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] html layers
On 08/01/2010 09:25 AM, Joseph Areeda wrote: > In my mind an hmtl layer would serve the same function as a text layer, > except that it would provide formatted text. It would be nice if could > be stored and edited as html then rendered on the fly. Hi, If you want more powerful formating of text layers, the solution is to improve text layers, not add HTML layers. Have you tried GIMP from git? It has been made possible to do per-character formating in text layers there. Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ "Automatic tab style and removed tab title bar" ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] html layers
I'm just starting to learn what it takes to be a GIMP developer so this is more from a user's perspective. In my mind an hmtl layer would serve the same function as a text layer, except that it would provide formatted text. It would be nice if could be stored and edited as html then rendered on the fly. I don't see GIMP becoming an html editor and I don't see a use for much of html such as links and forms but a rich text environment that could do tables, multiple fonts, multiple colors as a separate layer that could be edited in the original format would be pretty cool. HTML is a decent markup language and the undefined rendering attribute could be ignored. In our case all rendering attributes would be defined by our implementation. The end result for me would still be exported single layer images. Joe ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] html layers
Hello, On Sat, Jul 31, 2010 at 2:29 PM, Alexandre Prokoudine wrote: > On 7/31/10, LightningIsMyName wrote: > >> I don't see GIMP becoming an HTML editor - not only because there is >> no one with time to develop this (building an html editor is lots of >> work), but also because this isn't GIMP's product vision. > > Really? So GIMP is suddenly not the tool for web developers? :) > >> GIMP is meant to be a high-end image manipulation/creating program, >> and not an application for designing web interfaces (and coding them). > > Who said that? I don't say that I agree with that, but that is from the UI redesign wiki: http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision If we follow what's listed there then GIMP isn't a tool for generating/editing html code with graphics and stuff. As peter said: On Sat, Jul 31, 2010 at 2:38 PM, peter sikking wrote: > > I thought immediately of what the GIMP team said during > the discussion of the product vision. > > I brought up 'what about making mock-ups of web pages?' after a > serious look at what it means to support that (like pro-grade html > generation, support for fluid layouts), the team clearly felt that > this is not what they wanted GIMP to be. > > so there is an explicit 'no' for GIMP as a web design tool. > > there is an explicit 'yes' for GIMP as a production tool for > all graphics that are used on a website. This does mean that > there needs to be better support for this, like automated > cutting and exporting of all the parts from a working canvas, > much more than the hack-ish slicing we have right now. I don't agree with some of the product vision points as stated in the UI redesign wiki and by some developers (for example that GIMP is meant mainly for high end users and less for "simple" users - as we discussed on IRC yesterday), but I do agree on this point. GIMP is an image editining/authoring tool and not a web tool for coding and designing websites. >> I don't want overcomplicated interfaces just to get more features > > What makes you think this would be overcomplicated? Expirience taught me that lots of features *usually* mean more complicated interfaces. Let's hope that I'm wrong and we can keep the interface simple if/when we add this =) ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
