Обсуждение: Patch: New field in frmMain statusbar

The part that changed is just the one that added db1 and db2, right?

If so I definitely don't think it's a problem with too much info,and think this patch is good. (I haven't reviewed the code)

//Magnus

On Mon, Sep 14, 2015 at 3:34 PM, Adam Scott <adam.c.scott@gmail.com> wrote:

Hi,

thank you for your time to consider this patch.

Here's a few screenshots on my Windows 7 desktop.  Let me know if you want to see anything else. 

A few observations:

On Mon, Sep 14, 2015 at 4:43 AM, Magnus Hagander <magnus@hagander.net> wrote:

I don't have a working pgadmin env at the moment - any chance someone who has built it could show a screenshot?

I've certainly had customers complain about pgadmin in the case of many databases, though it's generally been on account of performance, and not something like this.

//Magnus

On Mon, Sep 14, 2015 at 10:57 AM, Dave Page <dpage@pgadmin.org> wrote:

Thanks Adam.

What do others feel about this proposed patch? I can see how it might
be useful, however I'm also concerned about overloading the UI with
more info - and in over a decade I don't recall anyone ever asking for
this feature or complaining of the issue Adam describes (though, it is
clearly feasible).

On Sun, Sep 13, 2015 at 4:19 PM, Adam Scott <adam.c.scott@gmail.com> wrote:
> Hi,
>
> please consider this patch to frmMain.
>
> Situation:  When a user has a large number of databases and connections,
> when they select a table or other object in the Object browser tree, they
> can lose track of which connection and database the object belongs too.
> This makes it really easy for the user to make a mistake and drop an object
> on the wrong connection (such as on a Production server instead of a
> Development server).  Also as a user is browsing multiple databases and
> connections they can lose track of which object they are working on.
>
> Solution: This patch adds a new field in the status bar of the main window
> (frmMain), between the two other fields, keeping them the same.  If there's
> a currently selected object the field will display it's connection and
> database.  If there's no currently selected object, it will be blank.
>
> Here's the danger, if we display the wrong connection and database, the user
> could drop the wrong object.  So it's imperative this never has a bug.  This
> code change is so small with so little dependencies, it relies on already
> used code for such a long time that if it had a bug, then there are other
> bigger bugs in the code that would have already shown up.
>
> Regards,
> Adam C. Scott
>
> patch generated using Tortoise Git Create Patch Serial
>
>
>

> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>

--

 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

The part that changed was just the database name since I clicked on an object in a different database on the same conneciton.  If I had selected an object in a different connection, the connection name would change as well.

For convenience, in green below, is the additional code to make this happen (there's other stuff in the patch to add the field in the statusbar not shown below).

Thank you,
Adam

void frmMain::EndMsg(bool done)
{
    msgLevel--;

    if (!msgLevel)
    {
        // Get the execution time & display it
        float timeval = stopwatch.Time();
        wxString time;
        time.Printf(_("%.2f secs"), (timeval / 1000));
        statusBar->SetStatusText(time, 3);

        wxString connection;
        if (currentObject)
        {
            pgDatabase *db = currentObject->GetDatabase();
      
            if (db)
                connection = db->GetServer()->GetDisplayName() + wxT(":") + db->GetDisplayName();
        }

        statusBar->SetStatusText(connection,2);

        // Display the 'Done' message
        if (done)
            statusBar->SetStatusText(timermsg + _(" Done."), 1);
        else
            statusBar->SetStatusText(timermsg + _(" Failed."), 1);

On Mon, Sep 14, 2015 at 10:11 AM, Magnus Hagander <magnus@hagander.net> wrote:

The part that changed is just the one that added db1 and db2, right?

If so I definitely don't think it's a problem with too much info,and think this patch is good. (I haven't reviewed the code)

//Magnus

On Mon, Sep 14, 2015 at 3:34 PM, Adam Scott <adam.c.scott@gmail.com> wrote:

Hi,

thank you for your time to consider this patch.

Here's a few screenshots on my Windows 7 desktop.  Let me know if you want to see anything else. 

A few observations:

On Mon, Sep 14, 2015 at 4:43 AM, Magnus Hagander <magnus@hagander.net> wrote:

I don't have a working pgadmin env at the moment - any chance someone who has built it could show a screenshot?

I've certainly had customers complain about pgadmin in the case of many databases, though it's generally been on account of performance, and not something like this.

//Magnus

On Mon, Sep 14, 2015 at 10:57 AM, Dave Page <dpage@pgadmin.org> wrote:

Thanks Adam.

What do others feel about this proposed patch? I can see how it might
be useful, however I'm also concerned about overloading the UI with
more info - and in over a decade I don't recall anyone ever asking for
this feature or complaining of the issue Adam describes (though, it is
clearly feasible).

On Sun, Sep 13, 2015 at 4:19 PM, Adam Scott <adam.c.scott@gmail.com> wrote:
> Hi,
>
> please consider this patch to frmMain.
>
> Situation:  When a user has a large number of databases and connections,
> when they select a table or other object in the Object browser tree, they
> can lose track of which connection and database the object belongs too.
> This makes it really easy for the user to make a mistake and drop an object
> on the wrong connection (such as on a Production server instead of a
> Development server).  Also as a user is browsing multiple databases and
> connections they can lose track of which object they are working on.
>
> Solution: This patch adds a new field in the status bar of the main window
> (frmMain), between the two other fields, keeping them the same.  If there's
> a currently selected object the field will display it's connection and
> database.  If there's no currently selected object, it will be blank.
>
> Here's the danger, if we display the wrong connection and database, the user
> could drop the wrong object.  So it's imperative this never has a bug.  This
> code change is so small with so little dependencies, it relies on already
> used code for such a long time that if it had a bug, then there are other
> bigger bugs in the code that would have already shown up.
>
> Regards,
> Adam C. Scott
>
> patch generated using Tortoise Git Create Patch Serial
>
>
>

> --
> Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-hackers
>

--

 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On Tue, Sep 15, 2015 at 12:14 PM, Magnus Hagander <magnus@hagander.net> wrote:
> On Tue, Sep 15, 2015 at 10:55 AM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> On Mon, Sep 14, 2015 at 5:11 PM, Magnus Hagander <magnus@hagander.net>
>> wrote:
>> > The part that changed is just the one that added db1 and db2, right?
>>
>> It's the server display name *and* the database name, so to give a
>> (redacted) example from my machine, I would have:
>>
>> aws-ap-southeast-1b.xxxxxxxxxxxxxxxx.com (aws-ap-southeast-1b.
>> xxxxxxxxxxxxxxxx.com:5432):postgres
>>
>> Which as you can see is quite long.
>
>
> I thought the point of display names was to have them nice and short :) I've
> certainly never used displaynames that are that long.

I generally use the full hostnames (as I have machines in multiple
domains) - and in the places that you currently see them, that length
is actually fine.

> Yes, I totally see with names like that it becomes annoying, and certainly
> not easy to parse. Perhaps what we really shoul dhave is just displayname +
> databasename, and exclude the actual hostname?

That would be an improvement, certainly.

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

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

If you have a development host and a production host, the database names will be the same.  I think the value of the having the new field goes away if you exclude the hostname.  You won't know what host the object you are selecting belongs to.  That could be the difference between modifying an object in development and production. 

It seems to me that what you could say about the display name is what could be said about the connection's display name in the tree control since this is what is displayed (plus the database name).

What the patch displays answers the questions, "What connection am I on?"  "What database am I on?"

I guess I can work on adding another patch that allows you to customize what is displayed using frmOptions...?

On Tue, Sep 15, 2015 at 5:20 AM, Dave Page <dpage@pgadmin.org> wrote:

On Tue, Sep 15, 2015 at 12:14 PM, Magnus Hagander <magnus@hagander.net> wrote:
> On Tue, Sep 15, 2015 at 10:55 AM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> On Mon, Sep 14, 2015 at 5:11 PM, Magnus Hagander <magnus@hagander.net>
>> wrote:
>> > The part that changed is just the one that added db1 and db2, right?
>>
>> It's the server display name *and* the database name, so to give a
>> (redacted) example from my machine, I would have:
>>
>> aws-ap-southeast-1b.xxxxxxxxxxxxxxxx.com (aws-ap-southeast-1b.
>> xxxxxxxxxxxxxxxx.com:5432):postgres
>>
>> Which as you can see is quite long.
>
>
> I thought the point of display names was to have them nice and short :) I've
> certainly never used displaynames that are that long.

I generally use the full hostnames (as I have machines in multiple
domains) - and in the places that you currently see them, that length
is actually fine.

> Yes, I totally see with names like that it becomes annoying, and certainly
> not easy to parse. Perhaps what we really shoul dhave is just displayname +
> databasename, and exclude the actual hostname?

That would be an improvement, certainly.

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

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

I think so - I realise it's not the display name (which would be
ideal), but it is a condensed name that fully describes the
connection.

On Tue, Sep 15, 2015 at 4:01 PM, Adam Scott <adam.c.scott@gmail.com> wrote:
> If it displayed what's displayed in the Query editor would that be better?
>
> Thank you,
> Adam
>
>
> On Tue, Sep 15, 2015 at 8:41 AM, Adam Scott <adam.c.scott@gmail.com> wrote:
>>
>> If you have a development host and a production host, the database names
>> will be the same.  I think the value of the having the new field goes away
>> if you exclude the hostname.  You won't know what host the object you are
>> selecting belongs to.  That could be the difference between modifying an
>> object in development and production.
>>
>> It seems to me that what you could say about the display name is what
>> could be said about the connection's display name in the tree control since
>> this is what is displayed (plus the database name).
>>
>> What the patch displays answers the questions, "What connection am I on?"
>> "What database am I on?"
>>
>> I guess I can work on adding another patch that allows you to customize
>> what is displayed using frmOptions...?
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Sep 15, 2015 at 5:20 AM, Dave Page <dpage@pgadmin.org> wrote:
>>>
>>> On Tue, Sep 15, 2015 at 12:14 PM, Magnus Hagander <magnus@hagander.net>
>>> wrote:
>>> > On Tue, Sep 15, 2015 at 10:55 AM, Dave Page <dpage@pgadmin.org> wrote:
>>> >>
>>> >> On Mon, Sep 14, 2015 at 5:11 PM, Magnus Hagander <magnus@hagander.net>
>>> >> wrote:
>>> >> > The part that changed is just the one that added db1 and db2, right?
>>> >>
>>> >> It's the server display name *and* the database name, so to give a
>>> >> (redacted) example from my machine, I would have:
>>> >>
>>> >> aws-ap-southeast-1b.xxxxxxxxxxxxxxxx.com (aws-ap-southeast-1b.
>>> >> xxxxxxxxxxxxxxxx.com:5432):postgres
>>> >>
>>> >> Which as you can see is quite long.
>>> >
>>> >
>>> > I thought the point of display names was to have them nice and short :)
>>> > I've
>>> > certainly never used displaynames that are that long.
>>>
>>> I generally use the full hostnames (as I have machines in multiple
>>> domains) - and in the places that you currently see them, that length
>>> is actually fine.
>>>
>>> > Yes, I totally see with names like that it becomes annoying, and
>>> > certainly
>>> > not easy to parse. Perhaps what we really shoul dhave is just
>>> > displayname +
>>> > databasename, and exclude the actual hostname?
>>>
>>> That would be an improvement, certainly.
>>>
>>>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EnterpriseDB UK: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>
>>
>



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

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Being consistent with the frmQuery probably helps the user as well.  Here's the patch to display the connection name as it is displayed in the frmQuery.

Thank you,

Adam

On Wed, Sep 16, 2015 at 9:30 AM, Dave Page <dpage@pgadmin.org> wrote:

I think so - I realise it's not the display name (which would be
ideal), but it is a condensed name that fully describes the
connection.

On Tue, Sep 15, 2015 at 4:01 PM, Adam Scott <adam.c.scott@gmail.com> wrote:
> If it displayed what's displayed in the Query editor would that be better?
>
> Thank you,
> Adam
>
>
> On Tue, Sep 15, 2015 at 8:41 AM, Adam Scott <adam.c.scott@gmail.com> wrote:
>>
>> If you have a development host and a production host, the database names
>> will be the same.  I think the value of the having the new field goes away
>> if you exclude the hostname.  You won't know what host the object you are
>> selecting belongs to.  That could be the difference between modifying an
>> object in development and production.
>>
>> It seems to me that what you could say about the display name is what
>> could be said about the connection's display name in the tree control since
>> this is what is displayed (plus the database name).
>>
>> What the patch displays answers the questions, "What connection am I on?"
>> "What database am I on?"
>>
>> I guess I can work on adding another patch that allows you to customize
>> what is displayed using frmOptions...?
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Sep 15, 2015 at 5:20 AM, Dave Page <dpage@pgadmin.org> wrote:
>>>
>>> On Tue, Sep 15, 2015 at 12:14 PM, Magnus Hagander <magnus@hagander.net>
>>> wrote:
>>> > On Tue, Sep 15, 2015 at 10:55 AM, Dave Page <dpage@pgadmin.org> wrote:
>>> >>
>>> >> On Mon, Sep 14, 2015 at 5:11 PM, Magnus Hagander <magnus@hagander.net>
>>> >> wrote:
>>> >> > The part that changed is just the one that added db1 and db2, right?
>>> >>
>>> >> It's the server display name *and* the database name, so to give a
>>> >> (redacted) example from my machine, I would have:
>>> >>
>>> >> aws-ap-southeast-1b.xxxxxxxxxxxxxxxx.com (aws-ap-southeast-1b.
>>> >> xxxxxxxxxxxxxxxx.com:5432):postgres
>>> >>
>>> >> Which as you can see is quite long.
>>> >
>>> >
>>> > I thought the point of display names was to have them nice and short :)
>>> > I've
>>> > certainly never used displaynames that are that long.
>>>
>>> I generally use the full hostnames (as I have machines in multiple
>>> domains) - and in the places that you currently see them, that length
>>> is actually fine.
>>>
>>> > Yes, I totally see with names like that it becomes annoying, and
>>> > certainly
>>> > not easy to parse. Perhaps what we really shoul dhave is just
>>> > displayname +
>>> > databasename, and exclude the actual hostname?
>>>
>>> That would be an improvement, certainly.
>>>
>>>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EnterpriseDB UK: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>
>>
>



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

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Wed, Sep 23, 2015 at 2:55 PM, Adam Scott <adam.c.scott@gmail.com> wrote:
> Is the last patch okay?  If there's something more required or anything
> please let me know.

Hi

The patch does not apply for me. Can you rebase it against master please?

Thanks.

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

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Thank you Dave!  I rebased from master.     To get it to build is going to take some research. It looks like it wants openssl, which I grabbed and configured for WIN32, but it's not happy.  First error is below.  But this patch is so straightforward, I'm sharing anyway for the sake of time, as it was working before.

2>c:\pgadmin3\pgadmin\libssh2\openssl.c(71): error C2037: left of 'e' specifies undefined struct/union 'rsa_st'

Thanks again!

Adam

On Wed, Sep 23, 2015 at 8:35 AM, Dave Page <dpage@pgadmin.org> wrote:

On Wed, Sep 23, 2015 at 2:55 PM, Adam Scott <adam.c.scott@gmail.com> wrote:
> Is the last patch okay?  If there's something more required or anything
> please let me know.

Hi

The patch does not apply for me. Can you rebase it against master please?

Thanks.

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

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

I created batch script to set the environment variable for setting OPENSSL, WXWIN (wxWidgets).

And, use that batch script in command prompt, and start the devenv (Visual Studio Development Environment IDE) from there.

Between - you will also require libxml2, libxslt, iconv (binaries of them kept in a same directory), and environment variable PGBUILD is set for it.

i.e.

c:\pgBuild\iconv\

c:\pgBuild\libxml2

c:\pgBuild\libxslt

And, PGBUILD environment variable is set to "c:\pgBuild".

Hope this helps.

--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company

http://www.linkedin.com/in/asheshvashi

On Thu, Sep 24, 2015 at 12:45 AM, Adam Scott <adam.c.scott@gmail.com> wrote:

Thank you Dave!  I rebased from master.     To get it to build is going to take some research. It looks like it wants openssl, which I grabbed and configured for WIN32, but it's not happy.  First error is below.  But this patch is so straightforward, I'm sharing anyway for the sake of time, as it was working before.

2>c:\pgadmin3\pgadmin\libssh2\openssl.c(71): error C2037: left of 'e' specifies undefined struct/union 'rsa_st'

Thanks again!

Adam

On Wed, Sep 23, 2015 at 8:35 AM, Dave Page <dpage@pgadmin.org> wrote:

On Wed, Sep 23, 2015 at 2:55 PM, Adam Scott <adam.c.scott@gmail.com> wrote:
> Is the last patch okay?  If there's something more required or anything
> please let me know.

Hi

The patch does not apply for me. Can you rebase it against master please?

Thanks.

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

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers