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

I>Правильно так — отрисковка в оконной системе виндов построена на GDI. Но сама оконная система виндов не сводится к отрисовке и потому в корне неверно утверждать что она построена на GDI.

Ну да, помимо отрисовки сама оконная система сводится еще к функциональности самой оконной системы.
Не надоело подставляться?

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

Y>Не очень понял условия задачи. Как в твоем примере с css будет разруливаться какое выделение применять (рамка, цвет, жирность)? Может ты изобразишь сначала свой пример? Пока по аналогии на WPF можно описать примерно так :

Y>

Y><Style TargetType="{x:Type Window}"> /*обычный*/</Style>
Y><Style x:Key="quot">/*цитата*/</Style>
Y><Style x:Key="code">/*код*/</Style>
Y><Style x:Key="sel">/*выделение*/</Style>
Y>

А как мне тогда задать отличие текста <H1> от <H2>?
Я же сказал, мало координат.

На самом деле все решаемо и я кое-какие попытки делал, например для x:Key можно ввести некий name convention, чтобы имя состояло из нескольких частей и прикрутить сверху некий хелпер-енжин, который этим управляет. Попытка реализовать вот ту описанную каскадность и аддитивность стилей и декларативную зависимость от взаимного расположения — вот тут я обломался, потому как дофига работы. Т.е. если встанет в реальном проекте необходимость — сделать можно, развлечения ради — слишком большая трудоемкость.

В принципе, тут не очем спорить, в интернете достаточно материала и сетований разработчиков на отсутствие функциональности, аналогичной каскадным стилям из HTML.

Даже такой момент — кто-нить видел, чтобы CSS-файлы продавали а деньги? А темы WPF/Silverlight продают аж бегом.

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


DC>Меня наоборот коробит от таких шрифтов, потому я просто поставил себе dpi 120 и средний хинтинг и глаза не устают и читать приятно.

Ну, если монитор x>2k, y>1.5k, то так и надо. Если нет, то крупный шрифт неудобен.

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

I>>Правильно так — отрисковка в оконной системе виндов построена на GDI. Но сама оконная система виндов не сводится к отрисовке и потому в корне неверно утверждать что она построена на GDI.

V>Ну да, помимо отрисовки сама оконная система сводится еще к функциональности самой оконной системы.

Нет, речь идет о "Windows provides three main categories of objects: user interface, graphics device interface (GDI), and kernel."

V>Не надоело подставляться?

Гуляй.

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

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

Y>>Не очень понял условия задачи. Как в твоем примере с css будет разруливаться какое выделение применять (рамка, цвет, жирность)? Может ты изобразишь сначала свой пример? Пока по аналогии на WPF можно описать примерно так :

Y>>

Y>><Style TargetType="{x:Type Window}"> /*обычный*/</Style>
Y>><Style x:Key="quot">/*цитата*/</Style>
Y>><Style x:Key="code">/*код*/</Style>
Y>><Style x:Key="sel">/*выделение*/</Style>
Y>>

V>А как мне тогда задать отличие текста <H1> от <H2>?
А для чего тебе их отличать? Стиль же не затирает базовый. Применишь его к нужному элементу и стиль перекроет только те свойства, setter-ы которых в нем заданы.

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

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


DC>>Меня наоборот коробит от таких шрифтов, потому я просто поставил себе dpi 120 и средний хинтинг и глаза не устают и читать приятно.

V>Ну, если монитор x>2k, y>1.5k, то так и надо. Если нет, то крупный шрифт неудобен.

Тебе неудобен (как и мне, зрение у меня хорошее). Но я знаю кучу народу которым очень даже удобен.

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

Не хотел влезать но раз уж меня тут поминают заочно ...

XAML разрабатывался для того чтобы быть использованным в IDE. Я подозреваю что немалая толика доходов уважаемой компании (NB: без кавычек) поступает от средств разработки, т.е. одна из причин почему XAML получился именно такой является достаточно приземленной.
Руками писать XAML никто изначально не собирался. А тем более его "учить".
Я уже как то раз говорил что XAML это XML сериализация того что раньше использовал VB в файлах описания форм (.frm).

Пример FRM:

Begin VB.Form frmMain 
   BorderStyle     =   3  'Fixed Dialog
   Caption         =   "HtmLayout PrintEx Sample"
   ClientHeight    =   5985
   ClientLeft      =   45
   ClientTop       =   330
   ClientWidth     =   6495
   BeginProperty Font 
      Name            =   "Tahoma"
      Size            =   8.25
      Charset         =   0
      Weight          =   400
      Underline       =   0   'False
      Italic          =   0   'False
      Strikethrough   =   0   'False
   EndProperty
   Icon            =   "frmMain.frx":0000
   LinkTopic       =   "Form1"
   ...
   Begin VB.Label lblPages 
      AutoSize        =   -1  'True
      Caption         =   "#"
      Height          =   195
      Left            =   150
      TabIndex        =   5
      Top             =   5625
      Width           =   120
   End

Пример XAML:

<Window x:Class="ComFrame.Expenses.Presentation.ExpenseSheetWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    xmlns:sys="clr-namespace:System;assembly=mscorlib"     
    xmlns:my="clr-namespace:ComFrame.Expenses.Presentation" 
    Title="Expenses" SizeToContent="WidthAndHeight" Background="White" Name="rootWindow">

    <!-- Main Panel -->
    <StackPanel Margin="12,6,12,12">
        <Label FontWeight="Bold" FontSize="24" Foreground="White" Margin="0,0,0,6">
            <Label.Background>
                <LinearGradientBrush StartPoint="0,0" EndPoint="1,0">
                    <GradientStop Offset="0" Color="#6E81F2"/>
                    <GradientStop Offset="0.9" Color="White"/>
                    <GradientStop Offset="1" Color="White"/>
                </LinearGradientBrush>
            </Label.Background>
            Expenses.NET
        </Label>

В общем-то всё узнаваемо. Т.е. ожидать чего-то волшебного от XAML самого по себе не надо. И учить его в общем-то тоже не надо — это XML.
То что реально надо учить так это сам набор элементов/классов который сериализуется в XAML.
Т.е. надо знать что есть такая/такое <StackPanel> а у него есть Margin="12,6,12,12", что есть <ListView Name="lineItemListView" и т.д.
"Выучить" это все невозможно в принципе ибо каждый новый класс (widget) — это свой набор методов и свойств.

Теперь касательно XAML и HTML/CSS.

Вот эта конструкция (XAML):

<StackPanel Margin="12,6,12,12">
        <Label FontWeight="Bold" FontSize="24" Foreground="White" Margin="0,0,0,6">
            <Label.Background>
                <LinearGradientBrush StartPoint="0,0" EndPoint="1,0">
                    <GradientStop Offset="0" Color="#6E81F2"/>
                    <GradientStop Offset="0.9" Color="White"/>
                    <GradientStop Offset="1" Color="White"/>
                </LinearGradientBrush>
            </Label.Background>
            Expenses.NET
        </Label>
  ...
<StackPanel>

В HTML/CSS разделяется на две части:

HTML

<div .panel>
  <label>Expenses.NET</Label>
  ...
</div>

и стили:

@media screen 
{
  div.panel
  {
    flow:stack;
    margin: 12px 6px 12px 12px;
  }
  div.panel label
  {
    font: bold 24px;
    color: white;
    background: linear-gradient(#6E81F2 white);
  }
}

@media high-contrast-black-screen 
{
  div.panel label
  {
    font: bold 24px;
    color: black;
    background: white;
  }
}
@media print 
{
  div.panel
  {
    flow:vertical;
  }
  ...
}

Т.е. markup (т.е. структура) объектов на экране строго отделена от стилистики. В моем примере я специально выделил то что стили имеют разные значения
для разных media. Для visually impaired people один стиль для всех остальных — другой. Для печати того же самого DOM — третий.
И это я считаю правильно. Собственно это и была одна из причин почему я выбрал HTML/CSS как языкы разметки/стилирования для UI.
Чем дальше мы с этим всем работаем тем больше убежденность что это правильный путь. Но есть одно "но", а именно:

WYSIWYG редактирование и IDE.

Скажу сразу что в HTML/CSS с WYSIWYG плохо. Если ты видишь текст "Expenses.NET" белого цвета то этот цвет может получиться миллионом разных способов.
Т.е. select-element-and-set-property-color в общем случае сделать нельзя вменяемым образом.
В XAML с этим лучше — выбрал элемент и сказал ему Foreground="White". Но это палка о двух концах ибо:

CSS, Cascading Style Sheets.

Это хорошо и правильно. Для UI например это означает что ты можешь использовать разные themes для одного и того же DOM.
Это означает что поддержка скажем high contrast или text selection элементов UI это сугубо декларативные фичи не требующие менять код живого приложения.
Ну и далее:

Поддержка Design Time.

При разработке виджетов для WPF приходится заботится о поддержке Design Time функциональности. Иногда это достаточно большой объем (если правильно все делать) кода который еще к тому же попадает в runtime где ему совершенно нечего делать. В качестве алтернативы в HTML используется ...

Простой набор сущностей.

В HTML/CSS ты оперируешь всего тремя основными объектами:

Универсальный DOM Element, набор свойств стилей и behavior — code behind DOM Element который превращает элемент в option box или list box.
Т.е. сущностей всего ничего поэтому потребность в вещах типа intellisense вообще говоря нужна в первые два-три дня.
Ну в самом деле DOM Element это примерно 30 методов — меньше чем функций в C runtime.
Чего там intellisens-ить?

Ну и есть еще такая штука как CSS Selectors.

На самом деле народ воспринимает CSS Selectors как данность но это реально язык запросов к UI.

Вот тебе управляемый data binding:

function onDataChanged(data)
{
   for( var element in self.$$([bound-with="some-data-source-name"]) )
     element.text = data;
}

Что означает: при изменении коакой-то data пройдись по всем элементам с атрибутом bound-with="some-data-source-name"
и поменяй их текст на новый. При этом ты можешь имплементировать всяко разные логики этого data binding, а не только
те что предусмотренны создателями framework.

Извиняюсь за длинное сообщение.

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




CS>[code]
CS><StackPanel Margin="12,6,12,12">
CS> <Label FontWeight="Bold" FontSize="24" Foreground="White" Margin="0,0,0,6">
CS> <Label.Background>
CS> <LinearGradientBrush StartPoint="0,0" EndPoint="1,0">
CS> <GradientStop Offset="0" Color="#6E81F2"/>
CS> <GradientStop Offset="0.9" Color="White"/>
CS> <GradientStop Offset="1" Color="White"/>
CS> </LinearGradientBrush>
CS> </Label.Background>
CS> Expenses.NET
CS> </Label>
CS> ...

Данная конструкция тоже разделяется на две части:

1. Объявление стиля

 <Style x:Key="lblStyle" TargetType="Label">
  <Setter Property="Background">
  <Setter.Value>
    <LinearGradientBrush StartPoint="0,0" EndPoint="1,0">
                    <GradientStop Offset="0" Color="#6E81F2"/>
                    <GradientStop Offset="0.9" Color="White"/>
                <GradientStop Offset="1" Color="White"/>
                </LinearGradientBrush>
  </Setter.Value>
  </Setter>
  <Setter Property="Foreground" Value="White"/>
  <Setter Property="FontWeight" Value="Bold"/>
  <Setter Property="FontSize" Value="24"/>
  </Style>

2. Собственно разметка

<StackPanel>
 <Label Style="{StaticResource lblStyle}"  Margin="0,0,0,6">
        Expenses.NET
    </Label>
</StackPanel>

причем стиль может быть объявлен во внешней сборке. Преимуществ CSS над WPF в данном конкретном примере не вижу.

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

C>причем стиль может быть объявлен во внешней сборке. Преимуществ CSS над WPF в данном конкретном примере не вижу.
Только корректнее будет убрать x:Key и оставить TargetType, без явного задания ссылки на стиль в Label.

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

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

C>>причем стиль может быть объявлен во внешней сборке. Преимуществ CSS над WPF в данном конкретном примере не вижу.
MM>Только корректнее будет убрать x:Key и оставить TargetType, без явного задания ссылки на стиль в Label.

Ну тут от задачи зависит. Это может быть как стиль по умолчанию, так и именованный. Я, собственно, x:Key поставил для наглядности. Реально он там, конечно, не нужен.

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

CS>Не хотел влезать но раз уж меня тут поминают заочно ...

CS>XAML разрабатывался для того чтобы быть использованным в IDE. Я подозреваю что немалая толика доходов уважаемой компании (NB: без кавычек) поступает от средств разработки, т.е. одна из причин почему XAML получился именно такой является достаточно приземленной.

Что именно ты понимаешь здесь под "IDE"? Навороченный дизайнер типа бленда? Тогда ты не прав. Всё, что нужно для реактирования ксамла — это текстовый редактор ("програмерский", с фичами типа отступов, подсветки и т.п.) + интеллисенс + немного валдации (есть ли такое свойство, такой ресурс и т.п.). Навороченный дизайнер ни разу не нужен. Максимум — некое preview в режиме только для чтения. В этой нише многим вполне по силам потягаться с Майкрософтом.

CS>Руками писать XAML никто изначально не собирался.

Именно "писать руками" XAML — самый удобный способ разработки.

CS>А тем более его "учить".

А учить всё-таки немного нужно. Запоминать — нет (интеллисенс и хорошая валидация тут бы помогли), но помнить некоторые паттерны, некоторые особенности, помнить имеющийся инструментарий (например, какие есть баиндинги и триггеры) нужно.

CS>Я уже как то раз говорил что XAML это XML сериализация того что раньше использовал VB в файлах описания форм (.frm).

Типа того, но плюс ещё такие совсем не маловажные пункты, как расширяемость и гибкая где-то возможность управления сохранением; возможности связывания элементов; возможность повторного использования.

CS>В общем-то всё узнаваемо. Т.е. ожидать чего-то волшебного от XAML самого по себе не надо. И учить его в общем-то тоже не надо — это XML.

Это совсем не xml, если говорить не о том, как оно выглядит, а о том, что из себя представляет.

CS>То что реально надо учить так это сам набор элементов/классов который сериализуется в XAML.
CS>Т.е. надо знать что есть такая/такое <StackPanel> а у него есть Margin="12,6,12,12", что есть <ListView Name="lineItemListView" и т.д.
CS>"Выучить" это все невозможно в принципе ибо каждый новый класс (widget) — это свой набор методов и свойств.

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

CS>Теперь касательно XAML и HTML/CSS.

CS>Вот эта конструкция (XAML):
…
CS>В HTML/CSS разделяется на две части:
CS>HTML
…
CS>и стили:
…
CS>Т.е. markup (т.е. структура) объектов на экране строго отделена от стилистики. В моем примере я специально выделил то что стили имеют разные значения
CS>для разных media. Для visually impaired people один стиль для всех остальных — другой. Для печати того же самого DOM — третий.
CS>И это я считаю правильно. Собственно это и была одна из причин почему я выбрал HTML/CSS как языкы разметки/стилирования для UI.

Ну и в чём тут отличие от XAML? В том, я могу судить, что ты или специально или по не знанию, не разделил описание стиля и описание поведения от, собственно, инстанцирования и применения заданного стиля Всё тоже самое доступно и в XAML, но с другим синтаксисов. Несомненно, в чём-то синтаксис (и структура организации) HTML/CSS лучше/удобнее XAML, в чём-то наверняка нет, а суть в том, что функционально они … инструменты одного порядка, никто из нах не на порядок лучше другого.

CS>Чем дальше мы с этим всем работаем тем больше убежденность что это правильный путь. Но есть одно "но", а именно:
CS>WYSIWYG редактирование и IDE.
CS>Скажу сразу что в HTML/CSS с WYSIWYG плохо.

В XAML тоже.

CS>Извиняюсь за длинное сообщение.

Ничего. По судя по этому сообщению, ты или мало знаешь о XAML и о том, как его можно и нужно правильно применять, или намеренно не используешь XAML так, что бы было просто и удобно.

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

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

C>Данная конструкция тоже разделяется на две части:

...

C>2. Собственно разметка

C>

C><StackPanel>
C> <Label Style="{StaticResource lblStyle}"  Margin="0,0,0,6">
C>        Expenses.NET
C>    </Label>
C></StackPanel>
C>

Все зависит от того что называть стилем. В WPF вообще нет строго разделения
на семантику и стиль. Скажем <StackPanel> это явно описание стиля контейнера (и/или поведения) — как он раскладывает своих children.

C>причем стиль может быть объявлен во внешней сборке. Преимуществ CSS над WPF в данном конкретном примере не вижу.

Да я как-то особо и не настаиваю именно на преимуществах того или иного подхода.
Например я же сказал: в WPF должно быть удобнее делать WYSIWYG в IDE.
Для вопрошающего товарища (a.k.a. topic starter) этот критерий является основополагающим.
Мне — нет. Т.е. все это сугубо субъективно.

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

C>Данная конструкция тоже разделяется на две части:
C>1. Объявление стиля
C>2. Собственно разметка
C>причем стиль может быть объявлен во внешней сборке. Преимуществ CSS над WPF в данном конкретном примере не вижу.

А как будет выглядеть стиль для превращения StackPanel во WrapPanel?

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

V>>А как мне тогда задать отличие текста <H1> от <H2>?
MM>А для чего тебе их отличать?

Затем, что x:Key используется для отличия блоков, навроде отличия <H1> от <H2>, т.е. уже занят.

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

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

C>>Данная конструкция тоже разделяется на две части:
C>>1. Объявление стиля
C>>2. Собственно разметка
C>>причем стиль может быть объявлен во внешней сборке. Преимуществ CSS над WPF в данном конкретном примере не вижу.

TK>А как будет выглядеть стиль для превращения StackPanel во WrapPanel?

Если не прибивать StackPanel гвоздями к разметке страницы, то как-то так:

<Window x:Class="WpfApplication25.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525" >
    <Window.Resources>
        <Style x:Key="TestPanelStyle" TargetType="ItemsControl">
            <Setter Property="ItemsPanel">
                <Setter.Value>
                    <ItemsPanelTemplate>
                        <WrapPanel>
                        </WrapPanel>
<!--
                        <UniformGrid>
                        </UniformGrid>
-->
<!--
                        <StackPanel>
                        </StackPanel>
-->
                    </ItemsPanelTemplate>
                </Setter.Value>
            </Setter>
            <Setter Property="ScrollViewer.HorizontalScrollBarVisibility" Value="Disabled"/>
            <Setter Property="ScrollViewer.VerticalScrollBarVisibility" Value="Disabled"/>
        </Style>
    </Window.Resources>
    <ItemsControl Style="{StaticResource TestPanelStyle}">
        <Label>Test</Label>
        <Label>Test</Label>
        <Label>Test</Label>
        <Label>Test</Label>
        <Label>Test</Label>
        <Label>Test</Label>
        <Label>Test</Label>
        <Label>Test</Label>
        <Label>Test</Label>
        <Label>Test</Label>
        <Label>Test</Label>
        <Label>Test</Label>
        <Label>Test</Label>
        <Label>Test</Label>
        <Label>Test</Label>
        <Label>Test</Label>
        <Label>Test</Label>
        <Label>Test</Label>
        <Label>Test</Label>
        <Label>Test</Label>
        <Label>Test</Label>
        <Label>Test</Label>
        <Label>Test</Label>
        <Label>Test</Label>
    </ItemsControl>
</Window>

Хотя, конечно, так в Grid этот ItemsControl не превратишь — до css3 xaml не дотягивает.

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

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

V>>>А как мне тогда задать отличие текста <H1> от <H2>?
MM>>А для чего тебе их отличать?

V>Затем, что x:Key используется для отличия блоков, навроде отличия <H1> от <H2>, т.е. уже занят.
Наследуй стили через BasedOn.

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

CS>Все зависит от того что называть стилем. В WPF вообще нет строго разделения
CS>на семантику и стиль. Скажем <StackPanel> это явно описание стиля контейнера (и/или поведения) — как он раскладывает своих children.
Здесь нет никакого стиля. Это описание фабрики.

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

V>>Понимаешь, контролов должно быть мало, а одновременно используемых для одного контрола стилей на одной форме — много. В итоге, для получения некоего разнообразия надо наследоваться от контролов без добавления какой-либо функциональности, только для того, чтобы отделить типы контролов друг от друга "по смыслу" (т.е. получить аналог element из HTML), а уже x:Key использовать как доп. координату, аналог class. И все-равно, без меташаблонов, описывающих взаимное расположение, ничего серьезного в виде стилей описать не получится.. так, по мелочи разве что.
MM>Да как-то дело привычки, по-моему. Никогда всерьез не занимался Вебом, поэтому не страдаю без чего-то подобного CSS. По мне так те же яйца только в профиль. Нет некоторых фич, но не так уж и часто они оказываются нужны.

Да, вопрос смены стиля встает нечасто. Но вот у меня иногда встает (заказчики хотят ребрендить нашу разработку, т.е. снабжать своим лого и стилем), и я пока просто присматриваюсь в этом плане.

V>>Они же себе ставили целью отделить работу художников от работы программиста, а на самом деле получилось в десятки раз более жестко одно на другое завязанно, чем даже в HTML.
MM>Пока ты будешь рассматривать XAML сквозь призму HTML, тебе будут видится одни проблемы.

HTML — это охренительный набор практик в области декларативного UI, выкидывать эти практики и возвращаться в пещеры как-то жалко.

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

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

C>>Данная конструкция тоже разделяется на две части:
C>>1. Объявление стиля
C>>2. Собственно разметка
C>>причем стиль может быть объявлен во внешней сборке. Преимуществ CSS над WPF в данном конкретном примере не вижу.

TK>А как будет выглядеть стиль для превращения StackPanel во WrapPanel?


А это уже будет Template. В качестве примера см. ItemsControl.ItemsPanel. Я так понимаю, поставленная вами задача валидна только в случае отображения списка элементов. Другого практического применения я ей не вижу.

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

MM>Здравствуйте, c-smile, Вы писали:

CS>>Все зависит от того что называть стилем. В WPF вообще нет строго разделения
CS>>на семантику и стиль. Скажем <StackPanel> это явно описание стиля контейнера (и/или поведения) — как он раскладывает своих children.
MM>Здесь нет никакого стиля. Это описание фабрики.

Скажем у меня есть примитивный select:

<select>
  <option>1</option>
  <option>2</option>
  <option>3</option>
</select>

и я хочу чтобы у него был переключаемый layout как в Windows ListBox: Icons, List, Details.

В htmlayout я напишу:

select[view-mode=icons] 
{
  flow: horizontal-flow;
}
select[view-mode=list] 
{
  flow: vertical-flow;
}
select[view-mode=details] 
{
  flow: vertical;
}

И могу переключать вид как в markup так и в runtime.
Я могу это сделать так как HTML это чисто семантическая модель — не содержит в общем случае никаких "фабрик" и всего остального.

Но еще раз повторюсь: ответ на то хорошо это или плохо зависит от конкретных задач.