GPAL's fluent interface is its defining characteristic. Every subsystem, every operation, every configuration option is expressed through the same chained method syntax - readable by anyone, consistent across 19 of the 21 possible engine and browser combinations.
Everything in GPAL starts with the GPAL static class. A single entry point that instantiates every subsystem and holds all global configuration through a clean fluent interface.
A Unit of Work (UOW) is GPAL's atomic block - any number of selectors followed by any number of actions, all operating on the same matched set of elements, until the next WithSelector starts a new UOW. One selector can match a hundred elements, and one action then applies to all of them.
Every With... Setter in a fluent chain returns a configuration interface, not the finished object. ToGPALObject(). Or an equivalent explicit cast. Is the step that turns that configuration into a real, usable GPAL object. Both forms do exactly the same thing; which one to write is a matter of what reads best where it's used.
WithHardware switches an element's interaction from programmatic DOM/UI-Automation calls to real OS-level mouse and keyboard events. The same input a person generates. And it works the same way for both browsers and desktop applications.
GPAL.Application automates desktop programs. GUI applications running outside the browser. Using the same selectors, actions, and units of work as GPAL.Browser.
GPAL.Browser is the entry point for web automation. GoTo drives a headful, visible Chrome window; Get runs the same real browser headless. Tabs, history, and the server response code round out the basics.
For the most reliable bot-resistant runs, point GPAL at a real Chrome profile that already has a signed-in session, cookies, and browsing history. If you don't specify one, GPAL creates a temporary profile for the session and deletes it afterward. Which works, but looks more 'bot-like' and can run into its own problems.
WithWaitOnDocumentReady and WithWaitOnIdleConnection both make GPAL wait before continuing after a navigation, but they measure 'ready' very differently. And for pages that load data asynchronously, only one of them tells the truth.
WaitFor means two different things depending on where it appears in a workflow: after WithSelector it's a search timeout for elements that haven't appeared yet; after an action it's a plain sleep. Knowing which one you're calling matters.
WithJavaScript swaps Selenium's normal element interaction for direct JavaScript injection. An escape hatch that's only meaningful for Selenium, since Puppeteer and OttoMagic have no equivalent 'normal' interaction to override in the first place.