Re: stderr
В Суб, 22/11/2008 в 00:17 +0300, Artem Chuprina пишет:
> Покотиленко Костик -> debian-russian@lists.debian.org @ Fri, 21 Nov 2008 22:23:11 +0200:
>
> >> > Вы наверняка знаете как появился Gtk+ Люди писали The GIMP и им по целому
> >> > ряду причин потребовалось сделать с Motif нечто, что его коммерческая
> >> > лицензия не позволяла. И они написали свой тулкит (вдвоем). Если бы они
> >>
> >> Ну, к авторам The Gimp и другие претезнии есть. Например, то, что в
> >> Script-Fu garbage-collection не собирает объекты IMAGE, CHANNEL и тому
> >> подобные. Их приходится уничтожать явно.
> >>
> >> То есть написать расширение к Scheme для обработки изображений, так
> >> чтобы оно работало в соответствии с духом Scheme они не сумели.
> >>
> >> Думаю, что и с GUI у них было то же самое - не сумели understand,
> >> и стали reinvent. Poorly.
> >>
> >> Кстати, большая часть тех вкусностей, которая отличала Gtk времен
> >> gimp 0.9 от современных ему тулкитов потом куда-то делась, задавленная
> >> тяжестью Gnome HIG.
>
> ПК> Сам GTK инструмент хороший, не без претензий конечно, НО тяжесть и
> ПК> ресурсоёмкость програм - это следствие малого количества времени
> ПК> затраченного разработчиками программ на ОПТИМИЗАЦИЮ.
>
> ПК> К примеру, была задача организовать TreeView с ~4 миллиона строк и ~30
> ПК> колонок, нужен был поиск. База в dbf ~3Гб. Представляю сколько памяти бы
> ПК> зажрала прога и как бы она тупила если всё держать в TreeStore с
> ПК> прокруткой и поиском. В итоге сделал поиск по индексу, а часть
> ПК> результата помещался в TreeView, который был размером количества строк,
> ПК> которое влазит на экран, прокрутка к TreeView не привязана, и при
> ПК> прокрутке, сдвинутый список заливался в TreeStore.
>
> ПК> В результате прога памяти почти не занимала, прокрутка была с задержкой
> ПК> в 100мс, но даже на ~4млн записей не тупила ни разу.
>
> Я тоже у себя в программе к такому подходу пришел. Но я к нему пришел
> от кривизны, глючности и недостаточной функциональности TreeView.
> Т.е. разделение на model, view и controller у них вменяемое, но ни
> вменяемого готового view, ни вменяемого готового model нет.
Под каждую ситуацию ни View ни Model не напишешь, штатных для
большинства хватает. Если Вам уже не хватает, значит Вы крут и
стандартными фишками Вам пользоваться грех, напишите свой, или пляшите
вокруг того что есть, как я.
Надо понимать, что для базы данных на сегодняшний день пару млн записей
не проблемы, а для не специализированного GUI - проблема, так как по
определению графический объект ресурсов требует намного больше, чем
структуры, которыми оперируют движки баз данных.
Мою задачу можно было красиво решить написав свой Model и может быть
View.
> В результате я опять оказываюсь в ситуации, когда все готовое и
> приемлемое укладывается в рамки возможностей Tk, а все остальное все
> равно приходится делать вручную.
Не хочешь делать в ручную, переходи на C#$%^, потом будешь жаловаться,
что программа что-то делает, а что не понятно и как влиять на это не
понятно тоже.
--
Покотиленко Костик <casper@meteor.dp.ua>
Reply to: