[...]
> > 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
>
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
