Board.KolibriOS.org

Official KolibriOS board
It is currently Mon Sep 28, 2020 4:00 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 403 posts ]  Go to page Previous 19 10 11 12 1327 Next
Author Message
PostPosted: Tue Oct 18, 2011 10:25 pm 
Я бы вообще разбил библиотеку на отдельные библиотеки в каждой из которых свой компонент и не понимаю, чем текущее положение мешает добавлению новых элементов. Я правда не понимаю, это наверное логика более высокого порядка, которая не помещается в моем скудном мозгу. Все предложенное является подходом ЯВУ и вообще объектного программирования - зачем такое внедрять в асмовскую библиотеку? Наверное, чтобы код еще больше стал по размер (все на благо программиста-человека разумеется). Как уже было сказано "Абстракции решают все проблемы, кроме одной -слишком много абстракций".

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


Top
   
PostPosted: Tue Oct 18, 2011 10:46 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Мне кажется, что причины предложения - облегчение жизни разработчика. Предложенные правки (как я понимаю) должны уменьшить количество кода, а не наоборот. Фишку с element_id я не пропалил, и вообще сомневаюсь в ее необходимости, а общие функции не кажутся мне плохой идеей.

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

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


Top
   
PostPosted: Tue Oct 18, 2011 10:52 pm 
Offline
User avatar

Joined: Mon Oct 27, 2008 10:10 pm
Posts: 829
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 байта для экономии). Такие параметры как отступы, ширина, высота уже есть в каждом элементе и на размер структур врятли повлияют, просто их прейдеться сдвинуть в начало структуры.


Top
   
PostPosted: Tue Oct 18, 2011 11:04 pm 
Offline
User avatar

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

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

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

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


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

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


Top
   
PostPosted: Tue Oct 18, 2011 11:13 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Вообще это и есть предложение для бранча, как я понимаю. У нас тут не каноникал.


Top
   
PostPosted: Tue Oct 18, 2011 11:17 pm 
Сравнил мягкое с теплым - весьма показательно. Сказал бы я что у нас, ну так ведь никто не любит, когда вот так.


Top
   
PostPosted: Tue Oct 18, 2011 11:30 pm 
Offline

Joined: Sat Aug 13, 2011 1:48 pm
Posts: 49
А не проще такой новый подход вынести в библиотеку, не?


Top
   
PostPosted: Tue Oct 18, 2011 11:38 pm 
Offline
User avatar

Joined: Mon Oct 27, 2008 10:10 pm
Posts: 829
Mario wrote:
Реализовать Tab достаточно просто (смотрим Opendialog), да это требует напрячь немного верхнее утолщение позвоночного столба.

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

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

Да так и есть, потому как изменений действительно очень много.
Joaquin wrote:
А не проще такой новый подход вынести в библиотеку, не?

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

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


Top
   
PostPosted: Wed Oct 19, 2011 1:46 am 
Offline

Joined: Sat Aug 13, 2011 1:48 pm
Posts: 49
IgorA wrote:
Joaquin wrote:
А не проще такой новый подход вынести в библиотеку, не?

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

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


Top
   
PostPosted: Wed Oct 19, 2011 1:57 am 
Не толсто, но жирно - абстракция абстракцией погоняет. Ничего что Edit_Box тупо работает с ASCII строкой, и чинить унитаз отбойным молотком, ололо!


Top
   
PostPosted: Wed Oct 19, 2011 2:08 am 
Offline

Joined: Sat Aug 13, 2011 1:48 pm
Posts: 49
Mario wrote:
Не толсто, но жирно - абстракция абстракцией погоняет. Ничего что Edit_Box тупо работает с ASCII строкой, и чинить унитаз отбойным молотком, ололо!

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


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


Top
   
PostPosted: Wed Oct 19, 2011 10:58 am 
Offline
User avatar

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

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


Top
   
PostPosted: Wed Oct 19, 2011 11:23 am 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Будто без KlbrInWin жизни не бывает. Я уже года два как этой программой не пользуюсь. Make-файлы сами программы компилируют и в образ дискеты вставляют.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 403 posts ]  Go to page Previous 19 10 11 12 1327 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited