Link lxdialog with mconf directly

After three years, the zombie walks again! This patch (against the latest git tree) cleans up interaction between kconfig's mconf (menuconfig frontend) and lxdialog. Its commandline interface disappears in this patch, instead a .so is packed from the lxdialog objects and the relevant functions are called directly from mconf.

scripts/kconfig/mconf.c +2 -2

@@ -808,18 +684,22 @@ static void conf(struct menu *menu)
    }
    break;
   case 4:
-   if (type == 't')
+   if (active_type == 't')
     sym_set_tristate_value(sym, no);
    break;
   case 5:
-   if (type == 't')
+   if (active_type == 't')
     sym_set_tristate_value(sym, mod);

Quoted 18 lines

After three years, the zombie walks again! This patch (against the latest git tree) cleans up interaction between kconfig's mconf (menuconfig frontend) and lxdialog. Its commandline interface disappears in this patch, instead a .so is packed from the lxdialog objects and the relevant functions are called directly from mconf.

scripts/kconfig/mconf.c +2 -2

@@ -808,18 +684,22 @@ static void conf(struct menu *menu)
    }
    break;
   case 4:
-   if (type == 't')
+   if (active_type == 't')
     sym_set_tristate_value(sym, no);
    break;
   case 5:
-   if (type == 't')
+   if (active_type == 't')
     sym_set_tristate_value(sym, mod);

scripts/kconfig/mconf.c static void conf(struct menu *menu) · line 699

Quoted 10 lines

scripts/kconfig/mconf.c +4 -3

    break;
   case 6:
-   if (type == 't')
+   if (active_type == 't') {
     sym_toggle_tristate_value(sym);
-   else if (type == 'm')
-    conf(submenu);
+   } else if (active_type == 'm') {
+    if (single_menu_mode)
+     submenu->data = (void *) !submenu->data;

Shouldn't this be:

     submenu->data = (void *) (long) !submenu->data;

Dear diary, on Mon, Dec 12, 2005 at 04:18:26AM CET, I got a letter where Kurt Wall <[email protected]> said that...

Quoted 4 lines

Quoted 1 line

+ submenu->data = (void *) !submenu->data;

Shouldn't this be:

     submenu->data = (void *) (long) !submenu->data;

You are right, it should be so at least for consistency - it'll be fixed in the next resend of the patch. I can't see why is it needed, though - shouldn't the int be padded to void* anyway?

In practice, this means that drawing on the screen is done with _MUCH_ less overhead now, the screen updates are better optimalized as ncurses won't get reset everytime you display something, that also implies that the ugly screen flickering is done. As a cute side-effect, the dialogs are now rendered on the top of the menu or help panel. In the future, this also gives us much more freedom for enhancing the user interface.

Compared to the previous version (from February 2003), this one should be less buggy (especially wrt. the escape character handling), should not crash while resizing and the resizing should have immediate effect (although things can still start looking ugly when you are resizing while not in a menu - to fix that properly, more liblxdialog integration is required). Also, the code is considerably simplified on few places.

Quoted 7 lines

Compared to the previous version (from February 2003), this one should be less buggy (especially wrt. the escape character handling), should not crash while resizing and the resizing should have immediate effect (although things can still start looking ugly when you are resizing while not in a menu - to fix that properly, more liblxdialog integration is required). Also, the code is considerably simplified on few places.

The <esc><esc> as described in mconf.c still produces two exits, which is a little annoying if one is used to it. I don't know how easy it is to supress that second <esc>.

After three years, the zombie walks again! This patch (against the latest git tree) cleans up interaction between kconfig's mconf (menuconfig frontend) and lxdialog. Its commandline interface disappears in this patch, instead a .so is packed from the lxdialog objects and the relevant functions are called directly from mconf.

In practice, this means that drawing on the screen is done with _MUCH_ less overhead now, the screen updates are better optimalized as ncurses won't get reset everytime you display something, that also implies that the ugly screen flickering is done. As a cute side-effect, the dialogs are now rendered on the top of the menu or help panel. In the future, this also gives us much more freedom for enhancing the user interface.

This opens space for plenty of cleanups of liblxdialog, removal of superfluous stuff and temporary files usage, etc.

Compared to the previous version (from February 2003), this one should be less buggy (especially wrt. the escape character handling), should not crash while resizing and the resizing should have immediate effect (although things can still start looking ugly when you are resizing while not in a menu - to fix that properly, more liblxdialog integration is required). Also, the code is considerably simplified on few places.

Signed-off-by Petr Baudis <[email protected]>

The following series revives one three years old patch, turning lxdialog
to a library and linking it directly to mconf, making menuconfig nicer and things in general quite simpler and cleaner.

The first two patches make slight adjustements to kbuild in order to make
liblxdialog possible. The third patch does the libification itself and appropriate modifications to mconf.c.

Quoted 7 lines

The following series revives one three years old patch, turning lxdialog
to a library and linking it directly to mconf, making menuconfig nicer and things in general quite simpler and cleaner.

The first two patches make slight adjustements to kbuild in order to make
liblxdialog possible. The third patch does the libification itself and appropriate modifications to mconf.c.

Why not just copy over relevant files to scripts/kconfig? Then no playing tricks with libaries etc. is needed, and everythings just works.

It is only 8 files and prefixing them with lx* would make them stand out compared to the rest. It is not like there is any user planned for the lxdialog functionality in the kernel, and kconfig users outside the kernel I beleive copy lxdialog with rest of kconfig files.

Btw. the work you are doing are clashing with a general cleanup effort of lxdialog I have in -mm at the moment.
I received only very limited feedback = looks ok. Integrating principles from your old patch was on my TODO list.

I have something in the works that uses linked list instead of a preallocated array, to keep the dynamic behaviour. I will probarly make a version with the linked list approach but otherwise use your changes to mconf.c. But it will take a few days until I get to it.

Quoted 4 lines

It is only 8 files and prefixing them with lx* would make them stand out compared to the rest. It is not like there is any user planned for the lxdialog functionality in the kernel, and kconfig users outside the kernel I beleive copy lxdialog with rest of kconfig files.

Ok. I didn't want to pollute scripts/kconfig/ too much, but if it's ok by you, I can do it that way. I will submit another series later in the evening.

Quoted 5 lines

Btw. the work you are doing are clashing with a general cleanup effort of lxdialog I have in -mm at the moment.
I received only very limited feedback = looks ok. Integrating principles from your old patch was on my TODO list.

Do you mean the series you posted at Nov 21? Should I just rebase my patches on top of that?

FWIW, the changes there look fine to me. I actually wanted to change the indentation of the menus as well; it looks horrible especially in the singlemenu mode.

Quoted 4 lines

I have something in the works that uses linked list instead of a preallocated array, to keep the dynamic behaviour. I will probarly make a version with the linked list approach but otherwise use your changes to mconf.c. But it will take a few days until I get to it.

I can do it and include it in the updated series.

Ok. I didn't want to pollute scripts/kconfig/ too much, but if it's ok by you, I can do it that way. I will submit another series later in the evening.