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 4:53 PM Jack Royal-Gordon <jackrg(at)pobox(dot)com> wrote:

> I’m happy to see that some of these items are already addressed.But I have
> a couple issues with them:
>
> 1) auto-re-sizing columns by clicking on their separator does not work for
> me. I’ve got Safari as my default browser (running on OS X,).
> Double-clicking the header separator to the right of the column does
> nothing. I checked and get the same behavior in Chrome (again on OS X). Just
> to confirm, I assume I’m in the right place if I get the resize ("←|→”)
> cursor.
>

Yes, that is correct. I just tested in Chrome 85.0.4183.102 (Official
Build) (64-bit) and Safari 13.1.2 (15609.3.5.1.3) on macOS 10.15.6
(19G2021), and it works fine in both for me.

Do you get any errors in the javascript console?

>
> 2) Occasioinally I accidentally un-dock one of the query tool windows
> (either the command window or the results window, and sometimes the whole
> query window). I’ve been unable to figure out how to re-dock it when this
> happens.I’ve tried dragging the undocked window all over the screen and
> I’ve tried double-clicking and right-clicking on the menu line of the
> undocked window. Can you explain how to re-dock these windows? I’ve played
> around with this a little more and have found that only very rarely can I
> re-dock a window once it is un-docked.
>

When you want to re-dock, make sure you grab the panel by the label in the
title bar. If you grab the title bar (outside of the label), it'll only let
you move it, but not re-dock. Move the panel around when holding it by the
label, and drop-zones should be highlighted to show where the panel will
dock if dropped.

>
> As a side thought on the issue of re-docking windows, pretty much every
> time I undock a window it is not intentional - could you add a feature to
> lock the undocking mechanism such that either a confirmation would be
> necessary or undocking has to be re-enabled before undocking can be done?
>

Like this one? :-)

[image: Screenshot 2020-09-24 at 17.07.08.png]

None is the default. Prevent Docking will stop you from docking/undocking
tabs and panels, but still allow you to adjust splitter bars (i.e. the size
of the results panel in the query tool with respect to the query
editor/history). Full Lock will lock splitter bars in place too.

>
> On Sep 24, 2020, at 1:35 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
> 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
>
>
>

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

EDB: http://www.enterprisedb.com