The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"Выбор среды и средств разработки графического приложения?"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Программирование под UNIX (Public)
Изначальное сообщение [Проследить за развитием треда]

"Выбор среды и средств разработки графического приложения?" 
Сообщение от Defender emailИскать по авторуВ закладки(??) on 12-Июл-05, 23:11  (MSK)
Встала задача реализации программы с графическим интерфейсом.
По функциональности, что-то вроде программ для банкоматов.
То есть стоит выбор какого-то GUI API для написания данной программы.

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

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

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

  Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

 Оглавление

Индекс форумов | Темы | Пред. тема | След. тема
Сообщения по теме

1. "Выбор среды и средств разработки графического приложения?" 
Сообщение от Lazarenko emailИскать по авторуВ закладки on 13-Июл-05, 00:32  (MSK)
если ты под на паскале коряво пишеш, то на чем другом ты можеш написать не коряво? :))) Отказоустойчивый гуй - XLib.. кроссплатформенного гуя бесплатного нормального нет. Только QT под Win собраный VC++ есть нормаьный, но денег стоит. Так что если проект серьезный - покупай, если же кросс платформенность не надо - то .NET widgets, иначе - Swing... В чем пробема? Выбор средств всегда самая сложная задача.
А вообще писать надо c MVC (не MFC, а Model-View-Controler)... тогда в случае неудачного выбора GUI его легко можно заменить.
  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

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

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

  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

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

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

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

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

// wbr


  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

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

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

  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

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

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

  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

10. "Выбор среды и средств разработки графического приложения?" 
Сообщение от dimus emailИскать по авторуВ закладки(??) on 27-Июл-05, 08:07  (MSK)

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

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

  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

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

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

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

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

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

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

  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

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

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

// wbr

  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

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

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

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

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

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

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

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

// wbr

  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

5. "Выбор среды и средств разработки графического приложения?" 
Сообщение от Vladislav emailИскать по авторуВ закладки(??) on 15-Июл-05, 22:31  (MSK)
Кросплатформенность не нужна? :) Тогда Kylix... CBuilder - быстро, легко и в кратчайшие сроки ваяемпрограммы.
Однако - попахивает пионерией...
  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

3. "Выбор среды и средств разработки графического приложения?" 
Сообщение от chip emailИскать по авторуВ закладки(ok) on 13-Июл-05, 11:10  (MSK)
>Понимаю, что написано коряво, но за последнюю неделю спал в сумме не
>более 24 часов 8( Так что уточняйте, не стесняйтесь! 8)

<offtopic>

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

</offtopic>


  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

9. "Выбор среды и средств разработки графического приложения?" 
Сообщение от favourite emailИскать по авторуВ закладки(??) on 27-Июл-05, 07:06  (MSK)
>Встала задача реализации программы с графическим интерфейсом.
>По функциональности, что-то вроде программ для банкоматов.
>То есть стоит выбор какого-то GUI API для написания данной программы.
>
>Конечно, можно написать её на том же Delphi/CBuilder, но система должна быть
>максимально отказоустойчива. А крутить её под потенциально подверженой к сбоям осью,
>мне стремновато... 8(
>
>Что уважаемый алл может предложить/посоветовать?
Может это тот случай когда подойдет TCL/TK ?
  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх


Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ]
Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.




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

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