Re: [Gimp-developer] Color management (UI perspective for GIMP 2.8)
On 2010-02-09 19:52, Martin Nordholts wrote: GIMP is nearly flawless in its color handling, but there is one problem. It forgets to convert copy and pasted image content. Also don't forget that the various color picker/selectors aren't color managed at the moment, so selected colors (FG/BG colors) will look differently when painted on a color managed image. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hybrid window mode
On 2010-02-08 00:40, Damien de Lemeny-Makedone wrote: I'm so sad this proposal did not trigger any further discussion. I really think that concurrent modes design is a mistake. It does not [cut] I think one of the reasons for this is that your emails are treated as spam by Google Gmail. I don't know why... -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.8 schedule, donations and krita
On 2010-01-15 18:02, Alexia Death wrote: Well, I didn't know it was an option, and my interest in such device is not limited to just developing gimp, so I've been plotting to get one on my own... But it would help a lot if me and someone else, like Martin or Mitch had the same set, for testing etc purposes. If you want pen rotation for for developing but you also need a tablet for your personal artistic needs, the best choice would be getting a Wacom Intuos4 Medium tablet + Art Pen (undiscounted price: about 370 + 100 euro), although if you're really into drawing and painting then you should get an Intuos4 Large which costs 480 euro (+ 100 euro Art Pen). These are prices from the official Wacom.eu shop; online retails prices are usually about 10% lower. If you're really on a budget (or better, if Gimp funds don't allow for such expenses) then you should get an Intuos4 Small (Wacom price: 225 euro), although I personally don't recommend it for drawing or painting as it's way too small. For testing/developing tablet support on Gimp would be more than enough anyway. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PATCH] Use Glade + GtkBuilder for file-png.c save_dialog()
On 2010-01-07 16:45, Martin Nordholts wrote: [...] The patch I am replying to ports the PNG save dialog to Glade and uses GtkBuilder to construct the UI. The purpose of this change is to introduce declarative construction of UIs in GIMP to give us experience in this area. The benefits of using Glade is: * Tweaking the UI doesn't requires re-bulding the app * Less code * Easier to start using a script language like JavaScript in the core * We make the GIMP code base more modern * UIs can be constructed through drag-and-drop with Glade [...] I'm not expert enough to decide whether using GtkBuilder to construct the UI is a good thing or not, but less code, more flexibility and no need to rebuild the app for interface customization all seem a good thing to me. Are there any disadvantages? Performance issues at start up and during actual program usage? Ideally, would this be limited to dialog windows or, instead, the entire user interface? -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ceci n'est pas une selection...
Sven Neumann wrote: I wonder why you need both hands on the tablet. The pros that I have seen working with GIMP always had one hand on the keyboard and the other hand holding the tablet pen. I don't want to offend you in any way, I just would like to understand why using the tablet and the keyboard at the same time is not an option for you. This workflow may be ok with certain types of uses/users (for example photo retouching with a small tablet), but personally when I'm drawing (main thing I use the tablet for with GIMP) I want, as when I draw on paper, to keep the tablet aligned to my main monitor and keep a proper body/arm position. As I'm right-handed, the only places for the keyboard to be would be in my case between the monitor and the tablet (where I actually keep it) or to the left of the tablet. So the ESC key would be in either cases too far away and require tiring and unnecessary stretching of my left arm. Most tablets have usually a few (4-8 or more depending on the model, some may have less) shortcut keys and a touch ring/strip. So the left hand (or right hand for LH users) is usually not just lying on the tablet doing nothing but has access to a limited set of quickly and comfortably reachable keys. It's true that one of them could be mapped to the select none option, but depending on the user and/or tablet, this shortcut might have to be sacrificed for other, more used, ones. All this without even talking of tablet PCs, tablet monitors, or users who use their tablet on their lap like if they were drawing on a sketchbook. In these cases keyboard access can be rather inconvenient and thus limited to the minimum possible. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ceci n'est pas une selection...
peter sikking wrote: say I have made a selection in GIMP, done what needed to be done to the pixels in the selection and now want to get rid of the selection. the obvious way is Select-None. how many more ways are there? I usually click with a selection tool on any area outside the active selection. But this isn't always fast to do. For example another tool may be currently selected, or the selection method may be set to addition, subtraction or intersection. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ceci n'est pas une selection...
peter sikking wrote: [cut] brainstorm - like a close box [x] on the top-right of the marching ants - or (another shortcut actually) press esc (may be taken in some states) /brainstorm I like the close box more (the esc button on my keyboard is too far away from my tablet, and I think this is the case for most tablet users, especially if large ones are used), but what if the selection is bigger than the drawing area or if is it in another part of the image than the one currently viewed? Then one would have to zoom out/pan again to click the box, in other words will have to search it. What about showing a small remove selection button near the Toggle Quick Mask button? That would be in my opinion a very logical place for the proposed close box [x] to be, would take out very little space and be always visible. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Icons for layer modes
peter sikking wrote: so I am sorry. no additions solely for digital-artists. Many people (and really I mean many) use Photoshop or GIMP, the closest open source equivalent program, for paint-for-scratch work even though they're really not suited for this job. This is because almost all specialized programs (included the famous Corel Painter) fail in so many aspects of raster image processing/editing that their advantages in artistic use are quickly overshadowed by them. GIMP may be headed to other directions, but I believe there is a strong demand for such features which cannot be ignored, as demonstrated for example by this mixing brush source code patch I linked in my previous post or Ramon Miranda's Gimp Paint Studio resource collection. Perhaps a more advanced brush engine in the future can overcome the current limitations without expressly introducing digital-artist-only features? Not really a question, just a hope. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Icons for layer modes
Martin Renold wrote: [cut] But those brush modes would copy the composited image into the current layer and brighten it there. The result would look on the screen as if you had flattened the image first. If I understood you correctly, this is exactly what you proposed in your footnote? Yes, I meant exactly this! Of course it would be an optional setting. David was somewhat enthusiastic about this, but I'm still wondering whether this would not result in some major annoyances, compared to layer modes? I still think layer modes (or layer operations) have their place, especially if they involve pre-made resources (for example the Overlay layer mode I wrote about in my previous post in my case is used mainly to apply subtle textures to areas painted on lower layers, for example paper/canvas texture). When you make invisible a layer below the one you used to brighten the image, you would see the (faint) image structure from the hidden layer because some of it was copied while brightening. Would this be no big issue? Now that I think about it, you're right, this could be a problem depending on the situation. Would it be important to also be able to manipulate (eg. brighten) the current layer only, in the way that brush modes work right now in GIMP? I think it would be important/useful to be able to affect only a limited set of layers. I think that layer groups/trees, which will be implemented in the 2.8 version of GIMP will add this capability (if a priority system based on layer position within the tree will be implemented. By the way, this is where GEGL is heading, from what I know). I understand if you're more interested in GIMP than in MyPaint, but I am still interested whether this would be compatible with your workflow... It appears it would be. Some issues would have to be sorted out though. By the way, this side-discussion started because on Photoshop CS4 I can use different painting modes even on totally transparent areas (if there is nothing in the background, then the brush behaves as if the painting mode is Normal), while GIMP does not. And, have you already used a software that offers such a feature? I can't try it again right now, because the trial period has expired and for some reasons it doesn't work anymore (it should, but without the file save features), but if I remember well Paint Tool SAI is a very good software for illustration/painting/drawing which handles layers and layer modes better than other programs: http://www.systemax.jp/en/sai/ I think layer modes here work on a hierarchy tree structure. Try it if you can. bye, Martin [1] http://www.davidrevoy.com/temp/mypaint-request/ [2] http://forum.intilinux.com/mypaint-development-and-suggestions/layer-blending-mode/ Thanks, SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Peter's single-window proposal (Was: We should go for a single-window mode in 2.8)
SHIRAKAWA Akira wrote: peter sikking wrote: so for everybody who feels this: _why_ do you need windows-in-window or work-side-by-side? Personally, for me who I'm into drawing and digital painting (rather than photo retouching) I can think of these reasons: [cut] If I may, I'd also like to add that I find absolutely necessary to maximize vertical space / resolution. It has become very precious resource lately as monitors are starting to adopt very squashed aspect ratios (16:10 was the normality until a few years ago, but recently 16:9 screens have been introduced with virtually no increase of vertical resolution despite the noticeable increase of horizontal one). This means that personally I wouldn't put a 'polaroids' feature on top of the screen or adopt a blender-style interface as suggested in another thread (or at least the standard one, I haven't used that program much but I remember that the default 3d viewport is very wide with all tools and commands on the bottom). Maximizing vertical space is especially important for digital tablets users, since most modern tablets are now in wide (16:10) format. A reduced vertical space forces the user to physically draw small on the tablet (implying very reduced hand movements), which for most artists is a bad thing. (that is, unless both the monitor and the tablet are set up to operate in portrait mode, but it's not a very practical thing to do, and most LCD monitors are not designed to work this way) -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Icons for layer modes
Martin Nordholts wrote: [cut] Or are people too used to the concept of layer modes that it would be suicide to make them less prominent? First of all, my field is digital painting/drawing [1], not photography retouching, so we may have different views on this. I rarely use layer modes except for the Overlay one which I use quite often [2], but I've seen many people using them extensively, mostly for artistic work, in order to create effects and tricks of all sorts. I personally have never thought of layer modes as way to obtain primitive non-destructiveness, but as one to obtain some effects that would be otherwise long/tricky/impossible to do or to have more control on them compared to filters/plug-ins. Will GEGL be able to do the same (or even more advanced ones) layer operations as layer modes currently allow? If yes, then I have no problem in removing the layer mode concept, as probably won't the majority of people who uses them now. If not/maybe not, then I think they will definitely need to remain. *** [1] By the way, many people would find nice to see more digital-artist oriented features such as a mixing brush for example, of which there's a third party GIMP source code patch here: http://sourceforge.jp/projects/gimp-painter/releases/ [2] I use paint modes more, especially Multiply, as it's so useful. Off-topic note: paint modes would be much more useful if there was a sample merged option for painting tools too, so that they will pick up colors from lower layers. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Peter's single-window proposal (Was: We should go for a single-window mode in 2.8)
peter sikking wrote: so for everybody who feels this: _why_ do you need windows-in-window or work-side-by-side? Personally, for me who I'm into drawing and digital painting (rather than photo retouching) I can think of these reasons: - For multiple views of the same image at different zooms at the same time. It's useful to have a zoomed window for detail work and then a more extended view in order check often how the whole drawing / painting looks. - To have one or more images as reference to copy / get inspired by. - To tests brushes, mix colors or trying anything else without affecting the original image. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PATCH] Improve brush outline for fuzzy brushes, sample screenshot included
yahvuu wrote: hi, what about using a dashed outline for fuzzy brushes? perhaps like a) in http://yahvuu.files.wordpress.com/2009/08/fuzzy-outline.png This is a very good idea, but I think it would be more logic and consistent with the style of brush outlines in GIMP if it was the opposite: solid external outline (representing the brush area limits), and dashed internal outline. One of the reasons for this is that hardness (which creates the fuzzyness) is a brush attribute which can dynamically change with brush dynamics (in static conditions hardness could be 100% hard, but become completely fuzzy as drawing pressure increases for example), and would better work with my proposal of varying in realtime brush outlines according to them. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The inside of the active image window doesn't seem to be part of gimp-2.6.exe
SHIRAKAWA Akira wrote: [...] It appears that when I hover the pen cursor inside the active image window (where you draw, etc), tablet drivers don't recognize the area to be part of GIMP anymore. By the way, it appears that the 2.7 development Windows Build (which I downloaded from the GIMP-Windows project page) solved this problem. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The inside of the active image window doesn't seem to be part of gimp-2.6.exe
Sven Neumann wrote: Interesting. I don't think we changed anything related in our code. I've checked again and the 2.6.7 version behaves correctly as well, now. I haven't made any changes to my system or tablet drivers since I first reported this problem. I think this improvement could be probably due to some changes to the GTK+ libraries, which are included with GIMP Windows installers. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tags on presets.
Martin Nordholts wrote: If we define a tip shape to be a dump bitmap/vector graphics, then it can be problematic (in terms of software maintainability and cleanness in design) to also read dynamics data from tip shape data files. Everything depends on how we define the concepts. I think this is the main problem. In my opinion the brush should either: - Be *only* the tip shape and nothing else (leaving dynamics, brush settings, etc, to tool options, and therefore, tool presets). - Include most, if not all, tool and brush options/settings, define the tip shape, its behavior, etc, like I proposed a few weeks ago. Brush presets would work as tool presets. Right now we have an unintuitive hybrid: some settings are defined by tool settings, some by brush settings. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PATCH] Suggestion on how to deal with obsolete data resources
Martin Nordholts wrote: [cut] then run GIMP and look at the brushes in the UI. Only the largest Circle* brushes are available. But you can still execute File - Create - Logos - Frosty.. which uses Circle Fuzzy (11). Any comments on the proposed way to deal with obsolete resources? Unfortunately since I'm using Windows there's not easy way for me to try this patch, but in my opinion from what you describe this seems a fair way to handle this problem. I assume this is only a temporary workaround that will be eventually eliminated in future major versions of GIMP, right? Because at some point probably most of the current resources or those which will come out in next version will become obsolete, I think (when/if there will be major changes to the whole brush system, for example). -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Layers and possible space for performance improvement in GIMP
Hello, A few days ago I was trying out Adobe Photoshop CS4 under my OS, Windows 7 RC 64 bit, and although I prefer using GIMP even though it lacks some very useful features, I was surprised at one thing in particular: its speed when many layers are used (20-25+, and on very complex works I often use even more). On Photoshop CS4 layers refresh almost instantly, new ones are created with about the same speed, and there are generally no graphic slowdowns on complex works. At some point I tried to save my work done under Photoshop and import it in GIMP. I discovered that all layers were cropped to their maximum extents (empty borders taken out). I thought that this could be one of the main reasons why Photoshop is faster when many layers are used: since unused borders are taken out, there's less to redraw to the screen each time or to check out for transparency. I'm not sure though if this is done by GIMP during the import process or in a transparent way (when a new layer is created it's assumed that it will cover the whole canvas) automatically in Photoshop, though. To verify my claim I tried to make a similarly complex, multilayered work natively under GIMP 2.6.6 (canvas size A4, 300 dpi, about 3500x2500 pixels) until at some point I reached about 25 different layers. Of course the program was still usable, but some slowdown was evident especially when toggling layer visibility (operation which took a while to complete). I then applied my so-called Photoshop optimization by autocropping all layers (Menu LayerAutocrop), and working speed went up noticeably, though not dramatically (note that I'm using an Intel Core 2 Duo 3.16 Ghz E8500 processor with 4 GB RAM). What I wonder is if GIMP could someday get advantage dynamically, automatically and in a transparent manner to the user of autocropping extra borders from layers (without manual intervention) in order improve performance when large canvases and many layers (the normality in creative works, not so much when only retouching photos) are used. For example, the user would create a 3500x2500 pixels new layer, but if he drew only in a small 100x200 pixels area, then the program would internally save and process only that area, while still allowing the user to draw outside of it (the layer extents would be automatically and transparently increased). What do you think about this proposition? -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Layers and possible space for performance improvement in GIMP
Michael Schumacher wrote: There's a long discussion about this in http://bugzilla.gnome.org/show_bug.cgi?id=93639 I'm not sure how much of this will change within a GEGL tree, so parts of this discussion could already be obsolete. Ah, thanks for linking that discussion. So this was already being discussed many years ago. My opinion is that when layer groups will be implemented (from what I understand, they will be soon as it's a very requested feature), layer usage will be going up since it will be easier to manage them, and a better, more efficient way to internally manage layer boundaries will be needed in order to keep good performance. I understand that layer boundaries are needed for many uses. I think too that they shouldn't go away completely, but they could be still retained if some sort of transparent effective layer boundary auto-growing feature is ever implemented into GIMP. Layer boundaries could simply be the internal auto-growing limits of the layer. Also, the whole auto-growing process wouldn't affect export functions or scripts which rely on boundaries, only on-screen drawing performance, as long as unused borders are transparent. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bug #164774
Martin Nordholts wrote: There hasn't been any further discussion, but we should have one. The first step would be to figure out a UI for the feature that helps fulfill the product vision [1]. As left clicking and dragging with the mouse creates new freely movable guides (left click-drag the upper ruler for horizontal guides, left click-drag the left ruler for vertical guides), I suggest that clicking and dragging the rulers (left-right for the upper one, up-down for the vertical one) with another mouse button (for example middle or right) could move their respective origin (zero point). Then, another option in the Image menu and below Configure Guides..., called Configure Rulers..., could be added for more precise ruler option settings (I was thinking not only the origin, but also font, style, number of notches, etc, if it's possible). But this is just my 2-minutes brainstorm. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] CIE-LCH Color selector?
Hello, The last discussion about using CIE LCH for some layer modes made me remember that there is a CIE LCH color selector plugin for GIMP that many people would like to see included in the main GIMP distribution sooner or later. It has room for improvements (for example when colors out of gamut are selected it can lead to some strange color selection results), but it should be a good start to begin from. Of course there is the source code available, and it's public domain too, according to the author. I've attached the tar.gz file to this email. -- SHIRAKAWA Akira gimp-lch-selector-0.3.tar.gz Description: application/gzip ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CIE-LCH Color selector?
Martin Nordholts wrote: Before we add support for picking device-independent colors, the whole color selector should be color managed, and it currently isn't. I'm all for adding a Lab/LCH color picker when that is fixed though. Ah, I see, thanks anyway for checking it out. By the way, as I wrote in another message I'm not a GIMP hacker, but by not color managed did you refer to this specific implementation of a LCH color picker or rather the whole GIMP color picking system? -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CIE-LCH Color selector?
Martin Nordholts wrote: I'm referring to the whole GIMP color picking system. The color picked using the default color picker is not represented in a device-independent way. One of the consequences is that painting with a green brush on a color managed image might not give a green stroke on the image. The absence of a color managed color picker becomes evident in test images which rotates color, i.e. maps e.g. RGB 0,255,0 in the image to RGB 0,0,255 on the screen. I understand, thanks for explaining. Can you give a rough estimate of when a color managed picking system will be integrated into GIMP ? I've only recently discovered the LCH color space / color selection and I think it's a great system. I know I could for now simply use the current available color selection module (which from what I see is just a graphic interface to do LCH-RGB24 color conversions, so it's a sort of fake LCH), but it's just my curiosity. Let me guess: this will happen when GEGL will be fully integrated into GIMP, right (also allowing higher color bit depths which if I'm not wrong the LCH color space needs) ? Then that would be in GIMP 2.10 or even later, I think. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Does Hue, Saturation, Value layer modes need HSV? How about CIE LCH instead?
Martin Nordholts wrote: Does anyone see any problems with using CIE LCH instead of HSV for these layer modes? We can ignore backwards compatibility issues for now. I very rarely use layer modes (and I'm not a GIMP hacker so I'm probably missing something), but if using internally CIE LCH for image processing instead of HSV leads to more correct results, then I wouldn't see any reason to not use it. Except for the final results, will there be any change at a user interaction level? Or any practical drawback resulting from this? -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] The inside of the active image window doesn't seem to be part of gimp-2.6.exe
Hello, I don't know if this is a bug, but it doesn't seem a normal behavior so I'm reporting it. Let's start from the beginning: I'm a Wacom Intuos4 pen tablet user who uses GIMP 2.6 under Windows 7 RC. Intuos tablet drivers enable different pen and tablet settings depending on the active program. So I have set up my personal keys and shortcuts configuration for gimp-2.6.exe ... but the problem starts here. It appears that when I hover the pen cursor inside the active image window (where you draw, etc), tablet drivers don't recognize the area to be part of GIMP anymore. How I discovered this: I've set up the main side button of the pen to execute CTRL-Z (undo). This combination works as long as the cursor is over any toolbar (main toolbar, color toolbar, layers, etc). But when it's inside the active image window, pen settings revert to default ones (side switch = right click). Oddly enough, if I hover the pen to the title bar of the active image window (where there are the filename, attributes and window control icons), the custom GIMP-2.6.exe controls I've set up start to work again. Is this a GIMP/GTK bug? If not, how can I solve it? Can other Intuos tablet user verify is the same happens on their Windows pc? Thanks in advance. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The inside of the active image window doesn't seem to be part of gimp-2.6.exe
Emil Assarsson wrote: I can not confirm it under XP. Hmm... Probably Vista users may be able to replicate this issue. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Improved brush editing interface mock-up
Martin Nordholts wrote: I would just like to point out that the smallest screen size supported by GIMP is 1280x1024, so we don't need to make 1024x768 work or look good. Yes, I've read that many times and I would agree with it too since anything lower than that resolution is rather old gear. I was experimenting (but what about 1440x900 screens though? This seems to be a common size for smaller monitors and some notebooks. The vertical resolution is the problem here). I personally think that an interface which works well with lower resolutions while still maintaining good functionality and usable space is a good interface, by the way. It's useful for everybody to maximize screen space (*)! (*) Possibly by avoiding wasting vertical space. Vertical resolution, except for high end or otherwise specialized monitors, seems to have stabilized to around 1050 pixels. Nowadays getting a bigger monitor with a higher resolution doesn't necessarily mean that there will be much more useful (and precious) vertical space. Common resolutions for most consumer-grade LCD monitors are typically: 1280x1024 (5:4) 1440x1050 (4:3) 1680x1050 (16:10) 1980x1080 (16:9) The current trend is that the following resolutions and higher ones will tend to be available only on high-end, professional grade monitors: 1600x1200 (4:3) 1980x1200 (16:10) -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Improved brush editing interface mock-up
Alexia Death wrote: Id have to agree with this one. I namely own a laptop with this resolution. I havent had any problems using gimp on it tho and I hope it stays that way. Yes, by keeping two dockable areas (left and right side of the screen) as by default, a 1440x900 resolution enables to normally work with GIMP without any particular problem. Finding myself desiring to use as much space as possible with my pen tablet and my screen, though, I've set up GIMP this way on my pc (only one dockable area, on the left), and lower vertical resolutions wouldn't work very well with this layout without losing a useful dockable window: http://img401.imageshack.us/img401/6244/mygimplayout.png (note: this is a custom version of GIMP with two more tools, a blending brush, a pen tool with a stroke smoothing feature and other small things) This layout is similar in many ways to what I proposed in this thread. -- SHIRAKAWA akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Improved brush editing interface mock-up
SHIRAKAWA Akira wrote: Yes, my proposition is to unify all of those. And this is a mock-up of my idea of how the toolbar would end up looking like by merging many tools into one: http://i25.tinypic.com/2ihxyd5.png -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Improved brush editing interface mock-up
SHIRAKAWA Akira wrote: Hello, I tried putting together my ideas I wrote about in this thread, in a single image. The result is an Inkscape-like SDI GIMP I know that in the medium term one of the main goal will be an SDI interface, and that would work very well with the improvements I have in mind. New interface and improvements mock-up link: http://i31.tinypic.com/2qjd55k.png Work in progress (the images needs annotations), of course, and open to changes and suggestions. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Improved brush editing interface mock-up
Nelson A. de Oliveira wrote: This is something that I, as an user, would like to have. It also seems to save some screen space when editing on a notebook that can do only 1024x768 too :-) This is the annotated version I sent to the GIMP UI brainstorm blog. It doesn't add much more than what has been already wrote in this thread though: http://img268.imageshack.us/img268/8928/sdigimp.png -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FW: Improved brush editing interface mock-up
Luis Diego Alpizar Alpizar wrote: I agree with this idea, but this would be implemented as a optional interface? We will be able to use both(Dockables or Non-dockables)? When i use Inkscape, i work very fast as their UI is very well done, with the colours palette down. But other users might find usefull the dockables As for the dockable windows, with this UI they will still be there, but they would be only dockable to the right side of the screen, as the current left toolbar would become a simple, standard toolbar. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Improved brush editing interface mock-up
Nelson A. de Oliveira wrote: This is something that I, as an user, would like to have. It also seems to save some screen space when editing on a notebook that can do only 1024x768 too :-) This is a smaller version I made which shows that at 1024x768 (and possibly at even lower resolutions) there's still much usable screen space: http://i29.tinypic.com/se3hg5.png -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Improved brush editing interface mock-up
David Gowers wrote: What do you mean here? I think we need at least these paint tools: Paint (this would be able to do all of what Pencil, Paintbrush, and Airbrush do currently, and perhaps also Eraser), Ink (this does not use 'brushes'), Clone (also Heal?) , Perspective Clone , Blur/Sharpen, Dodge/Burn, Smudge. Do you really have a proposition to unify all of those, or do I misunderstand you? Yes, my proposition is to unify all of those. The idea is that 'brushes' would become something different than what it is now, more related to the physical proprieties of the tool used (= brush preset) than their meaning in the computer graphics world. Brushes in the 'brush' setting window would be of different, selectable types, like for example: - Brushless - Behavior as with the current ink tool - Parametric - Vector brushes with adjustable settings affecting their shape, possibly of many different types (and not only circular) - From clipboard - Bitmap brush - From file - Load a brush in bitmap/SVG format (future versions) - From path - Vector brush from a user defined path (future versions) Paint, eraser, smudge, clone, blur/sharpen, dodge/burn, clone, would be simply different brush modes selectable in the brush editing window, possibly in addition to others. Some would be mutually exclusive (since their effect would cancel one each other, some would stack. With my idea this way a brush can have different shapes, different physical behaviors, and different modes of operation. Of course, there would be plenty of built-in presets (since the amount of different options would be overwhelming for the average user) selectable from the brush preset Window. A few basic settings (size, opacity, spacing/rate and dynamics will remain easily selectable within the standard tool settings window. There are some usability details to be still clarified, but this is my general idea. Anyway, I agree that it would be similar in many ways than how MyPaint works (I swear I have never heard of this great application before!). (By the way, I think maybe it's better to explain this idea a bit a time while discussing with other users instead writing a long slab of text like I initially intended?) -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Improved brush editing interface mock-up
David Gowers wrote: I considered that modes might be how you meant to implement it. That is definitely a large change in the way the user would use paint tools, we should get Peter Sikking's input here for sure. Most users wouldn't normally have to play with those details. There could be a standard set of brush presets grouped under various tags which would contain at least one version of each mode (by default for example a fuzzy and a standard circle variant, freely scalable). Here's a quick and dirty mock-up of what I have in mind: http://i29.tinypic.com/wikarn.png And we must make it visually clear that these are really properties of the brush, to avoid user confusion (A disclosure triangle would deal with this neatly) Yes, you're right. I haven't thought about this yet. Another thing is that we have actions named like tools-value-[12345]-(increase|decrease), etc which currently control some brush parameters (value-1 is opacity, usually). With your proposition, we should consider whether we need more actions so that the user can do more quick changes by keyboard (for example, I'd like to be able to toggle 'Apply Jitter' using a keyboard shortcut. And if 'Fade' (and fade length) were bindable to keyboard actions, they would be far more usable IMO. I think that anything that can be varied with pen tablet dynamics (I proposed that most numerically variable brush parameters would be) needs to have optional keyboard actions too. oh, that reminds me, I gave the wrong URL, the correct URL is: http://mypaint.intilinux.com Yes, I eventually figured it out and downloaded the Windows build. Definitely, it will get developed more, that way :) True! -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Improved brush editing interface mock-up
Hello, I was about to write a rather detailed interface/feature improvement suggestion about the brush editing feature in GIMP but then I thought that first it would be better to show you all this (incomplete) interface mock-up I made: http://i32.tinypic.com/1zwdwts.png Basically, in my vision, the brush editing dockable window would be much more detailed than what is now, containing most settings in common between brush-based tools (and also many new more), which is similar to what happens in other professional bitmap editing programs. Not only this would result in a more powerful brush editing process, but also in a significant reduction of icons in the toolbox. Many of the brush based tools that are there right now would become brush presets, which would work very well with the new tagging feature introduced in the GIT version of GIMP. Obviously backward compatibility with previous brush versions would need to be maintained in some way. If it turns out that brush editing in GIMP is actually going into this direction I'll be happy to describe much more in detail the interface and the behavior of the options and settings I have in mind (unfortunately I'm not an experienced programmer so I cannot explain in detail specific implementation details). -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Improved brush editing interface mock-up
Martin Nordholts wrote: Hi Akira, I suppose you haven't seen http://gui.gimp.org/index.php/Paint_dynamics_specification ? Hi Martin, Yes, I've already seen that! The idea (which I have not yet described in the opening message) is that each Dynamics button (those with the arrow inside) next to almost every numerically variable brush parameter would open of these Paint Dynamics windows in the page you linked. There would not be need to do this for all desired parameters as the Paint dynamics window has already a drop box with all the configurable settings. What I am proposing anyway is not a new brush dynamics system (which is already well thought out from what I see), but a new brush *parameters* system/editing window. In mind, things like hard edge (antialiasing), jitter, fade, etc, would become brush parameters instead of being tool settings like they are now. There would be also more settings; some completely new and some which would be only slight variations or additions to the current system. Would you like me to write more in detail and be more specific regarding this? -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Improved brush editing interface mock-up
Martin Nordholts wrote: Absolutely, I mean why would you hold it back? Because in its entirety my vision is an extensive change not only in brush selecting and editing compared to the current versions, but also in many aspects of the user interface (depending on how much of it would be implemented) and to explain it in detail it would require me some effort (maybe a few days) in both describing it in words (also because English is not my native language) and making graphic examples, which I have not prepared yet. If GIMP UI and brush development was going to another direction anyway, then there wouldn't be the need for such a detailed explanation, I think. Anyway, since I see that you seem interested I think I'll expand this idea. It will require me some time though. For now I can summarize it in a few points: - Make brush based tools as general as possible. Standard: Paint tool, eraser tool, clone/heal tool, tweak tool Advanced: Paint tool, clone/heal tool, tweak tool Extreme: Freehand/Geometric brush tool - Move most brush based tool settings in the brush settings window - Expand the brush settings window with more useful options - Leave the old tool selection concept to the new taggable brush selection window With a new generic brush system in most of the brush behavior is described by the brush settings, it's possible to leave the old tool selection concept to the new (and possibly even more improved) taggable brush presets window. This is similar somewhat in what happens in Corel Painter: there is only one brush tool, and many different brush presets grouped under different tags (Eraser, pencils, watercolor, clone tools, tweaking tools, etc). The most used presets can be dragged in a user specified window. In GIMP they could be docked to the new, lighter tool bar (which would by default have many less tools because many sharing the same functionality/concept would be merged into one). Oh, I ended up being more detailed than I thought! I'd like to expand more this idea though. I hope now it's more clear what I have in mind anyway. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Improved brush editing interface mock-up
Patrick Horgan wrote: Very cool! I'd only add a save button on the bottom right so that this combination of settings could be saved as a named button if desired. Yes, as I wrote, it's still very incomplete and I made this basically to show that the brush editing window could include many of the settings currently in common between various brush-based tools. Of course much more could be added. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
Martin Nordholts wrote: I get your drift, but is it really reasonable to force a user to scale a say 250px brush to 3px if that is what he desires? It might be, but I don't think it is with our current scaling mechanism. What do you think Regarding this, as an user (and not a programmer), I've always wondered why in the case of vector brushes a scaling setting is used instead of fiddling directly (and easily) with their size. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What would be a better set of default resources?
Martin Nordholts wrote: [cut] Does anyone have any suggestions on adjustments and additions to the default set of GIMP resources? I have a few suggestions as a creative/artistic user which uses GIMP mainly with a pen tablet (as probably any other people who is serious into raster graphic art). I'm not sure if they fit the product vision, but I'm trying anyway: - As you say, add larger variants of standard brushes. Artists typically work on rather large canvases (I personally use 300 dpi A4, which equates roughly to 3500x2500 pixels). The standard maximum brush size of 19 pixels at these resolutions can be quite small. - Add some variations of rake brushes (not standard in Gimp right now) and more different types and sizes of bristle brushes. - Add more realistic patterns from commonly used artistic media (for example different types of paper, etc), to simulate easily its texture while drawing. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Implement pen/cursor movement smoothing (.diff patch link included)?
Hello, I think GIMP lacks an extremely useful feature for graphics tablet users. That's stroke/movement smoothing. Graphics tablets can be very slippery and very slow and precise movement control may require a lot of effort. My suggestion is to add an inertia (mass) or smoothing feature in one of the next version of GIMP in order to solve this problem for certain users. A good example of this implementation can be found in Inkscape, where for certain tools there's a mass parameter which the higher it is, the more movement smoothing is applied. A japanese programmer has made a source code modification (patch) which enables this feature on GIMP by apply the moving average of cursor movement. The patch (diff file) for version 2.6.6 can be found here: http://sourceforge.jp/projects/gimp-painter/releases/ The filename is gimp-painter--20090618.diff The page (and its referring one) unfortunately is completely in japanese. The diff file patch actually contains two modifications: G-Pen, which is the patch for movement smoothing, and MixBrush, which enables a more advanced paintbrush blending feature, but it's not the scope of this email to speak about that. I don't know much about programming, but maybe an experienced GIMP coder can take a look at it and tell if it could be possible to implement it soon on future versions of GIMP? I think it would be a great feature to have for tablet users. Thanks for your time, SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Implement pen/cursor movement smoothing (.diff patch link included)?
Martin Nordholts wrote: Such smoothing already exist in GNOME gimp master so before looking at his work, he will need to rebase it against GNOME gimp master. Hello, Unfortunately I'm not in contact with the author. I happened to find the modification on the internet while I was searching for some ways to enable movement smoothing on GIMP like it's possible with other programs. I'm using it on my custom version of GIMP. But anyway, what is GNOME gimp master Is it the version of GIMP currently in development? If it is, good to know! I'm sorry if it's a stupid question, I tried to search it on google, but got no results. As I said, I do not know much about programming and development details. SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] About futures features
On Wed, 15 Apr 2009 12:21:59 +0200, Eduardo Barijan eduwb.horizo...@gmail.com wrote: I was thinking this time about 3 new other features that Gimp could have: 1 - grouping layers by folder. This one should help artists who does their work in a lot of layers, as example, coloring characters. Then you have a folder for body, for example, with just the layers that you used to do lineart and color of body, etc. Yes, I too think it's a good idea that should be implemented! It would be even more useful if it was not only an aestethic/usability addition, but if expanded program functionality by providing group layer masks. These group layers masks would work like normal masks, but with group of layers instead of single layers. That's one of the layer features I need most, as I'm an artist (more like creative user, though) and I use many layers even with simple works, and I often need masks to affect multiple layers at once. 3 - Select layers and then apply Merge layers Instead of do it, for example, 5 times to merge 5 layers, it could be possible to select which layers are affected and then do the command. This too, I'm surprised it's not possible to do at the time, because it's a logical and intuitive way to combine multiple layers together. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] About futures features
On Thu, 16 Apr 2009 12:42:16 +0200, David Gowers 00a...@gmail.com wrote: It is possible to do: 1. Shift-click on the visibility icon for one of the layers, to make it the only visible layer 2. Make the other layers that you want to include visible 3. Merge Visible Layers Aaah! So it was THAT easy :D I didn't see the merge visible layers on the bottom of the menu, and was trying to do the operation the Windows way by trying to ctrl-click multiple layers to select them, which obviously cannot be done on GIMP. -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
