Re: How do I tell pgAdmin 4 to not harass me with pointless extra clicks every single time I want to use it?

Hi

On Thu, Sep 24, 2020 at 12:09 AM Mark Murawski <markm-lists(at)intellasoft(dot)net>
wrote:

>
> One of my missing features is navigating directly to a trigger function
> from a trigger.
>
> Tables -> Triggers -> <triggername>
> You can see the SQL for CREATE TRIGGER, but can't navigate directly to
> the function, so this is a showstopper for me.
>

Yes, that is a TODO: https://redmine.postgresql.org/issues/2519

>
> Another missing feature is double click on a column header to expand the
> column to fit the data.
>

That functionality has been there for a long time (you actually
double-click on the right-hand vertical separator in the header).

>
> Another missing feature is the little DDL window in the bottom left
> corner so you can see DDL while also navigating around.
>

That has been there since v1.0. The default location is the main tabset
now, but you can drag the tab to dock it in the bottom corner.

>
> Another crazy behavior is when trying to organize the layout and move
> things like the SQL/DDL window, it's really difficult to put the SQL
> window back into the original location where Statistics/Dependencies/etc
> is. I wind up having to do 'reset layout' a lot. There's just an odd
> lag to the window managment and it also stops working when you run over
> a window border.
>

I'm not entirely sure what you mean. I have no problems dragging tabs
around and re-docking panels, though admittedly I don't typically work on
Linux clients.

>
> Also, if you reset the layout, all of your tabs and connections are
> gone. I might as well have restarted the application entirely... so I
> painstakingly set up my work environment and then with one false move
> adjusting the layout, I have to reset and rebuild from scratch... this
> is a showstopper.
>

Yes, it essentially does restart everything to do the reset. I'm not sure
that's particularly easy to fix - but then, I also wouldn't expect you to
have to reset the layout more than once in a blue moon.

>
> If you close and re-open pgadmin4, none of your work state is saved. Now
> that I've gotten used to omnidb and datagrip, this is now a showstopper.
> I can't even count how many times I've lost work because I've crashed
> chrome or firefox by doing other dev work in other tabs and lost my
> current state of affairs in pgadmin4.
>

The panel layout and (optionally) treeview state should be saved, though
you will have to open the server node again before it'll restore the state
(this is to stop you being bombarded with a ton of login prompts at once if
you previously had a number of servers open.

What it doesn't do is attempt to restore things like query tool instances.
This is because there is no way for us to ensure that the connection state
is restored to what it was; for example, you might have run a SET command
to change the search path (which may have been hidden inside a SELECT from
a function). Now it is true that since that was originally written, we've
improved the connection loss handling code which has to deal with the same
situation, and does so by simply popping up a big warning to the user. We
could take the same approach here if we add such a feature.

>
> It looks like Pgadmin4 must run in a browser these days. It looks like
> the self-contained local-web type of runtime is not available anymore.
> For my workflow, running in a browser just doesn't work at all.
>

Yes, unfortunately there were serious performance issues with the Qt
browser controls used in early versions that we were unable to resolve.
Most users that don't want to use their normal browser session will set a
custom browser command to use a dedicated profile so it doesn't interfere
with the default browser sessions.

How does OmniDB resolve this issue for you, as that also runs in a browser?

>
> If you close the dashboard or the scratch pad there's no way to get it
> back, unless you reset the layout. If you wind up losing the Browser
> window in the layout, there's no way to get it back without resetting
> the layout.
>

Right-click the tab bar and re-open them from the menu there.

>
> Oddity: Sometimes 'esc' doesn't get you out of menus and other popouts.
> Example: open up Tools, click inside a console window, and then hit
> 'esc'... nothing happens
>

There's nothing we can do about that; if the console has focus then it will
capture key events. That's the case for any web apps.

>
> Copy from a table has a bit to be desired... why does a copy of multiple
> columns concatenate all the values together? Why not put a comma in
> between values?
>

It's tab delimited by default, for standard compatibility with Microsoft
Excel and similar apps. You can change that under File -> Preferences ->
Query Tool -> Results Grid.

>
> Not sure if this is possible inside a browser, but ctrl-w doesn't close
> the tab you're working on... it closes the *browser* tab, which
> thankfully gives you a warning.
>

Right - I'm not sure we can capture that particular shortcut key; and even
if we can, I'm not sure it's a good idea to co-opt it.

>
> You cannot edit the label of a tab of a query window
>

That is a TODO: https://redmine.postgresql.org/issues/4230

>
> 'Detach Panel' of a query console pops up a completely blank,
> non-functional window.
>

Can you explain more about that please? I don't understand what you mean.

>
> When dragging a detached window tab around.. it sometimes gets 'stuck'
> and cannot cover the 'Browser' component, depending on the layout.
>

Detached tabs can only be positioned within their parent layout. Major
tools such as the Query Tool and Debugger are largely self-contained, to
allow them to be opened in separate browser tabs if desired (and, well,
because the code would be horrifically inefficient and significantly more
complex otherwise). This means that you cannot move a tab in a Query Tool
or Debugger session outside of the parent tab - which is why you can't put
them over the browser panel. On the other hand, it does prevent the user
from mixing up the same panel from different instances of the tools. This
is the same behaviour as we had in pgAdmin 3, and is not something I would
want to change for various reasons.

>
> It's also sometimes difficult to actually grab the component handle to
> try and move it in the layout.
>

You should always be able to grab the label. Is there a case where that
doesn't work for you?

Ultimately I think there are a number of issue classes here:

- Some are features that are there, but you haven't yet found (e.g. the
result copy/paste format).
- Some are features that may or may not have been in pgAdmin 3 (actually, I
think the only one that was there, was having the function node under the
trigger node)
- Some are simply limitations of webapps in general.

Please feel free to log issues for any of the above that are either new
features that don't already have tickets, or are reproducible bugs, if my
comments don't help you resolve the difficulties you're running into - and
of course, feel free to reply here with further questions etc. if you like.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: http://www.enterprisedb.com