On Tue, 16 Oct 2012 21:53:38 +0400 "Артём Н." <artio...@yandex.ru> wrote:
> >> Вот я думаю, что она должна быть в правом нижнем углу, выровнена по правой > >> границе с верхней кнопкой, причём находиться чуть выше нижней границы воон > >> того > >> "бевела", выделяющего группу контролов. > > Вот это условие как раз лучше описывается именно словами, а не языком > > жестов для глухонемых. > А когда таких слов очень много? Мало этих слов. Ничуть не больше, чем CBuilder в Object Inspector-е показывает. Причём в текст попадают только нужные, отличающиеся от дефолтного значения, а не всё подряд, что в этом окне выводится. > Может, проще посмотреть на интерфейс? "Лучше один раз увидеть", не? Смотри, кто ж мешает. Как надоест тестировать окошко после каждой незначительной правки, так задумаешься, что неплохо бы подойти и с другой стороны. > > К примеру, большинство набросанных в визуальном > > редакторе сибилдера формочек начинает съезжать при изменении размеров > > окна или шрифта. > Это ошибка не среды, а кривые руки и непредусмотрительность "дизайнера > интерфейсов". > Есть такое свойство, как Anchors. И ничего не съезжает. Ага, кнопки справа в окошке дизайнера, анчоры — слева в object inspector-е. Вот и крути головой туда-сюда, высматривая соответствия. Неудобно. > >> Но, при сложной форме, в текстовом описании интерфейса ещё проще > >> запутаться. > > Разбивай построение интерфейса на отдельные небольшие функции с внятными > > названиями. Рисовалка такой возможностив принципе не предоставляет. > Ну, думаю, предполагается, что пользователь может удержать не очень большое > число элементов в фокусе внимания. И надо создавать интерфейс так, чтобы он не > был перегружен. Он сам разбивается на отдельные компоненты. То ты говоришь про сложную форму, то говоришь, что они не нужны. Определись. > > Зачем? Зачем эта глупая привязка к IDE? Задачи прекрасно решаются и так. > Почему глупая? Потому что расход ресурсов на непроизводительные действия. > Мне надо: > 1. Написать. Удобно, быстро с отступами и подстановками. Создать интерфейс. Хороший текстовый редактор. А их всего два. > 2. Собрать часть и запустить на разных этапах (не переписывая Makefile, при > добавлении модуля). > 6. Проверить модуль с разными наборами данных. Unit testing. > 3. Попасть на строку, на которой программа вывалилась (именно на ошибку, а не > на > warning). Команда «:номер-строки» в виме. При компиляции из самого вима оно перескакивает автоматом. > 4. Посмотреть переменные в этом месте. Посмотреть подсказки (не просто > Segmentation fault). > 5. Пройти дальше на шаг, поменять значения переменных. Изредка посмотреть > дизассемблерный листинг. Это делает gdb. Я даже ставил себе clewn для интеграции оного в vim, но не прижился он у меня из-за неиспользуемости. При правке из отладчика рассматриваемый контекст ограничен одной функцией, потому годится для совсем очевидных ошибок. В других же случаях решает ошибку долгая медитация над кодом, по сравнению с которой 10 секунд на запуск gdb роли не играют. Кстати, очень грустно выглядит программист, который в отладчике ловит ошибку, проявляющуюся не ранее 135-й итерации цикла. Столько лишних нажатий на клавиши. > 7. Проверить программу на утечки, использование неиниц. переменных, обращения > за > границы и прочее. Мне нужна строка, где происходит обращение. И подсказка: > куда > и кем. valgrind. Он очень практично совмещается с unit-тестами. > 8. Сохранить изменения и записать версию. hg ci в терминале. Ну или прямо из вима. Можно и с окошком. > Я уж не говорю о интеграции с какой-то CASE-фигнёй или штукой уровня выше (тут > как-то писали про cucumber)... > И ещё много что. Говорить надо о том, что используется, а не баззворды с конференций повторять. > Да, "всё решается так". Но не слишком ли это..? Если бы всё было так славно и > удобно, вообще, IDE бы придумывали? То есть IDE придумали боги, а нам, простым смертным, надо в него уверовать ибо постичь мы не в состоянии? Или откуда тогда следует желание пользоваться чем-то только из-за того, что оно существует? -- Alexander Galanin -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121016222752.790e162e0be92b0c03532...@galanin.nnov.ru
