[linux] выбор GUI библиотеки
qt+qtdesigner+kdevelop, думаю, тебе подойдёт
Да, QT хороши тем, что к ним прилагается нехилый html-мануал с последовательно усложняющимися примерами и т.п.
Вот только сигнально-сокетная система озадачивает
Вот только сигнально-сокетная система озадачивает
qt+qtdesigner+kdevelop
я слышал о такой связке уже не раз и даже собирался приступить к изучению, как вспомнил про GTK
очень интересны сравнительные хар-ки разных библиотек, чтобы понимать свой выбор
и еще очень нужны советы такого плана: с чего начать, что почитать; приветствуются ссылки на разные ресурсы для начинающих (только если кто-то натыкался - я в инете пока не искал, решил сначала узнать мнение окружающих)
сигнально-сокетная система
что это и насколько часто используется?
Один объект (кнопка, например) может генерировать сигнал, который может быть обработан другим объектом, если у того есть т.н. сокет, "настроенный" на этот сигнал.
Эти сокеты настолько хитро там реализованы, что исходники даже сразу откомпилить нельзя - их сначала надо прогонять через qt-шный препроцессор.
Используются постоянно, ибо это основная идея QT.
Эти сокеты настолько хитро там реализованы, что исходники даже сразу откомпилить нельзя - их сначала надо прогонять через qt-шный препроцессор.
Используются постоянно, ибо это основная идея QT.
qtdesigner - разве GPL?.. не уверен.
Мы вот wxWidgets (бывшая wxWindows) юзали, у нее есть большое достоинство - она LGPL.
Т.е. можно писать коммерческий софт и никому ничего не платить
причем, абсолютно законно
Мы вот wxWidgets (бывшая wxWindows) юзали, у нее есть большое достоинство - она LGPL.
Т.е. можно писать коммерческий софт и никому ничего не платить
причем, абсолютно законноwxWidgets (бывшая wxWindows) юзали
расскажи, пожалуйста, как юзали, какой смежный софт юзали, что больше нравится, чем в qt!
спасибо за разъяснения!
интересно, помогает ли дизайнер управляться с этой системой, можно ли править построенное дизайнером вручную и насколько он будет это понимать?
интересно, помогает ли дизайнер управляться с этой системой, можно ли править построенное дизайнером вручную и насколько он будет это понимать?
юзали Мотиф и Иксы. Разница примерно как между MFC и Win32API (если не больше). Только формочки все вручную делали, хотя там вроде и дизайнер есть. Отличие от Qt в условиях лицензии (не надо сотни баксов платить ну и архитектура разная, хотя я с Qt не разбирался.
2 atilla дизайнер -- чистый гпл.
работать в нем вполне комфортно, единственный напряг -- добавлять свои виджеты, что бы пользоваться ими как стандартными. на данный момент это либо плагин писать (что не сложно, но геморно либо делать простое xml описание (но при этом теряется часть функциональности). генерит он простой xml, который легко правиться руками.
ситема сигналов-слотов достаточно продуманна, имхо, очень удачное решение. и вообще иерархия классов в общем сделана грамотно и понятно. есть конечно глюки, например, в работе с сокетами, но это в основном из-за того, что надо поддерживать кросплатформенность. скорость, маленький размер.
очень хорошая документация: стандарный хелп и примеры, идущие с либой покрывают практически все вопросы.
в общем, писал, пишу на куте и альтернативы не вижу
работать в нем вполне комфортно, единственный напряг -- добавлять свои виджеты, что бы пользоваться ими как стандартными. на данный момент это либо плагин писать (что не сложно, но геморно либо делать простое xml описание (но при этом теряется часть функциональности). генерит он простой xml, который легко правиться руками.
ситема сигналов-слотов достаточно продуманна, имхо, очень удачное решение. и вообще иерархия классов в общем сделана грамотно и понятно. есть конечно глюки, например, в работе с сокетами, но это в основном из-за того, что надо поддерживать кросплатформенность. скорость, маленький размер.
очень хорошая документация: стандарный хелп и примеры, идущие с либой покрывают практически все вопросы.
в общем, писал, пишу на куте и альтернативы не вижу
мне вот всегда было интересно, если qt дарит людям такое счастье, то почему gnome использует gtk? Чтобы gtk-шное приложение нормально отображалось (не в gnome надо еще какие-то файлики руками править. Зачем все эти телодвижения, если рядом такое чудо?
Мотиф нарушает большинство из заявленных требований, а именно первое, второе, четвёртое и пятое. А вообще кажется GTK+ постепенно всех вытесняет (по крайней мере из области Open Source) так что имеет смысл использовать его ну или всякие надстройки над ним вроде wxWindows.
QT - тормоз, и Trolltech сами об этом пишут 
если qt дарит людям такое счастье, то почему gnome использует gtk?
мне кажется, что они используют gtk потому, что они изначально на него заложились, а для перехода на другую систему нужно много переделывать и будет много глюков; ну это может быть лишь моим ламерским мнением...
а кто-нибудь программировал на обоих системах? может ли кто-нибудь сравнить их, указать достоинства и недостатки друг перед другом?
и еще вопрос по GTK: есть ли "gtk-designer"?
и просьба обосновать как-нибудь:
и еще вопрос по GTK: есть ли "gtk-designer"?
и просьба обосновать как-нибудь:
GTK+ постепенно всех вытесняет (по крайней мере из области Open Source)
меня удивляет вот что: почему Trolltech так клепает релизы Ot?
это такое бурное развитие или это говорит о недостатках Qt?
есть ли у них стабильная поддержка предыдущих версий в новых?
сильно ли отличается qt-2 от qt-3 и как у них с такой поддержкой? (т.е. пришлось ли переделывать код qt-2 --> qt-3?)
это такое бурное развитие или это говорит о недостатках Qt?
есть ли у них стабильная поддержка предыдущих версий в новых?
сильно ли отличается qt-2 от qt-3 и как у них с такой поддержкой? (т.е. пришлось ли переделывать код qt-2 --> qt-3?)
мне кажется, что они используют gtk потому, что они изначально на него заложилисьА мне кажется, что они используют GTK потому, что это их собственная разработка. А Qt --- это вообще коммерческий продукт, и строить главную GNU-сную оболочку поверх коммерческой библиотеки было бы странно (даже если Qt-шная лицензия это позволяет).
Ну доля Open Source продуктов, использующих Gtk постоянно растёт. Продукты из семейства KDE не в счёт. Они изначально заложились на Qt и на этом погорели, так как новые версии Qt чисто платные, а старые хоть и остаются бесплатными, но практически не развиваются, и лицензия не позволяет развивать их своими силами.
2 потому что когда зачинались гном и кде (это более мение одно время куте не публиковалась под гпл, ее лицензия была qpl -- гномовцам это не понравилось.
2 ссылку. вообще это пиздешь, куте работает очень шустро. запусткаются проги медленней гткашных, но это проблема не лтбы а линковщика.
гтк дизайнер есть, называется глэйд.
2 не замечал, что часто.
2 последнихбагфикс релиза куте: 27.04 и 01.03, два последник багфикс релиза гтк: 30.04 и 16.03.
а между большими (не багфикс) -- около 6-8 месяцев
при переходе с qt2 на qt3 код переделывать кое где придется, но не сильно много. как правило, они изменения вност постепенно, оставляют обсолете и депрекатед функции на несколько релизов, и только потом их убирают. и вообще, смотри доку, там это разжевано
2 ссылку. вообще это пиздешь, куте работает очень шустро. запусткаются проги медленней гткашных, но это проблема не лтбы а линковщика.
гтк дизайнер есть, называется глэйд.
2 не замечал, что часто.
2 последнихбагфикс релиза куте: 27.04 и 01.03, два последник багфикс релиза гтк: 30.04 и 16.03.
а между большими (не багфикс) -- около 6-8 месяцев
при переходе с qt2 на qt3 код переделывать кое где придется, но не сильно много. как правило, они изменения вност постепенно, оставляют обсолете и депрекатед функции на несколько релизов, и только потом их убирают. и вообще, смотри доку, там это разжевано
ткни пальцем в куте, которую нельзя юзать под гпл нод никсами?
а под винду тролли вполне могут подарить лицензию под хорошее дело, напр. sim.
а под винду тролли вполне могут подарить лицензию под хорошее дело, напр. sim.
Из их доков (у меня поставились вместе с QT)
/usr/X11R6/share/doc/qt/html/signalsandslots.html
/usr/X11R6/share/doc/qt/html/signalsandslots.html
The signals and slots mechanism is efficient, but not quite as fast as "real" callbacks. Signals and slots are slightly slower because of the increased flexibility they provide, although the difference for real applications is insignificant. In general, emitting a signal that is connected to some slots, is approximately ten times slower than calling the receivers directly, with non-virtual function calls. This is the overhead required to locate the connection object, to safely iterate over all connections (i.e. checking that subsequent receivers have not been destroyed during the emission) and to marshall any parameters in a generic fashion. While ten non-virtual function calls may sound like a lot, it's much less overhead than any 'new' or 'delete' operation, for example. As soon as you perform a string, vector or list operation that behind the scene requires 'new' or 'delete', the signals and slots overhead is only responsible for a very small proportion of the complete function call costs. The same is true whenever you do a system call in a slot; or indirectly call more than ten functions. On an i586-500, you can emit around 2,000,000 signals per second connected to one receiver, or around 1,200,000 per second connected to two receivers. The simplicity and flexibility of the signals and slots mechanism is well worth the overhead, which your users won't even notice.
а ты сумеешьс такой скоростью на мышку жать?
обработка сигналов занимает горазде меньшее время, чем, например, отрисовка виджетов, я как-то гонял под валгриндом -- передача сигналов копейки весит
обработка сигналов занимает горазде меньшее время, чем, например, отрисовка виджетов, я как-то гонял под валгриндом -- передача сигналов копейки весит
Неужели сигналы в QT эмитируются только по нажатию мышки? 
Не нравится мне аргументация в стиле "всё равно вы этого не заметите".
Не нравится мне аргументация в стиле "всё равно вы этого не заметите".
конечно нет, не только мышкой эмитятся.
имхо, относиться к этому нужно так: можно в каком-то месте пожертвовать производительностью ради удобства пользователя (т.е. того, кто под куте пишет если общее падение производительности будет несущественно.
имхо, относиться к этому нужно так: можно в каком-то месте пожертвовать производительностью ради удобства пользователя (т.е. того, кто под куте пишет если общее падение производительности будет несущественно.
А мне в QT не понравилось, что они предлагают расширение синтаксиса языка для реализации этих сигналов. Может это и удобно в некотором смысле, но как-то неправильно (IMHO).
где там расширения языка?
хинт: мок-компилер не меняет файлов, написанных тобой. если там есть что-то нестандартное, то как же это компилиться?
все типа "расширения" -- это макросы и не более того.
хинт: мок-компилер не меняет файлов, написанных тобой. если там есть что-то нестандартное, то как же это компилиться?
все типа "расширения" -- это макросы и не более того.
а ты сумеешьс такой скоростью на мышку жать?То есть так: "хрен с ним с race condition, все равно никогда не догонит"?
обработка сигналов занимает горазде меньшее время, чем, например, отрисовка виджетов, я как-то гонял под валгриндом -- передача сигналов копейки весит
а в каком месте там race condition?
P.S. и вообще что-то много пурги в этом треде, может разберёшься, как модератор?
P.S. и вообще что-то много пурги в этом треде, может разберёшься, как модератор?
Да, походу они не о тех сигналах говорят, что я подумал. Стало быть про race condition я не в тему сказал
Да, это скорее в тему треда про ФП.
Не хватило троллям возможностей C++, пришлось самим препроцессор придумывать
Не хватило троллям возможностей C++, пришлось самим препроцессор придумывать
The moc reads C++ source files. If it finds one or more class declarations that contain the "Q_OBJECT" macro, it produces another C++ source file which contains the meta object code for te classes. ...
Нам нужно использовать внешний препроцессор, а так же это привязка к одному языку.
но все их "ключевые" слова -- это сишные макросы и не более. мок -- опциональна штука, для тех, кто не хочет писать кучу похожего кода руками.
на счет привязки к одному языку я не понял, что ты имел в виду.
PyQT? или что?
на счет привязки к одному языку я не понял, что ты имел в виду.
PyQT? или что?
надстройки над ним вроде wxWindows
а WX существует в куче кариантах, и как надстройка над Win32 и как надстройка над Motif, и X11, и Gtk и вроде уже над .NET...
А зачем же тогда нужен moc, если это всего-лишь макросы, почему нельзя использовать cpp?
Про Python не знал, а ещё для чего-нибудь его портировали? Кроме как в PyQT обстоит дело с отставанием от последних версий QT или там это не имеет значения?
вроде уже про версию 4 слышал, мол там все быстрее и компактнее.
о! еще http://wxpython.org/ 
Все равно нет какого ключевого слова в c++ как signal. А moc это и есть расширение языка. Например в MFC все через макросы, все в рамках C++. Хотя мне понравилась идея что в Qt. Но свои сигналы могли бы получше реализовать, хотя бы как делегаты в .net. И вообще могли бы и дальше с moc пойти.
дык можно, только зачем каждый раз писать код, который может быть легко сгенерен?
есть вроде еще биндинги для перла и сишарпа.
есть вроде еще биндинги для перла и сишарпа.
всем спасибо
Почему каждый раз писать код? Если ты говоришь, что это можно сделать макросами, то почему так и не сделали? Для пользователя библиотеки ведь ничего не поменялось бы, но вот необходимось в moc отпала бы.
Why doesn't Qt use templates for signals and slots?
A simple answer is that when Qt was designed, it was not possible to fully exploit the template mechanism in multi-platform applications due to the inadequacies of various compilers. Even today, many widely used C++ compilers have problems with advanced templates. For example, you cannot safely rely on partial template instantiation, which is essential for some non-trivial problem domains. Thus Qt's usage of templates has to be rather conservative. Keep in mind that Qt is a multi-platform toolkit, and progress on the Linux/g++ platform does not necessarily improve the situation elsewhere.
Eventually te compilers with weak template implementations will improve. But even if all our users had access to a fully standards compliant modern C++ compiler with excellent template support, we would not abandon the string-based approach used by our meta object compiler. Here are five reasons why:
1. Syntax matters
Syntax isn't just sugar: the syntax we use to express our algorithms can significantly affect the readability and maintainability of our code. The syntax used for Qt's signals and slots has proved very successful in practice. The syntax is intuitive, simple to use and easy to read. People learning Qt find the syntax helps them understand and utilize the signals and slots concept -- despite its highly abstract and generic nature. Furthermore, declaring signals in class definitions ensures that the signals are protected in the sense of protected C++ member functions. This helps programmers get their design right from the very beginning, without even having to think about design patterns.
2. Precompilers are good
Qt's moc (Meta Object Compiler) provides a clean way to go beyond the compiled language's facilities. It does so by generating additional C++ code which can be compiled by any standard C++ compiler. The moc reads C++ source files. If it finds one or more class declarations that contain the "Q_OBJECT" macro, it produces another C++ source file which contains the meta object code for te classes. The C++ source file generated by the moc must be compiled and linked with the implementation of the class (or it can be #included into the class's source file). Typically moc is not called manually, but automatically by the build system, so it requires no additional effort by the programmer.
There are other precompilers, for example, rpc and idl, that enable programs or objects to communicate over process or machine boundaries. The alternatives to precompilers are hacked compilers, proprietary languages or graphical programming tools with dialogs or wizards that generate obscure code. Rather than locking our customers into a proprietary C++ compiler or into a particular Integrated Development Environment, we enable them to use whatever tools they prefer. Instead of forcing programmers to add generated code into source repositories, we encourage them to add our tools to their build system: cleaner, safer and more in the spirit of UNIX.
3. Flexibility is king
C++ is a standarized, powerful and elaborate general-purpose language. It's the only language that is exploited on such a wide range of software projects, spanning every kind of application from entire operating systems, database servers and high end graphics applications to common desktop applications. One of the keys to C++'s success is its scalable language design that focuses on maximum performance and minimal memory consumption whilst still maintaining ANSI-C compatibility.
For all these advantages, there are some downsides. For C++, the static object model is a clear disadvantage over the dynamic messaging approach of Objective C when it comes to component-based graphical user interface programming. What's good for a high end database server or an operating system isn't necessarily the right design choice for a GUI frontend. With moc, we have turned this disadvantage into an advantage, and added the flexibility required to meet the challenge of safe and efficient graphical user interface programming.
Our approach goes far beyond anything you can do with templates. For example, we can have object properties. And we can have overloaded signals and slots, which feels natural when programming in a language where overloads are a key concept. Our signals add zero bytes to the size of a class instance, which means we can add new signals without breaking binary compatibility. Because we do not rely on excessive inlining as done with templates, we can keep the code size smaller. Adding new connections just expands to a simple function call rather than a complex template function.
Another benefit is that we can explore an object's signals and slots at runtime. We can establish connections using type-safe call-by-name, without having to know the exact types of the objects we are connecting. This is impossible with a template based solution. This kind of runtime introspection opens up new possibilities, for example GUIs that are generated and connected from Qt Designer's XML ui files.
4. Calling performance is not everything
Qt's signals and slots implementation is not as fast as a template-based solution. While emitting a signal is approximately the cost of four ordinary function calls with common template implementations, Qt requires effort comparable to about ten function calls. This is not surprising since the Qt mechanism includes a generic marshaller, introspection and ultimately scriptability. It does not rely on excessive inlining and code expansion and it provides unmatched runtime safety. Qt's iterators are safe while te of faster template-based systems are not. Even during the process of emitting a signal to several receivers, te receivers can be deleted safely without your program crashing. Without this safety, your application would eventually crash with a difficult to debug free'd memory read or write error.
Nonetheless, couldn't a template-based solution improve the performance of an application using signals and slots? While it is true that Qt adds a small overhead to the cost of calling a slot through a signal, the cost of the call is only a small proportion of the entire cost of a slot. Benchmarking against Qt's signals and slots system is typically done with empty slots. As soon as you do anything useful in your slots, for example a few simple string operations, the calling overhead becomes negligible. Qt's system is so optimized that anything that requires operator new or delete (for example, string operations or inserting/removing something from a template container) is significantly more expensive than emitting a signal.
Aside: If you have a signals and slots connection in a tight inner loop of a performance critical task and you identify this connection as the bottleneck, think about using the standard listener-interface pattern rather than signals and slots. In cases where this occurs, you probably only require a 1:1
> its highly abstract and generic nature
сигнал - это всего лишь итерация по списку функций
вот функция, список и итерация - действительно абстрактные понятия,
с которыми C++ не очень хорошо умеет/умел работать
> Precompilers are good
... но не очень
основная проблема препроцессоров - если компилятор заметит ошибку,
то он выдаст её относительно сгенерированного кода, и человеку
придётся гадать, зачем препроцессор такой код сгенерировал
(проводить депрепроцессирование вручную)
сигнал - это всего лишь итерация по списку функций
вот функция, список и итерация - действительно абстрактные понятия,
с которыми C++ не очень хорошо умеет/умел работать
> Precompilers are good
... но не очень
основная проблема препроцессоров - если компилятор заметит ошибку,
то он выдаст её относительно сгенерированного кода, и человеку
придётся гадать, зачем препроцессор такой код сгенерировал
(проводить депрепроцессирование вручную)
основная проблема препроцессоров - если компилятор заметит ошибку,
то он выдаст её относительно сгенерированного кода, и человеку
придётся гадать, зачем препроцессор такой код сгенерировал
(проводить депрепроцессирование вручную)
во! точно!
этого не хотелось бы делать!
может быть считается, что программер должен понимать, что этот мок должен написать (и программер, если захочет, может написать то же без мок) - тогда не очень велика проблема
все же, наверное, мок достаточно сложен... (?)
2 , : qt предлагает какие-нибудь методы для борьбы с этим?
>основная проблема препроцессоров - если компилятор заметит
>ошибку,
>то он выдаст её относительно сгенерированного кода, и человеку
>придётся гадать, зачем препроцессор такой код сгенерировал
>(проводить депрепроцессирование вручную)
В теории да, на практике с мок такого не происходит: мок генерит тривиальный довесок к твоему коду и либо он сам ругается относительно твоего кода, когда не рюхает, что к чему, либо генерит правильный код. плюс твой и сгенеренный код физически разделены. за 2 года я ни разу не встречал, чтобы сгенеренный мок был ошибочен.
>ошибку,
>то он выдаст её относительно сгенерированного кода, и человеку
>придётся гадать, зачем препроцессор такой код сгенерировал
>(проводить депрепроцессирование вручную)
В теории да, на практике с мок такого не происходит: мок генерит тривиальный довесок к твоему коду и либо он сам ругается относительно твоего кода, когда не рюхает, что к чему, либо генерит правильный код. плюс твой и сгенеренный код физически разделены. за 2 года я ни разу не встречал, чтобы сгенеренный мок был ошибочен.
как происходит сборка: пусть есть youfile.h,youfile.cpp
порядок:
1) moc -o moc_youfile.cpp youfile.h
2) g++ -c youfile.cpp
3) g++ -c moc_youfile.moc
4) g++ youfile.o moc_youfile.o
если ты приведешь код, для которого 1-2 пройдут, а на 3 будет ошибка -- с меня пиво.
порядок:
1) moc -o moc_youfile.cpp youfile.h
2) g++ -c youfile.cpp
3) g++ -c moc_youfile.moc
4) g++ youfile.o moc_youfile.o
если ты приведешь код, для которого 1-2 пройдут, а на 3 будет ошибка -- с меня пиво.
за 2 года я ни разу не встречал, чтобы сгенеренный мок был ошибочен.
это положительно, а много ли ты программируешь?
скажи, а у тебя есть какие-нибудь личные опен-сорс-продукты, на которые можно поглазеть?
основная проблема препроцессоров - если компилятор заметит ошибку,Вовсе не вручную. Но ломать глаза на том, что генерит cpp конечно тяжелее, чем на человеческом коде (как раз этим сегодня занимался).
то он выдаст её относительно сгенерированного кода, и человеку
придётся гадать, зачем препроцессор такой код сгенерировал
(проводить депрепроцессирование вручную)
Не знаю как в других компиляторах, а VC++7.0 появилась директива, не помню точно, #line <line>, когда можно заставить компилятор считать, что сгенерированный код как бы лежит в строке с задыным номером. В 7ке для ATL появилось расширение языка с помощью атрибутов, которые предпроцессором превращаются в C++ код, в котором насованы эти директивы и поэтому со сроками в сообющениях об ошибках все ОК.
основная проблема препроцессоров - если компилятор заметит ошибку,
то он выдаст её относительно сгенерированного кода, и человеку
придётся гадать, зачем препроцессор такой код сгенерировал
(проводить депрепроцессирование вручную)
а ты когда-нить писал мудреные проги с помощью шаблонов?.. Вот уж где сообщения об ошибках замысловатые.
Типа ошибка в функции A<T1, T2, T3> B<T4, T1, T2>::F(T1, T2, T3, T4) with T1=C<int, float, std::string>, T2= ....
Instantiated from: .... и дальше еще примерно такое же чудо
а потом еще и еще. А все из-за того что где-то забыл привести float к double. qt приятная и легкая, особенно третья - в qt дезигнере писать легко, но неудобно, видгеты добавлять оченьпросто(кто не умеет без всяких иксмлей просто - я научу)
я писал на 3-ей qt, потом написал скрипт на perl, который прообразовывал в qt2.x - ибо она бешплатная для свободного пользования под винду.
теперь пишу под wxWindow
только у меня изначально задача другая была - кроссплатформеное приложене
а так - есть еще такая библиотека fox - тудаже
но когда выйдет Gtk 2.6 - буду под него писать ввиду поддержки directFB
вообще самая приятная обьекная модель в кутэ, имхо
// Fortl
я писал на 3-ей qt, потом написал скрипт на perl, который прообразовывал в qt2.x - ибо она бешплатная для свободного пользования под винду.
теперь пишу под wxWindow
только у меня изначально задача другая была - кроссплатформеное приложене
а так - есть еще такая библиотека fox - тудаже
но когда выйдет Gtk 2.6 - буду под него писать ввиду поддержки directFB
вообще самая приятная обьекная модель в кутэ, имхо
// Fortl
qt2.x - ибо она бешплатная для свободного пользования под винду
она бесплатная для бесплатных проектов или и для коммерческих?
вроде только для некомерческих - смотри у троллей на сайте
вот и я про что. У Qt лиценция GPL, а у wxWidgets - LGPL.
ну и что?
если я систему продавать не собираюсь, то не легче ли взять простую обьектную модель...
(хотя WX вс равно нормальная штука )
если я систему продавать не собираюсь, то не легче ли взять простую обьектную модель...
(хотя WX вс равно нормальная штука
)если я систему продавать не собираюсь
тогда у тебя богаче выбор
вообще самая приятная обьекная модель в кутэ, имхо
Согласен. Ну где еще можно на лету создать кнопку на форме и привязать к ней обработчик двумя операторами?
А вообще, есть смысл задуматься о платформе .NET.
Под *NIX УЖЕ есть аж две OpenSource реализации - Mono и Portable.NET. Не знаю, как Mono, а вот Portable.NET работает вполне сносно. Я скачивал тестовую прогу с их сайта, собирал во фре, а потом гонял exe-шник под виндой
Вот уж поистине кроссплатформенность..Единственно, что мне не очень понравилась их библиотека Windows.Forms. Раздражает отсутствие нормальный Layout-ов. А так ничего.
Ну где еще можно на лету создать кнопку на форме и привязать к ней обработчик двумя операторами?
в wxWindows, например
мб тормознутая Java лучше?
я на на нее забил первый раз, когда в 1998 году на 486 у меня апплет HELLow world копилировался в байт код несколько минут
потом не сложилось. зато кроссплатформеная.
по поводу qt vs wxWindow
1. qt работает на урезаных системах(ПДАшки вские типа Зауруса)
2. обьектная модель приятней (так думают многоие, но не большинство)
3. под wx нет нормальной визуальной среды разработки - не критично для не очень больших приложений, где юзабельность не критична
4. под кутэ есть куча прикольных и нужных видгетов, и вообще пока кутэ хорошо развита
5. я вот посмотрел qt roadmap, наметки на qt4, мне политика развития не очень нравится
6. кутэ прекопилируемая - это не очень хорошо, но приходится мириться
7 wx - LGPL, у троллей своя лицензия и GPL
// Fortl
я на на нее забил первый раз, когда в 1998 году на 486 у меня апплет HELLow world копилировался в байт код несколько минут
потом не сложилось. зато кроссплатформеная.
по поводу qt vs wxWindow
1. qt работает на урезаных системах(ПДАшки вские типа Зауруса)
2. обьектная модель приятней (так думают многоие, но не большинство)
3. под wx нет нормальной визуальной среды разработки - не критично для не очень больших приложений, где юзабельность не критична
4. под кутэ есть куча прикольных и нужных видгетов, и вообще пока кутэ хорошо развита
5. я вот посмотрел qt roadmap, наметки на qt4, мне политика развития не очень нравится
6. кутэ прекопилируемая - это не очень хорошо, но приходится мириться
7 wx - LGPL, у троллей своя лицензия и GPL
// Fortl
3. В общем, для wx оно не особо-то надо. Вообще, в чем-то похоже на .NET: все делается обычными вызовами, например, в конструкторе формы. Только в отличие от .NET есть такая вещь как sizer'ы, что делает размещение контролов "ручками" не сложнее чем вручную html писать.
8. В wx сделать кнопочку и прицепить обработчик "на лету" - в один оператор, а в Qt - в два. Вот пример:
8. В wx сделать кнопочку и прицепить обработчик "на лету" - в один оператор, а в Qt - в два.
Вот пример:
(new wxButton(&form, 1000, "Кнопарь" form.Connect(1000, wxEVT_COMMAND_BUTTON_CLICKED, (wxObjectEventFunction) MyForm::OnKnopar);
ты еще до комманд ассемблера разложи, и то как они в конвеер укладываются...
//fortl
//fortl
(new wxButton(&form, 1000, "Кнопарь" form.Connect(1000, wxEVT_COMMAND_BUTTON_CLICKED, (wxObjectEventFunction) MyForm::OnKnopar);
Так не считается
Это "хакерский" код, который писать не рекомендуется, ибо трудно читабелен.
Я уже запутался в это треде. Тот, кто разобрался, просто перечислите мне, какие библиотеки я могу использовать в closed-source проекте и с какими оговорками. Спасибо.
wxwidgets можешь использовать спокойно, не платя ни копейки. Либа кроссплатформенная: прогать можно и под винду (не хуже чем MFC, а в чем-то и лучше) и под *nix (будет работать поверх Gtk, X11 или Motif)
Кстати, wxWindows - не продукция ли Wind River System? А то у них есть ОС wxWorks...
вроде нет.
qt - если не хочешь замарачиваться а интерфейсе, ибо есть среда разработки + еще всякие радости - читайте анонс по 3.2.х
тогда уж надо про все нюансы говорить
http://www.trolltech.com/products/qt/licensing.html?cid=4
http://www.trolltech.com/products/qt/pricing.html?cid=4
Для тех у кого нет инета: при коммерческом использовании лицензия на одного разработчика - $1550 - professional/$2490 - enterprise за одну платформу, $3320/$4990 - за три.
http://www.trolltech.com/products/qt/licensing.html?cid=4
http://www.trolltech.com/products/qt/pricing.html?cid=4
Для тех у кого нет инета: при коммерческом использовании лицензия на одного разработчика - $1550 - professional/$2490 - enterprise за одну платформу, $3320/$4990 - за три.
для тех у кого нет и нета, но есть голова -
qt-x11 qt-ebbeded
идут по gpl
а то, что она есть платная - так поддержка и разработка хорошая
(нормальные проги стоит писать под нормальные операционные системы, ну есть cygwin)
а в остальном я согласен с аттилой(преподаватель всегда прав, ) хотя все мысли сходятся к лицензии и продаже, а commertional soft не рулит
qt-x11 qt-ebbeded
идут по gpl
а то, что она есть платная - так поддержка и разработка хорошая
(нормальные проги стоит писать под нормальные операционные системы, ну есть cygwin)
а в остальном я согласен с аттилой(преподаватель всегда прав,
) хотя все мысли сходятся к лицензии и продаже, а commertional soft не рулит qt-x11 qt-ebbeded
идут по gpl
GPL позволяет писать close-source программы?..
не верю и вообще, см. сабжнормальные операционные системы, ну есть cygwin
это шутка?..
преподаватель всегда прав
кто знает, в каком кабинете завтра зачет?
а commertional soft не рулит
Зато только он приносит деньги
GPL позволяет писать close-source программы?.. не верю и вообще, см. сабж
я же говорю, что платный софт не очень люблю... надо еще уточнить что именно вообще надо делать чуваку
это шутка?..
нет, намек
кто знает, в каком кабинете завтра зачет?
в том же
Зато только он приносит деньги
солидарен, ибо чувствую по роду деятельности
зато хорошее знание open source может приносить тоже немалые деньги
> GPL позволяет писать close-source программы?..
Можешь продолжать не верить, позволяет.
Читай отцов ГПЛ.
"УК и _комментарии_к_нему_."
---
...Я работаю антинаучным аферистом...
Можешь продолжать не верить, позволяет.
Читай отцов ГПЛ.
"УК и _комментарии_к_нему_."
---
...Я работаю антинаучным аферистом...
GPL позволяет писать close-source программы?.. не верю и вообще, см. сабж
Если ничего не путаю, то ты обязан открывать исходники производных версий. Если ты пишешь программу которая использует немодифицированную вресию GPL библиотеки, то эта программа не является производной версией, и ты волен делать с ней все что хочешь.
Если ничего не путаю, то ты обязан открывать исходники производных версий. Если ты пишешь программу которая использует немодифицированную вресию GPL библиотеки, то эта программа не является производной версией, и ты волен делать с ней все что хочешь.Лев, плс, найди ссылку на это утверждение. Я понять не могу, можно ли писать программу под BSD лицензией, если линкуешь её на libreadline.
AFAIK, по мнению FSF - можно, но результат будет фактически под GPL,
но твой код любой может встроить в BSD-проект, если отрежет readline.
Это именно потому, что FSF рассматривает такое использование readline
как создание derived work.
но твой код любой может встроить в BSD-проект, если отрежет readline.
Это именно потому, что FSF рассматривает такое использование readline
как создание derived work.
Почему FreeBSD, NetBSD, OpenBSD поставляются с gcc и с libreadline?
Лев, плс, найди ссылку на это утверждение
Готовую ссылку не нашел, поэтому давай читать GPL 2.0 вместе.
Итак, во-первых, в самом начале написано:
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope.
То есть теперь достаточно убедиться, что написание программы, использующей данную библиотеку не является modification.
Секция 2, читаем:
If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to te sections when you distribute them as separate works.
То есть, если достаточно очевидно, что твоя программа является не производным от readline, а самостоятельным кодом, то эта лицензия (GPL) никаких ограничений не накладывает. Но однако, если ты собираешься распростронять readline вместе с твоим кодом, до эта лицензия будет относиться к результату:
But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, we permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Другие секции к тебе не относятся, т.к. ты не хочешь распространять [u]свой[/u] код под GPL, а то что твоя программа не является производной мы уже доказали.
Иными словами, краткое резюме:
Если ты в дистрибутив своей программы вставляешь ссылку "собирать с GNU ReadLine", то ты ее можешь распростронять под любой лицензией. Если ты в дистрибутив своей программы включаешь исходники readline, или хотя бы их часть, то распростронять только по GPL.
Это именно потому, что FSF рассматривает такое использование readline
как создание derived work.
Ты не прав. Читай источники.
> can be reasonably considered independent and separate works in themselves
вот это можно трактовать по-разному
в спорных случаях будет решать суд, естественно
аргумент такой: если программа не работает без этой библиотеки, то есть
без readline её собрать нельзя, то её нельзя считать самостоятельной работой
однако если есть другие реализации API readline (я не знаю, так ли это то тогда уже
видно, что программа просто использует более-менее стандартное API,
и независима от какой-либо из реализаций, следовательно, самостоятельна
если можно отцепить readline (с потерей части функциональности) - то хз
но вообще, такие рассуждения отражают только пожелания сторон,
а в случае реальных споров решать будет, повторяю, суд (если стороны сами не смогут договориться)
вот это можно трактовать по-разному
в спорных случаях будет решать суд, естественно
аргумент такой: если программа не работает без этой библиотеки, то есть
без readline её собрать нельзя, то её нельзя считать самостоятельной работой
однако если есть другие реализации API readline (я не знаю, так ли это то тогда уже
видно, что программа просто использует более-менее стандартное API,
и независима от какой-либо из реализаций, следовательно, самостоятельна
если можно отцепить readline (с потерей части функциональности) - то хз
но вообще, такие рассуждения отражают только пожелания сторон,
а в случае реальных споров решать будет, повторяю, суд (если стороны сами не смогут договориться)
аргумент такой: если программа не работает без этой библиотеки, то есть без readline её собрать нельзя, то её нельзя считать самостоятельной работой
Ты не прав, аргумент не подходит. Ты оторвал начало предложения, и это очень сильно изменило смысл. Читаем внимательно: If identifiable sections of that work are not derived from the Program... Ну а дальше уже про независимость. То есть еще раз: нужна не независимость в плане "может работать без", а независимость в плане "независимая разработка, не использует родителя в качестве базы, не основана на коде родителя".
в спорных случаях будет решать суд, естественноГПЛщики все пугают судом, а суда пока ни разу не было.
аргумент такой: если программа не работает без этой библиотеки, то естьНу это немного абсурд. Программа еще бесполезна без компилятора, не работает без libc и ОС под которой она работает и системными вызовами которой пользуется. Однако это не мешает Oraclу быть платным и продаваться под Linux.
без readline её собрать нельзя, то её нельзя считать самостоятельной работой
> ГПЛщики все пугают судом, а суда пока ни разу не было.
Надеюсь, ты не считаешь, что я хочу тебя запугать.
Да, обычно договариваются мирно.
> Однако это не мешает Oraclу быть платным и продаваться под Linux.
Oracle можно собрать другим компилятором, слинковать с другими библиотеками, и запустить под другой ОС.
Это - использование стандартных библиотек.
Вот цитата из Столлмана:
Как видим, он явно считает (точнее, тогда считал что использование readline накладывает ограничения,
связанные с GPL.
Надеюсь, ты не считаешь, что я хочу тебя запугать.
Да, обычно договариваются мирно.
> Однако это не мешает Oraclу быть платным и продаваться под Linux.
Oracle можно собрать другим компилятором, слинковать с другими библиотеками, и запустить под другой ОС.
Это - использование стандартных библиотек.
Вот цитата из Столлмана:
However, when a library provides a significant unique capability, like GNU Readline, that's a horse of a different color. The Readline library implements input editing and history for interactive programs, and that's a facility not generally available elsewhere. Releasing it under the GPL and limiting its use to free programs gives our community a real boost. At least one application program is free software today specifically because that was necessary for using Readline.Источник: http://linuxtoday.com/news_story.php3?ltsn=1999-02-01-004-05-OP
Как видим, он явно считает (точнее, тогда считал что использование readline накладывает ограничения,
связанные с GPL.
Бред какой-то. Предположим, я пишу софт, который может опционально использовать libreadline и libeditline. Чисто для того, что бы сказать - libreadline опционально, поэтому ГПЛщики идут в сад. На самом деле функциональность libeditline ниже, и она глючна. Все понимают, что это просто отмазка, что все будут юзать только libreadline.
Oracle можно собрать другим компилятором, слинковать с другими библиотеками, и запустить под другой ОС. Это - использование стандартных библиотек.
"Продукт XXX можно собрать другим компилятором, слинковать с другими библиотеками, и запустить под другой ОС. Если не будет хватать функциональности gpl библиотеки yyy, то ее можно написать самому с нуля."
Совершенно справедливое утверждение. Именно оно и показывает, в чем разница между derived work (которую невозможно отделить) и independent work.
> Все понимают, что это просто отмазка, что все будут юзать только libreadline.
Насколько я понял позицию FSF, такой отмазки достаточно.
Насколько я понял позицию FSF, такой отмазки достаточно.
Пожалуйста, не надо меня убеждать, что Столлман неправ, мне это не очень интересно.
Я всего лишь указываю на его позицию.
Я всего лишь указываю на его позицию.
Пожалуйста, не надо меня убеждать, что Столлман неправ, мне это не очень интересно.Не надо мне доказывать, что в Библии неправда?
NP!
Дяденька, Вы с кем сейчас разговариваете?
ГПЛщики все пугают судом, а суда пока ни разу не было.
Был. Если не ошибаюсь, разработчик netfilter подал в суд на какого-то производителя
файерволов (или маршрутизаторов хз который пользовался нетфильтром и не поставлял
исходников и не ссылался на GPL. Дело он выиграл.
Был. Если не ошибаюсь, разработчик netfilter подал в суд на какого-то производителяЧисто как модератор, попрошу такие вещи сопровождать ссылками.
файерволов (или маршрутизаторов хз который пользовался нетфильтром и не поставлял
исходников и не ссылался на GPL. Дело он выиграл.
дело даже не в судах (и в том, реально там выиграть или нет а в том что заказчика вряд ли удастся убедить, что суд он выиграет... Просто не захочет с этим связываться и все.
Оставить комментарий
a10063
может, не совсем корректно выразился...хочется научиться писать проги с gui под линухом, аля приложения от C++ Builder & VC
два вопроса: на какие guilibs ориентироваться и с чего начать?
выбор не прост, так как есть ряд пожеланий к библиотеке (тулкиту которые важны в большей или меньшей степени (еще не определился):
1. Open Source + GPL.
2. Распространенная.
3. Хорошо документированная.
4. Легкая для освоения.
5. Развивающая (не хотелось бы, чтоб она через пару лет умерла).
6. Имеется Gui / IDE для разработки.
Посоветуйте мне что-нибудь по этим вопросам.
Заранее благодарю.
P.S. К текущему моменту слышал о GTK, Qt. Имею о них лишь слабое понятие на уровне пользователя.