Зачем?

Мужики - вам чего, делать нечего? У вас есть лишние 3 года жизни чтобы сделать что-то подобное по мощи gtk+themes (я не говорю по Gnome!) - или будет еще одна кастрированная библиотека, которую будут ипользовать только вы... Лучше не тратте времени, а отлизывайте Gnome или KDE или чего-то еще. Или вам лень читать доки и код для Gnome/Gtk? Если хотите поизучать Xlib - изучайте молча, не приманиваю таких же людей как вы, заманивая такими высокими словами как Gnome. В этом кроется одна из проблем freesoftware - пишут студенты для самообразования (в десятый раз изобретая кривой велосипед) - а потом выбрасывают как найдут работу. Стыдно за русских.

Re: amLib

Хмм. Во первых работа у меня есть. Во вторых если это интересно мне то может быть интересно кому-то еще. А вообще-то спасибо за комментарий, интересно и такое мнение. Ну да ладно, пойду-ка писать дальше.

Re: amLib

Блин, ну зачем еще одно ОО-глюкало? Разве до сих пор кому-то непонятно, что ГУЙ должен быть функциональным и rule-based, или это получится Windoze N2?

Re: amLib

Нет, господа, сейчас с Qt и GTK можно надолго забыть, как пишутся библы для GUI. Зачем лишний раз распыляться? Лучше напишите библу для приема-посыла факсов (по модему и по интернет), например. Это дуйствительно полезная штука будет.

Re: Re: amLib

Уважаемый vsl! Посмотрите исходники. ООП в данном случае функционально. На написание объекта "Password" я потратил около 15 минут вместе с отладкой. За основу был взят объект "Entry", у него была переписан всего лишь один метод - show (по привычке я еще называю методы функциями). Представьте сколько времени (и потенциальных ошибок) ушло бы на перепись объекта с нуля. У меня есть опыт в написании подобных библиотек на классическом С. Поверьте, может С++ и не так хорош для всего круга задач, но для интерфейсов он просто не заменим. А оптимальность наследования классов давайте оставим на совести компилятора и его разработчиков. Не уверен, что пытаясь сделать то же самое на классическом С, получил бы более оптимальный результат. Спасибо.

Re: amLib

Дествительно, базовые библиотеки сейчас есть, надо не распыляться, а работать с ними. Если кому не нравится сишный интерфейс gtk+, можно пользоваться с++ надстройками, например gtk-- : http://lazy.ton.tut.fi/terop/iki/gtk/gtk--.html (с++ конечно гораздо применимее для gui) Linux'у щас не хватает полезных прикладушек с гуем, надо их и писать

Re: Re: Re: amLib

Не стоит путать "процедурно" с "функционально". Естественно, C для интерфейсов - никак не подходит. Но и C++ тоже не фонтан, как и другие подобные ООП языки. Получается громоздко и неповоротливо, а так же очень неудобно для изменений и понимания - особенно если сравнивать с _функциональным_ подходом к построению GUI: это Tcl/Tk, всяческие примочки под Scheme (вроде Guile/Gtk), реализации GUI для Common Lisp. И, что самое главное - этот подход хорошо вписывается в Unix Way, в отличии от рисования ГУИ на C++ или Object Pascal, что есть чистейший Windows Way. Ну а если без мудрствования, практически к делу подойти - то у GUI на C++ есть один очевидный и фатальный для unix-like систем недостаток - такие библиотеки не экспортируются в скриптовые языки.

Re: Re: Re: amLib

Совершенно с Вами согласен насчет Unix Way и Windows Way. Таким образом Ваши слова о возможности экспорта в скриптовые языки становятся одним из приоритетных направлений дальнейшей разработки библиотеки. К счастью некоторые наработки уже имеются. Кстати, как Вам нравится консольная программа dialog, на основе которой постороен инсталлятор Slackware? Этот подход мне наиболее близок.

Re: Re: Re: Re: amLib

Про "единственный и фатальный недостаток" - это гон (да, конечно сразу функции ты не экспортируешь, но написав wrapper из одной строки для каждой функции - пожалуйста). Но что unix-way - это писать функциональность на компилируемом языке, а сам gui к софту - на скриптовом языке - согласен. В целом я всеми конечностями одобряю использования C++. Но разработку amlib как таковую - не одобряю (это я написал первое письмо сюда). Пишите/фиксите чего-нибудь другое. Вопрос авторам amlib на засыпку: кто-нибудь из вас разбирался и использовал gtk интенсивно? В курсе про theme engines? А уникод вам слабо будет поддерживать? А портабельность под Win*? Бросайте и фиксите чего-нибудь другое. Лучше потратте время на изучение С++ (шаблоны и STL), Perl, GTK.

Re: amLib

Re: amLib

Портабельность под Win* не предусмотрена. Юникод скорее да чем нет, но не первоочередная задача. Про theme engines не в курсе, но догадываюсь. С gtk разбирался, но интенисвно не использовал. Тест прошел? ж) Тем не менее Ваше неодобрение идет на пользу проекту. Гораздо хуже было бы игнорирование его.

Re: Re: amLib

Про theme-enginies - в действии их можно увидеть на gtk.themes.org (измненение внешенго вида не требует изменения исходного кода). Ну как?

Re: amLib

GTK+ и Gnome действительно редкостная дрянь и требует алтернвтивы.
Но альтернативных GUI итак достаточно
чем не устраивает qt и tcl/tk ?

Re: Re: Re: amLib

Красиво. И возможно удобно. Но съедает слишком много ресурсов. В противовес решению gtk, менять внешний вид приложений amLib может прикладной программист. На примере Button - наследовал свой класс от Button. Переписал метод show. Все:, внешний вид поменялся. Все таки одна из целей проекта - дать возможность прикладному программисту писать быстрые и компактные программы, которые для работы требуют лишь наличие Xlib. По поводу оптимизации: стоял даже вопрос, целесообразно-ли отслеживать движения мыши в меню, поскольку рассматривался даже вариант работы через модем/медленный IP.

Re: Re: amLib

Вы не поверите - меня устраивают и gtk и qt и tcl/tk, все другое что было, есть и будет. Просто хочется продолжить этот ряд. ;) А если серьезно, давайте вернемся к этому вопросу в Январе 2000 - на это время планируется первый релиз. А то что есть сейчас - попытка обрести единомышленников, привлечь народ к разработке библиотеки, а так же выяснить направление в котором дальше предстоит развивать проект. Между прочим помимо предложений "брось это гиблое дело" были и конструктивные предложения по существу, которые уже учлись в новой версии.

Re: Re: Re: Re: amLib

Насчет с[едания системных ресурсов - это зависит от темы. Если устанавливать только цвета (без фоновых pixmaps) да маленькие картиночки типа checkbox - то получается офигительно красивый внешний вид, и не требует доп. ресурсов. Да, по IP это возможно будет тормозить. Но "в противовес решению gtk" очень самхивает на One Microsoft Way. PS: надеюсь ваша либа будет под LGPL. Но мне лично жалко, что еще несколько нормальных мозгов будут заняты какой-то ерундой, а не фиксиньем Open Source soft'a.

Re: amLib

Вашу энергию да в мирных целях... В машинный перевод и OCR, например. А писать еще один ГУИ - зря жизнь прожигать. Не жалко молодость на такое тратить...

Re: amLib

Hi! появилось первое приложение: Xprocess viewer. Все еще очень кривое. Через пару деньков приложение уже можно будеть пользовать. Скриншот можно увидеть на amlib.hotmail.ru

Re: amLib

А давайте еще свою СУБД писать, тожа тема ничего. Если честно, то нормального GUI, с которым, к примеру, бухгалтер может заколотить сотню документов, не отвлекаясь на юзанье мыши, не видел. А что касается С vs C++... Наследование конечно это круто, но когда для изменения алгоритма обработки поля нужно генерить новый, да при этом инициализация в массивах не проходит... Смотреть страшно на листинге. Люблю это как всевозжмоные билдеры интерфейсов.

Re: Re: amLib

Да какие проблемы - пишите. Разве кто-нить запрещает? ;-)

Насчет наследования:
class NewClass::NewClass(char *somepar):OldClass(somepar) {
/*body skiped*/
}
И все проинициализируется. А в новом конструкторе можно че-нить
добавить или убрать.

Re: amLib

Две хорошие новости:
1. Продукт под лицензией GPL
2. Появилась документация, точнее пример программы с подробными комментариями. Простите за стиль комментариев.

Re: amLib

Теперь должно собираться под FreeBSD без напильника.