This allows windows/widgets to learn when something is being dragged
over them. They can then repaint themselves somehow to indicate that
they are willing to accept a drop.
Currently this is piggybacking somewhat on the mouse event mechanism
in WindowServer. I'm not sure that's the best design but it seemed
easier to do it this way right now.
Shuffle around some menu related code from window manager into menu
manager. This still is not perfect, and results in a little more of the
window manager to be publically exposed - but this is another step
towards better seperation of concerns between menu and window manager.
We also move the mouse_event handling into a new function in menu manager
as event handling was beginning to become a bit chunky.
If the window switcher is up when a window is made frontmost (usually
by clicking on it), the window will now become the selected window in
the switcher.
This still has a slight feeling of "hmm" but is definitely better than
what we had before.
Move applet logic to the own class. Remove applet code from MenuManager.
With new AppletManager applet order is configurable via WindowManager.ini file.
Some apps (looking at you, VisualBuilder) don't specify an icon
in their .af file, so WindowServer was trying to open an empty path.
That made it print a perror message to the log each time. Let's not
do that ^)
I started adding things to a Draw namespace, but it somehow felt really
wrong seeing Draw::Rect and Draw::Bitmap, etc. So instead, let's rename
the library to LibGfx. :^)
I've been wanting to do this for a long time. It's time we start being
consistent about how this stuff works.
The new convention is:
- "LibFoo" is a userspace library that provides the "Foo" namespace.
That's it :^) This was pretty tedious to convert and I didn't even
start on LibGUI yet. But it's coming up next.
This commit adds vertical wrap to menus. The first item is focused if
Key_Down is pressed on the last item and the last item is focused if
Key_up is pressed on the first item.
While one window is blocked by another modal one, just ignore events on
the window frame, and also ignore set_minimized() and set_maximized().
The only thing you're allowed to do with a blocked window is moving it.
Fixes#1111.
WSWindow now detaches from WSClientConnection when being destroyed.
Because of this, we can no longer rely on WSWindow::client() to tell
us whether a window is internal to WindowServer or not. So instead we
now have WSWindow::is_internal() which checks for client_id == -1.
Note that WSWindow now also gets a copy of its client_id when
constructed, since we can no longer rely on client() being valid after
destruction has started.
This allows various automatic mechanisms (e.g what happens in response
to window removal) to skip over windows that are being destroyed.
Fixes#387.
If something goes wrong when trying to message a windowing client,
we now tear it down *on next event loop* instead of immediately.
This avoids having to deal with disconnected windows suddenly
disappearing from window lists while looping over them.
Without this, we can't start programs via the system menu. This begs
the question: should WindowServer really be allowed to fork and exec
in the first place?
WindowServer needs persistent access to a few things:
- /res (for themes, fonts, cursors, apps, wallpapers, etc.)
- /etc/passwd (for username lookup, not sure this is actually needed..)
- /home/anon/WindowManager.ini (FIXME: this should not be hard-coded..)
These things are unveiled temporarily, and then dropped:
- /tmp (for setting up sockets)
- /dev (for opening input and framebuffer devices)
This leaves WindowServer running with a very limited view of the file
system, how neat is that!
A mouse move event needs to do a bit more work than what a mouse wheel event
does. Mouse wheel just needs to update the hovered item, and update for a new
hovered item. This also stops us from calling redraw() twice on a wheel event.
While I really enjoyed having an infinite cycle when I implemented menu
keys (and seeing it wizz around and around :D), menu key movement should
be consistent between menus - and an inifinite cycle does not make much
sense for a scrollable menu.
Menus now have a scroll offset (index based, not pixel based) which is
controlled either with the mouse wheel or with the up/down arrow keys.
This finally allows us to browse all of the fonts that @xTibor has made
avilable through his serenity-fontdev project:
https://github.com/xTibor/serenity-fontdev
I'm not completely sure about the up/down arrows. They feel like maybe
they occupy a bit too much vertical space.
Also FIXME: this mechanism probably won't look completely right for
menus that have separators in them.
Fixes#1043.
Use an imaginary triangle between the top and bottom of the submenu of a
hovered item to determine whether the mouse is moving towards the
submenu. If it is, we do not update the hovered item. This allows the
submenu to stay open, making for much easier menu navigation.
Closes#1094
As suggested by Joshua, this commit adds the 2-clause BSD license as a
comment block to the top of every source file.
For the first pass, I've just added myself for simplicity. I encourage
everyone to add themselves as copyright holders of any file they've
added or modified in some significant way. If I've added myself in
error somewhere, feel free to replace it with the appropriate copyright
holder instead.
Going forward, all new source files should include a license header.
Tracking the hovered menu item independently from the index of the
currently hovered item is error prone and bad code. Simplify WSMenu by
only tracking the index of the currently hovered item.
Fixes#1092
