> Щито? Вы на джаваскрипте программируете? А ничего, что и Qt и GTK
> предоставляют свои API для работы с файлами, потоками, таймерами, окнами и
> т.д. и каждый своим способом? Какой вы там параметр сборки собрались
> менять, если у вас получатся абсолютно две разные программы со своими
> заголовочными файлами, функциями и скриптами сборки? Или вы для "калькулятора" создадите
> абстракцию, которая отдельно ложится на gtk или qt (выбирается опцией компиляции)?
> Вы понимаете, что эта абстракция по сути повторит весь функционал qt
> и gtk? Ради чего такое делать?

Уже имею опыт написания под Qt, GTK и WinAPI, правда разовый. В основном работаю с Qt.
Для ПО создаются архитектурные элементы: 1) Инициатор; 2) Транслятор GUI; 3) Исполнитель; 4) Хранитель; 5) Обработчик протокола. Софтина являлась клиентом для удалённого сервиса.

Класс "транслятора GUI" цеплял всё, что надо и исполнял логику реакции интерфейса на события. Именно конечной реакции, а не отлова. От него наследовался класс, реализующий собственно диалог. Вот он-то и есть фреймворкозависимый. Всё, с чем он работает, — с фреймворком GUI. Больше ни с чем.

Параметр сборки — правило для Makefile (ненавижу юродивый CMake!). Собственно, для винды это — профиль под VC. В зависимости от платформы и фреймворка собиралась морда та, которая нужно. Задача была выполнена. не скулил и не плакался крокодильими слезами, "ах как плохо, что куча вариантов интерфейса!".

> В кроссплатформенных гуёвых проектах есть абстракции от платформы - windows или mac
> os. Но когда туда добавляется ещё и абстракции самой абстракции типа
> gtk и qt - это уже двойная бесполезная работа, не находите?
> Не было бы круто, если бы была бы платформа Xorg какая-нибудь
> и всё на этом?

Всего лишь отделяется фреймворконезависимая логика приложения от зависимой. Вот и всё. Просто не надо писать исполнительную логику посреди кода GUI! А с остальной частью можно поступать так же.

> Да-да, а ещё скрипты для CentOS 6, 7 и Fedora, а ещё
> Debian 8, 9 и Ubuntu - good luck.

Да. Лежит отдельно Shell-файлик, который определяет ОС, выдаёт по запросам нужные параметры для скриптов сборки. Собственно скрипты сборки универсальны и привязаны лишь к типу пакета (deb, rpm).

> Это прекрасно, что вы слышали такие понятия. Пишите на java и будет
> вам кроссплатформенно всё из коробки - это ж хороший тон, зачем
> вам qt и gtk тогда? Или вот вам задачка - напишите
> кроссплатформенную игру и опубликуйте её в маркете винды и эпла. Что?
> Как-то тормознуто получается, да? Абстракции съедают производительность, да? Дублируется
> логика, да? Ай-яй-яй. Какой "нехороший и неадекватный тон"! Выходит приходится писать
> что-то пер-platform и не потому что "мне так удобнее", а потому
> что это две разные платформы.

Повторяю: опыт есть, но для desktop-приложений, а не для мобильных. Но даже в этом случае есть решение. По сему ёрничанье тут не уместно. Если Вы не умеете в абстракцию без тормозов, то что тут говорить? Наверное лишь упомянуть, что она прорабатываться может не только на уровне исполнения кода.

> К сожалению, да. Поэтому нафиг выбор в виде двух яиц, разбейте одно,
> пусть живёт другое и не будет никаких воин.

Тут я бы предпочёл окончательное деление. Скажем, пусть будет какая-нибудь KDE OS и Gnome OS, от которых бы отталкивались остальные дистрибутивы. Чуть ближе к стандартизации.

> Сейчас, если в винде надо написать гуёвую программу и выложить в маркет
> - берите xaml, не надо в маркет - winforms (c++ или
> c# - что больше знаете). В макоси вообще cocoa и всё
> тут - это что плохо что ли?

Логика одна. Интерфейсы разные. Удивляет, когда люди столь категорично делят программы на "мобильные", "дэсктопные" и "серверные". Логика расчётов и исполнительная могут быть одинаковыми для всех, а оболочка — отдельная ипостась, будь она хоть мобильной, хоть настольной, хоть вообще WEB-мордой. Любят же люди нещадно дублировать код! По сто раз писать одно и то же.

> Если взять Qt или GTK - то да, гуй работать будет везде.
> Но тогда скажите разработчикам из LibreOffice, что они дураки, что пишут
> собственный кроссплатформенный гуи тулкит (https://docs.libreoffice.org/vcl.html).

Будет третий GUI Framework. Выбор — хорошее дело.

И ещё раз повторю: Быстро написанный код либо тормозной, либо монструозный по архитектурному решению, либо и вовсе франкенштейн, при работе с которым охота отправить его создателя на гильотину. Чем проще, тем надёжнее. Это правило не отменяет здоровой абстракции в меру и по порядку без перегибов.