Thanks. I like helping for stuff like that.
Last but not least: when you make a lot of small changes, always do:
This way you won’t get lost. And don’t fix everything at once. Make a list of small changes and do that one at a time.
Also to make development easier:
Besides the duplication of standard code, I see this kind of mistake all the time. If your code can be reduced to “return path.exists” it’s an alias that shouldn’t be there.
My random shitty opinion, don’t take it personally, I didn’t slept well, also I’m late for work:
README: you use both py and python3, choose one because I’m confused! Also you say “Navigate to ./src/” No, I’m a lazy user and I want instructions that I can copy-paste, it’s always better when you clone a random project (especially at work) and be able to copy-paste, like:
py -m pip install -r requirements.txt
cd src/
py main.py
Be affirmative! Also “This will install pip” could be wrong on most systems, remove that sentence if not true.
Still in the README, why should I run the thing from src? Is your application broken if I I do “py src/main.py”? What happens?
It seems like the GUI and the code that watermarks are mixed and that’s annoying. If it was clearly separated, you could make a command-line versions of your application in 5 minutes without changing the GUI, for example with argparse.
Why is there so much code to set the layout in main.py? Put that stuff in Layout, I don’t want to see that in my main. Also do “def main(): …” and “if __name__ == ‘__main__’” or something, it’s cleaner, and it prevents errors if I “import main”
Do you really really need all those members variables? I understand that Tk is weird, but ImageManager has 12 members, main has 3 instead of 1 (the main “Window”), and Layout has a billion members. For example total_columns and total_rows are not used in Layout.py, that’s confusing. ImageManager.SAVE_DIR and IMAGE_RESIZE_FACTOR are constants, move them out. DEFAULT_FOLDER is only used once, merge it with TEST_BG, that kind of thing.
ImageManager.path_is_valid is useless and potentially harmful because you’re duplicating standard code, remove it and use path.exists, no need to replicate the standard library, and other coders know what’s inside the path module, they don’t know what’s in your code and why it’s different from the standard modules because they’ll think “if it’s there, it must do something special!” (but it’s not special at all here)
Ideally you shouldn’t put testing code in your main code. TEST_BG and TEST_FG will have to be removed. I understand why it’s there, it’s faster for your test, but it always show that the architecture has flaws. For example here, it shows that you forgot to make it possible to load those things on the command line, like main.py --test-bg space.png --test-fg python-watermark.png or better main.py --bg space.png --fg python-watermark.png, see? You have the beginning of a command-line application!
On GitHub you have 6 branches, that’s madness. Merge them all one at a time, or delete them. Too many experiments are not good.
You commit messages are good and expressive, that’s nice! Also I see that you used the standard .gitignore for Python on GitHub, that very nice and way better than doing one from scratch who will miss a lot of stuff.
I’ll come back later if I can.
Edit: there is hardcoded paths “/home/mike/code” and no default pictures, I can’t test it right now, that’s something to fix too.
And very very expensive.
I liked the answer that I once saw here: “Real men do whatever the fuck they want.” No one cares about this kind of judgmental assholery.
Don’t forget to ask what is the other possible value(s) if the scenario doesn’t happen, because that is something forgotten most of the time.
I used pygit2 a few years ago and it was easy. Can’t complain.
I have a cure for all cancers. Except that bodies refuse to use its molecules, but it still cures cancer in theory. That’s how agile have always been used around me.
Agile wants to empower devs, but managers do not want this.
It assumes that: devs can and have the right to talk to the final user, devs can negotiate anything, and devs can make plans. Where I’ve used agile, the whole circus was taken hostage by the managers and there was nothing you could do about it.
You’ll tell me it’s not real agile, but it’s like real communism, I’ve never seen it.
Most companies I’ve worked for “do agile because agile” and everything revolves around agile. And you can’t change this because they decide and they have the money.
It’s not Agile’s fault
that managers want to stay in control of everything, and they decide whether they do it or not.
It’s like real communism: it’s perfect but it’s not possible to implement in our universe.
Amazing that this scam hasn’t been banned yet by Google.
FLAC is supposed to be way smaller: https://hbfs.wordpress.com/2012/02/07/looking-at-flac-compression-ratios/
I use Opus at 192 kbps. It’s overkill but it should be almost perfect and has the size of an MP4.
There are 5 or 6 ridiculous questions about AI at the beginning. They should have made it less obvious.
Handlers, module managers, any shitty thing that handle stuff or load stuff, but has a name more obscure than a philosophical book. God I hate this.
But how can you show them that you bought an overpriced shirt made by a child in Bangladesh?
no-code effort
And we know that the no-code fad was very successful in the past.
With an infinite supply of shitty projects created by “devs” who can’t code, I’ll have a guaranteed job for ever. Thanks AI!
Tutorial on python.org.
Curl.