Про прямоту рук разработчиков Джавы

ДЛя тех, кто не ходит по ссылкам:

Instead of determining if the system tray is supported,
isTraySupported() derives its result from the name of the window
manager. Specifically, it returns true only if the window manager is
named "Metacity" or "KWin". Not only is there no requirement that
the window manager be the entity providing the system tray, at least
in the case of Metacity, it really doesn't. This means:

If I use Gnome (complete with panel, which supplies the system
tray) but with an alternate window manager, SystemTray.isSupported()
returns false and I can't use the system tray.

If I use Metacity in an environment where there is no system tray
(e.g. outside of Gnome), SystemTray.isSupported() will incorrectly
return true.

А багу никто не забивал?

Если прочитать адрес сcылки, то с уверенностью можно предположить, что это и есть bugreport

> Если прочитать адрес сcылки, то с уверенностью можно предположить, что это и есть bugreport

Таки да. Но труЪ ЛОРовецЪ по ссылкам не то что не ходит, но даже на них не смотрит :)

Да, есть такая бяка. Проверил сейчас - в metacity true, в beryl - false.

А вообще, есть ли адекватные способы это определить?

Я конечно не спец по иксам, но когда например на панель задач xfce пытаешься добавить tray, то, если он уже есть какой-нибудь другой, получаешь ошибку, что tray manager на этом DISPLAY уже есть. Как-то же оно это определает. :)

Тупое быдло ынтерпрайз класса это как-то не осилило.

> Я конечно не спец по иксам, но когда например на панель задач xfce пытаешься добавить tray, то, если он уже есть какой-нибудь другой, получаешь ошибку, что tray manager на этом DISPLAY уже есть. Как-то же оно это определает.

Значит есть способ :) Очень жаль что в Java есть такая досадная ошибка, разработчики Linux-версии тоже видимо не спецы по иксам :)

> Значит есть способ :)

Ещё неизвестно, насколько он прямой. Может статься, что кривой, как в лучших традициях M$. А интересно, разработчики жабы могут напрямую содрать код себе из xfce? Или лицензия не позволит?

> Тупое быдло ынтерпрайз класса это как-то не осилило.

Платформенные фичи - вообще не сильная сторона жабы. Например, она так до сих пор и ниасилила определять каталог, где в венде положено хранить пользовательские настройки. В итоге все жабские приложения дружно срут напрямую в %HOMEPATH% вместо %APPDATA%. И что характерно - никто не чешется. Юзер обычно не видит, а остальным тем более пох.

>Платформенные фичи - вообще не сильная сторона жабы.

А у кого они сильнее?

> А вообще, есть ли адекватные способы это определить?

У freedesktop есть notification area spec, хоть это и черновик, но должно работать в большинстве случаев. Проблема в том, что поддержку system tray в jdk засунули практически напрямую из jdic (https://jdic.dev.java.net/), который (a) находится в каменном веке (b) мерзко написан (пришлось как-то в нем копаться, и в результате на него положить).

А ты бы смог просто и доходчиво доказать, что твои руки прямее? Ну в смысле сбацать код, который правильно реализует данный метод?

>>Платформенные фичи - вообще не сильная сторона жабы.

>А у кого они сильнее?

у С :)

>у С :)

И давно сишный бинарник стал переносимым? :D

> И давно сишный бинарник стал переносимым? :D

.o и .a вроде переносимы между различными версиями GCC, в том числе и Mingw... Или нет?

> И давно сишный бинарник стал переносимым? :D

А для чего, кроме тупых детских игрушек, нужны переносимые бинарники? Чё, так сложно откомпилить под пару платформ?

>А для чего, кроме тупых детских игрушек, нужны переносимые бинарники? Чё, так сложно откомпилить под пару платформ?

Ну да. Зоопарк бинарного кода под зоопарк процессоров. А чё -- венты большие, места не жалко. :))