Re: Logo (was Re: GTK+ Website Review)
Am Dienstag, den 29.05.2007, 01:31 +0200 schrieb Felix Rabe (public): > >>> I wonder where the GTK logo proposal went? I think it would fit quite > >>> well in this design. > >> Actually Andreas was doing some work there. I was sent a few ideas and > >> they looked good, but nothing further so far. > >> > > > > I might have another proposal based on the first one from Christophe > > ready in a short while. Those detached, glossy faces look cool, but they also make the logo look fragile. Well, and "fragile" that's definitly not a term I do or want associate with GTK+... Ciao, Mathias -- Mathias Hasselmann <[EMAIL PROTECTED]> http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Logo (was Re: GTK+ Website Review)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here is my take at the GTK+ logo. It is just a proposal, since it needs some optimization for icon sizes (I think). Remember that the original was from Christophe Dehais: http://mail.gnome.org/archives/gtk-devel-list/2007-April/msg00118.html Felix Rabe (public) wrote: > Martyn Russell wrote: > >>> I wonder where the GTK logo proposal went? I think it would fit quite >>> well in this design. >> Actually Andreas was doing some work there. I was sent a few ideas and >> they looked good, but nothing further so far. >> > > I might have another proposal based on the first one from Christophe > ready in a short while. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGW2ZqlW86h1QHmOcRAkLfAJ9HZaSstUmgBrr0M79jLmd7n8LsDQCfcvJD bwtItrcu+rAqk+qKKOyAibk= =3HZv -END PGP SIGNATURE- <>___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review
On Tue, 2007-05-29 at 00:08 +0100, Martyn Russell wrote: > I agree. I did look into frames, etc to get around this, but that > causes > more problems than it solves. The main problem here is that the FAQ is > generated, so we would need some post-docbook fix up script to do > something here. It is not insurmountable, adding just the line to use > the CSS formatting makes quite a difference. > > The other option, was to have the FAQ only on the website and not have > an SGML document - it really depends on how necessary it is to be able > to create the FAQ in PDF, HTML, and other formats with the docbook > tools. If possible I would rather it was just online. Yes, I agree. When I am looking for a FAQ, the first place I look is on the website. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review
Hi, If the headers prevent text to be black, I think headers should look different :) - Maybe use underlines (width=100%)? You might experiment with putting the text into the -- which should be there... why did you put the text next to the logo into the image file too? -- so it reads "GTK+ Overview" / "GTK+ FAQ" / "About GTK+" (!) - and use the same for (it's almost there). Then use instead of for all other headings. I say "experiment" because I can't think of a website that integrates their project name with the page name that much (or I didn't notice). Martyn Russell wrote: >> I wonder where the GTK logo proposal went? I think it would fit quite >> well in this design. > > Actually Andreas was doing some work there. I was sent a few ideas and > they looked good, but nothing further so far. > I might have another proposal based on the first one from Christophe ready in a short while. Greetings, Felix ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martyn Russell wrote: > Cody Russell wrote: >> On Mon, 2007-05-28 at 19:15 +0100, Martyn Russell wrote: >>> * What are people's thoughts on the initial look and feel? >> It looks great, except for the FAQ. Can it be styled similarly to the >> rest of the site and include the navigation bar at the top? > > I agree. I did look into frames, etc to get around this, but that causes > more problems than it solves. The main problem here is that the FAQ is > generated, so we would need some post-docbook fix up script to do > something here. It is not insurmountable, adding just the line to use > the CSS formatting makes quite a difference. > > The other option, was to have the FAQ only on the website and not have > an SGML document - it really depends on how necessary it is to be able > to create the FAQ in PDF, HTML, and other formats with the docbook > tools. If possible I would rather it was just online. > The FAQ is in SGML, right? What about converting it to proper XML (DocBook if you like), then write a custom XSLT stylesheet for it? (I would volunteer.) Felix -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGW2J5lW86h1QHmOcRArs5AKDBtWBFIifUaXow3h8mCnHmw5f/dACgm7oy RYjbYYU31T1aAhZRauzni7c= =cY1O -END PGP SIGNATURE- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review
Cody Russell wrote: > On Mon, 2007-05-28 at 19:15 +0100, Martyn Russell wrote: >> * What are people's thoughts on the initial look and feel? > > It looks great, except for the FAQ. Can it be styled similarly to the > rest of the site and include the navigation bar at the top? I agree. I did look into frames, etc to get around this, but that causes more problems than it solves. The main problem here is that the FAQ is generated, so we would need some post-docbook fix up script to do something here. It is not insurmountable, adding just the line to use the CSS formatting makes quite a difference. The other option, was to have the FAQ only on the website and not have an SGML document - it really depends on how necessary it is to be able to create the FAQ in PDF, HTML, and other formats with the docbook tools. If possible I would rather it was just online. -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review
Felix Rabe (public) wrote: > Hi Martyn, > > Martyn Russell wrote: >> Hi, > >> Over the last few weeks, I have spent time putting together the new >> website for gtk.org. I decided it would be easier to start from scratch >> reusing the original content. > >> I have put the new pages up here for review: > >> http://www.imendio.com/~martyn/gtk/ > >> The content is my primary interest, but if you have style queries or >> comments they are also welcome. > > Great work! This is the way to go, it looks great generally. Thanks > too for the clean HTML source. :) Yes, it is much nicer to work with. > Now come the "bad news" :) I will purely comment on style here. > > So, at first sight, the page looked a bit "empty". It was just a > feeling of "something is missing". I agree, the "Overview" page does need something, but I have yet to put my finger on it. > I think the Inkscape website had it, > but http://winehq.org/ still has it - a screenshot on the front page, > something representative besides just a logo. I think another source of > that feeling comes from the text color - just use black please. Make it > as easy on the eyes as possible, so black is *the* color for normal > paragraphs. Actually, I disagree here. Black is really quite harsh and the headers look less defined as a result. Perhaps if the headers were different it would work. > Also, the WineHQ page (at least the main page) has a reddish color > theme. Maybe use (GTK logo) colors for headings? Something like dark > (!) green for description pages (Overview, Features, About), blue for > downloadable stuff (Download, Screenshots), and red for in-depth / > development pages (Development). Hmm, that doesn't sound very logical to me and as a user I would wonder why some things are one colour and other things are another. That is just not what the user wants when they use a web site. > I would put the FAQ in the last > category, but I'm not too sure. > > I feel the coloring of the documentation page should be more unified - > there is red in the heading, and the icons are blue-ish and green. Yes, we could do something here I agree, perhaps the red menu item should be blue instead? or green? It might fit in better. > Also, the view and download icons don't match well in their style. And > maybe add some space vertically between the table rows (GLib / GObject / > Pango / ...) to not have it be one overwhelming "block". I know what you mean. Perhaps the 2.x API tables could be side by side to help that? > I wonder where the GTK logo proposal went? I think it would fit quite > well in this design. Actually Andreas was doing some work there. I was sent a few ideas and they looked good, but nothing further so far. -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review
On Mon, 2007-05-28 at 19:15 +0100, Martyn Russell wrote: > * What are people's thoughts on the initial look and feel? It looks great, except for the FAQ. Can it be styled similarly to the rest of the site and include the navigation bar at the top? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review
Murray Cumming wrote: > On Mon, 2007-05-28 at 19:15 +0100, Martyn Russell wrote: >> Hi, >> >> Over the last few weeks, I have spent time putting together the new >> website for gtk.org. I decided it would be easier to start from scratch >> reusing the original content. >> >> I have put the new pages up here for review: >> >> http://www.imendio.com/~martyn/gtk/ >> >> The content is my primary interest, but if you have style queries or >> comments they are also welcome. > [snip] > > It's generally nice. Well done. > > For pages where you've gathered various miscellaneous stuff together, > such as > http://www.imendio.com/~martyn/gtk/features.html I wouldn't say it was miscellaneous. The whole point of that page is to summarise all the features that you might want to know about when choosing a tool kit. Perhaps some parts need re-wording to make that more obvious? > I think some sub-menu would be useful. Otherwise people won't easily > find information such as the list of language bindings. Hmm, well, I personally am not a big fan of too many menus. I think simplicity for the web pages is quite important here, and another menu just adds clutter to a page which isn't actually that big anyway. > More importantly, I'd rather not have "Gimp Toolkit" in the page > heading. For me that's a bit like having "GNU Network Object Model > Environment" on a GNOME page. It's not relevant, it's distracting, and > it's a bit tacky. It's already mentioned on the About page. This is true, and I would have gone for just GTK+ but it is awfully short for a title. Perhaps something like "The GTK+ Project"? -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review
gege2061 wrote: > Martyn Russell a écrit : >> * Have I missed anything? >> >> > Hi, Hi, > I regulary use GTK+ web site for access to documents pages. I think > redirections of the http://www.gtk.org/api/xxx/ addresses towards > http://developer.gnome.org/doc/API/2.0/xxx/index.html would be very > practical! That does sounds like a good idea actually. Thanks. -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Martyn, Martyn Russell wrote: > Hi, > > Over the last few weeks, I have spent time putting together the new > website for gtk.org. I decided it would be easier to start from scratch > reusing the original content. > > I have put the new pages up here for review: > > http://www.imendio.com/~martyn/gtk/ > > The content is my primary interest, but if you have style queries or > comments they are also welcome. Great work! This is the way to go, it looks great generally. Thanks too for the clean HTML source. Now come the "bad news" :) I will purely comment on style here. So, at first sight, the page looked a bit "empty". It was just a feeling of "something is missing". I think the Inkscape website had it, but http://winehq.org/ still has it - a screenshot on the front page, something representative besides just a logo. I think another source of that feeling comes from the text color - just use black please. Make it as easy on the eyes as possible, so black is *the* color for normal paragraphs. Also, the WineHQ page (at least the main page) has a reddish color theme. Maybe use (GTK logo) colors for headings? Something like dark (!) green for description pages (Overview, Features, About), blue for downloadable stuff (Download, Screenshots), and red for in-depth / development pages (Development). I would put the FAQ in the last category, but I'm not too sure. I feel the coloring of the documentation page should be more unified - there is red in the heading, and the icons are blue-ish and green. Also, the view and download icons don't match well in their style. And maybe add some space vertically between the table rows (GLib / GObject / Pango / ...) to not have it be one overwhelming "block". I wonder where the GTK logo proposal went? I think it would fit quite well in this design. Now, I won't make my language exams in June now (but in September), so I have time left sooner for helping out here. I'm a bit busy with other things, but I can lend a hand still. Greetings, Felix PS: I'm new to message-signing. I don't normally see people sign their messages. Is it bad etiquette to use them on mailing lists? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGW1P6lW86h1QHmOcRAt8cAKCxp4jkylM+urLU9WHPJ/2DJv3pSwCeLMP4 o+Dn+ti/SHD1lFbrmH32ueU= =L1df -END PGP SIGNATURE- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkTextLayout users
Hi guys, There is an idea to make most of semi-private stuff in GtkTextLayout and friends really private. I did some search (and will do more), and looked at GnomeCanvas, and apparently only the list below is used (and needs to be exported). The stuff below is "normal api", i.e. api which is needed by folks who use GtkTextLayout in a canvas (perhaps somewhere else?). Problem is that there is also lot of stuff exposed which isn't used by anyone (apparently), and requires backwards-incompatible changes (see bug #435405 for example). For instance, GtkTextLayoutClass is public though nobody extends GtkTextLayout; GtkTextLayout is public and has lot of fields of which only default_style is used; GtkTextCursorDisplay and GtkTextLineDisplay are public though they are used only internally for drawing. So, are there GtkTextLayout users who use more than GnomeCanvas does? API used outside gtk: GtkTextLayout.default_style. gtk_text_layout_get_type() (and type macros), gtk_text_layout_new(), gtk_text_layout_default_style_changed(), gtk_text_layout_set_cursor_visible(), gtk_text_layout_get_cursor_visible(), gtk_text_layout_get_cursor_locations(), gtk_text_layout_validate(), gtk_text_layout_validate_yrange(), gtk_text_layout_get_size(), gtk_text_layout_set_buffer(), gtk_text_layout_set_screen_width(), gtk_text_layout_set_contexts(), gtk_text_layout_set_default_style(), gtk_text_layout_draw(), gtk_text_layout_move_iter_to_previous_line(), gtk_text_layout_move_iter_visually(), gtk_text_layout_move_iter_to_x(), gtk_text_layout_move_iter_to_line_end(), gtk_text_layout_get_iter_at_pixel(), gtk_text_layout_iter_starts_line(), gtk_text_layout_get_iter_location(), Best regards, Yevgen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review
Martyn Russell a écrit : > * Have I missed anything? > > Hi, I regulary use GTK+ web site for access to documents pages. I think redirections of the http://www.gtk.org/api/xxx/ addresses towards http://developer.gnome.org/doc/API/2.0/xxx/index.html would be very practical! If you are interested by French documentations, here a site to complete your documentation page : http://gtk.developpez.com (tutorials, FAQ, forum, ...) Regards, -- Nicolas Joseph Responsable de la rubrique GTK+, C & C++ de developpez.com http://nicolasj.developpez.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Common widget for choosing file formats
Am Montag, den 28.05.2007, 06:27 -0400 schrieb Freddie Unpenstein: > A tabless notebook beneath the format selector can probably handle the > most common basic extra options in many cases, ... Well, but guess this should be handled by applications themself. The file chooser dialog as a "set_extra_widget" method for that purpose. > One issue, is handling of formats supported already within GTK... Good idea added support for saveable GdkPixbuf formats. > Based on that structure, the files shown in the save dialog could be > filtered by type, first off. This would be standard behaviour > provided automatically by the save dialog. Trying to follow you. Am I understanding right, that you propose to provide an API for automatically adding filters to file choosers, when adding a file-format chooser? Sounds like a good idea, but considering that I've designed the format chooser as separate widget, I have no clue for a nice API to link both widgets. Chooses I see: 1) Automatically let the file chooser link them, when gtk_file_chooser_set_extra_widget is called with a GtkFileFormatChooser. 2) Automatically let the format chooser link them, when the file format chooser is added to some file chooser. 3) Provide some format-chooser-method replacing set_extra_widget and linking the widgets. Ciao, Mathias -- Mathias Hasselmann <[EMAIL PROTECTED]> http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review
On Mon, 2007-05-28 at 19:15 +0100, Martyn Russell wrote: > Hi, > > Over the last few weeks, I have spent time putting together the new > website for gtk.org. I decided it would be easier to start from scratch > reusing the original content. > > I have put the new pages up here for review: > > http://www.imendio.com/~martyn/gtk/ > > The content is my primary interest, but if you have style queries or > comments they are also welcome. [snip] It's generally nice. Well done. For pages where you've gathered various miscellaneous stuff together, such as http://www.imendio.com/~martyn/gtk/features.html I think some sub-menu would be useful. Otherwise people won't easily find information such as the list of language bindings. More importantly, I'd rather not have "Gimp Toolkit" in the page heading. For me that's a bit like having "GNU Network Object Model Environment" on a GNOME page. It's not relevant, it's distracting, and it's a bit tacky. It's already mentioned on the About page. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ Website Review
Hi, Over the last few weeks, I have spent time putting together the new website for gtk.org. I decided it would be easier to start from scratch reusing the original content. I have put the new pages up here for review: http://www.imendio.com/~martyn/gtk/ The content is my primary interest, but if you have style queries or comments they are also welcome. Issues outstanding: * The about page currently has several issues I would like to resolve before I would say it is complete. The main one being that the "Other credits" section lists (not comprehensively) contributors of important parts of GTK+. I don't think it makes sense to include it. What do others think? * The GTK+ team on the about page is out of date. We have the same issue with the FAQ and again with the AUTHORS file in the repository. I briefly discussed this with Tim Janik and we couldn't completely agree here. I personally think we should have a named team which are the established GTK+ team. Tim's point was that this changes quite often and mostly unrealistic. I think having this is vitally important for a project so the community have a body to turn to which is responsible. Maybe I am wrong? Either way, we need to synchronise these in one place I think. Naming people in the FAQ is pointless, it is updated even less frequently than the website. * The overview page lists the latest news items and I trimmed it down because it was quite long. I wonder if should only have the last 5 items? Also on the old pages we had news listings back to the beginning of time. I haven't done this due to the time it would take and those sort of things are always available in the archives. Does anyone disagree here? * Should the FAQ be JUST available in the website module? At the moment, we have to take that file and build the html and move it somewhere else to make sure it is visible for the website, it might make life easier if it was part of the same module. * I have added a section called "Support" to the Development page which is supposed to be for customers wanting to submit funds or man power into the project to have some clear direction and way forward to do that. I have added a link to the gnome-foundation mailing list, is there anything else we can do here? * Are we going to provide binary packages for Windows or OS X? I think we should state clearly what we are going to do here on the downloads page. I just used the last text which said Windows packages are coming soon, is this true? Perhaps we could link to Tor's page here OR perhaps Tor's page should be hosted at gtk.org? The first time I tried to get GTK+ working on Windows, I expected gtk.org to be the place to visit and it wasn't. * Should we add some information about getting GTK+ working on Windows and OS X on the development page (like the building Evolution on Windows HOWTO Tor wrote or the building Loudmouth on Windows HOWTO I wrote)? Having this information on the main site could eliminate a lot of questions posted to the mailing lists. * Have I missed anything? * What are people's thoughts on the initial look and feel? -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+/glib versions for GNOME 2.20
On Mon, 2007-05-28 at 16:12 +0200, Vincent Untz wrote: > Le mardi 15 mai 2007, à 15:05 +0200, Vincent Untz a écrit : > > Hi, > > > > In [1], Tim mentioned that the current plan was to release GTK+ 2.12 > > mid-June. Is this still the case or do you expect a delay? This would be > > useful to know, so we can tell people that it's okay to use the new GTK+ > > features. > > > > And any idea about glib 2.14? I guess if GTK+ 2.12 will be ready, the > > new glib will be ready too. > > > > (FWIW, Behdad told on IRC that he expects GNOME 2.20 to use pango 1.18) > > Since the release dates for GTK+ 2.12 and glib 2.14 are now post-GUADEC > and it's probably not a good idea to put pressure on the GTK+ team, I > believe it's better to stay with GTK+ 2.10/glib 2.12 for GNOME 2.20. > > If there's no objection, the release team will announce this in a few > days. If this happens, I hope that GTK+ will not then be frozen before GNOME 2.21/2.22 development has really started, or else the new GTK+ API will be frozen before it is tested. Synchronization with the GNOME release schedule would be best. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: XShmPixmap for GdkPixmap
On Wed, 2007-05-23 at 15:36 -0400, Owen Taylor wrote: > On Wed, 2007-05-23 at 15:12 -0400, Tristan Van Berkom wrote: > > > Something like this ? > > > > GdkPixmap * > > gdk_pixmap_new_shared (GdkDrawable *drawable, > > gint width, > > gint height, > > gint depth, > > GdkImage **image_ret) > > > > This way one could be specific about when using an XShmPixmap > > suits thier need, which is good enough for me. > > Multiple returns, ugh :-) > > Maybe just: > > GdkPixmap * > gdk_image_get_shared_pixmap(GdkImage *image); > Ok I tried all this out and its working nicely, I taylored a patch and posted it here: http://bugzilla.gnome.org/show_bug.cgi?id=441853 Hoping to hear feedback soon :) Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+/glib versions for GNOME 2.20
Le mardi 15 mai 2007, à 15:05 +0200, Vincent Untz a écrit : > Hi, > > In [1], Tim mentioned that the current plan was to release GTK+ 2.12 > mid-June. Is this still the case or do you expect a delay? This would be > useful to know, so we can tell people that it's okay to use the new GTK+ > features. > > And any idea about glib 2.14? I guess if GTK+ 2.12 will be ready, the > new glib will be ready too. > > (FWIW, Behdad told on IRC that he expects GNOME 2.20 to use pango 1.18) Since the release dates for GTK+ 2.12 and glib 2.14 are now post-GUADEC and it's probably not a good idea to put pressure on the GTK+ team, I believe it's better to stay with GTK+ 2.10/glib 2.12 for GNOME 2.20. If there's no objection, the release team will announce this in a few days. Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Common widget for choosing file formats
format = egg_file_format_new (_("Scalable Vector Graphics
(SVG)"), "svg", NULL);
>>> That may be a bit short for container formats, which must handle
>>> subformats (e.g. AVI with different audio/video codecs).
>> Definitly didn't have this case in mind, and maybe its out of
>> scope for a _common_ widget
> Agreed. After all applications needing to choose a codec will want
> to specify a bitrate and some other settings, way out of scope for
> your generic widget. A simple format name with an optional icon
> should be ok.
There's no reason the standard save dialog can't still have a widget for
format. Sure, extra format-specific settings still need to be provided for,
but that's only an issue where the application supports those extra settings.
And container sub-formats don't matter much when the application only has one
or two formats that it's capable of saving in.
A tabless notebook beneath the format selector can probably handle the most
common basic extra options in many cases, with an "Advanced" button for more.
Or, do as GIMP does, and just bring up a secondary dialog with the full range
of options for that format.
One issue, is handling of formats supported already within GTK. Using only GTK
(GDK actually, I think?) alone, there are several formats I can save a raw
image in, for example. So GTK needs to have a list of formats provided by its
built in image handling, ready for inclusion in such a list. Selecting a
format would emit a signal that includes a pointer (or other information) to a
structure with information about that format. An application could, for
example, run through the standard list, setting or clearing a flag on each
format indicating whether it should be included or not (since the list isn't
likely to change during an applications run). It could also add extra formats
it supports to the standard list.
Based on that structure, the files shown in the save dialog could be filtered
by type, first off. This would be standard behaviour provided automatically by
the save dialog. Then, if basic options are provided for also within the
dialog, that same signal would cause the relevant page of an embedded tabless
GtkNotebook to be shown (after loading/constructing the page as needs be).
Especially viable once the GtkBuilder stuff is worked out, allowing the
equivelant of a glade file to be distributed, that gets loaded and parsed
automatically the first time it's needed.
But whether specific options are provided for savable formats or not, the file
filtering is a "good thing!", as is the signal that allows the application to
do whatever they'd like to do instead (including nothing, if they want to jump
straight to the advanced options). And if you don't like it, allow it to be
optional, especially during the early releases (a little option in a
right-click menu to turn it off if it's hiding files it shouldn't be, is all
that's needed).
I for one would welcome development in this direction. I can't remember how
many times it's frustrated me digging through a long directory listing for the
file I want, more-so in load dialogs, but also when I've wanted to over-write a
file with new fresh content I'd just pasted into the application.
Fredderic
___
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
