Re: [pgadmin-hackers] pgAdmin Documentation
From: "Guillaume Lelarge" If we were to do the latter, in the Windows Installer for PostgreSQL (which we also need to consider, because it relies on our bundled docs), we would just build the CHM files for each of the three packages, without trying to merge them together. Thoughts? I would definitly vote for option 2. I also think of with you.! There were some discussions about the content of a Japanese document before. It has already had a Japanese version of PostgreSQL and Slony. Then, It is very huge. Moreover, timing in which Fix was up to date done had the problem that release and synchronization were not able to be taken. I'm very huge the translation work, and think that an important mission of team work. There is a special team in Japan PostgreSQL Users Group.!! I hope to act in the specific place emphasized it as each country. P.S) leader of document translation team in Japan. [EMAIL PROTECTED] Regards, Hiroshi Saito ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgadmin-hackers] pgAdmin Documentation
Dave Page a écrit : I've been thinking about trying to sort out the documentation included in pgAdmin. As you know, we currently bundle both the PostgreSQL and Slony docs with pgAdmin - what you may not know is that integrating these together at build time is a real pain, not to mention that those docs account for a major percentage of the number of files in our subversion repository, tarballs and Unix builds, and are also a fair percentage of the total size. There are at least a couple of options: 1) Leave things as they are, maybe attempt to script some of the build tasks. 2) Un-bundle the PostgreSQL and Slony docs. Allow the user to select a directory, CHM file, or website for each of these (we already allow a website to be selected for the PostgreSQL docs). This has the additional advantage that the user can use the docs for their server/slony version, rather than the ones we bundle. There's one more advantage to this method : we can use a translated manual. If we were to do the latter, in the Windows Installer for PostgreSQL (which we also need to consider, because it relies on our bundled docs), we would just build the CHM files for each of the three packages, without trying to merge them together. Thoughts? I would definitly vote for option 2. -- Guillaume. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgadmin-hackers] 'Stealing' SQL files association considered harmful
Magnus Hagander wrote: > Not really. I would've suggested the separate feature thing, but if that > doesn't work... > > Can we make it a checkbox and disable it from there? That's what would require a CA and custom dialogs. The CA because there is no way to put a condition on the appropriate tags, and custom dialogues because at the moment we're using the stock WiX ones and we'd need a whole set to replace them to add just one custom one. :-( /D ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgadmin-hackers] 'Stealing' SQL files association considered harmful
Dave Page wrote: > Milen A. Radev wrote: >> Testing pgAdmin III 1.7.0 (6292:6293) on Windows XP. After I installed >> it the SQL files (.sql) were associated with it. They used to be >> associated with my default editor. When I tried to delete the new >> association I could not find the extension in the "File Types" list >> (Windows Explorer > Tools > Folder Options). So I had to open the >> registry and delete the association from there. >> >> >> So if that feature will be in 1.8 I would like to request an option in >> the installer for it. >> > > I've spent a couple of hours researching this and I can't see how this > can be achieved in wix without manually re-authoring all the dialogues > and adding a custom action (which would be a *lot* of work). > > The way we're adding the association is exactly per Wix/MS's spec. > Trying to move it into a seperate feature so it can be disabled causes > the database to fail it's ICE69 validation check because it needs to be > in the same feature as it's target. > > Ideas anyone? Magnus? Not really. I would've suggested the separate feature thing, but if that doesn't work... Can we make it a checkbox and disable it from there? //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] Testing v1.7: Creating constraint => core dump
Hi, On Wed, 16 May 2007 10:43:35 +0200, Guillaume Lelarge wrote: > You're right about this. I didn't know constraint dialog used > dlgIndex.cpp. You'll find a patch attached fixing this issue. > Thank, now it works again. -- Greetings, Leszek Trenkner ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] pgAdmin Documentation
Magnus Hagander wrote: I think 2 is good, provided that the windows installer (or RPM packages or whatever is used on Mac) can be configured to pick up something by default. So that I don't have to figure out where my pg docs are if I just installed the bundle. OK, here's what I'm thinking. 1) Add configuration options for pgAdmin, PostgreSQL, EnterpriseDB and Slony helpfiles. 2) At startup, if any of those options are empty, search a set of local directories for the helpfiles: - On Windows only, look for CHM files first; - $INSTDIR/Docs/$LANG/pgadmin3.chm (and postgresql.chm etc) - $INSTDIR/Docs/en_US/pgadmin3.chm - $INSTDIR/Docs/pgadmin3.chm - $INSTDIR/pgadmin3.chm In addition, we look for postgresql.chm & slony.chm in the appropriate directory relative to the pg_dump directory, likewise the equivalent for enterprisedb.chm. - On other platforms (and Windows if we haven't got this far), we look for postgresql.hhp in the appropriate directory relative to the pg_dump directory, likewise the equivalent for enterprisedb.hhp. - For those paths we still haven't satisfied, we look in the same places as per the previous step for index.html files. - Finally, we fall back to websites - http://www.pgadmin.org/docs/current/, http://www.postgresql.org/docs/current/static/ and so on. 3) When the user views a helpfile, if it's a Slony or pgAdmin page, just use the appropriate path, if it's a DBMS page, use the PostgreSQL or EnterpriseDB path as appropriate; - if it's a CHM file, we launch MS HTML Help viewer using wxCHMHelpController - else if it's an hhp file, we launch the wx viewer using wxHtmlHelpController - else we launch the default web browser and pass it the html file, or URL to open. How does that sound? We do get questions about pginstaller why we always include pgadmin docs, which would also be solved as a side-effect of this :-) Yeah. Does this affect searching in help in a bad way? Shouldn't do. For CHM or HHP it'll be as it is now. For HTML there willl be no search, for web, there's the search engine on the site used (assuming there is one). Regards, Dave. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgadmin-hackers] pgAdmin Documentation
On Wed, May 16, 2007 at 12:15:06PM +0100, Dave Page wrote: > Hi, > > I've been thinking about trying to sort out the documentation included > in pgAdmin. As you know, we currently bundle both the PostgreSQL and > Slony docs with pgAdmin - what you may not know is that integrating > these together at build time is a real pain, not to mention that those > docs account for a major percentage of the number of files in our > subversion repository, tarballs and Unix builds, and are also a fair > percentage of the total size. > > There are at least a couple of options: > > 1) Leave things as they are, maybe attempt to script some of the build > tasks. > > 2) Un-bundle the PostgreSQL and Slony docs. Allow the user to select a > directory, CHM file, or website for each of these (we already allow a > website to be selected for the PostgreSQL docs). This has the additional > advantage that the user can use the docs for their server/slony version, > rather than the ones we bundle. > > If we were to do the latter, in the Windows Installer for PostgreSQL > (which we also need to consider, because it relies on our bundled docs), > we would just build the CHM files for each of the three packages, > without trying to merge them together. I think 2 is good, provided that the windows installer (or RPM packages or whatever is used on Mac) can be configured to pick up something by default. So that I don't have to figure out where my pg docs are if I just installed the bundle. We do get questions about pginstaller why we always include pgadmin docs, which would also be solved as a side-effect of this :-) Does this affect searching in help in a bad way? //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[pgadmin-hackers] pgAdmin Documentation
Hi, I've been thinking about trying to sort out the documentation included in pgAdmin. As you know, we currently bundle both the PostgreSQL and Slony docs with pgAdmin - what you may not know is that integrating these together at build time is a real pain, not to mention that those docs account for a major percentage of the number of files in our subversion repository, tarballs and Unix builds, and are also a fair percentage of the total size. There are at least a couple of options: 1) Leave things as they are, maybe attempt to script some of the build tasks. 2) Un-bundle the PostgreSQL and Slony docs. Allow the user to select a directory, CHM file, or website for each of these (we already allow a website to be selected for the PostgreSQL docs). This has the additional advantage that the user can use the docs for their server/slony version, rather than the ones we bundle. If we were to do the latter, in the Windows Installer for PostgreSQL (which we also need to consider, because it relies on our bundled docs), we would just build the CHM files for each of the three packages, without trying to merge them together. Thoughts? Regards, Dave ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] 'Stealing' SQL files association considered harmful
Milen A. Radev wrote: Testing pgAdmin III 1.7.0 (6292:6293) on Windows XP. After I installed it the SQL files (.sql) were associated with it. They used to be associated with my default editor. When I tried to delete the new association I could not find the extension in the "File Types" list (Windows Explorer > Tools > Folder Options). So I had to open the registry and delete the association from there. So if that feature will be in 1.8 I would like to request an option in the installer for it. I've spent a couple of hours researching this and I can't see how this can be achieved in wix without manually re-authoring all the dialogues and adding a custom action (which would be a *lot* of work). The way we're adding the association is exactly per Wix/MS's spec. Trying to move it into a seperate feature so it can be disabled causes the database to fail it's ICE69 validation check because it needs to be in the same feature as it's target. Ideas anyone? Magnus? Regards, Dave. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] Testing v1.7: Creating constraint => core dump
Leszek Trenkner a écrit :
Using recent SVN head (6301M) I've encoutered annoying bug - regression -
that wasn't there a few days back.
When I try to create constraint in the gui - in any way possible (right-
clicking on browser tree node, from the main menu, in table ctration
dialog on constraints tab) - pgadmin just core dumps ("Segmentation fault
(core dumped)"). It seems like the very dialog window that allows one to
input constraint definition is the culprit - but it does mater which type
of the constraint I want to create (primary key and unique do not work)-
so it might be a common piece of code just before displaying that window
between the two.
Everything else seems to work fine, as far as dialog windows are
concerned.
I've tried to debug this issue more closely, bus as far as I've got is
getting debug version of pgAdmin3 build (Ubuntu Fiesty 7.04, Ubuntu
supplied wx-2.8.1-dbg libraries), which unfortunately dies ("core dumped")
just as release build would in any constraint creation attempt. BTW,
where is the dumped core expected to appear?
I've tried to attach debugger to pgadmin3, and if I try to create a
constraint pgadmin stops on line 105 in pgadmin/dlg/dlgIndex.cpp:
105 txtFillFactor->SetValidator(numericValidator);
106 if (connection->BackendMinimumVersion(8, 2))
107 txtFillFactor->Enable();
108 else
109 txtFillFactor->Disable();
110
You're right about this. I didn't know constraint dialog used
dlgIndex.cpp. You'll find a patch attached fixing this issue.
Sorry about this, but thanks for your report.
Regards.
--
Guillaume.
Index: pgadmin/dlg/dlgIndex.cpp
===
--- pgadmin/dlg/dlgIndex.cpp (révision 6301)
+++ pgadmin/dlg/dlgIndex.cpp (copie de travail)
@@ -102,11 +102,14 @@
// create mode
}
-txtFillFactor->SetValidator(numericValidator);
-if (connection->BackendMinimumVersion(8, 2))
-txtFillFactor->Enable();
-else
-txtFillFactor->Disable();
+if (txtFillFactor)
+{
+txtFillFactor->SetValidator(numericValidator);
+if (connection->BackendMinimumVersion(8, 2))
+txtFillFactor->Enable();
+else
+txtFillFactor->Disable();
+}
btnAddCol->Disable();
btnRemoveCol->Disable();
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
[pgadmin-hackers] Testing v1.7: Creating constraint => core dump
Hi,
Using recent SVN head (6301M) I've encoutered annoying bug - regression -
that wasn't there a few days back.
When I try to create constraint in the gui - in any way possible (right-
clicking on browser tree node, from the main menu, in table ctration
dialog on constraints tab) - pgadmin just core dumps ("Segmentation fault
(core dumped)"). It seems like the very dialog window that allows one to
input constraint definition is the culprit - but it does mater which type
of the constraint I want to create (primary key and unique do not work)-
so it might be a common piece of code just before displaying that window
between the two.
Everything else seems to work fine, as far as dialog windows are
concerned.
I've tried to debug this issue more closely, bus as far as I've got is
getting debug version of pgAdmin3 build (Ubuntu Fiesty 7.04, Ubuntu
supplied wx-2.8.1-dbg libraries), which unfortunately dies ("core dumped")
just as release build would in any constraint creation attempt. BTW,
where is the dumped core expected to appear?
I've tried to attach debugger to pgadmin3, and if I try to create a
constraint pgadmin stops on line 105 in pgadmin/dlg/dlgIndex.cpp:
105 txtFillFactor->SetValidator(numericValidator);
106 if (connection->BackendMinimumVersion(8, 2))
107 txtFillFactor->Enable();
108 else
109 txtFillFactor->Disable();
110
So I guess it has something to do with table fill factor patches recently
added... Or just it was the point where everything died (ddd including :-
()
Note - right clicking browser tree node brings up assertion failed dialog
saying (guess it's the manu display code, as the menu doesn't show up):
ASSERT INFO:
../src/gtk/menu.cpp(984): assert "IsCheckable()" failed in IsChecked():
can't get state of uncheckable item!
BACKTRACE:
[1] wxMenuItem::IsChecked() cons)
[2] menuFactoryList::AppendEnabledMenus(wxMenuBar*, wxMenu*) /usr/src/
pgadmin3/pgadmin/./utils/factory.cpp:320
[3] frmMain::doPopup(wxWindow*, wxPoint, pgObject*) /usr/src/pgadmin3/
pgadmin/./frm/events.cpp:427
[4] frmMain::OnSelRightClick(wxTreeEvent&) /usr/src/pgadmin3/pgadmin/./
frm/events.cpp:510
[5] wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)
(wxEvent&), wxEvent&) cons)
[6] wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&,
wxEvtHandler*, wxEvent&)
[7] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[8] wxEvtHandler::ProcessEvent(wxEvent&)
[9] wxEvtHandler::ProcessEvent(wxEvent&)
[10] wxWindowBase::TryParent(wxEvent&)
[11] wxEvtHandler::ProcessEvent(wxEvent&)
[12] wxEvtHandler::ProcessEvent(wxEvent&)
[13] wxScrollHelperEvtHandler::ProcessEvent(wxEvent&)
[14] wxGenericTreeCtrl::OnMouse(wxMouseEvent&)
[15] wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)
(wxEvent&), wxEvent&) cons)
[16] wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&,
wxEvtHandler*, wxEvent&)
[17] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[18] wxEvtHandler::ProcessEvent(wxEvent&)
[19] wxEvtHandler::ProcessEvent(wxEvent&)
[20] wxScrollHelperEvtHandler::ProcessEvent(wxEvent&)
[21] wxWindow::GTKProcessEvent(wxEvent&) cons)
[22] _gtk_marshal_BOOLEAN__BOXED()
[23] g_closure_invoke()
[24] g_signal_emit_valist()
[25] g_signal_emit()
[26] gtk_propagate_event()
[27] gtk_main_do_event()
[28] g_main_context_dispatch()
[29] g_main_loop_run()
[30] gtk_main()
[31] wxEventLoop::Run()
[32] wxAppBase::MainLoop()
It repeats a few times in a row.
It's the one of many alike 'assertion-failed' windows encountered when
using debug version -
which is in fact useless because of them. As I do know nothing about wx
libraries and very little about C++, I don't know if it's the expected
behaviour or some kind of silent bug... Or wxWindows fault.
--
Greetings,
Leszek Trenkner
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
