[Gimp-developer] paint dynamics in the git version

2010-04-26 Thread Olivier
A small but annoying point: when I edit a paint dynamics, the new dockable
dialog dor this editing always pops up below the paint dynamics dialog. I
have to move it elsewhere and place it in the foreground. This is the only
dialog with this behaviour, to my knowledge.

-- 
Olivier Lecarme
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] paint dynamics in the git version

2010-04-26 Thread Olivier
In a git version compiled a few hours ago, there remain at least two
anomalies in the Paint Dynamics dialog: Duplicate Dynamics is always
inoperant, and on the contrary it is still possible to edit a predefind
dynamics by using other tabs than the mapping matrix. Moreover, Duplicate
Dynamics, when it will work, should also appear as a button in the bottom of
the Paint Dynamics dialog.

-- 
Olivier Lecarme
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Paint Dynamics in git version

2010-03-11 Thread Rob Antonishen
>> > A useful feature, in the same vein, would be to store resources in
>> > sub-folders of the normal folder, and to give them automatically a tag
>> > depending on the name of the sub-folder. Maybe also this could help the
>> > idea
>> > of lazy loading that you mention: a given sub-folder would be loaded
>> > only if
>> > the corresponding tag is used as a filter.
>>
>> I think tags are more flexible than folders. You can put a thing in
>> only one folder (category) while tagging solution allows to assign any
>> number of tags (categories, keywords) that should make it easier to
>> find an item you're searching for.
>
> I explained my idea poorly, let's try again. Suppose you find somewhere a
> large set of interesting brushes, which you plan to use some times, but not
> always. You install them in a sub-folder of your brushes folder, and choose
> for this sub-folder a meaningful name. Then, maybe depending on some
> explicit action, you would ask to import these brushes, giving to them as a
> first tag their sub-folder name. This would not prevent you to add to them
> other tags later, but it would automatically categorize them, and you could
> look at them in the brushes dialog simply by placing their tag in the filter
> field. By the way, it would also be useful, especially in this case, to have
> a negative filter, i.e. filter the resources that don't have a given tag.
> --
> Olivier Lecarme
>

Olivier -

Take a look at the GURM python plugin http://registry.gimp.org/node/13473

This is what I use currently for managing my patterns, brushes, and
gradients.  The only drawback for me is that it only supports a single
(flat) directory structure.  If it were enhanced to allow selection of
folders and subfolders then it would be extremely useful, rather than
just really useful ;)

I am not sure, however, if such a tool will work well with tagging as
I do not know if once resources are unloaded the tag information is
discarded and lost the next time the resources are loaded...

-Rob A>
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Paint Dynamics in git version

2010-03-11 Thread Olivier
2010/3/10 Aurimas Juška 

> Hi,
>
> 2010/3/9 Olivier :
> > With regards to useful extensions to this feature, it seems to me that
> the
> > most important one is the capability to tag several resources at the same
> > time, for example using combinations of the Ctrl and Shift keys while
> > clicking. In fact, this feature is useful mainly when you have a lot of
> > brushes, for example, and it would be a burden to have to tag several
> > hundreds of them.
> I have just commit such feature into development version. In you
> choose 'View as list' in any data view you can select multiple in
> usual way. Common set of tags for all selected items is displayed in
> assign tags box. If you add/remove tags there, all selected objects
> are updated accordingly. It is possible that in the future this
> feature will be available in other views and more actions might be
> available on multiple items at a time.
>
> Thanks a lot, this adds something very useful, and strongly improves the
usability of the whole thing.


>  > A useful feature, in the same vein, would be to store resources in
> > sub-folders of the normal folder, and to give them automatically a tag
> > depending on the name of the sub-folder. Maybe also this could help the
> idea
> > of lazy loading that you mention: a given sub-folder would be loaded only
> if
> > the corresponding tag is used as a filter.
>
> I think tags are more flexible than folders. You can put a thing in
> only one folder (category) while tagging solution allows to assign any
> number of tags (categories, keywords) that should make it easier to
> find an item you're searching for.
>

I explained my idea poorly, let's try again. Suppose you find somewhere a
large set of interesting brushes, which you plan to use some times, but not
always. You install them in a sub-folder of your brushes folder, and choose
for this sub-folder a meaningful name. Then, maybe depending on some
explicit action, you would ask to import these brushes, giving to them as a
first tag their sub-folder name. This would not prevent you to add to them
other tags later, but it would automatically categorize them, and you could
look at them in the brushes dialog simply by placing their tag in the filter
field. By the way, it would also be useful, especially in this case, to have
a negative filter, i.e. filter the resources that don't have a given tag.
-- 
Olivier Lecarme
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Paint Dynamics in git version

2010-03-10 Thread Rob Antonishen
2010/3/10 Aurimas Juška
> Hi,
>
> 2010/3/10 Rob Antonishen
>> What is the format for this?  If I wanted to distribute (for example)
>> a set of pre-tagged patterns, could this be done currently in the dev
>> build?
>
> There is no such feature yet. The idea is a simple archive of resouces
> + tags + possibly some metadata.  When resource package is dragged on
> GIMP it would install where necessary. Some tool to create such
> packages would be good too. However, first tag file format would have
> to be standardized a bit so that resource packages could be used not
> only in GIMP.
>
> Additional ideas are welcome.
>
> Regards,
> Aurimas
>

Thanks for the response.  So where/how are tags stored now?  In a
separate rc fil somewhere?

-Rob A>
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Paint Dynamics in git version

2010-03-10 Thread Aurimas Juška
Hi,

2010/3/10 Rob Antonishen :
> What is the format for this?  If I wanted to distribute (for example)
> a set of pre-tagged patterns, could this be done currently in the dev
> build?

There is no such feature yet. The idea is a simple archive of resouces
+ tags + possibly some metadata.  When resource package is dragged on
GIMP it would install where necessary. Some tool to create such
packages would be good too. However, first tag file format would have
to be standardized a bit so that resource packages could be used not
only in GIMP.

Additional ideas are welcome.

Regards,
Aurimas
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Paint Dynamics in git version

2010-03-09 Thread Rob Antonishen
2010/3/8 Aurimas Juška :
> Hi,
>
> On Sun, Mar 7, 2010 at 5:50 PM, Alexia Death  wrote:
>>> By the way, is there somewhere some explanations about the purpose and use
>>> of tags and filters? I think I can guess a large part of this, but reading
>>> authorized text would be useful.
>>
>> I doubt there is a text, even less authorized one, on this. Closest you can
>> get is when you find Auris , the author of this feature, in IRC and get him 
>> to
>> talk to you. Shouldn't be that complicated tho. you can assign tags to
>> resources and you can use filters to see just the tagged ones.
>
> You can go to http://sites.google.com/site/aurijusk/gimp-resource-tagging
> and choose tagging.pdf.
>
> Regards,
> Aurimas

Hi-

In that document it states:

Easy resource package import and export
It would be nice to allow users to share their favorite resources
which could be saved into
packages (together with tags assigned to them) and then shared with
other users which could
import them.

What is the format for this?  If I wanted to distribute (for example)
a set of pre-tagged patterns, could this be done currently in the dev
build?

-Rob A>
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Paint Dynamics in git version

2010-03-08 Thread Aurimas Juška
Hi,

On Sun, Mar 7, 2010 at 5:50 PM, Alexia Death  wrote:
>> By the way, is there somewhere some explanations about the purpose and use
>> of tags and filters? I think I can guess a large part of this, but reading
>> authorized text would be useful.
>
> I doubt there is a text, even less authorized one, on this. Closest you can
> get is when you find Auris , the author of this feature, in IRC and get him to
> talk to you. Shouldn't be that complicated tho. you can assign tags to
> resources and you can use filters to see just the tagged ones.

You can go to http://sites.google.com/site/aurijusk/gimp-resource-tagging
and choose tagging.pdf.

Regards,
Aurimas
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Paint Dynamics in git version

2010-03-07 Thread Alexia Death
On Sunday 07 March 2010 17:25:36 Olivier wrote:
> 1. What is the difference between Fade Tapering and Fade Tappering, and the
> same question for Velocity Tapering and Tappering?
One is renamed other. I made a typo. Sorry. Since you didn't do "make 
uninstall" between updates,you ended up with both. 

> 2. When trying to change an existing Paint Dynamics, the Mapping Matrix is
> grayed out, to show that it is read-only. However, the other tabs are not,
> and I can check boxes and change curves. Is this a bug or a feature?
That is a bug. You are not supposed to be able to edit anything for now, but 
hopefully things change before 2.8.
 
> By the way, is there somewhere some explanations about the purpose and use
> of tags and filters? I think I can guess a large part of this, but reading
> authorized text would be useful.

I doubt there is a text, even less authorized one, on this. Closest you can 
get is when you find Auris , the author of this feature, in IRC and get him to 
talk to you. Shouldn't be that complicated tho. you can assign tags to 
resources and you can use filters to see just the tagged ones.

--alexia
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] Paint Dynamics in git version

2010-03-07 Thread Olivier
Two questions about Paint Dynamics, a feature which I find extremely
promising, and about which I would like very much to have more explanations
than the current GUI specifications:

1. What is the difference between Fade Tapering and Fade Tappering, and the
same question for Velocity Tapering and Tappering?

2. When trying to change an existing Paint Dynamics, the Mapping Matrix is
grayed out, to show that it is read-only. However, the other tabs are not,
and I can check boxes and change curves. Is this a bug or a feature?

By the way, is there somewhere some explanations about the purpose and use
of tags and filters? I think I can guess a large part of this, but reading
authorized text would be useful.

-- 
Olivier Lecarme
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] paint dynamics

2010-02-16 Thread David Gowers
On Wed, Feb 17, 2010 at 8:24 AM, LightningIsMyName
 wrote:
> Hello
>
> On Tue, Feb 16, 2010 at 10:45 PM, Alexia Death  wrote:
> 2. The painting of the matrix as showed in the specifications seems
> very hard, and I doubt it worths it. We can easily implement different
> colors for each row, and users will have to settle for a little border
> between the columns.

http://www.pygtk.org/docs/pygtk/class-gtktreeview.html

Looks like it is possible to disable cell borders (and I think it may
be necessary when the cells are small like this-- we want to avoid the
borders visually overwhelming the cell content.

> If we agree to give up the proposed matrix
> painting and choose what I suggested, it can be done with GtkTreeView
> without any special changes, but it will leave the simpler GtkTable
> our of the question (which is fine with me).
> 3. Adding the images with the link's color should be a bit tricky, but
> I assume that it can be done dynamically (by drawing those images
> after acquiring the link's color, instead of embedding ready bitmaps).
> 4. Popup window: Part 1 - the curves widget. This can definetly be
> stolen from the curves tool, no need to work twice. The only needed
> modification is that we can show some other curves at the background,
> and that we add min and max arrows.
> 5. Popup window: Part 2 - switching the tabs. This doesn't seem to
> bad, especially since we already have similar functionality in the
> curves tool.
>
> only two things seem problomatic:
> A treeview widget can't have a bitmap in it's header, And adding the
> bitmaps as the first row is ugly and probably not the right way to do
> this. The guys on the GTK mailing list will probably be able to help
> us out here.
> And another questions is, why do we have the same header images at the
> bottom? Adding a footer to a GtkTreeView isn't possible. Do we really
> need that? Here i'm defintly sure it's not worth the coding amount
> that it will require, and I personally find it confusing.

I believe that this kind of measure is usually taken when the number
of input variables is anticipated to increase (so perhaps you won't be
able to see the top and bottom at the same time)


>
> I haven't seen anything that scary in here, but I doubt that I'll have
> time to touch it in this month. If I implement something like this on
> a dummy GtkWindow (instead of hacking GIMP's source code, which I
> don't excel at) as a stand-alone Gtk application, will it help?
> If so, I'll try to give it a shot.
> If you want to see how to use the TreeView and the CellRenderer, the
> gtk-demo program (which comes with GTK) has a nice example under "Tree
> View/List Store". The code is very simple and in one of the columns
> you'll see the Toggle renderer.
>
>> for example, one dock needs to hold 2.5 distinct views
> I haven't understood that sentence. Can you please explain (or, have I
> referred to it already)?

I think I understood it: one dockable must hold
a) the matrix,
b) the input mapping, and
c) the output mapping

I thought this was a fairly simple problem in GTK terms.

1. Put the matrix inside its own VBox. Pack it at the start of the window.
(This may require nesting inside another VBox.)
2. Put the input and output mapping in another VBox (one they share.)
in the following manner:
  1. Presets (shared between input and output)
  2. Inputs selector
  3. Outputs selector
  4. Curve display (shared?)
  5. 'Inputs' label
  6. 'Outputs' label
  7. Inputs treeview
  8. Outputs treeview
  9. 'Show current  input'
3. When switching modes, we:
  1. If switching to matrix mode, hide the input/output vbox. Show
the matrix vbox. Done.
  2. If switching away from matrix mode, hide the matrix vbox.
  3. If switching to inputs or outputs mode, we need to iterate
over the widgets in the VBox; Hide any widgets not specific to the
mode in question.
 I think there is a widget grouping mechanism in GTK that
allows for this kind of distinction.

That is in fact somewhat ugly.
There is probably another solution involving packing the input/output
widgets on the fly. That would be neater code-wise, and somewhat
slower.

I don't know whether the above would argue with the dockable's idea of
how tall it ought to be. That might be what Alexia was talking about.

> Just one offtopic comment: Some of the icons seem very unintuitive -
> even as an "old" GIMP user I'm still confused by the fifth one from
> the left. What does it stand for?

It looks like it's probably meant to be 'random'. I got that from the
list, not the graphic, though.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] paint dynamics

2010-02-16 Thread LightningIsMyName
Hello

On Tue, Feb 16, 2010 at 10:45 PM, Alexia Death  wrote:
> Curves widget is not a problem. Problem is the general making of Peter's
> spec[1] so that developers who do know gtk, dont faint in disgust at the sight
> of the code. for example, one dock needs to hold 2.5 distinct views. the check
> gird and two very similar variants of curves views switched by the drop down.
> I cant even imagine a solution for this in gtk terms.
>
> [1] http://gui.gimp.org/index.php/Paint_dynamics_specification

Wow! This seems to be an amazing idea, and probably extremly long to
implement...

So let's do some analyzing:
1. We need to implement a check grid. This seems to be pretty simple
using a GtkTable (if we pick the simple way), or if we use a
GtkTreeView (which can actually show a table) with
GtkCellRendererToggle.
2. The painting of the matrix as showed in the specifications seems
very hard, and I doubt it worths it. We can easily implement different
colors for each row, and users will have to settle for a little border
between the columns. If we agree to give up the proposed matrix
painting and choose what I suggested, it can be done with GtkTreeView
without any special changes, but it will leave the simpler GtkTable
our of the question (which is fine with me).
3. Adding the images with the link's color should be a bit tricky, but
I assume that it can be done dynamically (by drawing those images
after acquiring the link's color, instead of embedding ready bitmaps).
4. Popup window: Part 1 - the curves widget. This can definetly be
stolen from the curves tool, no need to work twice. The only needed
modification is that we can show some other curves at the background,
and that we add min and max arrows.
5. Popup window: Part 2 - switching the tabs. This doesn't seem to
bad, especially since we already have similar functionality in the
curves tool.

only two things seem problomatic:
A treeview widget can't have a bitmap in it's header, And adding the
bitmaps as the first row is ugly and probably not the right way to do
this. The guys on the GTK mailing list will probably be able to help
us out here.
And another questions is, why do we have the same header images at the
bottom? Adding a footer to a GtkTreeView isn't possible. Do we really
need that? Here i'm defintly sure it's not worth the coding amount
that it will require, and I personally find it confusing.

I haven't seen anything that scary in here, but I doubt that I'll have
time to touch it in this month. If I implement something like this on
a dummy GtkWindow (instead of hacking GIMP's source code, which I
don't excel at) as a stand-alone Gtk application, will it help?
If so, I'll try to give it a shot.
If you want to see how to use the TreeView and the CellRenderer, the
gtk-demo program (which comes with GTK) has a nice example under "Tree
View/List Store". The code is very simple and in one of the columns
you'll see the Toggle renderer.

> for example, one dock needs to hold 2.5 distinct views
I haven't understood that sentence. Can you please explain (or, have I
referred to it already)?

Just one offtopic comment: Some of the icons seem very unintuitive -
even as an "old" GIMP user I'm still confused by the fifth one from
the left. What does it stand for?

~LightningIsMyName
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] paint dynamics

2010-02-16 Thread Alexia Death
On Tuesday 16 February 2010 22:22:17 LightningIsMyName wrote:
> Can you give some explanations of what is needed? It suprises me that
> there is a problem with a curves widget, when we can "steal" most of
> the code from the existing curves dialog of the curve tool...
> I would like to know some more about this, maybe this is something
> that I can do (I probably won't be able to do it since my GTK
> programming skills aren't so great, but let's give it a try).

Curves widget is not a problem. Problem is the general making of Peter's 
spec[1] so that developers who do know gtk, dont faint in disgust at the sight 
of the code. for example, one dock needs to hold 2.5 distinct views. the check 
gird and two very similar variants of curves views switched by the drop down. 
I cant even imagine a solution for this in gtk terms.

[1] http://gui.gimp.org/index.php/Paint_dynamics_specification

-- Alexia
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] paint dynamics

2010-02-16 Thread LightningIsMyName
Hello,

On Tue, Feb 16, 2010 at 4:40 PM, Alexia Death  wrote:
> Curves don't exist in UI yet, because I personally suck at getting GTK
> to do what I want... If you know somebody with good GTK bending skills
> willing to help out, direct him/her to us. I could really use some
> help...

Can you give some explanations of what is needed? It suprises me that
there is a problem with a curves widget, when we can "steal" most of
the code from the existing curves dialog of the curve tool...
I would like to know some more about this, maybe this is something
that I can do (I probably won't be able to do it since my GTK
programming skills aren't so great, but let's give it a try).

~LightningIsMyName
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


Re: [Gimp-developer] paint dynamics

2010-02-16 Thread Alexia Death
On Tue, Feb 16, 2010 at 4:16 PM, Olivier  wrote:
> I discovered some weeks ago the new Paint Dynamics feature of version 2.7
> and the git one, but I would like to find some explanations about its use.
> One point which bothers me is that I thought there was some way to control
> the shape of the answer curve between some varying parameter (pressure,
> velocity, tilt, etc.) and some brush characteristic (opacity, hardness,
> size, etc.). However, I don't see this anywhere.
>
Curves don't exist in UI yet, because I personally suck at getting GTK
to do what I want... If you know somebody with good GTK bending skills
willing to help out, direct him/her to us. I could really use some
help...


-- 
--Alexia
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


[Gimp-developer] paint dynamics

2010-02-16 Thread Olivier
I discovered some weeks ago the new Paint Dynamics feature of version 2.7
and the git one, but I would like to find some explanations about its use.
One point which bothers me is that I thought there was some way to control
the shape of the answer curve between some varying parameter (pressure,
velocity, tilt, etc.) and some brush characteristic (opacity, hardness,
size, etc.). However, I don't see this anywhere.

Where should I search?
-- 
Olivier Lecarme
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer