[web] Enhancing Flutter Web's text editing system by using Platform Views

Objective
One of our core goals is to make Flutter Web feel more idiomatic and natural on the web. A key part of this is to align the behavior of our text inputs to be more consistent with how text inputs behave on the web. This has major implications given how many impactful features branch out of a simple text box (spellcheck, autofill, etc) that web users are conditioned to expect to work.  So when text inputs don’t work on Flutter Web apps exactly the way they do elsewhere on the web, it has a glaring impact on UX.
Problems
Clashing styles
We currently delegate all of the rendering of text inputs to the framework rather than the browser.

When an <input> element is created, we apply CSS to make these elements and aspects of these elements (content, selection caret, selection highlight, etc) invisible.  By resetting the browser’s default styling, we enable Flutter to have full control over the look and feel of our text inputs.
This has the potential to cause some issues via a “clashing” of styles.  The styles used to hide our text inputs don’t always work consistently across every combination of browsers and platforms, which can lead to strange rendering behavior.  For example, in https://github.com/flutter/flutter/issues/99918, iOS Safari does not support ::selection pseudoelement styles, which is the method we use to make browser selection transparent. This leads to a clash of styles that creates two overlapping selections, which makes inputs not feel quite right in Flutter Web apps on iOS Safari.

Lazily rendered inputs
We don’t render <input> elements immediately.  They are created “as needed” when the user initially focuses on any given text input.  They also cease to exist when you blur.

This causes some complexity with autofill functionality. Without all of the inputs rendered immediately, we can’t leverage the browser’s native behavior to autofill multiple inputs on a page.  Custom logic has been added to enable autofill to work in Flutter apps today.
Recreating the browser-native autofill behavior is no simple task.  This added complexity can create difficulties in the maintenance and debugging of autofill issues.

Related issues

https://github.com/flutter/flutter/issues/77076
https://github.com/flutter/flutter/issues/94130
https://github.com/flutter/flutter/issues/99918
https://github.com/flutter/flutter/issues/70841
https://github.com/flutter/flutter/issues/118337

Solution
The above problems highlight an interesting relationship between Flutter and the browser.  In some instances, we are fighting against the browser (e.g. hiding <input> els) and in other instances we’re adding a lot of complexity to our text editing system in order to enable browser-native behavior to work (autofill).
An alternative approach might be to work with the browser to leverage its native behavior as much as we can within the context of Flutter apps.
Platform Views
One way this could be accomplished is by using platform views.  Platform views allow you to embed native views in a Flutter app.  In the context of Flutter Web, we could use platform views to eagerly render <input> elements.
Additionally, we would need the browser to take responsibility from the framework for the styling of certain aspects of the input:

Content
Selection highlight
Selection caret
Context menus / mobile toolbars

Benefits

By aligning the functionality of our text inputs more closely with the browser, we can better achieve idiomatic behavior of Flutter Web text inputs and all of the baked-in features that browsers provide for these inputs.
We can greatly simplify our codebase (especially in engine) by leveraging pre-existing browser features (e.g. autofill) rather than trying to recreate them.  A simplified codebase can help us improve our velocity, maintain our code more effectively, and debug issues more efficiently.
We can fix browser-specific rendering issues for text inputs, some of which have no known workarounds in our current system.  By delegating the styling of content, carets, selections, and context menus to the browser, we can achieve a more native experience on a multitude of platforms.

Tradeoffs

The framework does a great job of giving devs the ability to customize text inputs, potentially to a greater degree than the browser allows.  Delegating styling responsibilities to the browser comes at the expense of losing this greater degree of customizability.

Potential issues / Unknowns

Platform views are performance-optimized and will disappear outside of the viewport.  If <input> elements disappear outside of the viewport, this will break autofill functionality.
Could platform views cause performance issues in CanvasKit due to interleaving of <input>elements between <canvas> sheets? Is a page with many inputs feasible when taking into account this performance cost?
Can we rewrite the text editing system in a way that continues to integrate well with the Framework’s code philosophy of being platform-agnostic?
How will this work when semantics are enabled? Will this solution play well with semantics mode?
Password autofill is currently broken for inputs within the shadowDOM in Chrome - but platform views need to be rendered within <slot>s and have to exist in the shadowDOM

This would be a major departure from Flutter's current approach.  You would lose Flutter's pixel-perfect rendering across platforms for text fields, and there would be a lot of work (and new ongoing bug reports) involved in trying to make it match as closely as possible.
I wonder how you might implement this in the framework side?  Maybe by recreating TextField, CupertinoTextField, and EditableText in your PlatformView and then dropping web support for everything lower-level than that (RenderEditable etc.).  Most Flutter users probably rarely go that low level, but it would break text editors like super_editor.  I'm not 100% familiar with how Flutter web currently handles this low level text editing stuff though, so fill me in if you have more ideas.
One possible argument in favor of using PlatformViews is issue https://github.com/flutter/flutter/issues/103163 on the iOS side of things.  Similarly to some of the points you made above, I currently have no good idea about how Flutter could solve that issue with our current Flutter-rendered approach.  CC @hellohuanlin.
I suppose to have the ability to make a decision on this, we might want to see a comparison of what things are not possible or feasible for Flutter to ever support with our current approach, and what things would we be giving up by using PlatformViews (maybe cross-platform support for everything below RenderEditable, etc.).
The fact that we would be moving away from one of Flutter's key advantages (fully controlled rendering) and taking an approach more like other frameworks like React Native makes me very wary of this idea.  However, if it's true that we are fighting a losing battle here, and there are important web features that Flutter is just never going to be able to support with our current approach, then maybe it's time we recognize our limitations and pivot.
CC @HansMuller @Renzo-Olivares @LongCatIsLooong
Oh and by the way, there are some Pub packages that attempt to do text input via PlatformViews (on other platforms at least) such as: https://pub.dev/packages/flutter_native_text_input.

@justinmc Do we have anything documented about the need to be pixel perfect across platforms? AFAIK we are not pixel-perfect because we use different fonts on different platforms, so pixel-perfection ship has sailed. I haven't done UX research on this, but my gut feeling is that it is more important for text fields to feel natural to each platform, and because text fields behave differently across platforms, it also means they should be different. We just need to carefully choose in what ways they should be different.
@htoor3 Do you think https://github.com/flutter/flutter/issues/58498 can also be fixed using the platform view design?

Also https://github.com/flutter/flutter/issues/40682

Thank you for your thoughts on this @justinmc! You are right; losing complete control of the rendering behavior is definitely the biggest tradeoff here.
However, it's arguable that the pattern of issues that keep arising due to our current system are having a greater negative impact on Flutter Web users than losing out on this pixel perfect control.  Some of these issues have no feasible solutions due to the quirks and behaviors of certain platform + browser combinations.
I've noticed this a lot with input rendering issues on iOS + Safari - sometimes Safari just doesn't support certain CSS specs and we're left with the choice of accepting poor UX for users in those cases or expending significant resources to find a viable workaround.  Oftentimes those workarounds add complexity to our codebase, which has negative longterm implications.

@justinmc thanks for bringing up super_editor as an example. I looked into it and they aren't using any of our text editing widgets or render objects. They only use TextInputConnection and TextInputClient to communicate with the engine. This means 2 things:

When we have a new web-specific implementation of EditableText using platform views, super_editor won't be affected.
We can't drop support for text input connections (i.e. setClient, setEditingState, etc).

As you said, most users go with EditableText or something higher level, so they'll get the new platform-view-based implementation for free with no breaking changes (except the fields will look slightly different). For the rare cases that need the low level input connection API, we can keep supporting them but we can simplify things a lot (e.g. remove the complex autofill support since these cases are usually doing rich text editors that don't need autofill anyway).
This proposal will allow us to play nicely with the browser and avoid a lot of hacks; and solve many issues that are unsolvable today.

Thank you all for the discussion here!  I don't think there's any killer requirement about pixel perfection down to the font level, it's just trading one set of bugs/weaknesses for another.  We'll fix the native fidelity bugs listed above, but we'll gain some related to inputs working/looking differently between platforms.  It seems like many of the problems we'd solve are severe and unfixable with the current architecture, and if the ones we'd gain are not, then that's a strong argument in favor of making the switch.
Maybe the next step is to write a proposal for how this might be implemented.  Then we could see more clearly what the limitations will be.
Also, +1 to keeping support for low-level text editing on web for advanced used cases!

Ideally we can avoid everyone needing to do something like this:
  // When I want a TextField that looks the same on all platforms.
  @override
  Widget build(BuildContext context) {
    if (kIsWeb) {
      return TextField(
        // <my text field configuration that makes up for platform differences>
      );
    }
    return TextField(
      // <my text field configuration for everything else>
    );
  }

As someone developing Web apps using Flutter and also maintaining a rich text editor plugin for Flutter (Fleather), I don't find using Platform View replacing Flutter's TextField a good idea.
If we are going to drop the whole text editing functionality on Flutter's side, a lot of projects would be killed.
If we are going to drop the TextField's widget and rendering only and keep the text editing infrustructure to keep projects like super_editor, fleather and others working as @mdebbar said, we would still face most of those issues (#40682, #103163, #134024, ...) and have to fix them thus facing the said complexities anyway.
I suggest to have a complete rewrite of text editing infrustructure to better handle complexities and work on fixes for those issues. @htoor3

@Amir-P I agree. I'm working on Flutter Web Apps, and it's been a long journey. A TextEditor is an absolute necessity to complete web apps, and it's something every developer desires. Unfortunately, Flutter is currently unable to provide this. A TextEditor with basic functionalities should be included as a core widget in Flutter. Furthermore, it needs a complete redesign from the ground up. Additionally, the characteristics of languages other than English, such as two-byte characters in Korean, Chinese, Japanese, etc., should be considered from the beginning. I hope this can be given the highest priority.

Thank you for raising these points @Amir-P and @Patrick386 and I'd love to understand some of these concerns further.
We've gone through a few iterations, and the idea that we're leaning towards is not to completely drop the TextField widget or a create a new EditableText for web, but rather integrate the platform view within the current system in a way that allows us to harmonize the strengths of the browser and the framework for web contexts.  We want to allow the browser to handle text rendering, selection, context menu, caret rendering, keyboard shortcuts - and continue to allow the framework to handle everything else (which includes rendering things around the content box).
Ideally, this can lead to a more expected text input user experience on Flutter Web apps.  The goal is to achieve text input UX parity with standard web apps - leveraging the browser would help with this. Autofill on page load (without explicitly focusing), password managers correctly working, spellcheck, selection on mobile, internationalization etc are all fundamental web experiences that this system would improve.  Not to mention all of the current difficult-to-solve bugs linked in this issue would have a solution.
On the flip side, we want these gains to be readily and painlessly available to Flutter devs and we're definitely keeping backwards compatibility and dev convenience in mind for the design - the last thing we want to do is break existing user apps. For devs, this means you can render a TextField or an AutofillGroup as before and get the above gains for free.
I'm not as familiar with the rich text editor ecosystem - what are your concerns and what do you think this system would break for existing projects? I would love to keep these in mind as we flesh out the design.

Thank you for raising these points @Amir-P and @Patrick386 and I'd love to understand some of these concerns further.
We've gone through a few iterations, and the idea that we're leaning towards is not to completely drop the TextField widget or a create a new EditableText for web, but rather integrate the platform view within the current system in a way that allows us to harmonize the strengths of the browser and the framework for web contexts. We want to allow the browser to handle text rendering, selection, context menu, caret rendering, keyboard shortcuts - and continue to allow the framework to handle everything else (which includes rendering things around the content box).
Ideally, this can lead to a more expected text input user experience on Flutter Web apps. The goal is to achieve text input UX parity with standard web apps - leveraging the browser would help with this. Autofill on page load (without explicitly focusing), password managers correctly working, spellcheck, selection on mobile, internationalization etc are all fundamental web experiences that this system would improve. Not to mention all of the current difficult-to-solve bugs linked in this issue would have a solution.
On the flip side, we want these gains to be readily and painlessly available to Flutter devs and we're definitely keeping backwards compatibility and dev convenience in mind for the design - the last thing we want to do is break current user apps or drastically change existing APIs. For devs, this means you can render a TextField or an AutofillGroup as before and get the above gains for free.
I'm not as familiar with the rich text editor ecosystem - what are your concerns and what do you think this system would break for existing projects? I would love to keep these in mind as we flesh out the design.

I understand, and it's highly ideal. It's great to hear that all the issues could be resolved. In that case, I believe there's no need to overly consider backward compatibility. Making too many concessions for compatibility might hinder embracing such a significant improvement. Many developers will recognize this and be willing to embrace it for greater benefits. I'd like to see it happen as soon as possible. There's no need to hesitate; executing and addressing the issues promptly is what's needed right now. Rich text editors are indeed different, and therefore, should be offered as a separate alternative. Thank you!

@htoor3 Thanks for your response and the proposal.
I believe there is some misunderstanding on my part. To clarify, I've summarized what I understood from your suggestion and outlined my concerns regarding them.
Based on your suggestion, the solution to the challenging issues we're currently facing, is to take advantage of Web's <input> element or iOS's UITextField instead of rendering our own input field. I can see how this would help with certain problems on Web or iOS, such as out-of-sync scrolling state on Web, paste button in context menu asking user permission issue on iOS, selection color on Web running on iOS and etc.
The primary objective of this significant change is to avoid the complexity of fixing these issues, simplify the codebase, and align our text input functionality with the browser's behavior.
However, considering custom rendering required by rich text editors, we won't be able to fully utilize native input elements, or at least they won't be visible and responsible for rendering, as is currently the case on the Web. So we're going to have those issues all over again and eventually, we're going to have to fix all those issues without taking advantage of native platform input elements and we're not going to have simplified codebase.
All this being said, I'm worried that the extensive effort required for this huge change, may result in even more complex codebase and slower and less prioritized bug fixes for cases not using EditableText.

Another issue this would solve: https://github.com/flutter/flutter/issues/138288

@htoor3 Thanks for your response and the proposal.
I believe there may be some misunderstanding on my part. To clarify, I've summarized what I understood from your suggestion and outlined my concerns regarding them.
Based on your suggestion, the solution to the challenging issues we're currently facing, is to take advantage of Web's <input> element or iOS's UITextField instead of rendering our own input field. I can see how this would help with certain problems on Web or iOS, such as out-of-sync scrolling state on Web, paste button in context menu asking user permission issue on iOS, selection color on Web running on iOS and etc.
The primary objective of this significant change is to avoid the complexity of fixing these issues, simplify the codebase, and align our text input functionality with the browser's behavior.
However, considering custom rendering required by rich text editors, we won't be able to fully utilize native input elements, or at least they won't be visible and responsible for rendering, as is currently the case on the Web. So we're going to have those issues all over again and eventually, we're going to have to fix all those issues without taking advantage of native platform input elements and we're not going to have simplified codebase.
All this being said, I'm worried that the extensive effort required for this huge change, may result in even more complex codebase and slower and less prioritized bug fixes for cases not using EditableText.

Apologies for getting to you late @Amir-P.  I think the concern that these benefits might not apply to RTEs is definitely a valid one.  However, I do think we need to prioritize plugging the leaky bucket that the current system is causing, because some of these issues are basic, expected, and standard text editing experiences.  Continuing to add patches to a system that's already working against the browser is turning into a losing battle, as we have no control over what updates are introduced on different platforms and browsers, and whether those updates might break the system we have in place (this has already happened a few times).  I will bring the RTE concerns to the team to see if we can discuss some kind of resolution or roadmap in place to support these use cases.

Text fields are one of the most problematic flutter parts. They are too integrated to environment on all platforms. I believe it will be better to use platform view for them as proposed. Every time when I need to solve error related to text fields I feel that I am fighting with platform. It may be better to move away from the original dogma of full screen control to achieve better integration.

I would like to express my sincere concerns and doubts regarding the lack of a definitive solution for a Rich Text Editor in Flutter Web, even after so much time. The Rich Text Editor is a basic function for any framework.
Currently, there are two popular alternatives for text editors in Flutter: quill_html_editor and html_editor_enhanced. However, as mentioned in the tutorial Rich Text HTML Editor for FlutterFlow Apps, the latest versions of these packages present significant incompatibilities with FlutterFlow.
This situation places developers in a delicate position, as the absence of an integrated Rich Text Editor is a major obstacle for developing applications with advanced text editing requirements, such as blogs, copywriting, and generative AI applications.
I would like to know if there is a specific plan or roadmap for a definitive Rich Text Editor solution in Flutter Web.
Thank you in advance for your attention and continuous work to improve the platform. I look forward to a solution that meets the needs of the entire developer community.
Best regards,

@SauloSA I think this is not the issue you are looking for.
Maybe this one might be what you are looking for https://github.com/flutter/flutter/issues/12675


Restyle the card-component class

We are trying to standardise how Cards are used in Rancher. As a part of that work, we want to restyle the current Card component (with class .card-container).
Currently, it is used in the following components:

In most of them, the box-shadow is removed.
The idea is to turn this component into a "content-block" or "panel" component without shadow or borders. If we ever need a panel to have borders, we can include an option.
Please check the Cards redesign Confluence page, especially the first section "Unnecessary cards" to see how those content blocks work without any border (or shadow).
Please document all changes for the design reviewer to check and adjust if necessary.

I'll create another ticket to tackle the unnecessary cards for Q3 and push this ticket out to Q4 since additional styling updates could be done at the same time and more testing is required.


testing datasets

Hi, thank you for your work！
will testing image degradation code be published in the future?

Hi, thanks for your attention to our work.
Do you mean the code for preparing the synthetic testing dataset?

yes！Is it possible for you to post the code for preparing testing dataset? Is there any reason why you haven't test on datasets such as set5 and set14？

I have uploaded the code for preparing the dataset, please check (in DASR/scripts). We have tested the performance on the Urban100 dataset, which shows similar observations to the results of DIV2K (We did not report the results for readability). You can synthetic the validation data and test the DASR by yourself if you are interested. Thanks.


update apache tika to 2.14.1 (from 1.23)

Description
This pull request updates apache tika libraries to fix multiple direct and indirect vulnerability warnings current version 1.23 has.
Motivation and Context
Open vunerability reports with old version  1.23 are the following. All of them are fixed updating to 1.24.1:

CVE-2019-14262 - indirect (dependency of tika-parsers), cvss 8.1
CVE-2019-17573 - indirect (dependency of tika-parsers), cvss 6.5
CVE-2020-1951 - direct, cvss 5.3
CVE-2020-1950 - direct, cvss 5.3
CVE-2020-9489 - direct, cvss 5.3

How Has This Been Tested?
gradlew check run succesful
Used tika-parsers 1.24 fo a longer time at our installation, 1.24.1 for some days without problems
Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist:

[x] My code follows the code style of this project.
[x] I have updated the documentation accordingly.

Thanks. The change LGTM

Thanks for your contribution


windows: Fix time string length retrieval

Hello.
I was thinking about how I can contribute to the project easily and without any difficulty, and I came up with the idea of having ChatGPT review libui-ng.
According to ChatGPT, there is a mistake here.
It may indeed be so.

Looks like a legitimate bug to me.
The GetLocaleInfoEx docs sadly do not state returned string on error is actually \0 terminated, so unsure if this would crash nonetheless on datetime = strf(L"%s %s", date, time);. But this patch definitely is an improvement and possibly all that is needed.

Looks like a legitimate bug to me.

Confirmed bug, checks ndate for error result twice instead of ntime.

Interesting. I did not know ChatGPT can be used for finding bugs. Can this also be applied to e. g. a codebase in (pure) ruby?


Unable to install on MacOS 10.14.6

Hello,
Attempting to install threadkeeper on 15inch touchbar macbook pro (late 2018)
After clicking on the package and letting it do its thing, I get the loading bar, then the cofiguring the install, then I get "The installation failed"
Any help would be great,
Thanks.
Fusion version 2.0.10253

Hi,
I'm not very used to Mac. I occasionally have had similar problems as you. Why it does not work, only someone better at Mac or Autodesk (who packages the installer) can say.
What I've done when the installer has failed:
Open a terminal and run:
sudo installer -pkg Downloads/addin_file.pkg -target /
(replace Downloads/addin_file.pkg with the correct pkg file path)
This command seems to have more privileges to install the add-in? I'm not sure if it is wise or not.
Alternative: Grab the release zip from github and install it, following this guide:
https://github.com/thomasa88/ThreadKeeper#installation
(PS. I have update the issue reporting link on the app store so users are no longer sent to the wrong project)

Closing old issue.


Adding maintainer relation

VIVO-Ontology GitHub issue: 28
What does this pull request do?
Add Maintainership subclass of Relationship for establishing maintainer relation between software and person
Interested parties
Tag (@ mention) interested parties or.

Discussion in https://wiki.lyrasis.org/display/VIVO/2024-09-18+Ontology+Interest+Group+Call:

Further investigations are needed on which level of granularity we want the software contributor roles to be.
If we decide on the few roles from codemeta we need to describe them and probably establish a hierarchy to enable future roles to be added at the correct place
one idea would be to have only one role with the possibility to add a label, which specifies the role. This is being the case for http://vivoweb.org/ontology/core#ResearcherRole already.


The flag "resultasstring" doesn't seem to work.

I would expect this to produce a list of all the test classes as comma separated, however, when running the command, I get the same table output:
sfdx sfpowerkit:source:apextest:list -p force-app --resultasstring
https://github.com/Accenture/sfpowerkit/blob/44f67a1224c73971210d82c360c93d22982160ea/src/commands/sfpowerkit/source/apextest/list.ts#L92

@dweaver33  we returning array or comma separated string to json output when you run the command with --json. happy to print the string in console in case of --resultasstring flag

@manisfdcsfdx, maybe we could give the option somehow?

@dweaver33 ya added a enhancement to print comma separated string oppose to table in case of --resultasstring

@dweaver33 you can check the fix in beta version. nov 2nd fix will be available in regular version.

@manisfdcsfdx, works great!  Thank you!


neko skips all updates "because at least one tracker has status of Unfollowed"

Steps to reproduce
update library
Expected behavior
it should update the library
(or tell me which trackers have status of Unfollowed)
Actual behavior
it skips updating all 174 entries in my library
the neko update log shows the error ! Skipped because at least one tracker has status of Unfollowed
not sure what that means but i checked and as far as i can tell none of the entries in my library have the tracker status of unfollowed
also everything worked before the latest update
Crash logs
No response
Neko version
2.15.0
Android version
android 11
Device
samsung galaxy 050
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
[X] I have written a short but informative title.
[X] I have updated the app to the newest version Latest.
[X] I have filled out all of the requested information in this form.

i found a workaround by disabling smart library update restrictions, but i don't get why it seems to think every single manga has a tracking status of "Unfollowed", even though i have them as "Reading"

i found a workaround by disabling smart library update restrictions, but i don't get why it seems to think every single manga has a tracking status of "Unfollowed", even though i have them as "Reading"

What other trackers are on that manga?

unfollowed is definitely, bugged.  I will fix it for next release.

What other trackers are on that manga?

i don't think there are any other trackers? how do i check that?

no worries that one is definitely bugged

Did some testing and this applies for all statuses, not just unfollowed, also Completed and Plan to Read seem to be mutually inclusive with no user feedback, I can't seem to just select one of them.
https://github.com/nekomangaorg/Neko/assets/34176510/3429b496-818a-4853-8047-725db0f0e1ea

Did some testing and this applies for all statuses, not just unfollowed.

No worries I already fixed it for next release. The Boolean check was opposite

Did some testing and this applies for all statuses, not just unfollowed.

No worries I already fixed it for next release. The Boolean check was opposite

ah, my cli didn't show the staged tag


feat(course-info.yaml) tag added

The "Beginner-friendly" tag added for the Learning Center integration

Hi @Geravant ?
Is this still relevant?
I can merge it if so.


[release-1.8] Fix: telemetry httpmx filter patch at Gateway should have wasmEnabled option

This is an automated cherry-pick of #29428

@istio-testing: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-multicluster-tests_istio_release-1.8
32920da76242604613af656e8f074ed894be5cc1
link
/test integ-pilot-multicluster-tests_istio_release-1.8

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest


Add factories module(s) with unit tests

Check if there are differences between the Python modules in the following (sub)packages:
https://github.com/elixir-europe/WES-ELIXIR/tree/dev/cwl-wes/factories
https://github.com/elixir-europe/proWES/tree/master/pro_wes/factories
https://github.com/elixir-cloud-aai/proTES/tree/dev/pro_tes/factories
If there are differences, summarize, and discuss differences. If not, add modules to the archetype (adjusting import paths).

Updated label because I think this may potentially be not as straight-forward as some other modules, as I think we need to create and return app objects here which is harder to unit test and requires more changes in the target code base than just different import statements


Fix Component Governance alerts

Thanks @wtgodbe.
@MackinnonBuck can you please see whether this is something to go well with your changes or should these be merged together? Thanks!

It might be the case that these steps should be repeated on #47. I'm not sure if these two PRs are compatible.

@MackinnonBuck, @wtgodbe we need Mackinnon's changes. But we also need to make sure we address CG alerts. So please work together to unify the changes into a single PR.

Closing in favor of https://github.com/dotnet/spa-templates/pull/47


Windows CMake issue when trying to run cmake command to build

I've tried all of the stuff on the README but nothing seems to work
Log:
**********************************************************************
** Visual Studio 2022 Developer PowerShell v17.10.3
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
PS C:\Users\haaps\source\repos> cd c:\src\vcpkg
PS C:\src\vcpkg> vcpkg.exe install tclap:x64-windows
warning: The vcpkg C:\Program Files\Microsoft Visual Studio\2022\Community\VC\vcpkg\vcpkg.exe is using detected vcpkg root C:\src\vcpkg and ignoring mismatched VCPKG_ROOT environment value C:\Program Files\Microsoft Visual Studio\2022\Community\VC\vcpkg. To suppress this message, unset the environment variable or use the --vcpkg-root command line switch.
error: Could not locate a manifest (vcpkg.json) above the current working directory.
This vcpkg distribution does not have a classic mode instance.
PS C:\src\vcpkg> cd c:\src
PS C:\src> git clone https://github.com/stephanecharette/DarkHelp.git
Cloning into 'DarkHelp'...
remote: Enumerating objects: 1920, done.
remote: Counting objects: 100% (422/422), done.
remote: Compressing objects: 100% (281/281), done.
remote: Total 1920 (delta 196), reused 183 (delta 120), pack-reused 1498
Receiving objects: 100% (1920/1920), 10.07 MiB | 2.20 MiB/s, done.
Resolving deltas: 100% (1217/1217), done.
PS C:\src> cd darkhelp
PS C:\src\darkhelp> mkdir build

    Directory: C:\src\darkhelp

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----          7/7/2024  10:50 AM                build

PS C:\src\darkhelp> cd build
PS C:\src\darkhelp\build> cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=C:/src/vcpkg/scripts/buildsystems/vcpkg.cmake ..
-- Building for: Visual Studio 17 2022
-- Selecting Windows SDK version 10.0.22621.0 to target Windows 10.0.22631.
-- The C compiler identification is MSVC 19.40.33811.0
-- The CXX compiler identification is MSVC 19.40.33811.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.40.33807/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
Building ver: 1.8.8-2
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - not found
-- Found Threads: TRUE
-- Found Protobuf: C:/src/vcpkg/installed/x64-windows/tools/protobuf/protoc.exe (found version "25.1.0")
-- Found TIFF: optimized;C:/src/vcpkg/installed/x64-windows/lib/tiff.lib;debug;C:/src/vcpkg/installed/x64-windows/debug/lib/tiffd.lib (found version "4.6.0")
-- Found HDF5: hdf5::hdf5-shared (found version "1.14.4")
-- Found ZLIB: optimized;C:/src/vcpkg/installed/x64-windows/lib/zlib.lib;debug;C:/src/vcpkg/installed/x64-windows/debug/lib/zlibd.lib (found suitable version "1.3.1", minimum required is "1")
-- Found LibArchive: C:/src/vcpkg/installed/x64-windows/lib/archive.lib (found version "3.7.2")
-- Found OpenMP_C: -openmp (found version "2.0")
-- Found OpenMP_CXX: -openmp (found version "2.0")
-- Found OpenMP: TRUE (found version "2.0")
-- Found OpenCV: C:/src/vcpkg/installed/x64-windows (found version "4.8.0")
-- Configuring done (15.0s)
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
Darknet
    linked by target "dh" in directory C:/src/DarkHelp/src-lib
    linked by target "cli" in directory C:/src/DarkHelp/src-tool
    linked by target "combine" in directory C:/src/DarkHelp/src-tool
    linked by target "server" in directory C:/src/DarkHelp/src-tool
    linked by target "display_single_image" in directory C:/src/DarkHelp/src-apps
    linked by target "process_video_webcam" in directory C:/src/DarkHelp/src-apps
    linked by target "display_single_image_custom_settings" in directory C:/src/DarkHelp/src-apps
    linked by target "display_single_image_snapping" in directory C:/src/DarkHelp/src-apps
    linked by target "display_using_bundle" in directory C:/src/DarkHelp/src-apps
    linked by target "video_display_realtime" in directory C:/src/DarkHelp/src-apps
    linked by target "process_many_images_on_threads" in directory C:/src/DarkHelp/src-apps
    linked by target "process_single_image" in directory C:/src/DarkHelp/src-apps
    linked by target "process_using_bundle_and_dhthreads" in directory C:/src/DarkHelp/src-apps
    linked by target "rotate_images" in directory C:/src/DarkHelp/src-apps
    linked by target "save_webcam_to_video" in directory C:/src/DarkHelp/src-apps
    linked by target "using_c_api" in directory C:/src/DarkHelp/src-apps
    linked by target "video_object_counter" in directory C:/src/DarkHelp/src-apps
    linked by target "DarkHelp_cam" in directory C:/src/DarkHelp/src-cam
TCLAP_INCLUDE_DIRS
   used as include directory in directory C:/src/DarkHelp
   used as include directory in directory C:/src/DarkHelp
   used as include directory in directory C:/src/DarkHelp/src-lib
   used as include directory in directory C:/src/DarkHelp/src-lib
   used as include directory in directory C:/src/DarkHelp/src-lib
   used as include directory in directory C:/src/DarkHelp/src-tool
   used as include directory in directory C:/src/DarkHelp/src-tool
   used as include directory in directory C:/src/DarkHelp/src-tool
   used as include directory in directory C:/src/DarkHelp/src-tool
   used as include directory in directory C:/src/DarkHelp/src-tool
   used as include directory in directory C:/src/DarkHelp/src-apps
   used as include directory in directory C:/src/DarkHelp/src-apps
   used as include directory in directory C:/src/DarkHelp/src-apps
   used as include directory in directory C:/src/DarkHelp/src-apps
   used as include directory in directory C:/src/DarkHelp/src-apps
   used as include directory in directory C:/src/DarkHelp/src-apps
   used as include directory in directory C:/src/DarkHelp/src-apps
   used as include directory in directory C:/src/DarkHelp/src-apps
   used as include directory in directory C:/src/DarkHelp/src-apps
   used as include directory in directory C:/src/DarkHelp/src-apps
   used as include directory in directory C:/src/DarkHelp/src-apps
   used as include directory in directory C:/src/DarkHelp/src-apps
   used as include directory in directory C:/src/DarkHelp/src-apps
   used as include directory in directory C:/src/DarkHelp/src-apps
   used as include directory in directory C:/src/DarkHelp/src-apps
   used as include directory in directory C:/src/DarkHelp/src-cam
   used as include directory in directory C:/src/DarkHelp/src-cam
   used as include directory in directory C:/src/DarkHelp/src-cam
   used as include directory in directory C:/src/DarkHelp/src-doc
   used as include directory in directory C:/src/DarkHelp/src-doc

CMake Error in CMakeLists.txt:
  Found relative path while evaluating include directories of "ZERO_CHECK":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in CMakeLists.txt:
  Found relative path while evaluating include directories of "ZERO_CHECK":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in CMakeLists.txt:
  Found relative path while evaluating include directories of "ZERO_CHECK":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in CMakeLists.txt:
  Found relative path while evaluating include directories of "ZERO_CHECK":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in CMakeLists.txt:
  Found relative path while evaluating include directories of "ALL_BUILD":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in CMakeLists.txt:
  Found relative path while evaluating include directories of "ALL_BUILD":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in CMakeLists.txt:
  Found relative path while evaluating include directories of "ALL_BUILD":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in CMakeLists.txt:
  Found relative path while evaluating include directories of "ALL_BUILD":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-lib/CMakeLists.txt:
  Found relative path while evaluating include directories of "dh":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-lib/CMakeLists.txt:
  Found relative path while evaluating include directories of "dh":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-lib/CMakeLists.txt:
  Found relative path while evaluating include directories of "dh":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-lib/CMakeLists.txt:
  Found relative path while evaluating include directories of "dh":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-lib/CMakeLists.txt:
  Found relative path while evaluating include directories of "dh":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-lib/CMakeLists.txt:
  Found relative path while evaluating include directories of "dh":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-lib/CMakeLists.txt:
  Found relative path while evaluating include directories of "dh":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-lib/CMakeLists.txt:
  Found relative path while evaluating include directories of "dh":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-lib/CMakeLists.txt:
  Found relative path while evaluating include directories of "dh":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-lib/CMakeLists.txt:
  Found relative path while evaluating include directories of "dh":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-lib/CMakeLists.txt:
  Found relative path while evaluating include directories of "dh":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-lib/CMakeLists.txt:
  Found relative path while evaluating include directories of "dh":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "combine":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "combine":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "combine":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "combine":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "combine":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "combine":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "combine":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "combine":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "combine":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "combine":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "combine":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "combine":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "cli":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "cli":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "cli":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "cli":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "cli":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "cli":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "cli":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "cli":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "cli":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "cli":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "cli":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "cli":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "server":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "server":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "server":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "server":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "server":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "server":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "server":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "server":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "server":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "server":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "server":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-tool/CMakeLists.txt:
  Found relative path while evaluating include directories of "server":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image_snapping":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image_snapping":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image_snapping":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image_snapping":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image_snapping":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image_snapping":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image_snapping":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image_snapping":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image_snapping":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image_snapping":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image_snapping":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image_snapping":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "video_display_realtime":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "video_display_realtime":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "video_display_realtime":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "video_display_realtime":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "video_display_realtime":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "video_display_realtime":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "video_display_realtime":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "video_display_realtime":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "video_display_realtime":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "video_display_realtime":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "video_display_realtime":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "video_display_realtime":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_using_bundle_and_dhthreads":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_using_bundle_and_dhthreads":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_using_bundle_and_dhthreads":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_using_bundle_and_dhthreads":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_using_bundle_and_dhthreads":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_using_bundle_and_dhthreads":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_using_bundle_and_dhthreads":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_using_bundle_and_dhthreads":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_using_bundle_and_dhthreads":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_using_bundle_and_dhthreads":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_using_bundle_and_dhthreads":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_using_bundle_and_dhthreads":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image_custom_settings":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image_custom_settings":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image_custom_settings":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image_custom_settings":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image_custom_settings":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image_custom_settings":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image_custom_settings":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image_custom_settings":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image_custom_settings":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image_custom_settings":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image_custom_settings":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image_custom_settings":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_single_image":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_many_images_on_threads":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_many_images_on_threads":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_many_images_on_threads":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_many_images_on_threads":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_many_images_on_threads":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_many_images_on_threads":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_many_images_on_threads":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_many_images_on_threads":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_many_images_on_threads":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_many_images_on_threads":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_many_images_on_threads":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_many_images_on_threads":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_single_image":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_single_image":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_single_image":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_single_image":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_single_image":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_single_image":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_single_image":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_single_image":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_single_image":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_single_image":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_single_image":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_single_image":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "rotate_images":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "rotate_images":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "rotate_images":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "rotate_images":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "rotate_images":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "rotate_images":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "rotate_images":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "rotate_images":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "rotate_images":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "rotate_images":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "rotate_images":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "rotate_images":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "save_webcam_to_video":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "save_webcam_to_video":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "save_webcam_to_video":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "save_webcam_to_video":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "save_webcam_to_video":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "save_webcam_to_video":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "save_webcam_to_video":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "save_webcam_to_video":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "save_webcam_to_video":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "save_webcam_to_video":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "save_webcam_to_video":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "save_webcam_to_video":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_using_bundle":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_using_bundle":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_using_bundle":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_using_bundle":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_using_bundle":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_using_bundle":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_using_bundle":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_using_bundle":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_using_bundle":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_using_bundle":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_using_bundle":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "display_using_bundle":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_video_webcam":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_video_webcam":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_video_webcam":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_video_webcam":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_video_webcam":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_video_webcam":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_video_webcam":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_video_webcam":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_video_webcam":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_video_webcam":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_video_webcam":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "process_video_webcam":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of "using_c_api":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of "using_c_api":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of "using_c_api":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of "using_c_api":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of "using_c_api":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of "using_c_api":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of "using_c_api":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of "using_c_api":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of "using_c_api":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of "using_c_api":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of "using_c_api":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of "using_c_api":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "video_object_counter":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "video_object_counter":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "video_object_counter":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "video_object_counter":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "video_object_counter":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "video_object_counter":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "video_object_counter":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "video_object_counter":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "video_object_counter":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "video_object_counter":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "video_object_counter":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-apps/CMakeLists.txt:
  Found relative path while evaluating include directories of
  "video_object_counter":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-cam/CMakeLists.txt:
  Found relative path while evaluating include directories of "DarkHelp_cam":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-cam/CMakeLists.txt:
  Found relative path while evaluating include directories of "DarkHelp_cam":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-cam/CMakeLists.txt:
  Found relative path while evaluating include directories of "DarkHelp_cam":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-cam/CMakeLists.txt:
  Found relative path while evaluating include directories of "DarkHelp_cam":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-cam/CMakeLists.txt:
  Found relative path while evaluating include directories of "DarkHelp_cam":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-cam/CMakeLists.txt:
  Found relative path while evaluating include directories of "DarkHelp_cam":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-cam/CMakeLists.txt:
  Found relative path while evaluating include directories of "DarkHelp_cam":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-cam/CMakeLists.txt:
  Found relative path while evaluating include directories of "DarkHelp_cam":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-cam/CMakeLists.txt:
  Found relative path while evaluating include directories of "DarkHelp_cam":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-cam/CMakeLists.txt:
  Found relative path while evaluating include directories of "DarkHelp_cam":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-cam/CMakeLists.txt:
  Found relative path while evaluating include directories of "DarkHelp_cam":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

CMake Error in src-cam/CMakeLists.txt:
  Found relative path while evaluating include directories of "DarkHelp_cam":

    "TCLAP_INCLUDE_DIRS-NOTFOUND"

-- Generating done (0.7s)
CMake Generate step failed.  Build files cannot be regenerated correctly.
PS C:\src\darkhelp\build>

You must follow the instructions in the readme.  These errors show me you did not follow the instructions.

Not only do you not have TClap installed as described in the readme, you're also using PowerShell while the instructions tell people to use the developer shell:

This is also described in the Darknet readme as well:

And again in the FAQ:

I reinstalled Darknet and Darkhelp using the command prompt (misread originally which is why I was doing it in PowerShell)
Current error is as follows (same line causes the error)
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
Darknet
    linked by target "dh" in directory C:/src/DarkHelp/src-lib
    linked by target "cli" in directory C:/src/DarkHelp/src-tool
    linked by target "combine" in directory C:/src/DarkHelp/src-tool
    linked by target "server" in directory C:/src/DarkHelp/src-tool
    linked by target "display_single_image" in directory C:/src/DarkHelp/src-apps
    linked by target "process_video_webcam" in directory C:/src/DarkHelp/src-apps
    linked by target "display_single_image_custom_settings" in directory C:/src/DarkHelp/src-apps
    linked by target "display_single_image_snapping" in directory C:/src/DarkHelp/src-apps
    linked by target "display_using_bundle" in directory C:/src/DarkHelp/src-apps
    linked by target "video_display_realtime" in directory C:/src/DarkHelp/src-apps
    linked by target "process_many_images_on_threads" in directory C:/src/DarkHelp/src-apps
    linked by target "process_single_image" in directory C:/src/DarkHelp/src-apps
    linked by target "process_using_bundle_and_dhthreads" in directory C:/src/DarkHelp/src-apps
    linked by target "rotate_images" in directory C:/src/DarkHelp/src-apps
    linked by target "save_webcam_to_video" in directory C:/src/DarkHelp/src-apps
    linked by target "using_c_api" in directory C:/src/DarkHelp/src-apps
    linked by target "video_object_counter" in directory C:/src/DarkHelp/src-apps
    linked by target "DarkHelp_cam" in directory C:/src/DarkHelp/src-cam

Please re-read the instructions.  This error is because you're not following the instructions correctly.

That worked - thank you so much!


MAKE ERROR

[ 25%] Building CXX object PyOpenPoseLib/CMakeFiles/PyOpenPose.dir/OpenPoseWrapper.cpp.o
[ 50%] Building CXX object PyOpenPoseLib/CMakeFiles/PyOpenPose.dir/PyOpenPose.cpp.o
[ 75%] Building CXX object PyOpenPoseLib/CMakeFiles/PyOpenPose.dir/opencv_expose.cpp.o
[100%] Linking CXX shared library PyOpenPose.so
/usr/bin/ld: cannot find -lopenpose
/usr/bin/ld: cannot find -lcaffe
collect2: error: ld returned 1 exit status
PyOpenPoseLib/CMakeFiles/PyOpenPose.dir/build.make:194: recipe for target 'PyOpenPoseLib/PyOpenPose.so' failed
make[2]: *** [PyOpenPoseLib/PyOpenPose.so] Error 1
CMakeFiles/Makefile2:117: recipe for target 'PyOpenPoseLib/CMakeFiles/PyOpenPose.dir/all' failed
make[1]: *** [PyOpenPoseLib/CMakeFiles/PyOpenPose.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2

Did you set the OPENPOSE_ROOT variable to point to the openpose root folder?
Note that the build script assumes that you use the Makefile (make distribute) to build openpose. If you choose to install the libraries else where, you must adapt CMakeLists.txt accordingly.

@padeler  I have set OPENPSOE_ROOT
I can run openpose demo, I used cmake to build openpose.
How to modifiy CMakeLists.txt?

You have to set the correct paths for caffe and openpose libs and header folders in lines 59-62.

Hello, I've encountered the same problem, but I've solved it by installing openpose with :
sudo make install from openpose/build as described in the section :
OpenPose from other Projects of documentation
https://github.com/CMU-Perceptual-Computing-Lab/openpose/blob/master/doc/installation_cmake.md

@unrealwill you are right. I can make it now. However, when I  try to run scripts/JusthandNet.py, Importing PyOpenPose as op failed.

Did you find a solution to your issue?

Nope, but I got around my problem by writing a c++ zmq server which uses OpenPose and serve the info I need.

ok so I am closing this issue.

@padeler I'm not the OP, so I don't know if he solved his issue one way or another.
@derekwong66 You can look at my project https://github.com/GistNoesis/Linn-Photobooth for the zmq server and usage

I have not tried pyopenpose with python3. I'll test it when i have some time, and report here for future reference.


r.Cursor.Next() no longer sets pointer to nil on document not found

Documents that don't exist no longer set the pointer to nil when using r.Cursor.Next(). Seems to come from this commit c52349e8e587dbbffe482e9404420d310b2015a7 in func decode()
Changing decode from
 func decode(dv, sv reflect.Value) {
       if dv.IsValid() {
               dv = indirect(dv, false)
               dv.Set(reflect.Zero(dv.Type()))
       }

        valueDecoder(dv, sv)(dv, sv)
 }

back to
 func decode(dv, sv reflect.Value) {
    valueDecoder(dv, sv)(dv, sv)
 }

restores previous behavior. I don't know the codebase well enough, to determine if this breaks other things.
test case (shortened for brevity) -- Also note that using cur.One(&doc) works as expected and returns nil
type doc struct {
 id string
}

cur, err := r.Table("test").Get(NonExistingDocId).Run(sess)
if err != nil {
 panic(fmt.Sprintf("Could not check for existing document [ERR:%s]", err.Error()))
}
cur.Next(&doc)
if doc == nil {
 fmt.Printf("Document not found!\n")
}

Sorry for taking so long to look into this, I will look into fixing this issue now.

I have just pushed an update to develop which should fix this issue, I hope to have it pushed to master within a couple of days.

No worries, it was an easy work around. I tested the develop branch, and it looks like it's fixed. Thanks for getting to this!

Merged to master


[WIP] nixos-doc: add reviewing contributions chapter

Motivation for this change
Improving reviewing process by making reviewing guidelines.
This is an attemp to improve situation raised in #17407.
Work in progress, polishing to come.
(80 chars linewrap will be made when ready to merge)
feedback is welcomed!
At the moment I am especially interested to get feedback regarding if this is a step in the right direction or not.
Things done

[ ] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] OS X
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

cc @obadz @zimbatm @domenkozar

@zimbatm Thanks for the valuable inputs, it really helps!

It's going in the right direction I think. Maybe merge that with the rest of the contributing manual to make it a single big section. I think the CONTRIBUTING.md should also be cleaned and only point to the manual, otherwise people will think that just reading the first bit is enough and not go to the manual.

Update: reflected comments.
Thanks for all the feedback!

@rasendubi Thanks for all the feedback! applied.
@all
I think this could take forever if we try to make it perfect for first iteration, so I propose to add a header to this section like "The following section is a draft and reviewing policy is still being discussed." and merge it after if we agree this is good enough, so we can at least have a base policy for reviewing.
What do you think?

thanks!

Oops, didn't had time to put the warning, squash the commits and make linebreaks at 80 chars, is that fine to merge in current state?


[Feature] A way to list deployed Subgraphs

Description
Hello!
Is there a way to list the subgraphs that are already deployed on the Graph Node instance?
Thank you!
Are you aware of any blockers that must be resolved before implementing this feature? If so, which? Link to any relevant GitHub issues.
No response
Some information to help us out

[ ] Tick this box if you plan on implementing this feature yourself.
[X] I have searched the issue tracker to make sure this issue is not a duplicate.

@folex You can use this graphman command to list all the deployments in a graph-node.
graphman info --all


Sever streaming method return rpc error: code = DeadlineExceeded desc = context deadline exceeded

my issue behavior is similar with #226
Proto file(s)
service TrService { rpc GetTrafficData(TrRequest) returns (stream TrResponse) {} }
Command line arguments / config
ghz --insecure --proto ./trafficproxy.proto --call trafficproxy.TrafficService.GetTrafficData --total=1 --stream-call-duration 10000ms --stream-call-count=10 -d '{xxxxx}' my.company.dns.com:10086
Describe the bug
I've similar issue when call grpc server streaming with new options in 0.80.0 release, like -stream-call-duration 10000ms,--stream-call-count=10
Summary:
Count: 1
Total: 20.00 s
Slowest: 0 ns
Fastest: 0 ns
Average: 20.00 s
Requests/sec: 0.05
Response time histogram:
Latency distribution:
Status code distribution:
[DeadlineExceeded] 1 responses
Error distribution:
[1] rpc error: code = DeadlineExceeded desc = context deadline exceeded
However, when I use BloomRPC tool with same proto file to call grpc method, which is successful. I mean server streaming response would always return data unless I stop the connection(channel).
Could be my parameter usage problem? please kindly give any suggestions , thanks in advance.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
A clear and concise description of what you expected to happen.
Environment

OS: [e.g. macOS 10.14.3]
ghz: [e.g. 0.106.1]

Hi there. I was with the same issue and I believe what it is missing here is the timeout 0 to define the infinite timeout. But this will cause another issue which is the cancelled error. But to "solve" that we can add the "count-errors" so then it should kind of work at the end.
whatever, example
ghz --insecure --async \
    --proto ../grpc-service/Protos/greet.proto \
    --call greet.Greeter.KeepTalking \
    --data '{ "name" : "Someone {{.RequestNumber}}" }' \
    --timeout 0 --total 100 --stream-call-count 2 --count-errors \
    --output streaming_keepTalking.html --format html  \
    localhost:5022

--timeout 0 sets ghz to infinite timeout
--total 100 perform 100 streaming requests
--stream-call-count 2 expects 2 returns from each streaming
--count-errors counts cancelled events as good events

Result (my example is with a server that returns infinite messages each 10s)
Summary:
  Count:        100
  Total:        10.04 s
  Slowest:      10.04 s
  Fastest:      10.02 s
  Average:      10.03 s
  Requests/sec: 9.96

Response time histogram:
  10020.563 [1]  |∎∎
  10022.154 [16] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  10023.744 [16] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  10025.335 [14] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  10026.926 [17] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  10028.516 [2]  |∎∎∎∎∎
  10030.107 [4]  |∎∎∎∎∎∎∎∎∎
  10031.698 [8]  |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  10033.289 [9]  |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  10034.879 [9]  |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
  10036.470 [4]  |∎∎∎∎∎∎∎∎∎

Latency distribution:
  10 % in 10.02 s
  25 % in 10.02 s
  50 % in 10.03 s
  75 % in 10.03 s
  90 % in 10.03 s
  95 % in 10.03 s
  99 % in 10.04 s

Status code distribution:
  [Canceled]   100 responses

Error distribution:
  [100]   rpc error: code = Canceled desc = context canceled

Hope that helps

But I agree that infinite server streaming performance tests are not supported by the tool, and instead, we do this kind of work around.


wlopm: init at 0.0.1

Description of changes
https://sr.ht/~leon_plickat/wlopm/
Simple client implementing zwlr-output-power-management-v1.

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 175473 run on x86_64-linux 1

1 package built:

wlopm

Builds fine, but no tests and I cannot test manually (X11 here) so waiting on someone else to test.

we can bump this to 0.1.0 now. I've built and tested 0.1.0 on Sway (multi monitor setup), and it seems to work nicely. It's nice to have more generic output power management instead of having to rely on something like swaymsg which is obviously not available on other wlroots compositors.

@ckiee Another tester has commented. Do you think it's ready to merge now?

@ofborg eval

You forgot to update the sha256 :P

Result of nixpkgs-review pr 175473 run on x86_64-linux 1

1 package built:

wlopm

Weird... I'm sure it was correct before. Well, I've updated it now and it works perfectly.

Result of nixpkgs-review pr 175473 run on x86_64-linux 1

1 package built:

wlopm

Did a quick test as well; ./results/wlopm/bin/wlopm --toggle DP-2 toggled the power of correct output.


Change to the last opened workspace feature

Done tasks:

[x] Create everything needed for the feature (including definitions and methods).
[x] Reuse the codes from CWindowManager::changeWorkspaceByID method.

Bugs:

False behavior when switching from the workspace that has windows opened and the one that don't have any windows.
Question about the bug: I don't know if that's because my own logic bugs or there are some parts implicitly included in your code. (very likely that I missed some implemented ideas of the reused method)

TODO:

Fix the bug and ready for a complete PR.

fixed.

Hey, I just want to say that your project is awesome. But imo, some of your naming is a little ambiguous. Still now, I'm not sure about the difference between workspaces and activeworkspaces (I think activeworkspaces includes the IDs of the active workspaces, if so you can change its name to activeworkspacesIDs for example).

they are, fair. I could include some comments.


Button to validate/download OpenAPI spec?

Is there OpenAPI analogue to the Swagger validate button? Or currently the Swagger one should be used?

There is no official validation tooling, though our charter does allow for that. Now that the v3 spec is released, this is something we'll consider, but it may be one of those things that the community rises to provide or that we end up with multiple validation projects (which has pros and cons!).


Tag function

Description of the new feature / enhancement
Help files and folders add tags, to help user quick search it.
Scenario when this would be used?
add new file or folder.
or search the tags files.
Supporting information
No response

Duplicate of #150

Thanks for your suggestion! This issue is a duplicate.
I'm linking this issue to #150 to centralize the discussion thread, please go to that thread for discussion.
Thanks for your help to make PowerToys a better piece of software!


Unable to change password for oracle user

I need to change the password for oracle user. I log into root user, run the passwd procedure to change password, it says it is successfully updated, but if I try to log into oracle user, it gives me error, like it wasn't changed at all.
I use this image for our developers, it is by far, the best for our needs. If I could change the password it would be perfect.
I assume it is possible by rewriting some line in the build script, but I don't know where to look.
Anyway, great work, thank you!

I log into root user, run the passwd procedure to change password, it says it is successfully updated, but if I try to log into oracle user, it gives me error, like it wasn't changed at all.

Can you give an example of the commands to reproduce this?
Maybe this could solve your problem: add this line to step2/Dockerfile
RUN echo 'oracle:new_password' | chpasswd`

But take into account that storing passwords in a Dockerfile is a bad idea.
Btw, why do you need the password? Is docker exec not enough?

Can you give an example of the commands to reproduce this?
docker exec -it -u root database_container bash
passswd oracle
password
password
Now it says all tokens updated successfully, but apparently not.

Btw, why do you need the password? Is docker exec not enough?

Unfortunately not, as we are developing an app, that connects to database instance (container in this case) and it uses it's system authentication.
Thank you, for quick response!
And as I've said, great work 👍 :)

Ok, I've just tried it and there seems to be other problem. The password is changed all right.
But if log into as other user
docker exec -it -u spadmin container bash and then try to open session for user oracle su oracle and enter password, it gives me error su: cannot open session: Permission denied

So, I was able to figure it out. The problem was in security file.
https://susguzman.wordpress.com/2017/06/26/su-cannot-open-session-permission-denied-oracle-database-12c-sobre-docker/
This solved it for me.
Anyway, thanks for your help!


Implements shared navigation for Jamstack Explorers.

Doesn’t depend on #508 but #508 is recommended as a pre-requisite!
More detail in https://github.com/netlify/marketing/issues/1470

🚢🛳⛴🚀📦


CTR mode does not accept a nonce, without which, it is completely broken.

CTR mode is fundamentally broken without a random nonce, for the same reason that repeated key XOR is broken, but in this library, ModeOfOperation.CTR, as far as I can tell, currently does not make use of a nonce.
https://security.stackexchange.com/questions/63188/whats-the-point-of-the-nonce-in-ctr-mode
p.s., minor nitpick, but "initialization vector" is also spelled wrong in all the errors.

My error, apologies: there is a second parameter to the ModeOfOperation.CTR method called counter which is the initialization value for the counter.


Invalid synchronization: . Valid types are 'delta' and 'full'.

Please check if sync input value does not have leading/trailing space.

Could you please share action log after enabling debug input parameter.

@mattlag
Thank you for providing action logs. It the same workflow did ran properly then I am guessing it was a temporary glitch with action runner.

@milanmk
I have encountered this issue and found the cause ,well for my problem anyway.
When trigging the deployment via a repo dispatch the following worked, however when trying to run the workflow manually, it would have the same issue as above.
The following is a cutdown example.
on:
  repository_dispatch:
    types: [production-release]
  workflow_dispatch:

.....

    - name: Deploy assets library to netstorage (CDN)
      uses<EMAIL_ADDRESS>      with:
        remote-protocol: 'sftp'
        remote-host: ${{ inputs.cdnRemoteHost }}
        remote-user: 'sshacs'
        ssh-private-key: ${{ inputs.cdnPrivateKey }}
        remote-path: ${{ inputs.cdnRemotePath }}
        local-path: asset
        sync: full
        ssh-options: '-oHostKeyAlgorithms=+ssh-dss'
        ftp-options: 'set cmd:fail-exit true'

The root cause of my issue was that the input_sync expects the sync input to come from the workflow inputs when I manually trigger the workflow.
Basically my input was being overridden by the default input.sync
 input_sync=${{inputs.sync}}
        if [ "${{github.event_name}}" == "workflow_dispatch" ]; then
          input_sync=${{github.event.inputs.sync}}
fi

You should have an input for workflow_dispatch like shown in the readme workflow example.
workflow_dispatch:
  inputs:
    sync:
      description: "File synchronization"
      required: true
      default: "delta"

I am trying this with manual trigger of the github action.
I do set sync in the settings:
      - name: sftp deploy
        uses: milanmk/actions-file-deployer@master
        with:
          remote-protocol: "sftp"
          remote-port: 22
          remote-host: ${{ secrets.DEPLOY_HOST }}
          remote-user: ${{ secrets.DEPLOY_USER }}
          remote-password: ${{ secrets.DEPLOY_PASS }}
          proxy: false
          sync: "full"
          local-path: "./public/*"
          remote-path: "test""

which leads to Invalid synchronization: . Valid types are 'delta' and 'full'
however when I additionally add sync to the input settings:
  workflow_dispatch:
    inputs:
      sync:
        description: "File synchronization"
        required: true
        default: "full"

it seems to work.
Why do I have to set sync twice?

@thomasmillercf
I agree with your reasoning with having one way of defining the default. Have merged the changes in #44  and sorry for not approving your PR on time.


[Feature Request] Font size change

The vim plugin zen-mode by folke has the ability to change the font size of Kitty, Wezterm and Alacritty.
Here's an example in lines 36-75. I would do it myself, but I'm not knowledgeable enough in  Go or in programming in general.
This would allow for the lyrics window to have a different font size making it more readable, this can be done easily by zooming in, but adjusting the font size this way means that it can then be reversed after the application closes.
This is just an idea and I would understand it if it's not implemented

I don't like the idea of writing "terminal emulator specific" code... There's probably a better way to implement it. Maybe a bash script that would set the desired font size, open sptlrx and wait for it to close, then return it to normal?


Cython and Fortran together

I am going to continue uploading the rest of the files and making sure that everything passes. Once I have done that I will make the changes (then I know that I havent broken it)

Everything is uploaded now. I will start cleaning up the code (there a few things I want to do).

I think this is ready to review.
I have made an extra change, by deleting the individual yml files for conda. I wanted to be able to see the differences between the OS's easily on a single screen. So it is now generated by a python script.
I have not added "c_python" and "fortran" to the names of the modules (e.g. quasielasticbayes.c_python.four or quasielasticbayes.fortran.four). I think it is better to do it as part of https://github.com/mantidproject/quasielasticbayes/issues/29 so we do not change the current API.