Re: Usability improvment ideas

Hi,

Le 14/03/2011 23:06, Bernhard Neuhauser a écrit :
> [...]
> I am not sure if this mailing list is suitable for giving feedback on pgadmin,
> so please redirect me to a better place if necessary.
>

No, it's the good list.

> Pgadmin itself seems to be a really nice tool,
> but I think that there is potential to improve its usability with minor development effort.
>
> 1] a "run current query" shortcut
> 2] an "abort query" shortcut
> 3] improved shortcut for comment/uncomment multiple lines
>
> 1] a "run current query" shortcut
>
> Whenever you have more than one query within the query editor,
> it is necessary to select the query in order to execute it.
> It would be better if it's possible to do the same without requiring an initial query selection.
>
> My proposal would be to add ctrl+F5 as shortcut, which runs the query surrounding the current cursor position.
> ctrl+F7 would do the same for an explain plan.
>
> It would not break the current behavior because the old way would still exist.
> This is most probably easy to implement.
>
> Don't think about a fancy algorithm to find the proper query surrounding the cursor.
> Implement it the simplest available way: an empty line above or below is the border to identify the query.
>

It may be a simple way to do it, but it's not the usual one. Everyone
using PostgreSQL and psql knows that what finishes a query is a colon.
So, to do it correctly, we would need to search the previous and the
next colons, and execute the query between them. But searching a colon
is not an easy thing (think colon in string, a string being between
simple quotes or dollar quoting... just a nightmare).

> If a line contains only whitespaces (tab, space,...) its qualified to limit the query scope.
> An comment-only line should not be treated as query border.
> (Complex queries might have full line comments within the query.)
>

This "view" of a query is too limited.

> Rationale:
> It allows a user to constantly spam "run query" or "explain query" without moving his hands from the keyboard.
>
> I must admit, that it's hard to see the value without the ability to get a feeling for it.
> I am not aware of a decent postgresql query tool caring about this issue.
>

Actually, I find the idea of executing a single query without selecting
it interesting. What I don't know yet is how to do it easily.

> Optional:
> The ability to configure the shortcut, because to be honest I like toads ctrl+enter more than the idea of ctrl+F5.
> You might think that this makes no difference,
> but for hitting ctrl+F5 I need to move my arm,
> while the other one is reachable with minimal effort (at least at my german keyboard layout)
> The same applies to ctrl+e vs. ctrl+F7.
>
> 2] an "abort query" shortcut
>
> How about using the escape key to abort the currently running query?
>

Yeah, like it.

> 3] improved shortcut for comment/uncomment multiple lines
>
> This is a controversial topic, because to be honest I'm not sure if my proposal is a good one.
> The only thing I know is that your current mechanic feels awkward.
>
> I think what I mostly dislike is:
> The comment of the first line does not appear at the beginning of the first line.
> It is always added to the start of the selection.
>

I've never tried it, but I understand why you find that weird.

> Currently I use comment/uncomment only within eclipse and toad.
> Toad is like pgadmin, but it adds the first comment at the start of the first line.
>
> But in the end it would be even nicer if it's even smarter as it is within eclipse.
> It allows using both actions with only one shortcut.
>
> If all lines start with -- => uncomment them. (ignore whitespaces in front of --)
> If one line within the selection does not start with -- => add a comment to all of them.
>
> This behavior might sound little bit odd,
> but after using both behaviors regular,
> I would always prefer the smarter eclipse way.
>

Seems interesting. I need to think about it.

> Regards,
> Bernhard
>
> Sorry for not trying to implement it on my own.
> But after 10 years of avoiding c, I doubt that the resulting code would be helpful.
>

--
Guillaume
http://www.postgresql.fr
http://dalibo.com