The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]




Версия для распечатки Пред. тема | След. тема
Новые ответы [ Отслеживать ]
Выбор среды и средств разработки графического приложения?, !*! Defender, 12-Июл-05, 23:11  [смотреть все]
Встала задача реализации программы с графическим интерфейсом.
По функциональности, что-то вроде программ для банкоматов.
То есть стоит выбор какого-то GUI API для написания данной программы.

Конечно, можно написать её на том же Delphi/CBuilder, но система должна быть максимально отказоустойчива. А крутить её под потенциально подверженой к сбоям осью, мне стремновато... 8(

Что уважаемый алл может предложить/посоветовать?

ЗЫ:
Прочёл что написал и ужаснулся 8(
Понимаю, что написано коряво, но за последнюю неделю спал в сумме не более 24 часов 8( Так что уточняйте, не стесняйтесь! 8)

  • Выбор среды и средств разработки графического приложения?, !*! Lazarenko, 00:32 , 13-Июл-05 (1)
    если ты под на паскале коряво пишеш, то на чем другом ты можеш написать не коряво? :))) Отказоустойчивый гуй - XLib.. кроссплатформенного гуя бесплатного нормального нет. Только QT под Win собраный VC++ есть нормаьный, но денег стоит. Так что если проект серьезный - покупай, если же кросс платформенность не надо - то .NET widgets, иначе - Swing... В чем пробема? Выбор средств всегда самая сложная задача.
    А вообще писать надо c MVC (не MFC, а Model-View-Controler)... тогда в случае неудачного выбора GUI его легко можно заменить.
    • Выбор среды и средств разработки графического приложения?, !*! Defender, 00:45 , 13-Июл-05 (2)
      >если ты под на паскале коряво пишеш, то на чем другом ты
      >можеш написать не коряво? :))) Отказоустойчивый гуй - XLib.. кроссплатформенного гуя
      >бесплатного нормального нет. Только QT под Win собраный VC++ есть нормаьный,
      >но денег стоит. Так что если проект серьезный - покупай, если
      >же кросс платформенность не надо - то .NET widgets, иначе -
      >Swing... В чем пробема? Выбор средств всегда самая сложная задача.
      >А вообще писать надо c MVC (не MFC, а Model-View-Controler)... тогда в
      >случае неудачного выбора GUI его легко можно заменить.
      Я не говорил, что пишу коряво.... (это так, для проформы 8) )

      Кроссплатформености не надо.
      Нужна скорость разработки и увереность в дальнейшей работе.
      Пока что рассмотриваю QT...
      Но возник ещё один вопрос по ходу дела: "А как дела обстоят с генерацией отчётов и их последующей печатью?"
      Чем это можно сделать?

      • Выбор среды и средств разработки графического приложения?, !*! klalafuda, 16:39 , 14-Июл-05 (4)
        >Кроссплатформености не надо.
        >Нужна скорость разработки и увереность в дальнейшей работе.
        >Пока что рассмотриваю QT...

        imho единственный разумный вариант.

        >Но возник ещё один вопрос по ходу дела: "А как дела обстоят
        >с генерацией отчётов и их последующей печатью?"
        >Чем это можно сделать?

        если на базе Qt: http://www.openrpt.com/

        // wbr


        • Выбор среды и средств разработки графического приложения?, !*! dimus, 15:33 , 25-Июл-05 (6)
          >>Кроссплатформености не надо.
          >>Нужна скорость разработки и увереность в дальнейшей работе.
          >>Пока что рассмотриваю QT...
          >
          >imho единственный разумный вариант.
          >
          >>Но возник ещё один вопрос по ходу дела: "А как дела обстоят
          >>с генерацией отчётов и их последующей печатью?"
          >>Чем это можно сделать?
          >
          >если на базе Qt: http://www.openrpt.com/
          >
          >// wbr

          Не совсем согласен с глубокоуважаемым сэром. Банкомат - это весьма специфическая система, и я не думаю, что использование таких вещей, как Qt или GTK+ тут будет очень уместно. Эти продукты заточены под работу с мышой в качестве основного интерфейса, что наблюдается у нас при работе на десктопе. Где вы видели банкомат с мышой? По функциональности интерфейс банкомата можно сравнить с интерфейсом компьютерной игры: есть немного пунктов меню, и есть кнопки, чтобы их выбирать. Обычно для игр делают свой гуи - это совсем не сложно, так как там очень простая логика работы и не нужны сложные виджеты. Я думаю, что Вам надо подумать в этом направлении. Недостаток данного подхода - не такая высокая скорость разработки. Достоинство: можно написать очень компактный, стабильный и неприхотливый к железу код.

          • Выбор среды и средств разработки графического приложения?, !*! Maxim Kuznetsov, 15:54 , 25-Июл-05 (7)
            >Не совсем согласен с глубокоуважаемым сэром. Банкомат - это весьма специфическая система,
            >и я не думаю, что использование таких вещей, как Qt или
            >GTK+ тут будет очень уместно. Эти продукты заточены под работу с
            >мышой в качестве основного интерфейса, что наблюдается у нас при работе
            >на десктопе. Где вы видели банкомат с мышой? По функциональности интерфейс
            >банкомата можно сравнить с интерфейсом компьютерной игры: есть немного пунктов меню,
            >и есть кнопки, чтобы их выбирать. Обычно для игр делают свой
            >гуи - это совсем не сложно, так как там очень простая
            >логика работы и не нужны сложные виджеты. Я думаю, что Вам
            >надо подумать в этом направлении. Недостаток данного подхода - не такая
            >высокая скорость разработки. Достоинство: можно написать очень компактный, стабильный и неприхотливый
            >к железу код.

            Уважаемый сэр dimus,
            искренне желаю Вам впредь, перед высказываниями, тщательно ознакомиться с материалом и предварять свои личные соображения абревиатурой "IMHO"..
            потому как необдуманные фразы могут внести сумятицу в неокрепшие мозги неофитов.
              А теперь, по делу - 1) и Qt и GTK совершенно спокойно (первый гораздо спокойнее) работают с touch-screen`ом и нестандартным железом.
            2) для 'специфического железа'  банкоматов (и банко-мётов) ни одна серьёзная компания не будет отдельно делать свой ГУЙ.
            3) по интерфейсу банкоматы - чистая ембедед платформа со своими наворотами по безопасности, а отнють не sokoban/Q3 и банк более интересуют именно вопросы безопасности а не интерфейс, поэтому вперед выходят платформы Linux+Qtembeded, QNX+Photon

            • Выбор среды и средств разработки графического приложения?, !*! dimus, 08:07 , 27-Июл-05 (10)

              >  А теперь, по делу - 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 КБ и может быть написан и отлажен за пару дней.

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

              • Выбор среды и средств разработки графического приложения?, !*! MaximKuznetsov, 10:03 , 27-Июл-05 (11)
                Уважаемый сэр dimus,
                Важе подход с разработкам, вызывает некоторое восхищение,
                ибо программисты по большей части ленивы и не делают все компоненты сами,
                стараясь максимально использовать наработанные и проверенные компоненты.

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

                предположим, делается автомат который принимает деньги с кредитной карты
                и продает пиво,воды и журналы. Этап проектирования.

                Пользователь должен иметь возможность выбора товара, при этом ему должна быть отображенна максимально полная информация о товаре, может расплачиваться средствами разных платёжных систем, при этом получать информацию о состянии счёта etc etc.. Срок разработки - 1 год, предполагаемый срок эксплуатации 7 лет. предусмотреть возможность модернизации при увеличении асортимента, изменениях в аппаратной платформе, ввода новых платёжных систем или изменения законодательства.

                - попробуйте назвать компонент Qt который АБСОЛЮТНО ТОЧНО не понадобится.
                - прикиньте срок разработки (вместе с отладкой и доводкой на разном железе) самодельного GUI
                - посчитаёте зарплату команды разработчиков сомодельного ГУЯ на восемь лет
                (это чтобы они не разбежались и при необходимости доводили ГУЙ)

                по поводу безопасности игрушек-свителок и ПО банковской сферы - это даже не поддается сравнению. У них просто разные критерии.. Почитайте умных книжек - всегда полезно..

              • Выбор среды и средств разработки графического приложения?, !*! klalafuda, 12:09 , 27-Июл-05 (12)
                >К сожалению видимо я недостаточно ясно высказал свою мысль, раз мои слова
                >так восприняли.
                >IMHO/Мое личное мнение (надеюсь, что неокрепшие мозги от этого не пострадают :)
                >):
                >1. Qt или GTK прекрасно могут справиться с такой задачей, используя при
                >этом лишь мизерную часть своих возможностей. При этом в качесве балласта
                >вы получите те самые неиспользуемые возможности - целая куча кода, которая
                >возможно содержит какие-то дыры. Для того, чтобы где-то разместить избыточный код,
                >вам потребуется дополнительная память и дополнительные вычислительные мощности - а значит
                >более мощное и дорогое железо.
                >2. Не согласен с Вашим вторым утверждением по причинам, изложенным в пункте
                >первом.
                >3. По безопасности интерфейс компьютерных игр находится на очень высоком уровне (если
                >не брать в расчет возможности "консоли", хотя и там больно не
                >порезвишься). Если Вам кажется, что тут я не прав - попробуйте
                >включить какую-нибудь игру и захватить при помощи меню игровых настроек контроль
                >над системой. А я посмотрю, как у вас это получится. Думаю,
                >что зрелище будет веселое.
                >Также не имею ничего против Linux+Qtembeded или QNX+Photon, просто в очень многих
                >случаях и их возможностей может быть с избытком. Хотя, по крайней
                >мере в случае Фотона, разработчики хорошо постарались в плане оптимизации.
                >Если уж мы начали про банкоматы, то давайте посмотрим, что нам реально
                >надо из возможностей интерфейса.
                >1. Надо принять ввод пользователя - нужно обрабатывать нажатия клавишь.
                >2. Желательно иметь некое подобие окошек - это помогает сгруппировать важную информацию
                >и вообще делает диалог с пользователем более наглядным. Нам не надо,
                >чтобы они могли двигаться, изменять свои размеры, передавать другим окнам фокус
                >ввода и пр. Короче, нам надо нарисовать прямоугольник, возможно с какими-то
                >красивостями, в определенных координатах.
                >3. Надо отрисовывать надписи на экране. Координаты надписей возможно должны иметь привязку
                >к координатам окошек, однако и это не обязательно.
                >
                >И это все. По моим прикидкам, для того, чтобы это работало нам
                >за глаза хватит возможностей древнего 386 компа. Код самого ГУИ после
                >компиляции будет весить 5 - 10 КБ и может быть написан
                >и отлажен за пару дней.
                >
                >Вобщем, если подвести итог моим мыслям, то он будет такой: не всегда
                >следование традиционным путем дает наилучший результат. Есть многие случаи, когда нетрадиционный
                >путь может дать гораздо большую выгоду.

                я воздержусь от комментариев :) могу лишь посоветовать, если будет оказия, посмотреть на врутренности банкомата. вы там сможете увидеть массу до боли знакомых вещей.. впрочем, это может быть тот или иной более-менее новый POS, информационный терминал (зайдите в оффис МТС или на вокзал) и иже с ними.

                // wbr

          • Выбор среды и средств разработки графического приложения?, !*! klalafuda, 08:22 , 26-Июл-05 (8)
            >Не совсем согласен с глубокоуважаемым сэром. Банкомат - это весьма специфическая система,
            >и я не думаю, что использование таких вещей, как Qt или
            >GTK+ тут будет очень уместно. Эти продукты заточены под работу с
            >мышой в качестве основного интерфейса, что наблюдается у нас при работе
            >на десктопе. Где вы видели банкомат с мышой?

            у меня на столе стоит не банкомат, но устройство управлением системой XYZ. все общение через сенсорный экран 17". мыши и клавиатуры ессно нет, оператор может только возить пальцем по дисплею.

            по собственному опыту, Qt3/4 прекрасно подходит для таких достаточно специфичных с точки срения ввода вещей.

            > По функциональности интерфейс
            >банкомата можно сравнить с интерфейсом компьютерной игры: есть немного пунктов меню,
            >и есть кнопки, чтобы их выбирать.

            да. вопрос - чем принципиально отличается выбор элемента xyz посредством пальца на дисплее и мышкой? ответ - ничем :)

            > Обычно для игр делают свой
            >гуи - это совсем не сложно, так как там очень простая
            >логика работы и не нужны сложные виджеты. Я думаю, что Вам
            >надо подумать в этом направлении. Недостаток данного подхода - не такая
            >высокая скорость разработки. Достоинство: можно написать очень компактный, стабильный и неприхотливый
            >к железу код.

            боже упаси вас разрабатывать/использовать для таких систем "свой gui". выгоды чистый ноль или минус, а трахов выше всякой крыши.

            // wbr

      • Выбор среды и средств разработки графического приложения?, !*! Vladislav, 22:31 , 15-Июл-05 (5)
        Кросплатформенность не нужна? :) Тогда Kylix... CBuilder - быстро, легко и в кратчайшие сроки ваяемпрограммы.
        Однако - попахивает пионерией...
  • Выбор среды и средств разработки графического приложения?, !*! chip, 11:10 , 13-Июл-05 (3)
    >Понимаю, что написано коряво, но за последнюю неделю спал в сумме не
    >более 24 часов 8( Так что уточняйте, не стесняйтесь! 8)

    <offtopic>

    Время сна обратно-пропорционально продуктивности работы. Вроде даже Linus T. уделял этой проблеме пару строчек в своем "Just For Fun".

    </offtopic>


  • Выбор среды и средств разработки графического приложения?, !*! favourite, 07:06 , 27-Июл-05 (9)
    >Встала задача реализации программы с графическим интерфейсом.
    >По функциональности, что-то вроде программ для банкоматов.
    >То есть стоит выбор какого-то GUI API для написания данной программы.
    >
    >Конечно, можно написать её на том же Delphi/CBuilder, но система должна быть
    >максимально отказоустойчива. А крутить её под потенциально подверженой к сбоям осью,
    >мне стремновато... 8(
    >
    >Что уважаемый алл может предложить/посоветовать?
    Может это тот случай когда подойдет TCL/TK ?



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру