[...]
> I wasn't meaning to argue *for* a combo, just the distinction between
> project and custom/non-project/whatever.  As we agreed, "all" is redundant
> if the delete is available, so a "project" check box is fine by me so long
> as it does the same as the project setting on the combo.

Since "project" does provide functionality, I'm changing the
proposition: make it a check box. A single click will be enough to
(un)lock it, and a double click (check-uncheck) will load the
project patterns and enable editing.

Sounds ok to me.
 

(From UI standpoint, it may be better to make Files label a button,
and the text between Files and Project on click - it'll look very
similar to the current combo box. But I'm not a HIG expert.)

Yes, any two-state widget would do, though I don't think changing the label is right, the field is always the file patterns, its just where they come from that changes.  The advantage of the "Project" checkbox is we don't have to agree on a name for the non-project state :)
 
[...]
> By "usual" I just meant using the %, not what the actual possible
> substitutions would be.

--include=%p will simply produce --include=<all patterns>. We would
need something like {--include=%p} to signify what text to repeat for
each pattern.

Such complications are probably part of why it hasn't been done :)
 

> > I'll explain again. The only point of the checkbox is to be able to
> > quickly disable the extra options, which is the same as clearing them,
> > *except* that you can restore them quickly.
> >
> > If we consider them so important as to have an extra interface element,
> > why don't we use a normal history, and have several sets of options?
> >
>
> "why don't" == "doesn't, and nobody cared enough to do it" ;-)

:) On the same hand, we don't even save the Files history, and not even
the current values of 'Search for' and 'Replace with'.


I guess none of the developers do the same search/replace in multiple sessions very often, so saving settings and history hasn't been worth it.

Cheers
Lex

--
E-gards: Jimmy
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel