Thread: Roadmap for pgAdmin3 on OSX

Hi

Since pgAdmin3 should now compile & run on OSX when using wxMac HEAD
and pgAdmin3 HEAD, it guess it's time to think about further improvements.

1) postgres start/stop support
2) open ".sql" with pgadmin?
3) ssl support
4) Standard location for postgresql.conf and pg_hba.conf?
5) Nightly Builds

ad 1), 4): Depends on weather there exists a "official" binary
version of postgres for OSX.

ad 2): Can you click on a saved sql query in windows, and
it is opened in pgadmin3? If so, I could try to do the same
for OSX

ad 3): This is a bug in configure - but I still don't know how to
fix/workaround this.

ad 5): A friend of mine has an old G4 lying around somewhere - we'll
try to get it to do nighty builds of pgadmin. Of course, if anyone can
offer a ssh account on some permanently networkes G5, I'd be happe to
use that for nightly builds ;-)))

Any other ideas? Comments? Suggentions? ;-))

greetings, Florian Pflug

hi,

> Since pgAdmin3 should now compile & run on OSX when using wxMac HEAD

i'm *still* having issues w/ the 'new' 2.6-branch HEAD (cref: my other posts).

i'm trying the wxMac 2.5.5 release at the moment ...

> and pgAdmin3 HEAD, it guess it's time to think about further improvements.
>
> 1) postgres start/stop support
> 2) open ".sql" with pgadmin?
> 3) ssl support
> 4) Standard location for postgresql.conf and pg_hba.conf?
> 5) Nightly Builds
>
> ad 1), 4): Depends on weather there exists a "official" binary
> version of postgres for OSX.

i'm unclear as to why this depends on an "official" bin?  could this not simply
point to a given 'custom' bin path, or presume that our $PATH has been set
correctly?

> ad 2): Can you click on a saved sql query in windows, and
> it is opened in pgadmin3? If so, I could try to do the same
> for OSX

are you thinking of simply using a LaunchServices assignment (i.e., using the
GetInfo dialog's "Open with ..." facility?)

> ad 3): This is a bug in configure - but I still don't know how to
> fix/workaround this.

do you have a thread reference for the particular problem, or a breif
description?

I've had no apparent issue linking/building against my external SSL build;
however, i haven't gotten as far as testing function ...

cheers,

richard

> -----Original Message-----
> From: pgadmin-hackers-owner@postgresql.org
> [mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of
> Florian G. Pflug
> Sent: 12 April 2005 12:04
> To: pgadmin-hackers
> Subject: [pgadmin-hackers] Roadmap for pgAdmin3 on OSX
>
> Hi
>
> Since pgAdmin3 should now compile & run on OSX when using wxMac HEAD
> and pgAdmin3 HEAD, it guess it's time to think about further
> improvements.
>
> 1) postgres start/stop support
> 2) open ".sql" with pgadmin?
> 3) ssl support
> 4) Standard location for postgresql.conf and pg_hba.conf?
> 5) Nightly Builds
>
> ad 1), 4): Depends on weather there exists a "official" binary
> version of postgres for OSX.

There is no official binary for OSX that I'm aware of - certainly not on
the PostgreSQL ftp site anyway. However, I assume OSX uses a BSD-like
init system, in which case looking for /etc/rc.d/rc.postgresql or
whatever is appropriate would work for the majority of sensibly
configured systems. WRT 4), again, we could just assume that
installations will be in /usr/local/pgsql/data or /var/pgsql/data or
whatever, as appropriate. Last time I tried that code it let me pick
other locations anyway so there shouldn't be any major problems.

> ad 2): Can you click on a saved sql query in windows, and
> it is opened in pgadmin3? If so, I could try to do the same
> for OSX

No you can't. Make it the first new feature on OSX and I'll pledge to
port it to Windows :-)

> ad 3): This is a bug in configure - but I still don't know how to
> fix/workaround this.

Our configure, or PostgreSQLs? Whats the problem exactly?

> ad 5): A friend of mine has an old G4 lying around somewhere - we'll
> try to get it to do nighty builds of pgadmin. Of course, if anyone can
> offer a ssh account on some permanently networkes G5, I'd be happe to
> use that for nightly builds ;-)))

I can't offer a G5, but I can offer an account on developer.pgadmin.org
to upload the results to. Let me know when you're good to go.

Thanks again for your efforts :-)

Regards,Dave.

Dave Page wrote:
>>Florian G. Pflug
>>1) postgres start/stop support
>>2) open ".sql" with pgadmin?
>>3) ssl support
>>4) Standard location for postgresql.conf and pg_hba.conf?
>>5) Nightly Builds
>>
>>ad 1), 4): Depends on weather there exists a "official" binary
>>version of postgres for OSX.
>
> There is no official binary for OSX that I'm aware of - certainly not on
> the PostgreSQL ftp site anyway. However, I assume OSX uses a BSD-like
> init system, in which case looking for /etc/rc.d/rc.postgresql or
> whatever is appropriate would work for the majority of sensibly
> configured systems. WRT 4), again, we could just assume that
> installations will be in /usr/local/pgsql/data or /var/pgsql/data or
> whatever, as appropriate. Last time I tried that code it let me pick
> other locations anyway so there shouldn't be any major problems.

Hm.. no, OSX doesn't use sysv-style (or bsd-style) init-scripts.
I has a quite similar system (also based on shell-scripts), but
each shell-script is acompanied by a plist file, describing
e.g. the dependencies. I believe that there is a api for starting
and stopping services, but I'll have to check.
Maybe we could add a preference specifying the servicename of
postgres (since it might be PostgreSQL, or postgres, or postgresql, ...)

You are of course right for the conf-file locations - those can be
choosen in pgadmin anyway, so we could just default it to some common
location.

>>ad 2): Can you click on a saved sql query in windows, and
>>it is opened in pgadmin3? If so, I could try to do the same
>>for OSX
>
> No you can't. Make it the first new feature on OSX and I'll pledge to
> port it to Windows :-)
The only problem I see with this, is that we would need to remember to
which "Server" the sql belonged...

On a related note - I often missed the ability to switch a given sql-window
to another connection (e.g. when I have to execute the same sql-script
on multiple machines). Would it be possible to add a dropdrown menu to the
sql-window which selects the connection to use? If I'd come up with a patch,
would it be accepted?

>>ad 3): This is a bug in configure - but I still don't know how to
>>fix/workaround this.
>
> Our configure, or PostgreSQLs? Whats the problem exactly?
It the ssl-detection in the pgadmin-configure. The ssl detection
works by linking with libpq, and checking if this makes the
symbol SSL_connect available. On unix this works, because
liking with libpq also links with libssl, which in turn provides
SSL_connect. On OSX, an app may not access such a "level-2" dynamic
symbol - the app needs to link to libssl directly. But then,
the symbol is available, regardless of weather libpq was linked against
openssl or not.

The only idea I have it to use "otool -l" (the equivalent to ldd on linux)
and grep to check wether libpq links to libssl or not... but this seems
to be quite... hm... hacky ;-)

greetings, Florian Pflug

OpenMacNews wrote:
> i'm *still* having issues w/ the 'new' 2.6-branch HEAD (cref: my other
> posts).
Are you sure you recompiled _all_ pgadmin files - if you just run configure
and specify a different wx-config, the build system doesn't realize it
has to rebuild everything. I had some unresolved symbols when switching
from wx 2.5.4 to 2.5.5, and they went away after doing "make clean; make"

> i'm trying the wxMac 2.5.5 release at the moment ...
Be sure to include fix by "Stefan Csomor":
---------------
as I don't have a buildable situation for pgadmin on my system, could
you please try out whether adding

DoSetWindowVariant( m_windowVariant) ;

in toplevel.cpp line 1204 , just in front of the m_macFocus = NULL ;
-----------------

>> 1) postgres start/stop support
>> 2) open ".sql" with pgadmin?
>> 3) ssl support
>> 4) Standard location for postgresql.conf and pg_hba.conf?
>> 5) Nightly Builds
>>
>> ad 1), 4): Depends on weather there exists a "official" binary
>> version of postgres for OSX.
 > i'm unclear as to why this depends on an "official" bin?  could this not
 > simply point to a given 'custom' bin path, or presume that our $PATH has
 > been set correctly?

Well, pgadmin needs to know how to start and stop postgres -
on osx - so we at least need to know the "servicename".
Of course this can be made configureable - but if there
was a "official way" for these things on osx, we could
save some config options.

>> ad 2): Can you click on a saved sql query in windows, and
>> it is opened in pgadmin3? If so, I could try to do the same
>> for OSX
>
> are you thinking of simply using a LaunchServices assignment (i.e.,
> using the GetInfo dialog's "Open with ..." facility?)
Kind of... see my other post in this thread - we'd need a way to remeber
the connection this sql was used in, or a way for the use to specify that.

>> ad 3): This is a bug in configure - but I still don't know how to
>> fix/workaround this.
> do you have a thread reference for the particular problem, or a breif
> description?
See my other mail in this thread.

> I've had no apparent issue linking/building against my external SSL
> build; however, i haven't gotten as far as testing function ...
Have you checked wether you actually got ssl support - I can link
against a ssl-enabled libpq just fine - but the pgadmin configure
doesn't detect the ssl-support, and disabled ssl-support for pgadmin.

greetings, Florian Pflug

> -----Original Message-----
> From: Florian G. Pflug [mailto:fgp@phlo.org]
> Sent: 13 April 2005 11:56
> To: Dave Page
> Cc: pgadmin-hackers
> Subject: Re: [pgadmin-hackers] Roadmap for pgAdmin3 on OSX
>
> Hm.. no, OSX doesn't use sysv-style (or bsd-style) init-scripts.
> I has a quite similar system (also based on shell-scripts), but
> each shell-script is acompanied by a plist file, describing
> e.g. the dependencies. I believe that there is a api for starting
> and stopping services, but I'll have to check.
> Maybe we could add a preference specifying the servicename of
> postgres (since it might be PostgreSQL, or postgres, or
> postgresql, ...)

:-)

> You are of course right for the conf-file locations - those can be
> choosen in pgadmin anyway, so we could just default it to some common
> location.
>
> >>ad 2): Can you click on a saved sql query in windows, and
> >>it is opened in pgadmin3? If so, I could try to do the same
> >>for OSX
> >
> > No you can't. Make it the first new feature on OSX and I'll
> pledge to
> > port it to Windows :-)
> The only problem I see with this, is that we would need to remember to
> which "Server" the sql belonged...

Hmm, yes - not only that, but the database as well. That is a problem.

> On a related note - I often missed the ability to switch a
> given sql-window
> to another connection (e.g. when I have to execute the same sql-script
> on multiple machines). Would it be possible to add a
> dropdrown menu to the
> sql-window which selects the connection to use? If I'd come
> up with a patch,
> would it be accepted?

I don't see why not if it's of acceptable quality. I think that's a
feature I'd use as well.

> >>ad 3): This is a bug in configure - but I still don't know how to
> >>fix/workaround this.
> >
> > Our configure, or PostgreSQLs? Whats the problem exactly?
> It the ssl-detection in the pgadmin-configure. The ssl detection
> works by linking with libpq, and checking if this makes the
> symbol SSL_connect available. On unix this works, because
> liking with libpq also links with libssl, which in turn provides
> SSL_connect. On OSX, an app may not access such a "level-2" dynamic
> symbol - the app needs to link to libssl directly. But then,
> the symbol is available, regardless of weather libpq was
> linked against
> openssl or not.
>
> The only idea I have it to use "otool -l" (the equivalent to
> ldd on linux)
> and grep to check wether libpq links to libssl or not... but
> this seems
> to be quite... hm... hacky ;-)

I see. As neither an OSX user or an autoconf guru I'm probably not the
best person to ask about that. Adam on the other hand, is both. Any
ideas Adam? :-)

Regards, Dave

Florian G. Pflug wrote:
> Dave Page wrote:
>
>>> Florian G. Pflug
>>> 1) postgres start/stop support
>>> 2) open ".sql" with pgadmin?
>>> 3) ssl support
>>> 4) Standard location for postgresql.conf and pg_hba.conf?
>>> 5) Nightly Builds
>>>
>>> ad 1), 4): Depends on weather there exists a "official" binary
>>> version of postgres for OSX.
>>
>>
>> There is no official binary for OSX that I'm aware of - certainly not on
>> the PostgreSQL ftp site anyway. However, I assume OSX uses a BSD-like
>> init system, in which case looking for /etc/rc.d/rc.postgresql or
>> whatever is appropriate would work for the majority of sensibly
>> configured systems. WRT 4), again, we could just assume that
>> installations will be in /usr/local/pgsql/data or /var/pgsql/data or
>> whatever, as appropriate. Last time I tried that code it let me pick
>> other locations anyway so there shouldn't be any major problems.
>
>
> Hm.. no, OSX doesn't use sysv-style (or bsd-style) init-scripts.
> I has a quite similar system (also based on shell-scripts), but
> each shell-script is acompanied by a plist file, describing
> e.g. the dependencies. I believe that there is a api for starting
> and stopping services, but I'll have to check.
> Maybe we could add a preference specifying the servicename of
> postgres (since it might be PostgreSQL, or postgres, or postgresql, ...)

A default won't really work, because we can't know if that server
registration really belongs to the init/start script (as opposed to
win32, where we *create* the localhost server registration from that).

> You are of course right for the conf-file locations - those can be
> choosen in pgadmin anyway, so we could just default it to some common
> location.
>
>>> ad 2): Can you click on a saved sql query in windows, and
>>> it is opened in pgadmin3? If so, I could try to do the same
>>> for OSX
>>
>>
>> No you can't. Make it the first new feature on OSX and I'll pledge to
>> port it to Windows :-)
>
> The only problem I see with this, is that we would need to remember to
> which "Server" the sql belonged...

:-) That ain't workin...
You'd need to pop up a "select server to connect to" box immediately.

>
> On a related note - I often missed the ability to switch a given sql-window
> to another connection (e.g. when I have to execute the same sql-script
> on multiple machines). Would it be possible to add a dropdrown menu to the
> sql-window which selects the connection to use? If I'd come up with a
> patch,
> would it be accepted?

After review and if reasonably full-featured. This is proabably A Good
Idea (tm), I'd like that too.

- A combobox in the toolbar with currently available connections would
be nice (menu to create conn)
- The SQL window would need to maintain its own private connection list
(it currently has a single private conn).
- conns should stay open, to retain settings / state.
- use existing open connection information, else ask for pwd if
necessary (hint: look at "join slony cluster" in slCluster for how to
select server/DB)

Regards,
Andreas

Andreas Pflug wrote:
> Florian G. Pflug wrote:
>> Dave Page wrote:
>>>> Florian G. Pflug
>>>> 1) postgres start/stop support
>>>> 2) open ".sql" with pgadmin?
>>>> 3) ssl support
>>>> 4) Standard location for postgresql.conf and pg_hba.conf?
>>>> 5) Nightly Builds
>>>>
>>>> ad 1), 4): Depends on weather there exists a "official" binary
>>>> version of postgres for OSX.
>>>
>>> There is no official binary for OSX that I'm aware of - certainly not on
>>> the PostgreSQL ftp site anyway. However, I assume OSX uses a BSD-like
>>> init system, in which case looking for /etc/rc.d/rc.postgresql or
>>> whatever is appropriate would work for the majority of sensibly
>>> configured systems. WRT 4), again, we could just assume that
>>> installations will be in /usr/local/pgsql/data or /var/pgsql/data or
>>> whatever, as appropriate. Last time I tried that code it let me pick
>>> other locations anyway so there shouldn't be any major problems.
>>
>> Hm.. no, OSX doesn't use sysv-style (or bsd-style) init-scripts.
>> I has a quite similar system (also based on shell-scripts), but
>> each shell-script is acompanied by a plist file, describing
>> e.g. the dependencies. I believe that there is a api for starting
>> and stopping services, but I'll have to check.
>> Maybe we could add a preference specifying the servicename of
>> postgres (since it might be PostgreSQL, or postgres, or postgresql, ...)
>
> A default won't really work, because we can't know if that server
> registration really belongs to the init/start script (as opposed to
> win32, where we *create* the localhost server registration from that).

So pgadmin3 on windows checks if there is a service called "postgresql" (or
whatever), and then create a server definition for that postgres instance if
it find an appropriate service?
How does pgadmin3 know the configuration for the service? (I guess it at least
needs to know the port number)
Maybe something similar is possible on osx...

>> On a related note - I often missed the ability to switch a given
>> sql-window
>> to another connection (e.g. when I have to execute the same sql-script
>> on multiple machines). Would it be possible to add a dropdrown menu to
>> the
>> sql-window which selects the connection to use? If I'd come up with a
>> patch,
>> would it be accepted?
>
> After review and if reasonably full-featured. This is proabably A Good
> Idea (tm), I'd like that too.
>
> - A combobox in the toolbar with currently available connections would
> be nice (menu to create conn)
What do you mean with "menu to create conn"? I'd put a combobox with
all available servers in there, and a second one with all databases on
that server..

> - The SQL window would need to maintain its own private connection list
> (it currently has a single private conn).
> - conns should stay open, to retain settings / state.
> - use existing open connection information, else ask for pwd if
> necessary (hint: look at "join slony cluster" in slCluster for how to
> select server/DB)
Ok.. I'll go browsing the code before pestering you with further questions ;-)))))

greetings, Florian Pflug

Florian G. Pflug wrote:
> So pgadmin3 on windows checks if there is a service called "postgresql" (or
> whatever), and then create a server definition for that postgres
> instance if it find an appropriate service?

Yup.

> How does pgadmin3 know the configuration for the service? (I guess it at
> least needs to know the port number)

We just guess it to be 5432... You'd have to change it later if it's not
correct.

>> - A combobox in the toolbar with currently available connections would
>> be nice (menu to create conn)
>
> What do you mean with "menu to create conn"? I'd put a combobox with
> all available servers in there, and a second one with all databases on
> that server..

Noooo...
m servers by n databases....
You'd probably using only some combinations, so I'd like a dedicated
connect to a selected server/db, which then appears in the "connected"
combobox so you can select only connected server/db combinations.

So what I mean is a "Connect..." menu under File, which is dynamically
filled with submenus for each server and each connectable+nonconnected db.

> Ok.. I'll go browsing the code before pestering you with further
> questions ;-)))))

:-)

Regards,
Andreas

> -----Original Message-----
> From: pgadmin-hackers-owner@postgresql.org
> [mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of
> Andreas Pflug
> Sent: 13 April 2005 13:56
> To: Florian G. Pflug
> Cc: pgadmin-hackers
> Subject: Re: [pgadmin-hackers] Roadmap for pgAdmin3 on OSX
>
> Florian G. Pflug wrote:
> > So pgadmin3 on windows checks if there is a service called
> "postgresql" (or
> > whatever), and then create a server definition for that postgres
> > instance if it find an appropriate service?
>
> Yup.
>
> > How does pgadmin3 know the configuration for the service?
> (I guess it at
> > least needs to know the port number)
>
> We just guess it to be 5432... You'd have to change it later
> if it's not
> correct.

No we don't. The PostgreSQL installer for Windows (which I strategically
made myself a developer of ;-p) writes a bunch of registry entries
describing the installation. pgAdmin searches for local installations
(each major.minor PG version goes in a different location in the
registry) and adds the appropriate server node to the tree for each one
it finds. Note that it only searches for service installations, so if
you didn't install it as a service, it won't be found.

Regards, Dave

Dave Page wrote:
>
>
>
>>-----Original Message-----
>>From: pgadmin-hackers-owner@postgresql.org
>>[mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of
>>Andreas Pflug
>>Sent: 13 April 2005 13:56
>>To: Florian G. Pflug
>>Cc: pgadmin-hackers
>>Subject: Re: [pgadmin-hackers] Roadmap for pgAdmin3 on OSX
>>
>>Florian G. Pflug wrote:
>>
>>>So pgadmin3 on windows checks if there is a service called
>>
>>"postgresql" (or
>>
>>>whatever), and then create a server definition for that postgres
>>>instance if it find an appropriate service?
>>
>>Yup.
>>
>>
>>>How does pgadmin3 know the configuration for the service?
>>
>>(I guess it at
>>
>>>least needs to know the port number)
>>
>>We just guess it to be 5432... You'd have to change it later
>>if it's not
>>correct.
>
>
> No we don't.

.. Unless changed in postgresql.conf, which won't be reflected in the
registry.

Regards,
Andreas

Hi,

> Are you sure you recompiled _all_ pgadmin files - if you just run configure
> and specify a different wx-config, the build system doesn't realize it
> has to rebuild everything. I had some unresolved symbols when switching
> from wx 2.5.4 to 2.5.5, and they went away after doing "make clean; make"

i always do either make clean/distclean

but in these cases i've been re dl'ing into fresh dirs to be sure ...

>> i'm trying the wxMac 2.5.5 release at the moment ...
> Be sure to include fix by "Stefan Csomor":

<snip>

OK

> Well, pgadmin needs to know how to start and stop postgres -
> on osx - so we at least need to know the "servicename".
> Of course this can be made configureable - but if there
> was a "official way" for these things on osx, we could
> save some config options.

Well, the 'official way' is to use the StartupItem script in
/Library/StartupItems for 3rd party, and/or /System/Library/StartupItems for
Apple-installed ...

I simply don't recall if PGSql installs one automatically ... I don't think so
-- as I write my own and use in independent of the Apple hierarchy.

that said, its as 'easy' as "(path to)/startup_script start" or "(path
to)/startup_script start"

the script can be named anything, and controls postmaster/pg_ctl directly.

if you like, i can post my script ...

>> are you thinking of simply using a LaunchServices assignment (i.e.,
>> using the GetInfo dialog's "Open with ..." facility?)
> Kind of... see my other post in this thread - we'd need a way to remeber
> the connection this sql was used in, or a way for the use to specify that.

ah.  my mistake.

i thought your were just worrying about getting the editable-query to open in a
selectable query editor ...

i see that you're talking about launching a query.

what i've done on occassion is simply write a shell-script and wrap it with a
finder-dubl-clickable wrapper ...

not "production quality", tho ...

>>> ad 3): This is a bug in configure - but I still don't know how to
>>> fix/workaround this.
>> do you have a thread reference for the particular problem, or a breif
>> description?
> See my other mail in this thread.

ok.

>> I've had no apparent issue linking/building against my external SSL
>> build; however, i haven't gotten as far as testing function ...
> Have you checked wether you actually got ssl support - I can link
> against a ssl-enabled libpq just fine - but the pgadmin configure
> doesn't detect the ssl-support, and disabled ssl-support for pgadmin.

i will as soon as i beat my build problems ... suddenly i've now got unresolved
symbol issues all over the place. argh.

richard

On Apr 13, 2005, at 07:05, Florian G. Pflug wrote:

> Be sure to include fix by "Stefan Csomor":
> ---------------
> as I don't have a buildable situation for pgadmin on my system, could
> you please try out whether adding
>
> DoSetWindowVariant( m_windowVariant) ;
>
> in toplevel.cpp line 1204 , just in front of the m_macFocus = NULL ;
> -----------------

What does this fix?

I successfully built pgadmin3-1.2.1 and wxMac-2.5.5 just by following
the instructions on the pgadmin web page. I had to add a few things to
the LIBS=... line in pgadmin3/src/Makefile and make a bundle directory
structure and Info.plist for the resulting binary, but otherwise it
worked beautifully out of the box.

Then I checked out pgadmin3 HEAD and built it with --enable-appbundle,
and I still had to modify the LIBS=... line a bit in
pgadmin3/src/Makefile, but otherwise it was a clean build.

The only issue I'm having is the widget sizing. It seems like the
windows are too small for the widgets inside them. Does Stefan's
one-liner fix address this problem? Or is it addressing something else?

Thanks! Looking good!

- Chris

> -----Original Message-----
> From: pgadmin-hackers-owner@postgresql.org
> [mailto:pgadmin-hackers-owner@postgresql.org] On Behalf Of
> Chris Campbell
> Sent: 14 April 2005 03:43
> To: pgadmin-hackers
> Subject: Re: [pgadmin-hackers] Roadmap for pgAdmin3 on OSX
>
>
> The only issue I'm having is the widget sizing. It seems like the
> windows are too small for the widgets inside them. Does Stefan's
> one-liner fix address this problem? Or is it addressing
> something else?

Yes, it was to do with sizing.

Regards, Dave

Chris Campbell wrote:
> I successfully built pgadmin3-1.2.1 and wxMac-2.5.5 just by following
> the instructions on the pgadmin web page. I had to add a few things to
> the LIBS=... line in pgadmin3/src/Makefile and make a bundle directory
> structure and Info.plist for the resulting binary, but otherwise it
> worked beautifully out of the box.
>
> Then I checked out pgadmin3 HEAD and built it with --enable-appbundle,
> and I still had to modify the LIBS=... line a bit in
> pgadmin3/src/Makefile, but otherwise it was a clean build.
What did you need to change? Please give me more detail, I'd like to fix this,
so that I build out-of-the-box.

> The only issue I'm having is the widget sizing. It seems like the
> windows are too small for the widgets inside them. Does Stefan's
> one-liner fix address this problem? Or is it addressing something else?
Yes, I fixes exactly that.

greetings, Florian Pflug