Наворачивание внутри класса связных списков неизвестной размерности ради того, чтобы кто-то мог одной функцией раз в пятилетку "опросить все кнопки" наврядли можно назвать эффективным распоряжением ресурсов, как минимум.
+100
Почему вопрос ТС вызвал флейм и почему автора не устроили ответы? - очень просто. потому что его вопрос в отрыве от конкретной задачи смысла не имеет. Надо знать, что это за кнопки. сколько их, насколько похожа или отличается их функция...
если речь про 110 кнопок клавиатуры - обьединение их в один класс оправдано, так как работа с каждой кнопкой повторяет соседнюю. Если же одна кнопка - кнопка энкодера, а другая - включение питания внешнего модуля. то обьядинять их в один класс незачем. кнопки разные по сути и работать с ними нужно совершенно по разному.
Собственно говоря, я это прекрасно понимаю и говорил об однотипных кнопках.
Собственно говоря, я это прекрасно понимаю и говорил об однотипных кнопках.
А о переходе количество в качество не слышали. Если 1-2 кнопки , то можно плясать как одинарный клик,двойной,долгое нажатие. Но вот если из одиночных кнопок собирается клавиатура, то здесь эти пляски уже вредны.
Собственно говоря, я это прекрасно понимаю и говорил об однотипных кнопках.
А о переходе количество в качество не слышали. Если 1-2 кнопки , то можно плясать как одинарный клик,двойной,долгое нажатие. Но вот если из одиночных кнопок собирается клавиатура, то здесь эти пляски уже вредны.
Об этом, действительно не знал. Да что там и не подумал, что это может вызвать проблемы. То есть если 2 десятка кнопок, то двойные нажатия и тем более многократные могут привести к коллапсу? Или я не верно понял? После работы иногда мозг не все адекватно воспринимает.
Ну вы работали на убитой мышке, где правая , левая кнопка заедает. Вот так и будет чувствовать себе пользователь вашей программы. Это как камушек в ботинке . Ходить можно,но б**я, убил бы производителя.
И не противоречит ли это «написанию хорошего кода».
"Хороший код" превращается в отвратительный, как только перестаёт быть или эффективным или понятным.
Наворачивание внутри класса связных списков неизвестной размерности ради того, чтобы кто-то мог одной функцией раз в пятилетку "опросить все кнопки" наврядли можно назвать эффективным распоряжением ресурсов, как минимум.
Про бритву Оккама читали?
Понял, то есть такая реализация - далека от совершенства, от слова - вообще.
Про бритву с удовольствием прочту. Если можно ссылку дать? Если нет - постараюсь сам найти.
Прочел, не знал просто раньше, что "множить сущности" - это бритва Оккама....
Ну вы работали на убитой мышке, где правая , левая кнопка заедает. Вот так и будет чувствовать себе пользователь вашей программы. Это как камушек в ботинке . Ходить можно,но б**я, убил бы производителя.
Правильно ли я понимаю, что это зависит от количества используемых кнопок? Но ведь если обрабатывать тоже количество кнопок по отдельности, могут возникнуть похожие сценарии. Или я не прав в рассуждении?
Скорее не правильно понимаете. Программирование это не написание сферического коня в вакууме, а учет кучи компромиссов. И эти компромиссы могут вылезти когда уже все время и деньги потрачены.
Кхе...кхе... я не спрашивал про то как реализовать обработчик...
Я спросил можно ли как то из класса дернуть все его объекты единовременно.
Будь то это кнопки или датчики температуры и т.д.
Часть накинулась непонятно с чем, другая принялась показывать примеры обработчиков.
P.S. пытался перевести в нужное русло. задавал вопрос по тому как реализовывать, наследовать класы с сетевым соединением, когда соединение нужно нескольким объектам. Но форум поплыл своим курсом.
Кхе...кхе... я не спрашивал про то как реализовать обработчик...
Я спросил можно ли как то из класса дернуть все его объекты единовременно.
Будь то это кнопки или датчики температуры и т.д.
Часть накинулась непонятно с чем, другая принялась показывать примеры обработчиков.
P.S. пытался перевести в нужное русло. задавал вопрос по тому как реализовывать, наследовать класы с сетевым соединением, когда соединение нужно нескольким объектам. Но форум поплыл своим курсом.
А что за буза? Собственно все обсудили и ответили Вам. Или массивы или как я предложил - списки. Никто ни на что не накидывался. Вы поймите, вопрос частный на форуме - это решения (возможные) для большинства. Эго Ваше тут ни в русло, ни в камень.
ЗЫ: Ещё и моменты реализации для Вас же обсудили. Делайте выводы и вперёд! А если готовое решение если надо - мало вероятно что помогут. Я по своим знаниям могу чего подкинуть от нефиг делать, но это точно не тот случай.
Я спросил можно ли как то из класса дернуть все его объекты единовременно.
нет, без ухищрений типа "диспетчеров" - нельзя.
Класс - это лишь описание обьекта в общем. Оно никак не может взаимодействовать с конкретными экземплярами, так же, как атлас анатомии не влияет на конкретных людей, "класс" которых этот атлас описывает :)
Я спросил можно ли как то из класса дернуть все его объекты единовременно.
нет, без ухищрений типа "диспетчеров" - нельзя.
Класс - это лишь описание обьекта в общем. Оно никак не может взаимодействовать с конкретными экземплярами, так же, как атлас анатомии не влияет на конкретных людей, "класс" которых этот атлас описывает :)
Скорее механизм сложнее для пользователя, особенно если пользователю надо проще. Здесь сложность вешается на среду обработки.
Грубый аналог. Что бы передать на большие расстояние сообщение надо написать на бумаге письмо. Но если очень сильно вложится в технологию телефон-смарфон, то пользователю станет проще передать сообщение по телефону. Но каждый раз изобретать телефон, что бы передать сообщение.
ПС: Упрощено говоря. Вам это не дано. Мне это напряжно. Но некоторые из мелькающих на форуме прямо так и говорили использовать этот подход. Как вариант #153
Значит мои умозаключения были верны. Верно ли я понимаю, что реализация класса в данном виде невозможна и более логично сделать класс, элементами которого будет структура связанного списка с классом кнопки в качестве данных? Ух как сказал, сам в шоке))) И не противоречит ли это «написанию хорошего кода».
Если то, что я предложил в №11, не нравится из-за наличия двух классов, можно сделать и с одним - диспетчером, который при создании объекта возвращает его идентификационный номер, по которому в дальнейшем можно будет запрашивать состояние. Но это уже, строго говоря, не ООП, хотя диспетчер и может быть оформлен в виде класса.
Кроме того, если вариант из №11 позволял распределять память для кнопок как статически, так и динамически, а также кроме базового класса кнопок использовать их потомков, в варианте с единственным классом ни то, ни другое невозможно.
Диспетчер сам должен инициировать порождение объекта - тогда ничего ловить не придётся.
т.е. класс диспетчера должен быть унаследован от класса кнопки?
Зачем? Один объект может порождать другой вовсе не будучи с ним в родстве.
Другое дело, что можно создать базовый класс (назовем его "диспечеризуемый") который будет знать диспетчер. Тогда если создавать класс кнопки или чего еще от этого класса, то тогда диспетчер сможет их создавать, регистрировать и выполнять определенные действия не зависимо от того, что это кнопка или что-то еще.
В любом случае для ардуино с несколькими объектами сильно жирно делать обработчик. Проще и быстрее ручками написать. другое дело если gui со своими 100500 объектами.
В любом случае для ардуино с несколькими объектами сильно жирно делать обработчик. Проще и быстрее ручками написать. другое дело если gui со своими 100500 объектами.
А теперь вопрос для продвинутых в GUI- почему у смартфонов стоит сенсорный экран, а не что-то подобное мыши?
А вы как представляете таскать в кармане смартфон с мышью? ))
А как Вы представляете себе хрень в виде защитных стекол,дополнительных чехлов и все равно ресурс этой хрени мал. Словно кто-то задался извлеч лишние деньги. Так что роллербол или джойстик логичнее.
А как Вы представляете себе хрень в виде защитных стекол,дополнительных чехлов и все равно ресурс этой хрени мал. Словно кто-то задался извлеч лишние деньги. Так что роллербол или джойстик логичнее.
А что если поставить тракбол, то экран не нужен будет, что ли? Ну если бы очки типа Google Glasses получили распространение, тогда да. А так нужен будет и экран плюс тракбол, размеры увеличатся, а пользовать будет менее удобно.
Самое важное вы и не замечаете. Сколько вычислительных ресурсов тратится на... курсор мышки. Убирая этот компонент можно сэкономить ресурсы процессора и емкость аккумулятора. Что является критичным для карманных изделий. Да из всех технологий сенсорных экранов выбрали самый грубый, но очень энергоэкономнный.
При использовании вслепую сенсорный экран впереди роллерболлов на тыщу корпусов, например. И я еще помню, что такое джойстик на айбиэмовском thinkpad-e - просто адов пи-ец.
Самое важное вы и не замечаете. Сколько вычислительных ресурсов тратится на... курсор мышки. Убирая этот компонент можно сэкономить ресурсы процессора и емкость аккумулятора. Что является критичным для карманных изделий. Да из всех технологий сенсорных экранов выбрали самый грубый, но очень энергоэкономнный.
Ну и сколько? Цифры есть или так, просто абстрактные рассуждения? Да сенсорный экран потребляет больше трекбола, но разница составляет порядка процента в общем потребелении смартфона. И рессурсы центрального процессора сенсорный экран не расходует. Там стоит свой микроконтроллер, который спит пока в экран не тыкают.
asam, а вот и нет. Наличие на экране курсора мышки требует обновлять экран не реже раз в 0,1 секунду . А без этого обновлять по событию требующую перерисовку экрана. Перерисовка экрана это перекачка большого объема информации из буфера у процессора в буфер контроллера экрана. И все на весь этот праздник трубуется энергия.
asam, а вот и нет. Наличие на экране курсора мышки требует обновлять экран не реже раз в 0,1 секунду . А без этого обновлять по событию требующую перерисовку экрана. Перерисовка экрана это перекачка большого объема информации из буфера у процессора в буфер контроллера экрана. И все на весь этот праздник трубуется энергия.
Ну даже не буду обсуждать этот бред про "экран не реже раз в 0,1 секунду". Но даже если это и верно, то получается что трекбол или трекпад, которые и требуют наличия курсора, по вашему, получаеются менее экономичными, потому что для тачскрина курсор не нужен.
Точно. Так и есть. Конечно если питать от сети это не важно, но аккумуляторы малы по емкости и по ресурсу. Покупателю все же удобнее не подключать каждый день к зарядке. Тем более при менее мощном процессоре обгонять конкурентные модели это боллее сильное преимущество на рынке.
asam, а вот и нет. Наличие на экране курсора мышки требует обновлять экран не реже раз в 0,1 секунду . А без этого обновлять по событию требующую перерисовку экрана. Перерисовка экрана это перекачка большого объема информации из буфера у процессора в буфер контроллера экрана. И все на весь этот праздник трубуется энергия.
Иногда, Пух, лучше жевать, чем говорить. Ты старайся на улицу выходить пореже, у вас там, видимо, распыляют чота.
Точно. Так и есть. Конечно если питать от сети это не важно, но аккумуляторы малы по емкости и по ресурсу. Покупателю все же удобнее не подключать каждый день к зарядке. Тем более при менее мощном процессоре обгонять конкурентные модели это боллее сильное преимущество на рынке.
Пух, ты не поверишь, но мой любимый телефон Panasonic, был как раз с трекболом, а любимый из за того, что его раз в три дня к зарядке подключать приходилось (все остальные кажный день, а то и чаще), чисто в ждущем режиме вообще 180 часов обещали. На пенсию он ушел именно по причине окончательной смерти трекбола и отсутствия запчастей.
2
Наворачивание внутри класса связных списков неизвестной размерности ради того, чтобы кто-то мог одной функцией раз в пятилетку "опросить все кнопки" наврядли можно назвать эффективным распоряжением ресурсов, как минимум.
+100
Почему вопрос ТС вызвал флейм и почему автора не устроили ответы? - очень просто. потому что его вопрос в отрыве от конкретной задачи смысла не имеет. Надо знать, что это за кнопки. сколько их, насколько похожа или отличается их функция...
если речь про 110 кнопок клавиатуры - обьединение их в один класс оправдано, так как работа с каждой кнопкой повторяет соседнюю. Если же одна кнопка - кнопка энкодера, а другая - включение питания внешнего модуля. то обьядинять их в один класс незачем. кнопки разные по сути и работать с ними нужно совершенно по разному.
Собственно говоря, я это прекрасно понимаю и говорил об однотипных кнопках.
Об этом, действительно не знал. Да что там и не подумал, что это может вызвать проблемы. То есть если 2 десятка кнопок, то двойные нажатия и тем более многократные могут привести к коллапсу? Или я не верно понял? После работы иногда мозг не все адекватно воспринимает.
Ну вы работали на убитой мышке, где правая , левая кнопка заедает. Вот так и будет чувствовать себе пользователь вашей программы. Это как камушек в ботинке . Ходить можно,но б**я, убил бы производителя.
"Хороший код" превращается в отвратительный, как только перестаёт быть или эффективным или понятным.
Наворачивание внутри класса связных списков неизвестной размерности ради того, чтобы кто-то мог одной функцией раз в пятилетку "опросить все кнопки" наврядли можно назвать эффективным распоряжением ресурсов, как минимум.
Про бритву Оккама читали?
Понял, то есть такая реализация - далека от совершенства, от слова - вообще.
Про бритву с удовольствием прочту. Если можно ссылку дать? Если нет - постараюсь сам найти.
Прочел, не знал просто раньше, что "множить сущности" - это бритва Оккама....
Ну вы работали на убитой мышке, где правая , левая кнопка заедает. Вот так и будет чувствовать себе пользователь вашей программы. Это как камушек в ботинке . Ходить можно,но б**я, убил бы производителя.
Правильно ли я понимаю, что это зависит от количества используемых кнопок? Но ведь если обрабатывать тоже количество кнопок по отдельности, могут возникнуть похожие сценарии. Или я не прав в рассуждении?
Прочел, не знал просто раньше, что "множить сущности" - это бритва Оккама....
Не множить сущности.
Прочел, не знал просто раньше, что "множить сущности" - это бритва Оккама....
Не множить сущности.
Да да, прошу прощения. Не множить сущности.
Скорее не правильно понимаете. Программирование это не написание сферического коня в вакууме, а учет кучи компромиссов. И эти компромиссы могут вылезти когда уже все время и деньги потрачены.
Кхе...кхе... я не спрашивал про то как реализовать обработчик...
Я спросил можно ли как то из класса дернуть все его объекты единовременно.
Будь то это кнопки или датчики температуры и т.д.
Часть накинулась непонятно с чем, другая принялась показывать примеры обработчиков.
P.S. пытался перевести в нужное русло. задавал вопрос по тому как реализовывать, наследовать класы с сетевым соединением, когда соединение нужно нескольким объектам. Но форум поплыл своим курсом.
Кхе...кхе... я не спрашивал про то как реализовать обработчик...
Я спросил можно ли как то из класса дернуть все его объекты единовременно.
Будь то это кнопки или датчики температуры и т.д.
Часть накинулась непонятно с чем, другая принялась показывать примеры обработчиков.
P.S. пытался перевести в нужное русло. задавал вопрос по тому как реализовывать, наследовать класы с сетевым соединением, когда соединение нужно нескольким объектам. Но форум поплыл своим курсом.
А что за буза? Собственно все обсудили и ответили Вам. Или массивы или как я предложил - списки. Никто ни на что не накидывался. Вы поймите, вопрос частный на форуме - это решения (возможные) для большинства. Эго Ваше тут ни в русло, ни в камень.
ЗЫ: Ещё и моменты реализации для Вас же обсудили. Делайте выводы и вперёд! А если готовое решение если надо - мало вероятно что помогут. Я по своим знаниям могу чего подкинуть от нефиг делать, но это точно не тот случай.
anarch, Вы можете отличить графическую среду разработки от просто среды разработки. Мышеклик от программирования ручками.
это начало обсуждения совершенно по теме вопроса.
Я спросил можно ли как то из класса дернуть все его объекты единовременно.
нет, без ухищрений типа "диспетчеров" - нельзя.
Класс - это лишь описание обьекта в общем. Оно никак не может взаимодействовать с конкретными экземплярами, так же, как атлас анатомии не влияет на конкретных людей, "класс" которых этот атлас описывает :)
вот такой ответ я и ожидал ;)
вот такой ответ я и ожидал ;)
Такой ответ Вам в любой книге по Си прописан.
Я спросил можно ли как то из класса дернуть все его объекты единовременно.
нет, без ухищрений типа "диспетчеров" - нельзя.
Класс - это лишь описание обьекта в общем. Оно никак не может взаимодействовать с конкретными экземплярами, так же, как атлас анатомии не влияет на конкретных людей, "класс" которых этот атлас описывает :)
Грубый аналог. Что бы передать на большие расстояние сообщение надо написать на бумаге письмо. Но если очень сильно вложится в технологию телефон-смарфон, то пользователю станет проще передать сообщение по телефону. Но каждый раз изобретать телефон, что бы передать сообщение.
ПС: Упрощено говоря. Вам это не дано. Мне это напряжно. Но некоторые из мелькающих на форуме прямо так и говорили использовать этот подход. Как вариант #153
qwone у вас в #154 довольно изящное решение.
Рад буду увидеть сообщения от Вас завтра. Спокойной ночи и Вам и Вашему коту (как зовут кота?)
Кота зовут по-разному. Офицально - Модест Матвеич (Мотя), но откликается и на "Кудаб.я!!!" и на "Иди жрать, авнюк шерстяной"
В данный момент, кот не спит, значит, хочет жрать, какабычно.
У него 2 состояния - голод и энергосбережение. других нет.
Красотк!
Красотк!
дак у тебя такой же.
И даже тёзки (по отчеству) :)
Правда, моего так по отчеству (Матвеичем) и называют.
О, у меня тоже Мотя:
От рождения - Матильда Владимировна Поклонская (довелось ей в тот год родиться, а ветеринар в пачпорт писать отказалась), стала просто Матильда.)))
И тоже красотка :)
Значит мои умозаключения были верны. Верно ли я понимаю, что реализация класса в данном виде невозможна и более логично сделать класс, элементами которого будет структура связанного списка с классом кнопки в качестве данных? Ух как сказал, сам в шоке))) И не противоречит ли это «написанию хорошего кода».
Заранее спасибо за ответ.
Возможны сами разные реализации. Я подозреваю, что количество возможных реализаций, указанное в http://arduino.ru/forum/programmirovanie/vopros-po-oop#comment-481086 , является лишь нижней оценкой.
Если то, что я предложил в №11, не нравится из-за наличия двух классов, можно сделать и с одним - диспетчером, который при создании объекта возвращает его идентификационный номер, по которому в дальнейшем можно будет запрашивать состояние. Но это уже, строго говоря, не ООП, хотя диспетчер и может быть оформлен в виде класса.
Кроме того, если вариант из №11 позволял распределять память для кнопок как статически, так и динамически, а также кроме базового класса кнопок использовать их потомков, в варианте с единственным классом ни то, ни другое невозможно.
А каким образом можно поймать момент создания объекта и поместить его в диспетчер?
Диспетчер сам должен инициировать порождение объекта - тогда ничего ловить не придётся.
Диспетчер сам должен инициировать порождение объекта - тогда ничего ловить не придётся.
Или уж на худой конец, объекты при своём создании (в конструкторе) должны у него (диспетчера) регистрироваться.
Диспетчер сам должен инициировать порождение объекта - тогда ничего ловить не придётся.
т.е. класс диспетчера должен быть унаследован от класса кнопки?
Диспетчер сам должен инициировать порождение объекта - тогда ничего ловить не придётся.
т.е. класс диспетчера должен быть унаследован от класса кнопки?
Зачем? Один объект может порождать другой вовсе не будучи с ним в родстве.
Другое дело, что можно создать базовый класс (назовем его "диспечеризуемый") который будет знать диспетчер. Тогда если создавать класс кнопки или чего еще от этого класса, то тогда диспетчер сможет их создавать, регистрировать и выполнять определенные действия не зависимо от того, что это кнопка или что-то еще.
Существует метод(инструмент) в ОПП, что бы одним вызовом loop() произошел опрос всех объектов.
ок. если бы я ещё понимал этот куриный язык - "ООП", "методы".
начинай читать тему с конца #558
в лупе объекту/ам передаётся структура параметров/значений, затем читаются переменные объекта/ов.
!таки, выносит мозг вопрос - "как?"
void setup() { button_0(); button_1(); button_2(); button_3(); }а, как иначе?
В любом случае для ардуино с несколькими объектами сильно жирно делать обработчик. Проще и быстрее ручками написать. другое дело если gui со своими 100500 объектами.
В любом случае для ардуино с несколькими объектами сильно жирно делать обработчик. Проще и быстрее ручками написать. другое дело если gui со своими 100500 объектами.
А вы как представляете таскать в кармане смартфон с мышью? ))
А вы как представляете таскать в кармане смартфон с мышью? ))
ну защитное стекло ни как не спасает от количества прикосновений если вы об этом. у чехла и защитного стекла немного другой функционал.
А что если поставить тракбол, то экран не нужен будет, что ли? Ну если бы очки типа Google Glasses получили распространение, тогда да. А так нужен будет и экран плюс тракбол, размеры увеличатся, а пользовать будет менее удобно.
Самое важное вы и не замечаете. Сколько вычислительных ресурсов тратится на... курсор мышки. Убирая этот компонент можно сэкономить ресурсы процессора и емкость аккумулятора. Что является критичным для карманных изделий. Да из всех технологий сенсорных экранов выбрали самый грубый, но очень энергоэкономнный.
т.е. если бы мышь жрала меньше ресурсов мы бы сейчас в одном кармане смартфон тигали а во втором мышу?
бред какой то...
anarch, повербанк тягается и ничего. а до этого ноуты тягать никого не напрягало.
придет время вместо литиевых элементов будет термоядерный реактор в смартфоне просто подождать нужно немного ))
и не придется таскать павербанк ))
Так что роллербол или джойстик логичнее.
При использовании вслепую сенсорный экран впереди роллерболлов на тыщу корпусов, например. И я еще помню, что такое джойстик на айбиэмовском thinkpad-e - просто адов пи-ец.
Самое важное вы и не замечаете. Сколько вычислительных ресурсов тратится на... курсор мышки. Убирая этот компонент можно сэкономить ресурсы процессора и емкость аккумулятора. Что является критичным для карманных изделий. Да из всех технологий сенсорных экранов выбрали самый грубый, но очень энергоэкономнный.
Ну и сколько? Цифры есть или так, просто абстрактные рассуждения? Да сенсорный экран потребляет больше трекбола, но разница составляет порядка процента в общем потребелении смартфона. И рессурсы центрального процессора сенсорный экран не расходует. Там стоит свой микроконтроллер, который спит пока в экран не тыкают.
asam, а вот и нет. Наличие на экране курсора мышки требует обновлять экран не реже раз в 0,1 секунду . А без этого обновлять по событию требующую перерисовку экрана. Перерисовка экрана это перекачка большого объема информации из буфера у процессора в буфер контроллера экрана. И все на весь этот праздник трубуется энергия.
asam, а вот и нет. Наличие на экране курсора мышки требует обновлять экран не реже раз в 0,1 секунду . А без этого обновлять по событию требующую перерисовку экрана. Перерисовка экрана это перекачка большого объема информации из буфера у процессора в буфер контроллера экрана. И все на весь этот праздник трубуется энергия.
Ну даже не буду обсуждать этот бред про "экран не реже раз в 0,1 секунду". Но даже если это и верно, то получается что трекбол или трекпад, которые и требуют наличия курсора, по вашему, получаеются менее экономичными, потому что для тачскрина курсор не нужен.
Точно. Так и есть. Конечно если питать от сети это не важно, но аккумуляторы малы по емкости и по ресурсу. Покупателю все же удобнее не подключать каждый день к зарядке. Тем более при менее мощном процессоре обгонять конкурентные модели это боллее сильное преимущество на рынке.
nokia 3310 наше все!
А без этого обновлять по событию требующую перерисовку экрана.
o_O
asam, а вот и нет. Наличие на экране курсора мышки требует обновлять экран не реже раз в 0,1 секунду . А без этого обновлять по событию требующую перерисовку экрана. Перерисовка экрана это перекачка большого объема информации из буфера у процессора в буфер контроллера экрана. И все на весь этот праздник трубуется энергия.
Иногда, Пух, лучше жевать, чем говорить. Ты старайся на улицу выходить пореже, у вас там, видимо, распыляют чота.
Точно. Так и есть. Конечно если питать от сети это не важно, но аккумуляторы малы по емкости и по ресурсу. Покупателю все же удобнее не подключать каждый день к зарядке. Тем более при менее мощном процессоре обгонять конкурентные модели это боллее сильное преимущество на рынке.
Пух, ты не поверишь, но мой любимый телефон Panasonic, был как раз с трекболом, а любимый из за того, что его раз в три дня к зарядке подключать приходилось (все остальные кажный день, а то и чаще), чисто в ждущем режиме вообще 180 часов обещали. На пенсию он ушел именно по причине окончательной смерти трекбола и отсутствия запчастей.