Archive gtk2

[Bruce Dubbs]

We will probably not be able to close this ticket for 12.1, but I'll leave it in this milestone for now. I just removed a lot of unneeded references to gtk2, but there are a lot of packages still left. Please address only one package per comment below. This is what I have remaining:

multimedia/videoutils/mplayer.xml:   <xref linkend="gtk2"/>  recommended
multimedia/libdriv/libcanberra.xml:  <xref linkend="gtk2"/>, optional
multimedia/libdriv/libquicktime.xml: <xref linkend="gtk2"/>, optional
multimedia/libdriv/alsa-tools.xml:   <xref linkend="gtk2"/>  optional

general/genutils/ibus.xml:     <xref linkend="gtk2"/>, recommended
general/genutils/pinentry.xml: <xref linkend="gtk2"/>, optional
general/genutils/graphviz.xml: <xref linkend="gtk2"/>  optional+
general/genlib/libiodbc.xml:   <xref linkend="gtk2"/>  recommended(for GUI admin tool) 
general/graphlib/pixman.xml:   <xref linkend="gtk2"/>  optional
general/prog/python-modules/pygtk.xml: <xref linkend="gtk2"/>. required

x/lib/libglade.xml:    <xref linkend="gtk2"/> required
x/lib/colord-gtk.xml:  <xref linkend="gtk2"/> recommended
x/lib/gtk-engines.xml: <xref linkend="gtk2"/> required
x/lib/keybinder2.xml:  <xref linkend="gtk2"/> required
x/lib/cairo.xml:       <xref linkend="gtk3"/> and <xref linkend="gtk2"/>, optional
                       (why both?, arch does not mention gtk at all)

pst/ps/epdfview.xml:    <xref linkend="gtk2"/> required (archive this?)
pst/scanning/xsane.xml: <xref linkend="gtk2"/> required
pst/scanning/sane.xml:  <xref linkend="gtk2"/> optional

networking/netutils/avahi.xml: <xref linkend="gtk2"/> recommended (why?)

xsoft/other/gimp.xml:       <xref linkend="gtk2"/> required
xsoft/other/hexchat.xml:    <xref linkend="gtk2"/> recommended
xsoft/other/pidgin.xml:     <xref linkend="gtk2"/> required
kde/plasma5/plasma-all.xml: <xref linkend="gtk2"/> required (but probably not)

[Douglas R. Reno]

keybinder2 can be archived as it was only used by lxpanel.

[Douglas R. Reno]

For epdfview, we should consider moving to the gtk3 version that Ken found.

[Bruce Dubbs]

Replying to Douglas R. Reno:

For epdfview, we should consider moving to the gtk3 version that Ken found.

I was thinking of just archiving it. We have mupdf. Isn't that enough?

[Douglas R. Reno]

For avahi, I looked at the docs/README file, and I found:

   - gtk2 + glade (optional, needed for avahi-discover-standalone)
   - Python 2.4, pygtk2 (optional, needed by all client tools)

avahi-ui.pc has the following:

prefix=@prefix@
exec_prefix=${prefix}
libdir=@libdir@
includedir=${prefix}/include

Name: avahi-ui
Description: Avahi Multicast DNS Responder (Common GTK2 UI support)
Requires: gtk+-2.0 avahi-client avahi-glib
Version: @PACKAGE_VERSION@
Libs: -L${libdir} -lavahi-ui
Cflags: -D_REENTRANT -I${includedir}

There is a GTK-3 version, but I'm not sure what in the book is using GTK2 for this over GTK3. Keep in mind that we might have some dependencies where gtk2 is not mentioned because of another library, e.g. libglade or pygtk, which brings it in.

As a result of that, we need to add the following to the list:

xsoft/other/xscreensaver.xml:      <xref linkend="libglade"/>, and
xsoft/other/rox-filer.xml:      <xref linkend="libglade"/> and
(another hit for graphviz)
(another hit for avahi)
x/wm/openbox.xml:        and <xref linkend="pygtk"/>).

[Douglas R. Reno]

Replying to Bruce Dubbs:

Replying to Douglas R. Reno:

For epdfview, we should consider moving to the gtk3 version that Ken found.

I was thinking of just archiving it. We have mupdf. Isn't that enough?

mupdf is almost impossible to use for this purpose. There is no scrollbar and it's interface is nonexistent other than just the page itself. There's no support for a table of contents, and it can only be navigated with the arrow keys

[Douglas R. Reno]

When it comes to gtk-engines, that can be archived at the same time as gtk2. It provides a bunch of core themes for it.

[Douglas R. Reno]

For Cairo, I'm not sure what exactly uses GTK there, but the configure script does mention it (and there's hits throughout Makefiles):

  GOBJECT_CFLAGS
              C compiler flags for GOBJECT, overriding pkg-config
  GOBJECT_LIBS
              linker flags for GOBJECT, overriding pkg-config
  glib_CFLAGS C compiler flags for glib, overriding pkg-config
  glib_LIBS   linker flags for glib, overriding pkg-config
  gtk_CFLAGS  C compiler flags for gtk, overriding pkg-config
  gtk_LIBS    linker flags for gtk, overriding pkg-config

It also mentions later on (line 29830):

# We use GTK+ for some utility/debugging tools

I also don't notice any hits for gtk+-3.0 in there, though there are plenty of hits for gtk+-2.0

[ken@…]

Replying to Douglas R. Reno:

Replying to Bruce Dubbs:

Replying to Douglas R. Reno:

For epdfview, we should consider moving to the gtk3 version that Ken found.

I was thinking of just archiving it. We have mupdf. Isn't that enough?

mupdf is almost impossible to use for this purpose. There is no scrollbar and it's interface is nonexistent other than just the page itself. There's no support for a table of contents, and it can only be navigated with the arrow keys

Very much agreed - mupdf is usable for looking at a pdf with one or two pages, but for anything else it is horrid.

[Bruce Dubbs]

Replying to ken@…:

Replying to Douglas R. Reno:

Replying to Bruce Dubbs:

Replying to Douglas R. Reno:

For epdfview, we should consider moving to the gtk3 version that Ken found.

I was thinking of just archiving it. We have mupdf. Isn't that enough?

mupdf is almost impossible to use for this purpose. There is no scrollbar and it's interface is nonexistent other than just the page itself. There's no support for a table of contents, and it can only be navigated with the arrow keys

Very much agreed - mupdf is usable for looking at a pdf with one or two pages, but for anything else it is horrid.

But there is also evince, okular, and firefox that can read large pdfs.

[Douglas R. Reno]

pst/scanning/xsane.xml: <xref linkend="gtk2"/> required

pst/scanning/sane.xml: <xref linkend="gtk2"/> optional

• Created #18532 to add Simple Scan and archive XSane and sane-frontends. There are some concerns regarding network scanning though that may cause us to be unable to get away from XSane/sane-frontends, but I will investigate this soon.

[ken@…]

Replying to Bruce Dubbs:

Replying to ken@…:

Replying to Douglas R. Reno:

Replying to Bruce Dubbs:

Replying to Douglas R. Reno:

For epdfview, we should consider moving to the gtk3 version that Ken found.

I was thinking of just archiving it. We have mupdf. Isn't that enough?

mupdf is almost impossible to use for this purpose. There is no scrollbar and it's interface is nonexistent other than just the page itself. There's no support for a table of contents, and it can only be navigated with the arrow keys

Very much agreed - mupdf is usable for looking at a pdf with one or two pages, but for anything else it is horrid.

But there is also evince, okular, and firefox that can read large pdfs.

Evince has a much heavier dependency chain (I build enough of gnome to allow me to build evince, but much later in a build, and it lacks a 'reload' option). I gave up building okular because the dependencies of KDE are just too heavy. Firefox works, but I do not really want it on the same desktop where I am creating and editing PDFs - I've already got firefox on a different desktop with multiple tabs open, I like to open a PDF next to the term where I've been editing it, and swap back between them.

[Rahul Chandra]

Evince has a much heavier dependency chain (I build enough of gnome to allow me to build evince, but much later in a build, and it lacks a 'reload' option). I gave up building okular because the dependencies of KDE are just too heavy. Firefox works, but I do not really want it on the same desktop where I am creating and editing PDFs - I've already got firefox on a different desktop with multiple tabs open, I like to open a PDF next to the term where I've been editing it, and swap back between them.

I'm with you on that one, both okular and evince are a small part of fully featured desktop environment, and they aren't really meant to be used standalone. We should have a standalone pdf reader, epdf gtk3 seems good for that.

[Rahul Chandra]

Colord-gtk can have gtk2 disabled with minimal regression. In fact the default is to turn it off. Should we do this?

[Douglas R. Reno]

Replying to Rahul Chandra:

Colord-gtk can have gtk2 disabled with minimal regression. In fact the default is to turn it off. Should we do this?

I think -Dgtk2=true should be changed to false here, with the command explanation being tweaked and GTK2 downgraded to Optional

An alternative would be to remove the dependency from the page entirely as well as the option, the command explanation, and the library... but I'm not entirely sure if we want to go that far yet.

[Rahul Chandra]

For IRC client I think Srain works pretty well, ​https://github.com/SrainApp/srain. It requires libconfig but that's a pretty simple build. Should I open a ticket to add those?

Edit: That would allow us to archive pidgin and hexchat, both of which are completely written in gtk2

[Rahul Chandra]

Replying to Douglas R. Reno:

Replying to Rahul Chandra:

Colord-gtk can have gtk2 disabled with minimal regression. In fact the default is to turn it off. Should we do this?

I think -Dgtk2=true should be changed to false here, with the command explanation being tweaked and GTK2 downgraded to Optional

An alternative would be to remove the dependency from the page entirely as well as the option, the command explanation, and the library... but I'm not entirely sure if we want to go that far yet.

Yeah making it an optional dependency is probably the best thing to do. At the end we can just remove all optional gtk2 references.

[Bruce Dubbs]

Replying to Douglas R. Reno:

Replying to Rahul Chandra:

Colord-gtk can have gtk2 disabled with minimal regression. In fact the default is to turn it off. Should we do this?

I think -Dgtk2=true should be changed to false here, with the command explanation being tweaked and GTK2 downgraded to Optional

An alternative would be to remove the dependency from the page entirely as well as the option, the command explanation, and the library... but I'm not entirely sure if we want to go that far yet.

Let's go ahead and remove the dependency from the page and the instructions. For the command explanations, leave it in and add that gtk2 is deprecated.

[Douglas R. Reno]

Hexchat is relatively concerning. There seems to be no motivation for upstream to move to gtk3 or higher, and upstream gets hostile when queried about it. ​https://github.com/hexchat/hexchat/issues/2047

We will definitely have to find another IRC client.

[Douglas R. Reno]

Pidgin is still in active maintenance and is getting commits several times a week: ​https://keep.imfreedom.org/pidgin/pidgin/shortlog/default

The 'default' branch is their gtk-3 port

[Douglas R. Reno]

Replying to Rahul Chandra:

For IRC client I think Srain works pretty well, ​https://github.com/SrainApp/srain. It requires libconfig but that's a pretty simple build. Should I open a ticket to add those?

Edit: That would allow us to archive pidgin and hexchat, both of which are completely written in gtk2

We can take a look at srain, and I have no problems adding it to the book if we decide to go with it. I would prefer if just Hexchat is archived in that case though. Pidgin is at least still progressing rapidly towards a gtk-3 port and an API refresh. Pidgin however used a lot of custom widgets - it's similar to another program that I use regularly, gkrellm. The only difference though is that gkrellm probably won't get converted (and Bruce and I both will eventually have to move to something else for that), but Pidgin is at least being moved.

[Douglas R. Reno]

Replying to Bruce Dubbs:

Replying to Douglas R. Reno:

Replying to Rahul Chandra:

Colord-gtk can have gtk2 disabled with minimal regression. In fact the default is to turn it off. Should we do this?

I think -Dgtk2=true should be changed to false here, with the command explanation being tweaked and GTK2 downgraded to Optional

An alternative would be to remove the dependency from the page entirely as well as the option, the command explanation, and the library... but I'm not entirely sure if we want to go that far yet.

Let's go ahead and remove the dependency from the page and the instructions. For the command explanations, leave it in and add that gtk2 is deprecated.

That sounds good. We should remove it from the Short Descriptions/Installed Files as well in that case, as well as the instruction/dependency changes.

[Bruce Dubbs]

Replying to Douglas R. Reno:

Replying to Rahul Chandra:

For IRC client I think Srain works pretty well, ​https://github.com/SrainApp/srain. It requires libconfig but that's a pretty simple build. Should I open a ticket to add those?

Edit: That would allow us to archive pidgin and hexchat, both of which are completely written in gtk2

We can take a look at srain, and I have no problems adding it to the book if we decide to go with it. I would prefer if just Hexchat is archived in that case though. Pidgin is at least still progressing rapidly towards a gtk-3 port and an API refresh. Pidgin however used a lot of custom widgets - it's similar to another program that I use regularly, gkrellm. The only difference though is that gkrellm probably won't get converted (and Bruce and I both will eventually have to move to something else for that), but Pidgin is at least being moved.

I took a look at my gtk+ book last night. Unfortunately it was published in 2007 and only covered gtk2. I looked at Amazon and could not find an equivalent for gtk3 (or 4).

My programming experience is more with Qt, but that is dated all the way back to Qt4. I would like to do a gkrellm port to Qt but I think that would take too much time away from LFS. OTOH, srain sounds like a good possibility for an IRC substitute and we should investigate.

[Rahul Chandra]

Replying to Bruce Dubbs:

Replying to Douglas R. Reno:

Replying to Rahul Chandra:

Colord-gtk can have gtk2 disabled with minimal regression. In fact the default is to turn it off. Should we do this?

I think -Dgtk2=true should be changed to false here, with the command explanation being tweaked and GTK2 downgraded to Optional

An alternative would be to remove the dependency from the page entirely as well as the option, the command explanation, and the library... but I'm not entirely sure if we want to go that far yet.

Let's go ahead and remove the dependency from the page and the instructions. For the command explanations, leave it in and add that gtk2 is deprecated.

Fixed @ fbd6311c31ba486e8e66d3d3c6c8de86ab2ab1ae

[Xi Ruoyao]

For IRC I'm using ​irssi. It's using a ncursesw-based TUI and the only non-LFS dependency is glib2.

[ken@…]

Replying to Rahul Chandra:

Evince has a much heavier dependency chain (I build enough of gnome to allow me to build evince, but much later in a build, and it lacks a 'reload' option). I gave up building okular because the dependencies of KDE are just too heavy. Firefox works, but I do not really want it on the same desktop where I am creating and editing PDFs - I've already got firefox on a different desktop with multiple tabs open, I like to open a PDF next to the term where I've been editing it, and swap back between them.

I'm with you on that one, both okular and evince are a small part of fully featured desktop environment, and they aren't really meant to be used standalone. We should have a standalone pdf reader, epdf gtk3 seems good for that.

It turned out I was mistaken when I said epdfview-gtk3 doesn't have options to go to next or specific page - they were in the toolbar which doesn't come up by default on any of my systems. After trying without the menu (bad idea - it now defaults to off on this machine) I had to read the source - and there are toggles (in the view menu, but it saves settings so I don't normally need to use that) - F6 for toolbar, F7 for menubar, F8 for inverse, F9 for index. Printing now tested, as well as going to a specific page

[Douglas R. Reno]

pst/scanning/xsane.xml: Archived at 1032bfd660955f41fcdd3183d34a0b6145728408

[Douglas R. Reno]

pst/scanning/sane.xml (SANE Frontends): Commented out/removed at 6646cae6c19f490fc88d8afff0c1c262daef2277

[Xi Ruoyao]

Now it seems clear this won't happen for 12.1. Change the milestone.

[Bruce Dubbs]

Plasma no longer needs gtk2. I'm not sure if it is used if present. The breeze icon theme does install some files in /opt/kf5/share/themesBreeze-Dark/gtk-2.0 on my system.