История изменений

Из реальных проблем в GTK2:

• Определения struct объектов являются частью публичного интерфейса, а не инкапсулированы за методами. Решение этой проблемы потребовало полностью сломать ABI, поэтому они довольно долго тянули до ввода GTK3, когда накопилась критическая масса идей, ради который стоило бы идти на такой кардинальный шаг, чтобы сразу всё воплотить.
• Как следствие предыдущего. В одной из структур фигурирует 32-битное значение под счётчик времени, и это нельзя исправить без поломки ABI. Если не ошибаюсь, это связано с кодом всплывающих подсказок. Поэтому если это не править, то в 2038-м этот код сломается.
  • В качестве решения я вижу изменить внутреннюю логику кода так, чтобы счётчик хранил относительное значение времени - отсчитывая разницу от момента запуска программы. Это починит логику, не сломав ABI.
• В GTK2 приложение линкуется с библиотекой вида libgtk-x11-2.0.so.0, то есть она связана с конкретным бэком. В GTK3 этот вопрос решили, приложение линкуется с libgtk-3.so.0. И теоретически, если не использует ничего, специфичного для конкретного бэка, то может прозрачно работать на любом бэке.
  • Для GTK2 этот вопрос можно решить, оставив libgtk-x11-2.0.so.0 как легаси-имя. То есть теоретически вполне возможно существующие собранные программы на GTK2 запустить на другом бэке, если доработать тулкит.
• HiDPI. Нужно допиливать. Тупо не завезено API под это дело, нужно завозить.

И да, реализация масштабирования UI в GTK3/4 - сосёт. Они отмазываются тем, что «реализация дробного масштабирования требует поддержки со стороны приложений». А миграция с GTK3 и GTK4 - не требует что ли??

Из реальных проблем в GTK2:

• Определения struct объектов являются частью публичного интерфейса, а не инкапсулированы за методами. Решение этой проблемы потребовало полностью сломать ABI, поэтому они довольно долго тянули до ввода GTK3, когда накопилась критическая масса идей, ради который стоило бы идти на такой кардинальный шаг, чтобы сразу всё воплотить.
• Как следствие предыдущего. В одной из структур фигурирует 32-битное значение под счётчик времени, и это нельзя исправить без поломки ABI. Если не ошибаюсь, это связано с кодом всплывающих подсказок. Поэтому если это не править, то в 2038-м этот код сломается.
  • В качестве решения я вижу изменить внутреннюю логику кода так, чтобы счётчик хранил относительное значение времени - отсчитывая разницу от момента запуска программы. Это починит логику, не сломав ABI.
• В GTK2 приложение линкуется с библиотекой вида libgtk-x11-2.0.so.0, то есть она связана с конкретным бэком. В GTK3 этот вопрос решили, приложение линкуется с libgtk-3.so.0. И теоретически, если не использует ничего, специфичного для конкретного бэка, то может прозрачно работать на любом бэке.
  • Для GTK2 этот вопрос можно решить, оставив libgtk-x11-2.0.so.0 как легаси-имя. То есть теоретически вполне возможно существующие собранные программы на GTK2 запустить на другом бэке, если доработать тулкит.
• HiDPI. Нужно допиливать. Тупо не завезено API под это дело, нужно завозить.

И да, реализация масштабирования UI в GTK3/4 - сосёт. Они отмазываются тем, что «реализация дробного DPI требует поддержки со стороны приложений». А миграция с GTK3 и GTK4 - не требует что ли??

Из реальных проблем в GTK2:

• Определения struct объектов являются частью публичного интерфейса, а не инкапсулированы за методами. Решение этой проблемы потребовало полностью сломать ABI, поэтому они довольно долго тянули до ввода GTK3, когда накопилась критическая масса идей, ради который стоило бы идти на такой кардинальный шаг, чтобы сразу всё воплотить.
• Как следствие предыдущего. В одной из структур фигурирует 32-битное значение под счётчик времени, и это нельзя исправить без поломки ABI. Если не ошибаюсь, это связано с кодом всплывающих подсказок. Поэтому если это не править, то в 2038-м этот код сломается.
  • В качестве решения я вижу изменить внутренню логику кода так, чтобы счётчик хранил относительное значение времени - отсчитывая разницу от момента запуска программы. Это починит логику, не сломав ABI.
• В GTK2 приложение линкуется с библиотекой вида libgtk-x11-2.0.so.0, то есть она связана с конкретным бэком. В GTK3 этот вопрос решили, приложение линкуется с libgtk-3.so.0. И теоретически, если не использует ничего, специфичного для конкретного бэка, то может прозрачно работать на любом бэке.
  • Для GTK2 этот вопрос можно решить, оставив libgtk-x11-2.0.so.0 как легаси-имя. То есть теоретически вполне возможно существующие собранные программы на GTK2 запустить на другом бэке, если доработать тулкит.
• HiDPI. Нужно допиливать. Тупо не завезено API под это дело, нужно завозить.

И да, реализация масштабирования UI в GTK3/4 - сосёт. Они отмазываются тем, что «реализация дробного DPI требует поддержки со стороны приложений». А миграция с GTK3 и GTK4 - не требует что ли??

Из реальных проблем в GTK2:

• Определения struct объектов являются частью публичного интерфейса, а не инкапсулированы за методами. Решение этой проблемы потребовало полностью сломать ABI, поэтому они довольно долго тянули до ввода GTK3, когда накопилась критическая масса идей, ради который стоило бы идти на такой кардинальный шаг, чтобы сразу всё воплотить.
• Как следствие предыдущего. В одной из структур фигурирует 32-битное значение под счётчик времени, и это нельзя исправить без поломки ABI. Если не ошибаюсь, это связано с кодом всплывающих подсказок. Поэтому если это не править, то в 2038-м этот код сломается.
• В качестве решения я вижу изменить внутренню логику кода так, чтобы счётчик хранил относительное значение времени - отсчитывая разницу от момента запуска программы. Это починит логику, не сломав ABI.
• В GTK2 приложение линкуется с библиотекой вида libgtk-x11-2.0.so.0, то есть она связана с конкретным бэком. В GTK3 этот вопрос решили, приложение линкуется с libgtk-3.so.0. И теоретически, если не использует ничего, специфичного для конкретного бэка, то может прозрачно работать на любом бэке.
  • Для GTK2 этот вопрос можно решить, оставив libgtk-x11-2.0.so.0 как легаси-имя. То есть теоретически вполне возможно существующие собранные программы на GTK2 запустить на другом бэке, если доработать тулкит.
• HiDPI. Нужно допиливать. Тупо не завезено API под это дело, нужно завозить.

И да, реализация масштабирования UI в GTK3/4 - сосёт. Они отмазываются тем, что «реализация дробного DPI требует поддержки со стороны приложений». А миграция с GTK3 и GTK4 - не требует что ли??

Из реальных проблем в GTK2:

• Определения struct объектов являются частью публичного интерфейса, а не инкапсулированы за методами. Решение этой проблемы потребовало полностью сломать ABI, поэтому они довольно долго тянули до ввода GTK3, когда накопилась критическая масса идей, ради который стоило бы идти на такой кардинальный шаг, чтобы сразу всё воплотить.
• Как следствие предыдущего. В одной из структур фигурирует 32-битное значение под счётчик времени, и это нельзя исправить без поломки ABI. Если не ошибаюсь, это связано с колом всплывающих подсказок. Поэтому если это не править, то в 2038-м этот код сломается.
• В качестве решения я вижу изменить внутренню логику кода так, чтобы счётчик хранил относительное значение времени - отсчитывая разницу от момента запуска программы. Это починит логику, не сломав ABI.
• В GTK2 приложение линкуется с библиотекой вида libgtk-x11-2.0.so.0, то есть она связана с конкретным бэком. В GTK3 этот вопрос решили, приложение линкуется с libgtk-3.so.0. И теоретически, если не использует ничего, специфичного для конкретного бэка, то может прозрачно работать на любом бэке.
  • Для GTK2 этот вопрос можно решить, оставив libgtk-x11-2.0.so.0 как легаси-имя. То есть теоретически вполне возможно существующие собранные программы на GTK2 запустить на другом бэке, если доработать тулкит.
• HiDPI. Нужно допиливать. Тупо не завезено API под это дело, нужно завозить.

И да, реализация масштабирования UI в GTK3/4 - сосёт. Они отмазываются тем, что «реализация дробного DPI требует поддержки со стороны приложений». А миграция с GTK3 и GTK4 - не требует что ли??