search

rockowitz / ddcutil

Control monitor settings using DDC/CI and USB
http://www.ddcutil.com
GNU General Public License v2.0
962 stars 39 forks source link

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

Open aryoda opened 5 years ago

aryoda commented 5 years ago

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

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

Edit Nov 11, 2018: More requirement regarding logging

Edit Nov 13, 2018: Added new requirement

rockowitz commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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"

vcp api layer proposal v0 2

aryoda commented 5 years ago

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 commented 5 years ago

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 commented 6 months ago

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 commented 6 months ago

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: