No, C please! ;) Don't want to wake that dinosaur, Linux is still full of that stuff.

I've played with Docker some time ago, but don't know how it helps to stay "portable" between Linux versions. How would it benefit Lumiera or OC?

DEB packaging will be an important point, so i appreciate your offer and will refer to it some time in the future. To automate the process i've planned to use Jenkins as a build system (local, for now). It would also accomplish a lot of other things, like performing automatic test runs and also to ensure clean builds, because a developer machine is usually messy as hell with all the libs and other dependencies.

I would suggest that we start from a very simple base to evaluate which direction to take. Lumiera should be the master and responsible for the session, at least for now.

My preference is a shared lib, as OC is already using OCcore for processing. Lumiera can be equipped with OC plugin which uses the lib One thing bothers me the most. I'm using Qt5 core features for disk IO (folder/file enumeration and similar) in OCcore module. Is it a problem for you to have QtCore as dependency for an OC adapter (at least for now)?

Small typo, it's T609, as T604 is about sociocracy.

Adjusted control names. Will be set to "Resolved" after layout changes are completed.

Current drive list state in Linux (adjusted visuals):

References to find optimal block size for transfer:

Obsolete after splitting OC into multiple applications.

Checked under Windows 8.1 and LinuxMint 17.2.

After reading http://askubuntu.com/questions/561368/why-does-my-qquick-application-crash-on-ubuntu-14-04 changed constructor signature from

Not actual anymore.

OC was restructured and this item isn't actual anymore.

CMake scripts were adjusted according to the new modular structure of OC.

Sill investigating, but it seems to be Qt related bug. Under Windows it works without hassle.

After some on and off OC development (regular job causes usual lack of time), here is the current state of removable drive list:

Tested and committed a bug fix.

Used (maybe misused a little bit) GetVolumeInformation() to get only mounted removable drives. Seems to work for now. Doing some tests before uploading the current source code.

Implemented and tested it successfully. Next step, before commit, is to retrieve only mounted drives as Windows provides all card reader drives (mounted or not).

Just for my understanding, would you do it like this or in some other way:

I know that everyone demands rsync or similar thing, but e.g. librsync depends on Cygwin and I try to avoid many dependencies. Still searching for alternative libs before rolling some sort of own implementation. OC doesn't need the network part of rsync, as Qt would be used to copy (or plain C++11), which should be portable. Also constrain OC to local drives (built-in oder removable ones) for now. Later OC would be sending data over local network (not internet, not for now at least), but this should be similar to the "local" workflow inside the application.

Also very helpful and valid things. The decoupling of Backup is progressing and I'll move parts of the current layout over to new OCBackup project (not commited yet).

Thanks for the input. For the "recopy" feature there were already plans to make something like one-way synchronization (see my last comment). I will evaluate it and other things you mentioned as soon as I've finished with decoupling OC modules (as Troy suggested).

As there weren't much updates lately here are the current tasks which i (slowly) work on.

My test was only related to Qt and PDF output, i've grabbed just the thumbnail view to get some output. Real one will be implemented soon, but other tasks like extended progress dialog and checksum have higher priority.

Did a little PDF export test for later transfer report feature. It was done quick, so i don't know about limitations so far, but what i've tried was sufficient for reports. One thing which is not clear to me yet is the resolution of output and how to calculate how many items fit on one page to generate next pages.

I've already considered to have one-way sync. OC would check what's already available at backup location, verify checksum to be really sure about the data and skip the files/items or at least ask the user what to do. There is already an "Overwrite" check box which is meant to bypass this check (not implemented yet).

Current work on data trasfer is progressing rather well, so i think that i would implement the hash check in the next days. Qt is really nice for such tasks: Reference: http://doc.qt.io/qt-5/qcryptographichash.html

Current state:

• Added removable drive recognition through QFileSystemWatcher, Linux only for now as it observes /media folder for changes, Windows and possibly OSX will follow
• After some discussions CinemaDNGDecoder project will be reactivated again (soon) to read meta data, as no real C++ lib for CinemaDNG headers was found, image data will still be retrieved by LibRaw for now

References:

• https://github.com/dropbox/librsync

Current State:

POCO will be removed from repository. QtCore has the necessary parts already included.

Currently removing controls from MainWindow and moving to clip manager or clip processor views as preparation for layout switching feature.

Raw version is done, not committed yet. Some points which aren't implemented at the moment:

• Scaling thumbnails down when view is resized
• Also scaling up when resized, both cases have to be evaluated first

• DONE: Rewrote with Qt classes, to minimize dependencies, POCO will be removed from repo soon

Merge the buttons in a separate control to have only one place to adjust behavior or appearance and to get events from. Maybe just one event which fires only if other button than currently selected was clicked and passes the index on to handler. This index could be used to switch the page in QStackedWidget-based layout (currently in development).

Notes:

• QStackedWidget will be used to switch between Manage/Process/Export parts of OC
• General layout concept is missing for this view at the moment, planning ongoing

Added POCO. Adjusted CMake files, but will be reworked later, e.g. right paths and file names for building in Windows. Set to "Resolved".

Small adjustment (disable/comment out "uninstall" target) has to be done in CMakeLists.txt, otherwise it collides with LibRaw "uninstall" one.

Updated LibRaw to latest version (commit 720cde83efa0fa7a5e953ec62aa8abfa75e2d756). Set to "Resolved".