Здравствуйте, vladserge, Вы писали: V>сел, написал
А как же полупрозрачное переднее стекло? V>сравнил, сомнения остались
А, то есть тебя не напрягает писать 207 строк вместо 108. Тогда конечно, непонятно зачем это все.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vladserge, Вы писали: V>>сел, написал S>А как же полупрозрачное переднее стекло? V>>сравнил, сомнения остались S>А, то есть тебя не напрягает писать 207 строк вместо 108. Тогда конечно, непонятно зачем это все.
я догадывался, возможно у кой кого будет соблазн вести такой подсчет, но надеялся что таких тут нет, оказалось их есь у нас.
намекаю, подсчет не верен, нужно выбросить код заливки картинки, код отображения и закрытия фрэйма + стрелочки у меня заостренные(и могут быть любыми). + мое решение всеплатформенное.
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, c-smile, Вы писали:
CS>>Я не понял а что такое XML?
Кё>Язык на основе XML, наилучшим образом подходящий для описания UI.
Понял, спасибо. Осталось выяснить какой именно придумывать язык.
Одна из серьезнейших проблем — learning curve. Это сурово.
CS>>XML и ASCII — это способы описания данных но не язык в чистом виде. CS>>Что ты имеешь ввиду конкретно?
Кё>В HTML есть фиксированный набор тэгов, семантика которых довольно неудобна. <SPAN> <DIV> — наиболее общие, <B> <I> <P> <H1> — какие-то частные случаи, фактически дублирующие <SPAN> или <DIV>. Это было хорошо давным-давно, до CSS, в самом начале языков разметки. С появлением CSS это только мешает.
Определить систему стилей — и гори оно огнем, нет?
В конце концов — используй DIV и SPAN только.
Но тут есть одна глобальная штука которая перевесила в свое время мои аналогичные рассуждения.
У меня досточно часто возникает проблема — вижу диалог — хочу его взять и загнать в clipboard.
Ну потребовалось мне имя файла например, а оно в поле static. Что делать?
В HTMLayout ты сейчас включаешь режим text selection и копирушь то что надо.
С сохранением структуры/семантики.
Кё>Я имею ввиду возможность, например, один раз определить тэг <button>, который потом развернется скажем в <DIV style="display: inline-block"> + текст с присоединённым к нему базовым CSS. Потом можно натыкать этих тэгов-кнопок по всему диалогу. Это и улучшит понятность исходника UI, уменьшит ошибки связанные с Copy+Paste, да и просто уменьшит размер UI.
Нет проблем. Описываем требуемую XML грамматику. Берем XML парсер SAX типа и генерим DOM
который нам надо. см. htmlayout::dom::element::create.
Соль и перец в виде CSS добавляем по вкусу.
И расматриваем наличие встроенного HTML парсера как бонус.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, vladserge, Вы писали:
V>>Здравствуйте, Sinclair, Вы писали:
S>>>Я тебе рекомендую сесть и написать апплет "стрелочные часы" используя общепринятый подход.
V>>сел, написал V>>сравнил, сомнения остались
CS>Клево
CS>Только идея на самом деле не о том чтобы нарисовать стрелки — это к тому же на win API получилось проще чем на Java.
а у меня стрелочки заостренные
CS>Ну да ладно — и так понятно что задачу можно и должно решить способом подходящим CS>к данному контексту — сиречь не одним единственным. CS>Спасибо тебе vladserge большое — вельми показательно.
спасибо польщен. В свою очередь хотел бы отметить незгладимое впечатление от J-SMILE
особенно своя VM, это сильно! у меня масса притензий к стандартной реализации JAVA.
Ваша реализация гараздо ближе к идеалу, без балды.
Здравствуйте, vladserge, Вы писали:
V>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, vladserge, Вы писали: V>>>сел, написал S>>А как же полупрозрачное переднее стекло? V>>>сравнил, сомнения остались S>>А, то есть тебя не напрягает писать 207 строк вместо 108. Тогда конечно, непонятно зачем это все.
V>я догадывался, возможно у кой кого будет соблазн вести такой подсчет, но надеялся что таких тут нет, оказалось их есь у нас. V>намекаю, подсчет не верен, нужно выбросить код заливки картинки, код отображения и закрытия фрэйма + стрелочки у меня заостренные(и могут быть любыми). + мое решение всеплатформенное.
Не обижайся. Проблема-то не в тебе лично или количестве строк — оно действительно примерно одинаковое
для данной конкретной задачи "рисуем ходики".
Я лично хотел продемонстрировать как можно на существующий DOM со всеми его прибамбасами
цеплять свой код. И только в то место где он действительно нужен. Не больше и не меньше.
И еще наличие HTML/CSS это само по себе конечно хорошо но
наличие HTMLayout как сущности расширяет возможности UI. Когда этот самый
UI собирается у пользователя из разных кусков однвременно : что-то из ресурсов
что-то из БД а что-то свежее подкачалось с твоего сайта.
Я утверждаю что грядет эра специализированных броузеров. И надо быть к этому готовым.
V>
CS>>Ну да ладно — и так понятно что задачу можно и должно решить способом подходящим CS>>к данному контексту — сиречь не одним единственным. CS>>Спасибо тебе vladserge большое — вельми показательно.
V>спасибо польщен. В свою очередь хотел бы отметить незгладимое впечатление от J-SMILE V>особенно своя VM, это сильно! у меня масса притензий к стандартной реализации JAVA. V>Ваша реализация гараздо ближе к идеалу, без балды.
Там абсолютно ничего нет военного.
Собственно береш http://waba.sourceforge.net и чикаешь под себя.
Я там добавил работу с double — по моему этого там не было.
C GC там помнится чего-то сделал.
И c threads все упростил. Кому упали те ThreadGroups я так и не понял.
Ну и четыре нативных GUI класса вмуровал вовнутрь.
Самое ценное там имхо именно сама система java классов
— это то что действиельно хорошо получилось.
Здравствуйте, vladserge, Вы писали:
V>Здравствуйте, c-smile, Вы писали:
CS>>Нет проблем. Описываем требуемую XML грамматику. Берем XML парсер SAX типа и генерим DOM V>
V>я конечно понимаю, такой вопрос задавать не модно и все такое... а сколько это чудо отъедает памяти? Насколько адекватно?
Почему это не модно?
DOM элемент в HTMLayout (например div и p) это примерно 80 байт.
Плюс каждый элемент хранит ссылку на стиль. Стили хранятся компактно —
каждый уникальный стиль хранится в одном экземпляре.
Плюс если есть текст то он хранится как wchar_t строка.
Это то что я аллоцирую на хипе. Но как при этом memory manager запрашивает
память у системы — то мне не ведомо. Будет время поэксперементирую со своим
собсвенным аллокаторм. Но пока проблем больших нет. У меня сам DOM
устроен таким образом что он не сильно напрягает аллокатор.
Фишка на самом деле в другом. HELEMENT это фактически
ссылка на мой DOM элемент и все операции с ним осуществляются
в "темпе вальса" — практически напрямую.
CS>DOM элемент в HTMLayout (например div и p) это примерно 80 байт. CS>Плюс каждый элемент хранит ссылку на стиль. Стили хранятся компактно — CS>каждый уникальный стиль хранится в одном экземпляре. CS>Плюс если есть текст то он хранится как wchar_t строка.
спасибо за ответ, для меня главное, что тебе не безразличен этот аспект .
Здравствуйте, vladserge, Вы писали:
V>Здравствуйте, c-smile, Вы писали:
CS>>DOM элемент в HTMLayout (например div и p) это примерно 80 байт. CS>>Плюс каждый элемент хранит ссылку на стиль. Стили хранятся компактно — CS>>каждый уникальный стиль хранится в одном экземпляре. CS>>Плюс если есть текст то он хранится как wchar_t строка.
V>спасибо за ответ, для меня главное, что тебе не безразличен этот аспект .
Еще как небезразличен.
Вот кстати нормальная такая идея:
Сделать exe cо встроенной или стандартной java machine.
Типа скажем appletviewer + htmlayout.
Ввести через JNI API htmlayout в java в удобоваримом виде.
Чтобы те же behaviors писать на Java. По моему очень даже ничего
получится. Я собираюсь выпустить также Мак версию.
Здравствуйте, c-smile, Вы писали:
CS>(извиняюсь за назойливость)
CS>Это собственно демонстрация идеи: UI можно в принципе делать "малой кровью" CS>программируя только то что действительно надо прогаммировать.
Красиво, ещё б к этому великолепию Python-bindings , может месяца за два как освобожусь попробую, а то уж больно красиво всё выглядит, а попробывать не выходит.
CS>Еще раз извиняюсь за настырность.
всем бы такую настырность и мы б горы свернули
Здравствуйте, Stoune, Вы писали:
S>Здравствуйте, c-smile, Вы писали:
CS>>(извиняюсь за назойливость)
CS>>Это собственно демонстрация идеи: UI можно в принципе делать "малой кровью" CS>>программируя только то что действительно надо прогаммировать.
S>Красиво, ещё б к этому великолепию Python-bindings , может месяца за два как освобожусь попробую, а то уж больно красиво всё выглядит, а попробывать не выходит.
"А зачем нам кузнец?"
Там JavaScript будет в скором времени...
Здравствуйте, c-smile, Вы писали: S>>Красиво, ещё б к этому великолепию Python-bindings , может месяца за два как освобожусь попробую, а то уж больно красиво всё выглядит, а попробывать не выходит.
CS>"А зачем нам кузнец?" CS>Там JavaScript будет в скором времени...
Я в том смысле что сама по себе идея Python binding клевая.
Но если просто ради скриптинга то там будет JS.
Здравствуйте, Mamut, Вы писали:
M>Вопрос. Хотел задать на форуме терраинформатики, но лень
M>Интересует следующее: drag'n'drop и scrollbars.
M>Идея в чем. Если имплементировть popup диалоги, например, об ошибках или перетягивать элементы с одного узла дерева в другой, то нужен drag'n'drop.
popup диалоги в общем-то делаются "в лоб". Просто окнами-диалогами. Или я не понял идею.
Это и сейчас возможно. но наверное имеет смысл мне сделать заготовку для этого.
А вот drag'n'drop тема нетривиально интересная.
В принципе это дело специального behavior. behavior могут рисовать поверх всего и в любом месте документа.
Это относится и к behaviors в C++ и к scripting behaviors.
В том числе с помощью behaviors/api можно нарисовать любой блочный элемент в любой области документа.
drag'n'drop несколько специфичен в каждом случае поэтому придется выбирать из возможных вариантов —
стандартного механизма не будет по всей видимости — придется делать руками каждый раз.
Вот это вопрос тоже интересный. Во первых нормальные scrollable tables (aka grid) — на повестке дня.
В ближайшее время будут.
Во-вторых, виртуальные списки как сущность.
В общем случае количество записей в таком списке неизвестно или операция по его подсчету дорогая (справедливо для большинства rDB). Поэтому в общем-то scrollbar вырождается в нечто другое — navigational bar — next/prev page или
ленту (например в EverNote).
Как я это вижу: с моей стороны надо сделать нечто что позволит поддержать визуальный рендеринг EverNote ленты.
Вот над этим надо думать.
А scrollbars... Это не самая удобная штука для больших наборов.
Большие наборы это persona non grata в usability. Как правило это решается по другому (см. Picassa/Google, EverNote/EverNote)
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, c-smile, Вы писали: S>>>Красиво, ещё б к этому великолепию Python-bindings , может месяца за два как освобожусь попробую, а то уж больно красиво всё выглядит, а попробывать не выходит.
CS>>"А зачем нам кузнец?" CS>>Там JavaScript будет в скором времени...
CS>Я в том смысле что сама по себе идея Python binding клевая.
Просто задрали меня эти кросплатформенные ГУИ я всё равно под винду пишу, а нативные что идут слишком кривые, вот тута попробовал Layered Windows использовать сразу несколько багов в реализации pywin32 всплыло. CS>Но если просто ради скриптинга то там будет JS.
Ну я скриптингом не занимаюсь, хотя иногда надо кое-чего на WSH сделать, только для меня это легче на Python.
А вообще я хочу нормальный движок для скинов, в последнее время юзвера хотят нестанадртный интерфейс, ваш движок имеет как будто некоторые задатки для этого.
CS>popup диалоги в общем-то делаются "в лоб". Просто окнами-диалогами. Или я не понял идею. CS>Это и сейчас возможно. но наверное имеет смысл мне сделать заготовку для этого.
Для попапов я такое, в принципе, и предпологал. Почему я их упомянул, потому что иногда не всегда удобно создавать новое окно (например, при работе с отдаленной от платформы системой типа LISP + UFFI + HTMLayout ). Но и это решаемо.
CS>А вот drag'n'drop тема нетривиально интересная. CS>В принципе это дело специального behavior. behavior могут рисовать поверх всего и в любом месте документа. CS>Это относится и к behaviors в C++ и к scripting behaviors. CS>В том числе с помощью behaviors/api можно нарисовать любой блочный элемент в любой области документа. CS>drag'n'drop несколько специфичен в каждом случае поэтому придется выбирать из возможных вариантов - CS>стандартного механизма не будет по всей видимости — придется делать руками каждый раз.
Хм... *почесал в затылке* Это дело надо обдумать (как только я все же доберусь до копания поближе). Конечно, хотелось бы общие события типа onDragStart, onDragStop, onDragHit. Но это, дейстительно нетривиально и имплементация ручками будет лучше. Буду думать
CS>К слову, я собираюсь сделать нечто типа Canvas в Safari CS>http://developer.apple.com/documentation/AppleApplications/Reference/SafariJSRef/Classes/Canvas.html CS>(Если с Максом Шеманаревым договоримся то может будет AGG графика)
Здорово
M>>Scrollbars нужны для эмуляции таблиц большого размера.
CS>Вот это вопрос тоже интересный. Во первых нормальные scrollable tables (aka grid) — на повестке дня. CS>В ближайшее время будут.
CS>Во-вторых, виртуальные списки как сущность. CS>В общем случае количество записей в таком списке неизвестно или операция по его подсчету дорогая (справедливо для большинства rDB). Поэтому в общем-то scrollbar вырождается в нечто другое — navigational bar — next/prev page или CS>ленту (например в EverNote).
CS>Как я это вижу: с моей стороны надо сделать нечто что позволит поддержать визуальный рендеринг EverNote ленты. CS>Вот над этим надо думать.
CS>А scrollbars... Это не самая удобная штука для больших наборов. CS>Большие наборы это persona non grata в usability. Как правило это решается по другому (см. Picassa/Google, EverNote/EverNote)
Я имел в виду скроллбары, как например в Лингво или том же Outlook'е. То есть, их единственное предназначение — сообщать, что мол трекер передвинут на такую-то дельту. Естественно, это можно ручками обработать (все же, это тот же drag'n'drop), но хотелось бы встроенной функциональности
1.1.4 stable rev. 510
