Мне кажется, что причины предложения - облегчение жизни разработчика. Предложенные правки (как я понимаю) должны уменьшить количество кода, а не наоборот. Фишку с 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, который никому пока не мешает.

IgorA wrote:

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

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

Тогда можно сделать библиотеку, которая станет как бы уровнем абстракции компонентов GUI (как HAL, только для гуя). Она будет использовать такие библы как box_lib, libGUI, импортируя процедуры из них для использования различных компонентов и экспортируюя процедуры для унифицированного механизма работы с виджетами. Таким образом, программы, без переписывания кода, использующие эту либу, смогут работать и с любыми оконным сервером/окружением рабочего стола (если такие будут реализованы), и с любыми интерфейсами ввода/ввывода (например в edit_box текст можно будет вводить с помощью распознования голоса, при этом программе использующей такой компонент ничего знать о механизме распознования будет не нужно). При этом если API у библиотеки будет стандартным, можно будет при настройке выбирать какие компоненты из какой библиотеки использовать. Например, пользователь сможет использовать в программах check box'ы из box_lib, а scroll bar'ы из libGUI, если ему так нравится.

Не толсто, но жирно - абстракция абстракцией погоняет. Ничего что Edit_Box тупо работает с ASCII строкой, и чинить унитаз отбойным молотком, ололо!

Mario wrote:Не толсто, но жирно - абстракция абстракцией погоняет. Ничего что Edit_Box тупо работает с ASCII строкой, и чинить унитаз отбойным молотком, ололо!

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

Абстракция построенная над абстракцией это зло, это породило кучу быдлокода, так называемыми "программистами" (80 уровня и выше). Одно дело когда человек понимает зачем и как сделано (это позволяет иногда не думать о всей концепции, ибо размер ОЗУ мозга ограничен), другое когда не понимает и более того не собирается разбираться и как тут любит говорить один товарищ "всем похуй" - в результате имеет все 33 удовольствия. Да, ладно бы если бы только сам "программист" поимел такое удовольствие (или удовольствия поимели его во все щели - ведь всем похуй, правда?), но такой код выдается за стандарт и понеслось.

Я против абстракций и разных дополнительных наслоений. Предложенная идея была в том, что бы привести параметры элементов к определенному порядку, для того что бы облегчить работу с ними. Например разве плохо знать что у всех элементов координата x в одном месте а y в другом и это смещение не зависит от используемого элемента? Конечно же такое переделывание только через новый branch, т. к. много программ уже используют box_lib.
Впрочем видно не судьба ... viewtopic.php?f=37&t=426&start=285#p38665

главные мысли выделил жирным

Будто без KlbrInWin жизни не бывает. Я уже года два как этой программой не пользуюсь. Make-файлы сами программы компилируют и в образ дискеты вставляют.