wxFileDialog for GTK2
Robert Roebling
Hi,
now that GTK+ 2.4 has a good looking file dialog,
we should probably use it. As with the printing
stuff, I'm currently fighting with, the problem
is that there is no such dialog in GTK+ 2.2, so
we'd have to use a pimpl implementation here
again and check at run-time, if GTK+ is version
2.4 and has the new dialog.
Robert
ABX
> now that GTK+ 2.4 has a good looking file dialog,
> we should probably use it.
Patch #1045753.
ABX
Vaclav Slavik
> Hi,
>
> now that GTK+ 2.4 has a good looking file dialog,
> we should probably use it.
Certainly. The beginnings are here:
https://sourceforge.net/tracker/?func=detail&atid=309863&aid=1045753&group_id=9863
I asked the submitter to fix some problems with it, if he won't, I'll
do it.
> As with the printing
> stuff, I'm currently fighting with, the problem
> is that there is no such dialog in GTK+ 2.2, so
> we'd have to use a pimpl implementation here
> again and check at run-time, if GTK+ is version
> 2.4 and has the new dialog.
Why? We already have a couple of 2.4 only features checked at compile
time, so a version built against 2.4 (which you have to do to get the
new selector, obviously) will not run on older GTK+ versions anyway.
Regards,
Vaclav
--
PGP key: 0x465264C9, available from http://pgp.mit.edu/
Vadim Zeitlin
VS> Why? We already have a couple of 2.4 only features checked at compile
VS> time, so a version built against 2.4 (which you have to do to get the
VS> new selector, obviously) will not run on older GTK+ versions anyway.
If an app compiled with GTK 2.4 is otherwise (i.e. currently compatible
with GTK 2.2 libs, then I think it would be a pity to break this. So being
able to use the 2.4 selector while still having a fallback to the generic
one when running under 2.2 would be nice.
Again, all this only makes sense if there are no other 2.4 run-time
dependencies, of course. I can't check it though as I don't have 2.2
installed anywhere any more.
Regards,
VZ
Vaclav Slavik
Vadim Zeitlin wrote:
> VS> Why? We already have a couple of 2.4 only features checked at
> compile VS> time, so a version built against 2.4 (which you have to
> do to get the VS> new selector, obviously) will not run on older
> GTK+ versions anyway.
>
> If an app compiled with GTK 2.4 is otherwise (i.e. currently
> compatible with GTK 2.2 libs,
It is not, see above.
> Again, all this only makes sense if there are no other 2.4 run-time
> dependencies, of course. I can't check it though as I don't have 2.2
> installed anywhere any more.
Grep $(wx)src/*/* for GTK_CHECK_VERSION, it will show you places where
2.4 (or other >2.0 versions) functions are used. In addition to that,
HAVE_PANGO_FONT_FAMILY_IS_MONOSPACE in fontenum.cpp is a relatively
recent function in Pango libs. Loading all of these functions
dynamically is possible with some effort, but I think it's not good
idea, because there will be more and more useful functions added to
GTK+ and we'd have to do it in many places.
Robert Roebling
> > now that GTK+ 2.4 has a good looking file dialog,
> > we should probably use it.
>
> Certainly. The beginnings are here:
> https://sourceforge.net/tracker/?func=detail&atid=309863&aid=1045753&group_id=9863
>
> I asked the submitter to fix some problems with it, if he won't, I'll
> do it.
>
> > As with the printing
> > stuff, I'm currently fighting with, the problem
> > is that there is no such dialog in GTK+ 2.2, so
> > we'd have to use a pimpl implementation here
> > again and check at run-time, if GTK+ is version
> > 2.4 and has the new dialog.
>
> Why? We already have a couple of 2.4 only features checked at compile
> time, so a version built against 2.4 (which you have to do to get the
> new selector, obviously) will not run on older GTK+ versions anyway.
I think that the other features are not nearly as important
as having a new file dialog, so I'd consider being able to
distribute binaries that work with GTK 2.2.X and using the
new file dialog a plus. I agree, though, that checking for
every new feature at run-time would be a bit of a burden...
Robert
Vaclav Slavik
Mart Raudsepp wrote:
> Quite all of this can be checked very easilly at run-time.
> That is, if a wx application is compiled statically against
> gtk+-2.4 (shared), then it's not that hard to make some or all of
> the 2.4 specific things work on a gtk+-2.2 system with that static
> binary.
That's an interesting idea! If we could make it work, I'm all for it.
Regards,
Mart Raudsepp
> On Sun, 28 Nov 2004 15:57:30 +0200 Mart Raudsepp <le...@dustbite.net> wrote:
>
> MR> Could the choosing between GtkFileChooserDialog and wxGenericFileDlg
> MR> still be done on runtime?
>
> It could, of course, but not that easily.
>
> MR> That fancy p_impl thing maybe that I have no idea of?
>
> Yes, this (not really fancy) pImpl approach would probably idneed be
> needed. It's quite some work, although definitely possible...
Then you can make it work on gtk+-2.2 system with the older filedialog
by putting it inside something like
#if GTK_CHECK_VERSION(2,4,0)
if(!gtk_check_version(2,4,0)
{
p_impl = something
#else
--
With regards,
Mart Raudsepp
Project manager of wxMUD
E-mail: le...@dustbite.net
http://wxmud.sourceforge.net/
Kevin Hock
I just searched my sources (which are admittedly about two weeks old or so)
and didn't find a single occurence of __WXGTK24__ ... I do remember seeing
it in your commit to artgtk.cpp but my point was that there were not
hundreds of places that would need updating to do dynamic checking, and I
think that my point is still valid since there are at most only a few
references to __WXGTK24__ (in addition the GTK_CHECK_VERSION calls). In my
local tree, there are only 12 files that use GTK_CHECK_VERSION--not
overwhelming by any means.
I would like to thank Vaclav for his long explanation for wxDynamicLibrary
and pros vs. cons of different solutions... I learned a few things and based
on my [limited] knowledge I also believe that a solution with only one
predictable, consistent way of breakage is probably the most desirable.
Best,
Kevin
----- Original Message -----
From: "Robert Roebling" <rob...@roebling.de>
To: "Kevin Hock" <hoc...@yahoo.com>; "wxdevs" <wx-...@lists.wxwindows.org>
Sent: Sunday, November 28, 2004 2:43 PM
Subject: Re: Re[2]: [wx-dev] wxFileDialog for GTK2
> Am So, 2004-11-28 um 18.30 schrieb Kevin Hock:
> > Hi Vadim,
> >
> > Gotcha. Thanks for the explanation. Fortunately, GTK_CHECK_VERSION
> > isn't used in too many places
>
> ... because I use __WXGTK24__
>
> Robert
>
Kevin Hock
Thanks,
Kevin
> OK, so I propose that add a switch to configure "--disable-gtk24" that
> will disable at compile time all features, which we cannot solve at
> run-time (currently the file dialog falls into that category) and
> add run-time checks for the GTK+ version in the other places where
> we use certain functions or constants only available in GTK+ 2.4.
> That way, we should be able to compile an app with GTK+ 2.4 installed
> and getting it to run under GTK+ 2.2 as well as making use of most
> functionality which GTK+ 2.4 offers if available.
>
> I'm currently thinking of a way how we could event make use of the
> file dialog if GTK+ 2.4 is present (which would entail writing both
> a wxNativeDialog as well as a wxPimplDialog class), but above changes
> can be made without this.
Robert Roebling
> RR> Thinking more about the wxPimplDialog, I don't think this
> RR> is possible do to at all. The idea was to write a wxFileDialog
> RR> which really is a wxDialog, with all the methods and all
> RR> the behaviour of a normal dialog object, but which implements
> RR> itself by way of another dialog referenced by a pointer.
>
> No, not another _dialog_. Another class but this class wouldn't be a
> wxDialog, and it normally wouldn't be a window in GTK+ sense neither. The
> main class should still have a valid m_widget but the function for creating
> it would be in wxFileDialogImpl class.
This may work well for certain (non-GUI) classes, but since
e.g. each dialog imlementation would need its own event table,
the event would need to get routed between the two classes.
This also entails that the wxFileDailogImpl class would at
least have to be a descendant of wxEvtHandler etc. I have
taken a different (and uglier) approach just for the sake
of having any solution for wxFileDialog, since this dialog
plays such a promiment role.
Robert