I recently updated the GTK3 lib I am using, both on windows and linux,
from version 3.20 to 3.22, and I noticed some bugs in my application (GTK3 + OpenGL using the GtkGLArea widget) appearing after the update.
The bug, namely the disappearance of window decoration appears after a precise, yet simple, succession of events:
1) screen shot before the bug:
2) Exporting an image from this window (using a framebuffer for off-screen rendering)
3) After saving, going back to the main window by closing the dialog box, note that the upper menu bar now appears like if de-activated (grey) but sill works:
4) ... and when re-sizing / hiding / showing again 'ie. configuring' the window the decoration disappear:
5) The menu bar still seems to be there and works fine:
Obviously I looked carefully to the code after the saving action, but what happens remain elusive to me and I do not know what to look for.
The program does not stop and keeps working fine.
There was absolutely no problem with GTK3 3.20, and the bug appears both on windows and Linux.
What can I do to correct this situation ?
In the Gtk-3 series there have been many changes to the CSS system. If you are not using the default Adwaita theme, then probably you have to search for an updated version of the theme you do have installed. It might even be possible that the Adwaita theme wasn't update correctly during your upgrade.
Anyway, nearly all appearance problems are due to changes in the CSS system - Gtk doesn't really occupy itself with the aesthetics anymore.
Related
I have an application which worked well so far.
Today I have updated my ubuntu to 18.04 and therefore reinstalled all software components, including Qt.
Now I experience a pretty wired behavior.
When I compile my application in debug build, everything is correct. When I switch to release build some combo boxes become invisible.
What is strange is, that events still work, the comboboxes are still there (but invisible).
I know this because I use an installEventFilter()
with if(event->type() == QEvent::Enter) which changes some other widgets if I hover the combo box with the mouse. Although the combo boxes are invisible the events still work when I hover the area where the combo box would be located.
Unfortunately, I do not know what makes this issue, so I cannot reproduce it in a minimal example.
My question is: Did anybody experience something like this before?
And: Where should I start to look for the error?
(I cannot debug it because everything is correct for debug builds)
By the way: I do not know if this is related but when I first tried to run the application I got an error that gl/gl.h was missing. After asking my friend google for help I found out that OpenGL was missing, so I installed it.
I would go and look for uninitalized variables when setting the properties of the combobox. Usually in debug even unitialized variables are set to some fixed value.
Or maybe you are setting properties in an assert that is not compiled in the release build? E.g. like this
Q_ASSERT(...)
that code in between the () will just be skipped during a release build.
I have some legacy code made with Borland C++ Builder 6 that I have to port from Windows XP embedded to Windows 10 IoT.
It all seems to run properly, except dialog forms which aren't drawn properly. When I call ShowModal on the forms to show them, they flash quickly and then seems to disappear. However they are not gone, instead they are just not drawn and the form behind the dialog is seen. The dialog form buttons can still be pressed (if we know where they are).
I have tried all possible redrawing, refresh, repaint and update functions I could find, but nothing seems to work.
To make matters worse, dialogs containing actual control elements (like one containing a set of TSpeedButton elements) the controls are redrawn when moving the mouse over them, but anything else are not redrawn.
I have tried to search for similar issues but can't find anything for this.
Could this be solved? Or do we have to update to a newer Embarcadero version of the IDE to be able to solve it (which is a lot or work and not really something we can do at the moment)?
The problem was the use of a Billenium Software (now defunct) package for "fancy" transitions.
The transition in question "zooms" a dialog open, and it just doesn't seem to work. Disabling this transition will solve the problem of the disappearing dialogs.
I still don't know if it's a problem with the components Windows 10 compatibility, or with its 64-bit system compatibility.
I have a UI written in Qt that makes extensive use of dock widgets, primarily so that end users can customize which which docks are available, and how they are arranged.
We recently upgraded to Qt 5.6.1, and the dock widgets can no longer be rearranged on Ubuntu, although they still work on windows and other OS's. When you try to move the docks, the rubber band still appears as usual showing the new location, but when dropped the dock just snaps back into whichever position it started in, which is always tabbed somehow.
After several hours of searching, I think the problem is related to QTBUG-54185, and I'm wondering if there is any way to work around the bug while we wait for the Qt 5.6.2 release which fixes it.
The bug is related to having the AnimatedDocks property disabled. QDockWidget rearranging still works, even in spite of the bug, for dock widgets which are animated.
The problem was that in the code, the main window was setting the dock options manually as
mainWindow->setDockOptions(AllowTabbedDocks);
Since DockOptions are OR'd, what is happening here is that the AnimatedDocks property, which is enabled by default, is being unintentionally disabled. The solution for me was to delete the offending line, since the default options are AllowedTabbedDocks|AnimatedDocks, which is actually what I wanted all along.
My Qt 4.8 application runs on a Windows 7 touch screen. I'm not using the QTouchEvent capabilities. In this case and following the documentation, touch events should appear as normal mouse events. Unfortunately, this is not the case for all widgets.
The tabs of QTabWidgets can't be switch by touching them. It works via keyboard inputs. Other widgets work as the should (QPushButton, QLineEdit), interpreting the touch as mouse event.
The widgets are created using the Designer.
Despite the answer might not, my question is simple:
How can this happen, resp. how to fix this?
Thank's in advance...
Update:
Just figured out that it seems to be a compiler issue. Compiling With msvc2010 SP1 under Windows 8 causes the problem.
Compiling using WinXP and mingw results in a correct behavior.
Unfortunately, I would like to use MS Speech SDK, so I need Win7+ and msvc...
Update 2:
It's getting worse: Using a normal mouse everything reacts as aspected. But touching the screen is ignored. At least on the top half of the screen.
To be even more confusing: Using Qt 4.8 classic widgets does not react (QPushButtin, QLineEdit) but links in a QWebView react. Using Qt 5 it's vice versa.
You can find the application on source forge: httpplayer
http://sourceforge.net/projects/httpplayer/
I know Tkinter can be an exercise in frustration at times, but I am stumped on the "correct" sequence of calls to a Tkinter/ttk Toplevel widget/window that will:
Display the window in the center of the screen WITHOUT drawing it off-center and THEN moving it.
Size the window properly.
Make the window toplevel to the parent form, but not system modal (that is, not toplevel to ALL apps/windows on the system).
Optionally create a taskbar button on Windows.
This is the current code that I have so far, with some unrelated bits removed for simplicity's sake:
def __init_ui__(self):
#// Basic setup.
self.wm_overrideredirect(False)
self.wm_resizable(False, False)
self.configure(relief=FLAT, borderwidth=4)
#// <Some extraneous widget-creation here>
#// Done!
self.update()
self.withdraw()
self.update_idletasks()
self.grid()
self.transient(self._parent)
self.grab_set()
self.form.initial_focus() #// sets initial focus before the window is displayed
center(self) #// https://stackoverflow.com/a/10018670
self.deiconify()
self._parent._parent.wait_window(self) #// Reaches back to the root Tk() obj.
# ENDIF
# END __init_ui__
This form inherits from a custom class I created that wraps a bunch of widget-creation calls, and the class inherits down from object. A second inheritance comes from ttk.Toplevel, to give it access to the various self.wm_* calls and other Tkinter goodies.
That said, I am certain some of my function calls are unneeded. But this particular call order seems to mostly work well on Windows 7. Under X11-over-ssh (using Xming for the X server in Windows), however, things get a bit weirder. In that case, if I move self.update() to be after self.withdraw(), then the window is centered correctly w/o redraw on Windows 7, but on X11, it is drawn and properly centered whilst hidden, but has ZERO geometry (only the compressed window border/decorations are shown). It's as-if grid propagation didn't fire or such.
But where self.update() is right now, it properly sizes and centers the window on both windows and X11 - but you can see the window getting created off-center THEN moved to center on both.
If I use self.wm_attributes("-toolwindow", 1) on Windows, then the windows gets centered without me seeing it, but -toolwindow only works on Windows system. It's an invalid command to both X11 and Aqua.
I'd like to avoid calls to tk::windowingsystem all the time to determine what my window manager is and having to apply different hacks for Windows and X11. And I can't test Mac/Aqua (don't own one, not going to buy), so I'll just have to hope the end look is somewhat functional on that platform.
Additionally, if I click away to another window/app under both Windows and remote X11, clicking back on the main form via the taskbar button only displays the main form -- the child Toplevel window only pops back up when you click anywhere inside the main form. Fixed: (kinda) -- I forgot that adding an argument to self._transient() kinda fixed that by specifying the parent. Earlier tonight, I didn't pass the parent argument in, thus the focusing wasn't right.
So is there some kind of tried-and-true magik recipe or invocation to the Priests of Ancient Mu to get a Tkinter/ttk Toplevel window to size, center, and properly get focus if it's not the root window? Using minimal X11, Motif-look, btw.
And no, I am not using PyGTK, PyQT, wxPython, or some other toolkit. It's standard Tkinter/ttk or bust, since that's what I've spent the last few weeks learning and writing wrapper functions for. The autocomplete combobox I worked up is a cute little contraption. Still slightly buggy, but that's a topic for another SO question...
PS, The Tkinter cookbook on Effbot is down. Looks like a server crash. Did anyone happen to mirror that site by chance?
Solved! Had to tweak the order of the calls a little bit:
#// Done!
self.withdraw()
self.grid()
self.transient(self._parent)
self.grab_set()
self.form.initial_focus()
center(self)
self.deiconify()
self._parent._parent.wait_window(self)
But the real fix was in the center() function I lifted from this answer, by changing the calls to winfo_width()/winfo_height() to winfo_reqwidth()/winfo_reqheight() and adding a call to update() as the first call in center(). Now I get my dialog windows to pop up in the center without seeing them move, focus is applied correctly, and it works on both Windows and remote X11. Maybe one day, I'll find out how well it works on Mac OS X/Aqua.