After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 652044 - uses deprecated APIs
uses deprecated APIs
Status: RESOLVED OBSOLETE
Product: gparted
Classification: Other
Component: application
GIT HEAD
Other Linux
: Normal normal
: ---
Assigned To: Curtis Gedak
gparted maintainers alias
: 791286 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-06-07 12:41 UTC by Colin Watson
Modified: 2018-07-15 08:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
initial attempt at building with gtkmm 2.24 without deprecated APIs (51.09 KB, patch)
2011-06-07 12:41 UTC, Colin Watson
none Details | Review
Work in progress to further initial attempt to avoid deprecated APIs (72.08 KB, patch)
2012-01-12 20:19 UTC, Curtis Gedak
none Details | Review
Work in progress to further initial attempt to avoid deprecated APIs (75.54 KB, patch)
2012-02-25 18:54 UTC, Curtis Gedak
none Details | Review
Work in progress patch to begin adding gtkmm 3.0 support (63.46 KB, patch)
2013-10-08 21:34 UTC, Curtis Gedak
none Details | Review
Stop using deprecated method free_colors() (v1) (4.47 KB, patch)
2013-10-11 19:21 UTC, Mike Fleetwood
none Details | Review
Stop using depreciated widget alignment enumerators (v1) (20.34 KB, patch)
2013-10-18 09:19 UTC, Mike Fleetwood
none Details | Review

Description Colin Watson 2011-06-07 12:41:02 UTC
Created attachment 189389 [details] [review]
initial attempt at building with gtkmm 2.24 without deprecated APIs

GParted needs to be ported away from deprecated APIs, as the first step to getting it working on GTK 3.  I've made a start at doing this.  The attached patch builds and minimally runs; however, I've clearly done something wrong with the Cairo port, as the visual disk area is blank.  There may well be other run-time problems.  However, since I've run out of time for working on this at the moment, I thought I might as well attach this so that perhaps somebody else can use it as the basis for further work.

I used the MM_ARG_ENABLE_WARNINGS Autoconf macro from mm-common as an easy way to get './configure --enable-warnings=fatal'.  I needed to add -Wno-unused-result and -Wno-unused-parameter to src/Makefile.am to work around some GCC warnings I didn't want to deal with immediately; since there aren't too many of those, perhaps they can be fixed later and those extra -W options removed.
Comment 1 Curtis Gedak 2011-06-07 14:31:08 UTC
Thanks Colin for reporting this problem and working towards a solution.

Is there a GNU/Linux distribution available that you would recommend for testing purposes so that I can work through the GTK 3 issues?
Comment 2 Sebastien Bacher 2011-06-29 10:59:59 UTC
You can clean the deprecation warnings on any distribution using the gtk2 version, the gtk3 bindings are available on most of the recent distributions as well (or at least on fedora15, debian unstable, and ubuntu oneiric)
Comment 3 Curtis Gedak 2011-07-14 16:59:19 UTC
Thank you Sebastien for this additional information.

Recently I found the following relevant link which should also help me with this task:
   Porting from gtkmm-2.4 to gtkmm-3.0
   http://live.gnome.org/gtkmm/PortingToGtkmm3
Comment 4 Curtis Gedak 2011-08-10 16:53:14 UTC
(In reply to comment #0)
> GParted needs to be ported away from deprecated APIs, as the first step to
> getting it working on GTK 3.  I've made a start at doing this.  The attached
> patch builds and minimally runs; however, I've clearly done something wrong
> with the Cairo port, as the visual disk area is blank.

Thanks again Colin for providing your initial attempt code.  I have used it as a baseline, and I too have not been able to get the cairo code to work.

While trying to get to the root of the problem, I tried compiling the following cairomm example:

   Example Application: Creating a Clock with Cairo
   http://developer.gnome.org/gtkmm-tutorial/3.0/sec-drawing-clock-example.html.en

This example works well in gtkmm-3.0, and it compiles in gtkmm-2.4 but does not display any graphics.  Hence I think the back port of some of the cairo stuff is not fully operational.

In going forward I plan to use #ifdef's to check for gtkmm-3.0 or gtkmm-2.4 so that the GParted code will compile under both gnome 3.0 and gnome 2.x.
Comment 5 Curtis Gedak 2011-09-22 15:28:52 UTC
While working on this task, I have run into another stumbling block.  Hopefully someone can offer me a tip on how to overcome this obstacle.

The obstacle is a crash when running GParted with the git.diff applied (provided by Colin).

To encounter the crash, start GParted, select unallocated space, and then choose to create a new partition.

The problem appears to be with the set_sensitive method call on the comboboxtext widget in the method Dialog_Partition_New::Dialog_Partition_New().

For example:
    std::vector<Gtk::CellRenderer*> cells = combo_type .get_cells();
    <snip>
    cells[ 1 ] ->set_sensitive( false );     <---- Crash location


The old code with the optionmenu widget does not exhibit this problem.

Any advice on how to resolve this problem would be greatly appreciated.
Comment 6 Curtis Gedak 2012-01-12 20:19:43 UTC
Created attachment 205132 [details] [review]
Work in progress to further initial attempt to avoid deprecated APIs

Attached is a patch that is a work in progress.

This patch is not ready to be committed to the gnome git master branch.  For example the patch still segfaults when creating a new partition.

This patch has been uploaded in case anyone else has a chance to further investigate the segfault problem.  At the moment one work-around I can think of is to change the Partition Type drop down list into a set of radio buttons.

To apply the patch (removing the commit status) use:

     git apply 0001-Work-in-progress-to-address-bug-652044-uses-deprecat.patch

To apply the patch with commit status use:

     git am -3 0001-Work-in-progress-to-address-bug-652044-uses-deprecat.patch
Comment 7 Curtis Gedak 2012-02-15 17:43:53 UTC
I am working on this patch again.  At the moment I see three items that still must be addressed:


  a) Fix the segmentation fault that occurs when creating a new
     partition.

     NOTE: To encounter the crash, start GParted, select unallocated
           space, and then choose to create a new partition.

     The problem seems to be an inability to set the partition type
     drop down list items inactive.

     To work around this problem I plan to only add only valid
     partition types to the list.
    

  b) Address the cairo graphics Gnome 3 back ported stuff not working.

     The problem is that when using the back ported cairo graphics
     stuff, the graphics are not displayed.

     To work around this problem I plan to use configure options to
     only use the cairo graphics stuff when configured and compiled
     with Gnome 3 libraries.


  c) Comment out the MM_ARG_ENABLE_WARNINGS stanza used for testing.

     This one is easy, but I will leave it to the end so that it is
     easier to continue testing.


If anyone has any comments or advice, please feel free to add to this
bug report.
Comment 8 Curtis Gedak 2012-02-15 18:58:54 UTC
Well I have been able to work around the problem listed in item (a) above.  
However, this led me to another similar challenge.  Namely the File system drop down menu previously also displayed inactive entries (e.g., file systems that could not be created because the tools are missing).

I plan to investigate replacing the OPTIONMENU method with the higher up COMBOBOX method instead of COMBOBOXTEXT.  Hopefully this supports inactive (i.e., non-selectable) entries.
Comment 9 Curtis Gedak 2012-02-17 17:23:38 UTC
Thanks to a response by Kjell Ahlstedt to my post on the gtkmm mailing list, I now know how to make the ComboBox method work.

The relevant mailing list post can be found at the following link:

Re: ComboBox with some entries not selectable or grayed out
http://mail.gnome.org/archives/gtkmm-list/2012-February/msg00041.html

A big thanks goes to Kjell Ahlstedt for showing the way over this hurdle.  :-)
Comment 10 Curtis Gedak 2012-02-25 18:54:42 UTC
Created attachment 208415 [details] [review]
Work in progress to further initial attempt to avoid deprecated APIs

Good news, I am now one step closer to developing a proper patch set to address this bug report.

This latest attachment fixes the segmentation fault that used to occur when creating a new partition.

The two issues that remain to be addressed are as follows:

  a) Address the cairo graphics Gnome 3 back ported stuff not working.

     The problem is that when using the back ported cairo graphics
     stuff, the graphics are not displayed.

     To work around this problem I plan to use configure options to
     only use the cairo graphics stuff when configured and compiled
     with Gnome 3 libraries.


  b) Comment out the MM_ARG_ENABLE_WARNINGS stanza used for testing.

     This one is easy, but I will leave it to the end so that it is
     easier to continue testing.


If anyone has any comments or advice, please feel free to add to this
bug report.
Comment 11 Phillip Susi 2013-10-08 14:06:48 UTC
Hi Curtis, it looks like so far you have been collecting all of the changes into a single massive patch.  I think it would be a good idea to break it up into a series of smaller patches, and maybe set up a gparted-1.0 git branch to hold them and work towards gparted 1.0.0 there.
Comment 12 Phillip Susi 2013-10-08 14:23:20 UTC
Also the number and complexity of #ifdefs for gtkmm 2.22 is mind numbing.  I really think gparted 1.0 should drop support for < 2.22 as continuing to support such ancient versions is prohibitively expensive in terms of reducing code readability.
Comment 13 Curtis Gedak 2013-10-08 21:31:46 UTC
Hi Phillip,

Your interest in enhancing GParted with the goal to have GParted
compile and run under gtkmm-3.x is appreciated.

Last week I tested the patch in comment #10 with Fedora 19 and the
same problem remains with the cairo graphics Gnome 3 back ported stuff
not working.  See also comment #4.

To compile I applied the patch on top of commit
efb00f1ed0ca97239620222466ae093fb7bcec82 and then had to comment out
the MM_ARG_ENABLE_WARNINGS macro in configure.in, which used to work
on an earlier version of Ubuntu (11.04 I think?).

The additional patch in this report includes my work back in early
2012 to try to add support for gtkmm-3.x.  My thoughts were that since
the back ported cairo graphics appear to be broken, then the only way
to move forward was to go directly to gtkmm-3.x.  I never did complete
this work as I became busy with other stuff.  Also the timing for
implementing gtkmm-3.x support seemed to early.

While working on these patches my development steps were:

  a)  Compile using:
        ./autogen.sh && ./configure --enable-warnings=fatal
  b)  Note the error and update the appropriate code
  c)  Goto (a)


Now onto the issues raised in comment #11 and comment #12.  If I
understand these correctly, the issues can be summarized as:

I1)  The complexity of #ifdefs for gtkmm 2.22 is mind numbing.  Dropping
     support for gtkmm < 2.22 would reduce this complexity.

I2)  A single massive patch is unwieldy.  Prefer to break it up into a
     series of smaller patches.

I3)  Suggest setup a gparted-1.0 git branch to hold patches and work
     towards gparted 1.0.0.


Responses to issues follow:

A1)  I agree that dropping support for gtkmm < 2.22 would enable us to
     get rid of many #ifdefs.  I assume that you chose gtkmm-2.22
     because this version contains APIs back ported from gtkmm-3.0.

     Regarding getting rid of many #ifdefs, dropping support for
     gtkmm < 3.0 would enable us to get rid of most, if not a all of
     this complexity.

     Peronally I do not wish to support two different versions of
     GParted, or at least not for an extended period.  As such we need
     to think about the appropriate time frame to switch from gtkmm
     2.4 support to gtkmm 3.0 support.

     To help us with this decision I have pulled together the
     following information on currently supported major GNU/Linux
     distributions and gtkmm versions.

     Mike and Phillip, please feel free to update this chart if I have
     made mistakes.

     GNU/LINUX DISTRO   SUPPORTED UNTIL   GTKMM 2.4      GTKMM 3.X
     ================   ===============   ============   ============
        Centos  5.10+          2017-03    2.10.9-1?          N/A?
        Centos  6.x            2020-11    2.10.9-1?          N/A?
        Debian  6.0            2014-05?   2.20.3-1           N/A
        Debian  7.0            TBA        2.24.2-1         3.4.0-3
        Fedora 18        Early 2014       2.24.2-4         3.6.0-1
      openSUSE 11.4            2014-06    2.24.4-1           N/A
      openSUSE 12.2            2014-01    2.24.2-5.1.2     3.4.0-2.1.2
        Ubuntu 10.04    Server 2015-04    2.20.1-1           N/A
        Ubuntu 12.04           2017-04    2.24.2-1         3.2.1-1

     If we drop support for gtkmm < 2.22, then GParted will not
     compile on the following distos:
          Centos  5.x and 6.x
          Debian  6.0
        openSUSE 11.4
          Ubuntu 10.04

     If we drop support for gtkmm < 3.0, then GParted will not compile
     on the following distros:
          Centos  5.x and 6.x
          Debian  6.0
        openSUSE 11.4
          Ubuntu 10.04

     Since these two lists are the same, I think that when we make the
     switch, we should go over completely to gtkmm 3.0.

     My thoughts are that mid-2014 might be a good time to make this
     switch based on the "supported until" dates.

     Some Questions:

     Q1)  Should we drop support for gtkmm < 2.22 or go all the way
          and drop support for gtkmm < 3.0?

     Q2)  What timeframe should we target for the switch in order to
          minimize the impact of switching?


A2)  I agree that a single massive patch is unwieldy.  However, there
     is a challenge enabling newer APIs, yet still having the code
     compile.  This is particularly a problem when I started working
     on gtkmm 3.0 support.  Either all the code works with gtkmm 3.0,
     or it won't compile.

     Since we want all the code in a commit to compile, I am afraid
     that we will have to make due with some very large patches.

     If there is some way to work around this limitation, then I am
     all ears.  :-)


A3)  Due to problems noted in (A2), I don't think that we'll be able
     to take advantage of multiple small commits.  With this in mind I
     think that one person will have to develop a few large patches
     that others can review.  I don't think that having these large
     patches in a git branch, and then having to change the same said
     patches in the git branch will be any more effective then simply
     working with patches.

     At least those are my thoughts.  I am open to learning specific
     reasons why this might be a good idea.

Curtis
Comment 14 Curtis Gedak 2013-10-08 21:34:26 UTC
Created attachment 256765 [details] [review]
Work in progress patch to begin adding gtkmm 3.0 support

Oops, forgot to include the patch of work-in-progress to add gtkmm-3.x support.

Note that this patch applies on top of the previous patch in comment #10.
Comment 15 Phillip Susi 2013-10-09 00:45:14 UTC
Just because a release is supported long term does not mean that we want to support the latest gparted on that release.  Debian 6 is depreciated already for instance, so I don't see why we need to worry about gparted 1.0 running on it.

Ignoring the apparent issues with the backported changes for the moment, the idea seems to be for gtk 2.22+ to support most of the required changes for the move to gtk3, so what I propose is for gparted 1.0 to work with either gtk3, or 2.22+.  Hopefully gparted 1.0 should be ready in the first half of 2014.  That should give us plenty of time to get it into shape, and support even somewhat old distros, just not really ancient ones.  Until then, we should have a development branch working towards that goal while continuing work on the existing branch.  During development any new features in current gparted would be included in the 1.0 branch by periodic rebasing.

Once the 1.0 branch is working well with gtk 2.22 and 3.0, it would be released, and anyone still running a distro without 2.22+ would simply need to upgrade or stick to the older gparted.

As far as keeping the code compiling while keeping the commits small, this is easily handled:  it doesn't necessarily have to compile with the depreciated apis disabled.  In other words, you disable the depreciated apis, fix one thing, and make a commit of the fix, minus the changes disabling the depreciated api.  That way it compiles with the depreicated apis still enabled, and you can verify that the small commit did not break things with gtk2.  You just can't verify that all of the changes fully fix gparted to work without the depreciated apis.  I believe you can even choose to disable the depreciated apis on a module by module basis.
Comment 16 Mike Fleetwood 2013-10-09 07:44:21 UTC
Having a minimum of gtkmm >= 2.22 is going to exclude the current RHEL /
CentOS 6.x, which only has gtk(mm) 2.18.
    http://distrowatch.com/table.php?distribution=redhat
While Red Hat themselves won't update GParted I think we should still
keep GParted compiling on significant current distros.


Another way to work could be to port to gtk 3.0 on a branch without
regard for backward compatibility.  Small commits much preferred.  When
complete cherry pick the changes back into master working out how to add
the minimal #ifdefs.
Comment 17 Phillip Susi 2013-10-09 13:35:01 UTC
Seeing as how that release is already 3 years old, I'd say that anyone wanting to bypass the distribution and build and install the latest gparted can also be bothered to install an up to date gtk library too.

And keep in mind this is still another 6 months away, and at least at first, gparted 1.0 will have feature parity with the last 0.xx, so they can probably continue to run that and not miss anything until a year or so from now, when they will then be running a 4 year old distribution.  I don't think we should feel bad telling someone trying to build gparted on a 4 year old distribution that they will also have to build a library.

I think very few people will be in that situation, so better to put the ( really pretty small ) burden on them instead of making it somewhat harder to work on the code and more likely to have bugs that will effect everyone.
Comment 18 Curtis Gedak 2013-10-09 16:45:38 UTC
I believe that 2.18 is of 2010 vintage.

RHEL / Centos 6.4 was released in early 2013 when newer versions of both gtkmm v2 and v3 were available.

I wonder why RHEL / Centos have such an old version of gtk(mm)?

Are they planning to not support gtk(mm) applications on the platform?

On the plus side, even if RHEL / Centos do not plan to support gtk(mm), applications like GParted can still be run from live media.
Comment 19 Curtis Gedak 2013-10-09 16:53:58 UTC
While trying to answer some my own questions from comment #18 about gtkmm support in RHEL / Centos I came across the following Red Hat bug report.

Bug 504903 - Question: Is there any plan to add gtkmm in RHEL5 or RHEL6?
https://bugzilla.redhat.com/show_bug.cgi?id=504903

This bug has been closed as a duplicate of another bug.  Unfortunately when I try to view the report (even when logged in with a RedHat bugzilla account), I see the following message:

    You are not authorized to access bug #509001.

Can anyone else view the contents of this link?

https://bugzilla.redhat.com/show_bug.cgi?id=509001
Comment 20 Phillip Susi 2013-10-09 17:43:09 UTC
Nope... you gotta love redhat's bug tracker...
Comment 21 Mike Fleetwood 2013-10-09 22:09:39 UTC
(In reply to comment #18)
> I believe that 2.18 is of 2010 vintage.
> 
> RHEL / Centos 6.4 was released in early 2013 when newer versions of both gtkmm
> v2 and v3 were available.
> 
> I wonder why RHEL / Centos have such an old version of gtk(mm)?

RHEL generally don't upgrade components after the initial release, so
RHEL 6 was released in Nov 2010.  It was based on Fedora 12 released
Nov 2009 which came with gtkmm-2.18.  Sometime in 2017 when RHEL 6.10
update is released it will still come with gtkmm-2.18.  It's just how
Red Hat maintain binary compatibility.  They patch in selected features
into old code.

http://en.wikipedia.org/wiki/Rhel#RHEL_6
https://access.redhat.com/site/support/policy/updates/errata/


> Are they planning to not support gtk(mm) applications on the platform?

Yes gtkmm is included in RHEL.  GParted is not part of the core distro
but is part of EPEL (Extra Packages for Enterprise Linux).  It's a
really old version, 0.6.0.  It might be possible to get this updated as
the update policy says:
    Only updates that fix important bugs (say: data-corruption, security
    problems, really annoying bugs) go to a testing branch for a short
    time period and then are pushed to the stable branch

http://fedoraproject.org/wiki/EPEL
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Package_maintenance_and_update_policy
Comment 22 Curtis Gedak 2013-10-10 17:02:20 UTC
Hi Mike and Phillip,

Thank you for sharing your thoughts on the issues involved upgrading
GParted gtkmm support.  After reading your comments I have come to the
following conclusions.


> Q1)  Should we drop support for gtkmm < 2.22 or go all the way
>      and drop support for gtkmm < 3.0?

Currently I think that dropping support for gtkmm < 2.22 should only
be an immediate stepping stone to full gtkmm 3.0 support.  My primary
reasons are:

  1)  The gtkmm 3.0 back ported cairo graphics stuff does not work.  As
      such we would have to keep gtkmm < 2.22 code in GParted anyway.
      Hence we would not be able to actually have a GParted release
      that contains code that strictly follows 2.22 < gtkmm < 3.0.

  2)  We would have to prematurely drop support for a major currently
      supported distro, namely RHEL/Centos if we drop gtkmm < 2.22
      support.  I believe it is best if GParted can compile and run on
      as many currently supported distros as is reasonably possible.


> Q2)  What timeframe should we target for the switch in order to
>      minimize the impact of switching?

My suggestion of mid-2014 for migrating off of gtkmm < 2.22 is only a
suggestion at this time.  I believe we should pick a date that
involves the least amount of inconvenience, and also minimizes the
amount of work we need to do with the GParted code.  Specifically I do
not think it is good use of our resources to support both gtkmm < 2.22
and gtkm >= 3.0 at the same time.

At the moment the GParted code compiles and runs on both the newer
distros and many older currently supported distros.  At some point in
time I believe that support for the gtkmm 2.x series will be dropped
and that will be a hard deadline that will force an upgrade in
GParted.

Having said that I think we can try to time our migration off of gtkmm
< 2.22 later rather than earlier.  If there were a compelling reason
to migrate to gtkmm 3.x earlier then we should consider this.  At the
current time I do not think that there are any specific new features
in gtkmm 3.0 that are "must haves" for GParted.

In addition, I do think we have some time before we are forced to
migrate from gtkmm < 2.22.  If I recall correctly, the GTK toolkit was
born out of the GIMP project.  From what I can tell, GIMP does not yet
support GTK 3.0, though there is a branch created for this future path
[1].  As such any distribution that wishes to support GIMP, will also
have to support GTK 2.x.  This gives me a level of comfort that
support for GTK 2.x will continue at least until GIMP makes the switch
to GTK 3.x.


> I3)  Suggest setup a gparted-1.0 git branch to hold patches and work
>      towards gparted 1.0.0.

I value both of your opinions, and since you appear to be in agreement
that a gparted 1.0.0 branch could work for preparing for an eventual
move off of gtkmm < 2.22, please feel free to create the branch.
Having such a branch would also be aligned with GIMP since they appear
to have created a GIMP 3.0 branch for future support of GTK 3.x.

Curtis


[1] GIMP Roadmap
    http://wiki.gimp.org/index.php/Roadmap
Comment 23 Mike Fleetwood 2013-10-11 19:21:02 UTC
Created attachment 257051 [details] [review]
Stop using deprecated method free_colors() (v1)

Hi Curtis and Phillip,

Here's a small first step.  Quoting the commit message:

    Stop using deprecated method free_colors() (#652044)

    Gtkmm releases 2.7.1 in July 2005 and 2.8 in September 2005 depreciated
    Gdk::Colormap::free_colors() and replaced it with
    Gdk::Colormap::free_color().  The oldest distribution currently
    supported is RHEL / CentOS 5.9 with gtkmm 2.10 so just unconditionally
    replace.

        ANNOUNCE: gtkmm 2.7.1
https://mail.gnome.org/archives/gnome-announce-list/2005-July/msg00025.html

        ANNOUNCE: gtkmm and glibmm 2.8
https://mail.gnome.org/archives/gnome-announce-list/2005-September/msg00026.html

I've successfully created, resize and viewed details of a partition on
CentOS 5.9.  It can be applied to the master branch now and is a small
step in reducing the difference to gparted-1.0.

Thanks,
Mike
Comment 24 Curtis Gedak 2013-10-15 16:37:13 UTC
Hi Mike and Phillip,

After making one minor change to the patch in comment #23 (typo "depreciated" -> "deprecated" in comment text), I successfully tested on the following distros:

    debian  6
    ubuntu 10.04
   kubuntu 12.04
  openSUSE 12.2

Because all of these distros use gtkmm > 2.8, I did not expect any problems.

Since the patch in comment #23 aligns with all of our current goals (small patch, works with all of our currently supported major distros, avoids need to support two or more gtkmm versions), I have committed the patch to the master branch of the GParted git repository.

The relevant git commit can be viewed at the following link:

Stop using deprecated method free_colors() (#652044)
https://git.gnome.org/browse/gparted/commit/?id=7f5ac07c3a5e7de3b900056122f8892f48735931

If there are any more deprecated APIs that are similar to this one, then these should be considered as well.

Curtis
Comment 25 Mike Fleetwood 2013-10-18 09:19:06 UTC
Created attachment 257624 [details] [review]
Stop using depreciated widget alignment enumerators (v1)

Hi Curtis and Phillip,

This is another step in reducing the difference to gparted-1.0.  It gets
rid of the use of deprecated alignment enumerators Gtk::ALIGN_LEFT etc.

Successfully tested on:
CentOS 5.9 with gtkmm-2.10.10
Debian 6 with gtkmm-2.20.3
Fedora 14 with gtkmm-2.22.0
Fedora 19 with gtkmm-2.24.2

Thanks,
Mike
Comment 26 Curtis Gedak 2013-10-18 20:18:56 UTC
Hi Mike and Phillip,

The patch set in comment #25 is an interesting solution to getting rid of the widget alignment enumerators by removing them as parameters from the method Utils::mk_label(), and instead hard coding floating values for the alignments directly in the method.

This works for now, and if we encounter problems in the future, we can always switch back to using the alignment enumerators in our migration to GTKMM 3.x.

Successfully tested on:
   debian  7.0
   ubuntu 10.04 LTS
  kubuntu 12.04 LTS
   ubuntu 13.04
   fedora 10 (this was the oldest VM I had for fedora, tho' not supported)

The patch set has been committed to the git repository.

The relevant git commits can be viewed at the following links:

Replace widget alignment ALIGN_TOP with ALIGN_CENTER (#652044)
https://git.gnome.org/browse/gparted/commit/?id=8b57278f67b38116faa27b9a5c67c8f43539d32d

Replace widget alignment ALIGN_RIGHT with ALIGN_LEFT (#652044)
https://git.gnome.org/browse/gparted/commit/?id=18e2eb86187df1aaba6fadb3c51dde95d26e2b4f

Stop using deprecated widget alignment enumerators (#652044)
https://git.gnome.org/browse/gparted/commit/?id=be2689ad25c104e3cb97e7d5d1f7627dbb137b19

Curtis
Comment 27 Curtis Gedak 2013-12-09 18:09:25 UTC
The patches from comment #23 and comment #25 that were committed in comment #26 have been included in the GParted 0.17.0 release on December 9, 2013.

Note that this bug report is still open because the above listed enhancements resolve only a portion of this report.
Comment 28 Curtis Gedak 2017-12-05 22:41:49 UTC
*** Bug 791286 has been marked as a duplicate of this bug. ***
Comment 29 Curtis Gedak 2017-12-06 16:55:23 UTC
'Just adding another concern we may have to program around if/when migration from gtkmm 2.x to 3.x is re-attempted.

I've read that GTK3 has been shown to break ABI compatibility between releases.  Following is one of the references I read:

Are GTK+ developers destroying Linux desktop with their plans?
https://fosspost.org/opinions/are-gtk-developers-destroying-linux-desktop-with-their-plans

In my opinion ABI compatibility is critically important, especially to a hobby project like GParted.  The instability of GTK3 makes me less than keen to attempt the migration again.
Comment 30 Jeremy Bicha 2017-12-06 17:09:57 UTC
Curtis, gtk3 is now in long-term stable support since 3.22 was released in September 2016. Therefore, this is a great time to switch to gtk3.

GTK4 is under active development, but I haven't found any apps using it so there's no reason to worry about it yet for gparted.

The post you linked to is based on outdated information. Here's an update:
https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/
Comment 31 Curtis Gedak 2017-12-06 18:18:21 UTC
Thanks Jeremy for the information.

From the link in comment #30:

    New major versions will be released once new features have
    stabilised, which is expected to be roughly every 2-3
    years. When bumping to a new major version deprecated API
    will be removed.

    ...

    We’ll also keep doing micro releases for bug fixes and
    security issues, for at least three years.

If I understand this correctly then there is the possibility that features may be disappearing as often as every 2-3 years.  For example features are marked deprecated in *major-release-version-minus-1* and then actually removed in **major-release-version**.  There could be a constant flow of deprecated features with every major release.  This proposal is nowhere near as stable as GTK2 has been.
Comment 32 Phillip Susi 2017-12-06 18:33:49 UTC
Yes, but you don't HAVE to switch to GTK4 as soon as it comes out.  This basically is a return to the same sane policy that they used to have of bumping the major number on incompatible changes, and not making such changes all that often.

It would be really nice to get gparted moved to GTK3 finally so it can run under Wayland directly without the Xwayland compatibility server.
Comment 33 Curtis Gedak 2017-12-06 18:53:07 UTC
In order to clarify, I did not say that GParted should not move to GTK3 or Wayland compatibility.  What I said is that the GTK3 ABI has not been as stable as GTK2, nor is the new proposal as stable as GTK2.

As stated on the GParted Development page [1]:

We try to ensure that the GParted will compile and run on the currently supported versions of many major GNU/Linux distributions (distros). Distros we often include in our testing include: Centos/RHEL, Debian, Fedora, openSUSE, and Ubuntu. 

[1]: https://gparted.org/development.php


We welcome patches to migrate to GTK3 / Wayland.
Comment 34 Jeremy Bicha 2017-12-06 19:17:44 UTC
> nor is the new proposal as stable as GTK2

I think it's clear that new major releases will not be as stable for app developers as bugfix releases to a long term support branch. ;)
Comment 35 Curtis Gedak 2017-12-06 19:42:46 UTC
By stable I mean not only does the ABI remain the same, but further the release is supported for many years.

To test the stability of GTK2 I fired up the oldest Virtual Machine I have (Fedora 12 released in 2009).  The current GParted 0.30.0 still compiles and runs on Fedora 12.  That demonstrates the long term ABI and support stability of GTK2.
Comment 36 Phillip Susi 2017-12-07 13:50:54 UTC
Not really Curtis; you will still be able to do that in 100 years since GTK2 is not being updated.  That doesn't mean it has had 100 years of stable support.
Comment 37 Curtis Gedak 2017-12-07 16:36:00 UTC
My point is the new GTK3+ proposal states support for a minimum of 3 years.  I think it is unreasonable to expect a hobby project to update to a new GUI every 3 years.
Comment 38 Jeremy Bicha 2017-12-07 16:44:43 UTC
Curtis, respectfully, I think the topic here should be limited to porting gparted to gtk3. If you have concerns about gtk's planned support length, please discuss that with gtk developers.

By the way, there have been no gtk2 bugfix releases since gtk 3.22's release. I think this is simply because no one cares enough to do the work. That's the same problem that will happen with future gtk releases. Unless someone is getting paid to support old gtk, it's hard for most qualified people to be interested in it.
Comment 39 Curtis Gedak 2017-12-07 16:48:50 UTC
Jememy, I raised the issue in comment #29 that GTK3 had broken the API between releases as a heads up to whoever undertakes the initiative to address this bug report.  In order to support older distros the person developing the patch may need to work around this ABI break.
Comment 40 Jeremy Bicha 2017-12-08 00:19:05 UTC
As long as you aren't trying to handle theming yourself, I think gtk3 probably won't cause problems for LTS distros.
Comment 41 Mike Fleetwood 2018-07-15 08:52:48 UTC
This bug has been migrated to GNOME's GitLab instance and has been
closed from further activity.

GParted | Port to GTK3
https://gitlab.gnome.org/GNOME/gparted/issues/7