This patch extends the 'File_system::Status',
'File_system::Directory_entry', and the related 'Vfs' types with
the following additional information:
- Distinction between continuous and transactional files (Node_type)
(issue #3507)
- Readable, writeable, and executable attributes (Node_rwx),
replacing the former 'mode' bits
(issue #3030)
The types 'Node_rwx', 'Node_type' are defined twice,
once for the VFS (vfs/types.h) and once for the 'File_system'
session (file_system_session/file_system_session.h).
Similarly, there is a direct correspondance between
'Vfs::Directory_service::Dirent' and 'File_system::Directory_entry'.
This duplication of types follows the existing pattern of keeping the
VFS and file-system session independent from each other.
Moving the handling into the input-session clients enables more
sophisticated implementations (like Qt5) to apply key-symbol based
handling of those modifiers like correct CTRL-A with QWERTY and AZERTY
layouts and distinction of CTRL-J and Return.
Issue #3483
With the added modification-time support in the libc, the extract tool
requires a timer session, which is not plausible for the purpose of the
program.
This behavior stems from the fact that the libc implicitly writes the
mtime when closing a written file. For this update, it implicitly calls
'clock_gettime', which in turn initializes the timer subsystem within
the libc (creating a timer session).
For the extract tool, the implicitly updated mtime is useless because
the extract tool overwrites this modification time with the mtime stored
in the archive anyway. However, the dependency from a timer service
remains.
This patch explicitly disables the libc's implicit updating of the
file-modification when closing a written file.
Issue #1784
This adds complete character-generator configurations for English (US),
German (Germany and Switzerland), and French (France and Switzerland).
The configs are manually amended and stripped-down versions of
xkb2ifcfg generated configs.
Issue #3483
This patch handles the situation where the usb_block_drv exits for any
reason, in particular when the driver fails to initialize the device. In
such cases, the usb_block_drv used to stay stale in the system,
effectively preventing the device from being passed to a VM. With the
patch, the USB storage device gets flagged as failed, the usb_block_drv
is removed from the runtime, and the condition is reflected at the user
interface.
This situation occurred on the attempt to access an iomega zip drive
with a version of the usb_block_drv without support for the START-STOP
command, but it may potentially also occur in other circumstances.
Fixes#3468
This commit implements the ssh exec channel request. It also handles
some shortcommings on the interactive channel like exit and concurrent
session establishments.
Pipes into the channel do not work yet. E.g.:
echo foobar | ssh noux@localhost -p 5555 "cat > /rw/test.txt"
The issue described with FIXME in Ssh::Server::incoming_connection()
could not be reproduced and might have been fixed with the improved
file descriptor handling.
Fixes#3401
To enable the clipboard for a VM, add the following node to the
<Hardware> sub node of your machine.vbox configuration:
<Clipboard mode="Bidirectional"/>
Issue #3437
The triggering of a new depot query can happen more than once per
activation of the sculpt manager if multiple conditions call for updated
information about the depot. When this happens, the depot-query
component produces intermediate results, which are not consumed by the
sculpt manager. By deferring depot queries for a few milliseconds, we
avoid such intermediate queries, relieving the workload of the
depot-query component at system boot time.
Issue #3436
The diagnostic messages presented in the runtime dialog lacked the name
if the subsystem was created from a launcher, e.g., the 'vm'. Instead of
determining the subsystem name from the start-XML-node (a launcher has
no 'name' attribute but the name corresponds to the launcher's file
name), the name is now passed as a dedicated argument.
The labels of clipboard ROM and clipboard report sessions of WM clients
must be consistent with the client's nitpicker label. Hence, we must
route those sessions through the window manager, analogously to the
approach taken for shape reports in #3165.
Issue #3437
This patch introduces two caches to the depot-query tool.
- A stat cache remembers the results of 'Directory::file_exists'
calls.
- The 'Cached_rom_query' caches the result of scanning the depot
for a given ROM module and pkg path. To elminates the need to
parse 'archive' files of pkgs referenced from other pkgs or
for the repeated instantation of the same pkg.
Both caches are bypassed whenever referring to the 'local' depot user.
Fixes#3427
When resizing windows of clients that respond very slowly to resize
requests, the window's size sometimes snapped back to its original size
immediately after finishing the drag operation.
The problem was caused by the interplay of the layout rules (obtained
via the 'rules' ROM, generated by the 'rules' report) and the
temporary interactive state that occurs during drag operations.
The rules are updated only at the time of releasing the button to keep
the overhead while dragging the window low. However, when releasing the
mouse, the (now outdated) rules kicked back into effect, triggering
resize requests for the window to its old size.
The patch solves this problem by decoupling the dragged state of a
window from the physical release of the button. The button release
triggers a transition from a DRAGGING to a SETTLING state and programs
a timer. In the SETTLING state, the windows behave as in DRAGGING state,
giving the interactive geometry precedence over the rules-dictated
geometry. During this state, further responses of window-resize requests
may come in and are handled like dragging was still in progress. After a
timeout, however, the current window layout is conserved as a new rules
report and the state goes back to IDLE.
For clients that takes a very long time (in particular, VirtualBox when
resizing the desktop, which takes sometimes multiple seconds), the
snap-back artifact can still occur, but the effect is reduced.
This problem surfaced with the new tool chain that changes the stack
layout. A pointer to the the config XML data was kept in the main object
but pointed to a stack variable. This patch fixes it by removing the
pointer.
Fixes#3416
This patch adds the missing propagation of the maximized state from the
layout rules to the internal representation of a window. Without this
patch this state could be toggled by clicking on the maximizer button
only.
The decorator's detection of the hovered window element was inaccurate,
which resulted in "jumping" windows in some situations, ultimately
caused by a combination of three different mechanisms.
First, when moving the pointer into the area of a window, the decorator
would detect the hovering of the left border whenever the distance of
the pointer from the border was less than the half of the theme texture
(e.g., 64x64 pixels for the default theme). However, if the left border
margin is set to a small value (e.g., 1), there is an overlap of the
sensitive resize border area and the content. Hence, chances were quite
high that - when moving the pointer from the left into the window - the
hover report would contain the hovering of the left border.
Second, the window manager tries to hide pointer movements from the
decorator if possible. It informs the decorator of the pointer position
if any decoration is hovered or if a new window is hovered. But it does
not expose pointer movements within a window to the decorator. For this
reason, the decorator would not update the hover report as long as the
pointer stays within a once hovered window. In the situation described
above, the hover report would still contain the stale information about
the hovering of the left resize border.
Third, when the user clicks on the window, the decorator examines the
most recent hover report and - in the situation described above - finds
the left border hovered. Consequently, it initiates a window-drag
operation. While resizing the window with the left border, the window
layouter pins the right border of the window to its current position.
All window-size changes of the client will be applied towards the left
(dragged) border. In the case of the top view, which continuously
resizes the window by itself, the window would "jump". In reality, it
actually tries to respond an interactive resize operation. The window
layouter cannot guess that the client is not responding to window
layouter's resize request but is acting independently.
This patch fixes the jumping window problem for the case where the
pointer hovers the overlapping area of the resize border and the
content. However, when trying the to interactively resize the top window
via the bottom-left corner, the "jumping" can still be observed.
Fixes#3303
By decoupling the leitzentrale from the (contended) boot CPU, the fading
on F12 interferes much less with animations like nano3d deployed in the
runtime.
Fixes#3268
