Обсуждение статьи "Графические интерфейсы VI: Элементы "Слайдер" и "Двухсторонний слайдер" (Глава 2)"
Мне интересны Ваши замечания и предложения.
Нужны уточнения.
- Как Вы разделяете понятие главного окна и окна настроек ?
- Какие возможности Вы предлагаете добавить в текущую реализацию окна, чтобы его можно было в итоге называть "главным" ?
Что касается примеров представленных в статьях, то я преследовал цель показать, как работают элементы в различных комбинациях. Это просто способ продемонстрировать бесконфликтность различных типов элементов. Особенно это касается выпадающих элементов и элементов, в которых используются полосы прокрутки.
...
Если Вы сделаете главное окно приложения композитным, Вы предоставите возможность всем разработчикам самим выбирать для него "главное" содержание. По моему мнению, - в "композитности" отличительная черта "главного" окна приложения.
В любом случае, я считаю, Вам стоит заняться развитием возможностей Ваших окон.
Подумал. Текущая структура библиотеки позволяет реализовать подобный функционал. Но до того, как приступить к реализации, нужно решить ряд других вопросов, чтобы было уж совсем красиво. Я вижу несколько вариантов. Какой из них будет пока не знаю, так как нужно провести ряд экспериментов и тестов, чтобы выбрать наименее ресурсо-затратный.
Займусь этим после того, как опубликуют запланированные статьи текущей серии. Остались самые сложные и интересные с точки зрения разработки элементы управления.
В общем, быстро не обещаю, так как кроме этого ещё планировал провести оптимизацию кода в текущей версии и внести некоторые дополнения и исправления, которые должны существенно сократить потребление ресурсов. А ещё есть такой момент, что говоря об оптимизации и попытках сократить потребление ресурсов, ещё неизвестно, удастся ли получить, какой-то выигрыш в итоге. Бывает так, что можно потратить много времени, а придя к финишу убедиться в том, что толку то и нет. Но меня это не пугает. Не попробуешь - не узнаешь. ;)
Однако, очень интересная постановка вопроса... Лично мне никогда не приходило в голову, что оптимизация и сокращение потребления ресурсов, могут быть необязательными и даже вредными, и у "финиша" не принести толку. Вы поставили меня в тупик... Можно, конечно провести дискуссию или спор на эту тему, но мне вряд ли найти достаточно аргументов, так как я никогда не смотрел на эту проблему с этой стороны.
...
Это не мои слова, что "оптимизация и сокращение потребления ресурсов могут быть необязательными и даже вредными". В моём случае, оптимизацию делать нужно и выигрыш точно будет. Я просто это сделаю и если будет результат, напишу статью об этом. Сейчас просто недостаточно времени, чтобы подробно это изложить.
Действительно ли так нужен весь синтаксис ООП? К примеру: зачем передавать переменные в функции, если их можно сделать видимыми на глобальном уровне? Зачем подключать классы, если можно подключать файлы с функциями? Файлы не требуют сложной системы взаимосвязи функций,создания объектов классов для доступа к функциям и переменным. К чему колоссальное нагромождение правил и разнообразного синтаксиса, которые отвлекает от сути решаемой задачи и запутывают.
Попробуйте сделать всё тоже самое, но без ООП. Чтобы всё работало именно так. Я вот сначала попробовал и пришёл к выводу, что без ООП заниматься таким проектом очень сложно, даже если делаешь его только для себя. Я очень легко теперь ориентируюсь в этой структуре. Всё упорядоченно и лежит на своём месте. Есть доступ ко всем объектам и элементам библиотеки. Они не пересекаются между собой и имеют доступ только там, где можно, у каждого свой тип и имя. Я вижу, где можно провести рефакторинг, оптимизацию кода и некоторых алгоритмов, снизить потребление ресурсов.
Каждый может внести свою лепту изложив не только предложения, но и методы решения некоторых проблем, если видит и знает как. Мне уже поступило множество предложений в личку от разных пользователей, что и где можно исправить. На английском форуме тоже указали на некоторые ошибки в проектировании относительно этой библиотеки. Я уже знаю по крайней мере четыре фактора, которые увеличивают потребление ресурсов. Некоторые очевидно потребляют лишнего и их устранение скорее всего даст результат. Но всё это пока только в теории. В любом случае нужно сделать, провести тесты и только после этого можно сказать, есть какой-то выигрыш или нет.
В любом случае споры о том, какие методы программирования лучше, а какие хуже, считаю бессмысленными. Ваш опыт Вам может говорить об одном, а кому-то другому всё в точности наоборот. Жизнь бесконечно разнообразна своим многообразием. ;)
Но ведь ПОРЯДОК КАК ТАКОВОЙ, не привязан к конкретному методу его реализации. Если Вы создаете порядок в программе, разделяя функционал по классам, то знайте, - такой же точно порядок, можно повторить разделяя функционал по файлам.
Порядок - да, но доступ и оперирование множеством объектов различных типов - нет. На мой взгляд в ООП это намного проще.
Если Вы создаете перечесление или структуру КАК ТАКОВЫЕ, то ОНИ не обязательно должны быть выполнены по правилам ООП, и с синтаксисом ООП. Можно просто закоментировать строку и написать - "Структура А. Перечень элементов:", и доступ к переменным упроститься. ООП не помогает ничего упорядочивать, а только предлагает единый стандарт записи уже готовой схемы порядка.
Зачем? Ведь можно сразу создать полноценную структуру и затем объявляя её экземпляры, массивы и даже массивы массивов экземпляров, спокойно жонглировать всем этим. Можно и без ООП, но на мой взгляд, с ООП удобнее.
И каким это образом доступ к переменным упростится, когда они находятся вне структуры или класса? Наоборот, именно продуманная схема порядка в ООП и помогает всё упорядочить и упростить доступ к тем переменным, к котором можно, а к которым нельзя - вообще закрыть.
Вот здесь с Вами не поспоришь. Вследствии общепринятости ООП, развитие Вашей библиотеки может быть легко подхвачено другими программистами. Желаю Вам, чтобы так и случилось. :)
Именно для этого всё это и затевалось. Одна голова хорошо, но мало. ;)
Ну а Вам то это зачем, если не секрет?
Спросите у Вселенной. Мы лишь инструменты в её руках. ;)
Тщеславие?
Нет. Удовлетворение. Но не от тщеславия. Не знаю отчего. Возможно от частичного прореживания роя нереализованных идей и задач в моей голове. А ещё написание статей дисциплинирует, так как ответственность выше. Я существенно улучшил код этой библиотеки, которую изначально писал для себя. И это ещё далеко не предел.
А ещё оплата за статьи это хотя бы небольшая компенсация за потраченное время.
Головы ленивы в большинстве, и ценят готовые продукты гораздо больше чем наборы инструментов с инструкциями или стройматериалы, из которых эти продукты можно изготовить. Будучи вынужденными, они воспользуются Вашей библиотекой, но при наличии возможности сократить усилия и создать интерфейс без написания кода, к сожалению, они быстро забудут Вашу прекрасную библиотеку. Это будет тем самым предательством, которое общество всегда подвергает честных и благородных людей, бескорыстно отдающих ему свои силы и душу.
Может быть в большинстве - да, но не все. Вот с ними я и делюсь. Также, как и они делятся с другими.
Кстати, визуальную студию для создания графических интерфейсов я тоже думаю сделать. Именно с помощью этой библиотеки она и будет создана. Хочу сделать что-то наподобие, как это сделано в Microsoft Visual Studio. А может быть даже и лучше. Время покажет. Всё, как обычно, начинается с небольших экспериментов. Что в итоге получится, даже я сам не знаю. )
Мне кажется что сообщество созрело для революции в практике создания торговых программ, а Вы хотите предоставить очередной "upgrade". Однако, при всем этом, я желаю Вам удачи. :)
Созрело конечно! Именно для этого я и решил всё это опубликовать. Зафиксироваться и двигаться в этом направлении дальше. ;)
Какие амбиции и какой оптимизм!!! Прям как у меня...)))
Поясните пожалуйста, кому Вы адресуете свой призыв, - только мне, или нам с Анатолием обоим?
Если мне, то я недавно продемонстрировал базовые возможности своих окон, полосы прокрутки, таблицу, и спец-эффекты.
К вам, конечно. Вы хотите конкурировать с хорошо прокомментированными исходниками Анатолия своими видео-роликами? В какой номинации? )
Чтобы оценить программу, нужна, как минимум, демо-версия. Это же интерфейс, его нужно щупать.
Вот я и призываю перестать рассказывать о "страшном конкуренте", а поскорее перейти к его демонстрации ;)
... Спросите у Анатолия, считает ли он меня конкурентом. Пусть он сам Вам ответит. :)
Нет, я не считаю Вас конкурентом. Я работаю в другом формате и мы никак не пересекаемся. И на перегонки тоже играть не хочу. Буду работать в привычном для меня темпе.
Публикация материала с моей стороны осуществляется только после того, как я добиваюсь более-менее, на мой взгляд, приемлемого качества.
Кстати, следующая на публикацию статья: Графические интерфейсы VII: Элементы "Таблицы" (Глава 1). В ней будет представлено целых три класса таблиц. ;)
А я то надеялся, что немного посоревнуемся! :) Как жаль!... Ну ладно... Заметил, что в сообществе дух соревнования какой то слабоватый. Когда спросил про конкуренцию в маркете, - сказали что ее нет, когда пытался поддержать инициативу другого человека по проведению чемпионата, - так участников почти не нашлось... Скучновато как то...;) Ну и ладно.
Будущие статьи обязательно посмотрю. Удачи. :)
Давайте соревноваться качеством и функционалом.
К тому же, с моей стороны уже вышло 18 статей. Можно считать, что это 18 ходов. Нет, 18 забитых голов в Ваши ворота. А Вы ещё ни одного не сделали. Обещаю забить Вам ещё минимум 7. Не очень интересно, когда игра идёт в одни ворота. ;)
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Опубликована статья Графические интерфейсы VI: Элементы "Слайдер" и "Двухсторонний слайдер" (Глава 2):
В предыдущей статье разрабатываемая библиотека была пополнена сразу четырьмя довольно часто используемыми в графических интерфейсах элементами управления: «чекбокс», «поле ввода», «поле ввода с чекбоксом» и «комбобокс с чекбоксом». Вторая глава шестой части серии будет посвящена таким элементам управления, как слайдер и двухсторонний слайдер.
Элемент управления «Слайдер»
Слайдер — это разновидность элемента типа «поле ввода», который содержит в себе диапазон, ограниченный минимальным и максимальным значениями. В отличие от элемента «поле ввода», который мы рассматривали ранее, в слайдере нет кнопок переключателей, чтобы изменить значение в поле ввода. Вместо этого здесь используется полоса, в границах которой можно перемещать ползунок. Такой элемент интерфейса подходит для тех случаев, когда не нужно указывать точное значение, то есть, достаточно будет лишь приблизительного значения в известном диапазоне. Тем не менее, возможность ввести точное значение в поле ввода всё равно сохраняется.
Собирать этот элемент мы будем из шести графических объектов. Перечислим их.
Автор: Anatoli Kazharski