- Выбор среды и средств разработки графического приложения?, 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 ?
|