Я бы вообще разбил библиотеку на отдельные библиотеки в каждой из которых свой компонент и не понимаю, чем текущее положение мешает добавлению новых элементов. Я правда не понимаю, это наверное логика более высокого порядка, которая не помещается в моем скудном мозгу. Все предложенное является подходом ЯВУ и вообще объектного программирования - зачем такое внедрять в асмовскую библиотеку? Наверное, чтобы код еще больше стал по размер (все на благо программиста-человека разумеется). Как уже было сказано "Абстракции решают все проблемы, кроме одной -слишком много абстракций".
З.Ы. Уже озвучил идею Диме, пожалуй настало время озвучить ее вслух - буду делать zSea на больших системах, может быть если вообще буду. Мне не нравится многое, что происходит в проекте в последнее время. По моему мнению (на которое всем похуй, что не раз и не два демонстрировалось остальными людьми) происходит тупо выпиливание уникальных качеств проекта Колибри, которые были в нем изначально. Это печально, но мейнстрим он ведь такой мейнстрим.
box_lib.obj - библиотека gui компонентов
Мне кажется, что причины предложения - облегчение жизни разработчика. Предложенные правки (как я понимаю) должны уменьшить количество кода, а не наоборот. Фишку с element_id я не пропалил, и вообще сомневаюсь в ее необходимости, а общие функции не кажутся мне плохой идеей.
Просьба не принимать вопрос в штыки. Которых качеств? Быстродействия и минимализма вплоть до аскетизма? Или еще каких-то?происходит тупо выпиливание уникальных качеств проекта Колибри
по идее для этого нужен 1 бит, можно над этим подуматьSoUrcerer wrote:Включить предлагаю поле "тип элемента" - со стандартным скином или программно-определенным.
добавлению элементов оно не мешает, но в данном подходе есть недостатки: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 байта для экономии). Такие параметры как отступы, ширина, высота уже есть в каждом элементе и на размер структур врятли повлияют, просто их прейдеться сдвинуть в начало структуры.
Фактически функции прорисовки элементов останутся такие как и были. Но они будут сидеть внутри библиотеки box_lib. Будет функция оболочка, которая как раз по element_id будет решать какую прорисовку вызвать для рисования элемента. Функция оболочка будет экспортироваться из библиотеки, а прикладной программист будет обращаться только к ней, не запоминая 10 названий и не думая что для элемента номер n функция n а для n+1 другая функция n+1. Это касается как прорисовки, так и реакции на мышь, клавиатуру ... и кто знает еще каких функций.SoUrcerer wrote:Мне кажется, что причины предложения - облегчение жизни разработчика. Предложенные правки (как я понимаю) должны уменьшить количество кода, а не наоборот. Фишку с element_id я не пропалил, и вообще сомневаюсь в ее необходимости, а общие функции не кажутся мне плохой идеей.
Думаю тут Mario предполагает что функции оболочки сильно затормозят программу, и усложнят жизнь программистам пишущим элементы.происходит тупо выпиливание уникальных качеств проекта Колибри
Предложенные изменения затрагивают все приложения использующие Колибри. Огромный фронт не нужной работы, исключительно ради прихоти - чтобы было удобно очередному пришедшему на 5 минут говнокодеру (привет дельфи программистам! они очень люят когда их гладят и очень обижаются когда их интересы не учитывают в ассемблером проекте). Реализовать Tab достаточно просто (смотрим Opendialog), да это требует напрячь немного верхнее утолщение позвоночного столба. Если тебе это нужно - что-то радикально отличающееся, кто мешает сделать бранч и развлекаться, но нет давайте все поломаем - обязательно перетряхнем весь код, породим энное количестве неизвестных ошибок. Красота! Впрочем делай как хочешь - как я уже сказал лисопед будет новый, с мизером и доярками.
З.Ы. Вообще программист плохо соображающий, как работает его собственная программа... ладно не будем обижать людей, они ведь тоже люди.
З.Ы. Вообще программист плохо соображающий, как работает его собственная программа... ладно не будем обижать людей, они ведь тоже люди.
Вообще это и есть предложение для бранча, как я понимаю. У нас тут не каноникал.
Сравнил мягкое с теплым - весьма показательно. Сказал бы я что у нас, ну так ведь никто не любит, когда вот так.
А не проще такой новый подход вынести в библиотеку, не?
По любому кто-то будет напрягаться или прикладной программист или тот кто пишет библиотекуMario wrote:Реализовать Tab достаточно просто (смотрим Opendialog), да это требует напрячь немного верхнее утолщение позвоночного столба.
Я ни разу не сказал что я прямо сейчас буду ламать основную ветвь trunk.Mario wrote:Если тебе это нужно - что-то радикально отличающееся, кто мешает сделать бранч и развлекаться, но нет давайте все поломаем - обязательно перетряхнем весь код, породим энное количестве неизвестных ошибок. Красота!
Да так и есть, потому как изменений действительно очень много.SoUrcerer wrote:Вообще это и есть предложение для бранча, как я понимаю.
Тогда это будет новая библиотека, не имеющая отношения к box_lib, просто не хочется плодить большое количество однотипных библиотек.Joaquin wrote:А не проще такой новый подход вынести в библиотеку, не?
По моему у нас и так уже есть еще не доделанный branch, который никому пока не мешает.
Тогда можно сделать библиотеку, которая станет как бы уровнем абстракции компонентов GUI (как HAL, только для гуя). Она будет использовать такие библы как box_lib, libGUI, импортируя процедуры из них для использования различных компонентов и экспортируюя процедуры для унифицированного механизма работы с виджетами. Таким образом, программы, без переписывания кода, использующие эту либу, смогут работать и с любыми оконным сервером/окружением рабочего стола (если такие будут реализованы), и с любыми интерфейсами ввода/ввывода (например в edit_box текст можно будет вводить с помощью распознования голоса, при этом программе использующей такой компонент ничего знать о механизме распознования будет не нужно). При этом если API у библиотеки будет стандартным, можно будет при настройке выбирать какие компоненты из какой библиотеки использовать. Например, пользователь сможет использовать в программах check box'ы из box_lib, а scroll bar'ы из libGUI, если ему так нравится.IgorA wrote:Тогда это будет новая библиотека, не имеющая отношения к box_lib, просто не хочется плодить большое количество однотипных библиотек.Joaquin wrote:А не проще такой новый подход вынести в библиотеку, не?
Не толсто, но жирно - абстракция абстракцией погоняет. Ничего что Edit_Box тупо работает с ASCII строкой, и чинить унитаз отбойным молотком, ололо!
В таком случае можно будет переписать абстракцию на использование более продвинутой библиотеки. А программы менять не нужно будетMario wrote:Не толсто, но жирно - абстракция абстракцией погоняет. Ничего что Edit_Box тупо работает с ASCII строкой, и чинить унитаз отбойным молотком, ололо!
Абстракция построенная над абстракцией это зло, это породило кучу быдлокода, так называемыми "программистами" (80 уровня и выше). Одно дело когда человек понимает зачем и как сделано (это позволяет иногда не думать о всей концепции, ибо размер ОЗУ мозга ограничен), другое когда не понимает и более того не собирается разбираться и как тут любит говорить один товарищ "всем похуй" - в результате имеет все 33 удовольствия. Да, ладно бы если бы только сам "программист" поимел такое удовольствие (или удовольствия поимели его во все щели - ведь всем похуй, правда?), но такой код выдается за стандарт и понеслось.
Я против абстракций и разных дополнительных наслоений. Предложенная идея была в том, что бы привести параметры элементов к определенному порядку, для того что бы облегчить работу с ними. Например разве плохо знать что у всех элементов координата x в одном месте а y в другом и это смещение не зависит от используемого элемента? Конечно же такое переделывание только через новый branch, т. к. много программ уже используют box_lib.
Впрочем видно не судьба ... viewtopic.php?f=37&t=426&start=285#p38665
главные мысли выделил жирным
Впрочем видно не судьба ... viewtopic.php?f=37&t=426&start=285#p38665
главные мысли выделил жирным
Будто без KlbrInWin жизни не бывает. Я уже года два как этой программой не пользуюсь. Make-файлы сами программы компилируют и в образ дискеты вставляют.
Who is online
Users browsing this forum: No registered users and 0 guests