Information Technology

Experiments with IUP Pt. 1

It seems rainy days and rabbit holes go hand in hand. I keep trying to get back to writing my GnuCOBOL book (having finished the first draft of the Emacs book) and I keep finding rabbit holes. In particular, I got involved in the GnuCOBOL GUI discussion.

The main version of GnuCOBOL is a transpiler. It translates the COBOL code to C then uses gcc to compile it. There is a C++ fork being worked on that I haven’t played with yet. Given all of the work I’ve done using Qt, I was interested in hearing there was consideration being given to using Qt for the GUI of the C++ fork. At first it sounds cool to have COBOL generate your Qt application, but the more I thought about the massive footprint and “adopt it as a complete religion” view of the framework, I advised against looking at Qt. You can’t “just sprinkle in” Qt. I get phone calls about projects from people/companies who tried to do that. At some point I’m going to play with NanoGUI and probably recommend they use that. It claims to be just a UI without the massive overreach of Qt.

Here is the other reason I would recommend they avoid Qt, even if I didn’t foresee technical problems. Qt Company has really honked off the OpenSource community with their licensing. As such, I expect KDE will be kicking Qt Company to the curb. I suspect they are a bit too heavily invested in Qt to kick it all the way to the curb. Rumblings I’ve heard is something I suggested a while back. A fork of 4.8, ripping out all of that worthless QML then splitting the packaging up. We shall see what becomes of it. There are too many people looking to get involved in such a project, potentially renaming the fork to avoid confusion. Last I heard, all that FLOSS needs is a sponsor. Exactly what a sponsor does or would be on the hook for, I have no idea. I honestly don’t care to know. Whether it is FLOSS or someone else, a fork of Qt is imminent at this point. Maybe KDE will kick Qt to the curb completely and just start with NanoGUI? Instead of one massive overreaching application framework, have a lot of little cooperative frameworks. At this point Qt definitely needs to be a contestant on “The Biggest Loser.”

Anyway, I pulled down iup from SourceForge.

sourceforge screenshot

I extracted the file into a subdirectory under Downloads. In the new subdirectory you find two files of importance:  install   install_dev

The first installs the shared libraries (.so). The second installs the header files and statically linked libraries for development. I ran them both just for grins, running install_dev first.

Like most OpenSource projects, the tutorial is out of date. It seems the only time people are willing to “do the paperwork” is in the bathroom after taking a good Trump and voting at least twice. Between email interruptions and Stevie Wonder leading Ray Charles through the woods, I got the first example to compile and run.

#include <stdlib.h>
#include <iup.h>

int main(int argc, char **argv)
{
  IupOpen(&argc, &argv);
  
  IupMessage("Hello World 1", "Hello world from IUP.");
  
  IupClose();
  return EXIT_SUCCESS;
}

Where the documentation went a bit off the rails was the command line to compile. It appears someone split the libraries into finer groupings. Here is the command line.

gcc -I/usr/include/iup example2_1.c -o example2_1 -liup -liupimglib

For whatever reason the tutorial skips adding the iup library. I’m guessing someone had an environment variable set or what is in iup got split off from iupimglib.

The problem with all GTK based applications is they look like an alien invader or something that stood too close to a nuclear reactor for too long. Then again, so did a quick test of a Qt application on this KDE system.

#include <QApplication>
#include <QMessageBox>

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    QMessageBox msg(QMessageBox::Information, "HelloQt", "Hello World!", QMessageBox::Ok );
    msg.exec();
    return a.exec();
}
QT       += core gui

greaterThan(QT_MAJOR_VERSION, 4): QT += widgets

CONFIG += c++11

# The following define makes your compiler emit warnings if you use
# any Qt feature that has been marked deprecated (the exact warnings
# depend on your compiler). Please consult the documentation of the
# deprecated API in order to know how to port your code away from it.
DEFINES += QT_DEPRECATED_WARNINGS

# You can also make your code fail to compile if it uses deprecated APIs.
# In order to do so, uncomment the following line.
# You can also select to disable deprecated APIs only up to a certain version of Qt.
#DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x060000    # disables all the APIs deprecated before Qt 6.0.0

SOURCES += \
    main.cpp

HEADERS +=

FORMS +=

# Default rules for deployment.
qnx: target.path = /tmp/$${TARGET}/bin
else: unix:!android: target.path = /opt/$${TARGET}/bin
!isEmpty(target.path): INSTALLS += target

Changing the icon requires just a touch more finesse under Qt.

#include <QApplication>
#include <QMessageBox>
#include <QIcon>

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    QMessageBox msg(QMessageBox::Information, "HelloQt", "Hello World!", QMessageBox::Ok );
    msg.setWindowIcon(QIcon::fromTheme("system-run"));
    msg.exec();
    return msg.exec();
}

It isn’t fair to say I cannot find one in iup. I haven’t really dug into anything yet.