Здравствуйте, LaPerouse, Вы писали:

I>>>Ну что ты, swing это круто !!!
C>>Уже нет HTMLayout круче.
LP>Может, для начала сделаешь docking manager для него?
LP><Шепотом, чтобы враги не услышали >: В WPF они есть.
Возможная реализация их есть в примерах. Мне, лично, они нафиг не сдались.

Здравствуйте, LaPerouse, Вы писали:

C>>В качестве первого приближения — XAML. Байндинги там на твёрдую четвёрку сделаны.
LP>А при чем здесь байндинги? Байндинг — это привязка данных к отображению, editors — это изменение данных. Байндинг для JTable делается через TableModel и никакого отношения к CellEditor-ам не имеет. Ты можешь сделать байнинги как в xaml или еще черт-знает где, но от editor-ов никуда не деться, если конечно тебе нужна нормальная таблица.
Таки посмотри как XAML работает...

LP>Вот пример. В моем приложении в таблице отображаются вектора токов, напряжений, мощностей и т. п, текстовые данные, комлексные числа и пр. Для редактирования векторов используется компонента VectorEditor. Для редактирования текстовых данных — JTextField. Для редактирования комплексных чисел — JPanel с двумя полями для ввода реальной и мнимой частей. Чем предлагаешь заменить это хозяйство?
Всем тем же. Но как мне их поместить в таблицу? Проблема в том, что приходится делать ad-hoc модели и адаптеры-рисовальщики. Неудобно.

LP>Да нет же. Editor — это лишь указание контроллеру таблицы, с помощью чего он должен менять данные определенного типа в таблице. А то, как он инициирует процесс редактирования — это реализация контроллера такая. Изменив ее, можно иметь хоть тысячу редакторов активных одновременно (если памяти хватит).
Проблема в том, что таблицы вообще не должна знать ничего об editor'ах. Таблица должна заниматься layout'ом элементов управления, а как они там взаимодействуют уже с пользователем — не проблема таблицы.

LP>>>Интересно. Я как раз искал таблицу с rowspan/colspan, нашел какую-то платную хрень, но она убога. Можно эту таблицу поместить в свинговый или awt-ный контейнер?
C>>HTMLayout встраивается в SWING, у нас для этого специальный слой написан.
LP>Кстати, есть еще одна альтернатива свингу — RIA "apache pivot". На вид сыроват, но некоторые его хвалят.
Они пытаются придумать XAML, но без ресурсов MS у них фигня получится.

LP>>>1. Давно существует, хорошо известны недостатки, накоплен большой опыт использования.
C>>Угу, и его резюме: не надо использовать SWING.
LP>Да я бы с удовольствием, да нет альтернативы. Ты сам это признал ниже
Именно поэтому я начал развивать привязки HTMLayout для Java...

Здравствуйте, vdimas, Вы писали:

RO>>FreeType кажется какой-то чуждой, хотя эти продукты на порядок лучше того, что используют в MS.
V>FreeType на малых разрешениях сливает TrueType, а в больших уже не принципиально.

FreeType использует TrueType. И Type 1, и OpenType. Ты имел в виду ClearType? Давай сравним.

http://qwertty.com/tmp/ScreenTypographyTest-small.html


Курсивная Джорджия, размеры все в пикселях, так что отрисовка ClearType должна быть тех же габаритов.

V>требовать "правильно отрисовывать" этот тест на <300 DPI — более чем глупо. На таких разрешениях нужна читабельность, а не точность позиционирования.

Без точности не будет читабельности. Как отрисовать подряд несколько букв шириной 2,4 пикселя?

Здравствуйте, yuriylsh, Вы писали:

Y>

Есть и коммерческая.

Здравствуйте, Ikemefula, Вы писали:


T>>ИМХО, у WPF главная проблема — это высокий порог вхождения.

Не в этом дело. Просто налицо несколько перекрывающих функциональность друг друга абстракций, и разработчики порой как те ослы у двух стогов сена, только здесь стогов больше. Особенно проблема заметна в отсутствии нескольких действительно нужных абстракций, например реализации отдельно скинов (аналога CSS), есть шаблоны представления, шаблоны данных и т.д., но нет шаблонов-шаблонов представлений, к которым привыкли в вебе, и это реально неудобно. Я бы еще добавил, что нет шаблонов-шаблонов данных, наподобие динамической раскраски ячеек Excel в зависимости от данных. Т.е., все это легко реализовать в конкретном шаблоне представления или шаблоне данных, вбить в дизайн гвоздями (или же косвено через ресурсы, не суть), но на лету менять такие "скины данных" — этого встроенного нет. Разумеется, можно писать самим, как внешнюю либу, и таких велосипедов уже хватает, но вот тут и встает такой момент, что было бы неплохо, чтобы этот тул гладко вошел во взаимодейтствие со всеми остальными абстракциями и своими велосипедами.


I>Не у WPF, а у декларатвного и функционального программирования вообще.

Ну, у тех, у кого есть опыт десктопного+вебового GUI, WPF особой сложности не представляет, так что не изобретай и не пальцуйся перед коллегами, тем более, что GUI на XML во многих других GUI либах рисуют около десятка лет.


I>Винформс это вагон граблей и отсутствие методов решения. Например Ownerdraw есть сплошная проблема из за отсутсвия мало-мальского механизма отрисовки.

Owner draw был введен в win32 контролы для кастомизации их внешнего вида, а не создания других контролов на их основе. Ты не забыл, что сообщение идет паренту, а не самому себе? Это ключ к пониманию концепции, которая банальна в общем-то. Если в этой простой модели и может быть какая-то проблема, то лишь из-за лени разработчиков, экономящих на спичках, т.е. поленившихся написать контрол практически с 0-ля, и предпочитающих бороться с развитой функциональностью базовой оконной процедуры, вместо написания своей.

А вообще, сравнивать GDI, которому около 30-ти лет, и WPF крайне глупо. Для своего времени, сервис ОС по перерисовке элементов управления был способом создавать маленькие бинарные образы и нетребовательные к ресурсам приложения, т.к. прилична была доля кода, которая шарилась м/у приложениями через системные DLL. Именно потому графический UI Windows 3.1 на 386-х просто летал, а на линуксный GUI на тех же машинах хотелось лишь пристрелить, чтобы не мучался.

Т.е. это все верно было для случая, когда требуемая кастомизация отображения стандартных контролов минимальна, желательно — вообще отсутствует, как во всех системных утилитах виндов. В случае же желания рисовать все "с чистого листа", сервисы рисования ОС только мешают, в этом плане любая библиотека с собственной отрисовкой будет лучше GDI, и не потому, что GDI плохой, а потому что забыли озвучить требования перед обсуждением.

Здравствуйте, dr.Chaos, Вы писали:

DC>Странное дело, у меня тоже mergetool на C# писанный кошмарно долго рисуется по RDP, хотя KDE-шный Kompare мгновенно.

Пару лет назад мы разработали свой протокол для шаринга приложений и пробовали при этом разные технологии для определения изменившихся областей экрана. Так вот, что интересно, хотя технология mirror driver, которую использует серверный компонент RDP и есть самая экономная в плане ресурсов сервера, но она же и самая неподходящая, если у гуиписателя руки не из того места растут. Т.е. надо перерисовать маленькую часть GUI, вместо этого современные программисты тупо делают refresh/invalidate всего и не парятся. Тоже самое при двойной буферизации. Поэтому сейчас, ввиду того, что интернет до сих пор не такой уж быстрый, а ресурсы современного компа ого-го, гораздо лучший результат дает технология тупого сканирования кадров с некоторой частотой, сравнения с предыдущими и кодировки только разницы.

Здравствуйте, vdimas, Вы писали:

V>Не в этом дело. Просто налицо несколько перекрывающих функциональность друг друга абстракций, и разработчики порой как те ослы у двух стогов сена, только здесь стогов больше. Особенно проблема заметна в отсутствии нескольких действительно нужных абстракций, например реализации отдельно скинов (аналога CSS), есть шаблоны представления, шаблоны данных и т.д., но нет шаблонов-шаблонов представлений, к которым привыкли в вебе, и это реально неудобно. Я бы еще добавил, что нет шаблонов-шаблонов данных, наподобие динамической раскраски ячеек Excel в зависимости от данных. Т.е., все это легко реализовать в конкретном шаблоне представления или шаблоне данных, вбить в дизайн гвоздями (или же косвено через ресурсы, не суть), но на лету менять такие "скины данных" — этого встроенного нет. Разумеется, можно писать самим, как внешнюю либу, и таких велосипедов уже хватает, но вот тут и встает такой момент, что было бы неплохо, чтобы этот тул гладко вошел во взаимодейтствие со всеми остальными абстракциями и своими велосипедами.
Что-то многих так и тянет сравнивать WPF с HTML и, не найдя привычных вещей, декларировать, что WPF крива... Но это я придираюсь, да и кривости есть местами.
Но интересно другое! Что это за шаблоны шаблонов такие? Какая нужна функциональность?

Здравствуйте, vdimas, Вы писали:

V>Owner draw был введен в win32 контролы для кастомизации их внешнего вида, а не создания других контролов на их основе. Ты не забыл, что сообщение идет паренту, а не самому себе? Это ключ к пониманию концепции, которая банальна в общем-то.

И что с того ? Отрисовка все равно убогая и даже для этой цели ownerdraw убог, при чем безнадежно.

V>А вообще, сравнивать GDI, которому около 30-ти лет, и WPF крайне глупо.

Оконная система недалеко ушла от GDI.

Здравствуйте, Roman Odaisky, Вы писали:

RO>Без точности не будет читабельности. Как отрисовать подряд несколько букв шириной 2,4 пикселя?

Как их читать затем?
Зачем переставлять местами причину и следствие? Уже вроде недавно об этом же поговорили, а ты все за свое...

Надо исходить из того, что есть, а есть около 100 DPI на современных мониторах, как бы тебе не хотелось иного. Для предпросмотра в системах верстки можно рендерить без хинтинга, чтобы убедиться, что все на месте, но для чтения — обязательно хинтинг со всеми искажениями в пользу позиционирования по пикселям, иначе зрению хана.

Здравствуйте, Ikemefula, Вы писали:


V>>Где именно она быстрее? На отрисовке сложных сцен? Ну так и уточняй. А пока что обычные GUI-приложения (где обычно десяток-другой контролов) WinForms запускаются в 2-3 быстрее и окошки заметно быстрее открываются.

I>При чем здесь сцены ? Читай свою же писанину

С первого раза не втыкается?
Попробуй не с первого. Хотя, и так понятно, где ты слажал — в термине "сцена". Издержки поверхностной эрудиции?


V>>WPF в плане быстордействия обгоняет традиционный GDI пока только там, где много контролов и визуальных эффектов. Не уверен, что пора уже все обычные приложения украшать рюшечками эстетики ради, если за это мы поплатимся заметной разницей в скорости запуска приложения. Так что на сегодняшней реальности WPF — это вовсе не тул общего назначения.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, vdimas, Вы писали:

V>>И зря ты пытаешься спорить с WPF на их поле, преимущество HTMLayout совершенно в другом — факт использования его в многих очень известных программах тому подтверждение. Точно так же как отсутствие факта использования WPF хоть в какой-нить более-менее известной программе, кроме беты MS VS 2010.
C>AutoCAD использует WPF для интерфейса.

Ну, автокад такого многогигового размера, что весь дотнет на его фоне теряется. А из повседневных программ? Почему MS вместо того, чтобы делать офис 2010 на WPF продолжает долбить его на С++? И кстати, судя по второй бете, это неплохо у них получается — MS Word запускает и работает гораздо шустрее предыдущих версий, по эффективности где-то на уровне Word 97. (ИМХО, Офис XP открыл линейку тормозных реализаций, похоже они это наконец поняли)

Здравствуйте, MxMsk, Вы писали:

MM>Но интересно другое! Что это за шаблоны шаблонов такие? Какая нужна функциональность?

Нужен аналог CSS, нужен доп. аттрибут аналогичный class="someCssClass" в HTML+CSS. Насколько я знаю, сейчас можно задать стиль только по типу элемента и его ID (x::Key), что есть статическое прибивание гвоздями. Нужен стиль, вот как меню на DHTML делаются? Активному элементу присваивается какой-нить class="menuSelected", и оно отображается не так, как остальные пункты.

Нужна система стилей, отвязанная от конкретных контролов, их типов и их ID, ибо слишком большая связанность получается. В принципе, все уже придумано в CSS. К тому же описывать стили в XML, в виде <Setter Property="" Value=""> — это чокнуться, очень плачевно.

И особено смешно, когда поднимается разговор о стилях, и кто-то пытается отсылать к функциональности связки св-в с динамическими или статическими ресурсами, которые в концептуальном плане недалеко ушли от ресурсов винапи.

Здравствуйте, Ikemefula, Вы писали:

I>И что с того ? Отрисовка все равно убогая и даже для этой цели ownerdraw убог, при чем безнадежно.

У тебя точно мысли не путаются?
Что для какой цели и почему убог именно owner draw, а не возможности используемого им GDI? Ты точно понимаешь, для чего owner draw нужен?
Скажу, что любой контрол можно закастамизировать безо всякого owner draw, напр. TabCtrl, owner draw вызывается только в том случае, если ты не переопределил процедуру рисования, т.е. если используется рисование по-умолчанию и стоит флаг owner draw, который говорит о том, что ты хочешь вмешаться лишь в процесс рисования табов, например, чтобы иконки там свои или как-нить табы цветом выделить. Хочешь полностью кастомно отрисовать — перехвати WM_PRINT/WM_PAINT/WM_ERASEBACKGROUND и рисуй сам с 0-ля как хочешь. Прицепи либу AGG, и нарисуешь все, что сможешь нарисовать в WPF.


V>>А вообще, сравнивать GDI, которому около 30-ти лет, и WPF крайне глупо.

I>Оконная система недалеко ушла от GDI.

Как она может от него уйти, если она на нем построена.
Че-то ты сегодня уже не впервой невпопад отвечаешь. Не выспался? Или откровенно не разбираешься в вопросе и нагло троллишь?

Здравствуйте, vdimas, Вы писали:

V>Ну, автокад такого многогигового размера, что весь дотнет на его фоне теряется. А из повседневных программ? Почему MS вместо того, чтобы делать офис 2010 на WPF продолжает долбить его на С++?

А почему не на HTMLayout или QT? Или что тут еще проскакивало — Swing? Вроде сто раз уже это обсуждалось...

Здравствуйте, vdimas, Вы писали:

V>Есть и коммерческая.

А! Так вот о какой жадности Turtle.BAZON.Group говорил...

Здравствуйте, yuriylsh, Вы писали:

V>>Почему MS вместо того, чтобы делать офис 2010 на WPF продолжает долбить его на С++?

Y>А почему не на HTMLayout или QT? Или что тут еще проскакивало — Swing?

Если брать MS Word, Excel, PP, то они сами себе HTMLayout. Тут надо спрашивать, почему не на AGG или похожей либе?
Так вот, DirectX мог бы ускорить всякие прокрутки и масштабирования. Далее, приложения офиса все-равно хранят как-то визуальные элементы в памяти — это могла быть одна и та же иерархия, корнем из дотнетного Visual.


Y>Вроде сто раз уже это обсуждалось...

И к чему пришли?

Здравствуйте, yuriylsh, Вы писали:

Y>А! Так вот о какой жадности Turtle.BAZON.Group говорил...

Он вообще сам с собой по большей части разговаривает. Что касается QT, если брать деньги за подобные качественные либы есть жадность... то чем бы вы там с BAZON не занимались, коль вам ЗП платят, и вы ее подло берете, вы те еще жлобы.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, MxMsk, Вы писали:

MM>>Но интересно другое! Что это за шаблоны шаблонов такие? Какая нужна функциональность?

V>Нужен аналог CSS, нужен доп. аттрибут аналогичный class="someCssClass" в HTML+CSS. Насколько я знаю, сейчас можно задать стиль только по типу элемента и его ID (x::Key), что есть статическое прибивание гвоздями. Нужен стиль, вот как меню на DHTML делаются? Активному элементу присваивается какой-нить class="menuSelected", и оно отображается не так, как остальные пункты.
Чем x:Key не аналог someCssClass?

V>Нужна система стилей, отвязанная от конкретных контролов, их типов и их ID, ибо слишком большая связанность получается. В принципе, все уже придумано в CSS. К тому же описывать стили в XML, в виде <Setter Property="" Value=""> — это чокнуться, очень плачевно.
А мне нравится

V>И особено смешно, когда поднимается разговор о стилях, и кто-то пытается отсылать к функциональности связки св-в с динамическими или статическими ресурсами, которые в концептуальном плане недалеко ушли от ресурсов винапи.
Ну да, по настоящему динамическими WPF-ные стили сделать не удастся. Если ссылку на стиль можно сделать динамической, то вот наследование (атрибут BasedOn) таким образом задать нельзя. Если бы MS открыл возможность пересоздания стилей по желанию, когда всё дерево заново конструируется, проблема бы пропала. Но пока этого нет и не знаю, появится ли. Поэтому, собственно, приходится жертвовать некоторыми достоинствами наследования, и тем не менее ничто не мешает менять связку "контрол-стиль" в рантайме.

Здравствуйте, vdimas, Вы писали:

V>У тебя точно мысли не путаются?
V>Что для какой цели и почему убог именно owner draw, а не возможности используемого им GDI? Ты точно понимаешь, для чего owner draw нужен?
V>Скажу, что любой контрол можно закастамизировать безо всякого owner draw, напр. TabCtrl, owner draw вызывается только в том случае, если ты не переопределил процедуру рисования, т.е. если используется рисование по-умолчанию и стоит флаг owner draw, который говорит о том, что ты хочешь вмешаться лишь в процесс рисования табов, например, чтобы иконки там свои или как-нить табы цветом выделить. Хочешь полностью кастомно отрисовать — перехвати WM_PRINT/WM_PAINT/WM_ERASEBACKGROUND и рисуй сам с 0-ля как хочешь. Прицепи либу AGG, и нарисуешь все, что сможешь нарисовать в WPF.
Да ладно. Понятно, что нарисовать можно всё что угодно, но таки кастомизация внешнего вида через контролы делается в WPF очень просто и наглядно.

Здравствуйте, vdimas, Вы писали:
V>У тебя точно мысли не путаются?
V>Что для какой цели и почему убог именно owner draw, а не возможности используемого им GDI? Ты точно понимаешь, для чего owner draw нужен?
V>Скажу, что любой контрол можно закастамизировать безо всякого owner draw, напр. TabCtrl, owner draw вызывается только в том случае, если ты не переопределил процедуру рисования, т.е. если используется рисование по-умолчанию и стоит флаг owner draw, который говорит о том, что ты хочешь вмешаться лишь в процесс рисования табов, например, чтобы иконки там свои или как-нить табы цветом выделить. Хочешь полностью кастомно отрисовать — перехвати WM_PRINT/WM_PAINT/WM_ERASEBACKGROUND и рисуй сам с 0-ля как хочешь. Прицепи либу AGG, и нарисуешь все, что сможешь нарисовать в WPF.

Обычай же ассирийских крестин был таков: как только у царя рождался младенец мужского, женского или иного пола, сейчас же специально обученный писарь садился и, взяв в руки клинья, начинал писать на глиняных плитах имя новорожденного. Когда, истомленный трудом, писарь падал мертвым, его сменял другой и так дальше до тех пор, пока младенец не достигал зрелого возраста. К этому сроку все его имя считалось полностью и правильно написанным до конца.

(с) Всеобщая история, обработанная Сатириконом