41

Re: Just Clipboard Manager

HTML схожий на хоч якийсь  платформонезалежний стандарт для форм з кнопками. Будь-що інше для цієї задачі — це як прямий доступ до відеопам'яті замість  stdin i stdout для вводу/виводу в консолі.

42

Re: Just Clipboard Manager

Чому ж тоді автори JVM не вкрутили HTML? І порівняння я не зрозумів?

43

Re: Just Clipboard Manager

mikeos написав:

Немає нічого ідеального. Кожну мову, технологію, проект і код можна розкритикувати.
Звісно програміст має писати чистий і оптимізований код. Конкретно в даному випадку вихідний код займає 1 мб (це врахлвуючи файли тестів, іконки і т.п.), отже все решта додає компілятор, значить треба критикувати Visual Studio чому скомпільований проект для десктопної програми так багато важить ).

З усім з годен а з оцим не згоден бо 1мб коду != 1мб програми бо як туда на імпортувати бібліотек то можна зкомпілити і гігову програму.

44 Востаннє редагувалося P.Y. (28.09.2023 18:45:21)

Re: Just Clipboard Manager

javascriptIsLife написав:

Чому ж тоді автори JVM не вкрутили HTML? І порівняння я не зрозумів?

На той час html був молодим і мав досить бідні можливості, а Java-аплети просувались як заміна того, чого в чистому html не вистачає. До нашого часу аплети вмерли, але ті ж класи, що в аплетах, продовжують використовуватись у десктопній джаві.

Узагалі, це непогана ідея — компілювати html у java-клас віконної форми. Не здивуюсь, якщо хтось уже розробив щось подібне.


Аналогія відсилає до програм для DOS, що працюють у текстовому режимі екрану. Така програма може виводити текст, записуючи його в відеопам'ять екрану безпосередньо, або ж вона може виводити текст через stdout. Прямий запис у відеопам'ять має свої переваги, ним можна робити різні цікаві ефекти, якийсь час це було модно і круто — але така програма буде залежною від конкретної платформи (чи навіть конкретного заліза), перенести її на іншу ОС чи машину з іншою архітектурою буде складно. Тоді як стандартний вивід використовується на багатьох різних платформах, і програму, розраховану на роботу з ним, можна без суттєвої переробки перенести на інші платформи. Повертаючись до наших формочок, практично будь-яка бібліотека для них — це бібліотека однієї платформи, код для якої складно перенести на іншу платформу чи переписати на іншу мову — набір класів різний, схема взаємодії з ними різна. У той же час, html є скрізь — можна оформити програму, наприклад, у вигляді веб-сервера на локалхості, що взаємодіятиме з користувачем через браузер — таку програму можна буде запустити на безлічі різних систем, і вона скрізь зможе виконувати свою роботу, не вимагаючи окремих фронтендників для віндовс-десктопу, лінукс-десктопу, мобільних платформ тощо.

45

Re: Just Clipboard Manager

Звучить дещо шизуфато.

P.Y. написав:

У той же час, html є скрізь — можна оформити програму, наприклад, у вигляді веб-сервера на локалхості, що взаємодіятиме з користувачем через браузер — таку програму можна буде запустити на безлічі різних систем, і вона скрізь зможе виконувати свою роботу, не вимагаючи окремих фронтендників для віндовс-десктопу, лінукс-десктопу, мобільних платформ тощо.

HTML є скрізь лише в тому смислі що переглядач для HTML є скрізь і штука в тому що навіть попри те що переглядач HTML є скрізь ніколи не зустрічав такого щоб розповсюджували HTML–файлик з програмою на JavaScript який відкриваєш в HTML–переглядачем і от тобі кросплатформенна програма. Вебщики розповсюджують свій монстроузний Electron (окремий фронтендник) і вже в ньому користувач запускає їхню програму а це рівнозначно програмам на таких кросплатформенних штуках як JVM, GTK, Qt, WxWidgets, Python, Tcl, Perl і будь–чому іншому що надає прослойку не привʼязану до ОС прослойку та програмою. Єдина суттєва відмінність між Electron та рештою полягає в тому що взяти якого–небудь верстальщика–явасценариста яких зараз розвелося стільки що куди не плюнь, обовʼязково влучиш в одного.

Задумка з HTTP–сервером якось занадто близька до божевільної ідеї писати під одну ОС, але потім розповсюджувати програму разом з ОС всередині файлу для віртуальної машини, але як бути у випадку коли потрібно не просто з БД взаємоідяти і в файлики писати а ще й робити якісь речі які HTTP–сервер чи браузер зробити не дозволить?

46

Re: Just Clipboard Manager

Tarpan87 написав:

Спробу схвалюю, але 50мегабайтне одоробло-менджер буферу обміну це занадто.

Зараз усі так пишуть. QT тягне 100 метрів на хелло_ворлд.
Пройшли ті часи, коли писали на нормальних мовах

47

Re: Just Clipboard Manager

kant12 написав:

QT тягне 100 метрів на хелло_ворлд.

Га ?
Код такого hello_world'а в студію.

48

Re: Just Clipboard Manager

Прошу звернути увагу що тут не лише більше 100 Мб і всередині віруальної машини .NET, але й на додочу лише для Windows. Незважаючи на всі накладні витрати воно не кросплатформенне що слугувало б хоч якимсь виправданням. Виграє лише програміст.

49

Re: Just Clipboard Manager

javascriptIsLife написав:

Задумка з HTTP–сервером якось занадто близька до божевільної ідеї писати під одну ОС, але потім розповсюджувати програму разом з ОС всередині файлу для віртуальної машини, але як бути у випадку коли потрібно не просто з БД взаємоідяти і в файлики писати а ще й робити якісь речі які HTTP–сервер чи браузер зробити не дозволить?

Ідею з http-сервером використано, наприклад, у дистрибутивах пітона, де можна запустити сервер документації й дивитися довідку офлайн через браузер (підозрюю, цим рідко користуються, бо є зручніші альтернативи, але така можливість є). HTTP-сервер не зобов'язаний бути чимось роздутим і сидіти під віртуалізацією — фактично, це може бути щось на рівні простенької консольної програмки, але взаємодіяти з користувачем не через stdin/stdout, a через браузер і протокол http. Самий браузер тягати з дистрибутивом програми непотрібно — як правило, в системі він вже є. Серверна частина може взаємодіяти з системою, як їй заманеться — це звичайна програма, тільки без власного графічного вікна. Уся графіка та взаємодія з користувачем — через браузер, тому обмеженням є графічні можливості браузера. Також обмеженням може бути сумісність з багатьма різними браузерами,  а не якимось конкретним (якщо від цього відійти, то справді доведеться тягати цей конкретний браузер разом з дистрибутивом програми). Кросплатформність серверної частини забезпечується приблизно так само, як кросплатформність консольної програми: це може бути програма для кросплатформного інтрпретатора назразок JVM, або ж це може бути переносний початковий код, що компілюється для різних систем.