Just as simple as that: just build and test on a MacOs system to see what needs to be fixed, etc. The current developers do not have access to a Mac so we need someone else to do this.

Hey there, I just wanted to share with folks who might be having an issue getting OpenImageIO built / installed on linux. If you simply install the Linux version of Homebrew (Linuxbrew), you can install OIIO using brew. It takes a bit (took about 10 minutes) but it will get the job done. :+1:

Thanks, -MH

Settings/tabs I am thinking we are going to include in the dialog, so far:

• [ ] Node wire curvature (e.g: 0 is straight, 8 is curved, etc)
• [ ] Maybe some settings for enabling/disabling node cache as it may not always be needed/wanted
• [ ] Node Manager (add/remove enable/disable available nodes)
• [ ] Enable/disable "experimental" features
• [ ] Toggle showing image thumbnails on nodes by default
• [ ] Fonts path (default could be the system font folder)
• [ ] Default output folder (default could be the home folder of the users computer)
• [ ] Whether to position the Add Node menu based on the cursor location or just have it static (placed at the bottom corner)
• [ ] Toggle showing the statusbar by default

This is a very difficult, work-in-progress PR to implement GLSL shader support (and thus GPU image processing) in the node API. It is currently demonstrable via the Opacity and Alpha Over Node, so feel free to test it out. 😃

There are a bunch of things to be worked out before merging this PR:

• [x] Implement ability to have multiple image inputs into the shader. Currently, you can only pass a single image into the shader. This works for nodes like Opacity, but the ability to pass in multiple images is needed in order to implement nodes like Mix, etc.
• [x] Figure out loading GLSL from a file rather than hardcoding it in the python file.
• [x] Work on code organization. (e.g: what is the best place for the GLSLRenderer class?)
• [x] Refine the API (Passing in props to the shader could be easier, I think. Though, we don't want too much overhead.)
• [x] Make sure to call Release on application quit.
• ~~When two nodes in a row are using GLSL shaders, it would be nice to keep the data on the GPU to reduce overhead. This could be achieved with the Swap method, but details need to be worked out.~~ Not in this PR
• ~~Implement 16-bit support via (uint16). Currently, only has 8-bit (uint8) support.~~ Not in this PR

At the moment, this uses ModernGL to give us access to an OpenGL 3.3+ context. Maybe other libraries would be better?

I am open to your critiques and thoughts on possible solutions @iwoithe, @JohJakob and others...

This will close #27

Describe the bug When I was doing testing in the fresh VM, after building and attempting to run the application for the first time, it seems it was able to create ~/.gimelstudio/ but it was not able to create the config file itself.

10075 INFO: Removing dir /home/mosthated/dev/github/GimelStudio/dist/GimelStudio
10135 INFO: Building COLLECT COLLECT-00.toc
10446 INFO: Building COLLECT COLLECT-00.toc completed successfully.
Build complete. Run GimelStudio now? y/n y
mosthated@pop-os:~/dev/github/GimelStudio$ [INFO] Registered core nodes
[INFO] Registered custom nodes
Traceback (most recent call last):
  File "main.py", line 67, in OnInit
AttributeError: 'NoneType' object has no attribute 'upper'
OnInit returned false, exiting...

I tried it a second time, starting it directly instead of letting the build script start it, just in case that has anything to do with it, but it had the same results.

mosthated@pop-os:~/dev/github/GimelStudio/dist/GimelStudio$ ./GimelStudio 
[INFO] Registered core nodes
[INFO] Registered custom nodes
Traceback (most recent call last):
  File "main.py", line 67, in OnInit
AttributeError: 'NoneType' object has no attribute 'upper'
OnInit returned false, exiting...

Once I manually created the config file by just copying it from my desktop into the VM's ~/.gimelstudio/pr1-config.json, it fired up just fine.

I didn't have this issue with my desktop. Upon first run, it created the folder and config file. The only real difference between the environments is my desktop was using pyenv to create the build and not the system install of py3, like the VM. I am wondering if since pyenv is installed and ran from $HOME/.pyenv/bin/, it might have something to do with it, but I feel like the built application, after the fact, it would not matter?

To Reproduce Steps to reproduce the behavior: From a fresh VM, navigate to dist/GimelStudio and execute the application via: ./GimelStudio If you create a config manually in ~/.gimelstudio/pr1-config.json, then start it again, it works. If you then remove/rename the config, ex. pr1-config.json.bak and try to start it again, it no longer works.

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

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

Desktop (please complete the following information): Issue does occur on:

python3 -V : Python 3.9.5
which python3: /usr/bin/python3

OS: Pop!_OS 21.04 x86_64 
Host: KVM/QEMU (Standard PC (Q35 + ICH9, 2009) pc-q35-5.2) 
Kernel: 5.15.5-76051505-generic 
Uptime: 39 mins 
Packages: 1910 (dpkg) 
Shell: bash 5.1.4 
Resolution: 1504x729 
DE: GNOME 3.38.4 
WM: Mutter 
WM Theme: Pop 
Theme: Pop-dark [GTK2/3] 
Icons: Pop [GTK2/3] 
Terminal: gnome-terminal 
CPU: AMD EPYC-Rome (24) @ 3.493GHz 
GPU: 00:01.0 Red Hat, Inc. QXL paravirtual graphic card 
Memory: 1439MiB / 15620MiB 

Issue does not occur on:

pyenv 2.2.1
pyenv python version: python3.9.9
whereis pyenv  - /home/mosthated/.pyenv/bin/pyenv

OS: Pop!_OS 21.04 x86_64
Host: X570 AORUS ELITE -CF
Kernel: 5.13.0-7620-generic
Uptime: 6 days, 21 hours, 10 mins
Packages: 3559 (dpkg), 171 (brew), 63 (flatpak), 13 (snap)
Shell: zsh 5.8
Resolution: 1920x1080, 2560x1080, 1920x1080
DE: GNOME 3.38.4
WM: Mutter
WM Theme: Pop
Theme: Materia-dark-compact [GTK2/3]
Icons: Flatery-Orange-Dark [GTK2/3]
Terminal: alacritty
CPU: AMD Ryzen 9 3950X (32) @ 3.500GHz
GPU: NVIDIA GeForce RTX 2070
Memory: 44962MiB / 64250MiB

Additional context I am going to install pyenv in the VM and then build with that and see if there is any sort of difference in behavior with the final application, I would not think there would be, but I guess that is what testing is all about.

Description

Rather raw implementation of multi-outputs for nodes and the switch to using properties for node values and connections (vs. the previous properties and parameters setup). A ton of breaking changes. This PR also updates all of the current nodes to be either fully or somewhat compatible with the changes. Some of the code is a mess and there are many things that need to be added, but in order to not make this PR huge I've cut it short to the bare minimum implementation.

Known things this PR breaks:

• Project file IO
• Node caching

Related issues

Systems Tested On

Windows 10

Checklist

• [x] I signed the CLA
• [x] There are no unnecessary or out-of-scope changes in this PR
• [x] Gimel Studio runs successfully on the above system(s) with the changes in this PR
• [x] The changes in this PR follow the style guides

Add the ColorProp class to property.py

Issue #93 (Implement node color property)

Systems Tested On: Windows 10

Checklist

• [x] I signed the CLA
• [x] There are no unnecessary or out-of-scope changes in this PR
• [x] Gimel Studio runs successfully on the above system(s) with the changes in this PR
• [x] The changes in this PR follow the style guides

Description

Update to build process for Linux systems

Related issues

https://github.com/GimelStudio/GimelStudio/issues/118

Systems Tested On

Pop_OS 21.04

Checklist

• [x] I signed the CLA
• [x] There are no unnecessary or out-of-scope changes in this PR
• [x] Gimel Studio runs successfully on the above system(s) with the changes in this PR
• [x] The changes in this PR follow the style guides

Closes https://github.com/GimelStudio/GimelStudio/issues/2

Todo

This PR is marked as a draft as there is still quite a bit of work to do. I have added a (rough) to do list below.

• [x] Make a final decision on the name (out of Preferences, Settings, or Options)

• [x] Add an accent to the currently selected button

• [x] Add the preferences themselves

• [ ] ~Make the widgets expand to fill the whole notebook~ Not this PR

When merged, this PR will not include

• The "special" pages (add-ons, nodes, and templates)
• Reset settings to defaults
• Search/filter settings

Current Progress

Toggles like “Toggle Status Bar” should have a different label based on their state to better indicate what they will do when clicked. For the status bar, this could be “Show Status Bar” and “Hide Status Bar” or it could be replaced with a checkbox toggle like “Auto Render”.

This would also make translations in certain languages (like German) easier because they do not have a convenient term like “toggle” (in German, the only fitting translation is “umschalten”, but it is a bit ambiguous). The same would apply to the help texts.

There is no real difference between user preferences and settings in Gimel Studio. It would make sense to simplify the term “User Preferences” and just call it “Preferences”. This would also shorten the term in German from “Benutzereinstellungen” to “Einstellungen” which is more desirable.

I would also append an ellipsis (…) to the menu item to let the user know that the action requires more actions/opens a dialogue. Both macOS and Blender use “Preferences…”.

Currently Bootstrap icons are being used for GS 1. At some point it would be nice to switch to a custom icon set. Also comes from the point that there more icons will need to be made anyway as Bootstrap icons won't always have a suitable icon.

Style

Lined, rounded style icons

Ideas:

Duo-tone icons

Description

The next re-write of Gimel Studio. More details to come soon.

Current Progress

As of writing, I am still working on the base of the project which will probably take a few months to complete. Note that there won't be much to see during this period.

You can see the issues for this re-write here.

Related issues

N/A

Systems Tested On

• Windows 10
• Linux (Slackware/XFCE 4)

Checklist

• [x] I signed the CLA
• [x] There are no unnecessary or out-of-scope changes in this PR
• [x] Gimel Studio runs successfully on the above system(s) with the changes in this PR
• [x] The changes in this PR follow the style guides

Currently, we do not have pre-built python wheels for OpenImageIO. OpenImageIO is only used for image I/O so it is not necessarily a hard dependency. OpenCV doesn't provide all of the same support for the formats OIIO does, but that is the tradeoff. :/

This issue should implement cv2 (which is already a dependency) as a fallback for image Input and output when OIIO is not installed. It should also alert the user that the image import and export may be limited because of using cv2 rather than OIIO.

Currently, you have to restart Gimel Studio every time you make a change to a node. Add the ability to reload and refresh the nodes in Gimel Studio without restarting. Take a look at the src/GimelStudio/node_importer for an idea how they are loaded in on application start.