I maintain a gtk3 (though a mixture of gtk2hs and gi-gtk) application that serves as a standalone status bar for tiling window managers called taffybar.
Taffybar has a long standing bug where something happens that causes one of its windows (it can have multiple windows e.g. when displaying on multiple monitors) to stop updating completely (issue here). I have verified through various logging mechanisms that the code that is supposed to be updating the window IS in fact continuing to run. Also, if taffybar is displaying on multiple windows, windows will become affected one at a time -- that is, the hang only seems to affect the window on which it occurs, which rules out anything strange happening on the UI thread or something like that.
Unfortunately, I do not have a consistent way to reproduce the issue. What's worse is that I haven't even been able to come up with a way to detect the issue programmatically. With that said, it is relatively easy to get the issue to occur as it has gotten much worse recently with the new icon loading mechanisms that have been added (it seems to happen about once every 5 minutes in the latest version). This reminds me that another thing I should mention is that I am relatively certain that the issue has something to do with pixbufs and image display because I have never seen the issue occur when the workspace images module is not active.
I hate to ask a question without even being able to provide a consistent way to reproduce the issue, but I'm simply at a loss as to how to go about tackling/debugging this issue. It's hard for me to imagine how the behavior that I have described is even possible, actually. I'm hoping that something about the idiosyncratic nature of the issue might be enough for someone more knowledgable about gtk than I to make some guesses as to what the issue might be.
To make my questions as explicit as possible I'll phrase it as follows:
What could cause a gtk application window to hang (stop updating) without crashing the application or the UI thread, or affecting any of the other windows created by the application?
EDIT: One more interesting quirk of this bug is that even though the window stops updating, it still responds to mouse input.
EDIT2: Another thing worth noting is that occasionally, I have gotten this message:
gtkicontheme.c:3956:proxy_pixbuf_destroy: assertion failed: (icon_info->proxy_pixbuf != NULL)
I have also gotten the following message when I attempt to destroy the hung window in code:
Source ID 363524 was not found when attempting to remove it
I am loading icons from the icon theme sometimes
I believe that the cause of this issue was simply that some UI updates were not being performed on the main UI thread. I can't be 100% certain of this because I was never able to reproduce. See this comment for more details:
https://github.com/taffybar/taffybar/issues/228#issuecomment-402591159
Related
I use xlib. I want to remember window position and restore it to that position the next time it starts. This will help the user as he won't need to move/size the window to the desired position at every start.
It works more or less Ok, except one case. When the window is maximized, I cannot find the way to determine its true (non-maximized) size and position. Perhaps someone knows how to do it?
There isn't as far as I know a standard way to do this. If you read the source to Metacity for example you can see it keeps this unmaximized size in the MetaWindow object but I don't think it gets stored in a property, and I don't see a property for this in the EWMH or ICCCM specs.
It's possible that some specific window managers might store it in a nonstandard property.
When a window is maximized you could get a property change event with the maximization flag (libwnck is an old library to track this sort of thing, maybe there's a newer one I don't know). However I doubt it's defined whether the resizing happens before or after setting the flag. You could perhaps heuristically assume that a resize covering most of the screen within 1 second of setting the maximize flag was a maximize, or some similar hack.
All that said, I suspect the easiest way to get this feature is to implement it as a window manager extension or plugin, which many WMs support in some way.
There is an old spec for this (X session management protocol) unfortunately the spec is ridiculously broken, unclear and essentially impossible to implement. A core issue that was never addressed - and probably needs app cooperation to address - is how to recognize "the same" window across restarts in order to restore its size.
There are only flawed heuristics for that.
(I wrote metacity and worked on a couple session managers long ago so once I could have told you a lot more, but I've forgotten many details.)
I must first say I have had a ticket open on DevExpress support for several days now with no resolution. I thought maybe other developers here have the same problem, and maybe even a solution.
While using the 30 Day Trial, whenever a DevExpress component is create, or something, an immovable and large dialogue pops up on the screen, on the same thread (I think) that created the component. If there is an error or breakpoint in the code that triggered that dialogue, all is lost. The debugger is unresponsive, and the evaluation dialogue is unresponsive. To make matters worse, it always appears centre screen, obscuring the error message, as in the image attached. My only recourse is to restart VS, but what then? The same debugging sequence has the same effect again. At this rate I will need 300, not 30, days to evaluate the product.
EDIT: I have posted a ticket at http://www.devexpress.com/Support/Center/Question/Details/Q534381, and they are working on it.
According to my experience, a Trial Screen is expected when using a Trial Version.
However, the mentioned issue is not a proper behavior and should be changed.
In any case, I believe that only DevExpress support can assist you with this issue and put you on the right track in the most effective manner.
If you has already posted an inquiry to the support, share the corresponding link here.
Once you get a valuable response from the support team, post a new answer here and accept it to close the SO issue.
I'm currently stuck with a pesky little issue. I developed an application that zeroes out the DXGI mode desc. structure and calls FindClosestMatchingMode() to, as advertised, "gravitate towards the desktop resolution".
This works fine if the laptop(s) run fully on their own display -- as soon as I plug in another monitor it goes berserk. In the case I extend my desktop it will still correctly get the laptop monitor resolution, yet the attached one (running 1080p) will yield a preference for 800*480 :) (sure, poor man's 16:10, but...)
Doing the same thing with the monitors cloned/combined (results in 1 output device), even if their resolution is equal, gives the same 800*480 crap.
What gives? And has anyone perhaps found a way to properly get a display's current mode through DXGI or a pointer for a wholly different yet functional approach to this here problem?
Life was easier back in the D3D9 days =)
-- Update
As it turns out any FindClosestMatchingMode() call made on the IDXGIOutput instance belonging to the external monitor behaves differently (and in most cases plain wrong) compared to the internal display, even though their native resolution is identical. To top it all off, other systems don't have this issue yet I can't get around supporting this particular laptop including it's drivers.
Time for a good old setup dialog.
Not the best solution but as I was constrained to these exact machines I settled for getting the monitor's current resolution through GetSystemMetrics() (SM_CXSCREEN/SM_CYSCREEN), which admittedly only works for the primary monitor but there's other ways, and feeding this resolution to the ModeToMatch structure fed to FindClosestMatchingMode().
It then settles for the correct (desktop) resolution.
Better answers are very welcome of course ;)
I'm having a weird bug on one of my computers with Visual C++. For some reason the screen will stop refreshing where my source code is. I can force a single refresh if I minimize and maximize Visual C++.
For example if I try to type something or use the scroll bar, it will not show any changes until I minimize and maximize. If I type something the changes have been made however. I can save and those changes will remain.
Oddly auto-complete still works as intended. If I type myClass.get_ it will bring up the auto-complete window.
It seems to occur randomly. It can happen if I leave the program up for a bit while doing other things or when I first start up the program. A fresh reboot nearly always fixes at that moment but what ever the cause is will occur after time. One thing that nearly always causes the program to stop working is if I start a video game.
I'd appreciate any help, thanks.
Assuming this is VS2010 - I think it does new-fangled GUI things with WPF and notably relies on hardware acceleration and write combining quite a lot more than before.
I had display issues in a virtual box gues installation (with multiple-monitor support in the guest enabled). I worked around it by lowering / disabling the hardware acceleration settings for the (virtual) graphics adaptor.
right click desktop
screen resolution
advanced/performance
use the slider to adjust acceleration level
Changing this setting apparently required a reboot on my system when I did it.
Introduction
I have been so annoyed by applications that have a startup dialog which is Always on Top configured.
By start dialog I mean the annoying box that tells you what program you just opened (and probably opened on purpose so useless information), who the program is registered to (most likely you, more uselessness), and some other random application specific information. Some have loading bars that indicate startup progress, but otherwise they seem basically useless except to show that your program is actually starting (to prevent the user from opening 5 instances during the loading process because they think it's not open yet).
The worst though is when this useless information is displayed over all the useful browsers and documents that I may be working on at the time, making me wait until the application is loaded before I can effectively work on something else again.
Most apps have the sense not to do this, but some still continue the practice.
Now that I'm done ranting...
My Question(s)
My question is..Why?
What is the point of all this?
Why does/did anyone ever do this?
What was the reasoning behind it?
Is anyone else annoyed by this?
Is there any benefit to the end user or developer to use this technique?
Should I ever use a startup dialog like this and when?
Anyone else have other comments/rants/suggestions to share with the community?
I believe you are talking about the 'splash screen.'
Some reasons for it:
It is often thought of as 'branding' in that it reinforces the company's logo.
It can contain some useful info such as version number.
Most importantly, it gives you the impression that the slow starting app is being just a bit more than unresponsive.
I share in your annoyance of Always-on-Top dialogs.
The use of the dialog is to let the user know that the application is actually doing something and hasn't hung. Back in the day, when IO wasn't as fast, it was reasonable to assume that the system is not very responsive while the application is doing its IO, so it was reasonable to bar the user from doing anything else while the application was loading.
Now that IO is faster and more concurrent, there isn't a need for hogging the user's focus and the start-up dialogs should simply be regular dialogs.
Since the main use of the dialog is to indicate application process, I like a visual indication, such as a progress bar. Eclipse does this well IMO.
It's good to have a startup screen so the user gets some feedback that they actually launched the app.
But putting that screen always on top of existing windows, so the user is sure to see it, is a definite no - you should not presume that your application is more important than the user's web browser, email, etc. Unfortunately many developers have a very self-centric view of the world, and think that their application is the most important thing the user is running.
Just gives visual indication that the app is initializing.
Startup dialogs or Splash screens are completely useless for the most part. The only time I think they are any use is if as you suggested a particular program takes a bit of time to load. Some kind of progress indication would be nice.
The only example I can think of is Photoshop. Not strictly necessary but it does take a moment to load.