Provide a stand-alone C++ API (binding) for ddcutil

[aryoda]

It would be great to have C++ API for ddcutil's C API that

• encapsulates all ddcutil's C API calls
• cares for correct allocation/deallocation of memory and handles (e. g. via smart pointers like unique_ptr and shared_ptr)
• is independent of Qt (e. g. uses only STL containers and can be compiled "stand-alone" therefore)

This would be a good basis for different front-ends and clients (e. g. using Gtk+ or another user paradigm).

Much work, I know (esp. finding a good API design).

Edit Nov 04, 2018: One more requirements

• The API must use STL containers, not Qt containers (Qt does not support unique_ptr since the overloaded copy constructors do not guarantee uniqueness): http://lists.qt-project.org/pipermail/interest/2013-July/007776.html). Good thing: No dependencies on Qt improves the re-usability of the API!
• The API shall be thread-safe and support async calls via multi-threading for a better user-experience

Edit Nov 11, 2018: More requirement regarding logging

• Add logging output possibilities
• Encapsulate the logging output calls and make them independent of any non-standard framework/library (e. g. don't use Qt for logging within the API)
• Allow to "plug-in" your own logging framework (e. g. from Qt)
• Use exceptions to encapsulate status return codes and reduce if cascades

Edit Nov 13, 2018: Added new requirement

• Support easy unit testing (e. g. mocking of physical displays)

[rockowitz]

Interesting idea.  I think it would make a great project for someone to take on as a contribution, as it doesn't entail delving into the (vast) ddcutil innards.

A couple thoughts.  For the experimental Python API implementations, it was natural to create a Python class wrapper. In part, this was to hide the low level details of the API calls. For the Qt UI, I felt no need to do this.  There's actually not a lot of memory management that goes on at the API level.  Once metadata is queried it is kept around forever (this would change if the ddcutil library supported dynamically connecting and disconnecting monitors).  Feature value access is encapsulated in a simple class that runs in a separate thread for each monitor, and the memory management is simple there as well.

Sanford

On 11/3/18 5:32 AM, aryoda wrote:

It would be great to have C++ API for ddcutil's C API that

• encapsulates all ddcutil's C API calls
• cares for correct allocation/deallocation of memory and handles (e. g. via smart pointers like |unique_ptr| and |shared_ptr|)
• is independent of Qt (e. g. uses only STL containers and can be compiled "stand-alone" therefore)

This would be a good basis for different front-ends and clients (e. g. using Gtk+ or another user paradigm).

Much work, I know (esp. finding a good API design).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/65, or mute the thread https://github.com/notifications/unsubscribe-auth/ANhsbqx3jkGhdASZGMZYQMa2KEy_XtLRks5urWLHgaJpZM4YMuC5.

[aryoda]

it would make a great project for someone to take on as a contribution

OK, I really would try to create a C++ (wrapper) API and (lack of) time is my only constraint ;-)

Since I am trying to implement a Qt-based UI that is focused on easy usability of the most frequent use cases incl. the must-have vendor-specific VCP codes as user configuration a C++ wrapper API could be a natural "spin-off".

My intended UI is different from your approach which is a perfect generic solution (similar to EnTech's softMCCS which is proprietary and for Windows only - see https://entechtaiwan.com/lib/softmccs.shtm).

My UI is yet just a "dream", I am still not "public" (at Github) yet - maybe never :-(

Feature value access is encapsulated in a simple class

Which class do you mean, I will have a look...

[rockowitz]

Comments interspersed.

On 11/3/18 8:16 AM, aryoda wrote:

it would make a great project for someone to take on as a contribution

OK, I really would try to create a C++ (wrapper) API and (lack of) time is my only constraint ;-)

Since I am trying to implement a Qt-based UI that is focused on easy usability of the most frequent use cases incl. the must-have vendor-specific VCP codes as user configuration a C++ wrapper API could be a natural "spin-off".

If there's some capability you need that the API doesn't provide, let me know.

My intended UI is different from your approach which is perfect generic solution (similar to EnTech's softMCCS which is proprietary and for Windows only - see https://entechtaiwan.com/lib/softmccs.shtm).

Hardly perfect.  The next ddcutil release contains a major code restructuring that lays the groundwork for user supplied definitions for the manufacturer specific features.  How to supply them is still up in the air.  Currently ddcutil reads files with a custom format. Perhaps YAML instead, and possibly an API.

One really nasty problem, from a UI perspective, that I don't have an solution for is that the settings shown in the UI don't match the actual monitor settings.  I've seen situations where  changing a setting, e.g. red level, in the GUI affects the monitor, but the monitor still reports the old value.  Conversely, I've seen cases where there's no apparent change in the monitor, yet it reports the newly set value.

My UI is yet just a "dream", I am still not "public" (at Github) yet - maybe never :-(

Feature value access is encapsulated in a simple class

Which class do you mean, I will have a look...

Still ugly, but take a look at ddcui files src/nongui/vcpthread.cpp/h

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/65#issuecomment-435583343, or mute the thread https://github.com/notifications/unsubscribe-auth/ANhsbpqACYjx_0Umxd4yPETevn1okvEOks5urYkQgaJpZM4YMuC5.

[aryoda]

I have created a first (very-early) proposal for an API interface for just the "public" layer of an object-oriented ddcutil wrapper API.

This is just a string point to add more layers or implementation details later.

My goal is just to offer the possible settings to a client via an API that could be implemented in any OO language like C++, Python etc.

Therefore you will not find technical data types of the ddcutil C API.

Note that getter/setter methods, public/private visibilities and filtered links are also not yet modelled completely.

I am asking for comments (wrong or strange names, missing or superfluous attributes or operations, things difficult to understand...).

PS: I have used the Umbrello UML Modeler (https://umbrello.kde.org/) to create this class diagram. I could send the file too on demand...

Edit: 04.11.2018: Renamed enum classes to get rid of "VCP"

[aryoda]

FYI: I have created a new Github repo to publish the UML models and the source code of my experimental implementation (still work in progress)...:

https://github.com/aryoda/ddcutil-cpp-API

[rockowitz]

I'm still seeing only the .gitignore, LICENSE, and README.md files at ddcutil-cpp-API.

Sanford

On 11/17/2018 11:31 AM, aryoda wrote:

FYI: I have created a new Github repo to publish the UML models and the source code of my experimental implementation (still work in progress)...:

https://github.com/aryoda/ddcutil-cpp-API

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/65#issuecomment-439629534, or mute the thread https://github.com/notifications/unsubscribe-auth/ANhsbr8jE49HYXpMmfTIGkdXoMaFNL47ks5uwDnygaJpZM4YMuC5.

[qht1003077897]

I'm still seeing only the .gitignore, LICENSE, and README.md files at ddcutil-cpp-API. Sanford … On 11/17/2018 11:31 AM, aryoda wrote: FYI: I have created a new Github repo to publish the UML models and the source code of my experimental implementation (still work in progress)...: https://github.com/aryoda/ddcutil-cpp-API — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#65 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/ANhsbr8jE49HYXpMmfTIGkdXoMaFNL47ks5uwDnygaJpZM4YMuC5.

yes,ha,hope mixed with disappointment

[aryoda]

yes,ha,hope mixed with disappointment

Yes, I had to prioritize how to "invest" my small spare time into open source projects and the C++ API did loose ;-)

Any contributions welcome :wink: