Awesome WM: what do the icons of the title bar mean? - awesome-wm

can someone tell me what is the meaning of the icons in the title bar? A rocket, a plus, a star.. Im very curious.

Look at the file names of the icons. The first component describes the meaning: https://github.com/awesomeWM/awesome/tree/master/themes/default/titlebar
The plus is for sticky windows. These are windows which are visible on all tags (normally windows are only visible if one of their tags is selected).
The star is for ontop. These windows ignore the normal stacking order and are ontop of everything else.
The rocket is for maximized windows. These windows ignore the current layout and use all the available space.
The arrow is for floating windows. These windows also ignore the current layout, but they can be freely resized to any size.
The cross is a close button. It closes windows! ;-)

Related

Is it somehow possible to get a native Windows menu bar in NW.js applications, or to at least style them?

I've followed this: https://nwjs.readthedocs.io/en/latest/References/Menu/#menu
The result is a very Chromium-looking menu. The items just look... nothing like how I think of Windows menu items. (Even though there are these days a million different styles of them in this FrankensteinOS...)
Is this it? I have to use whatever Chromium thinks is a good looking menu? I cannot style them with CSS or something, at least? For example, if I want them to be "dark mode" instead of bright white? I guess I could implement my own custom Canvas-based pixel-perfect menu, but that's both a ton of work and also will never feel native or quite as "responsive".
The documentation you pointed to is for using the Native OS Menu. This will be different on Linux, OSX, and Windows, and will match the native placement and interactions for that system, including keyboard navigation. Similar to how the minimize/maximize/restore/close buttons are built in and differ on each OS.
You can add your own markup and styling to create a custom menu if you like though, and it will look and act the same on every OS. Similarly, you can create your own markup and styles for the min/max/restore/close buttons, and title bar.
https://github.com/nwutils/frameless-example
If you're not confident in HTML/CSS enough to make a responsive menu yourself, you can use frameworks, like Bootstrap, which come responsive with menu styling out of the box.
https://getbootstrap.com/docs/5.0/components/navbar/

RStudio window zoom when changing from laptop only to docked to monitors, auto-adjust possible?

I was given a new laptop at work and when I switch back and forth from a docking station, RStudio seems to have problems realizing the change in display, while all the other programs seem to auto-detect and re-zoom appropriately. The only fixes I've found is logging out and back into my Windows user account, or going through R-Studio's View>Zoom-in or View>Zoom-out when going back and forth between docked and undocked, which takes time.
There's not some setting I'm missing, is there, so RStudio detects the type of display and auto-adjusts? Example images below.
thank you, dave
This is a known issue, and there is some indication that there are plans to address this in rstudio v1.2.
https://community.rstudio.com/t/dramatic-screen-resolution-issue-see-screen-snip/3703/6
A workaround suggested here:
You should be able to work around this by toggling the Zoom level in the Appearances pane
RStudio is basically a browser window (chrome web application). It will render according to the resolution of the screen, at the current zoom setting. It will not change your zoom level as you switch monitors. Ctr- and Ctrl+ are shortcuts for zooming in and out, where you should also see a popup with a reset (to 100%) option.
Zooming is not the same as changing font sizes, which is the preferable way of ensuring a good visual experience for a resolution.

2sxc shake edit buttons remain in sight

I installed 8.8. And shaking my phone like a maniac but the edit buttons remain in sight. Is that a known issue or should I be doing something different (like adjusting templates or something).
Kind regards
Tycho
If a button is visible or not is configured at various levels. So it can be that your buttons are set to always visible - in which case the shake has no effect.
But if you're just using normal buttons which only appear on float, and they already appear (on desktop and mobile) without float/shake, then it's probably something different.
Best to do some more testing to corner the issue.

Increasing font size in RStudio

On my MacbookPro, I can hold the command button down, then hit the +/= button and the fontsize increases in each and every panel, making it easier to read from a distance for my students viewing on our Smartboard.
How is this same thing performed on a PC Windows machine?
Ctrl++, and
Ctrl+-
More keys might be necessary to generate +/- (for instance, for me Zoom In is Ctrl+Shift+=).
Other notes:
You can also zoom in using the View menu
See a list of keyboard shortcuts with Alt+Shift+K (recent versions of RStudio only)
Tool --> Global Options --> Appearance --> Then you can adjust the font size at the right panel

Safari + jQuery thickbox = massive visual glitches?

I need help determining what the cause of a serious visual glitch is with one of my production websites. It is only happening with Safari - Chrome and all other browsers are fine.
http://www.philanthropicdirectory.org/search
This is a Drupal 6.x website, running the following simultaneously:
jQuery 1.3.2 (Drupal base/default)
jQuery 1.4.4 (This is used here and there by overriding the jQuery namespace to '$js' for certain advanced operations 1.3.2 can't handle)
jQuery UI 1.7.3
Thickbox 1.8.2.19 (I've slightly modified this .js)
TO REPRODUCE:
Click link (visit the page): http://www.philanthropicdirectory.org/search
Click twice (once to center) on any of the 5 'coverflow' panels to trigger Thickbox content
Once TB content loads, resize the browser window horizontally left or right
Notice the odd background-image and background-color offsetting
Switch between any of the 5 'tab' icons in the upper right of the modal system
At any point, use Web Inspector to uncheck and then recheck any CSS property, anywhere
Notice how this instantly clears/fixes all visual glitches
Resize the browser window again or tab between the other tabs, and notice the glitches return.
If you notice the same things I am, it'd be great to get your machine config and Safari version.
Before
After resizing
After tabbing
The images say it all, and as far as I could test, I can only reproduce this problem in the following setup, with Safari:
MacPro, 6-core Xeon (2010)
OS X 10.6.8
2 monitors: 1x 23" Cinema Display (old silver one) + 1x 27" Apple Cinema Display
ATI Radeon HD 5770 (Mac version w/01.00.436 Driver)
Safari 5.1+
I've tested other machines and other machines with earlier versions of Safari (4.x), and the problems are simply not present.
Is there anything you think I can test to figure out why this is happening?
PS: Only using one monitor at a time produces the same problems.
SOLUTION!
I noticed this happening with another website we've built - a website with nothing in common with the Drupal one with the problem here, save for the fact that this new one also has a Flash (SWF) file in the body, and I was applying a CSS property to an element with a negative z-index value.
It was happening on this new website because the container for the object in the HTML was set to
z-index: -1;
in order for elements positioned to overlap the object could be clicked on (otherwise, links on top of the object could not be interacted with).
I was able to permanently fix it by instead setting any elements positioned on top of the object
z-index: 1; /* or anything > 0 */
Given that solution, I hunted down any and all "z-index: -1" CSS on the Drupal website and sure enough there was an element within the Thickbox container that was shown on every tab - the big green "SEARCH" input button. It was styled that way because of visual needs (something to do with the fake inner-drop-shadow on the button).
I disabled the entire z-index property for this element, and lo-and-behold, the funkiness permanently disappeared on the Drupal website.
Hurray! It was surely providence that I came across the same issue more acutely on a different website.
Now I'm not sure the exact bug in Safari that is behind this without intense testing, but all I do know is that an object on the page + any element near it set to z-index: -1 equals total meltdown (on a Mac running Safari 5.x).
I checked in Safari 5.1 (7534.50) on an HP Xeon running Windows 7. I don't see any glitches.
That's weird. Sounds like a race condition of some sort. Maybe there is a bug in your ATI driver? Since it fixes itself when you re-render it, perhaps you could introduce some delay somewhere which might give it more time to render properly?

Resources