Среда, 04 Декабря 2024, 11:32

Приветствую Вас Гость

[ Новые сообщения · Игроделы · Правила · Поиск ]
Результаты поиска
GudleifrДата: Четверг, 04 Июня 2015, 11:08 | Сообщение # 1181 | Тема: База данных
почти ветеран
Сейчас нет на сайте
Цитата Ordan ()
выложи код
А чего читать-то? Ошибку я еще в 5-м посте указал.

P.S. Читать его "для общего образования" тоже не советую. Он крайне неопрятен - максимальное количество свистелок и перделок на единицу действия. Упражнение в обфускации, которое запутало самого программиста (в жалких двух десятках строчек).


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.

Сообщение отредактировал Gudleifr - Четверг, 04 Июня 2015, 11:25
GudleifrДата: Среда, 03 Июня 2015, 19:28 | Сообщение # 1182 | Тема: База данных
почти ветеран
Сейчас нет на сайте
Tymonr, раньше было веселее.

Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
GudleifrДата: Среда, 03 Июня 2015, 18:00 | Сообщение # 1183 | Тема: База данных
почти ветеран
Сейчас нет на сайте
Код
   gets(dbase[i].name);
    if(strlen(name)==0) break; //03

Вводим "dbase[i].name", а проверяем "name".


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
GudleifrДата: Воскресенье, 31 Мая 2015, 00:40 | Сообщение # 1184 | Тема: API для "двухстраничного" интерфейса
почти ветеран
Сейчас нет на сайте
Цитата maker-rus ()
Хорошо, мне стало понятно, что вы хотите изобрести собственный велосипед (операционную систему со своими плюшками и кабаками). В которой хотите реализовать оконный интерфейс, в виде двух страниц.
Нет, не велосипед (по крайней мере, годных решений я не видел), и к ОС задача отношения не имеет. Давайте завязывать. Рассуждать о решениях проблемы имеет смысл только в случае, если все согласны с ее наличием. Если Вы не когда с ней не сталкивались, то вряд ли поймете, зачем и как ее решать.


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
GudleifrДата: Пятница, 29 Мая 2015, 23:01 | Сообщение # 1185 | Тема: API для "двухстраничного" интерфейса
почти ветеран
Сейчас нет на сайте
Цитата maker-rus ()
Поэтому программно должны задаваться (динамические) размеры панелек и всего, что есть на экране.
Дык, мы на момент создания "панелек" знаем только, разрешение экрана, что панелек будет две (и, возможно, они будут снабжены парой кнопок "перелистывания"). Что на них будет нарисовано, мы не знаем, это выясниться только при загрузке на панельку содержимого выбранной страницы.

Цитата maker-rus ()
Любой "шаблонизатор", который выводит какую то информацию, оперирует значениями или условиями заданными создателем.
См. условие задачи. Наш "идеальный" шаблонизатор не знает, что за "информация" будет отображаться. Как окно CUA не знает, что будет в нем нарисовано программой.

Цитата maker-rus ()
Или вы предполагаете, что в системе будет чип, который реализует телепатию?
В любой операционной системе существует очередь событий (реализованная через файлы/семафоры и/или через сообщения). Нажав на кнопочку/ссылку на панельке, Вы порождаете событие "в ней", которое вызывает явный вызов ф-ии "здесь же" перевывода другой страницы. Т.е. страница "слушает" только саму себя. Более того, прослушать соседнюю физически невозможно, т.к. событие случившееся "там" полностью уничтожает информационный объект "здесь".


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.

Сообщение отредактировал Gudleifr - Пятница, 29 Мая 2015, 23:02
GudleifrДата: Пятница, 29 Мая 2015, 20:14 | Сообщение # 1186 | Тема: API для "двухстраничного" интерфейса
почти ветеран
Сейчас нет на сайте
Цитата maker-rus ()
это размер занимаемой области и позиции, для размещения
Никоим образом. Это свойства экрана, на котором программа вынуждена жить.
Цитата maker-rus ()
То есть некоторые объекты имеют больший размер
На момент создания "шаблонизатора" число и размер объектов неизвестны - это свойства загружаемой информации.
Цитата maker-rus ()
Прослушивающий объект должен соответствовать только одному требованию - слушать (получать состояние страничек).
Совершенно избыточно (за исключением отлова системного сигнала Resize). Зачем слушать, если листание производится явными действиями пользователя?


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
GudleifrДата: Пятница, 29 Мая 2015, 09:10 | Сообщение # 1187 | Тема: [Perl] Машина Тьюринга
почти ветеран
Сейчас нет на сайте
Ни у кого не завалялась реализация на Perl Машины Тьюринга (или другого достаточно сложного конечного автомата)? Не "гольф". Скорее, нужна красивая учебно-демонстрационная. Чтобы "входными символами" могли быть сложные регулярные выражения, и было бы куда цеплять функции-триггеры, отслеживающие переход из состояния в состояние. А то у меня получается менее красиво, чем на Си.

Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
GudleifrДата: Четверг, 28 Мая 2015, 23:38 | Сообщение # 1188 | Тема: API для "двухстраничного" интерфейса
почти ветеран
Сейчас нет на сайте
Цитата maker-rus ()
По моему, это кажется только вам.
Вот я и ищу людей, которым "кажется то же самое".

Добавлено (28 мая 2015, 23:38)
---------------------------------------------
Цитата maker-rus ()
И по поводу двух страничной реализации интерфейса.
Как я это вижу это?... добавить некоторую панель ... установить какой-то прослушивающий объект.

Эти "некоторые панели" и "какие-то объекты", очевидно, должны удовлетворять некоторым требованиям. Независимо от того, "сколько на экране кнопочек". Какими?


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.

Сообщение отредактировал Gudleifr - Четверг, 28 Мая 2015, 23:38
GudleifrДата: Четверг, 28 Мая 2015, 11:10 | Сообщение # 1189 | Тема: API для "двухстраничного" интерфейса
почти ветеран
Сейчас нет на сайте
maker-rus, у Вас как-то все две крайности: либо теория, либо рисуем нужные кнопочки. Есть и промежуточный слой: программно-независимая концепция кнопочек. Например тот же CUA...

Цитата
Как-то так:
Программа - организм. Смысловая часть - генотип. Принятые в твоей конторе оформительские соглашения - ограничения фенотипа. Зародыш развивается, заполняя своей биомассой структуру оконных форм (может - консоль, может - MDI). Гены лишь определяют ветвление в судьбоносные для зародыша моменты. Фенотип может быть представлен таблицей всех параметров всех окон, может списком отклонений стиля каждого окна от стандартного, может описанием совсем уж аппаратно-независимого дисплея.
Главное - минимум универсальности и максимум удобства.


Рассмотрим исторический пример: когда-то решили, что программам достаточно "write" и "read". И начали писать под это операционки с консолями/телетайпами. И хватало, ведь. Даже некоторый запас оставался: для рисования на экране картинки путем вывода большого количества строчек (ROGUE, STAR TREK) и даже для кусочка реалтайма путем оценки времени между началом и завершением "read" (OREGON TRAIL).
Потом "стандарт поплыл" - придумали "ввод без ожидания", управляющие консолью символы и т.д. Каждый писал свои резиденты и драйвера. Тогда XEROX и IBM придумали CUA - оконный интерфейс, базирующийся на окнах и сообщениях. И этого опять всем хватало: одна программа - одно окно, типовые менюшки, стандартные help-ы...
Пока не появился MS Excell, содержащий в себе не одно окно, а целую оконную систему...

Я не претендую на изобретение мирового стандарта. Просто, написав очередную FORTH-систему под Windows, я уперся в следующее:

Цитата
Очевидно, что, кроме огромного запаса API-функций, -структур, -сообщений и -констант, программист вынужден выучить еще и некие API-парадигмы, малейший отход от которых приведет к немедленному краху интерфейса проекта. Попыток как-то упорядочить эти самые парадигмы не перечесть, но, грубо говоря, есть всего три варианта.

1. Попытка систематизировать все эти API-кубики "как есть", разрешив программисту самому собрать из них что-то полезное. В примерах применялся именно этот подход. Результат - плачевный. Всем понятно, что достигнуть тут хоть какой-то обозримости можно только за счет грубого упрощения - сведения всех (часто) используемых параметров в списки propertie-сов и event-ов.

2. "Игровой подход" - отрисовать красивый экран самому, классифицировать все области пространства на экране и "перемножить" на все возможные действия мышкой (клики, Dbl- и Right-клики, Move, Drag&Drop-ы...) и клавиатуры (по крайней мере, Shift, Alt и Ctrl), привязав к каждой клетке получившейся таблицы осмысленные API-парадигмы.

3. Подход, предложенный в "Комнатной модели",- привязать парадигмы к "желаниям" и "ожиданиям" пользователя, плюнув на "универсальность", вроде бы постулируемую Биллом.


Поиграв во все три подхода, я прикинул, что "две страницы" (разновидность третьего) дадут одновременно и "очевидный интерфейс", и "универсальность". Мне интересно, кто-нибудь доходил до чего-то подобного? Т.е. не "может нарисовать две страницы, если припрет", а замечал, что все его программы на экране в чем-то получаются схожими и это сходство заключается не в том, что рисовал один дизайнер, а в том, что из раза в раз, он делит информацию на какие-то фрагменты и отображает их на экране схожим способом (идет ли речь о текстовой консоли, ЭЛТ, Tk, HTML, CUA...), организуя из раза в раз одни и те же каналы обмена...


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
GudleifrДата: Среда, 27 Мая 2015, 02:30 | Сообщение # 1190 | Тема: API для "двухстраничного" интерфейса
почти ветеран
Сейчас нет на сайте
Цитата maker-rus ()
Шаблонизатор не обязательный, а вспомогательный инструмент, который избавить страницу от говнокода.

Если Вам проще в терминах шаблонизатора, то примерно так.
Допустим есть идеальный двухстраничный шаблонизатор и, тоже допустим, есть компьютерная программа (любая), которую можно заставить "быть сервером". Никакой связи между ними нет - допустим, их писали два разных человека, ничего не зная о целях и задачах друг друга.
Интересует:
1) Во-первых, хватит ли двух страниц для интерфейса любой разумно организованной программы?
2) Во-вторых, если на первый вопрос ответ положительный, то как организовать автоматическое приведение ввода/вывода любой программы в двухстраничный вид?
3) В-третьих, какими свойствами должен обладать язык обмена информацией между страницами? Достаточно ли одной-единственной операции "вызови вторую страницу с параметрами ..."?
4) В четвертых, если выкинуть наш шаблонизатор и оставить только два этих языка (приведения и обмена), то смогут ли они быть настолько полными, чтобы определить автоматическое создание любого другого шаблонизатора "хоть вертикального, хоть горизонтального, хоть совмещенного"?


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.

Сообщение отредактировал Gudleifr - Среда, 27 Мая 2015, 02:31
GudleifrДата: Вторник, 26 Мая 2015, 15:08 | Сообщение # 1191 | Тема: API для "двухстраничного" интерфейса
почти ветеран
Сейчас нет на сайте
Цитата maker-rus ()
Дополнительные элементы, вроде того, что бы вернуться к оглавлению или перейти на следующую страничку сугубо индивидуальны и размещаются, как будет удобно.


Как бы изначально это и не устраивает, ни "индивидуальность", ни "как будет удобнее", что на практике означает "заведомо неудобно". Других проблем в теме почти нет (кроме двух: как в случае заранее неизвестного количества информации ее резать? и как в одних и тех же терминах описать "процесс" для разных сред - html, Tk, Win?).
Реализовать любое "деление" - проблем нет, важно понять, "как делить". Как убрать эту самую "индивидуальность"?

Усложнить себе жизнь: "Тут надо две страницы и мы идем рожать шаблонизатор",- очень просто. А, вот, можно ли ее упростить: "А, так тут две страницы, значит и думать не над чем!"? (Как мы до этого говорили: "Так это стандартный CUA с его рамкой и менюшками!". Или как Раскин говорил: "Все есть доска объявлений!".


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.

Сообщение отредактировал Gudleifr - Вторник, 26 Мая 2015, 15:25
GudleifrДата: Пятница, 15 Мая 2015, 16:16 | Сообщение # 1192 | Тема: Какие языки программирования вы считаете лучшими?
почти ветеран
Сейчас нет на сайте
martuk, из требования решать разные задачи на разных языках не следует равнодушное отношение к инструменту. Что-то легче и приятнее, другое муторнее.
Например, по моим наблюдением, программист встречаясь с новой задачей, тратит 10% сил/времени на проявление своей эрудиции (Да я щас эту фигню средствами новой библиотеки - "на ура", за пару дней) и 90% - на то, чтобы решение нормально заработало (Все давно работает, только валится). Можно всю жизнь решать типовые задачи (растягивая эти 10% на 90%), радуясь тому, что все давно на конвейере, надо только в шаблоне документации названия менять, а можно всю жизнь доводить до ума одну библиотеку (доводя 90% до 99.99%). Разные люди, разные предпочтения. Так что странного в том, что кому-то одни языки нравятся больше других? Отмазка "каждому - свое место" лишь "нежелание связываться".


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.

Сообщение отредактировал Gudleifr - Пятница, 15 Мая 2015, 16:33
GudleifrДата: Пятница, 15 Мая 2015, 12:00 | Сообщение # 1193 | Тема: API для "двухстраничного" интерфейса
почти ветеран
Сейчас нет на сайте
maker-rus, боюсь, все это не по теме. Вы, как и коллега Snake174 утверждаете, что обладая некоторой эрудицией, можно решить частную задачу. Это хорошо. Но в теме поднимается вопрос "общего решения". Т.е. какими свойствами, например, должны обладать "шаблонизаторы" (дались они Вам!), чтобы обеспечить "двустраничную синронизацию"? Кроме, конечно, "они должны обеспечивать двустраничную синронизацию". Насколько они должны быть "информационно замкнуты"? Возможно ли создание единого "интерфейсного элемента", или "синхронизация" должна включать в себя несколько "интерфейсных каналов"? Наконец, тупо, что удобнее: "обрезание по размеру", "масштабирование" или "прокрутка"? Можно ли их совмещать?

P.S. Короче, кто-нибудь задавался мыслью, что две страницы были бы удобнее, чем набор "супер навороченных адаптивно верстаемых всплывающих-выпадающих фигулек"? Чего для сиюминутной реализации этого не хватало?

Добавлено (15 мая 2015, 12:00)
---------------------------------------------
Кстати, обсуждение оказалось не совсем бесполезным.
Я понял, что информация, представляемая на страницах должна быть организована иерархически, что позволит обойтись без прокрутки:
1) обрезание "по окну" можно реализовать с точностью до "узла дерева"
2) масштабирование - свертывание/разворачивание "поддеревьев"


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.

Сообщение отредактировал Gudleifr - Среда, 13 Мая 2015, 19:04
GudleifrДата: Пятница, 15 Мая 2015, 11:24 | Сообщение # 1194 | Тема: Какие языки программирования вы считаете лучшими?
почти ветеран
Сейчас нет на сайте
Цитата PoidetLi ()
Что значит лучший?
Ну, как бы Вам и предлагается обосновать критерий. И некоторые из высказавшихся это и сделали...


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
GudleifrДата: Пятница, 15 Мая 2015, 10:58 | Сообщение # 1195 | Тема: Какие языки программирования вы считаете лучшими?
почти ветеран
Сейчас нет на сайте
Цитата KamiRonin ()
если бы тебе всемогущие существа сказали - выбери язык программирования, который останется на земле один единственный,

Цитата PATCH1 ()
Assembler

Цитата MysticPurple ()
Brainfuck

Зачем гадать? Ответ может быть только один - Машина Тьюринга. Без нее программирование математически невозможно.


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.

Сообщение отредактировал Gudleifr - Пятница, 15 Мая 2015, 10:59
GudleifrДата: Пятница, 15 Мая 2015, 10:55 | Сообщение # 1196 | Тема: Как вы относитесь к лямбда-выражениям?
почти ветеран
Сейчас нет на сайте
Цитата Vinchensoo ()
C++ просто не нужен
А куда девать людей, привыкших считать искусством программирования упражнения в запоминании особых свойств языка (или библиотек)?
В старое время пробным камнем была книга: Джефф Элджер "C++, библиотека программиста". Каждая главка начиналась словами: "А еще на C++ нельзя в лоб написать ...",- а затем приводился элегантный обходной путь. Остаться писать на C++ могли только те, кто не бросал чтение посреди книги со словами: "А не проще написать нормально на подходящем языке?" (Я не смог). К сожалению, с тех пор C++ ушел еще дальше.


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.

Сообщение отредактировал Gudleifr - Пятница, 15 Мая 2015, 11:15
GudleifrДата: Среда, 13 Мая 2015, 17:36 | Сообщение # 1197 | Тема: API для "двухстраничного" интерфейса
почти ветеран
Сейчас нет на сайте
maker-rus, и...?! Все давно известно и пройдено... Так почему не пересчитать на пальцах "основные моменты"? Как эти Ваши "замечательные фичи" и прочие "шаблонизаторы" обеспечивают "адаптивную верстку"? И нафига нам последняя?

Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.

Сообщение отредактировал Gudleifr - Среда, 13 Мая 2015, 17:37
GudleifrДата: Среда, 13 Мая 2015, 14:53 | Сообщение # 1198 | Тема: API для "двухстраничного" интерфейса
почти ветеран
Сейчас нет на сайте
Snake174, именно - "или что". Я ищу общие закономерности такого рода интерфейсов. Поэтому и собрал "все в одну кучу". Т.к. все это вещи родственные и одинаково мне неподходящие...

А так, как Вы предложили - это, повторю, извините, способ сделать все, что угодно, но "визуально". Надо доказать Большую Теорему Ферма?- Создаем окно "Большая Теорема Ферма", вставляем кнопочку "Доказать", добавляем красивый MessageBox "Что и требоовалось доказать!", стальное - по ходу дела...

Цитата Snake174 ()
Я тебе на примере С++/Qt
Забудьте Вы про C++ и Qt... Это лишь инструменты изгадить любую идею (сведя ее к копанию в ненужных мелочах), но не нечто полезное для измышления новых интерфейсов. (Посмотрите для примера книгу Раскина "Интерфейс: новые направления в проектировании компьютерных систем" или, если найдете, D.F.Scott "Разработка прикладных систем на Visual Basic for Windows").


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
GudleifrДата: Среда, 13 Мая 2015, 13:17 | Сообщение # 1199 | Тема: API для "двухстраничного" интерфейса
почти ветеран
Сейчас нет на сайте
YellowAfterlife, спасибо. Но в контексте вопроса, невозможность "управления в деталях" как раз плюс.
Например, в примере выше (второй рисунок - "Лунолет") параметры нажатой ссылки в левом фрейме честно передавались как параметры вызова CGI-калькулятора в правом. Откуда, в общем-то и родилась идея свести обмен между страницами к некоторому виду "синхронизации".


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
GudleifrДата: Среда, 13 Мая 2015, 10:59 | Сообщение # 1200 | Тема: API для "двухстраничного" интерфейса
почти ветеран
Сейчас нет на сайте
Snake174, пардон, это у Вас "издержки визуального образования": мол, не знаем, что нам надо запрограммировать, но если начать рисовать окна, может, что и получится. Какие "сообщения" должна получать "страница"? Как реагировать на "отслеженное" событие "не влазит"? Как менять один набор Controls на другой при смене типа "страницы"? Ваше "решение" - это, по-сути, отсутствие решения: мол, берем, чего надо, и рисуем. А вопрос ставился, скорее, как: "А что нам может быть надо в принципе?" Существуют ли интерфейсы, заведомо не сводимые к двум страницам? Частью какой страницы считать Win-рамку с "обычными панелями"? Как можно избавиться от Controls прокрутки и перелистывания?

Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Поиск:

Все права сохранены. GcUp.ru © 2008-2024 Рейтинг