Seite 6 von 10

Re: Graphische Oberfläche

Verfasst: So Jul 24, 2011 4:13 pm
von fat-lobyte
Erledigt: http://www.proggen.org/forum/viewtopic. ... 118#p22118
Ich kann Dedupe als ganzes noch nicht kompilieren, da meine Boost-Bibliotheken veraltet sind.
Oh je :-(
Das wird kompliziert. Da hatten wir mit Xin schon ziemlich viel stress. Am besten wäre es, wenn du deine Boost-Bibliotheken ganz deinstallierst. Oder irgendwie aus irgendwelchen alternativen Quellen neuere beziehst. Aber sowohl Xin, als auch Kerli hatten probleme damit CMake eine neuere Boost-Version beizubringen, wenn eine alte bereits installiert ist.
Das ist mir ziemlich egal, für später wäre es praktisch die Oberfläche über einen CMake-Flag (-DQTGUI=ON oder so iwie) auswählen zu können. Mir ist aber beides recht.
Geworden ist is DEDUPE_BUILD_QT, und standardmäßig ist sie auf OFF.

Re: Graphische Oberfläche

Verfasst: So Jul 24, 2011 5:21 pm
von nufan
fat-lobyte hat geschrieben:Erledigt: http://www.proggen.org/forum/viewtopic. ... 118#p22118
Ich kann Dedupe als ganzes noch nicht kompilieren, da meine Boost-Bibliotheken veraltet sind.
Oh je :-(
Das wird kompliziert. Da hatten wir mit Xin schon ziemlich viel stress. Am besten wäre es, wenn du deine Boost-Bibliotheken ganz deinstallierst. Oder irgendwie aus irgendwelchen alternativen Quellen neuere beziehst. Aber sowohl Xin, als auch Kerli hatten probleme damit CMake eine neuere Boost-Version beizubringen, wenn eine alte bereits installiert ist.
Ich hab mir die Bibliotheken aus dem SVN-Repository besorgt. CMake findet sie auch, aber make gibt beim Erstellen der kernel-Bibliothek einige undefined references aus...

Re: Graphische Oberfläche

Verfasst: So Jul 24, 2011 5:27 pm
von fat-lobyte
dani93 hat geschrieben:Ich hab mir die Bibliotheken aus dem SVN-Repository besorgt. CMake findet sie auch, aber make gibt beim Erstellen der kernel-Bibliothek einige undefined references aus...
Ja, genau das meinte ich. Boost verwendet zwar die Header aus der neuen Bibliothek, aber dafür die Libs aus der alten. Da sind die Filesystem v3 - Funktionen noch nicht drinnen.

Re: Graphische Oberfläche

Verfasst: So Jul 24, 2011 5:33 pm
von nufan
fat-lobyte hat geschrieben:
dani93 hat geschrieben:Ich hab mir die Bibliotheken aus dem SVN-Repository besorgt. CMake findet sie auch, aber make gibt beim Erstellen der kernel-Bibliothek einige undefined references aus...
Ja, genau das meinte ich. Boost verwendet zwar die Header aus der neuen Bibliothek, aber dafür die Libs aus der alten. Da sind die Filesystem v3 - Funktionen noch nicht drinnen.
Oh, ich hatte noch die filesystem-Bibliothek der Paketverwaltung installiert ^^ Diese hab ich entfernt, jetzt funktioniert alles :)

Re: Graphische Oberfläche

Verfasst: Di Nov 08, 2011 1:18 pm
von fat-lobyte
So, ich habe ein paar Änderungen an den

  • Dedupe::GUI::Markable ist eine Abstrakte Basisklasse, hat also Virtuelle Funktionen. Somit sind auch alle abgeleiteten Klassen virtuell und brauchen einen Virtuellen konstruktor. (Sonst wird beim delete eines Basiszeigers der Abgeleitete Destruktor nicht aufgerufen!). Das habe ich gemacht.
  • Irgendwo hat sich ein Semikolon nach einer Funktionsdefintion eingeschlichen. Das braucht man nicht.
  • Unbenutzte Funktionsparameter auskommentiert
  • Unbenutzte Variable entfernt.
Allerdings gibt es ein paar Probleme, die ich nicht geändert habe: http://www.bugs.proggen.org/show_bug.cgi?id=16

mfg, fat-lobyte

Re: Graphische Oberfläche

Verfasst: Fr Apr 06, 2012 2:57 pm
von nufan
*Push* ^^

Irgendwie passt mir das Bibliotheks-unabhängige Interface überhaupt nicht... Zur Erinnerung (und Kontrolle, ob ich das richtig verstanden habe):
GetAction() wartet auf einen Event und gibt einen entsprechenden Event-Code (siehe Dedupe::GUI::MainAction) zurück. Das mag für die NCurses-Oberfläche ganz praktisch sein (obwohl sie dieses Verhalten selbst nicht implementiert?!), aber für grafische Frameworks wie Qt und vermutlich auch wxWidgets ist das sehr schlecht. Wenn ich in der GetAction()-Methode den Thread blockiere, wird auch das Framework-interne Event-Handling blockiert. Die grafische Oberfläche kann man auch nicht auf einen anderen Thread auslagern.
Mein Vorschlag wäre es dieses Konzept komplett zu ändern. Das Interface erhält Bibliotheks-unabhängige Methoden wie OnAppend(), OnRemove() usw. Diese Methoden werden vom Event-Handling der jeweiligen Implementierung aufgerufen.

Meinungen?

Re: Graphische Oberfläche

Verfasst: Fr Apr 06, 2012 3:55 pm
von Bebu
Dieses Interface ist sowieso veraltet. Es ist längst ein neues eingebaut. Du findest es im Source als kernel.h.

Code: Alles auswählen

#ifndef ORG_PROGGEN_DEDUPE_KERNELINTERFACE
#define ORG_PROGGEN_DEDUPE_KERNELINTERFACE

#include <fileinfo.h>
#include <hash.h>
#include <dataholding.h>
#include <boost/function.hpp>
#include <boost/bind.hpp>


namespace Dedupe
{
  namespace Core
  {

    /**
      *HandleDuplicates is used to say, what to do
      *with founded Duplicates
      */
    enum HandleDuplicates
    {
      Empty, ///Default value
      Keep, ///Keep file
      MarkAsKeep, /// Mark file as "keep" in the database
      Delete ///delete file from hdd
    };

    /**
      *DupHandle represents a single file, paired with a message, which says
      *to do with it.
      */
    typedef std::pair<Dedupe::FileInfo, HandleDuplicates> DupHandle;

    /**
      *DuplicateGroup represents Files with the same hash value
      */
    typedef std::vector<DupHandle> DuplicateGroup;

    /**
      *Duplicates represents all founded Duplicates, cleanly grouped to
      *process it to the user
      */
    typedef std::vector<DuplicateGroup> Duplicates;

    class Kernel
    {
      public:

      Kernel( Dedupe::FilePath DatabaseLocation, size_t Threads, std::ostream &Messages );

      /**
        *AppendFile appends the given file(s) or directory(ies) to the processed files
        *from dedupe. Those files will be used to find duplicates
        */
      void AppendFile( Dedupe::FilePaths const &Paths , bool recursiv  );

      /**
        *ListDatabase writes all Files that are stored in the database
        *to the message stream
        */
      void ListDatabase();

      /**
        *RemoveFile deletes the given file(s) or dirtory(ies) from the
        *processed files of dedupe.
        */
      void RemoveFile( Dedupe::FilePaths const &Paths, bool recursiv );

      /**
        *FindDuplicates searches for duplicates in the database
        *@return a Duplicates Vector. If the vector is empty no
        *duplicates are found
        */
      Duplicates FindDuplicates();

      /**
        *After Duplicates are decided by the user, give the
        *Duplicates back to the kernel, which will be process
        *like the user decided.
        */
      void ProcessDuplicates( Duplicates Dups );

      /**
        *Call this function to update the database. Should be called
        *after programstart to read in all changes from files on hdd.
        */
      void AutoUpdateDatabase();

      /**
        *The kernel runs in it's own thread, so call this function when
        *the program should end. The kernel finishs it's work stores true
        *in the given bool variable and then kill himself.
        *THIS FUNCTION IS INCOMPLETE YET
        */
      void QuitKernel( bool &AmIDead );

      private:

      void AddFile( Dedupe::FileInfo &Info );

      void FileAndDirectoryHandler( Dedupe::FilePaths const &Paths,
                      bool recursiv,
                      boost::function<void ( Dedupe::FileInfo& )>Function );

      template<class T> void Threadcontroller( T FunctionPointer, Dedupe::FileStream &stream );


      Dedupe::Dataholding::Dataholding Database;
      size_t Threadcount;
      Dedupe::FileSearch::SearchFiles Searcher;

      Dedupe::Hash::Hash64 Hasher;

      std::ostream &MessageOut;

    };

  }
}

#endif

Re: Graphische Oberfläche

Verfasst: Fr Apr 06, 2012 3:57 pm
von Xin
dani93 hat geschrieben:Wenn ich in der GetAction()-Methode den Thread blockiere, wird auch das Framework-interne Event-Handling blockiert.
Narf... ja, verstehe... meine große GUI-Zeit war woanders... da fragte man die GUI, was man als nächstes tun sollte, heute ruft die GUI einfach Methoden auf.
dani93 hat geschrieben:Mein Vorschlag wäre es dieses Konzept komplett zu ändern. Das Interface erhält Bibliotheks-unabhängige Methoden wie OnAppend(), OnRemove() usw. Diese Methoden werden vom Event-Handling der jeweiligen Implementierung aufgerufen.

Meinungen?
Von meiner Seite (NCurses) Go.

Wir haben aber noch Bebu, der die Kommandozeilenversion gemacht hat, aber afair sowieso anders... Bebu, wir müssen mal reden ;)

PS: Da haben wir's ja schon :-)

Re: Graphische Oberfläche

Verfasst: Fr Apr 06, 2012 5:33 pm
von nufan
Bebu hat geschrieben:Dieses Interface ist sowieso veraltet. Es ist längst ein neues eingebaut. Du findest es im Source als kernel.h.
Ähm... blöde Frage: Wo ist da das Interface?! Die einzige Klasse "Kernel" sieht mir eher nach Model aus, ich will aber ein Interface für den View.

Re: Graphische Oberfläche

Verfasst: Fr Apr 06, 2012 10:58 pm
von Bebu
Mhh, ich stehe gerade etwas auf dem Schlauch. Du startest ein Kernelobjekt, startest deine GUI und rufst von da aus die Kernelfunktionen auf. Du bekommst dann vom Kernel einen Duplikates Vektor, verarbeitest ihn und gibst ihn dem Kernel zurück. Wie du die Daten innerhalb der GUI verarbeitest, ist dann völlig deiner Fantasie überlassen.

Diese Zeile soll sich noch einmal verändern von

Code: Alles auswählen

typedef std::pair<Dedupe::FileInfo, HandleDuplicates> DupHandle;
auf

Code: Alles auswählen

typedef std::pair<const Dedupe::FileInfo, HandleDuplicates> DupHandle;
Außerdem ist noch geplant den Konstruktor von Kernel so umzugestalten, das sich die Anzahl der Threads, der Nachrichtenstream und der Datenbankspeicherort zur Laufzeit verändern lassen. Das kommt aber erst dann, wenn ich das Multithreading in Angriff nehme.