Сообщение Re[4]: Библиотека для создания графических интерфейсов польз от 16.09.2017 17:18
Изменено 16.09.2017 17:27 c-smile
Re[4]: Библиотека для создания графических интерфейсов польз
Здравствуйте, alex_public, Вы писали:
_>Я сам предпочитаю во многих местах использовать исключительно функциональный стиль. Только вот есть небольшой нюанс: как раз для GUI стиль ООП является вполне себе естественным и оптимальным.
Ты уже сам определись: или "исключительно функциональный стиль" или "ООП является вполне себе естественным и оптимальным".
Что из этого верно?
CS>>Тогда как практически весь современный UI (Web это 99.99% всего UI) крайне далек от той изначальной модели.
_>
_>Предлагаю тебе просто открыть исходники какого-нибудь там Webkit'a и посмотреть своими глазами на реализацию этого самого Web UI — ты там увидишь всё те же самые C++ классы в классической ООП схеме.
Sciter тоже написан на C++ и использует классы и всё такое. Более того у меня используется динамическое наследование, см. мою дискуссию на SO. Здесь тоже обсуждалось. Так вот такие трюки это не совсем C++, а скорее C + VTBL руками сделанная.
Но суть в том что класс в смысле C++ там только один — namespace dom { class element; }. Т.е. снаружи такой системы UI это композиция однотипных элементов.
+ система event handlers которые уже и определяют как эти LEGO блоки себя ведут. Вот эти три <text>+<button>+<popup> собранные в одном месте есть COMBOBOX, а этот один <textarea> есть текстовый редактор.
Современная ситуация такова что базовых/классических элементов которые раньше использовались в UI в реальности не стало хватать с самого начала.
Появились всякие там OWNERDRAW и прочее попытки сделать это всё в ООП стиле... Ну кошмарно же получилось...
CS>>Т.е. весь современный UI это системы Lego блоков (DOM элементов) с динамически назначаемыми event handlers, свойствами и методами.
_>И это всё отлично ложится как раз на ООП модель.
Я не отрицаю, но давай уточним что такое "ООП модель". Это модель внутреннего устройства (WebKit, Gecko, Trident, h-smile engine в Sciter)
или то что предлагается использовать юзерам твоей OOП (MFC,Qt,wxWidgets,etc.)?
Если внутреннего устройства то это никого не парит.
Важно как API этого GUI engine устроен и его гранулярность.
CS>>Во многом functional и declarative programming. Проблема в том что UI имеет свою внутреннюю логику.
_>В HTML это происходит на машине клиента в момент загрузки страницы, а в Qt на машине разработчика в момент компиляции *.ui файлов — более эффективный подход.
Всё остальное поскипал, но вот на том популярном заблуждении хотел бы остановится.
Это вот
24 байта занимает. Предложи более компактный способ сериализации. И способ восстановления из того формата который существенно быстрее скажем этого вот моего парсера который я использую в sciter.
При все при том что координаты ты сериализовать не можешь — они не известны в общем случае (разные DPI и form factors target devices).
CS>>Без GC получить динамический UI сложно.
_>Полная ерунда и невладение C++.
Подозреваю что мой код работает на твоем компьютере в одном из установленных продуктов.
Сомневаюсь что твой — на моих.
Это я про объективные оценки того кто чем владеет.
CS>>Angular и React со товарищи рулят не просто так. Declarative code binding это не прихоть, а требование времени.
CS>>Мы перестали делать приложения "на всю жизнь". Время жизни UI решений теперь измеряется месяцами если не неделями.
CS>>Поэтому нужно уметь быстро подстраиваться под архитектуры OS и пр. Сколько жила Windows XP? А сколько Windows 7, а Windows 8.
CS>>Про Windows 10 я вообще молчу. Сейчас уже выходит Creators Update... Там некоторые UI принципы вообще другие...
CS>>Как пример сколько времени мы смотрели на кнопки в виде башни танка Тигр. А сколько в виде башни T64 (WinXP...Win7)? А сколько на современные плоские?
CS>>Сколько времени на цельнолитые windows? А сколько на современные blur behind (MacOS, Windows 8 и кульминация в Creators Update)...
_>Ты действительно считаешь, что правильное GUI должно это всё задавать в себе? Вообще то у разных людей разные вкусы и разные ОС, которые они настраивают под эти вкусы. Так что правильное GUI в идеале должно полностью соответствовать локальным настройкам, а не навязывать свои (такие приложения выделяются в негативную сторону, и кстати обычно это как раз приложения с веб интерфейсом или написанные на Java).
Я не знаю что такое "локальные настройки" в современном мире.
Windows XP и Windows 10 — там не то что настройки там UI API разные. В одном есть HWND во втором — уже нет (UWP).
А Linux? Gnome и KDE и твое приложение с тем самым .ui файлом что должно использовать?
Эта мулечка уже протухла лет 10 тому как... Какие нафиг "локальные настройки" в Microsoft Office? А в Visual Studio?
А если сравнить Sublime Text UI и скажем какой Notepad++ — ну блин UI/UX disaster же...
CS>>Время когда мы делали UI и прибивали его к пиксельным сеткам ушло.
_>Совершенно верно.
CS>>Соответственно вымерли visual designer динозавры как класс.
_>Какая чушь. Причём на всех уровнях — и по факту и по логическому выводу. Ну видно же, что твоё второе предложение даже теоретически может следовать из первого, только при условии что визуальные дизайенеры работают исключительно через пиксельную сетку. Что естественно не соответствует действительности. Как и собственно твое утверждение — визуальные дизайнеры вполне себе существуют и развиваются.
CS>>Мы делаем приложения работающие на широком спектре экранов и input sensors
_>Совершенно верно. Например у меня приложение работает на Android/Windows/iOS/OSX/Linux на всех экранах от телевизора до часов. И при этом GUI вполне себе рисуется в визуальном редакторе.
CS>>Для чистого С++ оптимальными UI задачами являются что-то типа Microsoft Word и Excel. Все остальное в UI крайне не подходит под C++.
CS>>Но верно и обратное. Google Docs лучше бы был написан на C++.
_>Что такое "остальное UI"? )
CS>>Т.е. C++ это эффективный rendering. Но UI composition, styling и event handling реально удобнее и надежнее делать в ... ну не буду повторяться.
_>Опять же ерунда. Хотя на самом деле определённое преимущество в создание web интерфейсов действительно имеется — для их создания не требуется брать крутого (и дорогого) C++ программиста, а можно взять за копейки любого верстальщика из веб'а, которых кругом полно. Однако это преимущество относится не к техническим, а к бизнес вопросам, так что вряд ли его стоит обсуждать в данной теме.
_>Я сам предпочитаю во многих местах использовать исключительно функциональный стиль. Только вот есть небольшой нюанс: как раз для GUI стиль ООП является вполне себе естественным и оптимальным.
Ты уже сам определись: или "исключительно функциональный стиль" или "ООП является вполне себе естественным и оптимальным".
Что из этого верно?
CS>>Тогда как практически весь современный UI (Web это 99.99% всего UI) крайне далек от той изначальной модели.
_>
_>Предлагаю тебе просто открыть исходники какого-нибудь там Webkit'a и посмотреть своими глазами на реализацию этого самого Web UI — ты там увидишь всё те же самые C++ классы в классической ООП схеме.
Sciter тоже написан на C++ и использует классы и всё такое. Более того у меня используется динамическое наследование, см. мою дискуссию на SO. Здесь тоже обсуждалось. Так вот такие трюки это не совсем C++, а скорее C + VTBL руками сделанная.
Но суть в том что класс в смысле C++ там только один — namespace dom { class element; }. Т.е. снаружи такой системы UI это композиция однотипных элементов.
+ система event handlers которые уже и определяют как эти LEGO блоки себя ведут. Вот эти три <text>+<button>+<popup> собранные в одном месте есть COMBOBOX, а этот один <textarea> есть текстовый редактор.
Современная ситуация такова что базовых/классических элементов которые раньше использовались в UI в реальности не стало хватать с самого начала.
Появились всякие там OWNERDRAW и прочее попытки сделать это всё в ООП стиле... Ну кошмарно же получилось...
CS>>Т.е. весь современный UI это системы Lego блоков (DOM элементов) с динамически назначаемыми event handlers, свойствами и методами.
_>И это всё отлично ложится как раз на ООП модель.
Я не отрицаю, но давай уточним что такое "ООП модель". Это модель внутреннего устройства (WebKit, Gecko, Trident, h-smile engine в Sciter)
или то что предлагается использовать юзерам твоей OOП (MFC,Qt,wxWidgets,etc.)?
Если внутреннего устройства то это никого не парит.
Важно как API этого GUI engine устроен и его гранулярность.
CS>>Во многом functional и declarative programming. Проблема в том что UI имеет свою внутреннюю логику.
_>В HTML это происходит на машине клиента в момент загрузки страницы, а в Qt на машине разработчика в момент компиляции *.ui файлов — более эффективный подход.
Всё остальное поскипал, но вот на том популярном заблуждении хотел бы остановится.
Это вот
<body>hello world</body>24 байта занимает. Предложи более компактный способ сериализации. И способ восстановления из того формата который существенно быстрее скажем этого вот моего парсера который я использую в sciter.
При все при том что координаты ты сериализовать не можешь — они не известны в общем случае (разные DPI и form factors target devices).
CS>>Без GC получить динамический UI сложно.
_>Полная ерунда и невладение C++.
Подозреваю что мой код работает на твоем компьютере в одном из установленных продуктов.
Сомневаюсь что твой — на моих.
Это я про объективные оценки того кто чем владеет.
CS>>Angular и React со товарищи рулят не просто так. Declarative code binding это не прихоть, а требование времени.
CS>>Мы перестали делать приложения "на всю жизнь". Время жизни UI решений теперь измеряется месяцами если не неделями.
CS>>Поэтому нужно уметь быстро подстраиваться под архитектуры OS и пр. Сколько жила Windows XP? А сколько Windows 7, а Windows 8.
CS>>Про Windows 10 я вообще молчу. Сейчас уже выходит Creators Update... Там некоторые UI принципы вообще другие...
CS>>Как пример сколько времени мы смотрели на кнопки в виде башни танка Тигр. А сколько в виде башни T64 (WinXP...Win7)? А сколько на современные плоские?
CS>>Сколько времени на цельнолитые windows? А сколько на современные blur behind (MacOS, Windows 8 и кульминация в Creators Update)...
_>Ты действительно считаешь, что правильное GUI должно это всё задавать в себе? Вообще то у разных людей разные вкусы и разные ОС, которые они настраивают под эти вкусы. Так что правильное GUI в идеале должно полностью соответствовать локальным настройкам, а не навязывать свои (такие приложения выделяются в негативную сторону, и кстати обычно это как раз приложения с веб интерфейсом или написанные на Java).
Я не знаю что такое "локальные настройки" в современном мире.
Windows XP и Windows 10 — там не то что настройки там UI API разные. В одном есть HWND во втором — уже нет (UWP).
А Linux? Gnome и KDE и твое приложение с тем самым .ui файлом что должно использовать?
Эта мулечка уже протухла лет 10 тому как... Какие нафиг "локальные настройки" в Microsoft Office? А в Visual Studio?
А если сравнить Sublime Text UI и скажем какой Notepad++ — ну блин UI/UX disaster же...
CS>>Время когда мы делали UI и прибивали его к пиксельным сеткам ушло.
_>Совершенно верно.
CS>>Соответственно вымерли visual designer динозавры как класс.
_>Какая чушь. Причём на всех уровнях — и по факту и по логическому выводу. Ну видно же, что твоё второе предложение даже теоретически может следовать из первого, только при условии что визуальные дизайенеры работают исключительно через пиксельную сетку. Что естественно не соответствует действительности. Как и собственно твое утверждение — визуальные дизайнеры вполне себе существуют и развиваются.
CS>>Мы делаем приложения работающие на широком спектре экранов и input sensors
_>Совершенно верно. Например у меня приложение работает на Android/Windows/iOS/OSX/Linux на всех экранах от телевизора до часов. И при этом GUI вполне себе рисуется в визуальном редакторе.
CS>>Для чистого С++ оптимальными UI задачами являются что-то типа Microsoft Word и Excel. Все остальное в UI крайне не подходит под C++.
CS>>Но верно и обратное. Google Docs лучше бы был написан на C++.
_>Что такое "остальное UI"? )
CS>>Т.е. C++ это эффективный rendering. Но UI composition, styling и event handling реально удобнее и надежнее делать в ... ну не буду повторяться.
_>Опять же ерунда. Хотя на самом деле определённое преимущество в создание web интерфейсов действительно имеется — для их создания не требуется брать крутого (и дорогого) C++ программиста, а можно взять за копейки любого верстальщика из веб'а, которых кругом полно. Однако это преимущество относится не к техническим, а к бизнес вопросам, так что вряд ли его стоит обсуждать в данной теме.
Re[4]: Библиотека для создания графических интерфейсов польз
Здравствуйте, alex_public, Вы писали:
_>Я сам предпочитаю во многих местах использовать исключительно функциональный стиль. Только вот есть небольшой нюанс: как раз для GUI стиль ООП является вполне себе естественным и оптимальным.
Ты уже сам определись: или "исключительно функциональный стиль" или "ООП является вполне себе естественным и оптимальным".
Что из этого верно?
CS>>Тогда как практически весь современный UI (Web это 99.99% всего UI) крайне далек от той изначальной модели.
_>
_>Предлагаю тебе просто открыть исходники какого-нибудь там Webkit'a и посмотреть своими глазами на реализацию этого самого Web UI — ты там увидишь всё те же самые C++ классы в классической ООП схеме.
Sciter тоже написан на C++ и использует классы и всё такое. Более того у меня используется динамическое наследование, см. мою дискуссию на SO. Здесь тоже обсуждалось. Так вот такие трюки это не совсем C++, а скорее C + VTBL руками сделанная.
Но суть в том что класс в смысле C++ там только один — namespace dom { class element; }. Т.е. снаружи такой системы UI это композиция однотипных элементов.
+ система event handlers которые уже и определяют как эти LEGO блоки себя ведут. Вот эти три <text>+<button>+<popup> собранные в одном месте есть COMBOBOX, а этот один <textarea> есть текстовый редактор.
Современная ситуация такова что базовых/классических элементов которые раньше использовались в UI в реальности не стало хватать с самого начала.
Появились всякие там OWNERDRAW и прочее попытки сделать это всё в ООП стиле... Ну кошмарно же получилось...
CS>>Т.е. весь современный UI это системы Lego блоков (DOM элементов) с динамически назначаемыми event handlers, свойствами и методами.
_>И это всё отлично ложится как раз на ООП модель.
Я не отрицаю, но давай уточним что такое "ООП модель". Это модель внутреннего устройства (WebKit, Gecko, Trident, h-smile engine в Sciter)
или то что предлагается использовать юзерам твоей OOП (MFC,Qt,wxWidgets,etc.)?
Если внутреннего устройства то это никого не парит.
Важно как API этого GUI engine устроен и его гранулярность.
CS>>Во многом functional и declarative programming. Проблема в том что UI имеет свою внутреннюю логику.
_>В HTML это происходит на машине клиента в момент загрузки страницы, а в Qt на машине разработчика в момент компиляции *.ui файлов — более эффективный подход.
Всё остальное поскипал, но вот на том популярном заблуждении хотел бы остановится.
Это вот
24 байта занимает. Предложи более компактный способ сериализации. И способ восстановления из того формата который существенно быстрее скажем этого вот моего парсера который я использую в sciter.
При все при том что координаты ты сериализовать не можешь — они не известны в общем случае (разные DPI и form factors target devices).
CS>>Без GC получить динамический UI сложно.
_>Полная ерунда и невладение C++.
Подозреваю что мой код работает на твоем компьютере в одном из установленных продуктов.
Сомневаюсь что твой — на моих.
Это я про объективные оценки того кто чем владеет.
CS>>Angular и React со товарищи рулят не просто так. Declarative code binding это не прихоть, а требование времени.
CS>>Мы перестали делать приложения "на всю жизнь". Время жизни UI решений теперь измеряется месяцами если не неделями.
CS>>Поэтому нужно уметь быстро подстраиваться под архитектуры OS и пр. Сколько жила Windows XP? А сколько Windows 7, а Windows 8.
CS>>Про Windows 10 я вообще молчу. Сейчас уже выходит Creators Update... Там некоторые UI принципы вообще другие...
CS>>Как пример сколько времени мы смотрели на кнопки в виде башни танка Тигр. А сколько в виде башни T64 (WinXP...Win7)? А сколько на современные плоские?
CS>>Сколько времени на цельнолитые windows? А сколько на современные blur behind (MacOS, Windows 8 и кульминация в Creators Update)...
_>Ты действительно считаешь, что правильное GUI должно это всё задавать в себе? Вообще то у разных людей разные вкусы и разные ОС, которые они настраивают под эти вкусы. Так что правильное GUI в идеале должно полностью соответствовать локальным настройкам, а не навязывать свои (такие приложения выделяются в негативную сторону, и кстати обычно это как раз приложения с веб интерфейсом или написанные на Java).
Я не знаю что такое "локальные настройки" в современном мире.
Windows XP и Windows 10 — там не то что настройки там UI API разные. В одном есть HWND во втором — уже нет (UWP).
А Linux? Gnome и KDE и твое приложение с тем самым .ui файлом что должно использовать?
Эта мулечка уже протухла лет 10 тому как... Какие нафиг "локальные настройки" в Microsoft Office? А в Visual Studio?
А если сравнить Sublime Text UI и скажем какой Notepad++ — ну блин UI/UX disaster же...
_>Я сам предпочитаю во многих местах использовать исключительно функциональный стиль. Только вот есть небольшой нюанс: как раз для GUI стиль ООП является вполне себе естественным и оптимальным.
Ты уже сам определись: или "исключительно функциональный стиль" или "ООП является вполне себе естественным и оптимальным".
Что из этого верно?
CS>>Тогда как практически весь современный UI (Web это 99.99% всего UI) крайне далек от той изначальной модели.
_>
_>Предлагаю тебе просто открыть исходники какого-нибудь там Webkit'a и посмотреть своими глазами на реализацию этого самого Web UI — ты там увидишь всё те же самые C++ классы в классической ООП схеме.
Sciter тоже написан на C++ и использует классы и всё такое. Более того у меня используется динамическое наследование, см. мою дискуссию на SO. Здесь тоже обсуждалось. Так вот такие трюки это не совсем C++, а скорее C + VTBL руками сделанная.
Но суть в том что класс в смысле C++ там только один — namespace dom { class element; }. Т.е. снаружи такой системы UI это композиция однотипных элементов.
+ система event handlers которые уже и определяют как эти LEGO блоки себя ведут. Вот эти три <text>+<button>+<popup> собранные в одном месте есть COMBOBOX, а этот один <textarea> есть текстовый редактор.
Современная ситуация такова что базовых/классических элементов которые раньше использовались в UI в реальности не стало хватать с самого начала.
Появились всякие там OWNERDRAW и прочее попытки сделать это всё в ООП стиле... Ну кошмарно же получилось...
CS>>Т.е. весь современный UI это системы Lego блоков (DOM элементов) с динамически назначаемыми event handlers, свойствами и методами.
_>И это всё отлично ложится как раз на ООП модель.
Я не отрицаю, но давай уточним что такое "ООП модель". Это модель внутреннего устройства (WebKit, Gecko, Trident, h-smile engine в Sciter)
или то что предлагается использовать юзерам твоей OOП (MFC,Qt,wxWidgets,etc.)?
Если внутреннего устройства то это никого не парит.
Важно как API этого GUI engine устроен и его гранулярность.
CS>>Во многом functional и declarative programming. Проблема в том что UI имеет свою внутреннюю логику.
_>В HTML это происходит на машине клиента в момент загрузки страницы, а в Qt на машине разработчика в момент компиляции *.ui файлов — более эффективный подход.
Всё остальное поскипал, но вот на том популярном заблуждении хотел бы остановится.
Это вот
<body>hello world</body>24 байта занимает. Предложи более компактный способ сериализации. И способ восстановления из того формата который существенно быстрее скажем этого вот моего парсера который я использую в sciter.
При все при том что координаты ты сериализовать не можешь — они не известны в общем случае (разные DPI и form factors target devices).
CS>>Без GC получить динамический UI сложно.
_>Полная ерунда и невладение C++.
Подозреваю что мой код работает на твоем компьютере в одном из установленных продуктов.
Сомневаюсь что твой — на моих.
Это я про объективные оценки того кто чем владеет.
CS>>Angular и React со товарищи рулят не просто так. Declarative code binding это не прихоть, а требование времени.
CS>>Мы перестали делать приложения "на всю жизнь". Время жизни UI решений теперь измеряется месяцами если не неделями.
CS>>Поэтому нужно уметь быстро подстраиваться под архитектуры OS и пр. Сколько жила Windows XP? А сколько Windows 7, а Windows 8.
CS>>Про Windows 10 я вообще молчу. Сейчас уже выходит Creators Update... Там некоторые UI принципы вообще другие...
CS>>Как пример сколько времени мы смотрели на кнопки в виде башни танка Тигр. А сколько в виде башни T64 (WinXP...Win7)? А сколько на современные плоские?
CS>>Сколько времени на цельнолитые windows? А сколько на современные blur behind (MacOS, Windows 8 и кульминация в Creators Update)...
_>Ты действительно считаешь, что правильное GUI должно это всё задавать в себе? Вообще то у разных людей разные вкусы и разные ОС, которые они настраивают под эти вкусы. Так что правильное GUI в идеале должно полностью соответствовать локальным настройкам, а не навязывать свои (такие приложения выделяются в негативную сторону, и кстати обычно это как раз приложения с веб интерфейсом или написанные на Java).
Я не знаю что такое "локальные настройки" в современном мире.
Windows XP и Windows 10 — там не то что настройки там UI API разные. В одном есть HWND во втором — уже нет (UWP).
А Linux? Gnome и KDE и твое приложение с тем самым .ui файлом что должно использовать?
Эта мулечка уже протухла лет 10 тому как... Какие нафиг "локальные настройки" в Microsoft Office? А в Visual Studio?
А если сравнить Sublime Text UI и скажем какой Notepad++ — ну блин UI/UX disaster же...