(извиняюсь за назойливость)

Они ходят

Это вот иллюстрация к тому что я имел ввиду здесь:
http://rsdn.ru/Forum/Message.aspx?mid=1473872&only=1

Автор: c-smile
Дата: 07.11.05

Этот самый behavior:clock в действии.



HTMLayout рисует элементы в три захода:
background, content и foreground

Данный конкретный behavior перекрывает только рисование content.

CSS задает две картинки
background:
и foreground:
(Последняя полупрозрачная — стекло — IE не умеет рисовать альфу).

Вот как выглядит CSS:

.clock {
   behavior:clock; /* name defined in behavior_clock.cpp */
   color:black; /* our behavior will use it for "hands" */
   width:153px;
   height:153px;

   /* clock face */       
   background-image:url(clock-images/clock-back.png);
   background-repeat:no-repeat;       
   background-position:50% 50%; /* middle center */
       
   /* clock glass */       
   foreground-image:url(clock-images/clock-fore.png);
   foreground-repeat:no-repeat;       
   foreground-position:50% 50%; /* middle center */
}

Т.е. в данном конкретном случае мы "реюзаем" все добавляя только
отрисовку контента.

Вот полный текст behavior_clock.cpp который оживляет картину:
(извиняюсь за полный текст, он не большой)

#include "stdafx.h"
#include "behavior_aux.h"

#include <math.h>

namespace htmlayout 
{

/*
BEHAVIOR: clock
    goal: Renders analog clock according to current tome.
TYPICAL USE CASE:
    <img style="behavior:clock">
SAMPLE:
    html_samples/behaviors/live-clock.htm
*/

struct clock: public behavior
{
    // ctor
    clock(): behavior(HANDLE_TIMER | HANDLE_DRAW, "clock") {} // здесь задается имя behavior для CSS

    virtual void attached  (HELEMENT he ) 
    { 
      HTMLayoutSetTimer( he, 1000 ); // set one second timer      
    } 

    virtual void detached  (HELEMENT he ) 
    { 
      HTMLayoutSetTimer( he, 0 ); // remove timer
    } 

    virtual BOOL on_timer  (HELEMENT he ) 
    { 
      dom::element el = he;
      RECT rc = el.get_location(false);
      HWND hw = el.get_element_hwnd(false);
      ::InvalidateRect(hw, &rc, FALSE);
      return TRUE; /*keep going*/ 
    }

    virtual BOOL on_draw   (HELEMENT he, UINT draw_type, HDC hdc, const RECT& rc ) 
    { 
      if( draw_type != DRAW_CONTENT ) return FALSE; /* do default draw if not DRAW_CONTENT */ 

      // we can get color settings from attributes but for simplicity lets use 
      // default values
            
      SYSTEMTIME st;
      GetLocalTime(&st);
      //Use GetSystemTime(&st); - if you need clocks in UTC or other TZ
      //you may use something like get_attribute("timezone")

      draw_clock_hand(hdc,rc, (st.wHour * 360) / 12, 0);
      draw_clock_hand(hdc,rc, (st.wMinute * 360) / 60, 1);
      draw_clock_hand(hdc,rc, (st.wSecond * 360) / 60, 2);
      
      return TRUE; /*skip default draw as we did it already*/ 
    }

    void draw_clock_hand( HDC hdc, const RECT& rc, int angle_degree, int hand )
    {
       double radians = (2 * 3.1415926 * (angle_degree - 90)) / 360.0 ;
       int radius = min( rc.bottom - rc.top, rc.right - rc.left ) / 2 - 12;
       
       HPEN hp = 0;
       LOGBRUSH logbrush = { BS_SOLID, RGB(0,0,0), 0 };
       logbrush.lbColor = ::GetTextColor(hdc);

       switch(hand)
       {
        case 0: // hours
           radius = (radius * 3) / 4; 
           hp = ::ExtCreatePen(PS_GEOMETRIC | PS_SOLID | PS_ENDCAP_ROUND, 5, &logbrush, 0,0);
           break;
        case 1: // minutes
           hp = ::ExtCreatePen(PS_GEOMETRIC | PS_SOLID | PS_ENDCAP_ROUND, 3, &logbrush, 0,0);
           break;
        case 2: // seconds
           logbrush.lbColor = RGB(0x7f,0,0);
           hp = ::ExtCreatePen(PS_GEOMETRIC | PS_SOLID, 1, &logbrush, 0,0);
           break;
        default:
           assert(false);
       }

       int y = (rc.bottom + rc.top) / 2;
       int x = (rc.right + rc.left) / 2;

       int xe = x + cos(radians) * radius;
       int ye = y + sin(radians) * radius;

       HGDIOBJ hpBefore = ::SelectObject(hdc,hp);
       ::MoveToEx(hdc,x,y,0);
       ::LineTo(hdc,xe,ye);
       ::SelectObject(hdc,hpBefore);
       ::DeleteObject(hp);

    }
   
};

// instantiating and attaching it to the global list
clock clock_instance; // регистрация behavior для CSS


} // htmlayout namespace

--EOF

Это собственно демонстрация идеи: UI можно в принципе делать "малой кровью"
программируя только то что действительно надо прогаммировать.

Еще раз извиняюсь за настырность.

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

S>Я тебе рекомендую сесть и написать апплет "стрелочные часы" используя общепринятый подход.

сел, написал

import java.awt.*;
import java.awt.event.*;
import java.awt.image.ImageObserver;
import java.io.*;
import java.util.*;


public class Clock extends Component
{
    class Hand
    {
        protected int[] baseX;
        protected int[] baseY;
        protected int[] transX;
        protected int[] transY;
        protected int numberOfPoints;

        public Hand(int points)
        {
            baseX = new int[points];
            baseY = new int[points];
            transX = new int[points];
            transY = new int[points];
            numberOfPoints = points;
        }

        protected void initiallizePoints(int originX, int originY, int length, int thickness)
        {
            baseX[0] = originX;
            baseY[0] = originY;
            baseX[1] = baseX[0] - (thickness / 2);
            baseY[1] = baseY[0] + (thickness / 2);
            baseX[2] = baseX[1];
            baseY[2] = (baseY[0] + length) - thickness;
            baseX[3] = baseX[0];
            baseY[3] = baseY[0] + length;
            baseX[4] = baseX[0] + (thickness / 2);
            baseY[4] = baseY[2];
            baseX[5] = baseX[4];
            baseY[5] = baseY[1];
        }

        public void draw(Color color, double angle, Graphics g)
        {
            transform(angle);
            g.setColor(color);
            g.fillPolygon(transX, transY, numberOfPoints);
        }

        protected void transform(double angle)
        {
            for (int i = 0; i < numberOfPoints; i++)
            {
                transX[i] = (int) (((baseX[0] - baseX[i]) * Math.cos(angle)) - ((baseY[0] - baseY[i]) * Math.sin(angle)) + baseX[0]);
                transY[i] = (int) (((baseX[0] - baseX[i]) * Math.sin(angle)) + ((baseY[0] - baseY[i]) * Math.cos(angle)) + baseY[0]);
            }
        }
    }

    Hand hourHand = new Hand(6);
    Hand minuteHand = new Hand(6);
    Hand secondHand = new Hand(3)
    {
        protected void initiallizePoints(int originX, int originY, int length, int unused)
        {
            baseX[0] = originX;
            baseY[0] = originY;
            baseX[1] = originX;
            baseY[1] = originY - (length / 5);
            baseX[2] = originX;
            baseY[2] = originY + length;
        }

        public void draw(Color color, double angle, Graphics g)
        {
            transform(angle);
            g.setColor(color);
            g.drawLine(transX[1], transY[1], transX[2], transY[2]);
        }
    };


    Color hColor = Color.black;
    Color mColor = Color.darkGray;
    Color sColor = Color.blue;
    Graphics g = null;
    int height;
    int width;

    Image backImage = null;

    public Clock()
    {
        try
        {
            InputStream is = getClass().getResourceAsStream("clock-back.png");
            byte[] buff = new byte[is.available()];
            is.read(buff);
            backImage = Toolkit.getDefaultToolkit().createImage(buff);
            width = backImage.getWidth(this);
            height = backImage.getHeight(this);

            return;
        }
        catch (IOException e)
        {
            e.printStackTrace();
        }

        width = 200;
        height = 200;
    }

    public boolean imageUpdate(Image img, int infoflags, int x, int y, int w, int h)
    {
        if (0 < (infoflags & ImageObserver.WIDTH))
            this.width = w;

        if (0 < (infoflags & ImageObserver.HEIGHT))
            this.height = h;

        init();

        return super.imageUpdate(img, infoflags, x, y, w, h);
    }


    private final GregorianCalendar calendar = new GregorianCalendar()
    {
        public void setTimeInMillis(long millis)
        {
            super.setTimeInMillis(millis);
        }
    };

    Thread clockThread = new Thread()
    {
        {start();}
        public void run()
        {
            Thread.currentThread().setPriority(Thread.MIN_PRIORITY);

            for (; ;)
                try
                {
                    calendar.setTimeInMillis(System.currentTimeMillis());

                    if (g == null) g = getGraphics();
                    if (g != null) paint(g);

                    Thread.sleep(1000L);
                }
                catch (InterruptedException _ex) {}
        }
    };


    public Dimension getPreferredSize()
    {
        return new Dimension(width, height);
    }

    public void init()
    {
        int cX = width / 2;
        int cY = height / 2;

        int min = Math.min(width, height);

        hourHand.initiallizePoints(cX, cY, (int) (25 / 100f * min), (int) (6 / 100f * min));
        minuteHand.initiallizePoints(cX, cY, (int) (40 / 100f * min), (int) (4 / 100f * min));
        secondHand.initiallizePoints(cX, cY, (int) (40 / 100f * min), 0);
    }

    public void paint(Graphics g)
    {
        this.g =null;
        g.drawImage(backImage, 0, 0, null);
        hourHand.draw(hColor, HOUR * calendar.get(Calendar.HOUR), g);
        minuteHand.draw(mColor, MINSEC * calendar.get(Calendar.MINUTE), g);
        secondHand.draw(sColor, MINSEC * calendar.get(Calendar.SECOND), g);
    }

    public static void main(String[] args)
    {
        Frame f = new Frame("Clock");
        f.setBounds(400, 0, 800, 800);
        f.addWindowListener(new WindowAdapter()
        {
            public void windowClosing(WindowEvent e)
            {
                System.exit(0);
            }
        });

        Clock clock = new Clock();

        f.add(clock, BorderLayout.CENTER);

        f.setVisible(true);
    }


    static final int BACKGROUND = 0;
    static final double MINSEC = (Math.PI * 2) / 60, HOUR = (Math.PI * 2) / 12;
}

S>Сравнить количество кода, которое потребовалось написать. После этого, я думаю, сомнений в преимуществах у тебя не останется.

сравнил, сомнения остались

Вопрос. Хотел задать на форуме терраинформатики, но лень

Интересует следующее: drag'n'drop и scrollbars.

Идея в чем. Если имплементировть popup диалоги, например, об ошибках или перетягивать элементы с одного узла дерева в другой, то нужен drag'n'drop.

Scrollbars нужны для эмуляции таблиц большого размера.

Здравствуйте, 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 несколько специфичен в каждом случае поэтому придется выбирать из возможных вариантов —
стандартного механизма не будет по всей видимости — придется делать руками каждый раз.

К слову, я собираюсь сделать нечто типа Canvas в Safari
http://developer.apple.com/documentation/AppleApplications/Reference/SafariJSRef/Classes/Canvas.html
(Если с Максом Шеманаревым договоримся то может будет AGG графика)

M>Scrollbars нужны для эмуляции таблиц большого размера.

Вот это вопрос тоже интересный. Во первых нормальные 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>Вот тот же behavior но уже прицепленный на другой элемент
CS>который в свою очередь тоже под behavior
CS>

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

мне правда, хочется разобраться "где собака порылась".
есть какие нибудь примеры где очевидны приимущества Вашего подхода по сравнению с ощепринятыми?

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

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

S>>Здравствуйте, vladserge, Вы писали:
V>>>сел, написал
S>>А как же полупрозрачное переднее стекло?
V>>>сравнил, сомнения остались
S>>А, то есть тебя не напрягает писать 207 строк вместо 108. Тогда конечно, непонятно зачем это все.

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

Не обижайся. Проблема-то не в тебе лично или количестве строк — оно действительно примерно одинаковое
для данной конкретной задачи "рисуем ходики".

Я лично хотел продемонстрировать как можно на существующий DOM со всеми его прибамбасами
цеплять свой код. И только в то место где он действительно нужен. Не больше и не меньше.

И еще наличие HTML/CSS это само по себе конечно хорошо но
наличие HTMLayout как сущности расширяет возможности UI. Когда этот самый
UI собирается у пользователя из разных кусков однвременно : что-то из ресурсов
что-то из БД а что-то свежее подкачалось с твоего сайта.

Я утверждаю что грядет эра специализированных броузеров. И надо быть к этому готовым.

Вот тот же behavior но уже прицепленный на другой элемент
который в свою очередь тоже под behavior

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

CS>Это собственно демонстрация идеи: UI можно в принципе делать "малой кровью"
CS>программируя только то что действительно надо прогаммировать.

Меня-то ты еще год назад убедил Я только до сих пор не пойму, почему не XML?

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

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

V>мне правда, хочется разобраться "где собака порылась".
V>есть какие нибудь примеры где очевидны приимущества Вашего подхода по сравнению с ощепринятыми?

Хех, а какие есть общепринятые? Сделать свой HWND-based контрол?

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, vladserge, Вы писали:

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

V>>мне правда, хочется разобраться "где собака порылась".
V>>есть какие нибудь примеры где очевидны приимущества Вашего подхода по сравнению с ощепринятыми?

Кё>Хех, а какие есть общепринятые? Сделать свой HWND-based контрол?

??? зачем достаточно того, что есть у базового окна.

Здравствуйте, vladserge, Вы писали:
V>мне правда, хочется разобраться "где собака порылась".
V>есть какие нибудь примеры где очевидны приимущества Вашего подхода по сравнению с ощепринятыми?
Я тебе рекомендую сесть и написать апплет "стрелочные часы" используя общепринятый подход. У нас, кстати, в курсе программирования на яве такое задание есть. Сравнить количество кода, которое потребовалось написать. После этого, я думаю, сомнений в преимуществах у тебя не останется.

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

Кё>>Хех, а какие есть общепринятые? Сделать свой HWND-based контрол?

V>??? зачем достаточно того, что есть у базового окна.

Я не понимаю Какие есть общепринятые способы?

http://www.codeproject.com/dotnet/vgclock.asp
И никакого obsolete win32 api

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

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

CS>>Вот тот же behavior но уже прицепленный на другой элемент
CS>>который в свою очередь тоже под behavior
CS>>

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

V>мне правда, хочется разобраться "где собака порылась".
V>есть какие нибудь примеры где очевидны приимущества Вашего подхода по сравнению с ощепринятыми?

Скожем вот sliding panel c list box:


Каким "общепринятым способом" предлагается это сделать?

Ни стандарьный Windows API ни WinForms этого тебе не позволяют.

И вообще HTML based UI это уже и есть один из общепринятых способов.
В самом общепринятом виде (встраивание IE или Mozilla) у него есть
ограничения для использования внутри приложений.
Данный конкретный компонент просто снимает основные ограничения.

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

CS>Скожем вот sliding panel c list box:
CS>

CS>Каким "общепринятым способом" предлагается это сделать?

CS>Ни стандарьный Windows API ни WinForms этого тебе не позволяют.

Кстати обрати внимание что этот самый ListBox прозрачный.

Прозрачность дочерних окон в Windows вообще отсутсвует.
(Только не говорите мне про WS_EX_TRANSPARENT пожалуйста — это фикция)

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

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

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

CS>Данный конкретный компонент просто снимает основные ограничения.

где можно подробнее почитать по внутреннему устройству, архитектуре HTMLayout

Здравствуйте, Кодёнок, Вы писали:

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

CS>>Это собственно демонстрация идеи: UI можно в принципе делать "малой кровью"
CS>>программируя только то что действительно надо прогаммировать.

Кё>Меня-то ты еще год назад убедил Я только до сих пор не пойму, почему не XML?

Я не понял а что такое XML?

XML и ASCII — это способы описания данных но не язык в чистом виде.
Что ты имеешь ввиду конкретно?

Здравствуйте, Аноним, Вы писали:

А>http://www.codeproject.com/dotnet/vgclock.asp
А>И никакого obsolete win32 api



А теперь возьми вот это нарисуй в XAML
http://www.terrainformatica.com/htmlayout/images/sliding-bar.jpg

а потом ответь на вопрос:

Чем вот это рисование цифры в приведенном примере:

XAML:

<Rectangle Name="one" Text="1" Location="220, 124.3782" Size="30, 30"
           StyleReference="Numeral" DrawAction="Fill" />

принципиально отличается от
API:
::DrawText(hdc, ..., "1", 1);

Я не честно не понимаю.

CS>а потом ответь на вопрос:

CS>Чем вот это рисование цифры в приведенном примере:

CS>XAML:
CS>

CS><Rectangle Name="one" Text="1" Location="220, 124.3782" Size="30, 30"
CS>           StyleReference="Numeral" DrawAction="Fill" />
CS>

CS>принципиально отличается от
CS>API:
CS> ::DrawText(hdc, ..., "1", 1);

CS>Я не честно не понимаю.


А я не понимаю о чем речь во втором примере. Первое описание мне понятно.
Вот собственно и разница.

Здравствуйте, Аноним, Вы писали:

CS>>XAML:
CS>>

CS>><Rectangle Name="one" Text="1" Location="220, 124.3782" Size="30, 30"
CS>>           StyleReference="Numeral" DrawAction="Fill" />
CS>>

CS>>принципиально отличается от
CS>>API:
CS>> ::DrawText(hdc, ..., "1", 1);

CS>>Я не честно не понимаю.

А>А я не понимаю о чем речь во втором примере. Первое описание мне понятно.
А>Вот собственно и разница.

Это недостаток легко исправить:
http://google.com/search?q=DrawText

Пойми, я не спрашиваю понимаешь ли ты слова Draw и Text.

Я спрашиваю чем принципиально отличается сложность разработки такого UI?
( http://www.codeproject.com/dotnet/vgclock.asp )

Лично я не вижу принципиальной разницы в написании

<Rectangle ... />
<Rectangle ... />
<Rectangle ... />
<Rectangle ... />

и
::Rectangle(... )
::Rectangle(... )
::Rectangle(... )
::Rectangle(... )

Первое при этом почему-то называется DeclarativeUI....

Мне лично все равно на каком языке такие скучные вещи писать:
на SVG, XAML или С++. Затраты те же.

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

V> где можно подробнее почитать по внутреннему устройству, архитектуре HTMLayout

Хороший вопрос, однако.
Надо его как-то осветить на сайте.

На самом деле ничего волшебного:

Есть специализированный DOM — его конcтруирует парсер или "руками" с помощью

static dom::element create(const char* tagname, const wchar_t* text = 0)

И есть behaviros — сущности цепляемые к элементам DOM — event handlers.

DOM cнаружи виден как иерархия HELEMENTs — можешь считать их lightweight HWND — абстракция достаточно
близка. behavior — это будет WndProc. Собственно и все.

Основные "фишки":
1) все дерево HELEMENT стилируется как единая система с помощью CSS. В зависимости от контекста тот же самый <SELECT> может выглядеть по разному.
2) все "сложные" HELEMENTs (например <SELECT>) есть просто части DOM и состоят из простых компонентов — тоже HELEMENT. Всем "ансамблем" в <SELECT> управляет специальный встроенный behavior.

Я не стал выносить базовые behaviors наружу по простой причине — при встраивании например в
PowerBasic пришлось бы их все переписывать на PB — не хочется.

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

CS>Я не понял а что такое XML?

Язык на основе XML, наилучшим образом подходящий для описания UI.

CS>XML и ASCII — это способы описания данных но не язык в чистом виде.
CS>Что ты имеешь ввиду конкретно?

В HTML есть фиксированный набор тэгов, семантика которых довольно неудобна. <SPAN> <DIV> — наиболее общие, <B> <I> <P> <H1> — какие-то частные случаи, фактически дублирующие <SPAN> или <DIV>. Это было хорошо давным-давно, до CSS, в самом начале языков разметки. С появлением CSS это только мешает.

Я имею ввиду возможность, например, один раз определить тэг <button>, который потом развернется скажем в <DIV style="display: inline-block"> + текст с присоединённым к нему базовым CSS. Потом можно натыкать этих тэгов-кнопок по всему диалогу. Это и улучшит понятность исходника UI, уменьшит ошибки связанные с Copy+Paste, да и просто уменьшит размер UI.

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

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

S>>Я тебе рекомендую сесть и написать апплет "стрелочные часы" используя общепринятый подход.

V>сел, написал
V>сравнил, сомнения остались

Клево

Только идея на самом деле не о том чтобы нарисовать стрелки — это к тому же на win API получилось проще чем на Java.

Основная фишка во всей системе резиновых HTML элементов и каскадирования CSS.

смотри:

img.clock 
{
  behavior: clock;
  width: 100px;
  height:100px;
  border:1px solid red;
}

p img.clock 
{
  border:1px dased green;
  padding:4px;
  width: 10px;
  height:10px;
}

div.clock 
{
  border:1px dased blue;
  padding:10px;
  width:100%%;
  height:100%%;
}


------------------ 
<img class=clock>
<p>А вот здесь уже будут другие <img class=clock> ходики. Их вид и положение зависит от контекста.</p>
<p>А вот ходики которые занимают все оставшееся место на view</p>
<div class=clock></div>

В принципе почти все это можно как-то с'эмулировать при помощи java LayoutManagers.
C inline элементами правда придется повозится.

Кстати концептуально java Layouts очень толковая штука.

Но вот основная беда layout managers — они не рисуют.
Принципиально в современном UI достаточно много всяких сугубо оформительских
деталей которые приходится сейчас руками програмировать. См например мой топик "XAML,XAML" —
опять ведь руками все написано хотя казалось бы у них все есть.

По хорошему тоже кстати еще тебе надо добавить какой-нибудь XML парсер что-бы хотя бы какая-то декларативность
была для сравнения.
Ну да ладно — и так понятно что задачу можно и должно решить способом подходящим
к данному контексту — сиречь не одним единственным.
Спасибо тебе vladserge большое — вельми показательно.

Здравствуйте, vladserge, Вы писали:
V>сел, написал
А как же полупрозрачное переднее стекло?
V>сравнил, сомнения остались
А, то есть тебя не напрягает писать 207 строк вместо 108. Тогда конечно, непонятно зачем это все.

Здравствуйте, 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.
Ваша реализация гараздо ближе к идеалу, без балды.

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


CS>Нет проблем. Описываем требуемую XML грамматику. Берем XML парсер SAX типа и генерим DOM


я конечно понимаю, такой вопрос задавать не модно и все такое... а сколько это чудо отъедает памяти? Насколько адекватно?

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


V>а у меня стрелочки заостренные

А у меня закругленные (один bit в декларации)

Шутка, не бери в голову.


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
устроен таким образом что он не сильно напрягает аллокатор.

Внизу на странице
http://www.terrainformatica.com/htmlayout/
есть таблица. Можно примерно прикинуть кто как хранит

Фишка на самом деле в другом. HELEMENT это фактически
ссылка на мой DOM элемент и все операции с ним осуществляются
в "темпе вальса" — практически напрямую.

Т.е никакого COM или XPCOM не надо для работы.

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


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, Вы писали:

Вот то же самое но теперь уже на PocketPC

Здравствуйте, 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.

Здравствуйте, 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), но хотелось бы встроенной функциональности