Здравствуйте!

Есть иерархический отчет колонок из пяти, хотелось бы в идеале отображать это как-то так:

	Qt'шный QTreeView sample — Edaitable Tree Model

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

Сейчас есть консольная прожка, которая генерит обычный html с обычным css/js, которые работают во всех бравзерах примерно одинакого. Но я не вдавался в тонкости css/js, и выглядит оно

	так себе

Хочется уйти из консольки, и сделать по-быстрому гуёвую аппу.

При этом:
1) Хочется это сделать быстро и без особого напряга — тут, имхо — WTL аппа со встрокой виндового COM-бравзера (или же htmllayout с минимальной переделкой генератора html) — тут не совсем понятно, что будет проще.
2) Хочется, не углубляясь ни в стандартные css/js, ни в ti script сделать как в кьюте, но без смены стека технологий на данном этапе
3) Или сразу — кьют. На старте — медленно, и без двух стадий, но зато результат примерно уже виден до старта, и бульменее понятно, что как делать.

Как быть?

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

M>Здравствуйте!

M>Есть иерархический отчет колонок из пяти, хотелось бы в идеале отображать это как-то так:
M>

	Qt'шный QTreeView sample — Edaitable Tree Model
	Image: editabletreemodel.png

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

Data model ( структура данных ) какая?

В sciter sdk есть пример таблицы с группами таблицы с группами таблицы с группами.

Там две базовых идеи:

1. иерархическая структура трансформируется в flat list:

function flatList(groups) {
  var out = [];
  for(var g in groups) {
    out.push(g); 
    if(g.expanded)
      for(var item in g.items)
        out.push(item);
  }
  return out;
}

И потом этот flat list скармливается table virtual view. И эта виртуальная таблица параметризируется функцией генерирующей row view:

function recordView(record,index) { // function generating single row
  const isCurrent = this.currentRecord===record
  if(record.group)
    return
      <tr.group key={record.key} :current={isCurrent} :expanded={record.expanded}>
        <th colspan="3">{record.group}</th>
      </tr>;
  else 
    return
      <tr key={record.key} :current={isCurrent} >
        <td>cell {record.field1}</td>
        <td>cell {record.field2}</td>
        <td>cell {record.field3}</td>
      </tr>;
}

В данном примере вложенность дерева строго 2 — список групп и записи в них — без подгруп.
Но по образу и подобию можно в принципе отобразить дерево произвольной вложенности — настроить flatList и recordView соотв. образом.

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


M>>Есть иерархический отчет колонок из пяти, хотелось бы в идеале отображать это как-то так:
M>>

	Qt'шный QTreeView sample — Edaitable Tree Model
	Image: editabletreemodel.png

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

CS>Data model ( структура данных ) какая?

Дерево, где каждый узел или лист обладает одним и тем же набором атрибутов


CS>В данном примере вложенность дерева строго 2 — список групп и записи в них — без подгруп.

Ну, не очень удачно показал, иерархия произвольной вложенности вообще, но на практике в основном 3-5 уровней вложенности

CS>Но по образу и подобию можно в принципе отобразить дерево произвольной вложенности — настроить flatList и recordView соотв. образом.

Спасибо за справку, но наверно я таки на кьюте лучше

Почему? У sciter, как я выяснил, есть проблема с производительностью, и есть проблема с совместимостью. Я скачал скайтер, попробовал из примеров html-браузер (start sciter in gdi mode.cmd/start sciter in warp mode.cmd):
1) Мой текущий html, который хром и IE открывает мнгновенно, скайтеровский браузер открывает секунд 20 где-то
2) css/js, который работает и в хроме и в IE — в скайтере не работает — у меня "[+]" — раскрываемые элементы, в скайтере они не раскрываются

Объем html — 1.5 Мб; в раскрытом виде, сохраненном в txt — 4К строк, из них 3К — на первом и единственном уровне дерева.

Т.е. сразу первая идея — просто загрузить мой html отчет в скайтер без лишних телодвижений — не работает, и неясно, как долго её придется допиливать.

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

M>Ну, не очень удачно показал, иерархия произвольной вложенности вообще, но на практике в основном 3-5 уровней вложенности


Добавил пример на эту тему:




Параметризуется двумя функциями:

Колонки, наименование и количество

function recordsetView() {
  return 
  <VTable recordset={flatList(tree)} @{vtable}>
    <columns>
      <th>Name</th>
      <th>First</th>
      <th>Second</th>
    </columns>
    { recordView }
  </VTable>;
}

И конкретный вид каждой строки:

function recordView(record,index) { // function generating single row
  const isCurrent = this.currentRecord===record;
  return
    <tr key={record.key} 
          class={record.items ? "node" : "leaf"} 
          :current={isCurrent} 
          :expanded={record.expanded} >
      <td><caption level={record.level}>cell {record.name}</caption></td>
      <td>cell {record.field1}</td>
      <td>cell {record.field2}</td>
    </tr>;
}

Внутри ячеек <td> может быть произвольный markup.

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


CS>Добавил пример на эту тему:

CS>Image: tree-table.png

Во, по виду — самое то, спасибо за пример.
Единственно, на тысячах строк — норм будет работать?

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

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


CS>>Добавил пример на эту тему:

CS>>Image: tree-table.png

M>Во, по виду — самое то, спасибо за пример.
M>Единственно, на тысячах строк — норм будет работать?

Этот tree viewer использует virtual list — т.е. кол-во DOM элементов не зависит от размера дерева.

Протестировать просто

Здесь вот
https://github.com/c-smile/sciter-sdk/blob/master/samples/%2Breactor/components/vlist/vtable-tree.htm#L47

Поменять 5 на 500 — получится 500*3*4 = 6000 items.

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

M>Есть иерархический отчет колонок из пяти, хотелось бы в идеале отображать это как-то так:

Навскидку, на картинке виден стандартный виндовый TreeView, который без проблем делается на голом WinAPI.

Здравствуйте, Евгений Музыченко, Вы писали:

M>>Есть иерархический отчет колонок из пяти, хотелось бы в идеале отображать это как-то так:

ЕМ>Навскидку, на картинке виден стандартный виндовый TreeView, который без проблем делается на голом WinAPI.

Не, ну я пописывал в своё время на голом WinAPI, но последние лет 8 даже на WTL ничего не делал.
Во-вторых — моя тулза написана на плюсиках, там ничего платформ-зависимого нет. Зачем мне делать гуй только под винду? Цели создать приложение, которое запускается под Win95 и под ReactOS у меня нет. Зачем мне тратить время на вспоминание того, за что в проф плане никто уже давно не платит, вместо того, чтобы разобраться с чем-то новым и потенциально полезным?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Marty, Вы писали:

M>>Есть иерархический отчет колонок из пяти, хотелось бы в идеале отображать это как-то так:

ЕМ>Навскидку, на картинке виден стандартный виндовый TreeView, который без проблем делается на голом WinAPI.

"стандартный виндовый TreeView" не поддерживает multiple columns.

Достоинство HTML/CSS и в частности Sciter состоит в том что достаточно легко делается композиция сложного из простых компонентов.

Отдельной строкой идет HTML event dispatching — events bubbling/sinking. Когда все child events проходят через parent.

Т.е. composition заложена в платформу by design. В Windows API хорошо сделаны базовые controls, но если нужна кастомизация или composition — туши свет кидай гранату и будь готов к "а здесь рыбу заворачивали" по всему коду.

Я много писал Windows GUI кода — собственно Sciter родился когда меня это все достало.

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

M>Зачем мне тратить время на вспоминание того, за что в проф плане никто уже давно не платит, вместо того, чтобы разобраться с чем-то новым и потенциально полезным?

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

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

CS>"стандартный виндовый TreeView" не поддерживает multiple columns.

Точно, забыл.

CS>Достоинство HTML/CSS и в частности Sciter состоит в том что достаточно легко делается композиция сложного из простых компонентов.

CS>Я много писал Windows GUI кода — собственно Sciter родился когда меня это все достало.

Я сейчас как раз подыскиваю что-нибудь для создания простых GUI на основе стандартных виндовых элементов, но с удобным позиционированием, масштабировнаием и т.п. И Sciter, и Qt выглядят неимоверно навороченными. А есть что-нибудь простое, и одновременно удобное, не тянущее в EXE мегабайты ненужного кода?

Здравствуйте, Евгений Музыченко, Вы писали:

M>>Зачем мне тратить время на вспоминание того, за что в проф плане никто уже давно не платит, вместо того, чтобы разобраться с чем-то новым и потенциально полезным?

ЕМ>Да я просто отметил. Но тот же Qt совсем уж неадекватно раздут. Для чего-нибудь большого и многофункционального он вполне годится, но в небольшом проекте кода Qt будет на порядок больше, чем собственно функционального.

В смысле — библиотечного?
Так это особо не важно. До 20 метров это уже не размер


ЕМ>Да и средства разработки для него тоже неадекватно огромны.

В смысле? Студия же всё та же

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

ЕМ>>в небольшом проекте кода Qt будет на порядок больше, чем собственно функционального.

M>В смысле — библиотечного?

Ну да.

M>Так это особо не важно. До 20 метров это уже не размер

Если соотносить с объемом современных накопителей — да, не размер. А если с объемом объективно потребного кода, то там же явная избыточность в несколько порядков. Нужно иметь очень стойкую психику, чтобы не обращать на это внимания.

ЕМ>>Да и средства разработки для него тоже неадекватно огромны.

M>В смысле? Студия же всё та же

Я про SDK, визуальные дизайнеры и т.п.

Здравствуйте, Евгений Музыченко, Вы писали:


ЕМ>Если соотносить с объемом современных накопителей — да, не размер. А если с объемом объективно потребного кода, то там же явная избыточность в несколько порядков. Нужно иметь очень стойкую психику, чтобы не обращать на это внимания.

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


M>>В смысле? Студия же всё та же

ЕМ>Я про SDK, визуальные дизайнеры и т.п.

SDK? Виндовый SDK что, легче? Визуальные дизайнеры? Они точно нужны? А то я в фаре всё пишу

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

M>Все уже давно забили

Слава богу, не все. У тех же Sysinternals или Nir Sofer полно очень компактных утилит с симпатичным, аккуратным и удобным GUI.

M>Но, судя по тому, что ты там что-то на ядреном уровне пишешь — тебе простительно

Проблема не столько в абсолютном размере, сколько в относительном (к функциональности). Слои и блоки наваливаются друг на друга, и уже мало кто помнит, что осталось внизу, и как оно работает. Получается что-то вроде биологических систем, которые выживают исключительно за счет множественных обратных связей, да и то чисто статистически.

M>SDK? Виндовый SDK что, легче?

Так в него навалено на все случаи жизни. В EXE оттуда почти ничего не тянется.

M>Визуальные дизайнеры? Они точно нужны?

Многим нравится гуй в гуе рисовать. Для простейших форм — удобно, а для мало-мальски сложных интерфейсов я бы предпочел удобное формальное описание визуальному построению.

Здравствуйте, Евгений Музыченко, Вы писали:

M>>Все уже давно забили

ЕМ>Слава богу, не все. У тех же Sysinternals или Nir Sofer полно очень компактных утилит с симпатичным, аккуратным и удобным GUI.

А, да, не все. Чуть более, чем все

Что такое Nir Sofer — не знаю, а винтернал — это чисто виндовые тулзы с довольно простым интерфейсом. Было бы странно их писать на кьюте или еще чём-то


ЕМ>Проблема не столько в абсолютном размере, сколько в относительном (к функциональности). Слои и блоки наваливаются друг на друга, и уже мало кто помнит, что осталось внизу, и как оно работает. Получается что-то вроде биологических систем, которые выживают исключительно за счет множественных обратных связей, да и то чисто статистически.

Да нормально там всё, не надо сгущать


M>>SDK? Виндовый SDK что, легче?

ЕМ>Так в него навалено на все случаи жизни. В EXE оттуда почти ничего не тянется.

Так и кьют в отдельных DLL-ках лежит, и обычно нужна только пара-тройка из них. Для перфекционистов всегда есть вариант пересобрать и оставить минимально необходимое.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>с удобным позиционированием, масштабировнаием и т.п.

Что имеется ввиду?

ЕМ>стандартных виндовых элементов … масштабировнаием

Как эти две сущности сочетаются?

Если под "масштабировнаием" имеется ввиду zoom типа этого:



(пример: https://github.com/c-smile/sciter-sdk/blob/master/samples/zoom/zoom-demo.htm)

то забей — нет такого у "стандартных виндовых элементов".

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


ЕМ>>стандартных виндовых элементов … масштабировнаием

CS>Как эти две сущности сочетаются?

Ну, я на WTL достаточно просто делал диалоги на стандартных контролах с масштабированием. Вернее, с ресайзом. Скорее всего это и имелось в виду

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

Кстати, как я понял, удобнее всего склонить репу к себе, чтобы оперативно получать обновления.

Грохнул скачанный архивом SDK, решил склонить с гитхаба — понял, что до пенсии не склонится — решил с гитхаба архивом слить — слил, но там не оказалось репы.

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

Ну это я так, побрюзжать

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

M>Что такое Nir Sofer — не знаю

nirsoft.com. Тоже чисто виндовые тулзы.

M>а винтернал — это чисто виндовые тулзы с довольно простым интерфейсом. Было бы странно их писать на кьюте или еще чём-то

А многие пишут. Просто потому, что могут.

M>Да нормально там всё, не надо сгущать

Объясните, как может быть нормальным раздувание программы на порядки только за счет гуя, по отношению к объективной функциональности? При том, что в современных ОС вполне хватает гуевых средств, и не нужно их все делать с нуля?

M>Так и кьют в отдельных DLL-ках лежит, и обычно нужна только пара-тройка из них. Для перфекционистов всегда есть вариант пересобрать и оставить минимально необходимое.

Ну вот сколько примерно оно потянет из статических библиотек на несложный интерфейс типа Tree View?