Создаю библиотеку для работы с последовательными портами. [УШЕЛ ИЗ ПРОЕКТА].

[lit-uriy]

>>Открыл у себя Git GUI и склонировал репозиторий в D:/git/ng
у тебя же уже есть клон, с ним и работай

[kuzulis]

Вроде сделал:
1. Зашел + залогинился на gitorious
2. Скопировал адрес:

git@gitorious.org:qserialdevice/qserialdevice.git

3. Открыл у себя Git GUI и склонировал репозиторий в:

D:/git/t

4. Сделал:

> git checkout --orphan 2.0-t

5. Сделал:

> git rm -rf *

6. Сделал:

> git commit -a

7. Создал файлы исходных кодов проекта *.h/*.cpp и скопировал их в

D:/git/t

8. Сделал:

> git add *

9. Открыл Git GU (ветку 2.0-t), сохранил изменения с коммитом: "Determination of the initial project structure."
10. Сделал:

> git checkout --orphan 2.0 2.0-t

11. Сделал:

> git branch -D 2.0-t

12. Открыл Git GU (ветку 2.0), сохранил изменения с коммитом: "Determination of the initial project structure."
13. Сделал:

> git push origin 2.0:refs/heads/2.0

1)
Теперь определимся с структурой самого проекта:
- файлы исходников будут в корне проекта или раскиданы по каталогам?
- нужны или нет всякие "реадми", "чейнчлоги"?
и.т.п

2.)
Как теперь коммитить в ветку 2.0?
Интересует алгоритм от клонирования, до редактирования, сохранения и отправки изменений.

[pastor]

1)

Можно такую структуру каталогов:

include
examples
src
<project_name>.pro
CHANGES
README
INSTALL

2)
Предлагаю работать не напрямую с репозиторием, а посредством мердж-реквестов

[lit-uriy]

2)
Как теперь коммитить в ветку 2.0?
Интересует алгоритм от клонирования, до редактирования, сохранения и отправки изменений.

также как ты работал с мастером.

[b-s-a]

Поддерживаю пастора
так же рекомендую делать проект типа subdirs (т.е. с подпроектами).

[b-s-a]

Я тут еще раз посмотрел на интерфейс. И мне пришла мысль отказаться от свойства portName.
И так. Предлагаю сделать 3 метода:
void setPort(const QString &portName);
void setPort(const SerialPortInfo &info);
QString portName() const;

portName возвращает всегда "COM1", "ttyS0" и т.п.
а вот setPort принимает и короткое название порта, и системный путь. Да и не перепутаешь setPort и setPortName.

[kuzulis]

Насчет структуры проекта: так пойдет?

/
|->/src
|     |-> /serialport
|     |           |-> *.h/*.cpp/*.pri
|     |->/serialportinfo
|     |           |-> *.h/*.cpp/*.pri
|     |->src.pro
|->/examples
|->serialport.pro //<< Или как-то иначе?
|->CHANGES
|->README
|->INSTALL

Я тут еще раз посмотрел на интерфейс. И мне пришла мысль отказаться от свойства portName.
И так. Предлагаю сделать 3 метода:
void setPort(const QString &portName);
void setPort(const SerialPortInfo &info);
QString portName() const;

portName возвращает всегда "COM1", "ttyS0" и т.п.
а вот setPort принимает и короткое название порта, и системный путь. Да и не перепутаешь setPort и setPortName.

Так я не понял, а setPortName() где тогда будет? Или его не будет?

2)
Предлагаю работать не напрямую с репозиторием, а посредством мердж-реквестов

А это как? Желательно по пунктам

[b-s-a]

Насчет структуры проекта: так пойдет?

Поменьше подкаталогов. Лучше как сказал пастор: /include - публичные хидеры
/src - приватные хидеры и реализация
/examples - примеры
/tests - юнит-тесты

Я тут еще раз посмотрел на интерфейс. И мне пришла мысль отказаться от свойства portName.
И так. Предлагаю сделать 3 метода:
void setPort(const QString &portName);
void setPort(const SerialPortInfo &info);
QString portName() const;

portName возвращает всегда "COM1", "ttyS0" и т.п.
а вот setPort принимает и короткое название порта, и системный путь. Да и не перепутаешь setPort и setPortName.

Так я не понял, а setPortName() где тогда будет? Или его не будет?

Именно - не будет. Иначе пользователь вводится в заблуждение - есть методы setPort и setPortName. Который из них надо использовать? Я бы выбрал первый и долго геморроился.

2)
Предлагаю работать не напрямую с репозиторием, а посредством мердж-реквестов

А это как? Желательно по пунктам

Для тебя никаких отличий. Т.е. как работал, так и будешь. А все остальные будут только делать мержреквесты.

[kuzulis]

1.

Лучше как сказал пастор: /include - публичные хидеры

Ну так в исходном виде эта директория должна содержать только
файлы типа: SerialPort (Или QSerialPort ?) и SerialPortInfo (Или QSerialPortInfo ?).
Содержимое которых соответственно:

SerialPort

Код

C++ (Qt)
#include "serialport.h"
 

SerialPortInfo

Код

C++ (Qt)
#include "serialportinfo.h"
 

Но она по идее не должна изначально содержать самих хидеров  "serialport.h" "serialportinfo.h".
Эти хидеры, по идее, должны автоматом копироваться в каталог /include после того как библиотека собралась.
Т.е. они должны изначально находится только в /src, а потом и в /include

А то, если бы они были только в /include - то как-то сбивается аналогия с Qt и/или с Qxt библиотеками.

2. Если уж делаем новую версию библиотеки "затачиваемую" под интеграцию в Qt, то нужно, скорее всего,
определиться как будет называться модуль (Например QtSerial, по аналогии с QtNetwork) ?

3. Нужно ли патчить qmake и т.п. ? Чтобы можно было в конфиге проекта написать типа: QT += serial

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

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


ЗЫ: Или я рано еще об этом?

 

[b-s-a]

ЗЫ: Или я рано еще об этом?

Именно. Что патчить и как оформлять - это будут решать тролли. Для начала, нужно сделать, чтобы работало.

[kuzulis]

Ну а насчет каталога /include : я тогда просто его создам и оставлю пустым (если в git это возможно), а все заголовки помещу в /src

[b-s-a]

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

[asvil]

А что случиться если включить что-нибудь приватное? Считаю это придумыванием несуществующих проблем.
Но таки папка include удобна, особенно если наполнить ее непосредственно заголовочниками. Зачем ее создавать пустую?

[kuzulis]

Ок.

1.
Теперь перейдем к АПИ приватных классов.
Я тут для SerialPortPrivate ориентировочно набросал АПИ:

Код

C++ (Qt)
/*
    License...
*/
 
#ifndef SERIALPORT_P_H
#define SERIALPORT_P_H
 
#include "serialport.h"
 
#if defined (Q_OS_WIN)
#  include <qt_windows.h>
#else
#  include <termios.h>
//#  include "../unix/ttylocker.h"
#endif
 
 
class SerialPortPrivate
{
public:
    SerialPortPrivate();
    virtual ~SerialPortPrivate();
 
    void setNativePort(const QString &port);
    QString nativePort() const;
 
    bool nativeOpen(QIODevice::OpenMode mode);
    void nativeClose();
 
    bool nativeSetRate(qint32 rate, SerialPort::Directions dir);
    qint32 nativeRate(SerialPort::Directions dir) const;
 
    bool nativeSetDataBits(SerialPort::DataBits dataBits);
    SerialPort::DataBits nativeDataBits() const;
 
    bool nativeSetParity(SerialPort::Parity parity);
    SerialPort::Parity nativeParity() const;
 
    bool nativeSetStopBits(SerialPort::StopBits stopBits);
    SerialPort::StopBits nativeStopBits() const;
 
    bool nativeSetFlowControl(SerialPort::FlowControl flow);
    SerialPort::FlowControl nativeFlowControl() const;
 
    void nativeSetDataInterval(int usecs);
    int nativeDataInterval() const;
 
    void nativeSetReadTimeout(int msecs);
    int nativeReadTimeout() const;
 
    bool nativeDtr() const;
    bool nativeRts() const;
 
    SerialPort::Lines nativeLines() const;
 
    bool nativeFlush();
    bool nativeReset();
 
    void nativeSetDataErrorPolicy(SerialPort::DataErrorPolicy policy);
    SerialPort::DataErrorPolicy nativeDataErrorPolicy() const;
 
    SerialPort::PortError nativeError() const;
    void nativeUunsetError();
 
    qint64 nativeBytesAvailable() const;
 
    qint64 nativeRead(char *data, qint64 len);
    qint64 nativeWrite(const char *data, qint64 len);
 
    int nativeSelect(int timeout, bool checkRead, bool checkWrite,
                     bool *selectForRead, bool *selectForWrite);
 
private:
    //General (for any OS) private parameters
    QString mPort;
    qint32 mInRate;
    qint32 mOutRate;
    SerialPort::DataBits mDataBits;
    SerialPort::Parity mParity;
    SerialPort::StopBits mStopBits;
    SerialPort::FlowControl mFlow;
    int mDataInterval;
    int mReadTimeout;
    SerialPort::DataErrorPolicy mPolicy;
    SerialPort::PortError mError;
 
    //General (for any OS) private methods
    void initVariables();
 
    void detectDefaultRate();
    void detectDefaultDataBits();
    void detectDefaultParity();
    void detectDefaultStopBits();
    void detectDefaultFlowControl();
    void detectDefaultCurrentSettings();
 
    bool prepareOtherOptions();
 
    bool saveOldSettings();
    bool restoreOldSettings();
 
    //OS specific parameters and methods
#ifdef Q_OS_WIN
 
    enum CommTimeouts {
        ReadIntervalTimeout, ReadTotalTimeoutMultiplier,
        ReadTotalTimeoutConstant, WriteTotalTimeoutMultiplier,
        WriteTotalTimeoutConstant
    };
 
    DCB mDCB, mOldDCB;
    COMMTIMEOUTS mCommTimeouts, mOldCommTimeouts;
    OVERLAPPED mOvRead;
    OVERLAPPED mOvWrite;
    OVERLAPPED mOvSelect;
 
    bool createEvents(bool rx, bool tx);
    bool closeEvents() const;
    void recalcTotalReadTimeoutConstant();
    void prepareCommTimeouts(CommTimeouts cto, DWORD msecs);
    bool updateDcb();
    bool updateCommTimeouts();
#else
    struct termios mTermios;
    struct termios mOldTermios;
    void prepareTimeouts(int msecs);
    bool updateTermious();
    bool setStandartRate(AbstractSerial::BaudRateDirection, speed_t rate);
    bool setCustomRate(qint32 rate);
#endif
 
};
 
#endif // SERIALPORT_P_H
 
 

И вот вопрос: может быть лучше создать абстрактный класс типа AbstractSerialPortPrivate
который бы содержал общие данные и общие методы для любой ОС.
Некоторые из них можно реализовать прямо в абстрактном AbstractSerialPortPrivate
(например, nativeRate(), nativeParity() и т.п.), а остальные сделать чисто виртуальными.

А уже класс SerialPortPrivate наследовался бы от AbstractSerialPortPrivate.

Тем самым, мы в объявлении SerialPortPrivate уменьшаем кол-во писанины (да и в реализации тоже),
но у нас тогда появляется дополнительный класс AbstractSerialPortPrivate, для которого нужно создать два файла *.h/*.cpp .

Или, может быть, есть более изящное решение?

2.
Кто нить накидает АПИ для SerialPortPrivateInfo?
А то я не соображу.

А что случиться если включить что-нибудь приватное? Считаю это придумыванием несуществующих проблем.
Но таки папка include удобна, особенно если наполнить ее непосредственно заголовочниками. Зачем ее создавать пустую?

Ок.

----
Еще прикрепил аттач с архивом предварительной конфигурации проекта и т.п.

[b-s-a]

На мой вгляд лучше делать именно через абстрактный класс. Причем, для него достаточно сделать только хидер - все методы пусть инлайнятся. Название его оставить SerialPortPrivate. А вот конкретные реализации - SerialPortPrivateWin/Unix.
А разве мьютекс не нужен?
слово native обязательно надо у каждого метода писать? Я бы понял, если бы это были защищенные абстрактные методы, которые вызываются публичными, но в таком виде смысле не вижу - лишняя писанина.
Что за "SerialPortPrivateInfo"? Должен же быть "SerialPortInfoPrivate", вроде. Разве нет? А потом, его состав полностью идентичен набору свойств публичного класса:

Код

C++ (Qt)
struct SerialPortInfoPrivate
{
   QString device;
   QString portName;
   QString manufacturer;
   virtual bool isValid() = 0;
};