I'm using LTK for basic windows in Common Lisp. I want to create a square button, but it turns out that height can't be changed. Here's the relevant part of the code:
(let ((tile (make-instance 'button
:width 20
:height 20))))
I'm getting an error:
Invalid initialization argument:
:HEIGHT
in call for class #<STANDARD-CLASS LTK:BUTTON>.
See also:
The ANSI Standard, Section 7.1.2
[Condition of type INITARG-ERROR]
In the LTK documentation, height is listed as configurable for buttons. Is there something wrong with the installation or is it a known bug or what?
I think it is missing on ltk side. With M-. in Slime I go to the definition of button:
(defargs button (widget)
command
compound
default
image
state
textvariable
underline
width)
There is no height indeed and it doesn't come from widget.
I asked on nodgui (ltk fork with syntax sugar and more meta-widgets) because the maintainer is real nice: https://notabug.org/cage/nodgui/issues/6
His answer:
nodgui supports only the widget that use 'ttk' theme engine:
https://www.tcl.tk/man/tcl8.6/TkCmd/ttk_intro.htm
the documentation for ttk::button:
https://www.tcl.tk/man/tcl8.6/TkCmd/ttk_button.htm
shows no height parameter (correct me if I am wrong)
(is there a chance that you are looking at https://www.tcl.tk/man/tcl8.6/TkCmd/button.htm ? This is the non-ttk version of the widget and is not supported)
Probably you can play with frame and sticky attribute to modify the geometry of a button (never tried), moreover I do not know about a way to specify the size of a button in pixel units.
Hope this helps someway! :)
ps: Probably is important to point out that the LTK documentation is outdated in the widget part.
Other information to consider: https://mailman.common-lisp.net/pipermail/ltk-user/2016-June/000625.html
Tcl/Tk up to 8.4
including allowed the font for buttons to be set. From 8.5 there was the
ttk widget set, which at some point became the default for ltk. The ttk
widget set uses a theme engine to determine many of the rendering
parameters for widgets to achieve a "native" look. This means that a lot of
older options for the widgets got removed. You can find the documentation
for the widget here: https://www.tcl.tk/man/tcl8.6/TkCmd/ttk_button.htm
If you push :tk84 onto features, you get the old style widgets, otherwise
you can of course create/modify ttk themes, that should give you the
ability to configure fonts too. With bug reports like this, it also would
be very helpful if you included information about the operation system the
problem shows, the lisp you are using Ltk with, and in this case, a screen
shot.
Related
I have been building small "proof of principle" programs to learn about GTK3, and now that GTK4 has limited availability, I have been attempting to learn about this version as well. In attempting to migrate to GTK4, I took a program I wrote for GTK3 that displays two progress bars with different attributes using CSS providers and rebuilt it under GTK4. When I ran the GTK4 version of the program, the CSS overrides in the program are ignored unless I introduce the CSS provider context to the display level for one of the progress bars. But that then results in having both progress bars exhibiting the same behavior instead of having unique behavior for each progress bar. Just as a further test, I added CSS providers and context for a label widget and that override worked. So some CSS overrides in GTK4 work as before, but some do not. It is as though some CSS provider overrides are ignored at the display level. Reviewing documentation about priorities (e.g. GTK_STYLE_PROVIDER_PRIORITY_APPLICATION) and testing out various priority constants did not make a difference.
Displaying the content of the code would be too long in this narrative, so I have uploaded the GTK3 and GTK4 versions of the code to my Github repositories along with a "pdf" file visually illustrating the different behavior between GTK3 and GTK4. If you want to review and test out the code yourself, the link is:
https://github.com/cschuls/GTK4_Mystery
I would suppose that widget-specific CSS customization could be added at the display level with an "id#" attribute, but that seems like that would just be adding unnecessary complexity when this practice works fine with GTK3. Thanks in advance for any answers and suggestions.
Additional comment.
Experimenting with various scenarios, I came up with a work-around that provides the desired result of having distinct style properties applied to each progress bar widget. For those widgets, I added their respective CSS provider data to the display style context instead of attempting to add the CSS provider to each widget's context. If you wish to view this work-around, I added a "work-around" folder with the source code to my Github repository.
This provides a decent solution to this problem, but it does not answer my underlying question as to why the CSS provider information for each progress bar widget is not enacted upon during the application's execution; whereas, CSS provider information associated with widgets such as labels and buttons do behave as they did with GTK3. If anyone can answer my core question, I would be very happy.
Regards,
Craig
I have a simple to do tree application that displays a QTreeView inside of a QMainWindow. I want to give the user the ability to change the magnification level of the content (using a spinbox most likely), but without actually changing the underlying font size of the text.
Is there a way to do this without changing my whole app to a QGraphicsScene? The app is just showing a good-old fashioned tree with text, no graphics or anything fancy other than wanting to change the magnification of the view; hence, I am thinking that switching to a graphics scene would be overkill.
Or, am I wrong, and switching to a graphics scene is the only simple way to do it?
Note a trimmed down version of the app is at Code Review. It contains a SSCCE, but is a bit long to post here.
In a site discussing how to put widgets on a scene, trolltech wrote (emphasis added):
I myself and several other Trolls’ve spent some time researching this
topic [how to embed a widget in a QGraphicsScene]. It’s not trivial;
most solutions to embedding widgets into a scene end up with several
serious drawbacks. That’s also why Qt doesn’t have any off-the-shelf
solution to this.
Widgets cannot be scaled or rotated, but graphics items can.
This suggests I cannot perform, in a simple way, the operations I want to on my QWidget by itself. That is, perhaps I need to add it to a scene, which is what I was trying to avoid. If that is the answer, then I'll accept it and start a new question if I get stuck doing that.
Note I just found this question, which is pretty much a duplicate, and does not have an (accepted) answer.
Related content
http://www.qtcentre.org/threads/62745-Zoom-a-view
QTableView Zoom In/Out
Drawing widgets (such as buttons) over QGraphicsView
QGraphicsView Zooming in and out under mouse position using mouse wheel
https://forum.qt.io/topic/15308/qgraphicsview-zooming-with-qslider
https://wiki.qt.io/Smooth_Zoom_In_QGraphicsView
As suggested by the docs quoted from trolltech in the original question, there is no built-in method to zoom on a view.
If the goal is to avoid the use of QGraphicsViews, the simplest way to separate the size of the font on the screen, versus the size of the font saved or printed, is to basically have two fonts. One to be displayed on the screen you can call 'zoom', versus the other to be saved/printed and call that 'font size'.
I got this idea from qtcentre (in a post I added to the original post too):
http://www.qtcentre.org/threads/62745-Zoom-a-view
I'm having an issue with the "browse for items" overlay for the default widget for z3c.relationfield, which I believe is using plone.formwidget.contenttree. I've created a custom field using this but get the same problem using the IRelatedItems behavior - the overlay has no browsable content. I am still able to use the autocomplete component of this widget, and can set relations programmatically with no problem, so I don't believe there is a problem with the intids utility. I've also tested on my local machine and on a dev server and everything works perfectly, just not in production (of course).
I apologize for the vague nature of this question, but I'm stumped. Are there any common pitfalls I could look for here? Any configuration step I might be overlooking?
Take a look at the Dexterity documentation and note the following:
Relation support no longer included by default
Content tree and Autocomplete widgets no longer included by default
So maybe you need to install the widget packages manually.
Other than trying to manually, re-write everything to mimic the tooblar graphics and the size transition animation when moving between pages, Is there a better way to do this?
Amazingly I can't find ANY resources covering this, or even someone asking for this.
http://qt-project.org/doc/qt-5.1/qtwidgets/qtwidgets-index.html#styles
The window animations may already work as is... You may want to specify Native Windowing, so that the Mac Windowing system is aware of your Qt windows:
http://qt-project.org/doc/qt-5.1/qtwidgets/qwidget.html#native-widgets-vs-alien-widgets
Native Widgets vs Alien Widgets
Introduced in Qt 4.4, alien widgets
are widgets unknown to the windowing system. They do not have a native
window handle associated with them. This feature significantly speeds
up widget painting, resizing, and removes flicker. Should you require
the old behavior with native windows, you can choose one of the
following options:
Use the QT_USE_NATIVE_WINDOWS=1 in your
environment.
Set the Qt::AA_NativeWindows attribute on your
application. All widgets will be native widgets.
Set the
Qt::WA_NativeWindow attribute on widgets: The widget itself and all of
its ancestors will become native (unless
Qt::WA_DontCreateNativeAncestors is set).
Call QWidget::winId to
enforce a native window (this implies 3).
Set the Qt::WA_PaintOnScreen
attribute to enforce a native window (this implies 3).
See also
QEvent, QPainter, QGridLayout, and QBoxLayout.
And this link has more information on the styling in Qt than I have ever seen before today!
http://qt-project.org/doc/qt-5.1/qtwidgets/style-reference.html
Hope that helps.
I wanted to consult with the sages here regarding Qt and skinning, get your opinion and chart a path for my development. My requirements are as follows:
My Qt/C++ application (cross platform with Mac, Windows and Linux versions) needs to have modular skins.
A skin is defined as a set of one or more elements: - Window background texture - Look/feel of UI controls such as edit boxes, drop down, radio buttons, buttons etc. - Look/feel of window "caption", resize grips etc.
Skins will be installed with the application installer, allowing the user to choose which one he/she wants to use. Users should be able to change skins on the fly.
Can I go the QML route? should this be custom and based on simple resources which are built into the application? Any design advice will be appreciated.
Thanks.
If I understood you correctly then stylesheet is the best way forward. You can create stylesheets similar to CSS and then pass them as command line option to your application or load on invocation to style your application at runtime. That way you can create multiple stylesheets each having a different look and feel and allow user to load them at will. Since its CSS it doesn't need any new learning and you can keep all your styling outside your source code.
Here are a list of resources that can get you up and running quickly:
http://blog.qt.io/blog/2007/11/27/theming-qt-for-fun-and-profit/
http://doc.qt.io/qt-5/stylesheet.html
I haven't played with QML yet, but you could also create a custom QStyle implementation that supports your resource format. Note that you'd lose style sheet support if you went this route.
Changing window captions is a little trickier if you want portability.
QML, if I understand correctly, doesn't really skin the widgets, it mainly deals with GUI layout etc etc.
QStyle is used to change the looks. It is a bit low-level though, and requires programming, so if you want to load different user-created skins (from an XML or so) it might be tricky to support extensive skinning. Chaining colors and a few items are easy enough though. (There might be someone else who've done something you could re-use.. not sure.)
For modifying widgets, use QStyle::polish(). You could use that to change the background picture (if it's a top-level window, or of a certain class). There are numerous repaint method to change almost every part of every widget.
Store/load the style using QSettings, by reading and setting the desired Style just after QApplication but before your main window is constructed.