LINUX.ORG.RU

amLib


0

0

Приглашаются разработчики. amLib - это объектно ориентированная библиотека для программирования в среде XFree86. Текущий статус: начало разработки. Комментарии приветствуются.

>>> Подробности



Проверено:

Зачем?

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

anonymous
()

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

mav
() автор топика

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

vsl
()

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

Druker
()
Ответ на: комментарий от vsl

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

mav
() автор топика

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

saigon
()
Ответ на: комментарий от mav

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

vsl
()
Ответ на: комментарий от mav

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

mav
() автор топика
Ответ на: комментарий от vsl

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

hvv
()

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

mav
() автор топика
Ответ на: комментарий от anonymous

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

hvv
()

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

anonymous
()
Ответ на: комментарий от hvv

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

mav
() автор топика
Ответ на: комментарий от anonymous

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

mav
() автор топика
Ответ на: комментарий от mav

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

hvv
()

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

anonymous
()

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

mav
() автор топика

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

mav
() автор топика

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

mav
() автор топика

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

mav
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.