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
e 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 obviousl
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 ta
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:
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
t 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
#x27;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
ngs 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
__
e 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
uld 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/mailm
any 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
__
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
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
___
G
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
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
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.
--
solutions) 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
0x1080 (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@li
y 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
, 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
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/mail
ternally 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?
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
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
__
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
c, 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
ated 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
__
ly 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
ance, 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
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
downl
provement 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
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
_
ssion it would lead to performance issues.
--
SHIRAKAWA Akira
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
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
ial programs.
An official single windowed GIMP would draw much attention from both end
users and potentially contributing developers and would definitely be
beneficial to the whole project in the medium to long run.
--
SHIRAKAWA Akira
___
Gimp-d
ing 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
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
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
sly 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
s 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
_
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 m
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
is 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
___
nd 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
enses) 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
le 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
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
47 matches
Mail list logo
