Re: [pgadmin-hackers] pgadmin3 debian package proposal
Side by side. Mmmm, if we're talking side by side right back to CVS, we really ought to be sure we want to do this. Basically we'd be committing to maintaining our own wx fork indefinately. Moving back to the standard distro might not be so easy in the future... No, I don't want it put into cvs, except for some custom makefiles maybe. We should stay with the current way of syncing our snapshot with wx from time to time, hoping for an age where we can get back to vanilla wx. That said, a single build system really would be nice. If we have wx in a subdirectory of our source tree top side by side to src, the make process can do it in a single build. In this case, we wouldn't need to have wx installed, thus minimizing the chance of interference with an official wx package. Regards, Andreas ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgadmin-hackers] pgadmin3 debian package proposal
Andreas Pflug wrote: Side by side. Mmmm, if we're talking side by side right back to CVS, we really ought to be sure we want to do this. Basically we'd be committing to maintaining our own wx fork indefinately. Moving back to the standard distro might not be so easy in the future... No, I don't want it put into cvs, except for some custom makefiles maybe. We should stay with the current way of syncing our snapshot with wx from time to time, hoping for an age where we can get back to vanilla wx. I agree with this. That said, a single build system really would be nice. If we have wx in a subdirectory of our source tree top side by side to src, the make process can do it in a single build. In this case, we wouldn't need to have wx installed, thus minimizing the chance of interference with an official wx package. What I was imaginating was to find a proper way to put, for example, the .tar.bz2 of "our" wx source in a specific place and to have a "magic" configure (for example) option which could handle the fact that the wx to link against is situated in the source tree. I don't want to get the wx source always in pgadmin3 source tree, think it has nothing to do here and I don't want that we loose cpu time to build wx snap every day when building snapshots... By the way, it may not be a good idea to "waste" a lot of time to get the configure/makefiles modified to get a single build process. May be we could just try to have the proper way of launching each configure / make commands and to document it well so that all packagers can publish spec, rules or whatever is appropriate to each disto. It may than be easier to backout to a dynamic build against official wx when they will be ready. Another thing, may be we should not borrow Michael with these discuss anymore ? He had the good idea and may not want to receive all our thought about it (?) :) I'll send back to you my build process as soon as it will be ok (hope it will be ok one day) (depends on my free time). regards, Raphaël ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] pgadmin3 debian package proposal
Raphaël Enrici wrote: Andreas Pflug wrote: That said, a single build system really would be nice. If we have wx in a subdirectory of our source tree top side by side to src, the make process can do it in a single build. In this case, we wouldn't need to have wx installed, thus minimizing the chance of interference with an official wx package. just for information, I have a first debian package that build without external wx. I'm gonna submit it to my "sponsor" so that he can gives its advice and gave corrections. I'll send you some news asap. The method I adopted follows: pgadmin-1.1.0/wxWindows-pgAdmin3-20031010-5 contains the untared snapshot The debian/rules (equivalent of rpm spec file) is charged of building and installing it in pgadmin-1.1.0/wxWindows-pgAdmin3-20031010-5/localinst just before the pgA3 configure line is invoked.It refers to it using --with-wx and --with-wx-config configure options. regards, Raphaël ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[pgadmin-hackers] New wx patch
Hi Dave,
I nailed down and fixed another clipboard bug. Actually, it's the same
problem we had with gtk, so I extended an existing patch.
I uploaded a cumulative patch to snake, but for compiling a new wx
snapshot you'd probable be better off if you apply the attached patch
separately. Since three files in the current snapshot are already
patched, the re-patch probably fails. Just get a fresh copy from wx cvs,
or I could mail you the files if you like that better.
For gtk, nightly builds do *not* need this additional patch, because the
new patch is just a reimplementation; this change affects only msw.
Regards,
Andreas
Index: src/gtk/clipbrd.cpp
===
RCS file: /pack/cvsroots/wxwindows/wxWindows/src/gtk/clipbrd.cpp,v
retrieving revision 1.53
diff -u -r1.53 clipbrd.cpp
--- src/gtk/clipbrd.cpp 2003/08/09 12:46:08 1.53
+++ src/gtk/clipbrd.cpp 2003/10/26 15:40:15
@@ -171,11 +171,14 @@
/* make sure we got the data in the correct form (selection type).
if so, copy data to target object */
+#if 0
+// prevents things to work, we already checked above!
if (selection_data->type != GDK_SELECTION_TYPE_STRING)
{
clipboard->m_waiting = FALSE;
return;
}
+#endif
data_object->SetData( format, (size_t) selection_data->length, (const char*)
selection_data->data );
@@ -497,6 +500,15 @@
(guint32) GDK_CURRENT_TIME );
while (m_waiting) gtk_main_iteration();
+
+#if defined(__WXGTK20__) && wxUSE_UNICODE
+if (!m_formatSupported && format == wxDataFormat(wxDF_UNICODETEXT))
+{
+// Another try with plain STRING format
+ extern GdkAtom g_altTextAtom;
+ return IsSupported(g_altTextAtom);
+}
+#endif
if (!m_formatSupported) return FALSE;
Index: src/gtk/dataobj.cpp
===
RCS file: /pack/cvsroots/wxwindows/wxWindows/src/gtk/dataobj.cpp,v
retrieving revision 1.40
diff -u -r1.40 dataobj.cpp
--- src/gtk/dataobj.cpp 2003/09/09 18:04:57 1.40
+++ src/gtk/dataobj.cpp 2003/10/26 15:40:16
@@ -28,6 +28,7 @@
//-
GdkAtom g_textAtom= 0;
+GdkAtom g_altTextAtom = 0;
GdkAtom g_pngAtom = 0;
GdkAtom g_fileAtom= 0;
@@ -77,12 +78,9 @@
{
PrepareFormats();
-if (type == wxDF_UNICODETEXT)
- type = wxDF_TEXT;
-
m_type = type;
-if (m_type == wxDF_TEXT)
+if (m_type == wxDF_TEXT || m_type == wxDF_UNICODETEXT)
m_format = g_textAtom;
else
if (m_type == wxDF_BITMAP)
@@ -143,7 +141,10 @@
// here (with whom?)
if (!g_textAtom)
#if wxUSE_UNICODE
+{
g_textAtom = gdk_atom_intern( "UTF8_STRING", FALSE );
+g_altTextAtom = gdk_atom_intern( "STRING", FALSE );
+}
#else
g_textAtom = gdk_atom_intern( "STRING" /* "text/plain" */, FALSE );
#endif
@@ -191,6 +192,21 @@
return n < nFormatCount;
}
}
+
+
+//
+// wxTextDataObject
+//
+
+#if defined(__WXGTK20__) && wxUSE_UNICODE
+
+void wxTextDataObject::GetAllFormats(wxDataFormat *formats,
wxDataObjectBase::Direction dir) const
+{
+*formats++ = GetPreferredFormat();
+*formats = g_altTextAtom;
+}
+
+#endif
//
// wxFileDataObject
Index: src/msw/ole/dataobj.cpp
===
RCS file: /pack/cvsroots/wxwindows/wxWindows/src/msw/ole/dataobj.cpp,v
retrieving revision 1.75
diff -u -r1.75 dataobj.cpp
--- src/msw/ole/dataobj.cpp 2003/09/12 16:10:00 1.75
+++ src/msw/ole/dataobj.cpp 2003/10/26 15:40:16
@@ -755,6 +755,23 @@
#endif // Debug
+
+
+//
+// wxTextDataObject supports CF_UNICODETEXT, CF_TEXT, CF_OEMTEXT
+//
+
+
+void wxTextDataObject::GetAllFormats(wxDataFormat *formats,
+ wxDataObjectBase::Direction WXUNUSED(dir)) const
+{
+*formats++ = wxDataFormat(wxDF_UNICODETEXT);
+*formats++ = wxDataFormat(wxDF_TEXT);
+*formats = wxDataFormat(wxDF_OEMTEXT);
+}
+
+
+
//
// wxBitmapDataObject supports CF_DIB format
//
Index: include/wx/dataobj.h
===
RCS file: /pack/cvsroots/wxwindows/wxWindows/include/wx/dataobj.h,v
retrieving revision 1.51
diff -u -r1.51 dataobj.h
--- include/wx/dataobj.h2003/08/09 12:37:10 1.51
+++ i
Re: [pgadmin-hackers] New wx patch
Hi Andreas. setup0.h isn't contained though "wx-20031026.patch" of the accumulation. you think that it was particularly excluded. Write it in readme-patches.txt. Because I was stupid, I did Make-Test again.:-( Does the thing which contains it become wxWindows-pgAdmin3-20031010-6.tar.bz2? And ID of the doubt?(828538->828537) ---readme-patches.txt----- ... wx-20031026.patch = ... all 828538 Wrong size calculation in wxCalendarCtrl Is it 828538? So, I am not found. regards, Hiroshi Saito - Original Message - From: "Andreas Pflug" <[EMAIL PROTECTED]> > Hi Dave, > > I nailed down and fixed another clipboard bug. Actually, it's the same > problem we had with gtk, so I extended an existing patch. > I uploaded a cumulative patch to snake, but for compiling a new wx > snapshot you'd probable be better off if you apply the attached patch > separately. Since three files in the current snapshot are already > patched, the re-patch probably fails. Just get a fresh copy from wx cvs, > or I could mail you the files if you like that better. > > For gtk, nightly builds do *not* need this additional patch, because the > new patch is just a reimplementation; this change affects only msw. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
