Is your feature request related to a problem? Please describe.
Windows is a popular platform where most GUI projects are run.
It is reasonable to ensure that our GUI is continuously deliverable on Windows platform

Describe the solution you'd like
Set up a workflow on Github Actions, testing

• Build compatibility of the codes on Windows machines
• Run regression tests on Windowns machines

Refer to the workflow example at

https://github.com/chipsalliance/Surelog/blob/ac38329a10128579831ee8fd8dfa7a8bcfbfb936/.github/workflows/main.yml#L128

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Simply rerun one of the runs from main that used to pass, and observe the msvc failure, something about a .vc file syntax and multiple processes accessing a file.
Looks like something changed in the compilation environment.

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Enviornment (please complete the following information):

• OS:

• Compiler:

• Version:

Additional context
Add any other context about the problem here.

Clicking in the console while command running: bogus error:
invalid command name "Synthesizing"

synth

Synthesizing design: Some cool design...

0% File: device.xml just for test
10% File: .readthedocs.yml just for test
20% File: src just for test
30% File: .gitignore just for test
40% File: Config.cmake.in just for test
50% File: README.md just for test
60% File: cmd.log just for test
70% File: .git just for test
80% File: .gitmodules just for test
90% File: tests just for test
Design Some cool design is synthesized!

invalid command name "Synthesizing"

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Clone repository and checkout commit id:
2. Execute a test case or your own example:
3. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Enviornment (please complete the following information):

• OS:

• Compiler:

• Version:

Additional context
Add any other context about the problem here.

alain@alain-xps:~/FOEDAG$ ./dbuild/bin/texteditor --replay tests/TestGui/gui_text_editor.tcl
TEXT EDITOR GUI START
TEXT EDITOR GUI OPENFILE
TEXT EDITOR GUI STOP
GUI EXIT
Tcl Exit
corrupted double-linked list
Aborted (core dumped)
alain@alain-xps:~/FOEDAG$ 

Is your feature request related to a problem? Please describe.
start_gui command is a standard used in many EDA softwares to launch the GUI through Tcl interface.
In current codes, we have a command gui_start, which can launch the Qt Mainwindow

Not sure, we do need start_gui or gui_start

Describe the solution you'd like
Some useful document:

• https://www.tcl.tk/community/tcl2017/assets/talk85/Slides.pdf
• https://wiki.tcl-lang.org/page/Extending+Tcl
• https://www.tcl.tk/man/tcl/TclLib/contents.html

I got random problem with batch command.
E.g. batch {synth}

gives output:

batch {synth}
true
Running batch...
Tcl Error: extra characters after close-quote
Batch Done.

Looks like smth uninitialized because it cause randomly.

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Clone repository and checkout commit id:
2. Execute a test case or your own example:
3. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Enviornment (please complete the following information):

• OS:

• Compiler:

• Version:

Additional context
Add any other context about the problem here.

Please cleanup all warnings so we can turn on -Werror compiler flag and treat all warnings as errors.

Add action(s) to run FOEDAG on the CI within the CentOS.

• Create basic support for output parser. Responsibilities:
  ** parse output
  ** create file hyperlinks
• create test parser to demo the possibilities.

Motivation.

Provide tcl console for the GUI.

Plan

First step:
Standalone application with full featured tcl console. The console should behave like regular console.
Second step:
Integration into main GUI.

Requirements for standalone:

• When start gui – no need tcl interpreter anymore.
• Tcl console should be a part of the project as well as standalone
• Main functionality:
  -- Text field for the input and output like standard console
  -- The widget doesn’t allow to enter command while running smth.
  -- There is should be possibility to terminate current run.
• Common console functionality:
  -- Abort current running.
  -- History
  -- Possibility to run prev command with !
  -- Autocompletion by tab
  -- Autocomplete for command parameters is more like nice to have feature.
  -- In case multiple choice show all cases
  -- Clear
• Search
• Hyperlinks (e.g., file line)
• The command should run in some thread in order not block gui.
• Multiline command like regular console – more like nice to have feature
• Interface between console and main part:
  TBD

Libraries for command line functionality:

Readline 

https://github.com/JuliaAttic/readline port for windows 

Libedit  

Libeditline is fork for C++. 

Linenoise  

linenoise-ng C++ with window support but the repo is archiched 

Requirements for main application:

• Possibility to add and remove console.
• TBD

Open questions:
What is A filter to display only errors and warnings

Describe the bug
A clear and concise description of what the bug is.

Which part of FOEDAG is buggy

• Documentation

A problem seen in #54

To Reproduce
Steps to reproduce the behavior:

1. You can see that in the README.md, the installation guidelines are hard-coded and it is out-of-data as compared to latest version in INSTALL.md. We should use include to avoid out-of-date guidelines. I have already done so in the sphinx documentation: https://foedag.readthedocs.io/en/latest/tutorials/getting_started/build_instructions/#clone-and-initialize-submodules

Expected behavior
We should always use the INSTALL.md as the golden reference. Anywhere else, we should link to the INSTALL.md rather than create a hard copy.

Screenshots
Currently front page:

Enviornment (please complete the following information):

• OS:

• Compiler:

• Version:

Additional context
Add any other context about the problem here.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Check this actions:
https://github.com/KochynVolodymyr/FOEDAG/runs/5057035101?check_suite_focus=true

One of the test fail:
CONSOLE GUI: source command

while executing
"console_proc process_qt_events"
("after" script)

But action pass successfully.

Expected result: Action test should fail.

return TCL_ERROR should cause test fail. But it doesn't.

This gives a couple of answers
https://stackoverflow.com/questions/68292797/running-java-gui-tests-on-github-using-xvfb

Motivation

Displays the hierarchy of files contained in the project.
Provide GUI for project management.

Technical Details

Detail the technicality of this widget, it must include the following aspects.

Code flow

Tcl command

We can also manage the project by using Tcl command.

> create_fileset [<type>][<setname>]

> add_files [<type>][<filename>] 

> set_active [<type>] [<setname>]

> set_as_top [<type>][<filename>]

> set_as_target [<filename>]

The tcl command operates on the active fileset.

About the widget window floorplanning ,I will do it soon by QT designer.

Open to discussion here.

The IDE I use is QT creator. MSVC2019 compilation environment
I compiled and installed FOEDAG on windows, but run failed

Unable to locate program input point...
I only compile and execute foedag.exe, which has the same problem.
What should I do?

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Clone repository and checkout commit id:
2. Execute a test case or your own example:
3. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Enviornment (please complete the following information):

• OS:

• Compiler:

• Version:

Additional context
Add any other context about the problem here.
@KochynVolodymyr, please check, also:

• all Compiler commands are not registered anymore with the console (synth, batch), somehow the registration call is gone.
  That code was removed in your last CI and not replaced by an equivalent (And we had no test yet to make sure that kept working):
  std::string design("Some cool design");
  FOEDAG::Compiler *com = new FOEDAG::Compiler{
  interpreter, new FOEDAG::Design(design), console->getStream()};
  com->RegisterCommands(interpreter, false);

• The Tcl test should do something more complex than just opening the console, it needs to send commands to the console like plain Tcl commands (puts ....) and more system level test:
  set TOTO 1
  batch { incr TOTO }
  update_result
  puts $TOTO

You need to develop a way to send those commands from the test to the console and execute them in the console, not in the Tcl interpreter itself.
You might want to create a Tcl command in the interpreter that encapsulate the script and send it to the console to execute.

console_exec {
set TOTO 1
batch { incr TOTO }
update_result
puts $TOTO
}

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Clone repository and checkout commit id:
2. Execute a test case or your own example:
3. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Enviornment (please complete the following information):

• OS:

• Compiler:

• Version:

Additional context
Add any other context about the problem here.

/home/alain/FOEDAG/src/NewProject/ProjectManager/project_manager.cpp:854:43: error: ‘this’ pointer is null [-Werror=nonnull]
854 | if (nullptr == proRun && proRun->runType() != RUN_TYPE_IMPLEMENT) {
| ~~~~~~~~~~~~~~~^~

Add possibility to terminate running of current command with combination Ctrl+C when there is no text selection.

Motivation.

Provide tcl console for the GUI.

Plan

First step:
Standalone application with full featured tcl console. The console should behave like regular console.
Second step:
Integration into main GUI.

Requirements for standalone:

• When start gui – no need tcl interpreter anymore.
• Tcl console should be a part of the project as well as standalone
• Main functionality:
  -- Text field for the input and output like standard console
  -- The widget doesn’t allow to enter command while running smth.
  -- There is should be possibility to terminate current run.
• Common console functionality:
  -- Abort current running.
  -- History
  -- Possibility to run prev command with !
  -- Autocompletion by tab
  -- Autocomplete for command parameters is more like nice to have feature.
  -- In case multiple choice show all cases
  -- Clear
• Search
• Hyperlinks (e.g., file line)
• The command should run in some thread in order not block gui.
• Multiline command like regular console – more like nice to have feature
• Interface between console and main part:
  TBD

Libraries for command line functionality:

Readline 

https://github.com/JuliaAttic/readline port for windows 

Libedit  

Libeditline is fork for C++. 

Linenoise  

linenoise-ng C++ with window support but the repo is archiched 

UML diagram:

ConsoleWidget. Main widget.
ConsoleInterface. Abstract class that provide interface for the widget.
TclConsole. Inmplementation of the ConsoleInterface for the TCL.
TclWorker. Class that encapsulate tcl. Must run in separate thread.

Requirements for main application:

• Possibility to add and remove console.
• TBD

Open questions:
What is A filter to display only errors and warnings

User wants to have autocomplete for arguments of the command like switches, filenames, dirs or keywords. As an example could be 'git' in the bash.

Currently this issue isn't urgent.

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Clone repository and checkout commit id:
2. Execute a test case or your own example:
3. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Enviornment (please complete the following information):

• OS:

• Compiler:

• Version:

Additional context
Add any other context about the problem here.

Add a top-level window with panes, tabs, to the FOEDAG main executable with initially the project viewer, Text Editor, Console

Is your feature request related to a problem? Please describe.
I already forgot the steps to compile the docs, a make doc target is needed in the top-level Makefile

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

User can search in history via Ctrl+R.
Issue isn't urgent.

The VS Compiler version keeps changing in CI ,
tcl_cmake contains a hardcoded VS version for file paths, make that a soft path based on compiler version

Installing tcl9registry13s.lib
" Tcl Compilation completed"
[167/267] Running utility command for tcl_build
FAILED: third_party/tcl_cmake/CMakeFiles/tcl_build.util
cmd.exe /C "cd /D D:\a\FOEDAG\FOEDAG\build\third_party\tcl_cmake && C:\hostedtoolcache\windows\cmake\3.21.3\x64\cmake-3.21.3-windows-x86_64\bin\cmake.exe -E copy ../../../third_party/tcl/win/Release_AMD64_VC1930/tcl90s.lib D:/a/FOEDAG/FOEDAG/build/third_party/tcl_cmake/../../lib/foedag/lib/tcl90s.lib"
Error copying file "../../../third_party/tcl/win/Release_AMD64_VC1930/tcl90s.lib" to "D:/a/FOEDAG/FOEDAG/build/third_party/tcl_cmake/../../lib/foedag/lib/tcl90s.lib".
ninja: build stopped: subcommand failed.
make: *** [Makefile:47: release] Error 1

Is your feature request related to a problem? Please describe.
I think we should add a step to generate the installation package

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

@MidsummerNight I had a discussion with @alain-rs

He suggest to use the CMake to build our Qt project, rather than the qmake. What is your take on this?

There are few issues:

• when run batch press enter - console try run some command instead of wait until batch finished.
• after batch finished - press enter - some command will run instead of doing nothing.
• when batch start - prompt is shown and then other output instead of wait until batch finish and only then show the prompt.

Is your feature request related to a problem? Please describe.
As the core of the IDE is Tcl+GUI, in all the tests deployed in CI, the Qt compilation is always enabeld.
However, we should also have a test to validate compilation without Qt, where only Tcl will run.

Describe the solution you'd like

• In CMakelist, make Qt package optional
• If source codes, use #WITH_GUI to skip Qt in compilation

Feel free to comment

Code format or coding convention is important for us to ensure clean, human readable, maintainable codes in this project.
Therefore, I suggest to pick a code format and force it in Github actions as a required check when merging pull request.

@alain-rs suggested to use the Google code format. He has scripts ready at

• https://github.com/chipsalliance/Surelog/blob/master/.clang-format
• https://github.com/chipsalliance/Surelog/blob/master/.github/bin/run-clang-format.sh

@MidsummerNight If you are o.k. we can bring them to this repo and adapt it.

By the end of this effort, we can see something like this when reviewing a pull request:

Is your feature request related to a problem? Please describe.
As seen in PR #35, the main window has been created.
I have learned from Qt online documentation: https://doc.qt.io/qt-5/qtwidgets-index.html
As the Qt framework is modularized, the main window will finally be a place where all the widgets are added.
Each widget will be an independent class inherit from Qt classes, e.g., QDockWidget, QApplication etc.
Therefore, it is time to split our workload and parallelize the effort.

Describe the solution you'd like

Work plan

I propose that we work in this style

• Define the list of Widgets to be created
• Each team member claims the Widget to work on
• We keep a track on the progress of each Widget. One Widget -> one or more pull requests

List of Widgets

Here, I only list the minimum Widgets required to build a mini FPGA IDE
Each widget can be in a separated issue

• Console which includes
  • A text box where Tcl command can be typed in
  • A label box where all the logs can be shown
  • A filter to display only errors and warnings
• Flow navigator which includes
  • A QTreeWidget which show steps required to perform a complete design flow
  • (Optional) Progress bars to show success and failures of each step
  • Right click to open any log files outputted by each step
• Text Editor which supports
  • TextBox to load and write HDL codes from/to files
  • HDL syntax highlight and error indicator
  • Multi-tab to open multiple files
• Project navigator which shows
  • Project settings
  • Source file categories and hierarchies
• New project wizard
  • Select device/board from a list
  • Select source files/design constraints
  • Create project description file
• New file wizard
  • Select the file types
  • Use QFileDialog as the base
• I/O plan wizard
  • Select the I/O plan from figures
  • Output I/O constraints to files
• Timing analysis stats
  • Show bar graph on the slack/path delay distribution on all the paths

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Clone repository and checkout commit id:
2. Execute a test case or your own example:
3. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Enviornment (please complete the following information):

• OS:

• Compiler:

• Version:

Additional context
Add any other context about the problem here.

User can input multiline text like:
proc myproc { } {
puts HELLO
}

or

batch {
synth
globalp
}

To ensure we have a always-ready documentation, we need to add the documentation building to the Continuous Integration (CI).
Our documentation is built through the open-source readthedocs.org, which will compile the documentation for

• the main branch when there is a change (pull request merged)
• any pull request which is made on the main branch

As a result,

• We should see something like this when reviewing our pull request
  
• We can preview the pull request when click the details in the above figure

Motivation

Provides an interface for editing HDL code.

Technical Details

Code flow

Basic functions

• HDL syntax highlight and error indicator
• Multi-tab to open multiple files
• Basic editing operations,such as cut,copy,paste,delete,undo,redo.

I will use a third-party open source library: QScintilla。
https://www.riverbankcomputing.com/static/Docs/QScintilla/

Open to discussion here.

Is your feature request related to a problem? Please describe.

This is an issue detected in pull request #18
Because the third party libraries, i.e., Tcl and Zlib, do not have native CMake scripts. So we use CMake to hook their Makefile.
As a result, the build for Tcl is not completely incremental, the configure part is redone for every compilation.
This will cause a long runtime each time we want to rebuild the source codes (nothing cached for these libraries)

Describe the solution you'd like
The solution is to find a way in CMakelist.txt for these third part libraries.
When creating a custom target in CMake, see if it can identify dependencies and avoid rebuilding from scratch

To ease

• Tracking issues (categorize problems, reproduce bugs etc.)
• Manage pull requests (link issues, assign code reviewers, checklist)

We definitely need

• An issue template (which is tuned for the current project). See an example:

name: Bug report
about: Create a report to help us improve
title: ''
labels: ''
assignees: ''

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Clone FOEDAG repository and checkout commit id:
2. Execute FOEDAG test or your own example:
3. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Enviornment (please complete the following information):

• OS:

• Compiler:

• Version:

Additional context
Add any other context about the problem here.

• An pull request template (which is tuned for the current project). See an example:

Motivate of the pull request

• To address an existing issue. If so, please provide a link to the issue:
• Breaking new feature. If so, please describe details in the description part.

Describe the technical details

What is currently done? (Provide issue link if applicable)

What does this pull request change?

Which part of the code base require a change

• Tcl
• QT-Main
• Multithread
• Waveform Viewer
• Schematic Viewer
• Text Editor
• Console
• Replay
• Compiler Flow
• Project setup
• Reports
• Code smell
• Continous Integration (CI) scripts

Impact of the pull request

• Require a change on Quality of Results (QoR)
• Break back-compatibility. If so, please list who may be influenced.

Describe the bug
A clear and concise description of what the bug is.

The CMakefile requires C++17 standard as the minimum requirement

I do not know if this will cause some incompatibility for any libraries.

OpenFPGA is complying with C+14, so is VPR:

https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/5409e84341dde0292951c273ffc3b5c2065a2fec/CMakeLists.txt#L90

Expected behavior
May need a discussion to see if the C++17 will cause any issues

Steps to reproduce:

1. run command:
   make debug && make test/valgrind

Results:
checking of bin/foedag waits for the user input.

I intend to implement the following functions on the dialog.

New project wizard
Project Location
    project name(default project_1)
    project location (support create subdirectory)
    
Project Type
    RTL project (default)
    Post-synthesis project
    
Add Design Source Files
    Add files
    Add directories
    Create file
        file name
        file type
        file path
    Display source file list
    Remove
    Move up
    Move Down
    Support copy design files to project
    
Add Constraints
    Add files
    Create file
        file name
        file type
        file path
    Display source file list
    Remove
    Move up
    Move Down
    Support copy files to project
    
Select device/board
    Display the device/board list(Read data form a device/board file(like *.xml))
    Support search by family, device，package and so on.
    
Summary
    Displays the details of the project you are about to create.

The project type and file type can be configured through a configuration file(like *.xml).

After clicking finish, the project file and project directory will be generated.As follows:

About the widget window floorplanning ,I will do it soon by QT designer.

Open to discussion here.

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Clone repository and checkout commit id:
2. Execute a test case or your own example:
3. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Enviornment (please complete the following information):

• OS:

• Compiler:

• Version:

Additional context
Add any other context about the problem here.

The console eats carriage returns
This command works:

batch { synth ; globp }

That command does not work (globp is not executed):

batch {
synth
globp
}
The carriage return in between synth and globp is gone when it reaches here:
https://github.com/alain-rs/FOEDAG/blob/b9d16b1d0b5effe5dfc910fd8fbf85777c75e4b5/src/Compiler/Compiler.cpp#L182

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

This isn't an urgent matter at all, I'm just posting for future discussion.

Is your feature request related to a problem? Please describe.
Problem: Distributing software for Linux platforms has always been painful compared to Windows and Mac. There are 2 conventional methods:

1. The developers offers source code and the user has to build it.
   This approach burdens the developers the least (in a sense) yet can cause the user much trouble. Missing libraries, outdated toolchains...you name it. Uninstalling and updating the software can also prove to be difficult.
2. The developers offers the binary package and the user installs it via comands like apt install
   Users can still counter dependency issues but it should be much milder than the troubles from building the source. This method also allows incremental updates. This time the headache is the developers', as different Linux distributions use different packages, for example .deb packages cannot be installed on RPM-based distros and vice versa. Adding to the confusion, even distros using the same package formats might not be able to use the same package. RHEL and SUSE are both RPM-based but their RPMs are different, for instance. This method requires the developer to maintain the packages themselves -- they'll have to choose between either diverge significant effort to maintain packages for each Linux distro, or focus on a small range of distros and leave users of other platforms to build the software from source.

Describe the solution you'd like
Enter the concept of Universal Apps, where the developers bundle their code and dependencies in an sandboxed package and the user can safely run/installed these ready-to-run software without worrying if their OS might conflict with the software. I recently had a taste of Universal Apps as a user and I think these 2 solutions feel pretty nice: Flatpak and AppImage. A user can easily install a Flatpak software by first installing flatpak (like sudo apt install flatpak) then running flatpak install <software_source_repository> <software_name>, whereas AppImage software is simply one execuatble file that can be launched by chmod +x <software_name>.Appimage (if the file doesn't have the execute permission) then ./<software_name>.Appimage. In both cases, the developer needs to maintain only 1 single binary package, period. Flatpak allows for incremental updates, and I think Appimage is starting to do so too.

Describe alternatives you've considered
Docker can definitely do the job -- OpenFPGA is already offering Docker images. But Docker might be overkill and still a bit complicated.

Snap is practically Canonical's counterpart of Flatpak, except Canonical completly controls the Snap platform much like how Apple controls App Store (we cannot distribute snap packages without uploading them to Snapcraft and have Canonical review our requests). In contrast, flatpaks can be hosted on our own repos.

Additional context
There are a few potential setbacks of Universal Apps.

1. Performance and size. Compared to conventional methods, Universal Apps tend to take more disk space, as they rely on bundled dependencies, instead of reusing what the OS already has. Universal Apps also seem to suffer from performance penalties, though I don't think either of these issues are of big concern for our GUI.
2. Worth the effort? Building an Universal App isn't exactly a cakewalk, especially when all of us lack the experience and have other priorities. If FOEDAG ends up mostly being used by FPGA companies to be the foundation of their own software suite, then offering it as an end-user-oriented Universal App might not make much sense. Besides that, a sandboxed FOEDAG might have trouble interfacing with EDA backends, but my grasp of Universal Apps is too thin to be sure right now.

I have this runtime issue:

~/FOEDAG$ ./build/bin/foedag --qml
QQmlApplicationEngine failed to load component
qrc:/mainWindow.qml:4:1: module "Qt.labs.platform" is not installed

We need to have a compile time cmake error if a QML component is missing.

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Clone repository and checkout commit id:
2. Execute a test case or your own example:
3. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Enviornment (please complete the following information):

• OS:

• Compiler:

• Version:

Additional context
Add any other context about the problem here.

Since we're going to use Qt's open source and @tangxifan asked about our GUI's license, I just checked Qt Open source Licensing FAQ and Qt Open Source Obligations of the GPL and LGPL. MIT licensed software can be integrated with GPL software, though not being a law expert and lacking experience with mixed-license open source projects, I'm not sure if that means we can take GPL/LGPL code from Qt (headers, libraries, modules etc.), modify it and then make it MIT, or do we have to keep our own MIT code strictly seperated from Qt's GPL/LGPL code, or how else should this be properly handled. As the definitive versions of all the above licenses are in English, I recommend someone in the States consult a law expert familar with this field. Keep in mind that GPL/LGPL both have several versions so that's another thing to watch out for. If consulting a lawyer is not viable, maybe we should go with LGPLv3 for the peace of mind?

Add Ctrl+F support for the console.

Currently one of the test - console_multiline - didn't finish successfully. Look at the log:

TEST_LOOP_ENTERED
CONSOLE GUI: pwd command
SUCCESS
CONSOLE GUI: source command
SUCCESS
CONSOLE GUI: multiline
CONSOLE GUI: cancelation
SUCCESS
GUI EXIT

there is no SUCCESS keyword after running test. Tcl didn't wait and can't check status from Qt.
This test should fail but it still pass.

Need to apply general solution and not only fix for the console.

Possible solution:
Tcl waits for some event from Qt for ending. If there is no such event, fail test after some timeout.