Обсуждение статьи "Графические интерфейсы VI: Элементы "Слайдер" и "Двухсторонний слайдер" (Глава 2)"

 

Опубликована статья Графические интерфейсы VI: Элементы "Слайдер" и "Двухсторонний слайдер" (Глава 2):

В предыдущей статье разрабатываемая библиотека была пополнена сразу четырьмя довольно часто используемыми в графических интерфейсах элементами управления: «чекбокс», «поле ввода», «поле ввода с чекбоксом» и «комбобокс с чекбоксом». Вторая глава шестой части серии будет посвящена таким элементам управления, как слайдер и двухсторонний слайдер.

Элемент управления «Слайдер»

Слайдер — это разновидность элемента типа «поле ввода», который содержит в себе диапазон, ограниченный минимальным и максимальным значениями. В отличие от элемента «поле ввода», который мы рассматривали ранее, в слайдере нет кнопок переключателей, чтобы изменить значение в поле ввода. Вместо этого здесь используется полоса, в границах которой можно перемещать ползунок. Такой элемент интерфейса подходит для тех случаев, когда не нужно указывать точное значение, то есть, достаточно будет лишь приблизительного значения в известном диапазоне. Тем не менее, возможность ввести точное значение в поле ввода всё равно сохраняется.

Собирать этот элемент мы будем из шести графических объектов. Перечислим их.

  1. Фон
  2. Надпись (текстовая метка)
  3. Поле ввода
  4. Полоса слайдера
  5. Ползунок слайдера
  6. Индикатор слайдера

 Рис. 1. Составные части элемента управления «Слайдер».

Автор: Anatoli Kazharski

 
Реter Konow:
...

Мне интересны Ваши замечания и предложения.

Нужны уточнения.

  1. Как Вы разделяете понятие главного окна и окна настроек ?
  2. Какие возможности Вы предлагаете добавить в текущую реализацию окна, чтобы его можно было в итоге называть "главным" ?

 

Что касается примеров представленных в статьях, то я преследовал цель показать, как работают элементы в различных комбинациях. Это просто способ продемонстрировать бесконфликтность различных типов элементов. Особенно это касается выпадающих элементов и элементов, в которых используются полосы прокрутки.

 
Реter Konow:

...

Если Вы сделаете главное окно приложения композитным, Вы предоставите возможность всем разработчикам самим выбирать для него "главное" содержание. По моему мнению, - в "композитности" отличительная черта "главного" окна приложения.

В любом случае, я считаю, Вам стоит заняться развитием возможностей Ваших окон.

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

Займусь этим после того, как опубликуют запланированные статьи текущей серии. Остались самые сложные и интересные с точки зрения разработки элементы управления.

В общем, быстро не обещаю, так как кроме этого ещё планировал провести оптимизацию кода в текущей версии и внести некоторые дополнения и исправления, которые должны существенно сократить потребление ресурсов. А ещё есть такой момент, что говоря об оптимизации и попытках сократить потребление ресурсов, ещё неизвестно, удастся ли получить, какой-то выигрыш в итоге. Бывает так, что можно потратить много времени, а придя к финишу убедиться в том, что толку то и нет. Но меня это не пугает. Не попробуешь - не узнаешь. ;)

 
Реter Konow:

Однако, очень интересная постановка вопроса... Лично мне никогда не приходило в голову, что оптимизация и сокращение потребления ресурсов, могут быть необязательными и даже вредными, и у "финиша" не принести толку. Вы поставили меня в тупик... Можно, конечно провести дискуссию или спор на эту тему, но мне вряд ли найти достаточно аргументов, так как я никогда не смотрел на эту проблему с этой стороны.

...

Это не мои слова, что "оптимизация и сокращение потребления ресурсов могут быть необязательными и даже вредными". В моём случае, оптимизацию делать нужно и выигрыш точно будет. Я просто это сделаю и если будет результат, напишу статью об этом. Сейчас просто недостаточно времени, чтобы подробно это изложить.

Действительно ли так нужен весь синтаксис ООП? К примеру: зачем передавать переменные в функции, если их можно сделать видимыми на глобальном уровне? Зачем подключать классы, если можно подключать файлы с функциями? Файлы не требуют сложной системы взаимосвязи функций,создания объектов классов для доступа к функциям и переменным. К чему колоссальное нагромождение правил и разнообразного синтаксиса, которые отвлекает от сути решаемой задачи и запутывают.

Попробуйте сделать всё тоже самое, но без ООП. Чтобы всё работало именно так. Я вот сначала попробовал и пришёл к выводу, что без ООП заниматься таким проектом очень сложно, даже если делаешь его только для себя. Я очень легко теперь ориентируюсь в этой структуре. Всё упорядоченно и лежит на своём месте. Есть доступ ко всем объектам и элементам библиотеки. Они не пересекаются между собой и имеют доступ только там, где можно, у каждого свой тип и имя. Я вижу, где можно провести рефакторинг, оптимизацию кода и некоторых алгоритмов, снизить потребление ресурсов.

Каждый может внести свою лепту изложив не только предложения, но и методы решения некоторых проблем, если видит и знает как. Мне уже поступило множество предложений в личку от разных пользователей, что и где можно исправить. На английском форуме тоже указали на некоторые ошибки в проектировании относительно этой библиотеки. Я уже знаю по крайней мере четыре фактора, которые увеличивают потребление ресурсов. Некоторые очевидно потребляют лишнего и их устранение скорее всего даст результат. Но всё это пока только в теории. В любом случае нужно сделать, провести тесты и только после этого можно сказать, есть какой-то выигрыш или нет.

В любом случае споры о том, какие методы программирования лучше, а какие хуже, считаю бессмысленными. Ваш опыт Вам может говорить об одном, а кому-то другому всё в точности наоборот. Жизнь бесконечно разнообразна своим многообразием. ;)

 
Реter Konow:

Но ведь ПОРЯДОК КАК ТАКОВОЙ, не привязан к конкретному методу его реализации. Если Вы создаете порядок в программе, разделяя функционал по классам, то знайте, - такой же точно порядок, можно повторить разделяя функционал по файлам.  

Порядок - да, но доступ и оперирование множеством объектов различных типов - нет. На мой взгляд в ООП это намного проще. 

Если Вы создаете перечесление или структуру КАК ТАКОВЫЕ, то ОНИ не обязательно должны быть выполнены по правилам ООП, и с синтаксисом ООП. Можно просто закоментировать строку и написать - "Структура А. Перечень элементов:", и доступ к переменным упроститься. ООП не помогает ничего упорядочивать, а только предлагает единый стандарт записи уже готовой схемы порядка. 

Зачем? Ведь можно сразу создать полноценную структуру и затем объявляя её экземпляры, массивы и даже массивы массивов экземпляров, спокойно жонглировать всем этим. Можно и без ООП, но на мой взгляд, с ООП удобнее.

И каким это образом доступ к переменным упростится, когда они находятся вне структуры или класса? Наоборот, именно продуманная схема порядка в ООП и помогает всё упорядочить и упростить доступ к тем переменным, к котором можно, а к которым нельзя - вообще закрыть.

Реter Konow:
Вот здесь с Вами не поспоришь. Вследствии общепринятости ООП, развитие Вашей библиотеки может быть легко подхвачено другими программистами. Желаю Вам, чтобы так и случилось. :)

 Именно для этого всё это и затевалось. Одна голова хорошо, но мало. ;)

 
Реter Konow:

Ну а Вам то это зачем, если не секрет?

Спросите у Вселенной. Мы лишь инструменты в её руках. ;)

Реter Konow:

Тщеславие?

Нет. Удовлетворение. Но не от тщеславия. Не знаю отчего. Возможно от частичного прореживания роя нереализованных идей и задач в моей голове. А ещё написание статей дисциплинирует, так как ответственность выше. Я существенно улучшил код этой библиотеки, которую изначально писал для себя. И это ещё далеко не предел.

А ещё оплата за статьи это хотя бы небольшая компенсация за потраченное время.

Реter Konow:

Головы ленивы в большинстве, и ценят готовые продукты гораздо больше чем наборы инструментов с инструкциями или стройматериалы, из которых эти продукты можно изготовить.  Будучи вынужденными, они воспользуются Вашей библиотекой, но при наличии возможности сократить усилия и создать интерфейс без написания кода, к сожалению, они быстро забудут Вашу прекрасную библиотеку. Это будет тем самым предательством, которое общество всегда подвергает честных и благородных людей, бескорыстно отдающих ему свои силы и душу.

Может быть в большинстве - да, но не все. Вот с ними я и делюсь. Также, как и они делятся с другими.

Кстати, визуальную студию для создания графических интерфейсов я тоже думаю сделать. Именно с помощью этой библиотеки она и будет создана. Хочу сделать что-то наподобие, как это сделано в Microsoft Visual Studio. А может быть даже и лучше. Время покажет. Всё, как обычно, начинается с небольших экспериментов. Что в итоге получится, даже я сам не знаю. )

Реter Konow:

Мне кажется что сообщество созрело для революции в практике создания торговых программ, а Вы хотите предоставить очередной "upgrade". Однако, при всем этом, я желаю Вам удачи. :)

Созрело конечно! Именно для этого я и решил всё это опубликовать. Зафиксироваться и двигаться в этом направлении дальше. ;)

 
Реter Konow:

Какие амбиции и какой оптимизм!!! Прям как у меня...)))

Ваши амбиции пока только на словах. Давайте уже продемонстрируйте свою конкуренцию!
 
Реter Konow:

Поясните пожалуйста, кому Вы адресуете свой призыв, - только мне, или нам с Анатолием обоим?

Если мне, то я недавно продемонстрировал базовые возможности своих окон, полосы прокрутки, таблицу, и спец-эффекты.

К вам, конечно. Вы хотите конкурировать с хорошо прокомментированными исходниками Анатолия своими видео-роликами? В какой номинации? )

Чтобы оценить программу, нужна, как минимум, демо-версия. Это же интерфейс, его нужно щупать.

Вот я и призываю перестать рассказывать о "страшном конкуренте", а поскорее перейти к его демонстрации ;)

 
Реter Konow:
... Спросите у Анатолия, считает ли он меня конкурентом. Пусть он сам Вам ответит. :)

Нет, я не считаю Вас конкурентом. Я работаю в другом формате и мы никак не пересекаемся. И на перегонки тоже играть не хочу. Буду работать в привычном для меня темпе.

Публикация материала с моей стороны осуществляется только после того, как я добиваюсь более-менее, на мой взгляд, приемлемого качества.

Кстати, следующая на публикацию статья: Графические интерфейсы VII: Элементы "Таблицы" (Глава 1). В ней будет представлено целых три класса таблиц. ;)

 
Реter Konow:

А я то надеялся, что немного посоревнуемся! :) Как жаль!... Ну ладно... Заметил, что в сообществе дух соревнования какой то слабоватый. Когда спросил про конкуренцию в маркете, - сказали что ее нет, когда пытался поддержать инициативу другого человека по проведению чемпионата, - так участников почти не нашлось... Скучновато как то...;) Ну и ладно.

Будущие статьи обязательно посмотрю. Удачи. :) 

Давайте соревноваться качеством и функционалом.

К тому же, с моей стороны уже вышло 18 статей. Можно считать, что это 18 ходов. Нет, 18 забитых голов в Ваши ворота. А Вы ещё ни одного не сделали. Обещаю забить Вам ещё минимум 7. Не очень интересно, когда игра идёт в одни ворота. ;)