John Spray wrote:
>> Attached is a version that should compile against the cleaned-up
>> FileFilterList API when you uncomment the block.
>
> Cool, that works great (after adding a couple of lyx::support::). I'll
> commit this if the filefilter API is going to stay this way.
No further changes p
On Fri, 2004-11-26 at 12:35 +, Angus Leeming wrote:
> John Spray wrote:
>
> > On Thu, 2004-11-25 at 14:44 +, Angus Leeming wrote:
> >> I asked because I wanted to know what functionality gtk would really
> >> need from FileFilterList. It seems that you're saying that we should
> >> really
John Spray wrote:
> On Thu, 2004-11-25 at 14:44 +, Angus Leeming wrote:
>> I asked because I wanted to know what functionality gtk would really
>> need from FileFilterList. It seems that you're saying that we should
>> really have:
>>
>> struct FileFilterList {
>> struct Filter {
>>
On Thu, 2004-11-25 at 14:44 +, Angus Leeming wrote:
> I asked because I wanted to know what functionality gtk would really
> need from FileFilterList. It seems that you're saying that we should
> really have:
>
> struct FileFilterList {
> struct Filter {
> std::vector
John Spray wrote:
> On Thu, 2004-11-25 at 12:06 +, Angus Leeming wrote:
>> John, the GTK file dialog currently ignores the list of filters. Is
>> there any plan to change that?
> The plan is to rewrite the file dialog stuff to use GtkFileChooser
> instead of GtkFileSelection. I'd been plannin
On Thu, 2004-11-25 at 12:06 +, Angus Leeming wrote:
> John, the GTK file dialog currently ignores the list of filters. Is there
> any plan to change that?
The plan is to rewrite the file dialog stuff to use GtkFileChooser
instead of GtkFileSelection. I'd been planning to leave that until the
d
John, the GTK file dialog currently ignores the list of filters. Is there
any plan to change that?
FileDialog::Private::open(string const & path,
lyx::support::FileFilterList const & /*filters*/,
string const & /*suggested*/)
The idea is to popu
