Встала задача реализации программы с графическим интерфейсом.
По функциональности, что-то вроде программ для банкоматов.
То есть стоит выбор какого-то GUI API для написания данной программы.Конечно, можно написать её на том же Delphi/CBuilder, но система должна быть максимально отказоустойчива. А крутить её под потенциально подверженой к сбоям осью, мне стремновато... 8(
Что уважаемый алл может предложить/посоветовать?
ЗЫ:
Прочёл что написал и ужаснулся 8(
Понимаю, что написано коряво, но за последнюю неделю спал в сумме не более 24 часов 8( Так что уточняйте, не стесняйтесь! 8)
если ты под на паскале коряво пишеш, то на чем другом ты можеш написать не коряво? :))) Отказоустойчивый гуй - XLib.. кроссплатформенного гуя бесплатного нормального нет. Только QT под Win собраный VC++ есть нормаьный, но денег стоит. Так что если проект серьезный - покупай, если же кросс платформенность не надо - то .NET widgets, иначе - Swing... В чем пробема? Выбор средств всегда самая сложная задача.
А вообще писать надо c MVC (не MFC, а Model-View-Controler)... тогда в случае неудачного выбора GUI его легко можно заменить.
>если ты под на паскале коряво пишеш, то на чем другом ты
>можеш написать не коряво? :))) Отказоустойчивый гуй - XLib.. кроссплатформенного гуя
>бесплатного нормального нет. Только QT под Win собраный VC++ есть нормаьный,
>но денег стоит. Так что если проект серьезный - покупай, если
>же кросс платформенность не надо - то .NET widgets, иначе -
>Swing... В чем пробема? Выбор средств всегда самая сложная задача.
>А вообще писать надо c MVC (не MFC, а Model-View-Controler)... тогда в
>случае неудачного выбора GUI его легко можно заменить.
Я не говорил, что пишу коряво.... (это так, для проформы 8) )Кроссплатформености не надо.
Нужна скорость разработки и увереность в дальнейшей работе.
Пока что рассмотриваю QT...
Но возник ещё один вопрос по ходу дела: "А как дела обстоят с генерацией отчётов и их последующей печатью?"
Чем это можно сделать?
>Кроссплатформености не надо.
>Нужна скорость разработки и увереность в дальнейшей работе.
>Пока что рассмотриваю QT...imho единственный разумный вариант.
>Но возник ещё один вопрос по ходу дела: "А как дела обстоят
>с генерацией отчётов и их последующей печатью?"
>Чем это можно сделать?если на базе Qt: http://www.openrpt.com/
// wbr
>>Кроссплатформености не надо.
>>Нужна скорость разработки и увереность в дальнейшей работе.
>>Пока что рассмотриваю QT...
>
>imho единственный разумный вариант.
>
>>Но возник ещё один вопрос по ходу дела: "А как дела обстоят
>>с генерацией отчётов и их последующей печатью?"
>>Чем это можно сделать?
>
>если на базе Qt: http://www.openrpt.com/
>
>// wbrНе совсем согласен с глубокоуважаемым сэром. Банкомат - это весьма специфическая система, и я не думаю, что использование таких вещей, как Qt или GTK+ тут будет очень уместно. Эти продукты заточены под работу с мышой в качестве основного интерфейса, что наблюдается у нас при работе на десктопе. Где вы видели банкомат с мышой? По функциональности интерфейс банкомата можно сравнить с интерфейсом компьютерной игры: есть немного пунктов меню, и есть кнопки, чтобы их выбирать. Обычно для игр делают свой гуи - это совсем не сложно, так как там очень простая логика работы и не нужны сложные виджеты. Я думаю, что Вам надо подумать в этом направлении. Недостаток данного подхода - не такая высокая скорость разработки. Достоинство: можно написать очень компактный, стабильный и неприхотливый к железу код.
>Не совсем согласен с глубокоуважаемым сэром. Банкомат - это весьма специфическая система,
>и я не думаю, что использование таких вещей, как Qt или
>GTK+ тут будет очень уместно. Эти продукты заточены под работу с
>мышой в качестве основного интерфейса, что наблюдается у нас при работе
>на десктопе. Где вы видели банкомат с мышой? По функциональности интерфейс
>банкомата можно сравнить с интерфейсом компьютерной игры: есть немного пунктов меню,
>и есть кнопки, чтобы их выбирать. Обычно для игр делают свой
>гуи - это совсем не сложно, так как там очень простая
>логика работы и не нужны сложные виджеты. Я думаю, что Вам
>надо подумать в этом направлении. Недостаток данного подхода - не такая
>высокая скорость разработки. Достоинство: можно написать очень компактный, стабильный и неприхотливый
>к железу код.Уважаемый сэр dimus,
искренне желаю Вам впредь, перед высказываниями, тщательно ознакомиться с материалом и предварять свои личные соображения абревиатурой "IMHO"..
потому как необдуманные фразы могут внести сумятицу в неокрепшие мозги неофитов.
А теперь, по делу - 1) и Qt и GTK совершенно спокойно (первый гораздо спокойнее) работают с touch-screen`ом и нестандартным железом.
2) для 'специфического железа' банкоматов (и банко-мётов) ни одна серьёзная компания не будет отдельно делать свой ГУЙ.
3) по интерфейсу банкоматы - чистая ембедед платформа со своими наворотами по безопасности, а отнють не sokoban/Q3 и банк более интересуют именно вопросы безопасности а не интерфейс, поэтому вперед выходят платформы Linux+Qtembeded, QNX+Photon
> А теперь, по делу - 1) и Qt и GTK
>совершенно спокойно (первый гораздо спокойнее) работают с touch-screen`ом и нестандартным железом.
>
>2) для 'специфического железа' банкоматов (и банко-мётов) ни одна серьёзная компания
>не будет отдельно делать свой ГУЙ.
>3) по интерфейсу банкоматы - чистая ембедед платформа со своими наворотами по
>безопасности, а отнють не sokoban/Q3 и банк более интересуют именно вопросы
>безопасности а не интерфейс, поэтому вперед выходят платформы Linux+Qtembeded, QNX+PhotonК сожалению видимо я недостаточно ясно высказал свою мысль, раз мои слова так восприняли.
IMHO/Мое личное мнение (надеюсь, что неокрепшие мозги от этого не пострадают :) ):
1. Qt или GTK прекрасно могут справиться с такой задачей, используя при этом лишь мизерную часть своих возможностей. При этом в качесве балласта вы получите те самые неиспользуемые возможности - целая куча кода, которая возможно содержит какие-то дыры. Для того, чтобы где-то разместить избыточный код, вам потребуется дополнительная память и дополнительные вычислительные мощности - а значит более мощное и дорогое железо.
2. Не согласен с Вашим вторым утверждением по причинам, изложенным в пункте первом.
3. По безопасности интерфейс компьютерных игр находится на очень высоком уровне (если не брать в расчет возможности "консоли", хотя и там больно не порезвишься). Если Вам кажется, что тут я не прав - попробуйте включить какую-нибудь игру и захватить при помощи меню игровых настроек контроль над системой. А я посмотрю, как у вас это получится. Думаю, что зрелище будет веселое.
Также не имею ничего против Linux+Qtembeded или QNX+Photon, просто в очень многих случаях и их возможностей может быть с избытком. Хотя, по крайней мере в случае Фотона, разработчики хорошо постарались в плане оптимизации.
Если уж мы начали про банкоматы, то давайте посмотрим, что нам реально надо из возможностей интерфейса.
1. Надо принять ввод пользователя - нужно обрабатывать нажатия клавишь.
2. Желательно иметь некое подобие окошек - это помогает сгруппировать важную информацию и вообще делает диалог с пользователем более наглядным. Нам не надо, чтобы они могли двигаться, изменять свои размеры, передавать другим окнам фокус ввода и пр. Короче, нам надо нарисовать прямоугольник, возможно с какими-то красивостями, в определенных координатах.
3. Надо отрисовывать надписи на экране. Координаты надписей возможно должны иметь привязку к координатам окошек, однако и это не обязательно.И это все. По моим прикидкам, для того, чтобы это работало нам за глаза хватит возможностей древнего 386 компа. Код самого ГУИ после компиляции будет весить 5 - 10 КБ и может быть написан и отлажен за пару дней.
Вобщем, если подвести итог моим мыслям, то он будет такой: не всегда следование традиционным путем дает наилучший результат. Есть многие случаи, когда нетрадиционный путь может дать гораздо большую выгоду.
Уважаемый сэр dimus,
Важе подход с разработкам, вызывает некоторое восхищение,
ибо программисты по большей части ленивы и не делают все компоненты сами,
стараясь максимально использовать наработанные и проверенные компоненты.Особенно восхищаться будет заказчик,узнав что сделанная Вами система насмерть привязанна к железу, обладает уникальными методами ввода-вывода,
требует значительных затрат по содержанию и по завершению жизненного цикла
подлежит полному списанию (то есть не подлежит модернизации).предположим, делается автомат который принимает деньги с кредитной карты
и продает пиво,воды и журналы. Этап проектирования.Пользователь должен иметь возможность выбора товара, при этом ему должна быть отображенна максимально полная информация о товаре, может расплачиваться средствами разных платёжных систем, при этом получать информацию о состянии счёта etc etc.. Срок разработки - 1 год, предполагаемый срок эксплуатации 7 лет. предусмотреть возможность модернизации при увеличении асортимента, изменениях в аппаратной платформе, ввода новых платёжных систем или изменения законодательства.
- попробуйте назвать компонент Qt который АБСОЛЮТНО ТОЧНО не понадобится.
- прикиньте срок разработки (вместе с отладкой и доводкой на разном железе) самодельного GUI
- посчитаёте зарплату команды разработчиков сомодельного ГУЯ на восемь лет
(это чтобы они не разбежались и при необходимости доводили ГУЙ)по поводу безопасности игрушек-свителок и ПО банковской сферы - это даже не поддается сравнению. У них просто разные критерии.. Почитайте умных книжек - всегда полезно..
>К сожалению видимо я недостаточно ясно высказал свою мысль, раз мои слова
>так восприняли.
>IMHO/Мое личное мнение (надеюсь, что неокрепшие мозги от этого не пострадают :)
>):
>1. Qt или GTK прекрасно могут справиться с такой задачей, используя при
>этом лишь мизерную часть своих возможностей. При этом в качесве балласта
>вы получите те самые неиспользуемые возможности - целая куча кода, которая
>возможно содержит какие-то дыры. Для того, чтобы где-то разместить избыточный код,
>вам потребуется дополнительная память и дополнительные вычислительные мощности - а значит
>более мощное и дорогое железо.
>2. Не согласен с Вашим вторым утверждением по причинам, изложенным в пункте
>первом.
>3. По безопасности интерфейс компьютерных игр находится на очень высоком уровне (если
>не брать в расчет возможности "консоли", хотя и там больно не
>порезвишься). Если Вам кажется, что тут я не прав - попробуйте
>включить какую-нибудь игру и захватить при помощи меню игровых настроек контроль
>над системой. А я посмотрю, как у вас это получится. Думаю,
>что зрелище будет веселое.
>Также не имею ничего против Linux+Qtembeded или QNX+Photon, просто в очень многих
>случаях и их возможностей может быть с избытком. Хотя, по крайней
>мере в случае Фотона, разработчики хорошо постарались в плане оптимизации.
>Если уж мы начали про банкоматы, то давайте посмотрим, что нам реально
>надо из возможностей интерфейса.
>1. Надо принять ввод пользователя - нужно обрабатывать нажатия клавишь.
>2. Желательно иметь некое подобие окошек - это помогает сгруппировать важную информацию
>и вообще делает диалог с пользователем более наглядным. Нам не надо,
>чтобы они могли двигаться, изменять свои размеры, передавать другим окнам фокус
>ввода и пр. Короче, нам надо нарисовать прямоугольник, возможно с какими-то
>красивостями, в определенных координатах.
>3. Надо отрисовывать надписи на экране. Координаты надписей возможно должны иметь привязку
>к координатам окошек, однако и это не обязательно.
>
>И это все. По моим прикидкам, для того, чтобы это работало нам
>за глаза хватит возможностей древнего 386 компа. Код самого ГУИ после
>компиляции будет весить 5 - 10 КБ и может быть написан
>и отлажен за пару дней.
>
>Вобщем, если подвести итог моим мыслям, то он будет такой: не всегда
>следование традиционным путем дает наилучший результат. Есть многие случаи, когда нетрадиционный
>путь может дать гораздо большую выгоду.я воздержусь от комментариев :) могу лишь посоветовать, если будет оказия, посмотреть на врутренности банкомата. вы там сможете увидеть массу до боли знакомых вещей.. впрочем, это может быть тот или иной более-менее новый POS, информационный терминал (зайдите в оффис МТС или на вокзал) и иже с ними.
// wbr
>Не совсем согласен с глубокоуважаемым сэром. Банкомат - это весьма специфическая система,
>и я не думаю, что использование таких вещей, как Qt или
>GTK+ тут будет очень уместно. Эти продукты заточены под работу с
>мышой в качестве основного интерфейса, что наблюдается у нас при работе
>на десктопе. Где вы видели банкомат с мышой?у меня на столе стоит не банкомат, но устройство управлением системой XYZ. все общение через сенсорный экран 17". мыши и клавиатуры ессно нет, оператор может только возить пальцем по дисплею.
по собственному опыту, Qt3/4 прекрасно подходит для таких достаточно специфичных с точки срения ввода вещей.
> По функциональности интерфейс
>банкомата можно сравнить с интерфейсом компьютерной игры: есть немного пунктов меню,
>и есть кнопки, чтобы их выбирать.да. вопрос - чем принципиально отличается выбор элемента xyz посредством пальца на дисплее и мышкой? ответ - ничем :)
> Обычно для игр делают свой
>гуи - это совсем не сложно, так как там очень простая
>логика работы и не нужны сложные виджеты. Я думаю, что Вам
>надо подумать в этом направлении. Недостаток данного подхода - не такая
>высокая скорость разработки. Достоинство: можно написать очень компактный, стабильный и неприхотливый
>к железу код.боже упаси вас разрабатывать/использовать для таких систем "свой gui". выгоды чистый ноль или минус, а трахов выше всякой крыши.
// wbr
Кросплатформенность не нужна? :) Тогда Kylix... CBuilder - быстро, легко и в кратчайшие сроки ваяемпрограммы.
Однако - попахивает пионерией...
>Понимаю, что написано коряво, но за последнюю неделю спал в сумме не
>более 24 часов 8( Так что уточняйте, не стесняйтесь! 8)<offtopic>
Время сна обратно-пропорционально продуктивности работы. Вроде даже Linus T. уделял этой проблеме пару строчек в своем "Just For Fun".
</offtopic>
>Встала задача реализации программы с графическим интерфейсом.
>По функциональности, что-то вроде программ для банкоматов.
>То есть стоит выбор какого-то GUI API для написания данной программы.
>
>Конечно, можно написать её на том же Delphi/CBuilder, но система должна быть
>максимально отказоустойчива. А крутить её под потенциально подверженой к сбоям осью,
>мне стремновато... 8(
>
>Что уважаемый алл может предложить/посоветовать?
Может это тот случай когда подойдет TCL/TK ?