In source code of mutter, /src/core/window.c, has a very nice string
window->mwm_border_only = FALSE;
If change value to TRUE, mutter removes titlebar, just leaving borders, allowing you to resize the window. But this fully works only in X-session.
In wayland-session, titlebars remove for windows of Firefox, Viewnior, Geany etc., but not removed for Bluefish, Pamac, Quodlibet...
http://storage8.static.itmages.ru/i/16/0417/h_1460873488_5752646_bf0ef083c9.png
Why? How to fix it? What are differences for windows of this applications in the source code Mutter or Wayland?
Distribution Linux Arch-based - Antergos.
Thanks you.
P.S. I beg excuse me for my english.
Related
Being relatively new to X11, I've been trying to make font rendering painless in my C example program. After giving up on making Xtf work reliabily, pangocairo seemed like the next best choice. I have encountered however an issue: pango doesn't always recognize the font description from a string. The following call does create a valid PangoFontDescription that will show text to a cairo x11 surface, however using any other font family that is not Sans or Serif won't display anything.
desc = pango_font_description_from_string ("Sans Bold 27");
The following one doesn't work no matter what sizes or weights are set up.
desc = pango_font_description_from_string ("Fixed 14");
What bugs me the most, the utility pango-view will create a perfectly working output of all descriptions given, even though they won't work in my pangocairo example.
pango-view --no-display --output out.png --text 'Test' --font 'Fixed 14'
Creating a new empty PangoFontDescription and setting up family, size and weight separately has the same exact issue as above with pango_font_description_from_string.
I'm really wondering what the issue could be, and the pango documentation hasn't really been helpful on this regard.
The ST terminal has a patch for scrolling back. I want to update said patch to enable mouse wheel up and down signals in additions to "PageUp" and "PageDown". I suspect that a small change in config.h is what is needed but I have no experience in terminal code thus my plea for help.
In the source code, in config.h these lines appear:
static Mousekey mshortcuts[] = {
/* button mask string */
{ Button4, XK_ANY_MOD, "\031" },
{ Button5, XK_ANY_MOD, "\005" },
};
So, clearly, we know what Button4/5 are. In addition, we have these:
static Shortcut shortcuts[] = {
/* mask keysym function argument */
[...]
{ ShiftMask, XK_Page_Up, kscrollup, {.i = -1} },
{ ShiftMask, XK_Page_Down, kscrolldown, {.i = -1} },
};
So, naively, I a assuming that adding another two raw (one for wheel up, one for wheel down) would do the trick. However, what?
Note: I know that suckless recommends using a terminal multiplexer such as tmux. I use that already. However, sometimes (rarely) I just want to use a terminal without tmux and this feature would be useful. Please do not comment/answer to use tmux, this is not what this question is about.
It is not that simple. This question occasionally arises when someone wants left/right scrolling for a mouse trackball.
On the left column of the tables is an X event. Those are limited to combinations of predefined symbols.
Button4 and Button5 are mentioned because those are conventionally used to pass the mouse wheel events. That has been the case for quite a while; there was a resource file used before modifying xterm in 1999 (patch #120) to make this a built-in feature.
The possible X events are laid out in C header files — X.h — and tables in the X source code; no wheel mouse events are provided for as such. For instance, there is a table in the X Toolkit library which lists all of the possibilities (for clients using X Toolkit such as xterm). xev uses the header-definitions.
If X were to support wheel mouse events in a different way, it would probably use new function calls for this purpose since the existing information may be packed into bit-fields in a way that precludes easy extensibility.
There is now a standalone program scroll that provides scrollback buffer for any terminal emulator. At the time of writing this answer, it is still in an experimental state, a lot of bugs are expected. In spite of that, it already handles scrollback better than the scrollback patches for st. E.g. resizing the terminal will wrap previous output instead of cut off and lose them.
To enable it, first of course download/clone the source code from suckless website and build it locally.
Then modify this line in config.def.h of st (you have to fetch the recent git commits to get support for scroll)
char *scroll = NULL;
to
char *scroll = "/path/to/scroll";
Now rebuild st, and run st. It will automatically use scroll to provide the scrollback buffer.
As stated in the manual, another way without modifying st's source code is to run st with the following command after you have installed both st and scroll:
/path/to/st -e /path/to/scroll /bin/sh
From the suckless site, there are some scroll back patches that allow scrolling using Shift+MouseWheel as well as full mouse scroll. The last patch might break other mkeys excluding scrolling functions.
Our app has a rotating map view which aligns with the compass heading. We counter-rotate the annotations so that their callouts remain horizontal for reading. This works fine on iOS5 devices but is broken on iOS6 (problem seen with same binary as used on iOS5 device and with binary built with iOS6 SDK). The annotations initially rotate to the correct horizontal position and then a short time later revert to the un-corrected rotation. We cannot see any events that are causing this. This is the code snippet we are using in - (MKAnnotationView *)mapView:(MKMapView *)theMapView viewForAnnotation:(id )annotation
CATransform3D transformZ = CATransform3DIdentity;
transformZ = CATransform3DRotate(transformZ, _rotationZ, 0, 0, 1);
annotation.myView.layer.transform = transformZ;
Anyone else seen this and anyone got any suggestions on how to fix it on iOS6?
I had an identical problem so my workaround may work for you. I've also submitted a bug to Apple on it. For me, every time the map got panned by the user the Annotations would get "unrotated".
In my code I set the rotations using CGAffineTransformMakeRotation and I don't set it in viewForAnnotation but whenever the users location get's updated. So that is a bit different than you.
My workaround was to add an additional minor rotation at the bottom of my viewForAnnotation method.
if(is6orMore) {
[annView setTransform:CGAffineTransformMakeRotation(.001)]; //iOS6 BUG WORKAROUND !!!!!!!
}
So for you, I'm not sure if that works, since you are rotating differently and doing it in viewForAnnotation. But give it a try.
Took me forever to find and I just happened across this fix.
We're porting an application from Tru64 to SLES11 and the part that I'm working on right now is a GUI written with TeleUSE.
The problem that I'm encountering is that one of my XmBulletinBoardDialogs has only half the size on LINUX compared to Tru64. I've tried to change the height in the pcd file and the generated c code looks alright but has no effect:
XtSetArg(args[n], XmNheight, 800); n++;
Any appearance changes that I've tried had no effect also..
Are there known problems or changes in functionality between the platforms or should I search for constraints from parent windows (then how would they look like?)? I'm new to TeleUSE so any hint on a probable source for the problem would help.
The size of the window was set by the input string "\n\n\n\n TEXT \n\n\n"
The problem was that apparently the parsing of the string is working differently with the function "XmStringCreateLtoR". I had to add spaces between the \n's for the line breaks to have an effect
This happens when compiling for Any Cpu as well as compiling to x86. Sections of the GUI doesn't redraw unless it's resized, for instance if the main form is maximized some of the controls don't resize with it, and others have sections that don't redraw and displays the what was previously there.
This works fine on 32-bit machines, both XP and Vista, but on 64-bit Vista (don't have x64 XP to test with) the redrawing just isn't working properly.
Anyone have any ideas on where to start tracking this down?
Edit: This occurs on 2 separate machines, and at least the one I'm currently on has the latest drivers from NVidia.
Edit2: Running a 32-bit XP virtual machine on my 64-bit machine and the application doesn't exhibit the redrawing issue in the VM
Edit3: It may be a driver issue, but we don't know if or when drivers will fix the issue. A co-worker says there's fewer issues with an ATI card at home than with NVidia, but I've been updating my video drivers pretty much monthly for the past few months and it's still not resolved, so we can't just release our product and just tell our customers that some day the driver manufacturers may get around to fixing this.
Does anyone have any insight on what things to try to avoid? We're compiling as x86 and all our components are x86. I can't seem to reproduce this issue with any of the components in test projects, and I haven't heard anyone else report these issues on most of the the component forums, so it is fairly likely that it's something we're doing.
That sounds horribly like this problem.
When resizing windows on Windows you typically get a chain where each window receives a WM_SIZE message and then calls MoveWindow() (or similar) on its children which in turn receive a WM_SIZE and so on. I'm sure that .NET does the same thing under the covers.
On x64, Windows limits the depth of this nesting, and after a certain point (12-15 nested windows) it will just not send the WM_SIZE messages anymore. This limitation does not appear to exist on x86. This limitation affects both x86 and x64 code running on x64 versions of Windows.
This foxed us for ages, as different x64 installs would show different symptoms. The MSDN blog posting above has some possible workarounds - we ended up using a secondary thread to do the window sizes asynchronously, this solved the problem fairly neatly.
If you're using Windows Forms, it could be to do with nesting limitation issues on Windows 64-bit.
Details here: http://www.feedghost.com/Blogs/BlogEntry.aspx?EntryId=17829
In summary...
From the MS source, in Control.SetBoundsCore:
SafeNativeMethods.SetWindowPos(new HandleRef(window, Handle), NativeMethods.NullHandleRef, x, y, width, height, flags);
// NOTE: SetWindowPos causes a WM_WINDOWPOSCHANGED which is processed
// synchonously so we effectively end up in UpdateBounds immediately following
// SetWindowPos.
//
//UpdateBounds(x, y, width, height);
And from MSDN:
http://social.msdn.microsoft.com/forums/en-US/windowsuidevelopment/thread/25181bd5-394d-4b94-a6ef-06e3e4287527/
"A little investigation showed that Windows stops sending WM_SIZE
when it reaches some certain nesting
level. In other words, it won't send
WM_SIZE to your child windows if you
try to resize them when you process
WM_SIZE in the parent ones. Depending
on the USER stuff/updates/serivice
packs the maximum nesting level at
which it stops propagating WM_SIZE may
vary from 15 to 31 and even much
higher (effectively unreachable) under
latest XP 32bit/sp2.
But it still too little under XP x64 and still some similar ugly things
happen to other messages under some
builds of Vista.
So it is certainly a Windows bug."
You have two choices: either reduce the depth of your control hierarchy (the more ideal solution), or else derive "fixed" controls from each of the system ones that you use, as follows:
public class FixedPanel : Panel
{
protected override void SetBoundsCore( int x, int y, int width, int height, BoundsSpecified specified )
{
base.SetBoundsCore( x, y, width, height, specified );
if( specified != BoundsSpecified.None )
{
if( ( specified & BoundsSpecified.X ) == BoundsSpecified.None )
{
x = Left;
}
if( ( specified & BoundsSpecified.Y ) == BoundsSpecified.None )
{
y = Top;
}
if( ( specified & BoundsSpecified.Width ) == BoundsSpecified.None )
{
width = Width;
}
if( ( specified & BoundsSpecified.Height ) == BoundsSpecified.None )
{
height = Height;
}
}
if( x != Left || y != Top || width != Width || height != Height )
{
UpdateBounds( x, y, width, height );
}
}
}
I think the most likely cause of this problem is a redraw issue in your application. It's possible that there is a subtle windows message ordering difference on 64 bit that is exposing this issue in your code.
You can experiment with this by doing the following.
Add a timer to your application.
In the event handler call flakyControl.Update()
I would set the timer to something long like 5 seconds. Then run the application on Win64 and see if that fixes the issue. If so then the most likely cause is one of your controls is not properly signaling that it's been invalidated.
I would start with any custom controls in the application. Systematically add an Update call to every overriden method and event handler in the code. Eventually you'll find the one that fixes the issue and then you'll know where the bug actually is.
If you use the BeginInvoke() solution described on the MSDN blog make sure to disable docking of the children of the control that overrides OnSizeChanged(). I had Dock = DockStyle.Fill and had to change to DockStyle.None for the fix to work.
Sounds like a display-driver problem to me...
Try updating to the latest drivers and see if that fixes the problem? The 64/32 bit difference is probably a red-herring...
I would agree with Gordon. I've seen issues where brand new 64-bit machines had display issues with programs that looked fine under 32-bit, but would exhibit odd issues on 64-bit machines. Updating to the latest/recommended drivers almost always fixed the issue.
The fact that you can run the program on a virtual OS without issues suggests that it is a driver issue, because (at least in VirtualPC) the graphics card is emulated. This means that some things which the graphics card would normally handle is now done by the CPU, and thus not interacting with the graphics driver. Mind you that I'm not an expert on virtualization and I suppose the virtualization layer could affect the issue in other ways.
I believe this is related to the number nested HWND's in the tree. I don't know the specific details, but there were some restrictions placed on nested HWNDs with 64bit. The times I've seen it occur, I work around it by dropping back from the full vista basic (or aero) theme, to windows classic. At this point the issues go away.
Try switching to classic, and if that resolves it, see if you can reduce the number of nested HWNDs.