Skip to contentSkip to conversation

Kconfig Gtk/Qt interface flavours ported to newest toolkit versions

PATCH In review davidgraeff 4 participants 15 messages Jul 2, 2013 – Jul 13, 2013

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

Hello all,

I've no idea if this is the right way to send patches. I'm kind of new to this. Attached is a patchset basically for porting the graphical Gtk and Qt flavours to their latest toolkit versions (Gtk3 and Qt4 with compatibility to Qt5 respectively). It took a day or so to get into the code -> Newly inserted and changed source code is commented in many/some places now.

I do not know if it was on purpose to keep all flavours except lxdialog in one single directory, but for presumably easier maintenance the first patch split of each flavours into its own subdirectory. Additionally I ripped out flavour specific makefile targets. Each subdirectory contains a separate makefile now.
An advantage is a more simple makefile for e.g. all the C++/Qt stuff, where Qt specific moc and uic tools are necessary.

The 2nd to 6th patch port the Gtk2 ui to the modern Gtk3 toolkit including the conversion from a libglade (deprecated) interface to a gtkbuilder interface.

The 7th to 9th patch port the Qt3/Qt4+Qt3support ui to the current version 4 of the Qt toolkit. The gui is no longer realised by handwritten c++ code but by the Qt Designer for a much easier user interface design and less code.
The Model/View concept of Qt is heavily used and no Qt3 support classes are used anymore, as a result the code should work with the newest Qt5, too.

Those newer graphical kconfig flavours will be used by a project I'm involved in so I will maintain it for the next couple of months.

If I did anything wrong, please instruct me or provide me a link please.

- David -

#1 lore raw

PATCH 2/9 kconfig: Update gtk interface codebase.

Use only non-deprecated functions, use accessor functions instead of direct access. A port to gtk3 should be easy now.

---
 scripts/kconfig/gconfig/Makefile |   4 +-
 scripts/kconfig/gconfig/gconf.c  | 177 +++++++++++++--------------------------
 2 files changed, 63 insertions(+), 118 deletions(-)
scripts/kconfig/gconfig/Makefile +3 -1
index 1ce47a6..cf0c32b 100644
@@ -28,7 +28,9 @@ clean-files	+= zconf.tab.c gconfig/gconf.glade.h gconf
 
 HOSTLOADLIBES_gconf	= `pkg-config --libs gtk+-2.0 gmodule-2.0 libglade-2.0`
 HOSTCFLAGS_gconf.o	= `pkg-config --cflags gtk+-2.0 gmodule-2.0 libglade-2.0` \
-                          -Wno-missing-prototypes
+                          -Wno-missing-prototypes -DGTK_DISABLE_SINGLE_INCLUDES \
+                          -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED \
+                          -DGSEAL_ENABLE
 
 $(obj)/gconfig/gconf.o: $(obj)/gconfig/.tmp_gtkcheck
 
scripts/kconfig/gconfig/gconf.c +60 -117

265 lines not on this page · raw message

Signature · 1 line
1.8.1.2
#2 lore raw

PATCH 3/9 kconfig: gtk interface port to Gtk3

In reply to davidgraeff

libglade is deprecated: use GtkBuilder and ui files instead. Remove some global variables.
Use new gtk signals.

---
 scripts/kconfig/POTFILES.in         |   2 +-
 scripts/kconfig/gconfig/Makefile    |  14 +-
 scripts/kconfig/gconfig/gconf.c     | 416 +++++++++++------------
 scripts/kconfig/gconfig/gconf.glade | 661 ------------------------------------
 scripts/kconfig/gconfig/gconf.ui    | 534 +++++++++++++++++++++++++++++
 5 files changed, 741 insertions(+), 886 deletions(-)
 delete mode 100644 scripts/kconfig/gconfig/gconf.glade
 create mode 100644 scripts/kconfig/gconfig/gconf.ui
scripts/kconfig/POTFILES.in +1 -1
index 4984825..2e44446 100644
@@ -6,7 +6,7 @@ scripts/kconfig/lxdialog/util.c
 scripts/kconfig/lxdialog/yesno.c
 scripts/kconfig/lxdialog/mconf.c
 scripts/kconfig/gkonfig/gconf.c
-scripts/kconfig/gkonfig/gconf.glade.h
+[type: gettext/glade]scripts/kconfig/gkonfig/gconf.ui
 scripts/kconfig/qconfig/qconf.cc
 scripts/kconfig/conf.c
 scripts/kconfig/confdata.c
scripts/kconfig/gconfig/Makefile +7 -7
index cf0c32b..282c500 100644
@@ -26,8 +26,8 @@ endif
 clean-files	+= zconf.tab.c gconfig/gconf.glade.h gconf
 
 
-HOSTLOADLIBES_gconf	= `pkg-config --libs gtk+-2.0 gmodule-2.0 libglade-2.0`
-HOSTCFLAGS_gconf.o	= `pkg-config --cflags gtk+-2.0 gmodule-2.0 libglade-2.0` \
+HOSTLOADLIBES_gconf	= `pkg-config --libs gtk+-3.0 gmodule-2.0`
+HOSTCFLAGS_gconf.o	= `pkg-config --cflags gtk+-3.0 gmodule-2.0` \
                           -Wno-missing-prototypes -DGTK_DISABLE_SINGLE_INCLUDES \
                           -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED \
                           -DGSEAL_ENABLE
@@ -39,20 +39,20 @@ ifeq ($(gconf-target),1)
 
 # GTK needs some extra effort, too...
 $(obj)/gconfig/.tmp_gtkcheck:
-	@if `pkg-config --exists gtk+-2.0 gmodule-2.0 libglade-2.0`; then		\
-		if `pkg-config --atleast-version=2.0.0 gtk+-2.0`; then			\
+	@if `pkg-config --exists gtk+-3.0`; then		\
+		if `pkg-config --atleast-version=3.0.0 gtk+-3.0`; then			\
 			touch $@;								\
 		else									\
 			echo >&2 "*"; 							\
-			echo >&2 "* GTK+ is present but version >= 2.0.0 is required.";	\
+			echo >&2 "* GTK+ is present but version >= 3.0.0 is required.";	\
 			echo >&2 "*";							\
 			false;								\
 		fi									\
 	else										\
 		echo >&2 "*"; 								\
 		echo >&2 "* Unable to find the GTK+ installation. Please make sure that"; 	\
-		echo >&2 "* the GTK+ 2.0 development package is correctly installed..."; 	\
-		echo >&2 "* You need gtk+-2.0, glib-2.0 and libglade-2.0."; 		\
+		echo >&2 "* the GTK+ 3.0 development package is correctly installed..."; 	\
+		echo >&2 "* You need gtk+-3.0 and glib-2.0."; 		\
 		echo >&2 "*"; 								\
 		false;									\
 	fi
scripts/kconfig/gconfig/gconf.c +199 -217

844 lines not on this page · raw message

scripts/kconfig/gconfig/gconf.glade deleted +0 -661

661 lines not on this page · raw message

scripts/kconfig/gconfig/gconf.ui new file +534 -0

534 lines not on this page · raw message

Signature · 1 line
1.8.1.2
#3 lore raw

PATCH 4/9 kconfig: gtk interface: fix splitview, split code into two files

In reply to davidgraeff

Split code into gconf.c and gconf_treeview_model. gconf.c now only contains ui init and ui signal callback code, all tree/model code is in the second file.

Issues with split view are fixed.

---
 scripts/kconfig/gconfig/Makefile               |   10 +-
 scripts/kconfig/gconfig/gconf.c                | 1103 +++++-------------------
 scripts/kconfig/gconfig/gconf.h                |   80 ++
 scripts/kconfig/gconfig/gconf.ui               |   16 +-
 scripts/kconfig/gconfig/gconf_treeview_model.c |  714 +++++++++++++++
 scripts/kconfig/gconfig/gconf_treeview_model.h |   43 +
 scripts/kconfig/gconfig/util.h                 |   33 +
 7 files changed, 1082 insertions(+), 917 deletions(-)
 create mode 100644 scripts/kconfig/gconfig/gconf.h
 create mode 100644 scripts/kconfig/gconfig/gconf_treeview_model.c
 create mode 100644 scripts/kconfig/gconfig/gconf_treeview_model.h
 create mode 100644 scripts/kconfig/gconfig/util.h
scripts/kconfig/gconfig/Makefile +7 -3
index 282c500..f2ca18e 100644
@@ -13,7 +13,7 @@ gconfig: $(obj)/gconf
 #         Based on GTK which needs to be installed to compile it
 # object files used by all kconfig flavours listed above
 
-gconf-objs	:= gconfig/gconf.o zconf.tab.o
+gconf-objs	:= gconfig/gconf.o gconfig/gconf_treeview_model.o zconf.tab.o
 
 ifeq ($(MAKECMDGOALS),gconfig)
 	gconf-target := 1
@@ -30,8 +30,12 @@ HOSTLOADLIBES_gconf	= `pkg-config --libs gtk+-3.0 gmodule-2.0`
 HOSTCFLAGS_gconf.o	= `pkg-config --cflags gtk+-3.0 gmodule-2.0` \
                           -Wno-missing-prototypes -DGTK_DISABLE_SINGLE_INCLUDES \
                           -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED \
-                          -DGSEAL_ENABLE
-
+                          -DGSEAL_ENABLE -std=c99
+HOSTCFLAGS_gconf_treeview_model.o	= `pkg-config --cflags gtk+-3.0 gmodule-2.0` \
+                          -Wno-missing-prototypes -DGTK_DISABLE_SINGLE_INCLUDES \
+                          -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED \
+                          -DGSEAL_ENABLE -std=c99
+                          
 $(obj)/gconfig/gconf.o: $(obj)/gconfig/.tmp_gtkcheck
 
 ifeq ($(gconf-target),1)
scripts/kconfig/gconfig/gconf.c +196 -907

1,390 lines not on this page · raw message

scripts/kconfig/gconfig/gconf.h new file +80 -0

81 lines not on this page · raw message

scripts/kconfig/gconfig/gconf.ui +9 -7
index 6aa29f7..0effd9f 100644
@@ -19,7 +19,7 @@
     <property name="can_focus">False</property>
     <property name="title" translatable="yes">Gtk Kernel Configurator</property>
     <property name="default_width">640</property>
-    <property name="default_height">250</property>
+    <property name="default_height">480</property>
     <signal name="destroy" handler="on_window1_destroy" swapped="no"/>
     <signal name="delete-event" handler="on_window1_delete_event" swapped="no"/>
     <child>
@@ -437,17 +437,18 @@
                 <property name="width_request">100</property>
                 <property name="visible">True</property>
                 <property name="can_focus">False</property>
-                <property name="margin_right">3</property>
+                <property name="margin_left">3</property>
                 <property name="shadow_type">in</property>
                 <property name="min_content_width">150</property>
                 <child>
                   <object class="GtkTreeView" id="treeview1">
+                    <property name="width_request">100</property>
                     <property name="visible">True</property>
                     <property name="can_focus">True</property>
-                    <property name="events">GDK_BUTTON_PRESS_MASK | GDK_KEY_PRESS_MASK | GDK_STRUCTURE_MASK</property>
+                    <property name="events">GDK_BUTTON_PRESS_MASK | GDK_KEY_PRESS_MASK</property>
                     <property name="headers_clickable">False</property>
                     <property name="enable_search">False</property>
-                    <signal name="key-press-event" handler="on_treeview2_key_press_event" swapped="no"/>
+                    <signal name="key-press-event" handler="on_treeviews_key_press_event" swapped="no"/>
                     <child internal-child="selection">
                       <object class="GtkTreeSelection" id="treeview-selection3">
                         <signal name="changed" handler="on_treeview1_selection_changed" swapped="no"/>
@@ -465,7 +466,7 @@
               <object class="GtkVPaned" id="vpaned1">
                 <property name="visible">True</property>
                 <property name="can_focus">True</property>
-                <property name="margin_left">3</property>
+                <property name="margin_right">3</property>
                 <property name="hexpand">True</property>
                 <child>
                   <object class="GtkScrolledWindow" id="scrolledwindow2">
@@ -476,10 +477,10 @@
                       <object class="GtkTreeView" id="treeview2">
                         <property name="visible">True</property>
                         <property name="can_focus">True</property>
-                        <property name="events">GDK_BUTTON_PRESS_MASK | GDK_KEY_PRESS_MASK | GDK_STRUCTURE_MASK</property>
+                        <property name="events">GDK_BUTTON_PRESS_MASK | GDK_KEY_PRESS_MASK</property>
                         <property name="enable_search">False</property>
                         <signal name="button-press-event" handler="on_treeview2_button_press_event" swapped="no"/>
-                        <signal name="key-press-event" handler="on_treeview2_key_press_event" swapped="no"/>
+                        <signal name="key-press-event" handler="on_treeviews_key_press_event" swapped="no"/>
                         <child internal-child="selection">
                           <object class="GtkTreeSelection" id="treeview-selection4">
                             <signal name="changed" handler="on_treeview2_selection_changed" swapped="no"/>
@@ -500,6 +501,7 @@
                     <property name="can_focus">False</property>
                     <property name="hscrollbar_policy">never</property>
                     <property name="shadow_type">in</property>
+                    <property name="min_content_height">80</property>
                     <child>
                       <object class="GtkTextView" id="textview3">
                         <property name="visible">True</property>
scripts/kconfig/gconfig/gconf_treeview_model.c new file +714 -0

714 lines not on this page · raw message

scripts/kconfig/gconfig/gconf_treeview_model.h new file +43 -0

43 lines not on this page · raw message

scripts/kconfig/gconfig/util.h new file +33 -0
new file mode 100644
index 0000000..876ec26
@@ -0,0 +1,33 @@
+ 
+/* Helping/Debugging Functions */
+
+#define bzero(b,len) (memset((b), '\0', (len)), (void) 0)
+const char *dbg_sym_flags(int val)
+{
+	static char buf[256];
+
+	bzero(buf, 256);
+
+	if (val & SYMBOL_CONST)
+		strcat(buf, "const/");
+	if (val & SYMBOL_CHECK)
+		strcat(buf, "check/");
+	if (val & SYMBOL_CHOICE)
+		strcat(buf, "choice/");
+	if (val & SYMBOL_CHOICEVAL)
+		strcat(buf, "choiceval/");
+	if (val & SYMBOL_VALID)
+		strcat(buf, "valid/");
+	if (val & SYMBOL_OPTIONAL)
+		strcat(buf, "optional/");
+	if (val & SYMBOL_WRITE)
+		strcat(buf, "write/");
+	if (val & SYMBOL_CHANGED)
+		strcat(buf, "changed/");
+	if (val & SYMBOL_AUTO)
+		strcat(buf, "auto/");
+
+	buf[strlen(buf) - 1] = '\0';
+
+	return buf;
+}
Signature · 1 line
1.8.1.2
#4 lore raw

PATCH 5/9 kconfig: images.c for gtk/qt gui flavour reoganized

In reply to davidgraeff

Change order of xpm image constants to build up groups. Make those groups optional via ifdefs.

---
 scripts/kconfig/images.c | 309 ++++++++++++++++++++++++-----------------------
 1 file changed, 161 insertions(+), 148 deletions(-)
scripts/kconfig/images.c +161 -148
index d4f84bd..c8563d9 100644
@@ -3,6 +3,166 @@
  * Released under the terms of the GNU GPL v2.0.
  */
 
+#ifdef IMAGES_TOOLBAR
+static const char *xpm_tree_view[] = {
+"22 22 2 1",
+". c None",
+"# c #000000",
+"......................",
+"......................",
+"......#...............",
+"......#...............",
+"......#...............",
+"......#...............",
+"......#...............",
+"......########........",
+"......#...............",
+"......#...............",
+"......#...............",
+"......#...............",
+"......#...............",
+"......########........",
+"......#...............",
+"......#...............",
+"......#...............",
+"......#...............",
+"......#...............",
+"......########........",
+"......................",
+"......................"};
+
+static const char *xpm_single_view[] = {
+"22 22 2 1",
+". c None",
+"# c #000000",
+"......................",
+"......................",
+"..........#...........",
+"..........#...........",
+"..........#...........",
+"..........#...........",
+"..........#...........",
+"..........#...........",
+"..........#...........",
+"..........#...........",
+"..........#...........",
+"..........#...........",
+"..........#...........",
+"..........#...........",
+"..........#...........",
+"..........#...........",
+"..........#...........",
+"..........#...........",
+"..........#...........",
+"..........#...........",
+"......................",
+"......................"};
+
+static const char *xpm_split_view[] = {
+"22 22 2 1",
+". c None",
+"# c #000000",
+"......................",
+"......................",
+"......#......#........",
+"......#......#........",
+"......#......#........",
+"......#......#........",
+"......#......#........",
+"......#......#........",
+"......#......#........",
+"......#......#........",
+"......#......#........",
+"......#......#........",
+"......#......#........",
+"......#......#........",
+"......#......#........",
+"......#......#........",
+"......#......#........",
+"......#......#........",
+"......#......#........",
+"......#......#........",
+"......................",
+"......................"};
+#endif
+
+#ifdef IMAGES_TREEVIEW
+static const char *xpm_void[] = {
+"12 12 2 1",
+"  c white",
+". c black",
+"            ",
+"            ",
+"            ",
+"            ",
+"            ",
+"            ",
+"            ",
+"            ",
+"            ",
+"            ",
+"            ",
+"            "};
+
+static const char *xpm_menu[] = {
+"12 12 2 1",
+"  c white",
+". c black",
+"            ",
+" .......... ",
+" .        . ",
+" . ..     . ",
+" . ....   . ",
+" . ...... . ",
+" . ...... . ",
+" . ....   . ",
+" . ..     . ",
+" .        . ",
+" .......... ",
+"            "};
+#endif
+
+/* Most images are taken from the system icon theme
+   in modern gui toolkits nowadays.
+   Because we compile with -Wunused-variable, we hide
+   the following xmp image constants.
+*/
+#ifdef IMAGES_EXTENDED
+
+static const char *xpm_menu_inv[] = {
+"12 12 2 1",
+"  c white",
+". c black",
+"            ",
+" .......... ",
+" .......... ",
+" ..  ...... ",
+" ..    .... ",
+" ..      .. ",
+" ..      .. ",
+" ..    .... ",
+" ..  ...... ",
+" .......... ",
+" .......... ",
+"            "};
+
+static const char *xpm_menuback[] = {
+"12 12 2 1",
+"  c white",
+". c black",
+"            ",
+" .......... ",
+" .        . ",
+" .     .. . ",
+" .   .... . ",
+" . ...... . ",
+" . ...... . ",
+" .   .... . ",
+" .     .. . ",
+" .        . ",
+" .......... ",
+"            "};
+
 static const char *xpm_load[] = {
 "22 22 5 1",
 ". c None",
@@ -91,86 +251,6 @@ static const char *xpm_back[] = {
 "......................",
 "......................"};
 
-static const char *xpm_tree_view[] = {
-"22 22 2 1",
-". c None",
-"# c #000000",
-"......................",
-"......................",
-"......#...............",
-"......#...............",
-"......#...............",
-"......#...............",
-"......#...............",
-"......########........",
-"......#...............",
-"......#...............",
-"......#...............",
-"......#...............",
-"......#...............",
-"......########........",
-"......#...............",
-"......#...............",
-"......#...............",
-"......#...............",
-"......#...............",
-"......########........",
-"......................",
-"......................"};
-
-static const char *xpm_single_view[] = {
-"22 22 2 1",
-". c None",
-"# c #000000",
-"......................",
-"......................",
-"..........#...........",
-"..........#...........",
-"..........#...........",
-"..........#...........",
-"..........#...........",
-"..........#...........",
-"..........#...........",
-"..........#...........",
-"..........#...........",
-"..........#...........",
-"..........#...........",
-"..........#...........",
-"..........#...........",
-"..........#...........",
-"..........#...........",
-"..........#...........",
-"..........#...........",
-"..........#...........",
-"......................",
-"......................"};
-
-static const char *xpm_split_view[] = {
-"22 22 2 1",
-". c None",
-"# c #000000",
-"......................",
-"......................",
-"......#......#........",
-"......#......#........",
-"......#......#........",
-"......#......#........",
-"......#......#........",
-"......#......#........",
-"......#......#........",
-"......#......#........",
-"......#......#........",
-"......#......#........",
-"......#......#........",
-"......#......#........",
-"......#......#........",
-"......#......#........",
-"......#......#........",
-"......#......#........",
-"......#......#........",
-"......#......#........",
-"......................",
-"......................"};
 
 static const char *xpm_symbol_no[] = {
 "12 12 2 1",
@@ -256,71 +336,4 @@ static const char *xpm_choice_yes[] = {
 "  ..    ..  ",
 "    ....    ",
 "            "};
-
-static const char *xpm_menu[] = {
-"12 12 2 1",
-"  c white",
-". c black",
-"            ",
-" .......... ",
-" .        . ",
-" . ..     . ",
-" . ....   . ",
-" . ...... . ",
-" . ...... . ",
-" . ....   . ",
-" . ..     . ",
-" .        . ",
-" .......... ",
-"            "};
-
-static const char *xpm_menu_inv[] = {
-"12 12 2 1",
-"  c white",
-". c black",
-"            ",
-" .......... ",
-" .......... ",
-" ..  ...... ",
-" ..    .... ",
-" ..      .. ",
-" ..      .. ",
-" ..    .... ",
-" ..  ...... ",
-" .......... ",
-" .......... ",
-"            "};
-
-static const char *xpm_menuback[] = {
-"12 12 2 1",
-"  c white",
-". c black",
-"            ",
-" .......... ",
-" .        . ",
-" .     .. . ",
-" .   .... . ",
-" . ...... . ",
-" . ...... . ",
-" .   .... . ",
-" .     .. . ",
-" .        . ",
-" .......... ",
-"            "};
-
-static const char *xpm_void[] = {
-"12 12 2 1",
-"  c white",
-". c black",
-"            ",
-"            ",
-"            ",
-"            ",
-"            ",
-"            ",
-"            ",
-"            ",
-"            ",
-"            ",
-"            ",
-"            "};
+#endif
Signature · 1 line
1.8.1.2
#5 lore raw

PATCH 6/9 kconf: gtk: move relayout code out of a loop

In reply to davidgraeff
---
 scripts/kconfig/gconfig/gconf.c                |    2 +
 scripts/kconfig/gconfig/gconf_treeview_model.c |   10 +-
 scripts/kconfig/qconfig/qconf.cc               | 1768 ------------------------
 scripts/kconfig/qconfig/qconf.cpp              | 1768 ++++++++++++++++++++++++
 4 files changed, 1771 insertions(+), 1777 deletions(-)
 delete mode 100644 scripts/kconfig/qconfig/qconf.cc
 create mode 100644 scripts/kconfig/qconfig/qconf.cpp
scripts/kconfig/gconfig/gconf.c +2 -0
index 9d7825e..dec1983 100644
@@ -114,6 +114,7 @@ void show_data(void)
 		case SINGLE_VIEW:
 			gtk_widget_hide(gconfwindow.tree1_w);
 			display_tree_part(&rootmenu);
+			gtk_paned_set_position(GTK_PANED(gconfwindow.hpaned), 0);
 			break;
 		case SPLIT_VIEW:
 		{
@@ -137,6 +138,7 @@ void show_data(void)
 			GtkTreeStore* tree2 = GTK_TREE_STORE(gtk_tree_view_get_model(GTK_TREE_VIEW (gconfwindow.tree2_w)));
 			gtk_tree_store_clear(tree2);
 			display_tree(&rootmenu, tree2);
+			gtk_paned_set_position(GTK_PANED(gconfwindow.hpaned), 0);
 			gtk_widget_set_sensitive(gconfwindow.back_btn, FALSE);
 			break;
 		}
scripts/kconfig/gconfig/gconf_treeview_model.c +1 -9
index c7689b3..f57ef05 100644
@@ -652,18 +652,10 @@ void display_tree(struct menu *menu, GtkTreeStore* tree)
 		} else
 			printf("\n");
 #endif
+		/* Do not show P_MENU entries in the right view if not in full view mode */
 		if ((view_mode != FULL_VIEW) && (ptype == P_MENU)
 		    && (tree == tree2))
 			continue;
-/*
-                if (((menu != &rootmenu) && !(menu->flags & MENU_ROOT))
-		    || (view_mode == FULL_VIEW)
-		    || (view_mode == SPLIT_VIEW))*/
-
-		/* Change paned position if the view is not in 'split mode' */
-		if (view_mode == SINGLE_VIEW || view_mode == FULL_VIEW) {
-			gtk_paned_set_position(GTK_PANED(gconfwindow.hpaned), 0);
-		}
 
 		if (((view_mode == SINGLE_VIEW) && (menu->flags & MENU_ROOT))
 		    || (view_mode == FULL_VIEW)
scripts/kconfig/qconfig/qconf.cc deleted +0 -1768

1,768 lines not on this page · raw message

scripts/kconfig/qconfig/qconf.cpp new file +1768 -0

1,199 lines not on this page · raw message

The rest of this diff is not shown. View the raw message.

Signature · 1 line
1.8.1.2

Part of the diff is not shown here. View the raw message.

#6 lore raw

Re: [PATCH 6/9] kconf: gtk: move relayout code out of a loop

Quoted 6 lines · davidgraeff
---
 scripts/kconfig/gconfig/gconf.c                |    2 +
 scripts/kconfig/gconfig/gconf_treeview_model.c |   10 +-
 scripts/kconfig/qconfig/qconf.cc               | 1768 ------------------------
 scripts/kconfig/qconfig/qconf.cpp              | 1768 ++++++++++++++++++++++++

That rename does not belong here...

Sam

#7 lore raw

PATCH 8/9 kconfig: qt flavour makefile fixes

In reply to davidgraeff

* Add comments to the makefile
* fix moc/uic invocation
* Compile moc classes as objects and link to qconf instead of including with #include. This is more compliant to the way IDEs like QtCreator work.

---
 scripts/kconfig/qconfig/Makefile | 39 ++++++++++++++++++++++++---------------
 1 file changed, 24 insertions(+), 15 deletions(-)
scripts/kconfig/qconfig/Makefile +24 -15
index 72e0bd1..b9857c3 100644
@@ -4,9 +4,6 @@
 
 PHONY +=  xconfig qconfig
 
-MOC_HEADERS := $(wildcard $(obj)/qconfig/*.h)
-MOCS := $(patsubst %.h,%.moc,$(MOC_HEADERS))
-
 xconfig: $(obj)/qconf
 	$< $(Kconfig)
 
@@ -14,12 +11,24 @@ qconfig: $(obj)/qconf
 	$< $(Kconfig)
 
 # ===========================================================================
-# qconf:  Used for the xconfig target
-#         Based on QT which needs to be installed to compile it
-# object files used by all kconfig flavours listed above
+# qconf:  Used for the xconfig/qconfig target
+#         Based on Qt4+ which needs to be installed to compile it
+
+# Meta object files (moc files) have to be considered for every class that uses the Q_OBJECT macro.
+# We collect all class header files below, build moc_[filename].o object filenames and store those in "MOCS".
+# Assumtion: All header files in this directory contain c++ code.
+MOC_HEADERS := $(wildcard $(obj)/qconfig/*.h)
+MOC_SOURCE_FILES := $(patsubst $(obj)/qconfig/%,%,$(MOC_HEADERS)) # remove directory part
+MOC_DEST_FILES := $(patsubst %.h,moc_%.o,$(MOC_SOURCE_FILES)) # add moc_ prefix
+MOCS := $(patsubst %,qconfig/%,$(MOC_DEST_FILES)) # add directory part
 
+# Object files used by this kconfig flavours listed below. Meta object files (moc files) are generated by
+# the Qt moc tool. We have to build and link those generated files, too.
 qconf-cxxobjs	:= qconfig/qconf.o qconfig/configItem.o qconfig/configModel.o qconfig/configmodeldelegate.o \
-     qconfig/infoViewWidget.o qconfig/mainwindow.o  qconfig/searchfiltermodelproxy.o qconfig/searchmodel.o
+     qconfig/infoViewWidget.o qconfig/mainwindow.o  qconfig/searchfiltermodelproxy.o qconfig/searchmodel.o \
+     $(MOCS)
+
+# Object files used by all kconfig flavours listed below
 qconf-objs	:= zconf.tab.o
 
 ifeq ($(MAKECMDGOALS),qconfig)
@@ -34,12 +43,12 @@ ifeq ($(qconf-target),1)
 	hostprogs-y += qconf
 endif
 
-clean-files	+= qconfig/*.moc qconfig/ui_*.h qconfig/.tmp_qtcheck qconf
+clean-files	+= qconfig/moc_*.cc qconfig/ui_*.h qconfig/.tmp_qtcheck qconf
 
 HOSTLOADLIBES_qconf	= $(KC_QT_LIBS)
-HOSTCXXFLAGS	= $(KC_QT_CFLAGS) -DINCLUDEMOC
+HOSTCXXFLAGS	= $(KC_QT_CFLAGS)
 
-$(obj)/qconfig/qconf.o: $(MOCS) $(UIS) $(src)/qconfig/.tmp_qtcheck
+$(obj)/qconfig/qconf.o: $(src)/qconfig/.tmp_qtcheck
 $(obj)/qconfig/mainwindow.o: $(obj)/qconfig/ui_mainwindow.h
 
 ifeq ($(qconf-target),1)
@@ -71,15 +80,15 @@ $(obj)/qconfig/.tmp_qtcheck:
 	echo "KC_QT_UIC=$$uic" >> $@
 endif
 
-$(obj)/qconfig/%.o: $(obj)/qconfig/%.moc
-
 quiet_cmd_moc = MOC     $@
-      cmd_moc = $(KC_QT_MOC) -nn -i $< -o $@
+      cmd_moc = $(KC_QT_MOC) -nn $< -o $@
 quiet_cmd_uic = UIC     $@
       cmd_uic = $(KC_QT_UIC) -n $< -o $@
 
-$(obj)/qconfig/%.moc: $(obj)/qconfig/%.h $(obj)/qconfig/.tmp_qtcheck
+$(obj)/qconfig/moc_%.cc: $(obj)/qconfig/%.h
 	$(call cmd,moc)
 
-$(obj)/qconfig/ui_%.h: $(obj)/qconfig/%.ui $(obj)/qconfig/.tmp_qtcheck
+$(obj)/qconfig/ui_%.h: $(obj)/qconfig/%.ui
 	$(call cmd,uic)
+
+$(obj)/qconfig/%.o: $(obj)/qconfig/moc_%.o
Signature · 1 line
1.8.1.2
#8 lore raw

PATCH 9/9 kconfig: qt flavour, add missing updateTree

In reply to davidgraeff

* Remove all #includes for moc files
* Add ui option to show/hide subtrees of disabled options.
* Update the entire model on current item change like gconf

---
 scripts/kconfig/qconfig/infoViewWidget.cc         |  4 +---
 scripts/kconfig/qconfig/mainwindow.cc             | 22 +++++++++++++---------
 scripts/kconfig/qconfig/mainwindow.h              |  2 ++
 scripts/kconfig/qconfig/mainwindow.ui             | 16 ++++++++++++++++
 scripts/kconfig/qconfig/searchfiltermodelproxy.cc |  4 +---
 scripts/kconfig/qconfig/searchmodel.cc            |  4 +---
 6 files changed, 34 insertions(+), 18 deletions(-)
scripts/kconfig/qconfig/infoViewWidget.cc +1 -3
index 21024a8..abcfa09 100644
@@ -10,9 +10,7 @@
 #include <QSettings>
 #include "../expr.h"
 #include "../lkc.h"
-#ifdef INCLUDEMOC
-#include "infoViewWidget.moc"
-#endif
+
 InfoViewWidget::InfoViewWidget(QWidget* parent)
     : Parent(parent), sym(0), _menu(0)
 {
scripts/kconfig/qconfig/mainwindow.cc +13 -9
index 04216f9..bb7870e 100644
@@ -20,9 +20,7 @@
 #include "../images.c"
 #include "../expr.h"
 #include "../lkc.h"
-#ifdef INCLUDEMOC
-#include "mainwindow.moc"
-#endif
+
 bool qconf_MainWindow::check_conf_changed()
 {
     bool changed = conf_get_changed();
@@ -291,12 +289,13 @@ void qconf_MainWindow::on_actionLoad_triggered()
 
 void qconf_MainWindow::on_actionBack_triggered()
 {
-    QModelIndex parent = ui->treeAll->rootIndex().parent();
-    if (view_mode==SINGLE_VIEW) {
-        ui->treeAll->setRootIndex(parent);
-        ui->actionBack->setEnabled(parent.isValid());
-        updateCurrentPositionLabel();
-    }
+    // if (view_mode==SINGLE_VIEW)
+    QModelIndex current = ui->treeAll->rootIndex();
+    QModelIndex parent = current.parent();
+    ui->treeAll->setRootIndex(parent);
+    ui->actionBack->setEnabled(parent.isValid());
+    ui->treeAll->scrollTo(current);
+    updateCurrentPositionLabel();
 }
 
 void qconf_MainWindow::on_actionSingleView_triggered()
@@ -376,3 +375,8 @@ void qconf_MainWindow::updateCurrentPositionLabel()
     }
     ui->labelPosition->setText(t);
 }
+
+void qconf_MainWindow::on_actionHide_disabled_subtrees_triggered()
+{
+    mBaseModel->setHideChildren(ui->actionHide_disabled_subtrees->isChecked());
+}
scripts/kconfig/qconfig/mainwindow.h +2 -0
index e741386..c52db88 100644
@@ -45,6 +45,8 @@ private Q_SLOTS:
     void on_treeAll_activated(const QModelIndex &index);
     void on_listSearch_clicked(const QModelIndex &index);
 
+    void on_actionHide_disabled_subtrees_triggered();
+
 private:
     Ui::qconf_MainWindow *ui;
     ConfigModel* mBaseModel;
scripts/kconfig/qconfig/mainwindow.ui +16 -0
index c6662af..0f548c8 100644
@@ -20,6 +20,9 @@
       <property name="orientation">
        <enum>Qt::Horizontal</enum>
       </property>
+      <property name="childrenCollapsible">
+       <bool>false</bool>
+      </property>
       <widget class="QTabWidget" name="tabWidget">
        <property name="currentIndex">
         <number>0</number>
@@ -149,6 +152,8 @@
     <property name="title">
      <string>Option</string>
     </property>
+    <addaction name="actionHide_disabled_subtrees"/>
+    <addaction name="separator"/>
     <addaction name="actionShow_Name"/>
     <addaction name="actionShow_Range"/>
     <addaction name="actionShow_Data_Value"/>
@@ -380,6 +385,17 @@
     <string>FullView</string>
    </property>
   </action>
+  <action name="actionHide_disabled_subtrees">
+   <property name="checkable">
+    <bool>true</bool>
+   </property>
+   <property name="checked">
+    <bool>true</bool>
+   </property>
+   <property name="text">
+    <string>Hide disabled subtrees</string>
+   </property>
+  </action>
  </widget>
  <layoutdefault spacing="6" margin="11"/>
  <customwidgets>
scripts/kconfig/qconfig/searchfiltermodelproxy.cc +1 -3
index daebe9f..5cf9377 100644
@@ -4,9 +4,7 @@
  */
 #include "searchfiltermodelproxy.h"
 #include "configModel.h"
-#ifdef INCLUDEMOC
-#include "searchfiltermodelproxy.moc"
-#endif
+
 SearchFilterModelProxy::SearchFilterModelProxy(QObject *parent) :
     QSortFilterProxyModel(parent)
 {
scripts/kconfig/qconfig/searchmodel.cc +1 -3
index 974ad53..b98311a 100644
@@ -2,9 +2,7 @@
 #include <QPalette>
 #include "../expr.h"
 #include "../lkc.h"
-#ifdef INCLUDEMOC
-#include "searchmodel.moc"
-#endif
+
 
 SearchModel::item::item(struct menu* menu) {
     this->menu = menu;
Signature · 1 line
1.8.1.2
#9 lore raw
In reply to davidgraeff

David, All,

On 2013-07-02 17:22 +0200, davidgraeff spake thusly:

Quoted 1 line

I've no idea if this is the right way to send patches. I'm kind of new to this.

It seems you're doing mostly fine! :-)

However, since you asked: your patches are numberedd 2 to 9. It seems you considered the intro mail (the one I'm replying to here) as the number one. Is that right, or is patch #1 missing?

Usually, patch series are sent as thus:
[PATCH 0/N] Subject for intro mail, aka "cover letter" [PATCH 1/N] Subject for first actual patch [PATCH 2/N] Subject for second actual patch [...]
[PATCH N-1/N] Subject for penultimate actual patch [PATCH N/N] Subject for last actual patch

You can achieve this using 'git send-email'. See:
git help send-email

Also, see (albeit not totaly up-to-date):
Documentation/SubmittingPatches

Nit-picking: please keep your mails and commit messages below 80-chars per line, it's easier to read. Thanks! :-)

Quoted 2 lines

Attached is a patchset basically for porting the graphical Gtk and Qt flavours to their latest toolkit versions (Gtk3 and Qt4 with compatibility to Qt5 respectively).

I did not do any review of the patches, since I have a concern about the series. It happens very often that, in enterprise ecosystems, the host build machines are running rather aging distro, such as RHEL 5 (or even RHEL 4 in some cases), so I think we still want the new kernels to be buildable (and thus configurable) on such machines (eg. for cross-compilation).

I have no idea when such enterprise distros have started bundling GTK3 or Qt4/5, but given RHEL-4 (which is still use in some places) is 8 years old, I doubt the new frontends would build on those distros.

Quoted 1 line

I do not know if it was on purpose to keep all flavours except lxdialog in one single directory,

Historical artifact, I think... :-(

[--SNIP--]

Quoted 2 lines

Those newer graphical kconfig flavours will be used by a project I'm involved in so I will maintain it for the next couple of months.

Could you please explain what this project of yours is about?

Quoted 1 line

If I did anything wrong, please instruct me or provide me a link please.

As I said above, mostly good. I've seen far worse submnissions, don't worry! ;-)

Regards,
Yann E. MORIN.

PS. Sorry for not answering earlier, I had connection issues yesterday,

    during all the evening & night. :-(

YEM.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
#10 lore raw

Yem, All,

Am 03.07.2013 18:30, schrieb Yann E. MORIN:

Quoted 8 lines

However, since you asked: your patches are numberedd 2 to 9. It seems you considered the intro mail (the one I'm replying to here) as the number one. Is that right, or is patch #1 missing?

[...]

You can achieve this using 'git send-email'. See:
git help send-email

I'm sorry for the missing first patch, actually I used git send-email, but had initial problems with perl and its smtp module. I guess perl ate this missing first patch mail, I'm not sure.

Quoted 2 lines

Nit-picking: please keep your mails and commit messages below 80-chars per line, it's easier to read. Thanks! :-)

I will do my best :) One of my intentions to use git send-email was because I thought it would automatically format patches in a way that reviewing them would be easier. Likely I'm too much used, should I say 'spoiled', by the github or gerrit review UI :)
I will change my proposed code accordingly.

Quoted 6 lines

I did not do any review of the patches, since I have a concern about the series. It happens very often that, in enterprise ecosystems, the host build machines are running rather aging distro, such as RHEL 5 (or even RHEL 4 in some cases), so I think we still want the new kernels to be buildable (and thus configurable) on such machines (eg. for cross-compilation).

A serious concern, you're absolutly right. Let me tell you some background information and my concerns regarding the current code.
Although the Gtk2->3 port was less effort than the Qt-flavour port, it is the more important one in my opinion. The current code definitly does not compile with gtk3 and some used libraries (e.g. libglade) are depreated for a while now.
Of just a cosmetic nature: In my experience, on newer systems gtk2 applications additionally look somewhat outdated.

Maybe it is a good idea, to have the current gtk implementation and the ported one side-by-side. What do you think?

Regarding the Qt-flavour port, I would classify it as an almost complete rewrite. I'm more into C++/Qt and personally I always used xconfig for kconf. The current implementation is more a Qt3 application that still compiles with Qt4 due of heavy usage of the deprecated Qt3support layer. For the new implementation, I adopted Qt4 techniques like the Qt MVC pattern
and the Qt interface designer (similar to the kconf-Gtk solution), while paying attention to a Qt5 compatibilty.
It's more likely that I introducted bugs in this kconf flavour port, of course. But I'd assume it's a good starting point for a discussion of a more future-proof and probably more easy to maintain implementation.

Your concern about those aging distros certainly applies to this ported kconf flavour, too. So I'm not sure how to proceed. Options, I can thing of are:

* Remove the Qt3/4-flavour and use the new Qt4/5 one, keep the Gtk2-flavour for aging distros.
* Keep both Qt-flavour implementations (maybe with make targets like xconfig and qconfig).
* Don't change the Qt3/4-flavour and do not introduce this proposed Qt-flavour.

I would prepare a v2 patch series consisting of three patches only:
1) Directory structure. For each kconf ui flavour a separate one.
2) gtk3-flavour as side-by-side solution to the existing gtk2 one.
3) Qt4/5-flavour as side-by-side solution to the existing Qt3/4 one. Far less intrusive :)

Quoted 3 lines
Quoted 2 lines

Those newer graphical kconfig flavours will be used by a project I'm involved in so I will maintain it for the next couple of months.

Could you please explain what this project of yours is about?

* A configurable firmware for atmega processors (we are using the menuconfig kconf interface only) [github: ethersex].
* CiAO: Highly configurable aspect oriented research operating-system. Configuration is realised by kconf. We are using the Qt interface mainly.
* And two other configurable operating systems, that are used for teaching.

I guess there are way more projects using the famous kconf and users who like to use the graphical interface flavours :)

Quoted 3 lines

PS. Sorry for not answering earlier, I had connection issues yesterday,

     during all the evening & night. :-(

YEM.

So now it's my time to say sorry, took a few days to respond.

David.

#11 lore raw

David, All,

On 2013-07-06 02:13 +0200, David Gräff spake thusly:

Quoted 45 lines

Am 03.07.2013 18:30, schrieb Yann E. MORIN:

Quoted 6 lines

I did not do any review of the patches, since I have a concern about the series. It happens very often that, in enterprise ecosystems, the host build machines are running rather aging distro, such as RHEL 5 (or even RHEL 4 in some cases), so I think we still want the new kernels to be buildable (and thus configurable) on such machines (eg. for cross-compilation).

A serious concern, you're absolutly right. Let me tell you some background information and my concerns regarding the current code.
Although the Gtk2->3 port was less effort than the Qt-flavour port, it is the more important one in my opinion. The current code definitly does not compile with gtk3 and some used libraries (e.g. libglade) are depreated for a while now.
Of just a cosmetic nature: In my experience, on newer systems gtk2 applications additionally look somewhat outdated.

Maybe it is a good idea, to have the current gtk implementation and the ported one side-by-side. What do you think?

Regarding the Qt-flavour port, I would classify it as an almost complete rewrite. I'm more into C++/Qt and personally I always used xconfig for kconf. The current implementation is more a Qt3 application that still compiles with Qt4 due of heavy usage of the deprecated Qt3support layer. For the new implementation, I adopted Qt4 techniques like the Qt MVC pattern
and the Qt interface designer (similar to the kconf-Gtk solution), while paying attention to a Qt5 compatibilty.
It's more likely that I introducted bugs in this kconf flavour port, of course. But I'd assume it's a good starting point for a discussion of a more future-proof and probably more easy to maintain implementation.

Your concern about those aging distros certainly applies to this ported kconf
flavour, too. So I'm not sure how to proceed. Options, I can thing of are:

* Remove the Qt3/4-flavour and use the new Qt4/5 one, keep the Gtk2-flavour for aging distros.
* Keep both Qt-flavour implementations (maybe with make targets like xconfig and qconfig).
* Don't change the Qt3/4-flavour and do not introduce this proposed Qt-flavour.

Quoted 5 lines

I would prepare a v2 patch series consisting of three patches only:
1) Directory structure. For each kconf ui flavour a separate one.
2) gtk3-flavour as side-by-side solution to the existing gtk2 one.
3) Qt4/5-flavour as side-by-side solution to the existing Qt3/4 one. Far less intrusive :)

I personnally don't use any of the two GUIs, so I can't really tell what their status is. However, there are users of these, so I think we do not want to leave them out in the cold.

I really don't know what to do about this.

One idea would be to have two new goals: g3config and q5config, and kepp the existing ones in place. I don't like it much, since the two old ones will ultimately no longer work, so may dusrupt users' expectations, and it's double maintenance on non-GUI related changes.

An alternate route would be to add the two new frontends, and keep xconfig and gconfig as-is, but decide which to build depending on availability of the libraries:
- xconfig: if Qt5 is present, then build and run the new Qt5-based frontend, otherwise build the current Qt3/4 frontend
- gconfig: ditto, but with Gtk3 vs. Gtk2.
This still means double maintenance, but means we can easily drop the old frontends in the future when Gtk2 and Qt3/4 are virtually no longer meaningful, since this does not break users' experience.

So as a summarry, here are the three options:
- update existing frontends against their respective framework
- add two new frontends, and two new goals to call them
- add two new frontends, and decide whether to call them or the old ones

Really, I have no idea what is best.

[--SNIP--]

Quoted 2 lines

I guess there are way more projects using the famous kconf and users who like to use the graphical interface flavours :)

Yes, countless other projects use that: busybox, uClibc, Buildroot, crosstool-NG, OpenBricks, NuttX, openWRT... to name a few I know of.

BTW, you may be interested in:
http://ymorin.is-a-geek.org/projects/kconfig-frontends

Regards,
Yann E. MORIN.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
#12 lore raw
Quoted 7 lines

So as a summarry, here are the three options:
- update existing frontends against their respective framework
- add two new frontends, and two new goals to call them
- add two new frontends, and decide whether to call them or the old ones

Really, I have no idea what is best.

As per my other mail the best candidate is
"- update existing frontends against their respective framework".

Because:
- There exist a fallback for users that do not have the never libs available
- The gtk/qt frontends see only little love&care - so coming up with something that require more love&care is not good
- And we know that we have a person to look after the problems that is introduced at lest for a few months.

We should carefully review the patches to make sure the resulting code is maintainable in the long term. I assume this is more or less a no-brainer.

Sam

#13 lore raw
In reply to Yann E. MORIN
Quoted 11 lines

I did not do any review of the patches, since I have a concern about the series. It happens very often that, in enterprise ecosystems, the host build machines are running rather aging distro, such as RHEL 5 (or even RHEL 4 in some cases), so I think we still want the new kernels to be buildable (and thus configurable) on such machines (eg. for cross-compilation).

I have no idea when such enterprise distros have started bundling GTK3 or Qt4/5, but given RHEL-4 (which is still use in some places) is 8 years old, I doubt the new frontends would build on those distros.

IMO users restricted to these systems - if required to look at / modify the kernel configuration can use one of the other frontends.
In other words - I do not think we shall stick to the old gtk / qt versions due to this.

Quoted 3 lines
Quoted 1 line

I do not know if it was on purpose to keep all flavours except lxdialog in one single directory,

Historical artifact, I think... :-(

lxdialog was one a separate binary - later we did a very rough conversion so it is now a single binary. But there are many left-overs from when it was separated.

Sam

#14 lore raw
In reply to davidgraeff
Quoted 24 lines · davidgraeff

Hello all,

I've no idea if this is the right way to send patches. I'm kind of new to this. Attached is a patchset basically for porting the graphical Gtk and Qt flavours to their latest toolkit versions (Gtk3 and Qt4 with compatibility to Qt5 respectively). It took a day or so to get into the code -> Newly inserted and changed source code is commented in many/some places now.

I do not know if it was on purpose to keep all flavours except lxdialog in one single directory, but for presumably easier maintenance the first patch split of each flavours into its own subdirectory. Additionally I ripped out flavour specific makefile targets. Each subdirectory contains a separate makefile now.
An advantage is a more simple makefile for e.g. all the C++/Qt stuff, where Qt specific moc and uic tools are necessary.

The 2nd to 6th patch port the Gtk2 ui to the modern Gtk3 toolkit including the conversion from a libglade (deprecated) interface to a gtkbuilder interface.

The 7th to 9th patch port the Qt3/Qt4+Qt3support ui to the current version 4 of the Qt toolkit. The gui is no longer realised by handwritten c++ code but by the Qt Designer for a much easier user interface design and less code.
The Model/View concept of Qt is heavily used and no Qt3 support classes are used anymore, as a result the code should work with the newest Qt5, too.

Quoted 4 lines

Those newer graphical kconfig flavours will be used by a project I'm involved in so I will maintain it for the next couple of months.

If I did anything wrong, please instruct me or provide me a link please.

It seems patch [1/9] is missing. Maybe the size as too big. Did you specify "-D -M" when you ran "git format-patch"? This will show file relocatiosn in a very efficent and reviewable way.

Sam