How do I make a Tkinter GUI have rounded corners?
Example:
If you mean the window itself, I am afraid that is not possible due to the fact that Tkinter needs to be supported by 3 different operating systems, all with different window handlers. If you wish to attempt to do this, you will need to find a OS-specific library to do this. If you mean having a canvas with a rounded rectangle inside it, this question, which jezza_99 mentioned, covers this quite nicely.
Related
im doing an tkinter app in a computer, im using the grid() method to place the widgets. At first of the program i use this code to make the window size like the screen size:
an = self.root.winfo_screenwidth()
al = self.root.winfo_screenheight()
self.tam = '%dx%d'%(an,al)
self.root.geometry(self.tam)
And it works, but this app will be used through a remote desktop with different devices (different screen sizes).
How can I do that the widgets fill on the window like the original design? Thanks
Without any concrete examples of your code, there's no way to give more specific advice than to say that the solution is to design your program so that it resizes well.
Tkinter excels at making widgets fit, so as long as you use the options at your disposal (fill and expand for pack, row and column weights and other options for grid), and you don't hard-code any widths and heights, your GUI will easily work on a variety of systems.
Concrete pieces of advice:
don't use place except in very rare circumstances. While place supports relative positioning and sizing, it requires more work than pack and grid
design the GUI to work on the smallest display possible, and then make sure that when you manually resize the window it behaves properly
When using grid, make sure you always have at least one row and one column with a non-zero weight so that it knows how to allocate extra space
When using pack make sure you use expand and fill properly
Don't turn off the ability for the user to resize the window
Presently I have my code which places a window on a canvas using
create_window((x,y),anchor="nw",....). I see how it displays (on a 1920x1080 monitor)and have adjusted x,y accordingly. But, when I then ran it on a 1360x768 screen it does not look good. So, I adjusted x,y (using the method to get screen width/height) and using different values for (x,y) based on that.
Is this the normal way to do that ? Because I have several places in my code for other calculations where I have to make this explicit adjustment. I am wondering if there is some better way to do this ?
As ProgrammingIsAwsome mentioned in the comments, I think you want your application to be in fullscreen mode. There are two different ways to do this (assuming root is a tk.Tk() instance):
The first way is actually a maximized window:
self.root.state("zoomed")
The second is the real fullscreen mode, hiding the taskbar and title bar:
self.root.attributes("-fullscreen", True)
Furthermore, I wouldn't recommend doing anything with absolute sizes. Use the nice geometry managers grid and place which manage that for you.
Question
I have created several GUI projects so far, but they all have one fatal mistake. When I make a window smaller, (which usually uses only one frame.) several of the widgets will disappear. Is there anyway to make the widgets 'aware' of the size of their frame?
What I have tried so far
I have tried to use this:
w, h = root.winfo_screenwidth(), root.winfo_screenheight()
to specify the size of the window, but since many widgets use values other than pixels, it never works. I am also unsure as to whether it updates constantly or only when the window is spawned. (Text uses the size of the characters... etc)
Specs
Python 2.7.3
Windows 7/ Mac OSX Lion
This is generally quite easy, and often just happens by default. It all depends on how you use pack and grid. Without seeing your code it's going to be hard to give you useful information.
Can you show us a really small program that illustrates the problem and is an accurate indication of how you lay out your GUIs?
What libraries/modules would you recommend for creating an interactive geometry program?
What I have found includes: Pyglet, Pygame, Pycairo, Sympy
I'll illustrate the basic requirements with an example:
Create two Point objects by clicking two locations on a canvas.
Create two intersecting Circle objects based on those two Points.
Detect the two circles and calculate their intersections.
I would like to work with a canvas that supports anti-aliasing.
I would also like the ability to produce(export) an image with a transparent background.
If you have a bit of experience with OpenGL I would seriously recommend pyglet. Very customizable. If you don't, get it, because in Python there doesn't really exist a game/rendering library that has a "canvas-style" interface, except, to a certain point, pygame. But pygame...
Stay away from pygame. Stay away. pygame has horrendous design, documentation, code written with it and performance.
I have no experience with the two others (or any others, for that fact). There aren't many options for this domain in Python sadly (this also is the reason why I started a project like this, but it's still too unstable and WIP). Most notably the built-in support for things like anti-aliasing, primitives and intersection calculating is non-existent.
I have created a library for interactive geometry board using tkinter.
http://bitbucket.org/zambu/pygraph
I want to put a Canvas with an image in my window, and then I want to pack widgets on top of it, so the Canvas acts as a background.
Is it possible to have two states for the pack manager: one for one set of widgets and another for another set?
The answer to your specific question is no. You can't have two states or otherwise use pack two different ways in the same parent.
However, what I think you want to accomplish is simple. Use the built-in features of the canvas to create an image item that is part of the canvas, then pack things into the canvas as if it were a frame.
You can accomplish a similar thing by creating a label widget with an image, then pack your other widgets into the label.
One advantage to using a canvas is you can easily tile an image to fill the whole canvas with a repeating background image so as the window grows the image will continue to fill the window (of course you can just use a sufficiently large original image...)
I believe that Bryan's answer is probably the best general solution. However, you may also want to look at the place geometry manager. The place geometry manager lets you specify the exact size and position of the widget... which can get tedious quickly, but will get the job done.
... turned out to be unworkable because I wanted to add labels and more canvases to it, but I can't find any way to make their backgrounds transparent
If it is acceptable to load an additional extension, take a look at Tkzinc. From the web site,
Tkzinc (historically called Zinc) widget is very similar to the Tk Canvas in that they both support structured graphics. Like the Canvas, Tkzinc implements items used to display graphical entities. Those items can be manipulated and bindings can be associated with them to implement interaction behaviors. But unlike the Canvas, Tkzinc can structure the items in a hierarchy, has support for scaling and rotation, clipping can be set for sub-trees of the item hierarchy, supports muti-contour curves. It also provides advanced rendering with the help of OpenGL, such as color gradient, antialiasing, transparencies and a triangles item.
I'm currently using it on a tcl project and am quite pleased with the results. Extensions for tcl, perl, and python are available.
Not without swapping widget trees in and out, which I don't think can be done cleanly with Tk. Other toolkits can do this a little more elegantly.
COM/VB/MFC can do this with an ActiveX control - you can hide/show multiple ActiveX controls in the same region. Any of the containers will let you do this by changing the child around. If you're doing a windows-specific program you may be able to accomplish it this way.
QT will also let you do this in a similar manner.
GTK is slightly harder.