Updates on Making Themera better.

[PySimpleGUI]

I have 2 very long issues that hold ALL of my images. I don't upload them to files for readme's. Instead I copy and paste or drag and drop into my "screenshots" issue.

Like this shot is a simple "screen copy" that's on my clipboard. I pasted here:

You will notice when you're editing the issue that when you drag and drop or copy and paste, a line like this is added:

![image](https://user-images.githubusercontent.com/46163555/70379106-a22b7580-18f6-11ea-9756-44d0f9528bcd.png)

You can then take that URL with the .jpg or .png file and use it directly in your readme.

Done... no fuss, no uploading stuff to github folders. The Issue can even be closed where people don't see it. Like this one in my GitHub:

https://github.com/PySimpleGUI/PySimpleGUI/issues/1897

Doing this is using GitHub as an image file server. I use it for Reddit posts. All kinds of shit. It's easier than Imagr and other services. Drop, drop, copy the link it makes and paste into your Reddit post and off you go.

This is how I make stuff like readme's, cookbooks, etc, with great speed.

[PySimpleGUI]

And by the way, I'm actually also a graphic designer

🤦🏻‍♂️

DOH!

Sorry! Man, it was a really really really long night. Not at all trying to be a know-it-all but rather just share stuff I've learned over the years. It took me a long time of working next to artists to understand how their world and brain is completely different than mine and other software engineers. It was an experience that I really value and wish more software people were working with artistic people nearby.

[definite-d]

No offence taken, that's okay. You were only trying to explain properly.

[definite-d]

Hello there.

I understand that I promised to upload the new version with the perfected shuffle and all (v2.6) after I fixed the bug, but I've decided to slip in one last feature. Well, it's more of a UI improvent rather than a feature.

It's an extension module for PySimpleGUI, which gives the ability to automatically reposition child windows to a specified parent window. I'm thinking of calling it Window Wrangler, and once I'm done, it will be up on its own repository.

I'm intending to add this module's functionality to LookyFeely, since the UI is constantly changing and thus future windows need to be able to position themselves well without manually moving them.

[PySimpleGUI]

I liked the changes you made and have been playing with the new shuffle feature. It's working well!

I'm interested in what you're describing with the windows. I've been experimenting a great deal with multiple window positioning. It's what enabled me to create what appears to be a window with a background image, something not easily accomplished with tkinter alone.

This is the result of "locking" two windows together. The problem I faced however is that it only works correctly when I use "grab anywhere". I've not got it working when moving using the titlebar.

[definite-d]

Wow.

As expected, you've already seen a far more advanced an cool use case for such.

The extension module actually has two classes:

• WindowContainer: For getting out the location values of different points in the window supplied ( like the upper left corner, center of the window etc)

• WindowManager: For doing the actual heavy lifting with a parent window and child windows specified.

So, if I need a window to move to the parent at the click of a button, I simply call the WindowManager.reposition_window() function. This moves the child window specified as an attribute to the upper left corner of the parent window; what you'd expect to happen from manually getting the location of the desired reference window and then manually computing where the sub window should move to, then calling aMove and Refresh on the window.

By calling WindowManager.reposition_window(somewindow, "UC", "UC"), I can have somewindow move to the parent window's top-center as though I manually dragged the top-center of somewindow to align with that of the parent window (provided that somewindow is under the WindowManager's control).

[definite-d]

This comment is mainly about WindowWrangler, not LookyFeely.

Well, about an hour ago, I was certain I had a fully working solution for all window auto-location issues, but I actually ended up with a huge and complex location calculator that interferes with the functioning of the windows by calling their functions on its own and altering their Read structure, and that interference is a bad thing because windows exist within their own event loops and them having a timeout value complicates things further.

So, unfortunately, I'll have to scrap what I've done and go for a lighter solution that:

• simply returns the ideal location for any window in accordance with the location of a reference (formerly parent) window,

rather than

• jumping in and applying that location itself then having to call a Refresh or a separate Read. This is what I have now, and it works, but not as expected. (Hint: Using it with a timeout enabled window within the event loops gives a tk error. Using it outside stops the execution flow.)

It will be up to the judgement of the user to use that location tuple however he sees fit, most likely by calling the Move function.

Now that I think about it, (not considering that a one-liner function is always preferable for utility packages), that structure actually gives the user more control.

Having such a structure will probably enable the background image use-case you mentioned to be possible by constantly checking the larger window's location and updating the smaller (actual) window it with the location value provided by WindowWrangler, preferably in a separate thread.

I know this isn't really the place to post stuff about a potentially different extension for PySimpleGUI, and I still haven't uploaded the promised LookyFeely version itself, but I really want these two to work hand in hand.

[definite-d]

In case you're wondering what exactly WindowWrangler can do right now (and also to explain better), I mentioned this:

... if I need a window to move to the parent at the click of a button, I simply call the WindowManager.reposition_window() function. This moves the child window specified as an attribute to the upper left corner of the parent window; what you'd expect to happen from manually getting the location of the desired reference window and then manually computing where the sub window should move to, then calling aMove and Refresh on the window.

By calling WindowManager.reposition_window(somewindow, "UC", "UC"), I can have somewindow move to the parent window's top-center as though I manually dragged the top-center...

I also have a function that moves the parent window and optionally has the child windows move automatically, with options to retain offset. I imagine this could be used to fake multi-area windows like most graphics design software.

This new structure I'm planning will likely condense all that into a single tuple result: the best location for any window to be in relation to a reference window.

[definite-d]

Well, with the new structure in place and a few hacks, I've managed to replicate your use case above without multithreading, though not exactly. A window following another as you showed up there is absolutely possible with my method, but the movement doesn't happen in real-time, and the window being moved has to be read with a 0 timeout.

[PySimpleGUI]

Congrats on making a window manager. You're ahead of me in expanding PySimpleGUI in this formal of a way. I've not formalized a Window Manager that groups together windows. It's been up to the user to date to manage window, much like you're doing. There's not an event at the moment that can be enabled that will tell you that a window has been moved. That's what you need to pull off something like synchronized windows in a way that's not polled.

There are a couple of new features that begin to expand the overall window capabilities like replacing the titlebar with a custom built one. That capability is coming up in the next release as I have made it possible to grab portions of windows (Text and Column elements) to move windows. It's an incremental approach with new stuff slowly added along with bug fixes.

Headsup about theme coloring. There's a new constant that is used to specify that a theme's progress bar is to be "computed". Previously the "default" variable was used to indicate this, but using that variable created a bit of a problem as it held the computed value rather than staying constant. What I needed was a constant that indicates the progress bar isn't specified in the definition but instead created using colors that are already part of the definition (e.g. button colors or the input text colors). I don't think it'll impact your code though.

[definite-d]

Darn, I'm getting excited thinking about the next release. It'll definitely be fun to play around with a Photoshop-esque custom titlebar.

About the window manager thing, considering the complexity of windows (which hit me when I actually tried altering past normal use), I'm not sure if a manager that has control over all windows would work as hoped for with the structure I had.

So, for the sake of the initial use case (to reposition windows), the new structure turns that into a location calculator. That's what will be distributed with LookyFeely, and I'll likely name it PSG_Loc8.

After the upload, I'll start re-developing a proper window manager.

Perhaps LookyFeely could use the proper manager in a later release.

[PySimpleGUI]

Glad you're looking forward to it.... meanwhile I'm half terrified of releasing it. Tons of changes. Testing on my Raspberry Pi at the moment to make sure everything still runs on 3.4. Having some trouble with the custom titlebar on the Pi. I'm not able to input text as it's going to the terminal window instead of the program. I think it may be related to running without a titlebar. I might have to force the focus. It looks great and I'm able to move the window around the Pi's screen with no problem. But won't be much good if can't enter anything.

[PySimpleGUI]

Needed to add a couple of new things to get the no-titlebar demo working right on the Pi. Glad the demo exposed an existing problem. tkinter isn't able to get focus unless focus is forced on the Pi. Was a great thing to catch. I'm sure it's been a problem for a while but no one has hit it yet. I think most people run full-screen on their Pi or run with a normal titlebar. No one has hit the right combination.

[definite-d]

And of course, if it works on the Pi, it works nearly everywhere. That's great.

Speaking of changes, I hope it's not too much to add one more. Don't worry, I don't think it's very big. It's about the Horizontal Spacer element in Tk.

If I were to make a custom titlebar, I'd essentially have a single row containing:

• The icon. Probably with a dummy button, as I don't really use the Image element itself.
• A text element for the window title.
• A horizontal spacer
• 2 or 3 buttons for window functionality.

From what I noticed while making the new shuffle window for LookyFeely, a horizontal spacer shows a sort of border along the top edge, making it seem sort of elevated. I understand that this comes in handy for good looking status bars at the bottom of windows, but it seems somewhat unsettling at the top in a custom titlebar or anywhere else in the window.

I had to use a text element with a space character as its value multiplied by over 30. This gave the desired spacing effect, but it needs manual adjustment everytime the window width changes.

[PySimpleGUI]

Can you post an image and perhaps that portion of your layout? I'm not sure I understand the issue from the description. Seeing it would be helpful. A short demo of it would be even better.

[PySimpleGUI]

You may want to also look at the expand capability that's been added. It is needed in order to right justify items so that they will move correctly when the window is resized. Maybe have a look at the custom titlebar demos to get a better idea of how expand is used. Previously you could do this by calling expand. Now it's been added as a parameter to the Column element. There's also a new status bar demo that shows how to use an expanding row to keep a titlebar located at the bottom of the window that also spans the width of the window.

[definite-d]

I see. Well, that answers all issues about that 😁 . No need to bother about the spacer if there's a better way, right?

Honestly, with all the testing and tweaking I've been on about LookyFeely, it's turned the code into a mess. When you click "Generate Theme" now, an unresponsive Unspecified Options window comes up. Closing that and clicking to generate again makes it work normally, but then again there's a random chance that the options may or may not work at all (with the exception of ImagePalette for some reason).

Again, it's a mess. I guess the best way for locating windows from the beginning of their life cycle is to specify a location in the window definition.

Then again, I just got an idea for a new structure (literally while typing this).

Windows are made of most commonly two things (from the user perspective); a layout declaration and calling the window function, right? And the layout is what defines the size (and thus basic location) of the window.

What if, the window relocator is built to work with mainly layouts rather than windows themselves? It could work like this:

• A Locator object is created, probably outside the reference window's event loop or first Read().
• The user registers the reference/home window as such when creating the object. This is the only Window object used by the locator, and it is used to obtain the home location and size.
• To get the ideal location for any window, the user has to use a calculator function and supply the layout for that window as a parameter.
• That location can then be fed into the window declaration.
• Behind the scenes, the supplied layout is duplicated and used to make a dummy window with a blacked-out theme, which is finalized and used for calculations. This process would appear better if there's a way to Finalize windows without them showing up for a split second.

Using layouts rather than windows themselves has the advantage of enabling the location to be passed as a parameter instead of having to depend on Finalize and Read hacks then Moving the window to the calculated location.

Rather, from the beginning, the window appears in the right place, and if the user wishes, he can use the Move function.

Have I hit the jackpot structure? Do tell me what you think.

[definite-d]

I've also found a way to duplicate layouts which have been used in Windows already, at least for my uses (for a dummy window).

I'm applying the locator system to LookyFeely now, and I might as well throw in a color previewer dummy button.

[definite-d]

Well, I'm done with integrating PSG-Loc8 (yes, that's what I named it) with the core part of LookyFeely, meaning that through the process of making a theme, all windows will be spawned properly no matter the location of the parent window.

[definite-d]

The latest version, 2.6, brings the new system I talked about.

A little thing to note though; LookyFeely may run a bit slow, thanks to PSG_Loc8 literally duplicating windows for data (though that happens literally invisibly).

[definite-d]

Hello everyone.

I know, I haven't been as active on this project as I used to, but I'll try to rectify that.

My computer recently crashed on me, and I lost my Python installation, which I can't get back due to some issues with my new system, so I'm using Repl.it now.

I've never used it before though, so it may take a while to get used to.

Anyway, I'm back now, and I'll start working on the things in the Roadmap.

Cheers. And Merry Christmas in advance.

[definite-d]

Since the major issue is running anything in Python, I decided to use a different workflow:

• Edit in Visual Studio Code
• Copy-paste into Repl.it and Run the code
• Do my testing with the widget shown.
• Repeat the process.

It's a bit cumbersome compared to my usual workflow of simply using PyCharm offline and clicking Ctrl+F5 whenever I need to run LF, but it works.

[PySimpleGUI]

I've been using Trinket as well, but there are some downsides. It doesn't do external package installs for example. But, it's superior in terms of being a teaching tool.

I used repl.it early on, but there was a period where it really failed badly with tkinter based projects. Some of my early projects no longer run and I think I'm going to have to delete them and start over. They're somehow corrupt.

Sometimes I found that I needed to import tkinter first thing in my code, even though tkinter isn't used in my main.py file. This was needed to trigger repl.it to use a tkinter based environment.

Lately I was struggling with errors saying that user packages weren't allowed. It's more of the corrupt projects best I can tell.

I'm back to using Trinket for an upcoming course I'm working on. This is my primary trinket page that has a bunch of projects. It's pretty old: https://pysimplegui.trinket.io/demo-programs#/demo-programs/the-basic-pysimplegui-program

But, it gets around the clock usage. Every time I go and see how people are using it, I see that in the past few MINUTES someone has run some of the examples. So I know it's reaching a large number of people generally speaking.

[definite-d]

That's no surprise; PySimpleGUI is the miracle of Python GUIs.

Well, I sure hope Repl.it doesn't give me unpredictable behavior down the line. It's already a bit awkward, as it doesn't support transparency. I'll look into Trinket soon. Thanks.

Now, I'm not sure if this is a bug caused by the change of systems, but are you unable to use ImagePalette successfully? I get a silent crash (likely masked by some break call). I want to be sure if it's a code issue.

[PySimpleGUI]

are you unable to use ImagePalette successfully?

I'm officially "taking a break" from the project and not looking at GitHub Issues, etc. I've arrived at a continue/quit decision point. Working non-stop for 2 1/2 years with no income has resulted in a financial and emotional crater which has necessitated a break from the project while I regroup and investigate options for the future for the project or determine this is the end of the road. Witnessing corporations benefit financially while not responding to pleas for assistance while others attempt to profit from PySimpleGUI by making minimal/superficial patches, renaming the package, and then asking for donations has resulted in this reassessment-break.

[definite-d]

Wow...

Well, enjoy your break. I really hope you don't quit this project, but you clearly have your reasons if you do.

[PySimpleGUI]

Thank you.... sorry to be abrupt or rash sounding. It's just frustrating showing through and complaining isn't going to be of benefit to anyone. It's ugly words and the internet has plenty of those. I'm sorry for posting them. -ugh- Too much ugliness in the world. I'm sorry to have contributed.

I really really appreciate all the help and support you've provided. It's invaluable. It's been the fuel for the passion of the project. Without the help and support of the many truly nice PySimpleGUI users out there, I wouldn't have made it this far. So, thanks.... your contribution has been large on many levels.

I've been busily designing a course for PySimpleGUI, so I'm not standing completely still. Slowly filling up my notebook with ideas, outlines, lists, sketches. Hopefully, something good will come from it. If PySimpleGUI is at all pioneering, then I'm bound to have a few arrows in my back.

Thanks again for being a positive voice in the PySimpleGUI universe.

[definite-d]

Happy New Year, and welcome to Themera!

I decided to rename this project to Themera, because... well... "LookyFeely" sounds a bit weird, and I just realized that 😆 .

So, going forward, LookyFeely will be distributed under the name of Themera, and the upcoming 2.7 release will be Themera v1.0. It's also coming with 2 out of the 3 features currently in the roadmap, as well as slight optimizations and a fix for the ImagePalette bug.

[PySimpleGUI]

Happy New Year! Love the new name!!

You sound really hopeful and have a sense of direction for the project. That's fantastic to see. It's a great fit for 2021.

[definite-d]

Well, I've got everything set about Themera, but GitHub is being a nightmare to use. I may end up deleting this repository, but I'm trying not to, as that will (probably) kick out everyone who has starred/watched this project so far.

I tried using Filestash, but that got busted after a while. Not sure how, but I think I broke it; GitHub and Filestash stopped showing the same content.

I'm trying out Sourcetree now though.

[PySimpleGUI]

I dunno about any other services. I use GitHub with GitHub desktop on Windows. I sometimes connect with the GitKraken GUI on windows but don't manipulate anything with it. I feel like I kinda have to be on GitHub. Good luck with whatever you end up with. Sad to hear you're spending time and energy on something so frustrating and not particularly enjoyable.

[definite-d]

Welp, I managed to fix things.

First, I got the repo set up on Sourcetree, then I made a new branch based off the first ever commit I made on this repo. Things were then as easy as deleting the old LICENSE and README.md files, and uploading all files below the 20MB GitHub upload mark.

Then I changed the default branch to 'main'; the branch I created.

Right now, I've got Filestash operating right (I guess), and I'm using that to upload the compiled app, the installer and the zip for Themera.

Also, I'm awfully sorry to all the watchers of this project; you all have probably seen a ton of emails of my activity from fooling around with GitHub, based on your Watch notification settings. I apologize again.

Anyway, in some minutes, Themera should be fully up and ready to be used 👍🏾 .

[definite-d]

Scratch that, it's all set now. Go ahead 👍🏾 . By the way, I think this issue should be closed once the number of comments reaches 100.