Add GUI tools for Clementine

[gallottino]

Now it is possible use some kind of graphic debug tools in the UI. You can easily add new ones and edit existing ones.

N.B. I also refactored all the structure of our workspace

[guerinoni]

There are some missing empty line at the end and usually other internale dependencies are not called packages but just put in a flat structure like

├── Cargo.lock
├── Cargo.toml
├── src/
│   ├── lib.rs
│   ├── main.rs
│   └── bin/
│       ├── named-executable.rs
│       ├── another-executable.rs
│       └── multi-file-executable/
│           ├── main.rs
│           └── some_module.rs
├── emulator/
│   ├── large-input.rs
│   └── multi-file-bench/
│       ├── main.rs
│       └── bench_module.rs
├── ui/
│   ├── simple.rs
│   └── multi-file-example/
│       ├── main.rs
│       └── ex_module.rs

[guerinoni]

Another possible useful feature is https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#inheriting-a-dependency-from-a-workspace for managing more than one workspace dependencies

[gallottino]

There are some missing empty line at the end and usually other internale dependencies are not called packages but just put in a flat structure like

├── Cargo.lock
├── Cargo.toml
├── src/
│   ├── lib.rs
│   ├── main.rs
│   └── bin/
│       ├── named-executable.rs
│       ├── another-executable.rs
│       └── multi-file-executable/
│           ├── main.rs
│           └── some_module.rs
├── emulator/
│   ├── large-input.rs
│   └── multi-file-bench/
│       ├── main.rs
│       └── bench_module.rs
├── ui/
│   ├── simple.rs
│   └── multi-file-example/
│       ├── main.rs
│       └── ex_module.rs

I'm not sure how it works, but my purpose was to divide them into packages mainly for two reasons:

• You can execute test only for emulation or only for ui (and in future for other packages) with: cargo test -p emu_clementine
• Emulation it is not only a local dependency but can be also build independently from others. In this way it is possible build custom ui from the emulation package and an user is not forced to use our.

I don't know what is the best practice, but I wrote this only to clarify my thoughts.

[guerinoni]

There are some missing empty line at the end and usually other internale dependencies are not called packages but just put in a flat structure like

├── Cargo.lock
├── Cargo.toml
├── src/
│   ├── lib.rs
│   ├── main.rs
│   └── bin/
│       ├── named-executable.rs
│       ├── another-executable.rs
│       └── multi-file-executable/
│           ├── main.rs
│           └── some_module.rs
├── emulator/
│   ├── large-input.rs
│   └── multi-file-bench/
│       ├── main.rs
│       └── bench_module.rs
├── ui/
│   ├── simple.rs
│   └── multi-file-example/
│       ├── main.rs
│       └── ex_module.rs

I'm not sure how it works, but my purpose was to divide them into packages mainly for two reasons:

• You can execute test only for emulation or only for ui (and in future for other packages) with: cargo test -p emu_clementine
• Emulation it is not only a local dependency but can be also build independently from others. In this way it is possible build custom ui from the emulation package and an user is not forced to use our.

I don't know what is the best practice, but I wrote this only to clarify my thoughts.

Can I push it behind this?

[gallottino]

There are some missing empty line at the end and usually other internale dependencies are not called packages but just put in a flat structure like

├── Cargo.lock
├── Cargo.toml
├── src/
│   ├── lib.rs
│   ├── main.rs
│   └── bin/
│       ├── named-executable.rs
│       ├── another-executable.rs
│       └── multi-file-executable/
│           ├── main.rs
│           └── some_module.rs
├── emulator/
│   ├── large-input.rs
│   └── multi-file-bench/
│       ├── main.rs
│       └── bench_module.rs
├── ui/
│   ├── simple.rs
│   └── multi-file-example/
│       ├── main.rs
│       └── ex_module.rs

I'm not sure how it works, but my purpose was to divide them into packages mainly for two reasons:

• You can execute test only for emulation or only for ui (and in future for other packages) with: cargo test -p emu_clementine
• Emulation it is not only a local dependency but can be also build independently from others. In this way it is possible build custom ui from the emulation package and an user is not forced to use our.

I don't know what is the best practice, but I wrote this only to clarify my thoughts.

Can I push it behind this?

Of course!