Russian Qt Forum

Дарова!
Можно как-то заставить их сотрудничать? )
Или может есть какаянить альтернатива?

перегрузить QAbstractFileEngine и реализовать в нём "прозрачную" поддержку фтп.
или подождать когда это сделаю я :)

"или подождать когда это сделаю я" -  ;D Ждать долго то?
Я так и думал что придется перегружать его. Еще думал что возможно как-то это можно сделать иначе...

иначе никак.

ближайшие неделю-полторы времени не будет и я буду недоступен.
назови свои сроки - если нужно срочно, могу помочь с теорией, а потом воспользоваться результатами (пусть даже и неполными); иначе подожди моих результатов и воспользуешься ими сам.
в любом случае, моя реализация будет лучше ;D

Как это понимать?!
Думаете уровень моих знаний ниже?

"лучше для меня"

зы. интересно что скрывается под точками)

хорошо, вижу, вызвал негативные эмоции :)
поэтому поясню: в данный момент асбтрактфайлэнджине подходит для написания вфс-ок лишь по документации. на самом же деле нужно пересматривать реализацию в целом, т.к. текущая реализация достаточна лишь для кутэшного движка - абстрактфайлэнджинеитератор писался на пару лет позже, чем абстрактфайлэнджине - связать их между собой не представляется возможным по причинам бинарной совместимости...и т.д., и т.п. т.е. до 5.0 реализацию никто пересматривать не будет.
сейчас у меня уже есть наработанный набор костылей, есть набор патчей, которые я намерен продвигать в мэйн, вдобавок имеется опыт в написании (в)фс на базе абстрактфайлэнджины.

надеюсь, этих разъяснений достаточно?)

Благо есть над чем поразмыслить...

niXman, предлагаю эксперимент:)

вводные: наша вфс будет иметь предопределённыую структуру пути (урл) - ftp://username:userpass@hostname/path/to/somefile. при получении пути, начинающегося с "ftp://", метод QAbstractFileEngine::create(...) создаст нам экземпляр класса FtpFileEngine (назовём его так).
разрешается: пользоваться любыми костылями в меру фантазии.
запрещается: модифицировать классы с префиксом "Q", функции с префиксом "q" и макросы с префиксом "Q_"
требуется: одновременно может быть открыто более одного фтп-соединения (сессии), но фактическое соединение для каждой сессии должно быть уникальным - т.е., для любой отдельной сессии перечисление каталога (FtpFileEngineIterator) и файловые операции (FtpFileEngine) должны происходить с использованием одного и того же экземпляра класса QFtp - без разрыва соединения между операциями. при завершении работы с сессией соединение должно быть разорвано и отпущены использованные ресурсы (внешних признаков окончания сессии нет - вероятно, их потребуется определить по использованию ресурсов).

какие будут идеи?:)

Увлекательное предложение.
Но дело в том, что у меня сейчас проект, и мне не нужна такая "крутая" реализация.
Вы недели-полторы будите заняты? Постараюсь к этому времени освободиться.

P.S.
Предложение принято.

к сожалению, задачка с фтпфс более простая, чем задачка с зипфс, которой я сейчас мучаюсь. наверное, есть какой-то обходной способ упростить мои мучения, но для этого мне нужен свежий взгляд и пинок под зад :)
сегодня услышал мнение, что QAbstractFileEngine уже не покрывает потребности нативной QFSFIleEngine. но сделать с этим до 5.0 они всё-равно ничего не могут (помним про source compatibility?)
прискорбно, конечно, но выбора нет - костыли и патчи...

зы. не нужно на "вы" - мы же здесь в одном котле :)

Есть же много готовых реализаций. Даже, где видел STL compatible.
А в чем причина?
Да.
Ок.

готовые не подойдут, т.к. перестраивать интерфейс нельзя. а писать свой набор контейнеров и моделей - тоже не вариант.

причина не называлась, но по косвенным признакам могу сделать предположение, что какие-то новые идеи также приходится реализовывать через костыли (мап/анмап, например)

моя задача - сделать фвс, прозрачную для приложения (в идеале любого на кутэ). т.е. в моём случае QFile("file.zip") - это файл, но QDir("file.zip") - это папка. это победил уже - написал пару патчей. но проблема в том, что без контекста невозможно определить что же требуется от пути: QFileInfo("file.zip") - это файл или папка? сейчас это файл и сделать его папкой можно лишь так: QFileInfo("file.zip/"), но тогда файлинфо будет возвращать другие filePath() и т.п., чем QFileInfo("file.zip")...
буду всю поездку ломать над этим голову...надеюсь, что-нибудь придумается

По реализации ВФС опыт имеется(не большой). Думаю что ЗИП ФС, было бы проще реализовать на Кутэ, а не в Кутэ(мне так кажеться).

zipfs я уже реализовал через ZipFileEngine (пока только на чтение). вот только хочется "прозраности"...
но я в принципе согласен - если за время поездки ничего умного не придумается, придётся отказаться от "прозрачности" и сделать что-нть вроде регистрации расширений для различных вфс (.zip, .iso и т.п.). это создаст массу неудобств и боюсь, придётся тогда клепать какие-нибудь промежуточные костыли для прозрачности файловых операций :(

Чем дело-то закончилось?
Дайте списать ченить.
А то очередной велосипед только умножит энтропию.

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

> Ничем. У меня есть энжин для определенного типа архивов, для зипа так никто и не написал, для фтп тоже.

откровенная ложь)
и для зип, и для фтп я писал энджины - они работали под 4.5, работают и ныне под 4.8

> В 5.0 энжины вообще выкинут, так что писать что-либо сейчас - мартышкин труд.
есть такое дело. вфс будет полностью пересмотрен, появится асинхронный режим и т.д. ждмё 5.0.