[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-gnubg] Status: Filerequesters in GTK+ 2.6

From: macherius
Subject: [Bug-gnubg] Status: Filerequesters in GTK+ 2.6
Date: Fri, 11 Feb 2005 18:02:18 +0100

I've looked into improving the GUI w/r to file requesters for import and
export, here are the findings so far.

1. File Dialogs in GTK 2.6

There are 3 useable Widgets in 2.6:
GtkFileChooserButton - A button to launch a file selection dialog
GtkFileChooserDialog - A file chooser dialog, suitable for "File/Open" or
"File/Save" commands
GtkFileChooserWidget - File chooser widget that can be embedded in other
They come in 4 operating flavors, LOAD, SAVE, SELECT_FOLDER and
CREATE_FOLDER, which differ quite a bit w/r to layout.

I have my problems with the paradigm used in SAVE, it differs quite a bit
from traditional dialogs we all know and love from e.g. Windows. E.g. it has
the line with the filename above the typical tree view of files and dirs.
Furthermore it starts with the latter collapsed, making it hard to size a
window correctly. You have a large, unused grey area (collapsed state) when
you try to imitate a classic windows style dialog. Maybe I just don't get
the point new paradigm, but it's different for sure.

All Dialogs are multiselect by default, Oystein pointed out that this should
be used for gnubg and I fully agree. Nice new feature for free.

2. Glade and GTK 2.6

The only version fully supporting GTK 2.6 is Glade 2.9 beta, released just
this month. There is not windows build so far, I'm currently trying to build
such a beast myself. It is needed because GtkFileChooserButton is not
supported by Glade 2.6.x, the official stable build.

I try to use GtkFileChooserButton rather than GtkFileChooserWidget because I
think it's unwieldy and confusing (see 1).

3. Side effects

Introducing clean file dialogs has 2 side effects:

3.1 Settings -> Paths should be implemented in the course
3.2 File -> Import/Export/Load/save become increasingly superflous

Depending on progress I'll probably tackle these two as well, yielding a
self contained change. I've checked with Oystein, who explained me the
historical background.

4. Code structure

Glade generates 5 main source files:

(1) gtkfilewidgets.c
(2) gtkfilewidgets.h
(3) stkfilewidgetsHandlerSupport.c
(4) stkfilewidgetsHandler.h
(5) stkfilewidgetsHandler.c

The concept is that 1-4 are regenerated from the Glade file everytime you
change a layout, while 5 is reserved (and kept) for user code. I really like
this structure, but it collides with gnubg's current code organization,
where glade output is concatenated in large files by cut/paste. The current
way loses the ability to change code using Glade, so for my taste it's

How is opinion about the following change to the GTK maintainance:

(a) Create a new folder "glade" where all Glade format sources are collected
(b) Accept the file generation paradigm of Glade and only work in *Handler.c

For my part, I'll do it this way while testing, it's up to the CVS
maintainer to change it. But that would be a waste in my opinion. So how is
opinion here, follow glade glade and take change some makefiles rather?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]