Улучшить поддержку Linux

[atauenis]

В связи с проблемами, связанными с невозможностью запускать программы с использованием Xwt на моём Linux-ПК, создаю обобщённую иссую о багах и недоделках FC, проявляющихся на системах *nix. Может быть, кто нибудь с нормально работающим libcairo присоединится. :-)

Итак, сейчас не должны работать на *nix: 1.) Поиск и вывод иконок; 2.) Определение MIME-типов. 3.) и прочие нововведения/правки после марта 2014 г.

P.S. https://groups.google.com/forum/#!topic/xwt-list/rMjLaT5uqwU

[kekekeks]

1) менять текущую директорию на содержащую бинарник - плохая идея, пользователь ожидает, что файловый менеджер откроет текущую. На никсах же сейчас оно запускается в /usr/lib/fcmd 2) неимоверно медленно обрабатываются директории с большим количеством вложенных файлов и папок (пример - /usr/lib). Сначала секунд десять читает содержимое, потом примерно на минуту всё зависает. В Xwt точно нет аналога VirtualMode из тривью, что был в Windows.Forms?

[kekekeks]

Да, скролл на таких директориях тоже небыстр

[atauenis]

Нет. Скролл реализован простым перетаскиванием ListView2Item (строк) за пределы экрана. На WPF их даже видно иногда в неудобных местах. Зато есть возможность прокрутки куда угодно из кода, чего не даёт штатный Xwt.ScrollView.

[kekekeks]

То есть, в листвью всегда все элементы, так? Этот подход нормально работает только при числе элементов не более сотни-двух. Судя по https://github.com/mono/xwt/blob/master/Xwt/Xwt/ListView.cs листвью у них очень деревянный, так что по-хорошему нужно делать свою реализацию. По идее можно утащить https://github.com/mono/mono/blob/master/mcs/class/Managed.Windows.Forms/System.Windows.Forms/ListView.cs и на его основе слепить нечто более-менее рабочее. Xwt же позволяет делать свои виджеты?

[kekekeks]

https://github.com/mono/xwt/blob/master/Xwt/Xwt/Canvas.cs - это единственное, что позволяет поверх себя рисовать? Судя по передаваемому object, там какая-то платформо-зависимая штука приходит. В случае с GTK я делал расшареный между Cairo и System.Graphics битмап (немного магии с указателями), в случае же с маковскими примитивами, не особо представляю, что можно сделать.

[atauenis]

Да. Есть ещё Table, но там посложнее, и не факт, что прокрутка перетасовыванием элементов будет быстрее чем Table + некий ScrollView (HeavyScroller). Платформозависимого там нет вообще. Только моменты интеграции с хостом, когда XWT в роли "гостя" (так XWT можно даже интегрировать в WInForms программы). Мне кажется, лучший выход оставить использование Table, но выводить только часть файлов. Кстати, текущая реализация не так и плоха, /dev на ноутбуке образца 2004 года с Linux грузится за 1 сек. Но менять стоит, однозначно.

[kekekeks]

Секунда на загрузку директории - это уже неприемлемо для файлового менеджера.

Посмотрел, как умеет рисовать Xwt, очень не понравилось. Каждый уважающий себя тулкит имееет возможность создать примитив растра из IntPtr, ширины, высоты и битности. Из-за того, что этого нет, практически невозможно просто использовать System.Drawing для отрисовки (разве что сохранять в стрим и грузить из него битмап каждый кадр, что, мягко говоря, не быстро и создаёт сильную нагрузку на GC).

[atauenis]

Есть такое дело. Но я думаю пойти путём вывода папок аналогично текущему способу, но по частям. Не просто так я делал HeavyScroller (продвинутый ScrollView). Кстати, тот же Total Commander большие каталоги грузит около 0,5-1 сек. и при резкой прокрутке нехило тормозит. Так что 1000 файлов/сек при загрузке будет вполне приемлемым результатом.

[kekekeks]

https://github.com/mono/xwt/issues/346 - создал им пока issue. По идее это должно решить проблемы с использованием нормального тулкита рисования, а не этого "общего знаменателя", что у них сейчас. Если найду время (а они не найдут, соответственно), попробую соорудить реализацию сам. Дальше можно портировать ListView из состава WinForms, попутно получить возможность изменять отрисовку элементов.

[atauenis]

Обнаружено, что при запуске с новым бэкендом Gtk3 fcmd падает с минимальной руганью: (fcmd:10832): Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported. При комментировании MainWindow.cs:278 падение исчезает. Видимо, столкнулись два говнокода, из GTK3 и в Mono WinForms :smiley: .

[kekekeks]

WinForms использует некоторые вещи из GDK, если мне память не изменяет.

[Break-Neck]

Всем привет, у меня веселые новости. Я насчет строчки, из-за которой выпадает ошибка (fcmd:10832): Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported, это я ее написал, мы тогда еще спорили: я сначала сделал там константное значение 1000, atauenis сказал, что его нужно брать из системы, мы сделали Winforms.SystemInformation.DoubleClickTime. Так вот, я полазил по исходникам, вот к чему в конечном счете сводится чтение этого свойства:

internal virtual int DoubleClickTime {
            get {
                return 500;
            }
        }

Предлагаю обсудить, что дальше делать. Я бы тоже заменил на константу (т.к. сами mono'вцы там написали константу, то их встроенный обработчик doubleclick наверняка также орентируется на это значение, значит, в предлагавшемся "поиске элемента, которому приходит событие" смысла мало – результат наверняка будет такой же).

[Break-Neck]

Еще вдогонку, насчет сохранения настроек: оно у меня не работает из-за этого бага. Баг старый, но никак не исправляется, пока не ясно, что с ним делать: либо пытаться его исправить в Mono и послать PR, либо написать свой временный костыль хранения настроек.

[atauenis]

1.) Тогда надо писать 3 платформо-зависимых плагина (для этого нужно сделать интерфейс IPlatformAdaptorPlugin : IPlugin), которые будут запрашивать эту информацию напрямую из реестра, gconf и т.д.. Либо делать 3 разных p/invoke к системным библиотекам в зависимости от ОС. Дело в том, что есть медленные пенсионеры, ставящие это время очень большим (1 сек. и более), так как быстрее они щёлкать не могут в принципе. Если выставить строго 1000 (или 500) мсек, даблклик в FC для этих пользователей может оказаться невозможным. 1.1.) Откат на тулкит Gtk2 не считаю возможным, т.к. он чрезвычайно глючный и к тому же устаревший, а Gtk3 имеется во всех современных дистрибутивах.

2.) Под Mono 3.2.8 (Debian Experemental) сохранение настроек работает. Конечно, можно добавить ещё один костыль в виде хранения настроек в XML или вообще в INI (а то и в EXE файл зашивать, как во времена MS-DOS), только зачем?

[Break-Neck]

Еще у меня при смене директории, если в ней достаточно много файлов, окно изменяет вертикальные размеры, чтобы отображать все элементы. На Windows такого нет, есть ли это на последних версиях Mono?

[atauenis]

Есть. Причина, по всей видимости, в Xwt.Table. См. #28 и #19.