Nerdlingen

Year: 2015

  • Elster-Formular mit Mint x64 / Wine

    Der kleine ELSTER-Inforoboter (leider keine Elster, sondern ein Roboter) verkündet großmäulig, “ELSTER läuft auch unter Linux“. Für einen kleinen Teil der angebotenen Softwareprodukte dieser Firma mag das stimmen, für ElsterFormular allerdings nicht, zumindest nicht Offline. Mit Wine allerdings läuft es quasi problemlos – wirklich gut allerdings nur mit 32-Bit Wine (für x64-Windows gibt es die entsprechenden .NET 3.5 DLLs nicht in einer Form, mit der Wine umgehen kann). Dafür erstellt man zunächst einen Wine-Prefix mit 32-Bit im Hintergrund:

    WINEPREFIX=$HOME/Anwendungen/Elster WINEARCH='win32' wine 'wineboot'

    Vorausgesetzt man hat wine, wine:i386 und wine-mono installiert, sollte Wine nun (hier im Ordner Anwendungen/Elster im Home-Verzeichnis) eine neue Wine-Basis einrichten – dafür frägt wein auch nach dem Mono- sowie dem Gecko paket, die man beide installieren sollte.

    Das Elster-Setup startet man nun mittels:

    WINEPREFIX=$HOME/Anwendungen/Elster wine ~/Downloads/ElsterFormular-16.3.170.20151019p.exe

    Wichtig ist, den WINEPREFIX-Teil nicht zu vergessen, sonst verwendet Wine den Standard-Prefix (meist ~/.wine) – dieser ist auf 64-Biting Linuxen dann doch meist 64 Bit. Die Installation läuft nun praktisch automatisch, wie auf Windows problemlos. Lustig ist, dass die Software zwingend eine Internetverbindung zum Anzeigen des Lizenzvertrages voraussetzt; wäre mal interessant zu prüfen, ob das so überhaupt rechtens ist…

    Lizenzdialog von ElsterFormular

    Das schöne ist, dass Wine für installierte Verknüpfungen den aktuell gesetzten WINEPREFIX automatisch mit in die entsprechenden .desktop-Files packt, sodass ab jetzt keine weitere Komandozeilenarbeit notwendig ist:

    Elster-ENV

    Ergebnis: Läuft!

    Elster

  • Updating sparklines in OriginC

    Ever wondered how to tell OriginLab to update the sparklines after a custom import-filter (or whatever data-manipulating script) has been called?

    Well, you can call the “sparklines” X-Function. The documentation is, as usual for OriginC, not the best and calling X-Functions with the wrong parameter will simply crash OriginLab, but it’s worth it…

    Code:

    bool call_UpdateSparklines_XF(Worksheet &wks)
{
    // Create an instance of XFBase using the X-Function name.
    XFBase xf("sparklines");
    if (!xf)
        return false;
 
    // Set the 'iw' argument. A worksheet for XFBase is referenced using a Pointer (not the name...)
    if (!xf.SetArg("iw", wks))
        return false;
 
    // Set the 'sel' argument.
    if (!xf.SetArg("sel", 0))
        return false;
 
    // Set the 'c1' argument, the first row to update. Counter starts at 1.
    if (!xf.SetArg("c1", 1))
        return false;
 
    // Set the 'sel' argument.
    if (!xf.SetArg("c2", wks.GetNumCols()))
        return false;
 
    // Call XFBase's 'Evaluate' method to execute the X-Function
    if (!xf.Evaluate())
        return false;
 
    return true;
}

    You might also find this Forum-Entry useful, where some different possibilities are given: OriginC-Forum / Sparklines

  • HD TFT vs. VGA-KVM Switch – and Linux

    Multiple Computers at the same Keyboard, Video and Mouse – no problem when using a KVM Switch. Unfortunately, mine (DLink DKVM-2KU) does not seem to route the IDx-Pins of the VGA connector correctly, my system was not able to get the required EDID data to know which timings and resolutions are supported by the monitor.

    This resulted in a max. resolution of 1360×768 pixels – way below the native 1920×1080 (which I could easily set when connecting the display directly via DVI or VGA). Most guides to add additional resolutions suggest asking gtf or cvt to calculate the respective timings (where for TFT-Displays CVT-based timings should be used, see e.g. http://www.uruk.org/~erich/projects/cvt/) and pasting these to xrandr to set the required mode. However, this does not work if xrandr thinks the monitor cannot take the requested frequencies.

    A call to cvt may produce this:

    X@Y ~ $ cvt 1920 1080
# 1920x1080 59.96 Hz (CVT 2.07M9) hsync: 67.16 kHz; pclk: 173.00 MHz
Modeline "1920x1080_60.00"  173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync

    The printed “modeline” contains all the timings needed for the card to drive the monitor at the requested resolution, however – in my case – adding the requested resolution resulted in an error, basically telling me that one of the parameters was not in a range supported by some device in the chain (DAC or Monitor for example):

    X@Y ~ $ xrandr --newmode "1920x1080_60.00"  172.80  1920 2040 2248 2576  1080 1081 1084 1118  -HSync +Vsync
X@Y ~ $ xrandr --addmode VGA-0 "1920x1080_60.00"
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  140 (RANDR)
  Minor opcode of failed request:  18 (RRAddOutputMode)
  Serial number of failed request:  29
  Current serial number in output stream:  30

    Most forum-threads, guides and Wiki-entires break at this point and say “Well, your monitor simply cannot do this”. Mine does, however the system doesn’t know. The source of the problem was in the X-Org config-file /usr/share/X11/xorg.conf.d/90-monitor.conf (in this case of Linux Mint 17.1, although I don’t know where this file came from – it doesn’t seem to be part of the standard system packages), which contained:

    Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Unknown"
    HorizSync       30.0 - 63.0
    VertRefresh     55.0 - 75.0
    Option         "DPMS"
EndSection

    When I2C and therefore EDID is working correctly, the file seems to get overruled by the information provided by the monitor – in my case, EDID didn’t get past the KVM switch. The modeline calculated by cvt stated a pixel-clock of 172.80 MHz, together with a total virtual display width of 2576 points. This results in a horizontal refresh-rate of 67 kHz – which is higher than the maximum of 63 kHz given in the file.

    Once I fixed this (I set it to 200, which is way to high, but doesn’t matter here…), xrandr accepted the mode. If you want this to be permanent, you might configure your X-Server according to this guide – but don’t forget to add the HorizSync and VertRefresh parameters!

    But, for haven’s sake, be careful! Setting really wrong values will at least leave you without a picture (or an “Out of Range” message) for TFT screens, CRTs might get damaged!

    Update: There’s annother error that I came accross when reinstalling the machine recently:

    X Error of failed request:  BadName (named color or font does not exist)

    This time, I simply had to change the name of the mode from “1920x1080_60.00” to “1080p” – problem solved. Possibly my Xsession-script did not fail completely and blocked the name for future use…