I am trying out awesome at the moment coming from KDE/MATE since many years and I really like it a lot. There's really only one thing that I'm missing from my previous workflows.
Occasionally I'm working with applications that have a lot of floating windows. What I found tremendously helpful in floating WMs was the ability to roll up or shade a window, basically only keeping the titlebar of the application but hiding its window contents.
Is this possible in awesome? Alternatively are there other options like tabbing windows (like in i3) or do you have other suggestions?
Thanks a lot in advance!
Is this possible in awesome?
Theoretically yes, but practically I do not know about anyone who implemented the necessary magic yet to make this work properly. A semi-good first approximation might be to resize the window to height 1.
Untested sketch:
function toggle_roll_up_or_shade(c)
if c.shade then
c:geometry{ height = c.shade }
c.shade = nil
c.size_hints_honor = c.size_hints_honor_before_shade
elseif c.floating then
c.shade = c.height
c.size_hints_honor_before_shade = c.size_hints_honor
c.size_hints_honor = false
c:geometry{ height = 1 }
end
end
The above function would then be bound to some key similar to how Mod+Ctrl+Space is bound to awful.client.floating.toggle in the default config.
Here is a variant which might work on AwesomeWM v3.5:
function toggle_roll_up_or_shade(c)
if awful.client.property.get(c, "shade") then
c:geometry{ height = c.shade }
awful.client.property.set(c, "shade", nil)
c.size_hints_honor = c.size_hints_honor_before_shade
elseif c.floating then
client.property.set(c, "shade", c.height)
client.property.set(c, "size_hints_honor_before_shade", c.size_hints_honor)
c.size_hints_honor = false
c:geometry{ height = 1 }
end
end
Also, if you want to get the height of the titlebar, you should be able to use local _, height = c:titlebar_top(). I'm not sure if this also works in AwesomeWM v3.5.
Related
Let me ask you a question about PIXI.js. In Chrome, these lines looks like not the same thickness, but its the same Graphics API (lineTo, moveTo). Why is that?
let boxW = 46.5;
this.leftBox
.lineStyle(1, 0x000,1)
.beginFill(0xffffff)
.moveTo(0, 0)
.lineTo(465, 0)
.lineTo(465, 465)
.lineTo(0, 465)
.lineTo(0, 0)
.endFill();
for (let i = 1; i <= 9; i++) {
this.leftBox.moveTo(boxW * i, 0).lineTo(boxW * i, 465);
}
PAEz is right, it is likely anti aliasing.
When you create you Application anti-aliasing is turned off by default.
Try the below and see if it helps:
const app = new PIXI.Application({
'antialias': true,
'resolution': 2 // This may help too
});
// Add the view to the DOM
document.body.appendChild(app.view);
// ... your line code
The documentation for the Application class and its options can be found here:
https://pixijs.download/dev/docs/PIXI.Application.html
As a side note, PIXI is very fast but as your application scales anti-aliasing and resolution may have performance implications.
Finally to answer your question about what anti-aliasing is, in short, its a way to smooth out jagged edges on non-rectangular shapes, though you have a series lines it could help with your situation too. Here is an article that can tell you more: https://www.gamingscan.com/what-is-anti-aliasing/
I've 3 (loader, locker and debug view) hidden views (touchEnabled and visible set to false, and zIndex to 1) above the main view (zIndex = 2).
Each 'over' view has this method:
$.debugView.show = function() {
$.debugView.touchEnabled = $.debugView.visible = true;
$.debugView.zIndex = 3;
};
$.debugView.hide = function() {
$.debugView.touchEnabled = $.debugView.visible = false;
$.debugView.zIndex = 1;
};
This screen has the 3 'over' views hidden:
Now, I'm opening the 'debug view', but, SOMETIMES it seems like it changes the positions (as if the center it's on the top left corner instead of the center of the device).
Instead of the required result:
If I use the opacity instead of the visible property, it works properly.
This might be an SDK bug right?
<Alloy>
<Window>
<View id="content"/>
<View id="locker"/>
<View id="loader"/>
<View id="debugView"/>
</Window>
</Alloy>
All of these 4 views don't have width or height (so it uses the Ti.UI.FILL as default)
I have noticed this too with a completely different implementation. I had just one view that I included in a window.
Apparently the left and top calculations were not done properly if the elements is hidden.
What I did to solve the issue is to hardcode the left/top position by calculating the left position using this:
$.content.left = (Ti.Platform.displayCaps.platformWidth - 75) / 2;
Where in my case 75 is the width the element has, so that'll be bigger in your case. You can do the same for height.
Now, this is an iOS only solution. On Android you will need to take DPI into consideration calculating it.
I do think it is a bug, though this solution works perfectly for me. I recommend looking at JIRA and see if it is a known issue, and if not, raise it with a very specific explanation of the problem, preferably with a reproducible case delivered as an app. Classic would help most. And if it is not reproducible in classic it might be an alloy issue.
I have vb.net winform app that has
AutoScaleMode = dpi
AutoScale = false
AutoSize = true
I've signed off after changing DPI setting.
I also tried restarting the machine.
Using g As Graphics = form.CreateGraphics()
Dim dpiX As Single = g.DpiX
dpiX is always 96 regardless of DPI setting. Anyone know what I am doing wrong?
I found solution. My app's manifest has to say it is dpiAware.
Because I am trying to detect high DPI and show a warning message box and not really trying to make my app dpi aware, I couldn't do that.
You can get dpi aware information from registry:
HKEY_CURRENT_USER\Control Panel\Desktop
LogPixels.
If you are using default, you won't have the key. Changing DPI setting will create one.
I ran into this problem and found that if you override the OnPaint(PaintEventArgs e) method of the form, and then get the Graphics object from the argument 'e' i.e. e.Graphics then the DpiX and DpiY value of this Graphics object is correct.
Unfortunately, the way windows handles DPI scaling is all over the place:
Using g As Graphics = form.CreateGraphics()
Dim dpiX As Single = g.DpiX
This code will only work if user has "Use Windows XP Style DPI Scaling" selected when setting custom DPI. Don't know if that option is even available in the new versions of Windows (8.x and 10) or if they've taken it out.
Your best bet would be to just read the registry:
Dim regUseDpiScaling As Integer
Try 'Use Try / Catch since the reg value may not exist if user using 96 DPI.
regUseDpiScaling = CInt(My.Computer.Registry.GetValue("HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM", "UseDpiScaling", Nothing)) ' if this returns 1, it means users is using modern DPI scaling.
Catch ex As Exception
regUseDpiScaling = 0 ' 0 means no DPI scaling or XP DPI scaling
End Try
If Not (regUseDpiScaling = 0) Then
boolUsesModernDPIScaling = True 'Means you haven't clicked "Use Windows XP Style DPI Scaling" while setting DPI in your system.
Else
boolUsesModernDPIScaling = False
MsgBox("2")
End If
Dim regAppliedDPI As Integer
Try
regAppliedDPI = CInt(My.Computer.Registry.GetValue("HKEY_CURRENT_USER\Control Panel\Desktop\WindowMetrics", "AppliedDPI", Nothing))
Catch ex As Exception
regAppliedDPI = 96
End Try
DPIratioX = regAppliedDPI / 96
DPIratioY = regAppliedDPI / 96
I found that having XP DPI scaling can result in different behavior, so it's good to have the program detect if it's being used.
There is a too long, didn't read version down below.
So I've been making a little game in which the player has to click on a grid of bricks that matches the color of the needed brick in the upper right hand corner of the screen. After they click on the needed color, the bricks explode and the bricks of the same color next to them explode as well creating combos. That leaves holes in the grid so I have to somehow reset the grid itself without resetting the gamestate itself. I've got something working right now which is this:
private function ResetNow():Void
{
if (Restter == 1) Restter = 0;
//if this block is up here, same results
/*
wantedBricks.kill();
wantedBrik._changeColor = FlxMath.rand(0, 2);
bricks.autoReviveMembers = true;
bricks.revive();
*/
Restter = 0;
//Removes stray detectors so the neverending combo bug won't occur
for (stray in dets.members) stray.kill();
if (Restter == 0)
{
wantedBricks.kill();
wantedBrik._changeColor = FlxMath.rand(0, 2);
bricks.autoReviveMembers = true;
bricks.revive();
wantedBricks.autoReviveMembers = true;
wantedBricks.revive();
for (zgem in bricks.members) zgem.EQUITYCHECK = FlxMath.rand(0, 2);
}
//add(bricks);
Restter = 1;
}
So, again, I have a grid of blocks set up at create, that is group bricks. And I have a sprite in the upper right corner which is wantedBrik. What happens during gameplay, is the player clicks on the bricks that matches the wanted bricks to clear them out of the grid. When there are no more wantedBricks(a group), it is supposed to reset the grid, and change the color of the wantedBrik. I also have it somewhere else in the code that if a member of the big grid's EQUITYCHECK(basic object hacked in value) is equal to the wantedBrik, add it to the wantedBricks(which, is why I'm checking for no more of them). So, what happens?
Well, if the color of the wantedBrik doesn't change, everything's fine and resets like normal. the wantedBricks group acurately counts the bricks that actually match the wantedBrik's color. And when it does change, for some reason, gameplay is normal. BUT, wantedBricks not only thinks that the old color is still needed, but it also thinks the new color is still needed too. So when the player clicks the new needed color bricks, they do explode, but because wantedBrik thinks the old color is still wanted, it doesn't hit null and the grid won't reset.
What can I do to make sure that wantedBricks behaves correctly after a color change?
TL;DR version: I need to get a Haxe array to forget or lose old numbers. How can I do this?
The "Pirate Pig" sample may be useful to you. Since it is a puzzle game, there may be some similar problems that were solved there. You can find it using openfl create or nme create depending on which you are currently using.
You can create a simple array like this:
var myArray = [];
You can also type arrays, like this:
var numbers = new Array<Float>();
Then you can use push(), concat() and other array methods.
A killer problem I've had in excel UIs since as long as I can remember, is with listbox scrolling.
When you have more elements in a listbox that can be displayed, a scoll bar will appear. In certain conditions, however, scrolling the bar all the way to the bottom of the list and releasing it, will "jump" the bar a notch upwards, and you won't be able to see the last item in the list. This is illustrated here:
There are many forum posts presenting this issue, and the solution has always been "Set the integral height property to false, and then set it to true again." What this does is slightly resize the listbox so that it the height is rounded to the height of a single row, and then no items are left hidden.
With lstbox
.IntegralHeight = False
.Height = myHeight
.IntegralHeight = True
End With
There are certain cases, however, where this does not work. If you are:
Programatically setting the height of your listbox
NOT using simple listbox selection (fmMultiSelectSingle)
Then simply setting integral height to false and then true after or between changes to height will make an adjustment to the height of your listbox, but when you go to scroll down, the problem will remain - the last item cannot be seen.
The key to this frustrating question is that while everyone else on the internet is confirming that the 'integralHeight' solution works for them, these very special cases are frustrated wondering why it doesn't work for them. So how do they get their fix?
Something I had to discover for myself, and which cannot be found anywhere else (which is why I'm posting it here), is that this problem had the added dimension of being dependent on the selection method. While I cannot fathom how the way the scroll bar works is related to not only the height and integral height property, but also the .MultiSelect property, I have found that it is.
When the .IntegralHeight method shown above does not work, the following method somehow does:
With lstbox
.IntegralHeight = False
.Height = myHeight
.IntegralHeight = True
.MultiSelect = fmMultiSelectSingle
.MultiSelect = fmMultiSelectExtended
End With
By simply changing the .MultiSelect property to fmMultiSelectSingle, and then restoring it back to the selection style desired, the height of the listbox will be automatically adjusted by the .IntegralHeight property to a slightly different height than when these actions aren't performed - the difference results in the scroll bar working correctly:
I hope the discovery of this special case and more precise workaround saves someone the hours of frustration and experimentation I had to go through.
i know this is very old post.
but i've been through a lot to fix this problem, so i just wanna share my tip. :)
first of all,
integralheight method doesn't work when worksheet zoom level is not 100%.
it will change listbox height and width, location, etc. (even if you set object property 'doesn't move or reseize with cell')
and when you try to take it its original size and location with code to fix this, this time its last item can't be seen
my tip is simple.
there's combination between font size and listbox height.
if your font size is 6-10(arial, regular), listbox height goes well with multiples of 12.75 (btw my list box style is 1 : ListStyle, 1-fmListStyleOption. it could be different with style 0)
as long as height is same with these multiples of 12.75, there will be no problem.
in case of font size 12(arial, regular), it's multiples of 13.55
so if there's no restiction about listbox size in your project, just resizing it slightly depending on your font size gives more comfort. :)
I had to anchor the position since my ListBox was walking across the page:
With ListBox1
.IntegralHeight = False
.IntegralHeight = True
.Height = 45
.Width = 69
.Top = 0
.Left = 1255.5
End With
With lstbox
`.Height = myHeight`
`.MultiSelect = fmMultiSelectExtended`
`.MultiSelect = fmMultiSelectSingle`
End With
This worked for me. No need of setting Integral height property
In my case the solution was this method:
with listbox
.IntegralHeight = False
.Height = myHeight
.Width = myWidth
.IntegralHeight = True
.Height = myHeight
.Width = myWidth
end with
Enjoy.
found ridiculously simple way to resolve this issue. adjust your height up or down a little bit so bottom line of list box is between check boxes, then you can scroll down to last item even if IntegralHeight is set to false
Thanks Alain. Your fix worked well for me.
I found a subsequent problem related to the height of the ListBox when resized, that it varied in an unpredictable way depending on the initial height. The resized height was different again when displayed on another machine with 125% text scaling. For example, if I set a height between 358 and 370, the resized height is either 370.65 or 371.4 on my machine but on the machine with 125% text scaling, it is 360.1, 370.25 or 380.45. With such large variability, the result was that the ListBox could obscure other controls below it.
The fix was to start with the maximum height I wanted and reduce the initial height until the resized height was less than the maximum height I wanted. I do this whenever I display that ListBox.
Hmax = 372 'Target Height
H1 = Hmax
With SteelForm.Controls.Item("ListBox1")
Do
H1 = H1 - 1
.IntegralHeight = False
.Height = H1
.IntegralHeight = True
.MultiSelect = fmMultiSelectSingle
.MultiSelect = fmMultiSelectExtended
DoEvents
Loop Until .Height < Hmax
End With
What I've seen in the past on forums is just adding an extra blank row to your list box. That should do it.
Just set the Integral Height property to True