urls were previously added to history in the Tab::load()
function, which excluded the setter on window.location.href.
This commit adds all urls to browser history when the page loads,
as long as the load_type is not LoadType::HistoryNavigation.
Closes#3148
Instead of translating between the sorting proxy and the underlying
file system model at all the DirectoryView API boundaries, just hand
out indexes into the sorting proxy model.
The only thing those indexes are used for on the outside is to
retrieve a GUI::FileSystemModel::Node for an index, so add a nice
helper on DirectoryView that turns a ModelIndex into a Node&.
The Node API was obnoxiously requiring you to pass the model into it
all the time, simply because nodes could not find their way back to
the containing model. This patch adds a back-reference to the model
and simplifies the API.
This patch begins the process of converting FileManager's desktop mode
to using the DirectoryView class.
This will allow us to share most of the code between the two different
runtime modes of FileManager.
We lose a bit of functionality in this patch, but we'll bring it back!
I noticed that nothing actually applies the wallpaper on startup.
I wasn't sure where to put the responsibility, so I gave it to
the desktop mode file manager.
Also adds a save_config option to set_wallpaper so it doesn't
needlessly save the config.
If the process table grows or shrinks, we need to invalidate all the
ProcessModel indexes. This is not great, but it's the most precise
invalidation we can do at the moment.
Instead of SortingProxyModel having a column+order, we move that state
to AbstractView. When you click on a column header, the view tells the
model to resort the relevant column with the new order.
This is implemented in SortingProxyModel by simply walking all the
reified source/proxy mappings and resorting their row indexes.
This removes one major source of confusion in DirectoryView. It's still
weird that we mix sorting model indexes with filesystem model indexes
a bit willy-nilly but we'll improve that separately.
This changes the graph caption from KB to KiB, but it keeps just "K"
instead of "KiB" for all the numbers in columns in the table, since "K"
is fairly well-established as abbreviation of "KiB" (the SI prefix is
lower-case), and space is at a premium here.
Let's use the one in AK/NumberFormat.h everywhere.
It has slightly different behavior than some of the copies this
removes, but it's probably nice to have uniform human readable
size outputs across the system.
The SI prefixes "k", "M", "G" mean "10^3", "10^6", "10^9".
The IEC prefixes "Ki", "Mi", "Gi" mean "2^10", "2^20", "2^30".
Let's use the correct name, at least in code.
Only changes the name of the constants, no other behavior change.
This is a follow up to #2936 / d3e3b4ae56aa79d9bde12ca1f143dcf116f89a4c.
Affected programs:
- Applications: Browser (Download, View source, Inspect DOM tree, JS
console), Terminal (Settings)
- Demos: Cube, Eyes, Fire, HelloWorld, LibGfxDemo, WebView,
WidgetGallery
- DevTools: HackStudio, Inspector, Profiler
- Games: 2048, Minesweeper, Snake, Solitaire
- Userland: test-web
A few have been left out where manual positioning is done on purpose,
e.g. ClipboardManager (to be close to the menu bar) or VisualBuilder (to
preserve alignment of the multiple application windows).
Various applications were using the same slightly verbose code to center
themselves on the screen/desktop:
Gfx::IntRect window_rect { 0, 0, width, height };
window_rect.center_within(GUI::Desktop::the().rect());
window->set_rect(window_rect);
Which now becomes:
window->resize(width, height);
window->center_on_screen();
This patch adds GUI::FocusEvent which has a GUI::FocusSource.
The focus source is one of three things:
- Programmatic
- Mouse
- Keyboard
This allows receivers of focus events to implement different behaviors
depending on how they receive/lose focus.
We should stop accessing the FileSystemModel outside DirectoryView.
This whole app is pretty badly factored, due to LibGUI being in its
infancy while it first developed.
With this information, it's a bit easier to intuit the current 'process tree'.
If you're reading this, can I convince you to implement a nice process tree for
SystemMonitor? It could be via PPID (unbounded depth), or SID+PGID (depth 3).
Or something else entirely :D
So far, clicking on a link from the Markdown/HTML preview Web::PageView did
nothing - now we pass that link to Desktop::Launcher, which will then
open it in Browser, FileManager, another TextEditor instance etc.
