Oberon space
General Category => Общий раздел => Тема начата: Vartovyj от Март 03, 2012, 12:52:24 pm
-
Убогость или приемлемое кроссплатформенное решение?
-
А можно ссылок на то, что вообще имеется в виду? А то SDL -- довольно распространённая аббревиатура, и везде расшифровывается по разному...
-
А можно ссылок на то, что вообще имеется в виду? А то SDL -- довольно распространённая аббревиатура, и везде расшифровывается по разному...
libsdl.org
-
Убогость или приемлемое кроссплатформенное решение?
Я просто с SDL имел дело и знаю на что оно способно.
SDL прекрасно подходит для кроссплатформенной игры например. Для кроссплатформенного эмулятора (виртуальной машины) - тоже прекрасно (см. qemu, dosbox и так далее). Вполне сойдет для видеоплеера (хотя тут уже с натяжками). Абсолютно не годится для IDE и тем более для BB (ведь он не только IDE, но и то на базе чего затем строится конечное приложение).
Поясню: в SDL у тебя ровно одно окно. Больше одного окна (в терминах OS) SDL не умеет. Более того, оно и с этим то окном весьма неумело обращается. Все что SDL умеет делать (в плане графики) - это рисовать в этом самом окне, точнее работать с видеопамятью (а функции рисования примитивов - изволь реализовывать сам, либо используй сторонние либы). И делает это хорошо.
А зачем нам вообще что-то кроме одного окна (в терминах OS, понятно что своих окошек мы внутри можем нарисовать ровно столько сколько захотим и OS про них ничего знать не будет)? А затем. Например для выпадающих меню - меню должно быть полностью на экране даже если не вмещается в родительское окно (простейший пример - высота окошка меньше чем высота менюшки - оно вылезает за его пределы). Также для диалогов (open file и так далее). Для всплывающих подсказок. Вообще многооконность вещь весьма полезная. Я видел помнится коммерческий графический редактор (аля фотошоп) реализованный целиком на SDL - это смотрелось ужасно. Вроде на скриншотах ничего, но пользоваться не приятно. Он крайне чужд любой системе.
В swing'e (стандартная gui-либа для java) есть разделение - есть тяжеловесные окна - это те окна которые существуют в терминах OS, и легковесные окна - которые мы полностью рисуем сами и OS про них ничего не знает. Одно тяжеловесное окно может содержать одно или несколько наших окон/граф. компонентов/виджетов (любой виджет это, очевидно, окно). Специально для тяжеловесных окон в swing'e есть тоненькая абстрактная прослойка над механизмами данной конкретной OS - awt. Она реализует (точнее оборачивает системные) кроссплатформенно ровно те немногочисленные функции, которые swing'у нужны от оконной системы. Например swing'у не нужны нативные системные контролы (кнопка там, чекбокс и так далее) - он сам рисует свои на базе легковесных окон. (хотя, справедливости ради, следует заметить что в awt они есть - это осталось с тех времен когда не было swing'a и все пытались сделать чисто на awt, без легковесных окон).
Таким образом, для построения кроссплатформенной гуйной либы тоже нужно реализовать тоже что-то вроде облегченного AWT для тяжеловесных окон разных систем. А уже потом внутри рисовать красивый (или не очень) гуй.
И да, swing работает во всех распространенных системах. Перекомпиляция программы не требуется.
PS. Кроме того, SDL изначально затачивался под игры. Там скорость много важнее надежности.
-
Может адаптировать что-нибудь паскалевское, типа fpGUI?
-
Может адаптировать что-нибудь паскалевское, типа fpGUI?
Я не знаю. С fpGUI я не знаком.
В принципе вполне годится взять и портировать (переписать) что-нибудь легковесное-сишное (не плюсовое). Именно в плане оконной либы. В качестве алгоритмов для рисования можно тот же AGG взять, который уже переписан на Обероне (полностью или почти полностью).
-
Например для выпадающих меню - меню должно быть полностью на экране даже если не вмещается в родительское окно (простейший пример - высота окошка меньше чем высота менюшки - оно вылезает за его пределы). Также для диалогов (open file и так далее). Для всплывающих подсказок.
Зачем это быть полностью на экране даже если не вмещается в родительское окно? Я, например, наоборот всегда воспринимал такое поведение (когда нечто выперло за рамки окна) как глюк в программе из-за кривых рук программистов.
-
Например для выпадающих меню - меню должно быть полностью на экране даже если не вмещается в родительское окно (простейший пример - высота окошка меньше чем высота менюшки - оно вылезает за его пределы). Также для диалогов (open file и так далее). Для всплывающих подсказок.
Зачем это быть полностью на экране даже если не вмещается в родительское окно? Я, например, наоборот всегда воспринимал такое поведение (когда нечто выперло за рамки окна) как глюк в программе из-за кривых рук программистов.
Например, когда отображения окна НЕТ (свернуто в трей).
-
Точнее, когда меню содержит команды - СМЫСЛ которых не зависит от статуса видимости и размеров ОКНА приложения
-
Например для выпадающих меню - меню должно быть полностью на экране даже если не вмещается в родительское окно (простейший пример - высота окошка меньше чем высота менюшки - оно вылезает за его пределы). Также для диалогов (open file и так далее). Для всплывающих подсказок.
Зачем это быть полностью на экране даже если не вмещается в родительское окно? Я, например, наоборот всегда воспринимал такое поведение (когда нечто выперло за рамки окна) как глюк в программе из-за кривых рук программистов.
Ну, например вот для такого (видимо я не слишком ясно объяснил, картинка покажет лучше):
(http://www.reactos.org/wiki/images/9/9e/TortoiseSVN_SVN-Update_Menu.png)
-
Например для выпадающих меню - меню должно быть полностью на экране даже если не вмещается в родительское окно (простейший пример - высота окошка меньше чем высота менюшки - оно вылезает за его пределы). Также для диалогов (open file и так далее). Для всплывающих подсказок.
Зачем это быть полностью на экране даже если не вмещается в родительское окно? Я, например, наоборот всегда воспринимал такое поведение (когда нечто выперло за рамки окна) как глюк в программе из-за кривых рук программистов.
Ну, например вот для такого (видимо я не слишком ясно объяснил, картинка покажет лучше):
(http://www.reactos.org/wiki/images/9/9e/TortoiseSVN_SVN-Update_Menu.png)
Что за ФОШИСТКАЯ писанина? ;)
-
Что за ФОШИСТКАЯ писанина? ;)
Да это видимо скриншот какого-то из немецких разработчиков ReactOS'и (у меня винды нет под рукой, поэтому использовал первый подвернувшийся скриншот из интернетов).
-
Впринципе, что касаеться SDL в качестве IDE, думаю понятно - в морг.
Так, что тему можно закрывать.
-
Поясню: в SDL у тебя ровно одно окно. Больше одного окна (в терминах OS) SDL не умеет. Более того, оно и с этим то окном весьма неумело обращается. Все что SDL умеет делать (в плане графики) - это рисовать в этом самом окне, точнее работать с видеопамятью (а функции рисования примитивов - изволь реализовывать сам, либо используй сторонние либы). И делает это хорошо.
По идее, описанное Вами ограничение можно было бы снять, если окно, принадлежащее системе, сделать transparent и растянуть во весь экран. В этом случае рисуй где хочешь. Но боюсь, что в этом случае система не позволит нарисовать "плотные" окна внутри прозрачного системного окна.
-
Поясню: в SDL у тебя ровно одно окно. Больше одного окна (в терминах OS) SDL не умеет. Более того, оно и с этим то окном весьма неумело обращается. Все что SDL умеет делать (в плане графики) - это рисовать в этом самом окне, точнее работать с видеопамятью (а функции рисования примитивов - изволь реализовывать сам, либо используй сторонние либы). И делает это хорошо.
По идее, описанное Вами ограничение можно было бы снять, если окно, принадлежащее системе, сделать transparent и растянуть во весь экран. В этом случае рисуй где хочешь. Но боюсь, что в этом случае система не позволит нарисовать "плотные" окна внутри прозрачного системного окна.
Ну, вообще, теоретически, OS может позволять делать окна с неравномерной прозрачностью (вот винда например позволяет, через GDI+). То есть прозрачность указывается индивидуально для каждого из пикселей, причем не 0/1, а с градацией. Но, сколь я помню, SDL это не умеет. В плане руления системным окном SDL весьма ограничена - оно ей просто не нужно.
Ну и в любом случае это был бы костыль который наверняка выходил бы боком в некоторых случаях.
-
Ну и в любом случае это был бы костыль который наверняка выходил бы боком в некоторых случаях.
Самое простое - вне "плотного" окна на рабочем столе лежит несколько ярлыков - пусть даже прозрачность "системного" окна позволяет их увидеть- как запустить соответствующие ярлыкам приложения не сворачивая "системного" окна?
-
Ну и в любом случае это был бы костыль который наверняка выходил бы боком в некоторых случаях.
Самое простое - вне "плотного" окна на рабочем столе лежит несколько ярлыков - пусть даже прозрачность "системного" окна позволяет их увидеть- как запустить соответствующие ярлыкам приложения не сворачивая "системного" окна?
В каждой OS свои нюансы. Ну например в пресловутой винде, если пиксел прозрачен на 100%, то и для кликов мышки оно будет прозрачно. Но там тоже какие-то нюансы есть.
-
Ну и в любом случае это был бы костыль который наверняка выходил бы боком в некоторых случаях.
Самое простое - вне "плотного" окна на рабочем столе лежит несколько ярлыков - пусть даже прозрачность "системного" окна позволяет их увидеть- как запустить соответствующие ярлыкам приложения не сворачивая "системного" окна?
В каждой OS свои нюансы. Ну например в пресловутой винде, если пиксел прозрачен на 100%, то и для кликов мышки оно будет прозрачно. Но там тоже какие-то нюансы есть.
Я говорю про другое - не очень прозрачен (для меня) механизм трансляции сообщений (в частности связанных с щелчками и перемещениями мыши) - предположим
что они просочились в систему через обработчик "прозрачного" главного окна и по щелчку запустилось приложение соответствующее ярлыку -если это обычное
оконное приложение то произойдет потеря фокуса системным окном - то есть по факту разрабатываемое таким образом приложение будет себя вести как "развернутое на весь экран"
оконное приложение - что для даже для псевдо многозадачных систем не есть гуд
-
Точнее, я сильно сомневаюсь, что удастся полностью эмулировать СТАНДАРТНОЕ для скажем винды поведение оконного приложения, а если можно то решение будет настолько
"непрозрачным" для разработчика, что использовать его никто не будет.
-
Ну, например вот для такого (видимо я не слишком ясно объяснил, картинка покажет лучше)
Ну да, именно это. Именно это выпирание за границы окна я рассматриваю как баг (в программе или в системе или в исходном дизайне системы).
-
Ну, например вот для такого (видимо я не слишком ясно объяснил, картинка покажет лучше)
Ну да, именно это. Именно это выпирание за границы окна я рассматриваю как баг (в программе или в системе или в исходном дизайне системы).
А в чем заключается ошибочность?
-
А в чем заключается ошибочность?
В настоящем некомпьютерном стеклянном окне видно то, что находится за окном, на улице. То что находится на улице за окном не может вылезти здесь у меня в комнате за пределы окна.
-
А в чем заключается ошибочность?
В настоящем некомпьютерном стеклянном окне видно то, что находится за окном, на улице. То что находится на улице за окном не может вылезти здесь у меня в комнате за пределы окна.
А оно еще и изменять размеры, сворачиваться и перемещаться (обычно) не может :-)
Метафоры и аналогии всегда лгут.
-
А оно еще и изменять размеры, сворачиваться и перемещаться (обычно) не может :-)
Метафоры и аналогии всегда лгут.
Правильнее сказать , что они редко ИСЧЕРПЫВАЮЩЕ характеризуют обьект - скорее некоторую особенность. Но , например , окно содержит отображение некоторого обьекта(ов) (с точностью позволяющей его идентифицировать - ну отличить от других), над обьектами разрешен ряд операций... лично я (как пользователь) воспринял бы в штыки идею о необходимости полного раскрытия окна приложения для того что бы совершить это действие. И потом как быть с приложениями допускающими свертывание в трей -например переключатель языка клавиатуры? - они что ошибка дизайна?
-
:) :) Блин как вспомню ответ Ильи на подобное замечание в коровнике - "А вы читали Сиськина?" (и естественно со ссылкой ) - так весело становиться (ну это сейчас , а тогда , помню, взбесился)
-
И потом как быть с приложениями допускающими свертывание в трей -например переключатель языка клавиатуры? - они что ошибка дизайна?
Трей общеэкранный.
-
И потом как быть с приложениями допускающими свертывание в трей -например переключатель языка клавиатуры? - они что ошибка дизайна?
Трей общеэкранный.
я говорю про выпадающее меню (правая кнопка мыши на пиктограмме)...
-
я говорю про выпадающее меню (правая кнопка мыши на пиктограмме)...
И пиктограмма общеэкранная.
-
я говорю про выпадающее меню (правая кнопка мыши на пиктограмме)...
И пиктограмма общеэкранная.
Понятно , вопросов больше не имею ;D ;D ;D ;D ;D
-
Ну "общеэкранная" -- это внутрикомнатная, а не на улице за окном. Есть объекты в комнате (они рисуются поверх окон), а есть объекты на улице, которые видно только через окна.
-
Но я же говорю про МЕНЮ , которое (если верить Алексею)можно отрисовать только внутри окна если использовать SDL
-
Есть объекты в комнате (они рисуются поверх окон), а есть объекты на улице, которые видно только через окна.
Да, если задуматься, интересные метафоры в ИТ. Рабочий стол с окнами, через которые видны документы. :)
-
Есть объекты в комнате (они рисуются поверх окон), а есть объекты на улице, которые видно только через окна.
Представьте, что контекстное меню это объект, который "в комнате". Он должен оставаться целиком в поле зрения, хоть и вышел за пределы окна. По-моему, всё корректно.
Допустим, Вы взглянули в окно (настоящее) и увидели там автомобиль. Вы решили навести по нему справку, берёте с книжной полки справочник и открываете его. Почему Вы считаете, что этот справочник обязательно должен находиться в поле вашего зрения в створе с окном? А если Вы слегка повернулись так, что при этом справочник оказался не в створе, то что? он должен исчезнуть из поля зрения? Но ведь он продолжает оставаться в комнате, не смотря на то, что автомобиль, про который написано в справочнике, находится на улице.
-
Допустим, Вы взглянули в окно (настоящее) и увидели там автомобиль. Вы решили навести по нему справку, берёте с книжной полки справочник и открываете его. Почему Вы считаете, что этот справочник обязательно должен находиться в поле вашего зрения в створе с окном? А если Вы слегка повернулись так, что при этом справочник оказался не в створе, то что? он должен исчезнуть из поля зрения? Но ведь он продолжает оставаться в комнате, не смотря на то, что автомобиль, про который написано в справочнике, находится на улице.
Вполне убедительно. Мне надо будет пересмотреть свою точку зрения на то что вылезает за пределы окна.
-
:)
-
Чет я разубедился в возможности построения гуя на базе SDL после прочтения ветки. Хотя игрушку на нем наверно рационально делать.
-
Чет я разубедился в возможности построения гуя на базе SDL после прочтения ветки. Хотя игрушку на нем наверно рационально делать.
Игрушку, эмулятор (например Кроноса), полноэкранный видеоплеер - самое оно.
IDE, IM, File Manager - не стоит и пытаться (опять таки если предполагается использовать это дело в обычных системах не на полный экран).
-
Есть объекты в комнате (они рисуются поверх окон), а есть объекты на улице, которые видно только через окна.
Да, если задуматься, интересные метафоры в ИТ. Рабочий стол с окнами, через которые видны документы. :)
Напомнило сценку "Уральских пельменей": Нубук (http://www.youtube.com/watch?v=p7jMD2vGzns)
-
Чет я разубедился в возможности построения гуя на базе SDL после прочтения ветки. Хотя игрушку на нем наверно рационально делать.
Ну, например ETH Oberon, можно сделать и на SDL.
-
Чет я разубедился в возможности построения гуя на базе SDL после прочтения ветки. Хотя игрушку на нем наверно рационально делать.
Ну, например ETH Oberon, можно сделать и на SDL.
Именно. Это и есть по сути виртуальная машина.
Собственно помнится info21 как раз рассказывал почему ETH Oberon у него не прижился и почему так хорошо прижился BlackBox - потому, что BlackBox был такой родной, виндовозный, хорошо в винду интегрированный и с общепринятым интерфейсом. А ETH Oberon был вещью в себе со странным интерфейсом. Перейдя на SDL мы по сути лишаемся этого (пожалуй основного значимого) преимущества BlackBox над ETH Oberon. Не полностью конечно (все же из приложения нам все еще много проще достучаться до системных либ чем из ETH Oberon) но тем не менее.
Да: еще про SDL: например через SDL не сделать элементарного - например буфер обмена (с другими приложениями). Придется втыкать системозависимый костыль.
-
Да: еще про SDL: например через SDL не сделать элементарного - например буфер обмена (с другими приложениями). Придется втыкать системозависимый костыль.
Да что там буфер обмена, даже файл нельзя прочитать. ;)
-
Да: еще про SDL: например через SDL не сделать элементарного - например буфер обмена (с другими приложениями). Придется втыкать системозависимый костыль.
Да что там буфер обмена, даже файл нельзя прочитать. ;)
Это то как раз можно (http://wiki.libsdl.org/moin.cgi/CategoryIO).
-
Ну вот, файлы добавили. Со временем и буфер добавят.
-
Ну вот, файлы добавили. Со временем и буфер добавят.
Дык они это сто лет назад уже добавили. То есть это чуть ли не изначально было. А вот буфер обмена он как бэ нинужен для игродела. Так что его там и не будет.
-
А вот буфер обмена он как бэ нинужен для игродела. Так что его там и не будет.
http://wiki.libsdl.org/moin.cgi/Roadmap
Sam: Create API for clipboard support (check out PyGame)
-
А вот буфер обмена он как бэ нинужен для игродела. Так что его там и не будет.
http://wiki.libsdl.org/moin.cgi/Roadmap
Sam: Create API for clipboard support (check out PyGame)
Круто. Причем там уже и поддержка кучи окон сделано:
Complete
Sam: Add support for multiple windows
-
Собрал SDL 2.0. Буду пробовать насколько там эта самая многооконность с буферами обмена работает.
-
Возьмите лучше IUP и не партесь.
-
Возьмите лучше IUP и не партесь.
А чем оно лучше всяких там gtk/wx/qt?
-
Возьмите лучше IUP и не партесь.
А чем оно лучше всяких там gtk/wx/qt?
А чем лучше SDL?
-
Возьмите лучше IUP и не партесь.
А чем оно лучше всяких там gtk/wx/qt?
А чем лучше SDL?
Тем что оно нормально работает на например MacOS, и тем что там виджетов нет :-) кроме того sdl это не только графика.
-
Возьмите лучше IUP и не партесь.
А чем оно лучше всяких там gtk/wx/qt?
А чем лучше SDL?
Тем что оно нормально работает на например MacOS, и тем что там виджетов нет :-) кроме того sdl это не только графика.
Круто, однако.
-
Возьмите лучше IUP и не партесь.
Нет , нельзя , без геморроя на свою задницу никак нельзя....
-
Так что с SDL 2.0, подходит в качестве платформы для IDE?
-
Так что с SDL 2.0, подходит в качестве платформы для IDE?
Умозрительно - да. Но нужно проверить. Чем я и хочу заняться на досуге.
-
Так что с SDL 2.0, подходит в качестве платформы для IDE?
Умозрительно - да. Но нужно проверить. Чем я и хочу заняться на досуге.
И каким образом будет переноситься модуль HostWindows на этот SDL?
-
Так что с SDL 2.0, подходит в качестве платформы для IDE?
Умозрительно - да. Но нужно проверить. Чем я и хочу заняться на досуге.
И каким образом будет переноситься модуль HostWindows на этот SDL?
Понятия не имею. Я рассматриваю с позиции IDE вообще, и Оберона в частности.
А что касается BB - думаю стоит посмотреть как аналог этого модуля был сделан для BB под MacOS, и обобщить.
-
и тем что там виджетов нет :-)
Хочется самому порисовать? ;)
-
и тем что там виджетов нет :-)
Хочется самому порисовать? ;)
Ага :-) Нативные виджеты - зло (в случае если мы хотим кроссплатформенно), ибо гуй начинает разъезжаться. Я этого дела успел уже нахлебаться. Да и пересечение множеств нативных виджетов для разных платформ сводится к очень убогому общему подмножеству. Помнится на AWT пытались так писать в свое время, получалось убого.
-
ЧЯ мне интересен именно как среда исполнения компонентов, но не как среда разработки (IDE). Потому что как IDE нужно довольно много допиливать, чтобы выйти на достойный уровень современных IDE.
По-моему, нужно разделить концепцию объединённого каркаса ЧЯ и среды разработки. Иными словами, отделить каркас подобно .NET от Visual Studio.
-
Ага :-) Нативные виджеты - зло (в случае если мы хотим кроссплатформенно), ибо гуй начинает разъезжаться. Я этого дела успел уже нахлебаться. Да и пересечение множеств нативных виджетов для разных платформ сводится к очень убогому общему подмножеству. Помнится на AWT пытались так писать в свое время, получалось убого.
Native look and feel - рулит. Хотя взять окно и нарисовать все самому несравнимо проще. А вот чтоб это не вызывало отрицательных эмоций у пользователя... Даже из QT лезет этот не-native, так в него сколько вбухано человекочасов.
P.S. Хотя пользователи уже смирились с вебом... Может сразу туда посмотреть?
-
Native look and feel - рулит. Хотя взять окно и нарисовать все самому несравнимо проще. А вот чтоб это не вызывало отрицательных эмоций у пользователя... Даже из QT лезет этот не-native, так в него сколько вбухано человекочасов.
А что QT? Оно нативно только на маке, ибо поделие яблочное. Под виндой оно конечно убого смотрится. Как и iTunes тот же самый.
Ну, а если про gui-либы говорить, то я не видел ни одной гуйной либы которая бы имела нативные виджеты и при этом где не возникали бы жуткие геморрои с кроссплатформенным гуем. А вот если взять тот же swing, то скажем под маком тот же netbeans смотрится приятней некоторых нативных приложений (с нативными виджетами). Приятней того же eclipse, который писан на swt и где стараются использовать таки нативные виджеты. Ну а под виндой тем более.
P.S. Хотя пользователи уже смирились с вебом... Может сразу туда посмотреть?
А толку туда смотреть, если IDE лучше все же не в браузере делать? Ну и ряд некоторых иных приложений тоже. Ради оффлайн работы на десктопе/ноуте разводить на этой же машине веб-сервер и грузить браузер выглядит несколько извратно :-)
-
ЧЯ мне интересен именно как среда исполнения компонентов, но не как среда разработки (IDE). Потому что как IDE нужно довольно много допиливать, чтобы выйти на достойный уровень современных IDE.
По-моему, нужно разделить концепцию объединённого каркаса ЧЯ и среды разработки. Иными словами, отделить каркас подобно .NET от Visual Studio.
Ну, вообще Оберон (и его производные) когда его извлекаешь из родной среды (ББ, ОС Оберон, A2), то он сразу теряет свою прелесть. Оберон хорош триединством - язык+среда исполнения+среда разработки. Сегодня это как раз обсуждалось в джаббер-конфе.
PS. Хотя мне конечно Оберон сейчас интересен как чисто язык.
-
А что QT? Оно нативно только на маке, ибо поделие яблочное. Под виндой оно конечно убого смотрится. Как и iTunes тот же самый.
Я говорю про http://en.wikipedia.org/wiki/Qt_(framework), а не про QuickTime ;)
Ну, а если про gui-либы говорить, то я не видел ни одной гуйной либы которая бы имела нативные виджеты и при этом где не возникали бы жуткие геморрои с кроссплатформенным гуем. А вот если взять тот же swing, то скажем под маком тот же netbeans смотрится приятней некоторых нативных приложений (с нативными виджетами). Приятней того же eclipse, который писан на swt и где стараются использовать таки нативные виджеты. Ну а под виндой тем более.
Дык, никто не говорит, что все хорошо с нативными виджетами. Я говорю, что отказавшись от самой идеи "рисуем гуй на одной платформе, затем он работает на другой" можно получить достойный гуй теми же затратами, что и пытаясь сделать мегафрэймворк для того, чтобы эта идея все таки работала. Причем чем выше планка к качеству гуя, тем больше усилий требует мегафрэймворк.
Я не люблю мегафрэймворки. Поэтому я бы предпочел иметь свою гуевую либу на каждой из платформ. Да, и рисовать гуй ручками для каждой платформы. Это не так страшно, как звучит :) Просто рисовать надо только гуй. Все остальное покрыто юниттестами и одинаково для всех платформ.
А толку туда смотреть, если IDE лучше все же не в браузере делать? Ну и ряд некоторых иных приложений тоже. Ради оффлайн работы на десктопе/ноуте разводить на этой же машине веб-сервер и грузить браузер выглядит несколько извратно :-)
Это из серии "если бы нужно было сделать гуй для нескольких платформ здесь и сейчас?". То я бы сначала посмотрел на HTML5 :)
-
Я говорю про http://en.wikipedia.org/wiki/Qt_(framework), а не про QuickTime ;)
Но сказал то QT а не Qt :-)
Дык, никто не говорит, что все хорошо с нативными виджетами. Я говорю, что отказавшись от самой идеи "рисуем гуй на одной платформе, затем он работает на другой" можно получить достойный гуй теми же затратами, что и пытаясь сделать мегафрэймворк для того, чтобы эта идея все таки работала. Причем чем выше планка к качеству гуя, тем больше усилий требует мегафрэймворк.
Согласен. Поэтому по работе мы не ваяем мегафреймворк для скажем андроида и iOS. Пишем две разные программы (с возможно общими алгоритмами) - это получается быстрее и качественнее.
Но вот инструментарий (внутренний), где трубуется GUI, который должен смотреться не великолепно, а просто нормально/не слишком тошнотворно и при этом работать на всех компах что у нас есть, мы частенько пишем на java/swing. Просто потому, что это банально быстрее и смотрится он одинаково (хорошо/плохо) везде. То есть пиксель в пиксель одинаково.
Я вижу за связкой Оберон+SDL именно такое вот применение - там где меганативность и графика не важна, но важна скорость разработки и точная одинаковость на всех платформах. В частности это может быть и IDE.
Если где-то нужна супернативность и вах какой интерфейс, то там нужно конечно уже делать биндинги к нативным гуям. К какаве, к gtk/qt, к WinAPI/WinRT.
Я не люблю мегафрэймворки. Поэтому я бы предпочел иметь свою гуевую либу на каждой из платформ. Да, и рисовать гуй ручками для каждой платформы. Это не так страшно, как звучит :) Просто рисовать надо только гуй. Все остальное покрыто юниттестами и одинаково для всех платформ.
Это зависит от задачи же :-)
Это из серии "если бы нужно было сделать гуй для нескольких платформ здесь и сейчас?". То я бы сначала посмотрел на HTML5 :)
Да ну нафик. Я как то со swing'ом свыкся. Работает неплохо :-)
-
То есть мегафреймворк он возникает когда пытаются в одной либе смешать сразу все - и чтобы было можно сделать супернативный гуй, и чтобы сразу кроссплатформенно - один раз написал, смотрится супернативно и круто везде.
Как по мне, это неподъемная задача. И нам туда не надо :-)
-
То есть нужен обероно-тиктакл...на современной графической платформе...
-
То есть нужен обероно-тиктакл...на современной графической платформе...
Ну типа того. И при этом без tcl :-) И чтобы свои виджеты можно было делать не выходя из уютненького Оберона. Ну и вообще чтобы гибкое, но не слишком кривое и монструозное :-)
-
То есть, по факту, это будут задачи.. прототипирования.
-
То есть, по факту, это будут задачи.. прототипирования.
Прототипирование, написание инструментария (программистского, научного и т.п.), всякие разные SCADA ну и т.п. Игры опять же :-) Применение довольно широкое.
-
То есть, по факту, это будут задачи.. прототипирования.
Прототипирование, написание инструментария (программистского, научного и т.п.), всякие разные SCADA ну и т.п. Игры опять же :-) Применение довольно широкое.
По сути вы предлагаете только TRUE кроссплатформенность и современную графическую основу... в сравнении с наитивным ББ... - вы считаете что это было причиной того, что он не пошел в массы? - все дело в технике исполнения?
-
Это из серии "если бы нужно было сделать гуй для нескольких платформ здесь и сейчас?". То я бы сначала посмотрел на HTML5 :)
Кстати, я вот подумал и понял почему мне html5 не кажется хорошим решением (а тебе похоже кажется) - просто у меня весь подобный (кроссплатформенный) гуй весьма специфичен - это либо какое-нибудь реалтаймовое видео (720p 30 fps) (для справки - то что видишь на ютубе это не оно) которое в html5 фиг завернешь, либо это какой-нибудь бешеный реалтаймовый график (группа графиков) который рисовать меньше чем 60 fps никак нельзя (иначе он уж очень по уродски смотрится). Собственно тут даже Qt и Swing так себе справляются (местами приходится костыли втыкать). А вот гуйня на базе SDL отлично справится со всем этим.
На сколько я понимаю, у тебя существенно другая специфика гуя :-)
-
Прототипирование, написание инструментария (программистского, научного и т.п.), всякие разные SCADA ну и т.п. Игры опять же :-) Применение довольно широкое.
По сути вы предлагаете только TRUE кроссплатформенность и современную графическую основу... в сравнении с наитивным ББ... - вы считаете что это было причиной того, что он не пошел в массы? - все дело в технике исполнения?
Нет. Не считаю. Там было много причин и это предмет отдельного разговора в отдельной ветке.
Я же хочу нечто подобное попробовать во-первых (и в главных) for fun, во-вторых потому, что это хорошо ложится на те задачи с которыми я сталкиваюсь и сталкивался, в-третьих, чтобы облегчить молодежи-новичкам, которые конечно же хватаются писать именно игру (сам таким был) как можно быстрее упереться в сложность задачи а не в сложность инструмента (в сложность инструмента упереться сейчас возможностей более чем достаточно).