Thread: The future of pgAdmin II...
Probably a little less dramatic than the subject implies, but I've now had a chance to play with Visual Studio.NET and got to thinking about where we're going with pgAdmin II. I've performed a test upgrade of the pgAdmin II main project to VB.NET - believe it or not, the upgrade report (attached) lists 413 issues post upgrade!! Don't forget, that doesn't include pgSchema or any of the Plugins, Exporters or Highlightbox. In light of this, I propose that pgAdmin II should stay as a VB6 application, at least for the forseeable future. For the longterm future (i.e. pgAdmin III), I think the way forward is C#. I've been playing with this over the last few days and it seems fairly easy to learn, and should easily do what would be required. The best bit is that there should be an open-source compiler and class libraries available soon (http://www.go-mono.com) which would enable us to target *nix platforms. In the nearer future, it should be possible to build plugins & exporters for pgAdmin II in C#, so I may well try this, and if successful, try porting some of the existing ones across. Anyway, I would welcome any comments *anyone* has about this. Regards, Dave.
Attachment
Hello,
I don't know what elements would be needed for .NET but it would
certainly be a pain if older windows needed to spend ages downloading to get
it working (or worse, couldn't get a .NET version working). Also I'm not
sure but I thought the mono project had very few class libraries completed.
If your wanting it working under linux in the near future wine may be the
way to go (I don't know about other *nix though). Still in the future it may
be the way to go (after the mono project shapes up etc...) .
Cheers,
- Stuart
> -----Original Message-----
> From: Dave Page [mailto:dpage@vale-housing.co.uk]
> Sent: 27 March 2002 10:56
> To: pgadmin-hackers@postgresql.org
> Subject: [pgadmin-hackers] The future of pgAdmin II...
>
>
>
> Probably a little less dramatic than the subject implies, but
> I've now had a
> chance to play with Visual Studio.NET and got to thinking
> about where we're
> going with pgAdmin II.
>
> I've performed a test upgrade of the pgAdmin II main project
> to VB.NET -
> believe it or not, the upgrade report (attached) lists 413 issues post
> upgrade!! Don't forget, that doesn't include pgSchema or any
> of the Plugins,
> Exporters or Highlightbox.
>
> In light of this, I propose that pgAdmin II should stay as a VB6
> application, at least for the forseeable future.
>
> For the longterm future (i.e. pgAdmin III), I think the way
> forward is C#.
> I've been playing with this over the last few days and it
> seems fairly easy
> to learn, and should easily do what would be required. The
> best bit is that
> there should be an open-source compiler and class libraries
> available soon
> (http://www.go-mono.com) which would enable us to target *nix
> platforms.
>
> In the nearer future, it should be possible to build plugins
> & exporters for
> pgAdmin II in C#, so I may well try this, and if successful,
> try porting
> some of the existing ones across.
>
> Anyway, I would welcome any comments *anyone* has about this.
>
> Regards, Dave.
>
>
> -----Original Message----- > From: Henshall, Stuart - WCP > [mailto:SHenshall@westcountrypublications.co.uk] > Sent: 27 March 2002 10:55 > To: 'Dave Page'; pgadmin-hackers@postgresql.org > Subject: RE: [pgadmin-hackers] The future of pgAdmin II... > > > Hello, > I don't know what elements would be needed for .NET but > it would certainly be a pain if older windows needed to spend > ages downloading to get it working (or worse, couldn't get a > .NET version working). Windows 95 isn't supported by .NET, and even XP doesn't include the framework. However, currently a pre-requisite is MDAC, which wouldn't be required, neither would the >1Mb msvbvm60.dll. However, I do take your point. > Also I'm not sure but I thought the > mono project had very few class libraries completed. If your > wanting it working under linux in the near future wine may be > the way to go (I don't know about other *nix though). Still > in the future it may be the way to go (after the mono project > shapes up etc...) . Yeah, this is a problem with Mono, however I am talking *way* (== years) in the future for pgAdmin III, by which time this shouldn't be a concern. Regards, Dave.
Dave Page wrote: > <snip> > For the longterm future (i.e. pgAdmin III), I think the way forward is C#. > I've been playing with this over the last few days and it seems fairly easy > to learn, and should easily do what would be required. The best bit is that > there should be an open-source compiler and class libraries available soon > (http://www.go-mono.com) which would enable us to target *nix platforms. Hi Dave, Purely as a matter of curiosity, what is it about C# which makes you feel it's the best available choice (I know, years in the future though). :) Regards and best wishes, Justin Clift <snip> > > Anyway, I would welcome any comments *anyone* has about this. > > Regards, Dave. > > ------------------------------------------------------------------------ > Name: Upgrade Report.zip > Upgrade Report.zip Type: Zip Compressed Data (application/x-zip-compressed) > Encoding: base64 > > Part 1.3 Type: Plain Text (text/plain) > Encoding: 8bit -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
> -----Original Message----- > From: Justin Clift [mailto:justin@postgresql.org] > Sent: 27 March 2002 14:41 > To: Dave Page > Cc: pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] The future of pgAdmin II... > > > Dave Page wrote: > > > <snip> > > For the longterm future (i.e. pgAdmin III), I think the way > forward is > > C#. I've been playing with this over the last few days and it seems > > fairly easy to learn, and should easily do what would be > required. The > > best bit is that there should be an open-source compiler and class > > libraries available soon > > (http://www.go-mono.com) which would enable us to target > *nix platforms. > > Hi Dave, > > Purely as a matter of curiosity, what is it about C# which > makes you feel it's the best available choice (I know, years > in the future though). If you believe the Microsoft hype (and I'm beginning to *this time* after playing with it), it combines the power of C++ with the development speed of VB. Despite years of tinkering, I could never get my head round C++ (probably didn't spend enough time in one go on it), yet my first app in C# (which took about 4 hours to learn/write) featured complete exception handling and input validation and allowed the user to enter connection details into a gui, then connected to PostgreSQL and listed the tables & their rowcounts in template1 into a listview. C/C++ with QT (even if I did get C++) would be *slow* to develop in. I wrote ~30,000 lines of fairly bug free code for pgAdmin II in about a year of spare time, working just little enough to keep the wife from throttling me. I could never have done that in C/C++. Java, *in my experience* is generally slow and clunky (before anyone starts, I'm not trolling). I've had problems with most Java apps I've come across. VB.NET is so different from VB6, that I don't want to learn it and spend the rest of my time in VB6 projects deleting the .NET code I just typed in without thinking. It's also not cross platform, not to mention the 400 upgrade issues with pgAdmin2.vbp!. So that's it I suppose. It's quick to learn, and will be cross platform soon (with a little effort fro Ximian + friends) and should do everything and more that pgAdmin XXX will require. Regards, Dave.
Dave/All, apologies if this has been discussed before but have you considered boa/python/wxwindows as a target platform? I haven't looked at boa for a while but it was usable a while back and offered a very delphi like ide. I think that potentially both projects could benefit as a number of data aware wxwindows components would be produced that could be added to the boa environment whilst existing components could be used in pgAdmin III?... Regards Steve Boyle
Dave, If there's one motto I've learned over the years.. "If it ain't broke, don't fix it." Why move to VB.NET (C#, VB.NET, etc.) in the first place? What new features and performances increases are going to be made available over the VB6 implementation of it ? I spent hundreds of dollars on Visual Studio 6, and have no intention of upgrading to VB.NET, because of cost concerns, and I'm sure there are many other developers that feel the same way. Perhaps in a few years it might really take off, but why lose the prospective developers that might join the project, that don't have VB.NET ? A lot of people have VB6 now, as it is, and know how to use it. You'd possibly be excluding an area of expertise, and developers that can't code in .NET. Again though, why the extra work to convert it, re-test everything, when there is already a working project, that anyone can jump in and modify if they need to ? It just seems like reinventing the wheel, when there is already something that works well. Why spend the extra development time on a new .NET version, when you could be spending that time adding new features and maturing the current version(s) ? My two cents :) Thanks, - Matthew
> -----Original Message----- > From: Steve Boyle [mailto:boylesa@co.uk] > Sent: 27 March 2002 19:24 > To: Justin Clift; Dave Page; pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] The future of pgAdmin II... > > > Dave/All, > > apologies if this has been discussed before but have you considered > boa/python/wxwindows as a target platform? To be honest, Python is the only one of those I've heard of. Do you know any good sites I could look at or should I just use Google? Regards, Dave.
> -----Original Message----- > From: Matthew M. [mailto:initri@initri.com] > Sent: 27 March 2002 21:59 > To: pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] The future of pgAdmin II... > > > Dave, > > If there's one motto I've learned over the years.. "If it > ain't broke, don't fix it." Why move to VB.NET (C#, VB.NET, > etc.) in the first place? What new features and performances > increases are going to be made available over the VB6 > implementation of it ? The main advantage would be cross platform capabilities provided by the Mono project (when it's ready). > I spent hundreds of dollars on Visual > Studio 6, and have no intention of upgrading to VB.NET, > because of cost concerns, and I'm sure there are many other > developers that feel the same way. Sooner or later most developers will probably upgrade. How many people do you know that are still actively using VB4? It was only about 5 years ago that that was the current version. That aside, the .NET SDK is free and supposedly includes command line compilers for VB/C#. I posted a URL for an IDE earlier. There is also the free Mono compiler which works on Windows/Linux now, it just requires the Microsoft class libraries until those are cloned as well. > Perhaps in a few years it might really take off, but why lose > the prospective developers that might join the project, that > don't have VB.NET ? A lot of people have VB6 now, as it is, > and know how to use it. You'd possibly be excluding an area > of expertise, and developers that can't code in .NET. Don't forget I'm looking forward to *at least* a year from now. > Again though, why the extra work to convert it, re-test > everything, when there is already a working project, that > anyone can jump in and modify if they need to ? It just > seems like reinventing the wheel, when there is already > something that works well. Why spend the extra development > time on a new .NET version, when you could be spending that > time adding new features and maturing the current version(s) ? After about 4 years, pgAdmin I got to the point where we just couldn't add the new features we wanted because of the way the design had grown. After much thought I decided to rewrite from scratch, taking into account how the old code had grown and it's limitations and allowing for easy addition of well structured new code. That's bought us a few more years, but we will probably run into the same problems again. In fact, come to think of it I've just committed a new feature to CVS which forced me to include database knowledge in pgAdmin rather than pgSchema - something I always discouraged myself and others from doing. I can't stress enough - this *is not happening now*. I'm just considering what form the next rewrite might take when it's required *in a few years*. Regards, Dave.
> To be honest, Python is the only one of those I've heard of. Do you know > any good sites I could look at or should I just use Google? Dear all, 1) WxWindows http://www.wxWindows.org http://www.wxWindows.org/screensh.htm 2) WxPython http://www.wxpython.org http://www.wxpython.org/wxpshots.php 3) GUI http://boa-constructor.sourceforge.net/ http://www.roebling.de/default.html (10 user licence = 399 EUR) http://www.mema.ucl.ac.be/~rolinsky/xrced/ http://wxworkshop.sourceforge.net http://wxstudio.sourceforge.net 4) http://www.roebling.de/info.html ........ Begin of extract wxDesigner is a tool written to make creating dialogs for wxWindows based programs easy and fast. wxWindows is a cross-platform toolkit and it thus cannot make use of native resource formats as they typically exist for many platforms. For that reason, wxWindows has been optimized over time to make writing dialogs by hand as easy as possible, but this approach has limitations as soon as dialogs reach a certain complexity. Even without the inevitable number of typos, writing nice looking dialogs is a hassle and reordering the items in a dialog often amounts to rewriting the dialog from scratch. In addtion to being quite some work, writing dialogs also requires a profound and exact knowledge of the syntax used for creating and positioning dialog items. Another problem when writing dialogs using the wxWindows library is that some users might want to make use of the RAD features of the Python bindings during development, but create a native binary using C++ at the end. This would entail rewriting (or at least reediting considerably) all dialog related code. [...] ........ End of extract Does it mean we can develop a visual application in an interpreted language using Python bindings .. and obtain a native compiled binary in the end? This seems very exciting. Cheers, Jean-Michel
> -----Original Message----- > From: Jean-Michel POURE [mailto:jm.poure@freesurf.fr] > Sent: 28 March 2002 07:19 > To: pgadmin-hackers@postgresql.org > Cc: 'boylesa@roselink.co.uk'; Justin Clift; Dave Page > Subject: Re: [pgadmin-hackers] The future of pgAdmin II... > > > > To be honest, Python is the only one of those I've heard of. Do you > > know any good sites I could look at or should I just use Google? > > Dear all, > > 1) WxWindows > http://www.wxWindows.org > http://www.wxWindows.org/screensh.htm > > 2) WxPython > http://www.wxpython.org > http://www.wxpython.org/wxpshots.php > > 3) GUI > http://boa-constructor.sourceforge.net/ > http://www.roebling.de/default.html (10 user licence = 399 > EUR) http://www.mema.ucl.ac.be/~rolinsky/xrced/ > http://wxworkshop.sourceforge.net http://wxstudio.sourceforge.net > > 4) http://www.roebling.de/info.html Hmm, does look good. I especially liked the Matrix Sizer on the wxworkshop site. > ........ Begin of extract > wxDesigner is a tool written to make creating dialogs for > wxWindows based > programs easy and fast. > > wxWindows is a cross-platform toolkit and it thus cannot make > use of native > resource formats as they typically exist for many platforms. > For that reason, > wxWindows has been optimized over time to make writing > dialogs by hand as > easy as possible, but this approach has limitations as soon > as dialogs reach > a certain complexity. Even without the inevitable number of > typos, writing > nice looking dialogs is a hassle and reordering the items in > a dialog often > amounts to rewriting the dialog from scratch. In addtion to > being quite some > work, writing dialogs also requires a profound and exact > knowledge of the > syntax used for creating and positioning dialog items. > > Another problem when writing dialogs using the wxWindows > library is that some > users might want to make use of the RAD features of the > Python bindings > during development, but create a native binary using C++ at > the end. This > would entail rewriting (or at least reediting considerably) > all dialog > related code. [...] > ........ End of extract > > Does it mean we can develop a visual application in an > interpreted language > using Python bindings .. and obtain a native compiled binary > in the end? I took it to mean that's exactly what you don't get. Regards, Dave.