Russian Qt Forum

долго думал в какую ветку это писать, остановился здесь

есть программа
к ней прилагается, скажем, десяток текстовых файлов
в файлах информация, построчно
вся суть софта в том, чтобы эту информацию обрабатывать

с одной стороны все просто:
при запуске грузим все файлы в память, предоставляем интерфейс для их редактирования и кнопку Сохранить
по окончании какой-то части работы автосохраняются в файлы

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

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

также, хочу заметить, что я продаю софт людям разного интеллектуального достатка, поэтому интересует наиболее универсальное решение, которое будет понятным и удобным большинству

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

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

Добавлю, что пишу я на python 3.2 + pyqt4

Не грех если вообще не будет. Или модальный редактор с кнопками Save/Cancel. В любом случае нужен "Reload(All)". То есть обойтись без внутреннего редактора можно, без внешнего нельзя.

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

Десяток файлов по 5-10 Mb - это сейчас не объем, поэтому нет оснований для значительного усложнения (грузить по частям). К тому же так или иначе Вы из них какие-то данные извлекаете - так зачем хранить в памяти сам текст? Извлекли - освободили, занялись следующим файлом.

спасибо за ответ

модальный - это суб-окно с textEdit и парой кнопок, которое появляется поверх основного окна?

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

Да

Не кучеряво ли будет "на поток по строке"?  :) Но все равно - когда-то же "разборка" закончится, ведь в любом случае Вы работаете с извлеченными из текста данными (а не с самим текстом)

собственно, вся работа софта и заключается в обработке строк
каждая строка - типа задания для потока - что ему делать

может кто-нибудь ещё поделится опытом из своих проектов?
был бы очень признателен :)

Возможно стоит использовать что-то вроде SQLite.. - транзакции, полноценные запросы и прочие преимущества налицо.
Можете хранить исходные документы (у вас что-то вроде скриптов?) в текстовом виде, затем разбирать на задания и сохранять в базу. Для редактирования грузите весь файл, а при выполнении только несколько записей. Выполненные задания помечаете, или удаляете из базы.
При падении не нужно будет повторять проделанную работу.

при запуске на выполнение/сохранении "вручную"/закрытии/переодически(~.tmp)
В зависимости от "продвинутости" целевой аудитории. Если ваши файлы-документы и могут в понимании пользователя существовать отдельно от программы (вроде .doc, .txt) то нужно. Либо если пользователь достаточно опытен. В остальных случаях лучше прятать тонкости реализации за интерфейсами.
если надо - то надо, но увлекаться не стоит..