Прошу прощения за офф-топ, однако, разве никто никогда не видел подписей под checkbox'ами в Win или Linux (Unix-подобных) системах?
Или я не прав?

В принципе, если ВСЁ по центру, то и ... с ним. Но если культурно, то есть для людей (л, УЗЕРОВ), то лучше с вариациями. Личное мнение.

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

Люди которые занимались написанием элементов для box_lib знают или догадываются о том что я сейчас скажу.
Нужно стандартизировать все элементы управления. Так будет возможно решить возникающие трудности при развитии библиотеки и добавлении новых компонентов. Предлагаю в начале структуры каждого элемента библиотеки сделать общую информацию для каждого элемента. Например можно сделать так: Это позволит создать несколько общих функций, например:
element_draw - сейчас для рисования каждого элемента создается своя функция. Но можно будет сделать одну общую, которая в зависимости от значения element_id будет вызывать необходимую функцию для рисования элемента.
element_key - таже ситуация что и с функциями draw
element_move - чтобы можно было одной функцией менять расположение любого элемента
element_set_focus - ... установка фокуса на элемент
element_get_rect - ...
... - и т. д.
В итоге использование элементов прикладными программистами должно значительно облегчится, т. к. библиотека уже не будет экспортировать множество однотипных функций, а сама в зависимости от кода элемента будет определять что ей делать. Специфические функции для каждого элемента останутся.
В начале это будет новый branch, т. к. такие изменения сразу сделать нельзя, много всего нужно переписывать. Рано или поздно это нужно начинать Главный вопрос в том кто первый решится. Может быть будут предложения о том что еще нужно включить в общую часть структуры элемента?

Включить предлагаю поле "тип элемента" - со стандартным скином или программно-определенным. Это еще сильнее может упростить жизнь программисту. Если ему параллельно, какие цвета будут у контрола, или, что еще важнее, он хочет использовать системные цвета - то опция "стандартный скин" позволит ему не определять кучу параметров вручную. Только размеры контрола, изображение для dynamic button и надписи. Плюс это еще один маленький шажок к унификации интерфейса.

Я бы вообще разбил библиотеку на отдельные библиотеки в каждой из которых свой компонент и не понимаю, чем текущее положение мешает добавлению новых элементов. Я правда не понимаю, это наверное логика более высокого порядка, которая не помещается в моем скудном мозгу. Все предложенное является подходом ЯВУ и вообще объектного программирования - зачем такое внедрять в асмовскую библиотеку? Наверное, чтобы код еще больше стал по размер (все на благо программиста-человека разумеется). Как уже было сказано "Абстракции решают все проблемы, кроме одной -слишком много абстракций".

З.Ы. Уже озвучил идею Диме, пожалуй настало время озвучить ее вслух - буду делать zSea на больших системах, может быть если вообще буду. Мне не нравится многое, что происходит в проекте в последнее время. По моему мнению (на которое всем похуй, что не раз и не два демонстрировалось остальными людьми) происходит тупо выпиливание уникальных качеств проекта Колибри, которые были в нем изначально. Это печально, но мейнстрим он ведь такой мейнстрим.

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

происходит тупо выпиливание уникальных качеств проекта Колибри

Просьба не принимать вопрос в штыки. Которых качеств? Быстродействия и минимализма вплоть до аскетизма? Или еще каких-то?

SoUrcerer wrote:Включить предлагаю поле "тип элемента" - со стандартным скином или программно-определенным.

по идее для этого нужен 1 бит, можно над этим подумать

Mario wrote:чем текущее положение мешает добавлению новых элементов

добавлению элементов оно не мешает, но в данном подходе есть недостатки:
1) При добавлении новых элементов расширяется таблица экспорта функций (почти всегда добавляются 3 функции: рисование, клавиатура, мышь). Потом прикладной программист думает какую функцию вызвать для прорисовки элемента. Например сейчас есть 11 функций прорисовки: check_box_draw, check_box_draw2, option_box_draw, scrollbar_v_draw, scrollbar_h_draw, dbutton_draw, menu_bar_draw, FileBrowser_draw, tl_draw, PathShow_draw, ted_draw. Почему бы не перекинуть выбор функции прорисовки на саму библиотеку? Пришло ей 4 байта (код элемента) и она сама думает куда дальше направлять эту структуру... Не думаю что лишних 4 байта на каждый элемент и небольшая задержка за счет функции оболочки сильно затормозят работу программы.
2) Сейчас организовать переход фокуса по нажатию кнопки Tab сделать почти не возможно. Что в таком случае нужно?
-1- перевести фокус на новый элемент
-2- обновить элемент потерявший фокус (предположим элемент рисуется как не активный)
-3- обновить элемент получивший фокус (предположим элемент рисуется как активный)
Как это все сделать если около 10 функций для рисования? Как узнать какого вида элемент использовался (был активен) если структуры содержат данные в хаотическом порядке? Я предлагаю сделать идентификатор элемента что бы по указателю на структуру элемента можно было сразу сказать что за элемент и как с ним работать...
3) Врятли данные изменения я смогу сделать в ближайшем будущем, это пока на уровне идеи.

Вывод:
Фактически к структуре элемента добавляется только 4 байта (можно даже сделать 2 байта для экономии). Такие параметры как отступы, ширина, высота уже есть в каждом элементе и на размер структур врятли повлияют, просто их прейдеться сдвинуть в начало структуры.

SoUrcerer wrote:Мне кажется, что причины предложения - облегчение жизни разработчика. Предложенные правки (как я понимаю) должны уменьшить количество кода, а не наоборот. Фишку с element_id я не пропалил, и вообще сомневаюсь в ее необходимости, а общие функции не кажутся мне плохой идеей.

Фактически функции прорисовки элементов останутся такие как и были. Но они будут сидеть внутри библиотеки box_lib. Будет функция оболочка, которая как раз по element_id будет решать какую прорисовку вызвать для рисования элемента. Функция оболочка будет экспортироваться из библиотеки, а прикладной программист будет обращаться только к ней, не запоминая 10 названий и не думая что для элемента номер n функция n а для n+1 другая функция n+1. Это касается как прорисовки, так и реакции на мышь, клавиатуру ... и кто знает еще каких функций.

происходит тупо выпиливание уникальных качеств проекта Колибри

Думаю тут Mario предполагает что функции оболочки сильно затормозят программу, и усложнят жизнь программистам пишущим элементы.

Предложенные изменения затрагивают все приложения использующие Колибри. Огромный фронт не нужной работы, исключительно ради прихоти - чтобы было удобно очередному пришедшему на 5 минут говнокодеру (привет дельфи программистам! они очень люят когда их гладят и очень обижаются когда их интересы не учитывают в ассемблером проекте). Реализовать Tab достаточно просто (смотрим Opendialog), да это требует напрячь немного верхнее утолщение позвоночного столба. Если тебе это нужно - что-то радикально отличающееся, кто мешает сделать бранч и развлекаться, но нет давайте все поломаем - обязательно перетряхнем весь код, породим энное количестве неизвестных ошибок. Красота! Впрочем делай как хочешь - как я уже сказал лисопед будет новый, с мизером и доярками.

З.Ы. Вообще программист плохо соображающий, как работает его собственная программа... ладно не будем обижать людей, они ведь тоже люди.

Вообще это и есть предложение для бранча, как я понимаю. У нас тут не каноникал.

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

А не проще такой новый подход вынести в библиотеку, не?

Mario wrote:Реализовать Tab достаточно просто (смотрим Opendialog), да это требует напрячь немного верхнее утолщение позвоночного столба.

По любому кто-то будет напрягаться или прикладной программист или тот кто пишет библиотеку

Mario wrote:Если тебе это нужно - что-то радикально отличающееся, кто мешает сделать бранч и развлекаться, но нет давайте все поломаем - обязательно перетряхнем весь код, породим энное количестве неизвестных ошибок. Красота!

Я ни разу не сказал что я прямо сейчас буду ламать основную ветвь trunk.

SoUrcerer wrote:Вообще это и есть предложение для бранча, как я понимаю.

Да так и есть, потому как изменений действительно очень много.

Joaquin wrote:А не проще такой новый подход вынести в библиотеку, не?

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

По моему у нас и так уже есть еще не доделанный branch, который никому пока не мешает.