View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001492 | Wishes | Panel | public | 2010-09-03 19:10 | 2013-02-03 00:34 |
Reporter | igor_yudincev | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | have not tried |
Status | new | Resolution | open | ||
Product Version | 2.0 | ||||
Summary | 0001492: Многострочная статусная область в панелях | ||||
Description | Предлагаю ввести возможность задания произвольного числа строк статуса, чтобы можно было отображать в статусной области во всю ширину панели на отдельных строках такие вещи, как описания файлов, длинные имена, содержимое custom-колонок и т.п. | ||||
Tags | No tags attached. | ||||
Build | |||||
|
|
|
В настройке типов для статусной строки можно использовать фиктивный тип "B" (разрыв строки). Хотя он и фиктивный, но ширину для него, хотя и фиктивную :) указывать все-равно надо. В настройке колонок можно использовать тип "X" - расширение без точки. Для папок расширение не отображается, только для файлов. В колонке N можно использовать модификатор N - имя файла без расширения. В макросах доступны APanel.StatusHeight и PPanel.StatusHeight |
|
патч покрывает тикет: http://bugs.farmanager.com/view.php?id=1589 |
|
PS. Содержимое статусных строк "тримается" и центрируется |
|
Вариант настройки мне кажется удобным и даже более наглядным чем сейчас (сильно неудобно считать по пальцам колонки и соответствующие им ширины). http://forum.farmanager.com/viewtopic.php?p=81830#p81830 И думается, что нужно соответственно поправить структурку в API (убрать ...Width): struct PanelMode { size_t StructSize; const wchar_t *ColumnTypes; const wchar_t * const *ColumnTitles; const wchar_t *StatusColumnTypes; PANELMODE_FLAGS Flags; }; |
|
> http://forum.farmanager.com/viewtopic.php?p=81830#p81830 согласен, вариант хорош. я б добавил: по-умолчанию считать "N=0" и "N" равнозначными. |
|
> И думается, что нужно соответственно поправить структурку в API (убрать ...Width): В смысле, предлагается забить ширины в другие поля? Это лишнее, имхо. То, как данные отображаются в UI и то, как они представлены в API - это разные вещи. "Мухи от котлет" должны быть отдельно (как сейчас). Я работаю с этими данными в своих плагинах, сужу практически, так сказать. То, что предлагается - это усложнение API. Чтобы получить ширины, плагинам придется их парсингом доставать из других данных? Это не архи-сложно, да, но все ж сложнее. Зачем? |
|
странное замечание... учитывая, что ты и так парсингом доставал данные из ColumnWidths... теперь будешь доставать из ColumnTypes. |
|
А я и не говорю, что то, как есть, это идеально (но парсинг был простой, просто разбить по запятым и проверить проценты). Не хочется, чтобы парсинг продолжал усложняться. P.S. Почему вообще такая идея представления данных прижилась в АПИ? Лучше бы вообще все данные четко отображались как массивы структур типа ColumnInfo { Title, Type, Width, WidthType }. Не? |
Date Modified | Username | Field | Change |
---|---|---|---|
2010-09-03 19:10 | igor_yudincev | New Issue | |
2011-05-31 20:43 | Maximus | File Added: 110531.diff.7z | |
2011-05-31 20:45 | Maximus | Note Added: 0007112 | |
2011-05-31 20:45 | Maximus | Note Added: 0007113 | |
2011-05-31 21:29 | Maximus | Note Added: 0007114 | |
2011-05-31 21:43 | Maximus | Note Added: 0007115 | |
2011-06-12 03:58 | samlyukov | Note Added: 0007190 | |
2011-06-13 05:57 | NightRoman | Note Added: 0007191 | |
2011-06-13 09:31 | samlyukov | Note Added: 0007192 | |
2011-06-13 09:55 | NightRoman | Note Added: 0007193 | |
2013-02-03 00:34 | alexy | Severity | minor => feature |