Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

GTK+ 2.24.10 & 3.4.2 cause problems to cfwrapper.py #41

Closed
vmagnin opened this Issue May 19, 2012 · 30 comments

Comments

Projects
None yet
2 participants
Collaborator

vmagnin commented May 19, 2012

Please do not use cfwrapper.py if you have upgraded to GTK+ 2.24.10 or GTK+ 3.4.2 (available in Ubuntu 12.04). The automatically generated files lack some functions interfaces and gtk-fortran can not be compiled anymore. I need to have a look to the GTK+ files in order to understand what has changed...

@ghost ghost assigned vmagnin May 19, 2012

Collaborator

vmagnin commented May 19, 2012

The problem is mainly due to the fact that many functions/objects of GLib and GTK+ have been deprecated (g_value_get_char, gtkhbox, gtktable...) For that reason, many examples of our project should be updated following the recommandations of the GTK+ documentation.

We will probably need to create new branches. Perhaps not for 2.24.10 but probably for GTK+ 3.4.

By now, you can use without problem the gtk-fortran files of the repository. They were generated with GTK+ 2.24.6 and 3.2.0 but work fine with 2.24.10 and 3.4.2.

Collaborator

vmagnin commented May 20, 2012

I have created a "test" branch for GTK+ 2.24.10 (and Glib 2.32):

Everything seems to be OK, but:

  • James, could you verify that my modifications concerning gtk-hl-tree are correct and introduce no regressions ?
  • If someone still have previous versions of GTK+ and Glib in its distribution, can he try to compile gtk-fortran and examples (./test.sh) and report any problem ?
Collaborator

jtappin commented Jun 13, 2012

The modifications to gtk-hl-tree look to be correct. I have fixed the syncing of the source file and the template and replaced kind=1 with kind=c_int8_t as the standard does not require a 1-byte value to be kind=1.

My Pardus-Anka box has glib 2.28.8 and Gtk 2.24.7, and cannot build the hl_list & tree examples in the test branch as g_value_get_schar was not introduced until 2.32. It also gives a warning:

/usr/bin/ld: warning: creating a DT_TEXTREL in object.

when building the sharable for the same reason.

I'm not sure how many distros are still running older versions (Debian stable to be sure), Pardus is very much in a state of flux having nearly died so some packages are lagging -- and gtk-related stuff isn't a high priority for a KDE/QT distribution.

Collaborator

jtappin commented Jun 13, 2012

Just one further thought. Since Fortran doesn't have unsigned types, I don't really see that there's likely to be a problem with g_value_get_char certainly I don't recall any issues on my G3 but I'd need to check that there are any examples using char g_values.

Collaborator

jtappin commented Jun 13, 2012

I think this is uncovering another argument type issue.

I added a G_TYPE_CHAR column to examples/hl_list_n.f90 and with the old g_value_[gs]et_char versions, the values are not at all correct, likewise if I use G_TYPE_UCHAR in either version.

As far as I can tell, Fortran character types are never passed by value -- i.e. even a scalar character is treated as an array of length 1.

Hence I think the only simple solution is to interpret gchar arguments as integer(kind=c_int8_t) but gchar * as character(kind=c_char), dimension(*), there does not seem to be a problem with return values. (Any other solution I can think of would involve writing wrappers and that's a whole new can of worms).

(Committed the updated example with both a char and a uchar column to test branch)

Collaborator

vmagnin commented Jul 28, 2012

A new branch gtk2_24_glib2_32 has been created (from the previous test branch) since deprecated functions have been deleted in GLib 2.32. gtk-fortran has been compiled and tested with Ubuntu 12.04 which is coming with gfortran 4.6.3, GTK+ 2.24.10 and GLib 2.32.3.

The GTK+ 3.4.2 version is now under testing in the test branch.

Collaborator

vmagnin commented Jul 28, 2012

Using GTK+ 3.4.2 and GLib 2.32.3 in the test branch, there is a lot of errors when compiling gtk-hl. Most of the following functions have been deprecated since GTK+ 2.24, 3.2 or 3.4:
'gtk_combo_box_get_active_text'
'gtk_combo_box_new_text'
'gtk_combo_box_entry_new_text'
'gtk_combo_box_append_text'
'gtk_combo_box_insert_text'
'gtk_combo_box_prepend_text'
'gtk_combo_box_remove_text'
'gtk_hbox_new'
'gtk_table_attach'
'gtk_table_get_size'
'gtk_table_new'
'gtk_table_resize'
'gtk_table_set_col_spacing'
'gtk_table_set_col_spacings'
'gtk_table_set_row_spacing'
'gtk_table_set_row_spacings'
'gtk_vbox_new'
'gtk_notebook_set_group'
'gtk_table_new'
'gtk_hbox_new'
'gtk_vbox_new'
'gtk_vbox_new'
'gtk_progress_bar_set_orientation'
'gtk_progress_left_to_right'
'gtk_progress_bottom_to_top'
'gtk_progress_top_to_bottom'
'gtk_progress_right_to_left'
'gtk_progress_bottom_to_top'
'gtk_progress_left_to_right'
'gtk_progress_right_to_left'
'gtk_progress_top_to_bottom'
'gtk_hscale_new'
'gtk_hscale_new_with_range'
'gtk_vscale_new'
'gtk_vscale_new_with_range'

See the following pages:
http://developer.gnome.org/gtk/stable/api-index-deprecated.html
http://developer.gnome.org/gtk3/stable/api-index-deprecated.html

Functions marked as deprecated should not be used because they will be deleted in future versions of GTK+ and GLib.

Collaborator

jtappin commented Jul 28, 2012

Vincent,
I updated the high-level table routines to use grids in the 3.x versions a few weeks ago, so provided you run the mk_gtk_hl.pl script to generate the routines from the templates the table routine errors should not be happening -- the other's I'd need to check, but I'm fairly sure that most of those should be handled by that script for 3.x versions.
[Actually looking at that list, I think some of them may be issues with usemodules.py as I don't recall the high level table ever using row_spacing, only row_spacings -- I think that it pulls substrings as well as full names, and I'm not sure if it understands comments]

The one area where I can see a potential issue would be for routines that were deprecated in 2.24 (especially if the replacement does not exist in 2.22).

Also: did you change the scalar character type mapping in cfwrapper.py?

Collaborator

vmagnin commented Jul 29, 2012

Hello James,
ok, after running mk_gtk_hl.pl in the test branch (3.4.2), the remaining problems with gtk_hl are:

'gtk_table_attach'
'gtk_table_get_size'
'gtk_table_new'
'gtk_table_resize'
'gtk_table_set_col_spacing'
'gtk_table_set_col_spacings'
'gtk_table_set_row_spacing'
'gtk_table_set_row_spacings'

GTK+ 3 documentation says "GtkTable has been deprecated since version 3.4. Use GtkGrid instead. It provides the same capabilities as GtkTable for arranging widgets in a rectangular grid, but does support height-for-width geometry management. "

Concerning "row_spacing", yes they were included in the "use gtk, only" statement in gtk-hl-container.f90. Your idea about substrings found by usemodules.py is probably correct.

'gtk_vbox_new'
'gtk_hbox_new'

"GtkVBox has been deprecated since version 3.2. You can use GtkBox instead, which is a very quick and easy change."

'gtk_hscale_new'
'gtk_hscale_new_with_range'
'gtk_vscale_new'
'gtk_vscale_new_with_range'

"GtkHScale has been deprecated since version 3.2, use GtkScale instead."

I have just changed the scalar character type mapping in cfwrapper.py:
gchar arguments as integer(kind=c_int8_t)
(only in the test branch by now)

Collaborator

vmagnin commented Jul 29, 2012

With gchar arguments as integer(kind=c_int8_t) , I have errors compiling the tests.f90 file (examples directory). The test_c_char_in_out() function is testing the input and output of the GLib g_ascii_tolower() function, which accepts and returns a gchar:

!  gchar g_ascii_tolower (gchar c) G_GNUC_CONST;
function g_ascii_tolower(c) bind(c) 
  use iso_c_binding, only: c_int8_t
  integer(kind=c_int8_t) :: g_ascii_tolower
  integer(kind=c_int8_t), value :: c
end function

Example of compiling errors:

../examples/tests.f90:182.33:

  if (iachar(g_ascii_tolower(c)) /= i) then
                             1

Error: Type mismatch in argument 'c' at (1); passed CHARACTER(1) to INTEGER(1)
../examples/tests.f90:182.17:

  if (iachar(g_ascii_tolower(c)) /= i) then
             1

Error: 'c' argument of 'iachar' intrinsic at (1) must be CHARACTER
...

Collaborator

jtappin commented Jul 29, 2012

I think that that should become:

    if  (g_ascii_tolower(ichar(c,c_int8_t)) /= i) then

I'm actually puzzled that that example ever worked, because when I tried to add a G_TYPE_CHAR or G_TYPE_UCHAR column to a list, it inserted not the character but the first byte of the address. (For an example see the hl_list_n example in the gtk2_24_glib2_32 branch).

Collaborator

jtappin commented Jul 29, 2012

Aha, I see what has happened with the deprecated gtk_table routines -- I modified gtk-hl-container-tmpl.f90 to use gtk_grid after the test branch was created and never pushed those changes to the test branch.

Collaborator

jtappin commented Jul 29, 2012

I have fixed the deprecated routines in the test branch after resyncing all the hl templates to the gtk3 branch.
I have also changed the cmake system to gtk3.

N.B. For the glib calls in gtk-hl-tree-tmpl.f90 I have not done a "proper" job (I just edited the source and haven't yet devised a scheme to auto-generate both versions, but since big changes are on the way in the high-level tree stuff I'll leave it till I've got that at a committable state.

There are still issues in the examples directory -- the build fails on bazaar.f90, gtkhello2.f90, julia_pixbuf.f90, mandelbrot_pixbuf_zoom.f90, menu.f90 and notebooks.f90 because of gtk_table and/or gtk_[vh]box routines.

So far I've only dealt with the test branch, I still need to resync the changes to the templates back into the other branches.

Collaborator

jtappin commented Jul 30, 2012

Regarding the integer(c_int8_t) vs. character(len=1,kind=c_char) issue for gchar & guchar arguments.

It turns out that the reason the high-level tree & list routines had an issue was that I was using svalue(1:1) which is treated as an array of size 1, if I use a temporary scalar length=1 character variable, the problem goes away.

However in the Gvalue settings, the new g_value_[sg]et_schar routines have an explicit gint8 argument so using character for _uchar and int for _schar makes for inconsistent interfaces, so for that reason I think c_int8_t is probably to be preferred (also I think the fact that using a length=1 substring doesn't give the same result as a scalar character variable is not good).

Collaborator

vmagnin commented Aug 2, 2012

I have just pushed the "gchar" modification in the gtk2_24glib2_32 branch.
For the master and gtk3 branches I will need virtual machines, since all my PC are now under Ubuntu 12.04 with GLib 2.32.

Collaborator

jtappin commented Aug 2, 2012

I have a (virtual) machine with Pardus Anka which has Gtk 2.24 and Glib 2.28 (I think -- need to check when I get home) but no Gtk3. (I'm not sure what is on my iBook as I've not updated that in months, again I'll check this evening or over the weekend).

Collaborator

vmagnin commented Aug 2, 2012

Ok James,
so you can update the master branch:

  • by changing the line 220 of cfwrapper.py (as in the gtk2_24_glib2_32 branch)
  • running it : python cfwrapper.py
  • testing the examples: ./tests.sh
  • comitting...
Collaborator

jtappin commented Aug 3, 2012

The guchar mapping should (I think) also be changed for the same reasons.

Collaborator

jtappin commented Aug 5, 2012

Really odd behaviour in 'tests.f90`

After modifying the mapping of gchar and guchar on systems with glib-2.32 the int16 test loop (test_int16_in_out1) is failing to terminate.

The version with the modified mappings works fine on the system with glib-2.28, but both the trees generated for 2.32 and for 2.28 loop infinitely when built & run on a 2.32 system.

Changing either the upper or lower limit of the loop by 1 makes it terminate correctly. While I can see a potential problem with loops that end on huge(), that fact that it's inconsistent suggests that's not the issue.
I'm a bit wary of pushing code with a workaround for an issue I don't understand.

Any thoughts?

Update (6/8/12):
I've tested with a version that reverts to character for both g*char types and it still loops forever with glib-2.32 so I'm happy it's not something I've broken.

Collaborator

jtappin commented Aug 8, 2012

I've now updated the master branch. (Also added the new renderers for list & trees, and automated plplot detection).
The _auto.f90 files are generated against gtk2-2.24, glib-2.28.

All the examples look to run correctly, I can't test the plplot stuff as there is a module version mismatch between the plplot packages and the version of gfortran, but it is found if present.

I'll try to do the gtk3 branch over the next few days (using an oneiric VM), then the others.

I think that we should probably then re-align the branches as:
master -> gtk2-old
gtk2_24_glib2_32 -> master
gtk3 -> gtk3_old
test -> gtk3

Collaborator

jtappin commented Aug 9, 2012

All four branches should now be updated to use c_int8_t for gchar & guchar.

Also pushed are plplot integration, extra renderers for lists & trees and a few other small tweaks.

N.B. I've not been able to test plplot (other than detection) for the master & gtk3 branches as Pardus has broken modules (wrong compiler) and Ubuntu Oneiric has too old a plplot version.

(I've not tried to update the old build scripts).

Collaborator

vmagnin commented Aug 16, 2012

Thank you James for the hard work. I have successfully tested the plplot examples for the gtk3 branch, under Ubuntu 12.04.

I am OK to rename the branches as suggested. I have tried to do it with the "git branch -m old new" syntax, but failed to push it on github. I do not remember how I had done with the gtk2_24_glib2_32 branch... I have just finally delete my local gtk3 branch and put a mess in my local repository... Can you try the renaming ?

Collaborator

jtappin commented Aug 17, 2012

Hi Vincent
I'll have to take a read of the git documentation, and try to figure out how it should be done.

Collaborator

vmagnin commented Aug 17, 2012

I will also have a look. The "git branch -m old new" syntax is OK for the local repository. But I failed to push the modification.
I have found the following link which seems to suggest things are not as easy as they should:
http://stackoverflow.com/questions/1526794/git-rename-remote-branch

Collaborator

jtappin commented Aug 19, 2012

Hi Vincent,
I have managed to get things such that
master is gtk2.24 glib2.32 (Ubuntu 12.04)
gtk3 is gtk3.4 glib2.32 (Ubuntu 12.04)
gtk2-old is gtk2.24 glib 2.28 (Pardus Anka)
gtk3-old is gtk3.2 glib 2.30 (Ubuntu 11.10)

As I ended up doing a semi-manual process of pushing pulling and merging, a few glitches in some of the scripts also got cleaned up.

However I have not managed to delete the old test and gtk2_24_glib2_32 branches.

There do appear to be some discrepancies in the screenshots directories.

Collaborator

vmagnin commented Aug 20, 2012

Hi James,

for information, when I type git pull origin, git tells me there is two new branches but do not create them locally. The branch is created locally when I type e.g. git checkout gtk3-old.

The command to delete a remote branch is:
git push origin :gtk2_24_glib2_32
If you think everything is ready, I can try.

Do you think we still need to maintain the gtk?-old branches ? I think four branches is too heavy to maintain.

Concerning the screenshot directories, I think that at the beginning of the project I put everything in a directory in all the branches, without caring about the GTK version. So some cleaning is now needed...

Collaborator

jtappin commented Aug 20, 2012

I'm still not very clear on keeping multiple branches in one tree for the local copy. I tried to do it over the weekend but it wouldn't find the test branch. So I went back to what I had been doing and checking each branch to a separate local directory.

Let's give it a few days before deleting the gtk2_24_glib2_32 and test branches just in case there are any oversights.

As for the gtk?-old branches: I think that they can be essentially frozen so we won't add new features into them, only fix catastrophic bugs, there are still a few distros with older glib versions (though it's hard to be sure which as DistroWatch doesn't list the Glib version)--I suspect most of those are also the ones with old gcc/gfortran versions which are going to be problematic anyway.

Collaborator

vmagnin commented Feb 17, 2013

James,
I think we can now delete the gtk2_24_glib2_32 and test branches. Are you OK ?

Collaborator

jtappin commented Feb 17, 2013

I think that's reasonable. They were only kept in case we had made some mistakes in setting up the new structure.

Collaborator

vmagnin commented Feb 17, 2013

OK, it is done:

git push origin :gtk2_24_glib2_32
git push origin :test

Note that it seems also possible to delete a branch from the GitHub branch tab.

@vmagnin vmagnin closed this Feb 17, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment