Re: web-frontend к ftp с поиском
On Sat, 2 Jun 2001, Vlad Harchev wrote: Напишу. Используя Gtk, Fltk, Qt или wxWindows. Хотя на мой взгляд из них всех Tk по-прежнему самый переносимый и удобный. Ни на одном из них ты не напишешь GUI одновременно для Win32, X11, MacOS, BeOS, OS/2, и QNX. Напишешь. Более того, если мы начинаем говорить о портабельности, то *BSD актуальнее чем BeOS, OS/2 и QNX вместе взятые. AWT со всеми упомянутыми даже рядом не стоял. Возможно, но он портабельнее. Иногда это намного важнее. Увы, нет. По моему личному опыту Java менее портабельна чем любой скриптовый язык. Вот-вот, если бы при этом все они пользовались одинаковой DTD, и одинаково реализовывали то, что в DTD не влазит (собственно код приложения) - проблем бы не было. А лицензия конкретной мозилловской реализации не важна, потому что Reference implementation всегда ублюдочна и для практической работы малопригодна. Посмотри хотя бы на фраунгоферовский MP3 кодер. Ну, MP3 кодеры - это уже наука. А виджетсеты - нет - и посему ничего особо ублюдочного (кроме архитектуры) там быть не может - они либо работают, либо Большая часть существующих GUI ублюдочна именно потому что никто не рассматривает их дизайн как науку. А это куда более сложная наука (поскольку включает в себя психологию), чем алгоритмы упаковки звука, которые чистая физика плюс немного физиологии.
Re: web-frontend к ftp с поиском
On Sun, Jun 03, 2001 at 12:27:28PM +0400, Victor B. Wagner wrote: Большая часть существующих GUI ублюдочна именно потому что никто не рассматривает их дизайн как науку. А это куда более сложная наука (поскольку включает в себя психологию), чем алгоритмы упаковки звука, которые чистая физика плюс немного физиологии. Ваяние GUI и психология вообще не науки, IMHO. Уж по крайней мере на значимость физики (математики) они претендовать не могут. И быстрое дискретное преобразование Фурье, на котором основываются алгоритмы сжатия звука/изображения вещь не совсем тривиальная. Я это говорю как человек, заканчивающий мехмат МГУ. P.S. Извиняюсь за offtopic. -- WBR, Konstantin V. Sorokin GnuPG key fingerprint = 37A1 D039 0F07 774A BE34 428B 1E11 18BA 735B 7797 :wq pgpjOPgP6iHib.pgp Description: PGP signature
Re: web-frontend к ftp с поиском
On Sun, 3 Jun 2001, Victor B. Wagner wrote: On Sat, 2 Jun 2001, Vlad Harchev wrote: Напишу. Используя Gtk, Fltk, Qt или wxWindows. Хотя на мой взгляд из них всех Tk по-прежнему самый переносимый и удобный. Ни на одном из них ты не напишешь GUI одновременно для Win32, X11, MacOS, BeOS, OS/2, и QNX. Напишешь. Более того, если мы начинаем говорить о портабельности, Откровенная чушь. Ни gtk, ни qt, ни Tk все эти системы вместе не поддерживают. А от вендора каждой уважающей себя ОС или граф. оболочки как раз и ждут, что будет доступен порт java. А вот портирования gtk или Tk - нет.. Стандарты де-факто, блин.. то *BSD актуальнее чем BeOS, OS/2 и QNX вместе взятые. Согласен. Но это другой вопрос. Вот-вот, если бы при этом все они пользовались одинаковой DTD, и одинаково реализовывали то, что в DTD не влазит (собственно код приложения) - проблем бы не было. А лицензия конкретной мозилловской реализации не важна, потому что Reference implementation всегда ублюдочна и для практической работы малопригодна. Посмотри хотя бы на фраунгоферовский MP3 кодер. Ну, MP3 кодеры - это уже наука. А виджетсеты - нет - и посему ничего особо ублюдочного (кроме архитектуры) там быть не может - они либо работают, либо Большая часть существующих GUI ублюдочна именно потому что никто не рассматривает их дизайн как науку. А это куда более сложная наука Дизайн - емкое слово, обозначающее и архитектуру и внешний вид. Что ты имел ввиду? Проектирование архитектуры можно с очень большой натяжкой назвать наукой, тем более если можно пользоваться опытом использования/анализом уже существующих аналогов об[хекта. Best regards, -Vlad
Re: web-frontend к ftp с поиском
On Sun, 3 Jun 2001, Konstantin Sorokin wrote: On Sun, Jun 03, 2001 at 12:27:28PM +0400, Victor B. Wagner wrote: Большая часть существующих GUI ублюдочна именно потому что никто не рассматривает их дизайн как науку. А это куда более сложная наука (поскольку включает в себя психологию), чем алгоритмы упаковки звука, которые чистая физика плюс немного физиологии. Ваяние GUI и психология вообще не науки, IMHO. Уж по крайней мере на значимость физики (математики) они претендовать не могут. И быстрое дискретное преобразование Фурье, на котором основываются алгоритмы сжатия звука/изображения вещь не совсем тривиальная. Я это говорю как человек, заканчивающий мехмат МГУ. А я, как человек, окончивший географический факультет того же МГУ, говорю, что основная беда нашей цивилизации в том, что технари не желают признавать науки о сложных системах, будь то человек, человеческое общество или биоценоз, за науку. Виноваты здесь не только и не столько технари, но факт налицо. P.S. Извиняюсь за offtopic.
Re: web-frontend к ftp с поиском
On Sun, 3 Jun 2001, Vlad Harchev wrote: Напишешь. Более того, если мы начинаем говорить о портабельности, Откровенная чушь. Ни gtk, ни qt, ни Tk все эти системы вместе не поддерживают. А от вендора каждой уважающей себя ОС или граф. оболочки как раз и ждут, что будет доступен порт java. А вот портирования gtk или Tk - нет.. Стандарты де-факто, блин.. Ждут-то ждут, но как эти ожидания хреново оправдываются... Согласен. Но это другой вопрос. Большая часть существующих GUI ублюдочна именно потому что никто не рассматривает их дизайн как науку. А это куда более сложная наука Дизайн - емкое слово, обозначающее и архитектуру и внешний вид. Что ты имел ввиду? В первую очередь - архитектуру, во вторую feel, в третью - look. Проектирование архитектуры можно с очень большой натяжкой назвать наукой, Вот в том-то и проблема, что с большой натяжкой.
Re: web-frontend к ftp с поиском
Hi. VH Напишу. Используя Gtk, Fltk, Qt или wxWindows. VH Хотя на мой взгляд из них всех Tk по-прежнему самый переносимый и удобный. VH VH Ни на одном из них ты не напишешь GUI одновременно для Win32, X11, MacOS, VH BeOS, OS/2, и QNX. Еще Palm забыл ;-) Там браузер есть. А gtk и т.п. - нету. VH VH AWT со всеми упомянутыми даже рядом не стоял. VH VH Возможно, но он портабельнее. Иногда это намного важнее. Кстати, любой софт надо устанавливать, а браузер - всегда есть (практически). Вобщем, дискуссия интересная, но ни к чему не ведущая IMHO :-) -- Константин Черкасов [EMAIL PROTECTED]
Re: web-frontend к ftp с поиском
On Fri, 1 Jun 2001, Vlad Harchev wrote: Ну и на perl python ты не напишешь GUI (не используя Tk :) - Напишу. Используя Gtk, Fltk, Qt или wxWindows. Хотя на мой взгляд из них всех Tk по-прежнему самый переносимый и удобный. AWT со всеми упомянутыми даже рядом не стоял. А я - видел. Да и вообще, запуск java-appleta в браузере - технически простая вещь (с точки зрения реализации - это создание подокна и управление фокусом ввода) - посему именно *к браузерам* претензий быть не должно. Проблемы могут быть в теории только из-за java VM standard classes implementation. Вот именно из-за них они и есть. А еще из-за самой идеологии писания GUI на объектно-ориентированном компилируемом языке. Самые большие проблемы заключаются в том, что модель lightweight процессов в Java крива и тяжеловесна, а при этом GUI классы зарекаются на ее использование. В отличие от Tk Gtk и иже с ними, которые event-driven и erlang, в котором легковесные процессы реализованы по-человечески. Чего чего? Какое отношение LGPL может иметь к XML-ной DTD? DTD любой школьник за 10 минут наклепает. Важен многоплатформенный код, Ты пробовал писать DTD? Я - пробовал. Последний раз разработка DTD для такой тривиальной вещи как конфигурация кроновских заданий заняла у нас с Толиком Лазаревым два дня. За это время были написаны (и выброшены) две реализации кода, который с этой DTD работает. который в соотв-ии с xml создает и конфигурит виджеты, а также сам кроссплатформенный виджетсет который юзается мозиллой. Ну а если просто про идею описания GUI в XML - это уже давно используется для qt и gtk и наверно для других виджетсетов. Вот-вот, если бы при этом все они пользовались одинаковой DTD, и одинаково реализовывали то, что в DTD не влазит (собственно код приложения) - проблем бы не было. А лицензия конкретной мозилловской реализации не важна, потому что Reference implementation всегда ублюдочна и для практической работы малопригодна. Посмотри хотя бы на фраунгоферовский MP3 кодер. -- Victor Wagner [EMAIL PROTECTED] Chief Technical Officer Office:7-(095)-748-53-88 Communiware.Net Home: 7-(095)-135-46-61 http://www.communiware.net http://www.ice.ru/~vitus
Re: web-frontend к ftp с поиском
Jun 1, Victor Wagner: On Fri, 1 Jun 2001, Vlad Harchev wrote: Самые большие проблемы заключаются в том, что модель lightweight процессов в Java крива и тяжеловесна, а при этом GUI классы зарекаются на ее использование. В отличие от Tk Gtk и иже с ними, которые event-driven и erlang, в котором легковесные процессы реализованы по-человечески. Хмм... А где это в яве есть лайтвейт процессы? Там просто треды. Никакие не лайтвейт, ни хевивейт, а просто треды. Тяжеловесность их сильно приувеличена, равно как и кривость. -- Paul S. Romanchenko, Jet Infosystems, Russia.
Re: web-frontend к ftp с поиском
On Fri, 1 Jun 2001, Pavel Romanchenko wrote: Самые большие проблемы заключаются в том, что модель lightweight процессов в Java крива и тяжеловесна, а при этом GUI классы зарекаются на ее использование. В отличие от Tk Gtk и иже с ними, которые event-driven и erlang, в котором легковесные процессы реализованы по-человечески. Хмм... А где это в яве есть лайтвейт процессы? Там просто треды. Никакие Ну так треды и есть частный случай лайтвейт процессов. не лайтвейт, ни хевивейт, а просто треды. Тяжеловесность их сильно приувеличена, равно как и кривость. Почему же тогда у примитивного GUI Oracle Installer RSS 128Mb, а у существенно более развесистого GUI на Tcl/Tk - 5Mb? Кстати, о прямизне и кривости posix threads давайте рассуждать после того, как рассмотрим некоторую другую модель lightweight процессов. Вот в сравнении и будет понятно что криво, а что прямо. thread-ы кривы не сами по себе, а в сочетании с моделью управления памятью принятой в Java. -- Victor Wagner [EMAIL PROTECTED] Chief Technical Officer Office:7-(095)-748-53-88 Communiware.Net Home: 7-(095)-135-46-61 http://www.communiware.net http://www.ice.ru/~vitus
Re: web-frontend к ftp с поиском
On Wed, 30 May 2001, Daniel Ginsburg wrote: On Wed, May 30, 2001 at 05:03:50PM +0700, Dmitry Chernyakov wrote: On Wed, 30 May 2001 11:52:50 +0400 (MSD) Victor Wagner [EMAIL PROTECTED] wrote: VW Хочешь ли ты сказать, что веб-интерфейс неудобен вообще, сам по себе, либо это неудобно лишь как средство управления сайтом и его контентом? VW Вообще. Обоснуй (это обзывательство). Web интерфейсы ужасны. Чего хотя бы стоит редактирование текста в формах. По мне, так без vi bindings текст редактировать вообще невозможно. Отсутствие vi bindings - это уже к браузеру, а не к web intrefaces. lynx позволяет использовать vi bindings AFAIR (уж emacs bindings точно) (и вызывать внешний редактор для редактирования textarea). При большом желании можно отхакать Mozilla для поддерджки vi bindings. В netscape наверно это уже делается с помощью X resources (уж emacs bindings точно). Выбирать, что-либо из этих menu from hell, состоящих из 150-200 пунктов (часто очень встречаются) я не могу. Это можно упростить/сделать с помощью спец. java or javascipt applets. Во всех браузерах крайне слабая клавиатурная навигация, без мыши не обойдешься. Это проблема некоторых браузеров. В lynx можно прыгнуть к элементу с произвольным номером (у него есть режим, когда около каждой link/control показывается номер - типа [43] - и достаточно набить его чтобы перейти на тот элемент).То же и в popup lists - ссылки тоже нумеруются. А также в popup lists можно искать подстроку - и эелемнт с найденной подстрокой автоматически выбирается. В HTML 4.0 Specification есть accelerators для form controls (хотя я не в курсе, поддерживают ли их современные гуевые браузеры). Из web приложений, требующих развитого интерфейса, таких, как управление контентом сайта, почта, конференции и т.д., я ни разу не встречал ничего удобного и думаю что не встречу никогда. Короче, вся инфраструктура для удобного web-interface уже есть, либо может теоретически предоставляться браузерами, и на худой конец реализуема при помощи применения Java. Слава богу, код Mozilla - открыт, и при желании можно добавить в нее поддержку mouseless navigation, accelerators custom keyboard bindings если сильно приспичит. Best regards, -Vlad
Re: web-frontend к ftp с поиском
On Thu, 31 May 2001, Vlad Harchev wrote: Web интерфейсы ужасны. Чего хотя бы стоит редактирование текста в формах. По мне, так без vi bindings текст редактировать вообще невозможно. Отсутствие vi bindings - это уже к браузеру, а не к web intrefaces. lynx позволяет использовать vi bindings AFAIR (уж emacs bindings точно) (и вызывать внешний редактор для редактирования textarea). При большом желании можно отхакать Mozilla для поддерджки vi bindings. В netscape наверно это уже делается с помощью X resources (уж emacs bindings точно). Так вот, теоретически можно гланды через одно место вырезать. Вопрос в том, зачем. Когда говорят о web-интерфейсах, имеют обычно в виду интерфейсы доступные достаточно широкому классу пользователей без апгрейда их браузеров и установки специальных плагинов. Поелику если нам надо ставить специальную софтину, почему бы не поставить специализированный клиент, написанный на Java или каком-нибудь Delpi/Kylix? Этот специализированный клиент написать гораздо легче чем эквивалентный по функциональности Web-интерфейс. Общаться с сервером этот клиент может, скажем по SOAP, чем снимаются все проблемы с проникновением через firewall-ы. Если нужна гибкость и возможность централизованной модификации интерфейса, клиент пишется на Tcl/Tk, Perl/Tk, Python/Tkinter и подгружает обновившиеся модули с сервера по мере необходимости (а уж какие возможности тут предоставляет erlang) Другой вариант - использование ssh-клиента (благо тут вариантов куча putty.exe, не нуждающийся в установке, java ssh applet) и curses или slang-based полноэкранный интерфейс на сервере. Если мы будем всегда рассматривать эти два варианта (вернее три - компилированный клиент SOAP, скриптовый клиент SOAP и текстовый интерфейс over ssh) как альтернативы web-интерфейсу, то мы увидим, что во всех случаях кроме самых тривиальных (поисковые системы и форумы) web-интерфейс проигрывает. Даже для web-чатов использование Java-клиента (запускаемого как апплет) зачастую осмыслено. Слава богу, код Mozilla - открыт, и при желании можно добавить в нее поддержку mouseless navigation, accelerators custom keyboard bindings если сильно приспичит. В Mozilla есть XUIL или как он там называется- XML User Interface Language. Вот на этом и стоило бы писать интерфейсы, если бы оно было чуточку более распространено. Хотя модель распределенного программирования в erlang все равно круче. -- Victor Wagner [EMAIL PROTECTED] Chief Technical Officer Office:7-(095)-748-53-88 Communiware.Net Home: 7-(095)-135-46-61 http://www.communiware.net http://www.ice.ru/~vitus
Re: web-frontend к ftp с поиском
On Thu, 31 May 2001, Victor Wagner wrote: On Thu, 31 May 2001, Vlad Harchev wrote: Web интерфейсы ужасны. Чего хотя бы стоит редактирование текста в формах. По мне, так без vi bindings текст редактировать вообще невозможно. Отсутствие vi bindings - это уже к браузеру, а не к web intrefaces. lynx позволяет использовать vi bindings AFAIR (уж emacs bindings точно) (и вызывать внешний редактор для редактирования textarea). При большом желании можно отхакать Mozilla для поддерджки vi bindings. В netscape наверно это уже делается с помощью X resources (уж emacs bindings точно). Так вот, теоретически можно гланды через одно место вырезать. Вопрос в том, зачем. Когда говорят о web-интерфейсах, имеют обычно в виду интерфейсы доступные достаточно широкому классу пользователей без апгрейда их браузеров и установки специальных плагинов. Про vi-bindings высказывание было довольно конкретное и обозначало именно тоску по vi bindings. Поелику если нам надо ставить специальную софтину, почему бы не поставить специализированный клиент, написанный на Java или каком-нибудь Delpi/Kylix? Причем тут спец. софтина? Bindings - глобальная настройка пользователем bindings для своего браузера, независящая от URL'а в текущем окне. Ну а для расширенной функциональности - типа rich text formatting - как раз и нужны java applets (есть же X server на java в 300 Kb). Этот специализированный клиент написать гораздо легче чем эквивалентный по функциональности Web-интерфейс. Общаться с сервером этот клиент может, скажем по SOAP, чем снимаются все проблемы с проникновением через firewall-ы. Да. Можно обойтись без всякого общения с севером через SOAP и не вылезать за рамки http post/get и обычных форм (то же rich text formatting не требует постоянного диалога с сервером по мере редактирования - просто сбрасываем RTF или HTML в hidden input когда юзер нажимает submit). И посему расширяющие функциональность applets могут быть очень общими (general) - то есть имеется возможность собирать функциональность из таких applets как из кирпичиков. Если нужна гибкость и возможность централизованной модификации интерфейса, клиент пишется на Tcl/Tk, Perl/Tk, Python/Tkinter и подгружает обновившиеся модули с сервера по мере необходимости (а уж какие возможности тут предоставляет erlang) Другой вариант - использование ssh-клиента (благо тут вариантов куча putty.exe, не нуждающийся в установке, java ssh applet) и curses или slang-based полноэкранный интерфейс на сервере. Вышеуказанные варианты требуют установки спец. софта (за исключением java ssh applet) и посему не очень портабельны (надо будет достать клиентов для всех популярных платформ и все такое).. Java для этого - практически оптимальна из-за распространенности. И не обязательно на ней писать - можно скомпилить что-нить в java bytecode (например python). Если мы будем всегда рассматривать эти два варианта (вернее три - компилированный клиент SOAP, скриптовый клиент SOAP и текстовый интерфейс over ssh) как альтернативы web-интерфейсу, то мы увидим, что во всех случаях кроме самых тривиальных (поисковые системы и форумы) web-интерфейс проигрывает. Даже для web-чатов использование Java-клиента (запускаемого как апплет) зачастую осмыслено. Согласен. Ты только почему-то в понятие web interface не включаешь java applets. Ну а если включать java applets то должно быть очевидно, что как web interfaces можно реализовать все (не рассматривая трудоемкость писания, приспособленность java и пр.). Слава богу, код Mozilla - открыт, и при желании можно добавить в нее поддержку mouseless navigation, accelerators custom keyboard bindings если сильно приспичит. В Mozilla есть XUIL или как он там называется- XML User Interface Language. Вот на этом и стоило бы писать интерфейсы, если бы оно было чуточку более распространено. Было бы оно LGPLed - уже многие писали бы. А так - кому оно нужно.. Best regards, -Vlad
Re: web-frontend к ftp с поиском
On Thu, 31 May 2001, Vlad Harchev wrote: Когда говорят о web-интерфейсах, имеют обычно в виду интерфейсы доступные достаточно широкому классу пользователей без апгрейда их браузеров и установки специальных плагинов. Про vi-bindings высказывание было довольно конкретное и обозначало именно тоску по vi bindings. Зачем же специально сужать тему? Поелику если нам надо ставить специальную софтину, почему бы не поставить специализированный клиент, написанный на Java или каком-нибудь Delpi/Kylix? Причем тут спец. софтина? Bindings - глобальная настройка пользователем Притом, что все кроме Java-апплета, например Active-X или Flash Plugin - суть специальная софтина, которую надо ставить. клиент пишется на Tcl/Tk, Perl/Tk, Python/Tkinter и подгружает обновившиеся модули с сервера по мере необходимости (а уж какие возможности тут предоставляет erlang) Другой вариант - использование ssh-клиента (благо тут вариантов куча putty.exe, не нуждающийся в установке, java ssh applet) и curses или slang-based полноэкранный интерфейс на сервере. Вышеуказанные варианты требуют установки спец. софта (за исключением java ssh Как иFlash, или Active-X или MSXML без которых развитых web-интерфейсов не бывает. applet) и посему не очень портабельны (надо будет достать клиентов для всех популярных платформ и все такое).. Java для этого - практически оптимальна из-за распространенности. И не обязательно на ней писать - можно скомпилить что-нить в java bytecode (например python). Моя практика показывает, что Java, несмотря на все заявления Sun и прочих МЕНЕЕ портабельна, чем perl, tcl и python. Например, на BSDI 2.x и 3.x эти три есть, а Java - нет. На более современных *BSD, да в общем-то и на Linux, Java глючна неимоверно (из-за своей любви к multithreading), а эти три - rock solid. проигрывает. Даже для web-чатов использование Java-клиента (запускаемого как апплет) зачастую осмыслено. Согласен. Ты только почему-то в понятие web interface не включаешь java applets. Не включаю. Из-за того, что ни разу не видел работоспособного за пределами конкретного браузера java-апплета, который бы не надо было нафиг переписывать по каждому чиху. Технология разработки web-интерфейсов, и технология разработки Java-апплетов принципиально различны, и последняя больше похожа на технологию разработки традиционных приложений на C. В Mozilla есть XUIL или как он там называется- XML User Interface Language. Вот на этом и стоило бы писать интерфейсы, если бы оно было чуточку более распространено. Было бы оно LGPLed - уже многие писали бы. А так - кому оно нужно.. Чего чего? Какое отношение LGPL может иметь к XML-ной DTD? -- Victor Wagner [EMAIL PROTECTED] Chief Technical Officer Office:7-(095)-748-53-88 Communiware.Net Home: 7-(095)-135-46-61 http://www.communiware.net http://www.ice.ru/~vitus
Re: web-frontend к ftp с поиском
On Thu, 31 May 2001, Victor Wagner wrote: On Thu, 31 May 2001, Vlad Harchev wrote: Когда говорят о web-интерфейсах, имеют обычно в виду интерфейсы доступные достаточно широкому классу пользователей без апгрейда их браузеров и установки специальных плагинов. Про vi-bindings высказывание было довольно конкретное и обозначало именно тоску по vi bindings. Зачем же специально сужать тему? Я отвечал на конкретную фразу в письме. клиент пишется на Tcl/Tk, Perl/Tk, Python/Tkinter и подгружает обновившиеся модули с сервера по мере необходимости (а уж какие возможности тут предоставляет erlang) Другой вариант - использование ssh-клиента (благо тут вариантов куча putty.exe, не нуждающийся в установке, java ssh applet) и curses или slang-based полноэкранный интерфейс на сервере. Вышеуказанные варианты требуют установки спец. софта (за исключением java ssh Как иFlash, или Active-X или MSXML без которых развитых web-интерфейсов не бывает. applet) и посему не очень портабельны (надо будет достать клиентов для всех популярных платформ и все такое).. Java для этого - практически оптимальна из-за распространенности. И не обязательно на ней писать - можно скомпилить что-нить в java bytecode (например python). Моя практика показывает, что Java, несмотря на все заявления Sun и прочих МЕНЕЕ портабельна, чем perl, tcl и python. Например, на BSDI 2.x и 3.x эти три есть, а Java - нет. На более современных *BSD, да в общем-то и на Linux, Java глючна неимоверно (из-за своей любви к multithreading), а эти три - rock solid. Ну, на популярных плафтормах она вроде ничего.. Ну и на perl python ты не напишешь GUI (не используя Tk :) - а на java - ты смеешь надеяться. Ну и глючит/неглючит - это уже относится к деталям реализации. В теории все должно быть ОК. проигрывает. Даже для web-чатов использование Java-клиента (запускаемого как апплет) зачастую осмыслено. Согласен. Ты только почему-то в понятие web interface не включаешь java applets. Не включаю. Из-за того, что ни разу не видел работоспособного за пределами конкретного браузера java-апплета, который бы не надо было А я - видел. Да и вообще, запуск java-appleta в браузере - технически простая вещь (с точки зрения реализации - это создание подокна и управление фокусом ввода) - посему именно *к браузерам* претензий быть не должно. Проблемы могут быть в теории только из-за java VM standard classes implementation. нафиг переписывать по каждому чиху. Технология разработки web-интерфейсов, и технология разработки Java-апплетов принципиально различны, и последняя больше похожа на технологию разработки традиционных приложений на C. Да, технологии существенно отличаются. В Mozilla есть XUIL или как он там называется- XML User Interface Language. Вот на этом и стоило бы писать интерфейсы, если бы оно было чуточку более распространено. Было бы оно LGPLed - уже многие писали бы. А так - кому оно нужно.. Чего чего? Какое отношение LGPL может иметь к XML-ной DTD? DTD любой школьник за 10 минут наклепает. Важен многоплатформенный код, который в соотв-ии с xml создает и конфигурит виджеты, а также сам кроссплатформенный виджетсет который юзается мозиллой. Ну а если просто про идею описания GUI в XML - это уже давно используется для qt и gtk и наверно для других виджетсетов. Best regards, -Vlad
Re: web-frontend к ftp с поиском
On Wed, 30 May 2001, Dmitry Chernyakov wrote: Victor Wagner [EMAIL PROTECTED] wrote: VW управления контентом сайта. Во-первых, web-интерфейсы жутко неудобны VW в обращении, во-вторых - повесишься с security. Хочешь ли ты сказать, что веб-интерфейс неудобен вообще, сам по себе, либо это неудобно лишь как средство управления сайтом и его контентом? Вообще. -- Victor Wagner [EMAIL PROTECTED] Chief Technical Officer Office:7-(095)-748-53-88 Communiware.Net Home: 7-(095)-135-46-61 http://www.communiware.net http://www.ice.ru/~vitus
Re: web-frontend к ftp с поиском
On Wed, 30 May 2001, Dmitry Chernyakov wrote: VW Хочешь ли ты сказать, что веб-интерфейс неудобен вообще, сам по себе, либо это неудобно лишь как средство управления сайтом и его контентом? VW Вообще. Обоснуй (это обзывательство). По-моему, для ИНТЕРФЕЙСА (т.е. средств интерактивного взаимодействия с пользователем) DTD HTML не приспособлена как класс. form и input - типичнейшие костыли. Реализация их в браузерах неудобна до безобразия. Чуть только у тебя текст длинее окошка в форме, в нем сразу теряешься. Ни тебе поиска, ни тебе переходов на заданный номер строки, про подсветку синтаксиса (если он есть) я и не говорю. Про WISYWYG (при необходимости ввода форматированного текста - тем более). Многоуровневых каскадных меню - нет. Все списки вариантов выбора должны быть отданы пользователю сразу. Даже если из десяти popup-menu на странице ему в среднем нужно одно. Даже до такой тривиальной вещи как select src=http/ никто не додумался. По-моему, в браузерах (в первую очередь в ie) нехватает всего двух стандартных для HTML4 возможностей: thead и tfoot в таблицах для постраничной печати и вывода на экран, и shortcut кнопки в формах. Речь идет не о соответствии браузера стандарту, а о соответствии стандарта или его практической реализации задаче. Все остальное лечимо и приспосабливаемо. -- Yours truly, CDS - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Victor Wagner [EMAIL PROTECTED] Chief Technical Officer Office:7-(095)-748-53-88 Communiware.Net Home: 7-(095)-135-46-61 http://www.communiware.net http://www.ice.ru/~vitus
Re: web-frontend к ftp с поиском
On Wed, May 30, 2001 at 05:03:50PM +0700, Dmitry Chernyakov wrote: On Wed, 30 May 2001 11:52:50 +0400 (MSD) Victor Wagner [EMAIL PROTECTED] wrote: VW Хочешь ли ты сказать, что веб-интерфейс неудобен вообще, сам по себе, либо это неудобно лишь как средство управления сайтом и его контентом? VW Вообще. Обоснуй (это обзывательство). Web интерфейсы ужасны. Чего хотя бы стоит редактирование текста в формах. По мне, так без vi bindings текст редактировать вообще невозможно. Выбирать, что-либо из этих menu from hell, состоящих из 150-200 пунктов (часто очень встречаются) я не могу. Во всех браузерах крайне слабая клавиатурная навигация, без мыши не обойдешься. Из web приложений, требующих развитого интерфейса, таких, как управление контентом сайта, почта, конференции и т.д., я ни разу не встречал ничего удобного и думаю что не встречу никогда. -- dg This message is for informational purposes only and may contain confidential business information. All data and other information in it are not warranted as to completeness or accuracy. Any statements made herein do not necessarily reflect those of WARP Solutions Inc. It is intended for the addressee only and may not be copied without our permission. If you are not the intended recipient please contact the sender as soon as possible
Re: web-frontend к ftp с поиском
попробуйте вот это : http://ftp.ee.ncku.edu.tw/ftplocate/readme.english.html -- /mator
Re: web-frontend к ftp с поиском
On Sat, 26 May 2001, constantin cherkasoff wrote: From: constantin cherkasoff [EMAIL PROTECTED] Subject: web-frontend к ftp с поиском X-Mailer: stuphead ver. 0.5.2 (CleverMan) (GTK+ 1.2.10; Linux 2.2.17; i686) Hi! Не подскажет кто, из чего наименее геморойно сделать ftp-архив с поиском, html-индексами и т.д.? Вдруг есть что-то готовое? apache ;-) -- Victor Wagner [EMAIL PROTECTED] Chief Technical Officer Office:7-(095)-748-53-88 Communiware.Net Home: 7-(095)-135-46-61 http://www.communiware.net http://www.ice.ru/~vitus
Re: web-frontend к ftp с поиском
Hi! VW Не подскажет кто, из чего наименее геморойно сделать ftp-архив с поиском, VW html-индексами и т.д.? Вдруг есть что-то готовое? VW VW apache ;-) Очень смешно :-P Не, ну серьезно. Всяких портало-слэшдот-образных готовых систем пруд пруди. А типа download.ru, только в 100 раз проще что-нибудь? Не охота изобретать велосипед. -- Константин Черкасов [EMAIL PROTECTED]
Re: web-frontend к ftp с поиском
On Mon, 28 May 2001, constantin cherkasoff wrote: Hi! VW Не подскажет кто, из чего наименее геморойно сделать ftp-архив с поиском, VW html-индексами и т.д.? Вдруг есть что-то готовое? VW VW apache ;-) Очень смешно :-P Не, ну серьезно. Всяких портало-слэшдот-образных готовых систем пруд пруди. А типа download.ru, только в 100 раз проще что-нибудь? Не охота изобретать велосипед. Apache без всяких наворотов, с DocumentRoot совпадающим с корнем архива и Option +Indexes. Можно еще с FancyIndexes, AddIconByType и прочими директивами конфигурации поиграться. Поиск по файловому архиву - вещь весьма бессмысленная, если только у тебя нет исторически сложившейся системы комментирования файлов в архиве. Если есть, то проще прикрутить поиск к ней, чем искать готовую систему, и конвертировать базу описаний в ее формат. Вообще говоря, до наступления всяких навороченных систем веб-сервера были предназначены для раздачи файлов. И они не забыли как это делать, в отличие от пользователей.
