Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2005-06

BUG: gtk2 unit and GtkFileChooserDialog

9 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Federico Lox Lucignano

Hi to all,
I'm new to FPC and making some tests in the last few days I've found 2 little but annoying bugs:

1) in libglade2 unit the windows dll is referenced as "libglade-2.0.dll" while the correct name is "libglade-2.0-0.dll" (in all the other gtk related units the libxxx-2.0-0.dll pattern is used correctly)

2)Although it is declared in gtkfilechooserdialog.inc the PGtkFileChooserDialog symbol doesn't seem to be usable (i.e. the compiler doesn't find it at compile time, and yes, I've included the right "uses" statements).

Thanks for the attention ;-)

=================================================

Federico Lucignano

e-mail personale:

Reply by email

Peter Vreman
to Federico Lox Lucignano
Show quoted text 5 lines
1) in libglade2 unit the windows dll is referenced as "libglade-2.0.dll" while the correct name is "libglade-2.0-0.dll" (in all the other gtk related units the libxxx-2.0-0.dll pattern is used correctly)

Fixed

2)Although it is declared in gtkfilechooserdialog.inc the PGtkFileChooserDialog symbol doesn't seem to be usable (i.e. the compiler doesn't find it at compile time, and yes, I've included the right "uses" statements).

GTK 2.2 is supported. gtkfilechooserdialog is only included if the unit is recompiled with GTK 2.4 support

Reply by email

Federico Lox Lucignano
to Peter Vreman

Alle 23:00, mercoledì 08 giugno 2005, hai scritto:

Show quoted text 8 lines
> 1) in libglade2 unit the windows dll is referenced as "libglade-2.0.dll" > while > the correct name is "libglade-2.0-0.dll" (in all the other gtk related > units > the libxxx-2.0-0.dll pattern is used correctly) Fixed

Perfect ;-)

Show quoted text 7 lines
> 2)Although it is declared in gtkfilechooserdialog.inc the > PGtkFileChooserDialog symbol doesn't seem to be usable (i.e. the compiler > doesn't find it at compile time, and yes, I've included the right "uses" > statements). GTK 2.2 is supported. gtkfilechooserdialog is only included if the unit is recompiled with GTK 2.4 support

Yes, I found the $define directive about 5 minutes ago (for those that don't know it is in yoursrcdir/packages/extra/gtk2/gtk+/gtk/gtk2.pas and can have the following values: GTK2_2, GTK2_4, GTK2_6, you have to set it in the source ;-)), but I've searched for it for almost 1 hour O_O, this thing should be more visible, for example what about putting it in something like a configuration file or even better finding a way to make it choose the libgtk2 version dinamically at unit-compile-time accordingly to what is available on the system?

=================================================

Federico Lucignano

e-mail personale:

Reply by email

Peter Vreman
to Federico Lox Lucignano
Show quoted text 24 lines
> > 2)Although it is declared in gtkfilechooserdialog.inc the > > PGtkFileChooserDialog symbol doesn't seem to be usable (i.e. the > compiler > > doesn't find it at compile time, and yes, I've included the right > "uses" > > statements). > > GTK 2.2 is supported. gtkfilechooserdialog is only included if the unit > is > recompiled with GTK 2.4 support Yes, I found the $define directive about 5 minutes ago (for those that don't know it is in yoursrcdir/packages/extra/gtk2/gtk+/gtk/gtk2.pas and can have the following values: GTK2_2, GTK2_4, GTK2_6, you have to set it in the source ;-)), but I've searched for it for almost 1 hour O_O, this thing should be more visible, for example what about putting it in something like a configuration file or even better finding a way to make it choose the libgtk2 version dinamically at unit-compile-time accordingly to what is available on the system?

That is not possible. The gtk2 unit is already delivered precompiled with a release. So it can't detect the gtk version installed at your machine.

The only possible solution i see is to add multiple units gtk2_2, gtk2_4 and gtk2_6 that provide the functions for each gtk release. But that needs to be decided with the original gtk2 for pascal maintainers.

Reply by email

Mattias Gaertner
to Peter Vreman
Show quoted text 31 lines
>> > 2)Although it is declared in gtkfilechooserdialog.inc the >> > PGtkFileChooserDialog symbol doesn't seem to be usable (i.e. the >> compiler >> > doesn't find it at compile time, and yes, I've included the right >> "uses" >> > statements). >> >> GTK 2.2 is supported. gtkfilechooserdialog is only included if the unit >> is >> recompiled with GTK 2.4 support > > Yes, I found the $define directive about 5 minutes ago (for those that > don't > know it is in yoursrcdir/packages/extra/gtk2/gtk+/gtk/gtk2.pas and can > have > the following values: GTK2_2, GTK2_4, GTK2_6, you have to set it in the > source ;-)), but I've searched for it for almost 1 hour O_O, this thing > should be more visible, for example what about putting it in something > like a > configuration file or even better finding a way to make it choose the > libgtk2 > version dinamically at unit-compile-time accordingly to what is > available on > the system? That is not possible. The gtk2 unit is already delivered precompiled with a release. So it can't detect the gtk version installed at your machine. The only possible solution i see is to add multiple units gtk2_2, gtk2_4 and gtk2_6 that provide the functions for each gtk release. But that needs to be decided with the original gtk2 for pascal maintainers.

I see no problem with that.

Mattias

Reply by email

Federico Lox Lucignano
to Peter Vreman: That is not possible. The gtk2 unit is already delivered precompiled with a release. So…
Mattias Gaertner wrote: I see no problem with that.

Well the problem is that you cannot find a word about this "setting" in any readme or web-page, the problem is that someone that doesn't know about it could loose hours trying to find why GtkFileChooserDialog is unavailable although there's an entire array of files with it's name.

After I've found the "guilty" $define GTK2_2 I've started to wonder if there are other "hidden" settings like this one in the other units. O_o ( okok I'm starting to be a bit obsessed :-D )

Show quoted text 6 lines
That is not possible. The gtk2 unit is already delivered precompiled with a release. So it can't detect the gtk version installed at your machine. The only possible solution i see is to add multiple units gtk2_2, gtk2_4 and gtk2_6 that provide the functions for each gtk release. But that needs to be decided with the original gtk2 for pascal maintainers.

Sorry, I'm not talking about the binary release, I'm talking about the sources available through both the website and Subversion ;-)

=================================================

Federico Lucignano

e-mail personale:

Reply by email

Mattias Gaertner
to Federico Lox Lucignano
Show quoted text 7 lines
>Mattias Gaertner wrote: >I see no problem with that. Well the problem is that you cannot find a word about this "setting" in any readme or web-page, the problem is that someone that doesn't know about it could loose hours trying to find why GtkFileChooserDialog is unavailable although there's an entire array of files with it's name.

The documentation is a further problem. See below. We need a better solution for the binary releases anyway.

Show quoted text 19 lines
After I've found the "guilty" $define GTK2_2 I've started to wonder if there are other "hidden" settings like this one in the other units. O_o ( okok I'm starting to be a bit obsessed :-D ) > That is not possible. The gtk2 unit is already delivered precompiled > with a release. So it can't detect the gtk version installed at your > machine. > > The only possible solution i see is to add multiple units gtk2_2, gtk2_4 > and gtk2_6 that provide the functions for each gtk release. But that > needs to be decided with the original gtk2 for pascal maintainers. Sorry, I'm not talking about the binary release, I'm talking about the sources available through both the website and Subversion ;-) for example what about putting it in something like a configuration file or even better finding a way to make it choose the libgtk2 version dinamically at unit-compile-time accordingly to what is available on the system?

This is already done by compile_with_fpc_under_linux.sh. It compiles a small pascal program, which prints the current gtk version and then the script sets the -d flags accordingly. The problem is here: It would be nice, to ship some precompiled gtk2 bindings and the Lazarus IDE does not have the flags, so find declaration does not find filechoose and friends. So, it was merely a hack, and therefore undocumented.

Peter's idea would solve it, so I see no problem with that. Then users can decide, what gtk versions they want to support. And this should be documented.

Mattias

Reply by email

peter green
to Mattias Gaertner
Show quoted text 8 lines
> Well the problem is that you cannot find a word about this "setting" in > any readme or web-page, the problem is that someone that doesn't know > about it could loose hours trying to find why GtkFileChooserDialog is > unavailable although there's an entire array of files with it's name. The documentation is a further problem. See below. We need a better solution for the binary releases anyway.

the better soloution is dlopen/dlsym this allows the descision on what to use to be moved to app development time or even runtime. (e.g. only using new features if they are actually availible)

unfortunately doing this by hand is tedious++ so i think code generation will have to be used to reasonablly do this. basically you have to generate stubs that check if a procvar is nill,call a function to populate it if it is nil and then call down the procvar. the code generator would take a name and a parameter list and spit out theese stubs.

Reply by email

Micha Nelissen
to peter green
Show quoted text 9 lines
the better soloution is dlopen/dlsym this allows the descision on what to use to be moved to app development time or even runtime. (e.g. only using new features if they are actually availible) unfortunately doing this by hand is tedious++ so i think code generation will have to be used to reasonablly do this. basically you have to generate stubs that check if a procvar is nill,call a function to populate it if it is nil and then call down the procvar. the code generator would take a name and a parameter list and spit out theese stubs.

The stubs don't implement the functionality so you have a half-broken app. The problem really has to be solved by the app developer, not the bindings maintainer. The simplest solution is to require users to have gtk 2.6 or whatever library (it's free anyway).

Micha

Reply by email