Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Brew #29

Open
duskfallcrew opened this issue Jan 14, 2025 · 4 comments
Open

Brew #29

duskfallcrew opened this issue Jan 14, 2025 · 4 comments
Assignees
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed

Comments

@duskfallcrew
Copy link
Collaborator

Porting installation at some stage into Homebrew once we're functional enoguh

@duskfallcrew duskfallcrew converted this from a draft issue Jan 14, 2025
@duskfallcrew duskfallcrew added enhancement New feature or request help wanted Extra attention is needed good first issue Good for newcomers labels Jan 14, 2025
@duskfallcrew duskfallcrew added this to the Brew Installation & Pypi milestone Jan 14, 2025
@exdysa
Copy link
Collaborator

exdysa commented Jan 15, 2025

Where we are feature wise:

  • We open jpeg, png, webp, text, json and toml files with (from what I can tell) a high degree of accuracy and a low percent of failure.
  • We open ComfyUI and A1111 style tags, and they look nearly identical in the viewer.
  • Our file list is sorted alphanumerically.
  • The app launches in the current working folder for compatibility with file explorers.

Code wise we look like this:

  • The metadata display headers, supported file types, are dynamically created, allowing for easy future expansion.
  • The code is broken into small chunks to make it less redundant and simpler to maintain.
  • Stability has been greatly improved.
  • Metadata parser in particular is quite solid and thoroughly tested.
  • There are a few remaining hard-coded tag names for ComfyUI that I have not abstracted out into the types file. They've been standard since ComfyUI started, and they're only used in one or two places, so I think we can get by.
  • We probably can't edit and pack the metadata BACK into the file easily with the way things are. My thought is we would need to add a routine to cut the json from the file, add a lot more type checks when reading, then re-write the image file with the new data. We could do it, but its a lot of work. I know you said don't worry about it, but if we did pursue it in the future we should definitely discuss why between ourselves and our users.
  • We could use more (ANY) tests for the ui and widgets.py file, so that changing them in the future involves less poking in the dark. I can try to do this today or tomorrow.

Goals :

  • Arrow keys ought to select image also instead of only mouse, especially since were working towards accessibility.
  • Launch image viewer on double click? Image preview turns into larger image inside the app? I'm not sure which to choose but things certainly feel like they should be clickable, and leaving them the way they are at the moment feels broken.
  • We don't have themes yet. I know you want them real bad, I still need to do research as I've been focused on core functionality. If they are done poorly I think they can be an eyesore and make us look like bad designers, so I'd like to take care in how we pursue it. (I'm admittedly biased as well to the simplicity of the current light/dark modes)
  • Thumbnails? Would they lower responsiveness? Litter the file system? If not, I think we can look into it, but this is precluded by my learning more QT, and I have yet to really find a simple resource.
  • Again, I really really think it would be useful to open safetensors/gguf/pt LoRA/checkpoint/embedding metadata and I already have the components built
  • Idk, shorten the redundant file paths in the file list? Im not sure what else should be done.
  • I need to clock interaction speed and benchmark on my intel macbook, and mayyybeee test on my old pc as well.

We may be at the point we could work the thing into brew already, but with these together it would be ideal. Though that would require research too. For windows users, we could use an installer like BeeWare or PyInstaller, but in general Windows will flag the software as potential malware unless we get a formal credential certificate, which is $$

@duskfallcrew
Copy link
Collaborator Author

Well, uhm -- Windows doesn't USE brew?
it's only Linux/Mac.
So windows doesn't need a $$$.

Mac's $$$ is when you have a DMG file installer..
Because SD prompt reader has that, and ... well nobody's paying 99 per program per lisc XD

Pypi would cover windows mostly.

But yea, Brew's just a good package handler, and one used trusted in the AI and Open Source commmunity- - HELL I HAVE SUPER TUX ON MY THING!

@duskfallcrew
Copy link
Collaborator Author

Also themes + drag and drop aren't a "NEED" for brew.
Brew is also easy to update, and semi easy to package.
If anything, if you want me to focus on that part, i'm happy to do THAT crawling since i know i've used brew and it's fairly simple.

I know you'er win/mac -- but Monterey isnt' as fussy as Ventura for stuff

@exdysa
Copy link
Collaborator

exdysa commented Jan 27, 2025

Well, uhm -- Windows doesn't USE brew? it's only Linux/Mac. So windows doesn't need a $$$.

it does require money. You have to pay for a signing certificate, otherwise virus scanners flag you. its less of an issue however because windows users are used to downloading random .exes and running them willy nilly.

brew is definitely a proper handler, but we should look at packaging with some kind of installer. and we need a brand icon AND an app icon.

PyPi should definitely come first!

if we have to be 'popular' first for brew (im suppressing a froTHING RANT HERE) then we definitely should look at https://github.com/beeware/briefcase

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed
Projects
Status: In Progress
Development

No branches or pull requests

2 participants