Re: Appreciation for pgAdmin 4's progress

[Dave Page]

On Wed, Jul 31, 2019 at 4:04 AM Avin Kavish  wrote:

> First of all since this is an appreciation thread, I want to mention one
> of my favourite features - the map !!! Being able to view GIS data on a
> visual map of earth is the best thing ever. It has saved me from countless
> hours of messing up SRIDs and struggling to get everything right. I can
> always check the map to see if I've made any mistakes with the st_..
> functions. Besides, it's just fun to look at maps :)
>
> I have to plus one better context menus, even as a developer who slams the
> keyboard quite violently, there are times when I power down, lean back and
> use one hand to do copy-pastes. But programmatic access to the users
> clipboard has been limited in web browsers. There's a recent Clipboard API
>  addition
> with basic support which maybe worth a look.
>
> Question:  Why would a*nyone* ever want to 'Remove Panel', 'Detach
>> Panel', or 'Add Panel' (the only options in the current query tool context
>> menu)?
>
>
> Yeah, why are these options everywhere, wouldn't it suffice to have them
> on the tabs and show different *context* menus elsewhere? Maybe instead
> of hijacking the right click on the query editor just let the click pass
> through and be handled with the default context menu shown by browsers.
>

They are put there by the underlying layout library. Patches are welcome to
change that.


>
>
>
>
> On Tue, Jul 30, 2019 at 11:26 PM Michel Feinstein <
> michelfeinst...@gmail.com> wrote:
>
>> I always have one hand at the mouse and one at the keyboard, once I
>> select stuff with the mouse, I hit cntrl+c with the other hand, it's a lot
>> quicker. At least if you don't have any disabilities or are left handed,
>> ctrl+c is at the bottom right corner, where my left hand already rests.
>>
>> On Tue, Jul 30, 2019, 14:49 richard coleman 
>> wrote:
>>
>>> I concur.  Ctrl-C/Ctrl-V is basically muscle memory at this point.
>>> Unfortunately though there are times when it's particularly jarring.
>>> Selecting things are done in pgAdmin4 with the mouse/track ball/etc. so
>>> your hand is already off the keyboard.  So for example; you select an sql
>>> statement to copy/paste/make a small change/run a process I do all the time
>>> in pgAdmin4.  Select->right-click->grumble about *useless 
>>> options*->Ctrl-C->move
>>> to another area with mouse->Ctrl-V.
>>>
>>> It seems especially strange since if you select a cell in the results
>>> pane the copy / paste options are in *that* context menu.
>>>
>>> Question:  Why would a*nyone* ever want to 'Remove Panel', 'Detach
>>> Panel', or 'Add Panel' (the only options in the current query tool context
>>> menu)?
>>>
>>>- You can't move them outside of the tab and only within a of a
>>>smallish portion of the current tab.
>>>- You can't reattach them, so trying to use that option to rearrange
>>>them doesn't work.
>>>- The only way to *fix* it, if you've accidentally selected it is
>>>the *nuclear *option of 'Reset Layout'.
>>>
>>> There are just certain items that people *expect* in a context menu,
>>> especially one that's associated with a text editor.  *None* of them
>>> currently exist in the context menu of the query tool.  It would be
>>> *nice* if that could be addressed, sooner as opposed to later.
>>>
>>> Thanks,
>>>
>>> rik.
>>>
>>>
>>> On Tue, Jul 30, 2019 at 12:26 PM Dave Caughey 
>>> wrote:
>>>
 Correct.  But the absence of support in the context menu is a basic UI
 usability issue. Instead we only have "remove panel", "detach panel", "add
 panel".

 Context menus are an essential usability feature.  A context menu is
 intended to allow the user to quickly access the basic operations that
 apply to whatever is clicked on / selected (i.e., the "context"), and the
 menu items should be biased towards very commonly used actions (e.g., e.g.,
 copy/paste, new, etc.).  The most frequently used should be situated near
 the top of the context menu to minimize the mouse movement required to get
 to the desired operation. Less frequently-used stuff should be buried in
 submenus because the usability hit required to get to these uncommon
 operations is a big deal, compared with making it easier to get to the
 common operations.

 I totally understand that you don't think it's a big issue because
 (clearly) you're happy to use keyboard shortcuts.  But that's that way you
 prefer to work.   But many (most?) people rely on context menus, and it's
 just an unnecessary usability irritant when the stuff that you expect to
 find in a context menu is missing (e.g., #4229) or when the context menu
 hasn't had any thought given to the relative frequency of the operations
 (e.g., right-click on a table in the navigation pane, and you'll see
 less-frequently used operations like "Reset Statistics", "Drop Cascaded",
 "Main

How can I add a custom EPSG to the Map (Geometry) Viewer in PGAdmin4,

[Basques, Bob (CI-StPaul)]

All,

Following the appreciation thread and saw the reference to the geometry viewer, 
I didn’t even know that was in there.  Anyway, nice, but we have a custom EPSG, 
where do I add this into PGAdmin4?

Also, it would be nice to add in our own background mapping layers as well, is 
there a method for adding in WMS/WFS to the layer list?

Thanks

bobb

Managing 'Operators' in pgAdmin4

[Milan Oparnica]

Hello,

I like the fresh and modern approach that pgAdmin4 offers, updating 
instantly when new versions pop-up praying to find few options I still 
miss from pgAdmin3.


Working with 'Operators' objects


Is there any chance you could reconsider the decision not to support 
Operators objects in pgAdmin4 ?
I'm sure we're not the only one to use them - as they proved to be a 
great tool when migrating software from other database platforms.


They provide easiest way of handling certain date and string crucial 
operations that differ from pg implementation.



Best regards,

Milan Oparnica

Search database objects

[Milan Oparnica]

Hello,

I like the fresh and modern approach that pgAdmin4 offers, updating 
instantly when new versions pop-up praying to find few options I still 
miss from pgAdmin3.


Search database objects
===

I'm sure this tool will put a smile on many faces. Although not perfect, 
the 'Search' option in good-old pgAdmin3 is still superior to the 
'browser-based-search' we have now.


It takes a lot of time to:

1. Expand the database tree
2. Expand the desired schema (and you have to know which one exactly)
3. Expand the proper node (tables, views, functions...)
4. Search with the browsers tool - hoping from one partial-result to
   another trying to spot the right one...

When collections hold thousand items it takes too much efort.

Are there any plans to add the 'Search tool' in pgAdmin4 ?


Best regards

Milan Oparnica

Re: pgadmin4 - Use classic style interface, don't launch browser?

[richard coleman]

Avin,

Visual Studio Code (VSC) [a very nice if somewhat heavy weight editor] is
written in part using the Electron Framework {
https://en.wikipedia.org/wiki/Visual_Studio_Code} so it's using Node.js and
the Blink rendering engine as well as C++ and C#.  It's *not* using Atom,
nor can it be considered a browser by any definition.  VSC is a traditional
desktop application complete with it's own UI aimed squarely at the
desktop.  When you close it, you are stopping the application.  If you open
multiple windows, you are running multiple instances.  It's just makes use
of traditional web technologies in its development.

Just thought I would clear that up,

rik.

On Tue, Jul 30, 2019 at 10:37 PM Avin Kavish  wrote:

> On the topic of speed, the current limitation is not imposed by the fact
> that it is run inside the browser, fyi some really popular and successful
> apps are web based, even visual studio code. It's more of an architectural
> and design problem than a platform issue.
>
I'm not very familiar with the code yet, but I suspect the following could
> be factors,
>
>- a lack of caching on both the client and the server,
>- excessive amounts of DOM nodes (currently around 4000 at idle),
>- excessive nesting using tables,
>- lack of a view reconciliation library such as React/Angular
>- usage of AMD modules making dead-code elimination (tree-shaking)
>impossible, if asynchronous loading was the intention, webpack supports
>dynamic imports with ESModules while retaining the benefits of 
> tree-shaking.
>- lack of skeleton uis that are perceived as being faster - most top
>sites do this now making them look faster even if the time to interactive
>is the same
>- waiting on ajax requests before loading UIs, (theory) (the query
>tool takes 2-3s to open, is this why?)
>
> There's more to discover, I'm still reading through.
>
> Modern UI design philosophy is to react immediately to user response by
> showing something as close to the real interface as possible and then to
> load the data asynchronously behind a loading indicator, which is done in
> some situations but often not convincing enough or not immediate enough.
> (again, query tool, anywhere between 2-4s till first paint) Anywhere over
> one second and frustration sets in. 100ms should be the target to keep
> power users happy.
>
> More info:
> Performance:
> https://developers.google.com/web/fundamentals/performance/rail
> DOM Size:
> https://developers.google.com/web/tools/lighthouse/audits/dom-size
>
> The best way to identify areas that require improvement is to run the
> lighthouse
> 
> auditing tool.
>
>
> On Tue, Jul 30, 2019 at 5:46 PM richard coleman <
> rcoleman.ascen...@gmail.com> wrote:
>
>> Dave,
>>
>> That's true.  Of course that's the ultimate draw back of the
>> client/server model.  Having *just* a server isn't enough, you need a
>> *client* as well.  pgAdmin4 is *just* the server portion of that model.
>> It's relying on *borrowing* someone else's client.  That's frees up
>> quite a bit of resources, not having to write an actual client.
>> Unfortunately that means you have to deal with all of the limitations;
>> speed, footprint, compatibility, security, capabilities that that entails.
>> Contrary to the thought in some circles, not *everything* is amenable to
>> being served through a web browser.
>>
>> just one man's opinion.
>>
>> On Tue, Jul 30, 2019 at 4:10 AM Dave Page  wrote:
>>
>>>
>>>
>>> On Mon, Jul 29, 2019 at 7:31 PM Mark Murawski <
>>> markm-li...@intellasoft.net> wrote:
>>>

 Would there be a possibility of embedding chromium?  Since of course
 it's actively developed and everyone including their pet cat are using
 it as a rendering engine these days (including microsoft)  Not sure of
 the compatibility with the BSD license would go...

>>>
>>> It's technically possible of course (one most, but not all of our
>>> supported platforms), but would be a massive amount of work, probably tying
>>> up most of my team for months whilst they figure out how to glue all the
>>> pieces together into Qt on Windows, Mac and Linux. I'd far rather they were
>>> building actual features.
>>>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EnterpriseDB UK: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>

Re: Search database objects

[Avin Kavish]

Can confirm, I smiled.

On Wed, Jul 31, 2019 at 8:33 PM Milan Oparnica  wrote:

> Hello,
>
> I like the fresh and modern approach that pgAdmin4 offers, updating
> instantly when new versions pop-up praying to find few options I still miss
> from pgAdmin3.
>
> Search database objects
> ===
>
> I'm sure this tool will put a smile on many faces. Although not perfect,
> the 'Search' option in good-old pgAdmin3 is still superior to the
> 'browser-based-search' we have now.
>
> It takes a lot of time to:
>
>1. Expand the database tree
>2. Expand the desired schema (and you have to know which one exactly)
>3. Expand the proper node (tables, views, functions...)
>4. Search with the browsers tool - hoping from one partial-result to
>another trying to spot the right one...
>
> When collections hold thousand items it takes too much efort.
>
> Are there any plans to add the 'Search tool' in pgAdmin4 ?
>
>
> Best regards
> Milan Oparnica
>