Custom Query (6 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (4 - 6 of 6)

1 2
Ticket Resolution Summary Owner Reporter
#8 fixed XCenter - Increase the Icon Size. martini
Description

Hello

On machines with higher resolutions like 1,920 x 1,080, I usually increase the size of XCenter to a more confortable size. But there is the issue that icons size on any widget remains the same.

I was wondering if something can be done so the user can increase the size of the icons of XCenter.

Regards

#7 invalid Change the "Tray 1" name in default Tray Widget martini
Description

Hello

The "Tray" widget in XCenter came by default with a tray with the system icons called "Tray 1".

I was wondering if we can rename that "Tray 1" and maybe call it "System" by default.

Regards

#5 worksforme WPS restart: reset SHELL semaphores for reliable operation of API "WinWaitForShell" erdmann
Description

using XWP 1.0.13:

there are three named event semaphores that are using by the "WinWaitForShell?" API function so that this function can block on (or being polled for) these 3 events: Desktop created, Desktop opened, Desktop populated.

The named event semaphores are: \SEM32\WORKPLAC\SHELL1WT.SEM (for Desktop created) \SEM32\WORKPLAC\SHELL2WT.SEM (for Desktop opened) \SEM32\WORKPLAC\SHELL3WT.SEM (for Desktop populated)

These 3 event semaphores are created by the 1. instance of PMSHELL.EXE but they are opened and set by the 2. instance of PMSHELL.EXE.

The problem is, that on XWP function "WPS restart", the 2. instance is just terminating thread 1 (which leads to process termination) without resetting these event semaphores. If the WPS is then restarted and an application also starting up (or the WPS) is using "WinWaitForShell?" waiting for the desktop to be created/opened/populated respectively, the "WinWaitForShell?" API call will return immediately without blocking because the event semaphores are still set. This typically leads to hang problems and the like because the WPS is typically not in the state that the application/WPS class expects it to be after returning from "WinWaitForShell?". One indication of such might be WPS classes installed via WarpIn? and requiring a WPS restart to become active where the WPS restart will lead to a system hang.

I propose to reset these 3 event semaphores shortly before the 2. instance of PMSHELL.EXE terminates its thread 1 (on a "WPS restart").

1 2
Note: See TracQuery for help on using queries.