No entire COVID-19 statistics data of the Shanghai lockdown period can be found in the JHU CSSE COVID-19 Data project. Data of project shanghai-lockdown-covid-19 is crawled from Shanghai Government‘s public website, began on 19/03/2022, the date of my place lockdown.

Shanghai is divided by the Huangpu River into two parts, the Pudong area, and the Puxi area. Pudong’s lockdown began on 28/03/2022 firstly, and Puxi started its shutdown on 01/04/2022.

Shanghai Government has announced its city-wide lockdowns will be gradually lifted from 1 June on 16/05/2022, after 15 out of 16 districts achieving “social dynamic Zero-Covid cases”. My place alse reopened on the same day, but with some limits.

Shanghai returned to normal on 1 June, the epidemic wave in the city is under control effectively and this project has stopped updating at 2 June.

Data files can be found in directory data, including:

• JSON
• CSV
• Excel
• Sqlite

Notice: I think db files are too large, and they will make this repo hard to clone. If you want to get the latest db files, uncomment the line in db.py and run the file to generate all db files.

I have disabled the update workflow at 2 June, this project will not be updated anymore.

This project will be updated every 15min between 8am and 10pm GMT+8 by GitHub Actions.

git clone --depeth=1 https://github.com/lewangdev/shanghai-lockdown-covid-19.git

• New Cases = Confirmed Cases + Asymptomatic Cases – A2C Cases
• A2C Cases: Asymptomatic cases that are confirmed

• Shanghai Municipal Health Commission’s website

Fortify is a puzzle game where your objective is to protect teddy 🧸

This game was made during the Global Game Jam 2019 (GGJ). The theme of the jam was:

What home means to you

This project was bootstrapped with phaser-template and hosted on remarkablegames. To learn more, read the following blog post.

Play this game on:

• remarkablegames
• Newgrounds

• Node.js
• npm

Clone repository:

git clone https://github.com/remarkablegames/fortify.git

Install dependencies:

npm install

In the project directory, you can run:

Runs the game in the development mode.

Open http://localhost:3000 to view it in the browser.

The page will reload if you make edits.

You will also see any lint errors in the console.

Builds the game for production to the build folder.

It correctly bundles in production mode and optimizes the build for the best performance.

The build is minified and the filenames include the hashes.

Your game is ready to be deployed!

Bumps the package.json using standard-version.

Deploys the game to GitHub Pages by force pushing the build folder to the remote repository’s gh-pages branch.

If you’re uploading the game to a site, make sure to do the following:

1. Open package.json and change the "homepage" value to ".". This ensures the links are relative. Optional: update the game config url in src/index.js.

2. Optional: remove GitHub Corners from public/index.html and src/index.css.

3. Build the game, remove any unnecessary files, and compress the folder into a zip archive:

   npm run clean
   npm run build
   rm build/service-worker.js
   zip -r fortify.zip build

4. Don’t forget to clean up the project directory after the upload succeeds:

   rm fortify.zip

MIT

A strong foundation for building predictable and straight-forward Rust UI toolkits. Reclutch is:

• Bare: Very little UI code is included. In practice it’s a utility library which makes very little assumptions about the toolkit or UI.
• Platform-agnostic: Although a default display object is provided, the type of display object is generic, meaning you can build for platforms other than desktop. For example you can create web applications simply by using DOM nodes as display objects while still being efficient, given the retained-mode design.
• Reusable: Provided structures such as unbound queue handlers allow for the reuse of common logical components across widgets.

Reclutch implements the well-known retained-mode widget ownership design within safe Rust, following along the footsteps of popular desktop frameworks. To implement this behavior, three core ideas are implemented:

• A widget ownership model with no middleman, allowing widgets to mutate children at any time, but also collect children as a whole to make traversing the widget tree a trivial task.
• A robust event queue system with support for futures, crossbeam and winit event loop integration, plus a multitude of queue utilities and queue variations for support in any environment.
• An event queue abstraction to facilitate just-in-time event coordination between widgets, filling any pitfalls that may arise when using event queues. Beyond this, it also moves the code to handle queues to the constructor, presenting an opportunity to modularize and reuse logic across widgets.

There appears to be a bug with shared OpenGL textures on MacOS. As a result, the opengl example won’t work correctly. For applications that require rendering from multiple contexts into a single texture, consider using Vulkan or similar.

• Events and event queues
• Otway

All rendering details have been excluded for simplicity.

#[derive(WidgetChildren)]
struct Button {
    pub button_press: RcEventQueue<()>,
    graph: VerbGraph<Button, ()>,
}

impl Button {
    pub fn new(global: &mut RcEventQueue<WindowEvent>) -> Self {
        Button {
            button_press: RcEventQueue::new(),
            global_listener: VerbGraph::new().add(
                "global",
                QueueHandler::new(global).on("click", |button, _aux, _event: WindowEvent| {
                    button.button_press.emit_owned(());
                }),
            ),
        }
    }
}

impl Widget for Button {
    type UpdateAux = ();
    type GraphicalAux = ();
    type DisplayObject = DisplayCommand;

    fn bounds(&self) -> Rect { /* --snip-- */ }

    fn update(&mut self, aux: &mut ()) {
        // Note: this helper function requires that `HasVerbGraph` be implemented on `Self`.
        reclutch_verbgraph::update_all(self, aux);
        // The equivalent version which doesn't require `HasVerbGraph` is;
        let mut graph = self.graph.take().unwrap();
        graph.update_all(self, aux);
        self.graph = Some(graph);
    }

    fn draw(&mut self, display: &mut dyn GraphicsDisplay, _aux: &mut ()) { /* --snip-- */ }
}

The classic counter example can be found in examples/overview.

Children are stored manually by the implementing widget type.

#[derive(WidgetChildren)]
struct ExampleWidget {
    #[widget_child]
    child: AnotherWidget,
    #[vec_widget_child]
    children: Vec<AnotherWidget>,
}

Which expands to exactly…

impl reclutch::widget::WidgetChildren for ExampleWidget {
    fn children(
        &self,
    ) -> Vec<
        &dyn reclutch::widget::WidgetChildren<
            UpdateAux = Self::UpdateAux,
            GraphicalAux = Self::GraphicalAux,
            DisplayObject = Self::DisplayObject,
        >,
    > {
        let mut children = Vec::with_capacity(1 + self.children.len());
        children.push(&self.child as _);
        for child in &self.children {
            children.push(child as _);
        }
        children
    }

    fn children_mut(
        &mut self,
    ) -> Vec<
        &mut dyn reclutch::widget::WidgetChildren<
            UpdateAux = Self::UpdateAux,
            GraphicalAux = Self::GraphicalAux,
            DisplayObject = Self::DisplayObject,
        >,
    > {
        let mut children = Vec::with_capacity(1 + self.children.len());
        children.push(&mut self.child as _);
        for child in &mut self.children {
            children.push(child as _);
        }
        children
    }
}

(Note: you can switch out the reclutch::widget::WidgetChildrens above with your own trait using #[widget_children_trait(...)])

Then all the other functions (draw, update, maybe even bounds for parent clipping) are propagated manually (or your API can have a function which automatically and recursively invokes for both parent and child);

fn draw(&mut self, display: &mut dyn GraphicsDisplay) {
    // do our own rendering here...

    // ...then propagate to children
    for child in self.children_mut() {
        child.draw(display);
    }
}

Note: WidgetChildren requires that Widget is implemented.

The derive functionality is a feature, enabled by default.

Rendering is done through “command groups”. It’s designed in a way that both a retained-mode renderer (e.g. WebRender) and an immediate-mode renderer (Direct2D, Skia, Cairo) can be implemented. The API also supports Z-Order.

struct VisualWidget {
    command_group: CommandGroup,
}

impl Widget for VisualWidget {
    // --snip--

    fn update(&mut self, _aux: &mut ()) {
        if self.changed {
            // This simply sets an internal boolean to "true", so don't be afraid to call it multiple times during updating.
            self.command_group.repaint();
        }
    }

    // Draws a nice red rectangle.
    fn draw(&mut self, display: &mut dyn GraphicsDisplay, _aux: &mut ()) {
        let mut builder = DisplayListBuilder::new();
        builder.push_rectangle(
            Rect::new(Point::new(10.0, 10.0), Size::new(30.0, 50.0)),
            GraphicsDisplayPaint::Fill(Color::new(1.0, 0.0, 0.0, 1.0).into()),
            None);

        // Only pushes/modifies the command group if a repaint is needed.
        self.command_group.push(display, &builder.build(), Default::default(), None, true);

        draw_children();
    }

    // --snip--
}

The update method on widgets is an opportunity for widgets to update layout, animations, etc. and more importantly handle events that have been emitted since the last update.

Widgets have an associated type; UpdateAux which allows for a global object to be passed around during updating. This is useful for things like updating a layout.

Here’s a simple example;

type UpdateAux = Globals;

fn update(&mut self, aux: &mut Globals) {
    if aux.layout.node_is_dirty(self.layout_node) {
        self.bounds = aux.layout.get_node(self.layout_node);
        self.command_group.repaint();
    }

    self.update_animations(aux.delta_time());

    // propagation is done manually
    for child in self.children_mut() {
        child.update(aux);
    }

    // If your UI doesn't update constantly, then you must check child events *after* propagation,
    // but if it does update constantly, then it's more of a micro-optimization, since any missed events
    // will come back around next update.
    //
    // This kind of consideration can be avoided by using the more "modern" updating API; `verbgraph`,
    // which is discussed in the "Updating correctly" section.
    for press_event in self.button_press_listener.peek() {
        self.on_button_press(press_event);
    }
}

The above code is fine, but for more a complex UI then there is the possibility of events being processed out-of-order. To fix this, Reclutch has the verbgraph module; a facility to jump between widgets and into their specific queue handlers. In essence, it breaks the linear execution of update procedures so that dependent events can be handled even if the primary update function has already be executed.

This is best shown through example;

fn new() -> Self {
    let graph = verbgraph! {
        Self as obj,
        Aux as aux,

        // the string "count_up" is the tag used to identify procedures.
        // they can also overlap.
        "count_up" => event in &count_up.event => {
            click => {
                // here we mutate a variable that `obj.template_label` implicitly/indirectly depends on.
                obj.count += 1;
                // Here template_label is assumed to be a label whose text uses a template engine
                // that needs to be explicitly rendered.
                obj.template_label.values[0] = obj.count.to_string();
                // If we don't call this then `obj.dynamic_label` doesn't
                // get a chance to respond to our changes in this update pass.
                // This doesn't invoke the entire update cycle for `template_label`, only the specific part we care about; `"update_template"`.
                reclutch_verbgraph::require_update(&mut obj.template_label, aux, "update_template");
                // "update_template" refers to the tag.
            }
        }
    };
    // ...
}

fn update(&mut self, aux: &mut Aux) {
    for child in self.children_mut() {
        child.update(aux);
    }

    reclutch_verbgraph::update_all(self, aux);
}

In the verbgraph module is also the Event trait, which is required to support the syntax seen in verbgraph!.

#[derive(Event, Clone)]
enum AnEvent {
    #[event_key(pop)]
    Pop,
    #[event_key(squeeze)]
    Squeeze(f32),
    #[event_key(smash)]
    Smash {
        force: f64,
        hulk: bool,
    },
}

Generates exactly;

impl reclutch::verbgraph::Event for AnEvent {
    fn get_key(&self) -> &'static str {
        match self {
            AnEvent::Pop => "pop",
            AnEvent::Squeeze(..) => "squeeze",
            AnEvent::Smash{..} => "smash",
        }
    }
}

impl AnEvent {
    pub fn unwrap_as_pop(self) -> Option<()> {
        if let AnEvent::Pop = self {
            Some(())
        } else {
            None
        }
    }

    pub fn unwrap_as_squeeze(self) -> Option<(f32)> {
        if let AnEvent::Squeeze(x0) = self {
            Some((x0))
        } else {
            None
        }
    }

    pub fn unwrap_as_smash(self) -> Option<(f64, bool)> {
        if let AnEvent::Smash{force, hulk} = self {
            Some((force, hulk))
        } else {
            None
        }
    }
}

get_key is used to find the correct closure to execute given an event and unwrap_as_ is used to extract the inner information from within the given closure (because once get_key is matched then we can be certain it is of a certain variant).

Reclutch is licensed under either

• Apache 2.0
• MIT

at your choosing.

This license also applies to all “sub-projects” (event, derive and verbgraph).

• Running Magento 2 project really fast on your machine.
• Just a few steps to setup.
• No extra step to deploy code from host to container.
• Easy to modify PHP, MySQL, and Nginx configurations.
• Works on Linux, macOS, and Windows.

• php:7.2-fpm
• mysql:5.7
• nginx:1.19

All OS: Install Git

Linux: Install Docker and Docker-compose.

MacOS: Install Docker and Docker-compose.

Windows: Install Docker and Docker-compose.

git clone https://github.com/jaredchu/Magento2-Docker-Development.git [project_name]
cd [project_name]

• How to get Magento authentication keys
• How to get Github personal access token

docker-compose up -d
docker exec -it app bash -c "rm .gitkeep && composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition:2.3 . --prefer-dist --no-interaction --dev"

docker-compose down
docker-compose up -d

You can now start to install your new Magento 2 site via Web Setup Wizard (will be removed in Magento 2.4) or Command Line (recommended).

git clone https://github.com/jaredchu/Magento2-Docker-Development.git [project_name]
cd [project_name]

docker-compose up -d

docker exec -i db mysql -uroot -ppassword magento2 < your-database.sql

'db' => [
    'table_prefix' => '',
    'connection' => [
        'default' => [
            'host' => 'db',
            'dbname' => 'm2db',
            'username' => 'm2user',
            'password' => 'm2pw',
            'active' => '1',
            'driver_options' => [
            ]
        ]
    ]
],

Enter the app container TTY (to run any command without docker exec -i app prefix).

docker exec -it app bash

Run the composer installation:

composer install

Check magento command is working or not:

bin/magento --help

127.0.0.1	magento2.local
::1             magento2.local

docker exec -i app bin/magento config:set web/unsecure/base_url http://magento2.local/
docker exec -i app bin/magento config:set web/unsecure/base_link_url http://magento2.local/
docker exec -i app bin/magento config:set web/secure/base_url https://magento2.local/
docker exec -i app bin/magento config:set web/secure/base_link_url https://magento2.local/

docker-compose down
docker-compose up -d

Modify .env, replace RESTART_CONDITION=no with RESTART_CONDITION=always.

docker exec -i app bin/magento [parameters]

or

docker exec -it app bash
bin/magento [parameters]

All the common variables are in .env.

• src – your project root directory that contains composer.json and app folder.
• m2dd/local.ini – PHP configuration file.
• m2dd/my.cnf – MySQL configuration file.
• m2dd/auth.json – Composer basic auth file.
• m2dd/conf.d/ – Contains nginx configuration files.
• m2dd/ssl/ – Contains SSL certs.
• m2dd/crontabs/root – Crontab for root user.
• m2dd/crontabs/www – Crontab for www user.

Feel free for submitting pull requests to this project.

This project is using SemVer for versioning. For the versions available, see the tags on this repository.

• Jared Chu – Initial work – About Jared

See also the list of contributors who participated in this project.

This project is licensed under the MIT License – see the LICENSE.md file for details.

This package provides an easy way to quickly set up AdminLTE v3 with Laravel (7 or higher). It has no others requirements and dependencies besides Laravel, so you can start building your admin panel immediately. The package provides a blade template that you can extend and an advanced menu configuration system. Also, and optionally, the package offers a set of AdminLTE styled authentication views that you can use in replacement of the ones that are provided by the legacy laravel/ui authentication scaffolding.

If you want to use an older Laravel or AdminLTE version, review the following package releases:

• Releases 1.x: These releases supports Laravel 5 and include AdminLTE v2
• Releases 2.x: These releases supports Laravel 6 and include AdminLTE v2
• Releases 3.x (<=3.8.6): These releases supports Laravel 6 and include AdminLTE v3

All documentation is available at Laravel-AdminLTE Documentation site, we encourage you to read it. If you are new start with the Installation Guide. To update the package consult the Updating Guide.

The current package requirements are:

• Laravel >= 8.x
• PHP >= 7.3

You can report issues or ask questions in the issues section. Please, start your issue with [BUG] and your question with [QUESTION] in the subject.

If you have a question, it is recommended to make a search over the closed issues first.

To submit a Pull Request, fork this repository and create a new branch to commit your new changes there. Finally, open a Pull Request from your new branch. Refer to the contribution guidelines for detailed instructions. When submitting a Pull Request take the next notes into consideration:

• Verify that the Pull Request doesn’t introduce a high downgrade on the code quality.
• If the Pull Request adds a new feature, consider adding a proposal of the documentation for this feature too.
• Keep the package focused, don’t add special support to other packages or to solve very particular situations. These changes will make the package harder to maintain.

Graph traversal to walk through ESM dependency graph for further static analysis. The traversal algorithm is classified as Breadth-first search (BFS).

$ npm install deps-walker

Here is an example of an entry point module entry.js with its dependencies, which in turn depend on their dependencies, which in turn depend on…

//------ entry.js ------
import a from './a.js';
import b from './b.js';

//------ a.js ------
import b from './b.js';
import c from './c.js';
import d from './d.js';

//------ c.js ------
import d from './d.js';

//------ d.js ------
import b from './b.js';

In other words:

entry.js -> a.js
entry.js -> b.js
a.js -> b.js
a.js -> c.js
a.js -> d.js
c.js -> d.js
d.js -> b.js

deps-walker is used to traverse entry.js dependency graph:

const walk = require('deps-walker')();

walk('entry.js', (err, data) => {
  if (err) {
    // catch any errors...
    return;
  }
  const { filePath, dependencies } = data;
  // analyse module dependencies
});

The dependencies are traversed in the following order:

deps-walker support async/await API, it can be used to await traverse completion:

async function traverse() {
  await walk('entry.js', (err, data) => {
    /*...*/
  });
  console.log('Traverse is completed');
}

deps-walker supports multiple roots:

walk(['entry1.js', 'entry2.js', 'entry3.js'], (err, data) => {
  /*...*/
});

deps-walker uses @babel/parser with sourceType: 'module' option by default. You can specify any other available options:

const babelParse = require('deps-walker/lib/parsers/babel');
const walk = require('deps-walker')({
  parse: (...args) =>
      babelParse(...args, {
      // options
      sourceType: 'module',
      plugins: ['jsx', 'flow']
    })
});

or specify your own parse implementation:

const walk = require('deps-walker')({
  parse: (code, filePath) => {
    // parse implementation
  }
});

It is not always obvious where import x from 'module' should look to find the file behind module, it depends on module resolution algorithms, which are specific for module bundlers, module syntax specs, etc.. deps-walker uses resolve package, which implements NodeJS module resolution behavior. You may configure NodeJS resolve via available options:

const nodejsResolve = require('deps-walker/lib/resolvers/nodejs');
const walk = require('deps-walker')({
  resolve: (...args) =>
    nodejsResolve(...args, {
      // options
      extensions: ['.js'],
      paths: ['rootDir'],
      moduleDirectory: 'node_modules'
    })
});

You can also use other module resolution algorithms:

const walk = require('deps-walker')({
  resolve: async (filePath, contextPath) => {
    // resolve implementation
  }
});

You may break traversal for some dependencies by specifying ignore function:

const walk = require('deps-walker')({
  // ignore node_modules
  ignore: filePath => /node_modules/.test(filePath)
});

Module parsing and resolving can be resource intensive operation (CPU, I/O), cache allows you to speed up consecutive runs:

const cache = require('deps-walker/cache');
const walk = require('deps-walker')({ cache });
//...
await cache.load('./cache.json');
await walk('entry.js', (err, data) => {
  /*...*/
});
await cache.save('./cache.json');

You can also override the default file reader:

const fsPromises = require('fs').promises;
const read = _.memoize(filePath => fsPromises.readFile(filePath, 'utf8'));
const walk = require('deps-walker')({ read });

MIT

Welcome to my personal dotfiles repository, tailored for the 🐟 Fish shell. These configurations are designed to create a baseline for my development environment, integrating seamlessly with VSCode, Starship, tmux, etc.

• Prompt Customization with ⭐️🚀 Starship: A sleek, informative command-line interface built in Rust.

• Effortless Dotfile Management: Uses chezmoi for a streamlined process to update, install, and configure my environment with a simple one-line command.

• Intelligent OS Detection: Automatically installs OS-specific packages, ensuring compatibility and ease of setup.

• User-Guided Installation Script: Tailored setup with interactive prompts to select only the tools I need.

• Enhanced File Listing with eza: A more colorful and user-friendly ls command.

• Optimized Tmux Configuration: Benefit from a powerful Tmux setup by gpakosz, enhancing your terminal multiplexer experience.

  

Note: This setup is currently optimized for macOS and Debian-based Linux distributions.

To install, choose one of the following methods and execute the command in my terminal:

• Curl:

  sh -c "$(curl -fsLS get.chezmoi.io)" -- init --apply mmena1

• Wget:

  sh -c "$(wget -qO- get.chezmoi.io)" -- init --apply mmena1

• Homebrew:

  brew install chezmoi
  chezmoi init --apply mmena1

• Snap:

  snap install chezmoi --classic
  chezmoi init --apply mmena1

Keep my environment fresh and up-to-date with a simple command:

chezmoi update

This will fetch and apply the latest changes from the repository, ensuring my setup remains optimal.

Leveraging the best of oh-my-zsh, I’ve crafted custom Fish scripts, including git and eza abbreviations, enriching my shell without the need for plugins.

At the heart of my dotfile management is Chezmoi, a robust tool offering templating features to dynamically adapt scripts across various systems, alongside the capability to preview and verify scripts before execution.

A task-based approach is used for managing the setup and configuration of my development environment. Instead of running a monolithic script, the setup process is broken down into discrete tasks that can be individually registered, managed, and executed.

Key features of the task management system:

• Task Registration: Each setup component is registered as a task with a name, description, list of dependencies, and execution function.
• Dependency Resolution: Tasks specify their dependencies, ensuring they’re executed in the correct order. For example, package installation requires Homebrew to be installed first (only for macOS).
• Interactive Execution: Before each task runs, I’m prompted to confirm, letting me customize my setup process.
• Error Handling: If a task fails, I can choose to continue with the remaining tasks or abort the setup.
• Modular Implementation: Setup components are organized into modules (package management, shell configuration, development tools, etc.) that can be maintained independently.

This approach makes the setup process more maintainable, flexible, and user-friendly. New tasks can be added without modifying existing code, and dependencies are automatically resolved to ensure a smooth setup experience.

sequenceDiagram
    participant User
    participant SetupScript
    participant TaskManager
    participant TaskModule

    User->>SetupScript: Initiate environment setup
    SetupScript->>TaskManager: Register setup tasks
    TaskManager->>TaskManager: Check dependencies for each task
    TaskManager->>TaskModule: Execute task module (e.g., packages, tools, shell)
    TaskModule-->>TaskManager: Return task status
    TaskManager-->>SetupScript: Report consolidated task results
    SetupScript->>User: Display "Setup completed" message

A special thanks to:

• GitHub ❤ ~/ for a fantastic collection of dotfiles repositories.
• Adam Eivy’s dotfiles for inspiration on automation and design.
• Sebastián Estrella for introducing me to the world of dotfile management.
• LFreza for the invaluable memes and laughter shared during work.

This project is licensed under the ISC License – see Martin Mena for more details.

A library to capture and record from your audio and video devices.

Contains the main library and two example applications (command line and graphic interface).

A video presentation of the QT application can be found here.

1. Install dependencies

brew install ffmpeg
brew install fmt
brew install qt6

2. Build project

export CMAKE_PREFIX_PATH=/usr/local/Cellar/qt/6.2.2
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
cmake --build .  

1. Install dependencies

sudo apt-get install libavdevice-dev
sudo apt-get install libavfilter-dev
sudo apt-get install libfmt-dev
sudo apt-get install libxrandr-dev
sudo apt-get install pip
pip install -U pip
pip install aqtinstall
aqt install-qt linux desktop 6.2.0

2. Build project

sudo snap install cmake --classic
export CMAKE_PREFIX_PATH=~/6.2.0/gcc_64
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
cmake --build .  

1. Install CMake (>= 3.22)

2. Install Visual Studio environment for desktop c++ applications

3. Install Qt6 MSVC environment for desktop applications

4. Install dependencies

cd \
git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
.\bootstrap-vcpkg.bat
.\vcpkg integrate install
.\vcpkg install ffmpeg[avcodec,avdevice,avfilter,avformat,avresample,core,gpl,postproc,swresample,swscale,x264,ffmpeg]:x64-windows
.\vcpkg install fmt:x64-windows

5. Build project

cmake -DCMAKE_TOOLCHAIN_FILE=C:/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_BUILD_TYPE:STRING=Release -DCMAKE_PREFIX_PATH=C:/Qt/6.2.3/msvc2019_64 ..
cmake --build  . -- /property:Configuration=Release

6. Provide dependencies

• Release:

cd build\qt_screen_recorder\Release
C:\Qt\6.2.3\msvc2019_64\bin\windeployqt.exe -qmldir ..\..\..\qt_screen_recorder\components --release appqt_screen_recorder.exe

• Debug:

cd build\qt_screen_recorder\Debug
C:\Qt\6.2.3\msvc2019_64\bin\windeployqt.exe -qmldir ..\..\..\qt_screen_recorder\components --debug appqt_screen_recorder.exe

7. Run

set QSG_RHI_BACKEND=opengl // Might be needed for VMs
appqt_screen_recorder.exe

Iforgor is a customisable and easy to use command line tool to manage code samples.
It’s a good way to quickly get your hand on syntax you dont remember right from your terminal without wasting time looking on the internet.

Creates symlinks of iforgor.py and the snippets folder to /usr/local/bin. So that it can be run from anywhere on the terminal.

• Python.
• Git.
• The colorama python module.

1. Open a terminal and cd into the directory you want to install the program into.

2. Run “git clone https://github.com/Solirs/iforgor/“

3. Cd into the newly created “iforgor” directory

4. Run “./setup.sh” as root (it has to be run as root since it needs to create files in /usr/local/bin), add the ungit argument to remove github related files and folders like the readme and license.

5. Run “iforgor -h”

If it works, the install was successful.
You can then delete setup.sh

To uninstall, simply delete the ‘iforgor’ and ‘snippets’ symlinks in /usr/local/bin.

Then delete the iforgor folder.

To display a piece of code, run the following.

iforgor LANGUAGE SNIPPET

The language argument represents a folder in the “snippets” directory.
You can add any language you want by creating a folder in it.

The snippet argument represents a *.txt file in the specified language directory that containd the code sample you want to display.
You can add any code sample by creating a *.txt in a desired language folder.

So if you want to add a function sample for the, lets say Rust language for example.
You will have to create a directory named “rust” in the snippets folder.
And create a function.txt file in the rust folder with the code you want inside.

You can then print it out by running iforgor rust function

• Languages and snippets are case insensitive. So you can run ‘iforgor lAnGuAgE sNiPpeT’.

• You dont need to do the setup process, but its required if you want to be able to run iforgor easily from anywhere.

• There are default snippets yes, but iforgor is designed to be customized, dont hesitate to add your own custom snippets and languages.

This should work on pretty much any linux distro, but i can make mistakes, so dont hesitate opening an issue if you face problems.

Iforgor was tested on:

Debian 11 : Working

Void Linux : Working

Arch Linux : Working

Those are less certain to work, but you can still give it a try.

Tested on:

FreeBSD : Working

OpenBSD : Working

Sure. All help is accepted.

The code is very commented if you want to take a look at it.

PLEASE dont forget to star the project if you find it interesting, it helps out a ton.