nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
f317f8e67e
putty-source/unix/columns.c

1202 lines
36 KiB
C
Raw Normal View History

First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
/*
* gtkcols.c - implementation of the `Columns' GTK layout container.
*/
Add some more miscellaneous asserts. These clarify matters for static checkers (not to mention humans), and seem inexpensive enough not to worry about adding.
2018-12-01 14:13:37 +00:00
#include <assert.h>
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#include <gtk/gtk.h>
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
#include "defs.h"
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
#include "gtkcompat.h"
Rename most of the platform source files. This gets rid of all those annoying 'win', 'ux' and 'gtk' prefixes which made filenames annoying to type and to tab-complete. Also, as with my other recent renaming sprees, I've taken the opportunity to expand and clarify some of the names so that they're not such cryptic abbreviations.
2021-04-23 05:19:05 +00:00
#include "columns.h"
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Stop using deprecated gtk_container_set_focus_chain(). In GTK 2, this function was a new and convenient way to override the order in which the Tab key cycled through the sub-widgets of a container, replacing the more verbose mechanism in GTK 1 where you had to provide a custom implementation of the "focus" method in GtkContainerClass. GTK 3.24 has now deprecated gtk_container_set_focus_chain(), apparently on the grounds that that old system is what they think you _ought_ to be doing. So I've abandoned set_focus_chain completely, and switched back to doing it by a custom focus method for _all_ versions of GTK, with the only slight wrinkle being that between GTK 1 and 2 the method in question moved from GtkContainer to GtkWidget (my guess is so that an individual non-container widget can still have multiple separately focusable UI components).
2018-10-28 09:14:53 +00:00
#if GTK_CHECK_VERSION(2,0,0)
/* The "focus" method lives in GtkWidget from GTK 2 onwards, but it
* was in GtkContainer in GTK 1 */
#define FOCUS_METHOD_SUPERCLASS GtkWidget
#define FOCUS_METHOD_LOCATION widget_class /* used in columns_init */
#define CHILD_FOCUS(cont, dir) gtk_widget_child_focus(GTK_WIDGET(cont), dir)
#else
#define FOCUS_METHOD_SUPERCLASS GtkContainer
#define FOCUS_METHOD_LOCATION container_class
#define CHILD_FOCUS(cont, dir) gtk_container_focus(GTK_CONTAINER(cont), dir)
#endif
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
static void columns_init(Columns *cols);
static void columns_class_init(ColumnsClass *klass);
Memory leak: add a columns_finalize() method. My custom GTK layout class 'Columns' includes a linked list of dynamically allocated data, and apparently I forgot to write a destructor that frees it all when the class is deallocated, and have never noticed until now.
2017-11-26 08:45:45 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
static void columns_finalize(GtkObject *object);
#else
static void columns_finalize(GObject *object);
#endif
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
static void columns_map(GtkWidget *widget);
static void columns_unmap(GtkWidget *widget);
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
static void columns_draw(GtkWidget *widget, GdkRectangle *area);
static gint columns_expose(GtkWidget *widget, GdkEventExpose *event);
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#endif
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
static void columns_base_add(GtkContainer *container, GtkWidget *widget);
static void columns_remove(GtkContainer *container, GtkWidget *widget);
static void columns_forall(GtkContainer *container, gboolean include_internals,
GtkCallback callback, gpointer callback_data);
Stop using deprecated gtk_container_set_focus_chain(). In GTK 2, this function was a new and convenient way to override the order in which the Tab key cycled through the sub-widgets of a container, replacing the more verbose mechanism in GTK 1 where you had to provide a custom implementation of the "focus" method in GtkContainerClass. GTK 3.24 has now deprecated gtk_container_set_focus_chain(), apparently on the grounds that that old system is what they think you _ought_ to be doing. So I've abandoned set_focus_chain completely, and switched back to doing it by a custom focus method for _all_ versions of GTK, with the only slight wrinkle being that between GTK 1 and 2 the method in question moved from GtkContainer to GtkWidget (my guess is so that an individual non-container widget can still have multiple separately focusable UI components).
2018-10-28 09:14:53 +00:00
static gint columns_focus(FOCUS_METHOD_SUPERCLASS *container,
GtkDirectionType dir);
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
static GType columns_child_type(GtkContainer *container);
GTK3 port: replace size_request in the Columns layout class. It's been replaced by a new pair of methods get_preferred_width and get_preferred_height. For the moment, I've followed the porting guide's suggestion of keeping the old size_request function as an underlying implementation and having each of those methods just return one of its outputs. The results are ugly, but it'll compile and run, which is a start.
2015-08-16 13:16:08 +00:00
#if GTK_CHECK_VERSION(3,0,0)
static void columns_get_preferred_width(GtkWidget *widget,
gint *min, gint *nat);
static void columns_get_preferred_height(GtkWidget *widget,
gint *min, gint *nat);
Implement GTK3 height-for-width layout in Columns. Now that I've got the main calculation code separated from the GTK2 size_request and size_allocate top-level methods, I can introduce a completely different set of GTK3 top-level methods, which run the same underlying calculations but based on different width and height information. So now we do proper height-for-width layout, as you can see if you flip the PuTTY config box to a pane with a wrapping label on it (e.g. Fonts or Logging) and resize the window horizontally. Where the GTK2 config box just left the wrapped text label at its original size, and the GTK3 one before this change would reflow the text but without changing the label's height, now the text reflows and the controls below it move up and down when the number of lines of wrapped text changes. (As far as I'm concerned, that's a nice demo of GTK3's new abilities but not a critically important UI feature for this app. The more important point is that switching to the modern layout model removes one of the remaining uses of the deprecated gtk_widget_size_request.)
2015-08-23 13:50:47 +00:00
static void columns_get_preferred_width_for_height(GtkWidget *widget,
gint height,
gint *min, gint *nat);
static void columns_get_preferred_height_for_width(GtkWidget *widget,
gint width,
gint *min, gint *nat);
#else
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
static void columns_size_request(GtkWidget *widget, GtkRequisition *req);
Implement GTK3 height-for-width layout in Columns. Now that I've got the main calculation code separated from the GTK2 size_request and size_allocate top-level methods, I can introduce a completely different set of GTK3 top-level methods, which run the same underlying calculations but based on different width and height information. So now we do proper height-for-width layout, as you can see if you flip the PuTTY config box to a pane with a wrapping label on it (e.g. Fonts or Logging) and resize the window horizontally. Where the GTK2 config box just left the wrapped text label at its original size, and the GTK3 one before this change would reflow the text but without changing the label's height, now the text reflows and the controls below it move up and down when the number of lines of wrapped text changes. (As far as I'm concerned, that's a nice demo of GTK3's new abilities but not a critically important UI feature for this app. The more important point is that switching to the modern layout model removes one of the remaining uses of the deprecated gtk_widget_size_request.)
2015-08-23 13:50:47 +00:00
#endif
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
static void columns_size_allocate(GtkWidget *widget, GtkAllocation *alloc);
static GtkContainerClass *parent_class = NULL;
Another tedious chore off the to-do list. I've just checked over my custom Columns layout class to see what fiddly details of GTK2isation were yet to be done. It turns out that all the basic object management got moved out of GTK into a separate library, so that all the gtk_object_* calls are deprecated and g_object_* should be used instead; having done that, though, it all looks perfectly fine. [originally from svn r7962]
2008-04-02 17:04:21 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
GType columns_get_type(void)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
static GType columns_type = 0;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
if (!columns_type) {
static const GtkTypeInfo columns_info = {
"Columns",
sizeof(Columns),
sizeof(ColumnsClass),
(GtkClassInitFunc) columns_class_init,
(GtkObjectInitFunc) columns_init,
/* reserved_1 */ NULL,
/* reserved_2 */ NULL,
(GtkClassInitFunc) NULL,
};
columns_type = gtk_type_unique(GTK_TYPE_CONTAINER, &columns_info);
}
return columns_type;
}
Another tedious chore off the to-do list. I've just checked over my custom Columns layout class to see what fiddly details of GTK2isation were yet to be done. It turns out that all the basic object management got moved out of GTK into a separate library, so that all the gtk_object_* calls are deprecated and g_object_* should be used instead; having done that, though, it all looks perfectly fine. [originally from svn r7962]
2008-04-02 17:04:21 +00:00
#else
GType columns_get_type(void)
{
static GType columns_type = 0;
if (!columns_type) {
static const GTypeInfo columns_info = {
sizeof(ColumnsClass),
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
NULL,
NULL,
Another tedious chore off the to-do list. I've just checked over my custom Columns layout class to see what fiddly details of GTK2isation were yet to be done. It turns out that all the basic object management got moved out of GTK into a separate library, so that all the gtk_object_* calls are deprecated and g_object_* should be used instead; having done that, though, it all looks perfectly fine. [originally from svn r7962]
2008-04-02 17:04:21 +00:00
(GClassInitFunc) columns_class_init,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
NULL,
NULL,
Another tedious chore off the to-do list. I've just checked over my custom Columns layout class to see what fiddly details of GTK2isation were yet to be done. It turns out that all the basic object management got moved out of GTK into a separate library, so that all the gtk_object_* calls are deprecated and g_object_* should be used instead; having done that, though, it all looks perfectly fine. [originally from svn r7962]
2008-04-02 17:04:21 +00:00
sizeof(Columns),
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
0,
Another tedious chore off the to-do list. I've just checked over my custom Columns layout class to see what fiddly details of GTK2isation were yet to be done. It turns out that all the basic object management got moved out of GTK into a separate library, so that all the gtk_object_* calls are deprecated and g_object_* should be used instead; having done that, though, it all looks perfectly fine. [originally from svn r7962]
2008-04-02 17:04:21 +00:00
(GInstanceInitFunc)columns_init,
};
columns_type = g_type_register_static(GTK_TYPE_CONTAINER, "Columns",
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
&columns_info, 0);
Another tedious chore off the to-do list. I've just checked over my custom Columns layout class to see what fiddly details of GTK2isation were yet to be done. It turns out that all the basic object management got moved out of GTK into a separate library, so that all the gtk_object_* calls are deprecated and g_object_* should be used instead; having done that, though, it all looks perfectly fine. [originally from svn r7962]
2008-04-02 17:04:21 +00:00
}
return columns_type;
}
#endif
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Stop using deprecated gtk_container_set_focus_chain(). In GTK 2, this function was a new and convenient way to override the order in which the Tab key cycled through the sub-widgets of a container, replacing the more verbose mechanism in GTK 1 where you had to provide a custom implementation of the "focus" method in GtkContainerClass. GTK 3.24 has now deprecated gtk_container_set_focus_chain(), apparently on the grounds that that old system is what they think you _ought_ to be doing. So I've abandoned set_focus_chain completely, and switched back to doing it by a custom focus method for _all_ versions of GTK, with the only slight wrinkle being that between GTK 1 and 2 the method in question moved from GtkContainer to GtkWidget (my guess is so that an individual non-container widget can still have multiple separately focusable UI components).
2018-10-28 09:14:53 +00:00
static gint (*columns_inherited_focus)(FOCUS_METHOD_SUPERCLASS *container,
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GtkDirectionType direction);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
static void columns_class_init(ColumnsClass *klass)
{
Another tedious chore off the to-do list. I've just checked over my custom Columns layout class to see what fiddly details of GTK2isation were yet to be done. It turns out that all the basic object management got moved out of GTK into a separate library, so that all the gtk_object_* calls are deprecated and g_object_* should be used instead; having done that, though, it all looks perfectly fine. [originally from svn r7962]
2008-04-02 17:04:21 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
Memory leak: add a columns_finalize() method. My custom GTK layout class 'Columns' includes a linked list of dynamically allocated data, and apparently I forgot to write a destructor that frees it all when the class is deallocated, and have never noticed until now.
2017-11-26 08:45:45 +00:00
GtkObjectClass *object_class = (GtkObjectClass *)klass;
Another tedious chore off the to-do list. I've just checked over my custom Columns layout class to see what fiddly details of GTK2isation were yet to be done. It turns out that all the basic object management got moved out of GTK into a separate library, so that all the gtk_object_* calls are deprecated and g_object_* should be used instead; having done that, though, it all looks perfectly fine. [originally from svn r7962]
2008-04-02 17:04:21 +00:00
GtkWidgetClass *widget_class = (GtkWidgetClass *)klass;
GtkContainerClass *container_class = (GtkContainerClass *)klass;
#else
Memory leak: add a columns_finalize() method. My custom GTK layout class 'Columns' includes a linked list of dynamically allocated data, and apparently I forgot to write a destructor that frees it all when the class is deallocated, and have never noticed until now.
2017-11-26 08:45:45 +00:00
GObjectClass *object_class = G_OBJECT_CLASS(klass);
Another tedious chore off the to-do list. I've just checked over my custom Columns layout class to see what fiddly details of GTK2isation were yet to be done. It turns out that all the basic object management got moved out of GTK into a separate library, so that all the gtk_object_* calls are deprecated and g_object_* should be used instead; having done that, though, it all looks perfectly fine. [originally from svn r7962]
2008-04-02 17:04:21 +00:00
GtkWidgetClass *widget_class = GTK_WIDGET_CLASS(klass);
GtkContainerClass *container_class = GTK_CONTAINER_CLASS(klass);
#endif
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Another tedious chore off the to-do list. I've just checked over my custom Columns layout class to see what fiddly details of GTK2isation were yet to be done. It turns out that all the basic object management got moved out of GTK into a separate library, so that all the gtk_object_* calls are deprecated and g_object_* should be used instead; having done that, though, it all looks perfectly fine. [originally from svn r7962]
2008-04-02 17:04:21 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
parent_class = gtk_type_class(GTK_TYPE_CONTAINER);
Reinstate all the GTK1-specific code under ifdefs, and verify that we can now build and run successfully using both GTK1 and GTK2 by giving appropriate options to make. (Specifically, to override the default of GTK2 in favour of GTK1, "make GTK_CONFIG=gtk-config".) [originally from svn r7966]
2008-04-04 10:56:26 +00:00
#else
parent_class = g_type_class_peek_parent(klass);
Another tedious chore off the to-do list. I've just checked over my custom Columns layout class to see what fiddly details of GTK2isation were yet to be done. It turns out that all the basic object management got moved out of GTK into a separate library, so that all the gtk_object_* calls are deprecated and g_object_* should be used instead; having done that, though, it all looks perfectly fine. [originally from svn r7962]
2008-04-02 17:04:21 +00:00
#endif
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Memory leak: add a columns_finalize() method. My custom GTK layout class 'Columns' includes a linked list of dynamically allocated data, and apparently I forgot to write a destructor that frees it all when the class is deallocated, and have never noticed until now.
2017-11-26 08:45:45 +00:00
object_class->finalize = columns_finalize;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
widget_class->map = columns_map;
widget_class->unmap = columns_unmap;
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
widget_class->draw = columns_draw;
widget_class->expose_event = columns_expose;
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#endif
GTK3 port: replace size_request in the Columns layout class. It's been replaced by a new pair of methods get_preferred_width and get_preferred_height. For the moment, I've followed the porting guide's suggestion of keeping the old size_request function as an underlying implementation and having each of those methods just return one of its outputs. The results are ugly, but it'll compile and run, which is a start.
2015-08-16 13:16:08 +00:00
#if GTK_CHECK_VERSION(3,0,0)
widget_class->get_preferred_width = columns_get_preferred_width;
widget_class->get_preferred_height = columns_get_preferred_height;
Implement GTK3 height-for-width layout in Columns. Now that I've got the main calculation code separated from the GTK2 size_request and size_allocate top-level methods, I can introduce a completely different set of GTK3 top-level methods, which run the same underlying calculations but based on different width and height information. So now we do proper height-for-width layout, as you can see if you flip the PuTTY config box to a pane with a wrapping label on it (e.g. Fonts or Logging) and resize the window horizontally. Where the GTK2 config box just left the wrapped text label at its original size, and the GTK3 one before this change would reflow the text but without changing the label's height, now the text reflows and the controls below it move up and down when the number of lines of wrapped text changes. (As far as I'm concerned, that's a nice demo of GTK3's new abilities but not a critically important UI feature for this app. The more important point is that switching to the modern layout model removes one of the remaining uses of the deprecated gtk_widget_size_request.)
2015-08-23 13:50:47 +00:00
widget_class->get_preferred_width_for_height =
columns_get_preferred_width_for_height;
widget_class->get_preferred_height_for_width =
columns_get_preferred_height_for_width;
GTK3 port: replace size_request in the Columns layout class. It's been replaced by a new pair of methods get_preferred_width and get_preferred_height. For the moment, I've followed the porting guide's suggestion of keeping the old size_request function as an underlying implementation and having each of those methods just return one of its outputs. The results are ugly, but it'll compile and run, which is a start.
2015-08-16 13:16:08 +00:00
#else
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
widget_class->size_request = columns_size_request;
GTK3 port: replace size_request in the Columns layout class. It's been replaced by a new pair of methods get_preferred_width and get_preferred_height. For the moment, I've followed the porting guide's suggestion of keeping the old size_request function as an underlying implementation and having each of those methods just return one of its outputs. The results are ugly, but it'll compile and run, which is a start.
2015-08-16 13:16:08 +00:00
#endif
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
widget_class->size_allocate = columns_size_allocate;
container_class->add = columns_base_add;
container_class->remove = columns_remove;
container_class->forall = columns_forall;
container_class->child_type = columns_child_type;
Stop using deprecated gtk_container_set_focus_chain(). In GTK 2, this function was a new and convenient way to override the order in which the Tab key cycled through the sub-widgets of a container, replacing the more verbose mechanism in GTK 1 where you had to provide a custom implementation of the "focus" method in GtkContainerClass. GTK 3.24 has now deprecated gtk_container_set_focus_chain(), apparently on the grounds that that old system is what they think you _ought_ to be doing. So I've abandoned set_focus_chain completely, and switched back to doing it by a custom focus method for _all_ versions of GTK, with the only slight wrinkle being that between GTK 1 and 2 the method in question moved from GtkContainer to GtkWidget (my guess is so that an individual non-container widget can still have multiple separately focusable UI components).
2018-10-28 09:14:53 +00:00
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
/* Save the previous value of this method. */
if (!columns_inherited_focus)
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
columns_inherited_focus = FOCUS_METHOD_LOCATION->focus;
Stop using deprecated gtk_container_set_focus_chain(). In GTK 2, this function was a new and convenient way to override the order in which the Tab key cycled through the sub-widgets of a container, replacing the more verbose mechanism in GTK 1 where you had to provide a custom implementation of the "focus" method in GtkContainerClass. GTK 3.24 has now deprecated gtk_container_set_focus_chain(), apparently on the grounds that that old system is what they think you _ought_ to be doing. So I've abandoned set_focus_chain completely, and switched back to doing it by a custom focus method for _all_ versions of GTK, with the only slight wrinkle being that between GTK 1 and 2 the method in question moved from GtkContainer to GtkWidget (my guess is so that an individual non-container widget can still have multiple separately focusable UI components).
2018-10-28 09:14:53 +00:00
FOCUS_METHOD_LOCATION->focus = columns_focus;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
static void columns_init(Columns *cols)
{
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
gtk_widget_set_has_window(GTK_WIDGET(cols), false);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
cols->children = NULL;
cols->spacing = 0;
}
Memory leak: add a columns_finalize() method. My custom GTK layout class 'Columns' includes a linked list of dynamically allocated data, and apparently I forgot to write a destructor that frees it all when the class is deallocated, and have never noticed until now.
2017-11-26 08:45:45 +00:00
static void columns_child_free(gpointer vchild)
{
ColumnsChild *child = (ColumnsChild *)vchild;
if (child->percentages)
g_free(child->percentages);
g_free(child);
}
static void columns_finalize(
#if !GTK_CHECK_VERSION(2,0,0)
GtkObject *object
#else
GObject *object
#endif
)
{
Columns *cols;
g_return_if_fail(object != NULL);
g_return_if_fail(IS_COLUMNS(object));
cols = COLUMNS(object);
#if !GTK_CHECK_VERSION(2,0,0)
{
GList *node;
for (node = cols->children; node; node = node->next)
if (node->data)
columns_child_free(node->data);
}
g_list_free(cols->children);
#else
g_list_free_full(cols->children, columns_child_free);
#endif
cols->children = NULL;
#if !GTK_CHECK_VERSION(2,0,0)
GTK_OBJECT_CLASS(parent_class)->finalize(object);
#else
G_OBJECT_CLASS(parent_class)->finalize(object);
#endif
}
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
/*
* These appear to be thoroughly tedious functions; the only reason
* we have to reimplement them at all is because we defined our own
* format for our GList of children...
*/
static void columns_map(GtkWidget *widget)
{
Columns *cols;
ColumnsChild *child;
GList *children;
g_return_if_fail(widget != NULL);
g_return_if_fail(IS_COLUMNS(widget));
cols = COLUMNS(widget);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
gtk_widget_set_mapped(GTK_WIDGET(cols), true);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
for (children = cols->children;
children && (child = children->data);
children = children->next) {
if (child->widget &&
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_widget_get_visible(child->widget) &&
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
!gtk_widget_get_mapped(child->widget))
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
gtk_widget_map(child->widget);
}
}
static void columns_unmap(GtkWidget *widget)
{
Columns *cols;
ColumnsChild *child;
GList *children;
g_return_if_fail(widget != NULL);
g_return_if_fail(IS_COLUMNS(widget));
cols = COLUMNS(widget);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
gtk_widget_set_mapped(GTK_WIDGET(cols), false);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
for (children = cols->children;
children && (child = children->data);
children = children->next) {
if (child->widget &&
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
gtk_widget_get_visible(child->widget) &&
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
gtk_widget_get_mapped(child->widget))
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
gtk_widget_unmap(child->widget);
}
}
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
static void columns_draw(GtkWidget *widget, GdkRectangle *area)
{
Columns *cols;
ColumnsChild *child;
GList *children;
GdkRectangle child_area;
g_return_if_fail(widget != NULL);
g_return_if_fail(IS_COLUMNS(widget));
if (GTK_WIDGET_DRAWABLE(widget)) {
cols = COLUMNS(widget);
for (children = cols->children;
children && (child = children->data);
children = children->next) {
if (child->widget &&
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GTK_WIDGET_DRAWABLE(child->widget) &&
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
gtk_widget_intersect(child->widget, area, &child_area))
gtk_widget_draw(child->widget, &child_area);
}
}
}
static gint columns_expose(GtkWidget *widget, GdkEventExpose *event)
{
Columns *cols;
ColumnsChild *child;
GList *children;
GdkEventExpose child_event;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
g_return_val_if_fail(widget != NULL, false);
g_return_val_if_fail(IS_COLUMNS(widget), false);
g_return_val_if_fail(event != NULL, false);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
if (GTK_WIDGET_DRAWABLE(widget)) {
cols = COLUMNS(widget);
child_event = *event;
for (children = cols->children;
children && (child = children->data);
children = children->next) {
if (child->widget &&
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
GTK_WIDGET_DRAWABLE(child->widget) &&
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
GTK_WIDGET_NO_WINDOW(child->widget) &&
gtk_widget_intersect(child->widget, &event->area,
&child_event.area))
gtk_widget_event(child->widget, (GdkEvent *)&child_event);
}
}
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
return false;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
Commit Colin Watson's original GTK2 patch, exactly as mailed to me on 1st January except that I've had to fiddle with it a bit to take account of r7117 having happened since then. [originally from svn r7157] [r7117 == 174bb7f1fd1b1a4823905ca931eec67ab0fc9976]
2007-01-25 19:33:29 +00:00
#endif
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
static void columns_base_add(GtkContainer *container, GtkWidget *widget)
{
Columns *cols;
g_return_if_fail(container != NULL);
g_return_if_fail(IS_COLUMNS(container));
g_return_if_fail(widget != NULL);
cols = COLUMNS(container);
/*
* Default is to add a new widget spanning all columns.
*/
columns_add(cols, widget, 0, 0); /* 0 means ncols */
}
static void columns_remove(GtkContainer *container, GtkWidget *widget)
{
Columns *cols;
ColumnsChild *child;
GtkWidget *childw;
GList *children;
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool was_visible;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
g_return_if_fail(container != NULL);
g_return_if_fail(IS_COLUMNS(container));
g_return_if_fail(widget != NULL);
cols = COLUMNS(container);
for (children = cols->children;
children && (child = children->data);
children = children->next) {
if (child->widget != widget)
continue;
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
was_visible = gtk_widget_get_visible(widget);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
gtk_widget_unparent(widget);
cols->children = g_list_remove_link(cols->children, children);
g_list_free(children);
New Columns method, columns_force_same_height(). This forces two child widgets of a Columns to occupy the same amount of vertical space, and if one is really shorter than the other, vertically centres it in the extra space.
2015-08-24 18:23:32 +00:00
if (child->same_height_as) {
g_return_if_fail(child->same_height_as->same_height_as == child);
child->same_height_as->same_height_as = NULL;
if (gtk_widget_get_visible(child->same_height_as->widget))
gtk_widget_queue_resize(GTK_WIDGET(container));
}
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
g_free(child);
if (was_visible)
gtk_widget_queue_resize(GTK_WIDGET(container));
break;
}
for (children = cols->taborder;
children && (childw = children->data);
children = children->next) {
if (childw != widget)
continue;
cols->taborder = g_list_remove_link(cols->taborder, children);
g_list_free(children);
break;
}
}
static void columns_forall(GtkContainer *container, gboolean include_internals,
GtkCallback callback, gpointer callback_data)
{
Columns *cols;
ColumnsChild *child;
Fix a _very_ subtle segfault in my two GTK container classes: the `forall' function has to be prepared for the list of widgets to change along the way if (for example) the callback function destroys its input widget. [originally from svn r3029]
2003-03-31 11:22:06 +00:00
GList *children, *next;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
g_return_if_fail(container != NULL);
g_return_if_fail(IS_COLUMNS(container));
g_return_if_fail(callback != NULL);
cols = COLUMNS(container);
for (children = cols->children;
children && (child = children->data);
Fix a _very_ subtle segfault in my two GTK container classes: the `forall' function has to be prepared for the list of widgets to change along the way if (for example) the callback function destroys its input widget. [originally from svn r3029]
2003-03-31 11:22:06 +00:00
children = next) {
/*
* We can't wait until after the callback to assign
* `children = children->next', because the callback might
* be gtk_widget_destroy, which would remove the link
* `children' from the list! So instead we must get our
* hands on the value of the `next' pointer _before_ the
* callback.
*/
next = children->next;
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (child->widget)
callback(child->widget, callback_data);
Fix a _very_ subtle segfault in my two GTK container classes: the `forall' function has to be prepared for the list of widgets to change along the way if (for example) the callback function destroys its input widget. [originally from svn r3029]
2003-03-31 11:22:06 +00:00
}
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
GTK 3 prep: use the glib names for base object types. All the things like GtkType, GtkObject, gtk_signal_connect and so on should now consistently have the new-style glib names like GType, GObject, g_signal_connect, etc.
2015-08-08 16:29:02 +00:00
static GType columns_child_type(GtkContainer *container)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
return GTK_TYPE_WIDGET;
}
GtkWidget *columns_new(gint spacing)
{
Columns *cols;
Another tedious chore off the to-do list. I've just checked over my custom Columns layout class to see what fiddly details of GTK2isation were yet to be done. It turns out that all the basic object management got moved out of GTK into a separate library, so that all the gtk_object_* calls are deprecated and g_object_* should be used instead; having done that, though, it all looks perfectly fine. [originally from svn r7962]
2008-04-02 17:04:21 +00:00
#if !GTK_CHECK_VERSION(2,0,0)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
cols = gtk_type_new(columns_get_type());
Another tedious chore off the to-do list. I've just checked over my custom Columns layout class to see what fiddly details of GTK2isation were yet to be done. It turns out that all the basic object management got moved out of GTK into a separate library, so that all the gtk_object_* calls are deprecated and g_object_* should be used instead; having done that, though, it all looks perfectly fine. [originally from svn r7962]
2008-04-02 17:04:21 +00:00
#else
cols = g_object_new(TYPE_COLUMNS, NULL);
#endif
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
cols->spacing = spacing;
return GTK_WIDGET(cols);
}
void columns_set_cols(Columns *cols, gint ncols, const gint *percentages)
{
ColumnsChild *childdata;
gint i;
g_return_if_fail(cols != NULL);
g_return_if_fail(IS_COLUMNS(cols));
g_return_if_fail(ncols > 0);
g_return_if_fail(percentages != NULL);
childdata = g_new(ColumnsChild, 1);
childdata->widget = NULL;
childdata->ncols = ncols;
childdata->percentages = g_new(gint, ncols);
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
childdata->force_left = false;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
for (i = 0; i < ncols; i++)
childdata->percentages[i] = percentages[i];
cols->children = g_list_append(cols->children, childdata);
}
void columns_add(Columns *cols, GtkWidget *child,
gint colstart, gint colspan)
{
ColumnsChild *childdata;
g_return_if_fail(cols != NULL);
g_return_if_fail(IS_COLUMNS(cols));
g_return_if_fail(child != NULL);
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
g_return_if_fail(gtk_widget_get_parent(child) == NULL);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
childdata = g_new(ColumnsChild, 1);
childdata->widget = child;
childdata->colstart = colstart;
childdata->colspan = colspan;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
childdata->force_left = false;
New Columns method, columns_force_same_height(). This forces two child widgets of a Columns to occupy the same amount of vertical space, and if one is really shorter than the other, vertically centres it in the extra space.
2015-08-24 18:23:32 +00:00
childdata->same_height_as = NULL;
Memory leak: add a columns_finalize() method. My custom GTK layout class 'Columns' includes a linked list of dynamically allocated data, and apparently I forgot to write a destructor that frees it all when the class is deallocated, and have never noticed until now.
2017-11-26 08:45:45 +00:00
childdata->percentages = NULL;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
cols->children = g_list_append(cols->children, childdata);
cols->taborder = g_list_append(cols->taborder, child);
gtk_widget_set_parent(child, GTK_WIDGET(cols));
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
if (gtk_widget_get_realized(GTK_WIDGET(cols)))
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
gtk_widget_realize(child);
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
if (gtk_widget_get_visible(GTK_WIDGET(cols)) &&
gtk_widget_get_visible(child)) {
if (gtk_widget_get_mapped(GTK_WIDGET(cols)))
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
gtk_widget_map(child);
gtk_widget_queue_resize(child);
}
}
Factor out columns_find_child() in the Columns class. This is an obviously reusable loop over cols->children looking for a widget, which I'm about to use a couple more times so it seems worth pulling it out into its own helper function.
2015-08-24 18:12:29 +00:00
static ColumnsChild *columns_find_child(Columns *cols, GtkWidget *widget)
{
GList *children;
ColumnsChild *child;
for (children = cols->children;
children && (child = children->data);
children = children->next) {
if (child->widget == widget)
return child;
}
return NULL;
}
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
void columns_force_left_align(Columns *cols, GtkWidget *widget)
{
ColumnsChild *child;
g_return_if_fail(cols != NULL);
g_return_if_fail(IS_COLUMNS(cols));
g_return_if_fail(widget != NULL);
Factor out columns_find_child() in the Columns class. This is an obviously reusable loop over cols->children looking for a widget, which I'm about to use a couple more times so it seems worth pulling it out into its own helper function.
2015-08-24 18:12:29 +00:00
child = columns_find_child(cols, widget);
g_return_if_fail(child != NULL);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
child->force_left = true;
Factor out columns_find_child() in the Columns class. This is an obviously reusable loop over cols->children looking for a widget, which I'm about to use a couple more times so it seems worth pulling it out into its own helper function.
2015-08-24 18:12:29 +00:00
if (gtk_widget_get_visible(widget))
gtk_widget_queue_resize(GTK_WIDGET(cols));
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
New Columns method, columns_force_same_height(). This forces two child widgets of a Columns to occupy the same amount of vertical space, and if one is really shorter than the other, vertically centres it in the extra space.
2015-08-24 18:23:32 +00:00
void columns_force_same_height(Columns *cols, GtkWidget *cw1, GtkWidget *cw2)
{
ColumnsChild *child1, *child2;
g_return_if_fail(cols != NULL);
g_return_if_fail(IS_COLUMNS(cols));
g_return_if_fail(cw1 != NULL);
g_return_if_fail(cw2 != NULL);
child1 = columns_find_child(cols, cw1);
g_return_if_fail(child1 != NULL);
child2 = columns_find_child(cols, cw2);
g_return_if_fail(child2 != NULL);
child1->same_height_as = child2;
child2->same_height_as = child1;
if (gtk_widget_get_visible(cw1) || gtk_widget_get_visible(cw2))
gtk_widget_queue_resize(GTK_WIDGET(cols));
}
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
void columns_taborder_last(Columns *cols, GtkWidget *widget)
{
GtkWidget *childw;
GList *children;
g_return_if_fail(cols != NULL);
g_return_if_fail(IS_COLUMNS(cols));
g_return_if_fail(widget != NULL);
for (children = cols->taborder;
children && (childw = children->data);
children = children->next) {
if (childw != widget)
continue;
cols->taborder = g_list_remove_link(cols->taborder, children);
g_list_free(children);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
cols->taborder = g_list_append(cols->taborder, widget);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
break;
}
}
/*
* Override GtkContainer's focus movement so the user can
* explicitly specify the tab order.
*/
Stop using deprecated gtk_container_set_focus_chain(). In GTK 2, this function was a new and convenient way to override the order in which the Tab key cycled through the sub-widgets of a container, replacing the more verbose mechanism in GTK 1 where you had to provide a custom implementation of the "focus" method in GtkContainerClass. GTK 3.24 has now deprecated gtk_container_set_focus_chain(), apparently on the grounds that that old system is what they think you _ought_ to be doing. So I've abandoned set_focus_chain completely, and switched back to doing it by a custom focus method for _all_ versions of GTK, with the only slight wrinkle being that between GTK 1 and 2 the method in question moved from GtkContainer to GtkWidget (my guess is so that an individual non-container widget can still have multiple separately focusable UI components).
2018-10-28 09:14:53 +00:00
static gint columns_focus(FOCUS_METHOD_SUPERCLASS *super, GtkDirectionType dir)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
Columns *cols;
GList *pos;
GtkWidget *focuschild;
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
g_return_val_if_fail(super != NULL, false);
g_return_val_if_fail(IS_COLUMNS(super), false);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Stop using deprecated gtk_container_set_focus_chain(). In GTK 2, this function was a new and convenient way to override the order in which the Tab key cycled through the sub-widgets of a container, replacing the more verbose mechanism in GTK 1 where you had to provide a custom implementation of the "focus" method in GtkContainerClass. GTK 3.24 has now deprecated gtk_container_set_focus_chain(), apparently on the grounds that that old system is what they think you _ought_ to be doing. So I've abandoned set_focus_chain completely, and switched back to doing it by a custom focus method for _all_ versions of GTK, with the only slight wrinkle being that between GTK 1 and 2 the method in question moved from GtkContainer to GtkWidget (my guess is so that an individual non-container widget can still have multiple separately focusable UI components).
2018-10-28 09:14:53 +00:00
cols = COLUMNS(super);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Stop using deprecated gtk_container_set_focus_chain(). In GTK 2, this function was a new and convenient way to override the order in which the Tab key cycled through the sub-widgets of a container, replacing the more verbose mechanism in GTK 1 where you had to provide a custom implementation of the "focus" method in GtkContainerClass. GTK 3.24 has now deprecated gtk_container_set_focus_chain(), apparently on the grounds that that old system is what they think you _ought_ to be doing. So I've abandoned set_focus_chain completely, and switched back to doing it by a custom focus method for _all_ versions of GTK, with the only slight wrinkle being that between GTK 1 and 2 the method in question moved from GtkContainer to GtkWidget (my guess is so that an individual non-container widget can still have multiple separately focusable UI components).
2018-10-28 09:14:53 +00:00
if (!gtk_widget_is_drawable(GTK_WIDGET(cols)) ||
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
!gtk_widget_is_sensitive(GTK_WIDGET(cols)))
return false;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Stop using deprecated gtk_container_set_focus_chain(). In GTK 2, this function was a new and convenient way to override the order in which the Tab key cycled through the sub-widgets of a container, replacing the more verbose mechanism in GTK 1 where you had to provide a custom implementation of the "focus" method in GtkContainerClass. GTK 3.24 has now deprecated gtk_container_set_focus_chain(), apparently on the grounds that that old system is what they think you _ought_ to be doing. So I've abandoned set_focus_chain completely, and switched back to doing it by a custom focus method for _all_ versions of GTK, with the only slight wrinkle being that between GTK 1 and 2 the method in question moved from GtkContainer to GtkWidget (my guess is so that an individual non-container widget can still have multiple separately focusable UI components).
2018-10-28 09:14:53 +00:00
if (!gtk_widget_get_can_focus(GTK_WIDGET(cols)) &&
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
(dir == GTK_DIR_TAB_FORWARD || dir == GTK_DIR_TAB_BACKWARD)) {
focuschild = gtk_container_get_focus_child(GTK_CONTAINER(cols));
gtk_container_set_focus_child(GTK_CONTAINER(cols), NULL);
if (dir == GTK_DIR_TAB_FORWARD)
pos = cols->taborder;
else
pos = g_list_last(cols->taborder);
while (pos) {
GtkWidget *child = pos->data;
if (focuschild) {
if (focuschild == child) {
focuschild = NULL; /* now we can start looking in here */
if (gtk_widget_is_drawable(child) &&
GTK_IS_CONTAINER(child) &&
!gtk_widget_has_focus(child)) {
if (CHILD_FOCUS(child, dir))
return true;
}
}
} else if (gtk_widget_is_drawable(child)) {
if (GTK_IS_CONTAINER(child)) {
if (CHILD_FOCUS(child, dir))
return true;
} else if (gtk_widget_get_can_focus(child)) {
gtk_widget_grab_focus(child);
return true;
}
}
if (dir == GTK_DIR_TAB_FORWARD)
pos = pos->next;
else
pos = pos->prev;
}
return false;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
} else
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
return columns_inherited_focus(super, dir);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
/*
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
* Underlying parts of the layout algorithm, to compute the Columns
* container's width or height given the widths or heights of its
* children. These will be called in various ways with different
* notions of width and height in use, so we abstract them out and
* pass them a 'get width' or 'get height' function pointer.
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
*/
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
typedef gint (*widget_dim_fn_t)(ColumnsChild *child);
static gint columns_compute_width(Columns *cols, widget_dim_fn_t get_width)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
ColumnsChild *child;
GList *children;
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
gint i, ncols, colspan, retwidth, childwidth;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
const gint *percentages;
static const gint onecol[] = { 100 };
Add conditioned-out diagnostics in columns_compute_width. These are a slightly cleaned-up version of the diagnostics I was using to debug the layout problems in the GTK3 config box the other day. In particular, if the box comes out far too wide - as I've just found out that it also does when I compile the current state of the code against OS X GTK3 - these diagnostics should provide enough information to figure out which control is the limiting factor. To enable: make CPPFLAGS="-DCOLUMNS_WIDTH_DIAGNOSTICS"
2015-08-27 17:32:41 +00:00
#ifdef COLUMNS_WIDTH_DIAGNOSTICS
printf("compute_width(%p): start\n", cols);
#endif
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
retwidth = 0;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
ncols = 1;
percentages = onecol;
for (children = cols->children;
children && (child = children->data);
children = children->next) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!child->widget) {
/* Column reconfiguration. */
ncols = child->ncols;
percentages = child->percentages;
continue;
}
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
/* Only take visible widgets into account. */
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
if (!gtk_widget_get_visible(child->widget))
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
continue;
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
childwidth = get_width(child);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
colspan = child->colspan ? child->colspan : ncols-child->colstart;
Add some more miscellaneous asserts. These clarify matters for static checkers (not to mention humans), and seem inexpensive enough not to worry about adding.
2018-12-01 14:13:37 +00:00
assert(colspan > 0);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Add conditioned-out diagnostics in columns_compute_width. These are a slightly cleaned-up version of the diagnostics I was using to debug the layout problems in the GTK3 config box the other day. In particular, if the box comes out far too wide - as I've just found out that it also does when I compile the current state of the code against OS X GTK3 - these diagnostics should provide enough information to figure out which control is the limiting factor. To enable: make CPPFLAGS="-DCOLUMNS_WIDTH_DIAGNOSTICS"
2015-08-27 17:32:41 +00:00
#ifdef COLUMNS_WIDTH_DIAGNOSTICS
printf("compute_width(%p): ", cols);
if (GTK_IS_LABEL(child->widget))
printf("label %p '%s' wrap=%s: ", child->widget,
gtk_label_get_text(GTK_LABEL(child->widget)),
(gtk_label_get_line_wrap(GTK_LABEL(child->widget))
Adopt C99 <stdbool.h>'s true/false. This commit includes <stdbool.h> from defs.h and deletes my traditional definitions of TRUE and FALSE, but other than that, it's a 100% mechanical search-and-replace transforming all uses of TRUE and FALSE into the C99-standardised lowercase spellings. No actual types are changed in this commit; that will come next. This is just getting the noise out of the way, so that subsequent commits can have a higher proportion of signal.
2018-10-29 19:50:29 +00:00
? "true" : "false"));
Add conditioned-out diagnostics in columns_compute_width. These are a slightly cleaned-up version of the diagnostics I was using to debug the layout problems in the GTK3 config box the other day. In particular, if the box comes out far too wide - as I've just found out that it also does when I compile the current state of the code against OS X GTK3 - these diagnostics should provide enough information to figure out which control is the limiting factor. To enable: make CPPFLAGS="-DCOLUMNS_WIDTH_DIAGNOSTICS"
2015-08-27 17:32:41 +00:00
else
printf("widget %p: ", child->widget);
{
gint min, nat;
gtk_widget_get_preferred_width(child->widget, &min, &nat);
printf("minwidth=%d natwidth=%d ", min, nat);
}
printf("thiswidth=%d span=%d\n", childwidth, colspan);
#endif
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
/*
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
* To compute width: we know that childwidth + cols->spacing
* needs to equal a certain percentage of the full width of
* the container. So we work this value out, figure out how
* wide the container will need to be to make that percentage
* of it equal to that width, and ensure our returned width is
* at least that much. Very simple really.
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
*/
{
int percent, thiswid, fullwid;
percent = 0;
for (i = 0; i < colspan; i++)
percent += percentages[child->colstart+i];
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
thiswid = childwidth + cols->spacing;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
/*
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
* Since childwidth is (at least sometimes) the _minimum_
* size the child needs, we must ensure that it gets _at
* least_ that size. Hence, when scaling thiswid up to
* fullwid, we must round up, which means adding percent-1
* before dividing by percent.
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
*/
fullwid = (thiswid * 100 + percent - 1) / percent;
Add conditioned-out diagnostics in columns_compute_width. These are a slightly cleaned-up version of the diagnostics I was using to debug the layout problems in the GTK3 config box the other day. In particular, if the box comes out far too wide - as I've just found out that it also does when I compile the current state of the code against OS X GTK3 - these diagnostics should provide enough information to figure out which control is the limiting factor. To enable: make CPPFLAGS="-DCOLUMNS_WIDTH_DIAGNOSTICS"
2015-08-27 17:32:41 +00:00
#ifdef COLUMNS_WIDTH_DIAGNOSTICS
printf("compute_width(%p): after %p, thiswid=%d fullwid=%d\n",
cols, child->widget, thiswid, fullwid);
#endif
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
/*
* The above calculation assumes every widget gets
* cols->spacing on the right. So we subtract
* cols->spacing here to account for the extra load of
* spacing on the right.
*/
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
if (retwidth < fullwid - cols->spacing)
retwidth = fullwid - cols->spacing;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
}
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
retwidth += 2*gtk_container_get_border_width(GTK_CONTAINER(cols));
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
Add conditioned-out diagnostics in columns_compute_width. These are a slightly cleaned-up version of the diagnostics I was using to debug the layout problems in the GTK3 config box the other day. In particular, if the box comes out far too wide - as I've just found out that it also does when I compile the current state of the code against OS X GTK3 - these diagnostics should provide enough information to figure out which control is the limiting factor. To enable: make CPPFLAGS="-DCOLUMNS_WIDTH_DIAGNOSTICS"
2015-08-27 17:32:41 +00:00
#ifdef COLUMNS_WIDTH_DIAGNOSTICS
printf("compute_width(%p): done, returning %d\n", cols, retwidth);
#endif
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
return retwidth;
GTK3 port: replace size_request in the Columns layout class. It's been replaced by a new pair of methods get_preferred_width and get_preferred_height. For the moment, I've followed the porting guide's suggestion of keeping the old size_request function as an underlying implementation and having each of those methods just return one of its outputs. The results are ugly, but it'll compile and run, which is a start.
2015-08-16 13:16:08 +00:00
}
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
static void columns_alloc_horiz(Columns *cols, gint ourwidth,
widget_dim_fn_t get_width)
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
{
ColumnsChild *child;
GList *children;
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
gint i, ncols, colspan, border, *colxpos, childwidth;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
border = gtk_container_get_border_width(GTK_CONTAINER(cols));
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
ncols = 1;
/* colxpos gives the starting x position of each column.
* We supply n+1 of them, so that we can find the RH edge easily.
* All ending x positions are expected to be adjusted afterwards by
* subtracting the spacing. */
colxpos = g_new(gint, 2);
colxpos[0] = 0;
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
colxpos[1] = ourwidth - 2*border + cols->spacing;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
for (children = cols->children;
children && (child = children->data);
children = children->next) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!child->widget) {
gint percent;
/* Column reconfiguration. */
ncols = child->ncols;
colxpos = g_renew(gint, colxpos, ncols + 1);
colxpos[0] = 0;
percent = 0;
for (i = 0; i < ncols; i++) {
percent += child->percentages[i];
colxpos[i+1] = (((ourwidth - 2*border) + cols->spacing)
* percent / 100);
}
continue;
}
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
/* Only take visible widgets into account. */
GTK 3 prep: use accessor functions for object data fields. We now build cleanly in GTK2 with -DGSEAL_ENABLE.
2015-08-08 14:53:43 +00:00
if (!gtk_widget_get_visible(child->widget))
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
continue;
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
childwidth = get_width(child);
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
colspan = child->colspan ? child->colspan : ncols-child->colstart;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
/*
* Starting x position is cols[colstart].
* Ending x position is cols[colstart+colspan] - spacing.
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
*
* Unless we're forcing left, in which case the width is
* exactly the requisition width.
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
*/
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
child->x = colxpos[child->colstart];
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (child->force_left)
child->w = childwidth;
else
child->w = (colxpos[child->colstart+colspan] -
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
colxpos[child->colstart] - cols->spacing);
}
g_free(colxpos);
}
static gint columns_compute_height(Columns *cols, widget_dim_fn_t get_height)
{
ColumnsChild *child;
GList *children;
gint i, ncols, colspan, *colypos, retheight, childheight;
retheight = cols->spacing;
ncols = 1;
colypos = g_new(gint, 1);
colypos[0] = 0;
for (children = cols->children;
children && (child = children->data);
children = children->next) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!child->widget) {
/* Column reconfiguration. */
for (i = 1; i < ncols; i++) {
if (colypos[0] < colypos[i])
colypos[0] = colypos[i];
}
ncols = child->ncols;
colypos = g_renew(gint, colypos, ncols);
for (i = 1; i < ncols; i++)
colypos[i] = colypos[0];
continue;
}
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
/* Only take visible widgets into account. */
if (!gtk_widget_get_visible(child->widget))
continue;
childheight = get_height(child);
New Columns method, columns_force_same_height(). This forces two child widgets of a Columns to occupy the same amount of vertical space, and if one is really shorter than the other, vertically centres it in the extra space.
2015-08-24 18:23:32 +00:00
if (child->same_height_as) {
gint childheight2 = get_height(child->same_height_as);
if (childheight < childheight2)
childheight = childheight2;
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
colspan = child->colspan ? child->colspan : ncols-child->colstart;
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
/*
* To compute height: the widget's top will be positioned at
* the largest y value so far reached in any of the columns it
* crosses. Then it will go down by childheight plus padding;
* and the point it reaches at the bottom is the new y value
* in all those columns, and minus the padding it is also a
* lower bound on our own height.
*/
{
int topy, boty;
topy = 0;
for (i = 0; i < colspan; i++) {
if (topy < colypos[child->colstart+i])
topy = colypos[child->colstart+i];
}
boty = topy + childheight + cols->spacing;
for (i = 0; i < colspan; i++) {
colypos[child->colstart+i] = boty;
}
if (retheight < boty - cols->spacing)
retheight = boty - cols->spacing;
}
}
retheight += 2*gtk_container_get_border_width(GTK_CONTAINER(cols));
g_free(colypos);
return retheight;
}
static void columns_alloc_vert(Columns *cols, gint ourheight,
widget_dim_fn_t get_height)
{
ColumnsChild *child;
GList *children;
New Columns method, columns_force_same_height(). This forces two child widgets of a Columns to occupy the same amount of vertical space, and if one is really shorter than the other, vertically centres it in the extra space.
2015-08-24 18:23:32 +00:00
gint i, ncols, colspan, *colypos, realheight, fakeheight;
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
ncols = 1;
/* As in size_request, colypos is the lowest y reached in each column. */
colypos = g_new(gint, 1);
colypos[0] = 0;
for (children = cols->children;
children && (child = children->data);
children = children->next) {
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
if (!child->widget) {
/* Column reconfiguration. */
for (i = 1; i < ncols; i++) {
if (colypos[0] < colypos[i])
colypos[0] = colypos[i];
}
ncols = child->ncols;
colypos = g_renew(gint, colypos, ncols);
for (i = 1; i < ncols; i++)
colypos[i] = colypos[0];
continue;
}
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
/* Only take visible widgets into account. */
if (!gtk_widget_get_visible(child->widget))
continue;
New Columns method, columns_force_same_height(). This forces two child widgets of a Columns to occupy the same amount of vertical space, and if one is really shorter than the other, vertically centres it in the extra space.
2015-08-24 18:23:32 +00:00
realheight = fakeheight = get_height(child);
if (child->same_height_as) {
gint childheight2 = get_height(child->same_height_as);
if (fakeheight < childheight2)
fakeheight = childheight2;
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
colspan = child->colspan ? child->colspan : ncols-child->colstart;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
/*
* To compute height: the widget's top will be positioned
* at the largest y value so far reached in any of the
* columns it crosses. Then it will go down by creq.height
* plus padding; and the point it reaches at the bottom is
* the new y value in all those columns.
*/
{
int topy, boty;
topy = 0;
for (i = 0; i < colspan; i++) {
if (topy < colypos[child->colstart+i])
topy = colypos[child->colstart+i];
}
New Columns method, columns_force_same_height(). This forces two child widgets of a Columns to occupy the same amount of vertical space, and if one is really shorter than the other, vertically centres it in the extra space.
2015-08-24 18:23:32 +00:00
child->y = topy + fakeheight/2 - realheight/2;
child->h = realheight;
boty = topy + fakeheight + cols->spacing;
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
for (i = 0; i < colspan; i++) {
colypos[child->colstart+i] = boty;
}
}
}
Whitespace rationalisation of entire code base. The number of people has been steadily increasing who read our source code with an editor that thinks tab stops are 4 spaces apart, as opposed to the traditional tty-derived 8 that the PuTTY code expects. So I've been wondering for ages about just fixing it, and switching to a spaces-only policy throughout the code. And I recently found out about 'git blame -w', which should make this change not too disruptive for the purposes of source-control archaeology; so perhaps now is the time. While I'm at it, I've also taken the opportunity to remove all the trailing spaces from source lines (on the basis that git dislikes them, and is the only thing that seems to have a strong opinion one way or the other). Apologies to anyone downstream of this code who has complicated patch sets to rebase past this change. I don't intend it to be needed again.
2019-09-08 19:29:00 +00:00
g_free(colypos);
First stab at a GTK layout engine. It's missing all sorts of stuff (list boxes are particularly conspicuously absent), it has no event handling at all, and it isn't in any way integrated into pterm - you have to build it specially using the test stubs in gtkdlg.c. But what there is so far seems to work plausibly well, so it's a start. Rather than browbeat the existing GTK container/layout widgets into doing what I wanted, I decided to implement two subclasses of GtkContainer myself, which implement precisely the layout model assumed by the config box specification; this has the rather cool consequence that the box can be resized and will maintain the same layout at all times that it would have had if initially created at that size. [originally from svn r2931]
2003-03-13 19:52:28 +00:00
}
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
/*
* Now here comes the interesting bit. The actual layout part is
* done in the following two functions:
*
* columns_size_request() examines the list of widgets held in the
* Columns, and returns a requisition stating the absolute minimum
* size it can bear to be.
*
* columns_size_allocate() is given an allocation telling it what
* size the whole container is going to be, and it calls
* gtk_widget_size_allocate() on all of its (visible) children to
* set their size and position relative to the top left of the
* container.
*/
Implement GTK3 height-for-width layout in Columns. Now that I've got the main calculation code separated from the GTK2 size_request and size_allocate top-level methods, I can introduce a completely different set of GTK3 top-level methods, which run the same underlying calculations but based on different width and height information. So now we do proper height-for-width layout, as you can see if you flip the PuTTY config box to a pane with a wrapping label on it (e.g. Fonts or Logging) and resize the window horizontally. Where the GTK2 config box just left the wrapped text label at its original size, and the GTK3 one before this change would reflow the text but without changing the label's height, now the text reflows and the controls below it move up and down when the number of lines of wrapped text changes. (As far as I'm concerned, that's a nice demo of GTK3's new abilities but not a critically important UI feature for this app. The more important point is that switching to the modern layout model removes one of the remaining uses of the deprecated gtk_widget_size_request.)
2015-08-23 13:50:47 +00:00
#if !GTK_CHECK_VERSION(3,0,0)
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
static gint columns_gtk2_get_width(ColumnsChild *child)
{
GtkRequisition creq;
gtk_widget_size_request(child->widget, &creq);
return creq.width;
}
static gint columns_gtk2_get_height(ColumnsChild *child)
{
GtkRequisition creq;
gtk_widget_size_request(child->widget, &creq);
return creq.height;
}
static void columns_size_request(GtkWidget *widget, GtkRequisition *req)
{
Columns *cols;
g_return_if_fail(widget != NULL);
g_return_if_fail(IS_COLUMNS(widget));
g_return_if_fail(req != NULL);
cols = COLUMNS(widget);
req->width = columns_compute_width(cols, columns_gtk2_get_width);
req->height = columns_compute_height(cols, columns_gtk2_get_height);
}
Implement GTK3 height-for-width layout in Columns. Now that I've got the main calculation code separated from the GTK2 size_request and size_allocate top-level methods, I can introduce a completely different set of GTK3 top-level methods, which run the same underlying calculations but based on different width and height information. So now we do proper height-for-width layout, as you can see if you flip the PuTTY config box to a pane with a wrapping label on it (e.g. Fonts or Logging) and resize the window horizontally. Where the GTK2 config box just left the wrapped text label at its original size, and the GTK3 one before this change would reflow the text but without changing the label's height, now the text reflows and the controls below it move up and down when the number of lines of wrapped text changes. (As far as I'm concerned, that's a nice demo of GTK3's new abilities but not a critically important UI feature for this app. The more important point is that switching to the modern layout model removes one of the remaining uses of the deprecated gtk_widget_size_request.)
2015-08-23 13:50:47 +00:00
static void columns_size_allocate(GtkWidget *widget, GtkAllocation *alloc)
{
Columns *cols;
ColumnsChild *child;
GList *children;
gint border;
g_return_if_fail(widget != NULL);
g_return_if_fail(IS_COLUMNS(widget));
g_return_if_fail(alloc != NULL);
cols = COLUMNS(widget);
gtk_widget_set_allocation(widget, alloc);
border = gtk_container_get_border_width(GTK_CONTAINER(cols));
columns_alloc_horiz(cols, alloc->width, columns_gtk2_get_width);
columns_alloc_vert(cols, alloc->height, columns_gtk2_get_height);
for (children = cols->children;
children && (child = children->data);
children = children->next) {
if (child->widget && gtk_widget_get_visible(child->widget)) {
GtkAllocation call;
call.x = alloc->x + border + child->x;
call.y = alloc->y + border + child->y;
call.width = child->w;
call.height = child->h;
gtk_widget_size_allocate(child->widget, &call);
}
}
}
#else /* GTK_CHECK_VERSION(3,0,0) */
static gint columns_gtk3_get_min_width(ColumnsChild *child)
{
gint ret;
gtk_widget_get_preferred_width(child->widget, &ret, NULL);
return ret;
}
static gint columns_gtk3_get_nat_width(ColumnsChild *child)
{
gint ret;
Make Columns disregard the preferred width of GtkEntry. On OS X GTK, it requests a preferred width that's way too large. I think that's because that's based on its max_width_chars rather than its width_chars (and I only set the latter). But I don't want to actually reduce its max_width_chars, in case (either now or in a future version) that causes it to actually refuse to take up all the space it's allocated.
2015-08-27 17:59:24 +00:00
if ((GTK_IS_LABEL(child->widget) &&
gtk_label_get_line_wrap(GTK_LABEL(child->widget))) ||
GTK_IS_ENTRY(child->widget)) {
Implement GTK3 height-for-width layout in Columns. Now that I've got the main calculation code separated from the GTK2 size_request and size_allocate top-level methods, I can introduce a completely different set of GTK3 top-level methods, which run the same underlying calculations but based on different width and height information. So now we do proper height-for-width layout, as you can see if you flip the PuTTY config box to a pane with a wrapping label on it (e.g. Fonts or Logging) and resize the window horizontally. Where the GTK2 config box just left the wrapped text label at its original size, and the GTK3 one before this change would reflow the text but without changing the label's height, now the text reflows and the controls below it move up and down when the number of lines of wrapped text changes. (As far as I'm concerned, that's a nice demo of GTK3's new abilities but not a critically important UI feature for this app. The more important point is that switching to the modern layout model removes one of the remaining uses of the deprecated gtk_widget_size_request.)
2015-08-23 13:50:47 +00:00
/*
* We treat wrapping GtkLabels as a special case in this
* layout class, because the whole point of those is that I
* _don't_ want them to take up extra horizontal space for
* long text, but instead to wrap it to whatever size is used
* by the rest of the layout.
Make Columns disregard the preferred width of GtkEntry. On OS X GTK, it requests a preferred width that's way too large. I think that's because that's based on its max_width_chars rather than its width_chars (and I only set the latter). But I don't want to actually reduce its max_width_chars, in case (either now or in a future version) that causes it to actually refuse to take up all the space it's allocated.
2015-08-27 17:59:24 +00:00
*
* GtkEntry gets similar treatment, because in OS X GTK I've
* found that it requests a natural width regardless of the
* output of gtk_entry_set_width_chars.
Implement GTK3 height-for-width layout in Columns. Now that I've got the main calculation code separated from the GTK2 size_request and size_allocate top-level methods, I can introduce a completely different set of GTK3 top-level methods, which run the same underlying calculations but based on different width and height information. So now we do proper height-for-width layout, as you can see if you flip the PuTTY config box to a pane with a wrapping label on it (e.g. Fonts or Logging) and resize the window horizontally. Where the GTK2 config box just left the wrapped text label at its original size, and the GTK3 one before this change would reflow the text but without changing the label's height, now the text reflows and the controls below it move up and down when the number of lines of wrapped text changes. (As far as I'm concerned, that's a nice demo of GTK3's new abilities but not a critically important UI feature for this app. The more important point is that switching to the modern layout model removes one of the remaining uses of the deprecated gtk_widget_size_request.)
2015-08-23 13:50:47 +00:00
*/
gtk_widget_get_preferred_width(child->widget, &ret, NULL);
} else {
gtk_widget_get_preferred_width(child->widget, NULL, &ret);
}
return ret;
}
static gint columns_gtk3_get_minfh_width(ColumnsChild *child)
{
gint ret;
gtk_widget_get_preferred_width_for_height(child->widget, child->h,
&ret, NULL);
return ret;
}
static gint columns_gtk3_get_natfh_width(ColumnsChild *child)
{
gint ret;
gtk_widget_get_preferred_width_for_height(child->widget, child->h,
NULL, &ret);
return ret;
}
static gint columns_gtk3_get_min_height(ColumnsChild *child)
{
gint ret;
gtk_widget_get_preferred_height(child->widget, &ret, NULL);
return ret;
}
static gint columns_gtk3_get_nat_height(ColumnsChild *child)
{
gint ret;
gtk_widget_get_preferred_height(child->widget, NULL, &ret);
return ret;
}
static gint columns_gtk3_get_minfw_height(ColumnsChild *child)
{
gint ret;
gtk_widget_get_preferred_height_for_width(child->widget, child->w,
&ret, NULL);
return ret;
}
static gint columns_gtk3_get_natfw_height(ColumnsChild *child)
{
gint ret;
gtk_widget_get_preferred_height_for_width(child->widget, child->w,
NULL, &ret);
return ret;
}
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
static void columns_get_preferred_width(GtkWidget *widget,
gint *min, gint *nat)
{
Implement GTK3 height-for-width layout in Columns. Now that I've got the main calculation code separated from the GTK2 size_request and size_allocate top-level methods, I can introduce a completely different set of GTK3 top-level methods, which run the same underlying calculations but based on different width and height information. So now we do proper height-for-width layout, as you can see if you flip the PuTTY config box to a pane with a wrapping label on it (e.g. Fonts or Logging) and resize the window horizontally. Where the GTK2 config box just left the wrapped text label at its original size, and the GTK3 one before this change would reflow the text but without changing the label's height, now the text reflows and the controls below it move up and down when the number of lines of wrapped text changes. (As far as I'm concerned, that's a nice demo of GTK3's new abilities but not a critically important UI feature for this app. The more important point is that switching to the modern layout model removes one of the remaining uses of the deprecated gtk_widget_size_request.)
2015-08-23 13:50:47 +00:00
Columns *cols;
g_return_if_fail(widget != NULL);
g_return_if_fail(IS_COLUMNS(widget));
cols = COLUMNS(widget);
if (min)
*min = columns_compute_width(cols, columns_gtk3_get_min_width);
if (nat)
*nat = columns_compute_width(cols, columns_gtk3_get_nat_width);
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
}
static void columns_get_preferred_height(GtkWidget *widget,
Implement GTK3 height-for-width layout in Columns. Now that I've got the main calculation code separated from the GTK2 size_request and size_allocate top-level methods, I can introduce a completely different set of GTK3 top-level methods, which run the same underlying calculations but based on different width and height information. So now we do proper height-for-width layout, as you can see if you flip the PuTTY config box to a pane with a wrapping label on it (e.g. Fonts or Logging) and resize the window horizontally. Where the GTK2 config box just left the wrapped text label at its original size, and the GTK3 one before this change would reflow the text but without changing the label's height, now the text reflows and the controls below it move up and down when the number of lines of wrapped text changes. (As far as I'm concerned, that's a nice demo of GTK3's new abilities but not a critically important UI feature for this app. The more important point is that switching to the modern layout model removes one of the remaining uses of the deprecated gtk_widget_size_request.)
2015-08-23 13:50:47 +00:00
gint *min, gint *nat)
{
Columns *cols;
g_return_if_fail(widget != NULL);
g_return_if_fail(IS_COLUMNS(widget));
cols = COLUMNS(widget);
if (min)
*min = columns_compute_height(cols, columns_gtk3_get_min_height);
if (nat)
*nat = columns_compute_height(cols, columns_gtk3_get_nat_height);
}
static void columns_get_preferred_width_for_height(GtkWidget *widget,
gint height,
gint *min, gint *nat)
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
{
Implement GTK3 height-for-width layout in Columns. Now that I've got the main calculation code separated from the GTK2 size_request and size_allocate top-level methods, I can introduce a completely different set of GTK3 top-level methods, which run the same underlying calculations but based on different width and height information. So now we do proper height-for-width layout, as you can see if you flip the PuTTY config box to a pane with a wrapping label on it (e.g. Fonts or Logging) and resize the window horizontally. Where the GTK2 config box just left the wrapped text label at its original size, and the GTK3 one before this change would reflow the text but without changing the label's height, now the text reflows and the controls below it move up and down when the number of lines of wrapped text changes. (As far as I'm concerned, that's a nice demo of GTK3's new abilities but not a critically important UI feature for this app. The more important point is that switching to the modern layout model removes one of the remaining uses of the deprecated gtk_widget_size_request.)
2015-08-23 13:50:47 +00:00
Columns *cols;
g_return_if_fail(widget != NULL);
g_return_if_fail(IS_COLUMNS(widget));
cols = COLUMNS(widget);
/* FIXME: which one should the get-height function here be? */
columns_alloc_vert(cols, height, columns_gtk3_get_nat_height);
if (min)
*min = columns_compute_width(cols, columns_gtk3_get_minfh_width);
if (nat)
*nat = columns_compute_width(cols, columns_gtk3_get_natfh_width);
}
static void columns_get_preferred_height_for_width(GtkWidget *widget,
gint width,
gint *min, gint *nat)
{
Columns *cols;
g_return_if_fail(widget != NULL);
g_return_if_fail(IS_COLUMNS(widget));
cols = COLUMNS(widget);
/* FIXME: which one should the get-height function here be? */
columns_alloc_horiz(cols, width, columns_gtk3_get_nat_width);
if (min)
*min = columns_compute_height(cols, columns_gtk3_get_minfw_height);
if (nat)
*nat = columns_compute_height(cols, columns_gtk3_get_natfw_height);
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
}
static void columns_size_allocate(GtkWidget *widget, GtkAllocation *alloc)
{
Columns *cols;
ColumnsChild *child;
GList *children;
gint border;
g_return_if_fail(widget != NULL);
g_return_if_fail(IS_COLUMNS(widget));
g_return_if_fail(alloc != NULL);
cols = COLUMNS(widget);
gtk_widget_set_allocation(widget, alloc);
border = gtk_container_get_border_width(GTK_CONTAINER(cols));
Implement GTK3 height-for-width layout in Columns. Now that I've got the main calculation code separated from the GTK2 size_request and size_allocate top-level methods, I can introduce a completely different set of GTK3 top-level methods, which run the same underlying calculations but based on different width and height information. So now we do proper height-for-width layout, as you can see if you flip the PuTTY config box to a pane with a wrapping label on it (e.g. Fonts or Logging) and resize the window horizontally. Where the GTK2 config box just left the wrapped text label at its original size, and the GTK3 one before this change would reflow the text but without changing the label's height, now the text reflows and the controls below it move up and down when the number of lines of wrapped text changes. (As far as I'm concerned, that's a nice demo of GTK3's new abilities but not a critically important UI feature for this app. The more important point is that switching to the modern layout model removes one of the remaining uses of the deprecated gtk_widget_size_request.)
2015-08-23 13:50:47 +00:00
columns_alloc_horiz(cols, alloc->width, columns_gtk3_get_min_width);
columns_alloc_vert(cols, alloc->height, columns_gtk3_get_minfw_height);
GTK3 prep: refactor the layout calculation in Columns. Previously, columns_size_request and columns_size_allocate would each loop over all the widgets doing computations for both width and height. Now I've separated out the width parts from the height parts, and moved both out into four new functions, so that the top-level columns_size_request and columns_size_allocate are just wrappers that call the new functions and plumb size and position information between them and GTK. Actual functionality should be unchanged by this patch.
2015-08-23 13:49:01 +00:00
for (children = cols->children;
children && (child = children->data);
children = children->next) {
if (child->widget && gtk_widget_get_visible(child->widget)) {
GtkAllocation call;
call.x = alloc->x + border + child->x;
call.y = alloc->y + border + child->y;
call.width = child->w;
call.height = child->h;
gtk_widget_size_allocate(child->widget, &call);
}
}
}
Implement GTK3 height-for-width layout in Columns. Now that I've got the main calculation code separated from the GTK2 size_request and size_allocate top-level methods, I can introduce a completely different set of GTK3 top-level methods, which run the same underlying calculations but based on different width and height information. So now we do proper height-for-width layout, as you can see if you flip the PuTTY config box to a pane with a wrapping label on it (e.g. Fonts or Logging) and resize the window horizontally. Where the GTK2 config box just left the wrapped text label at its original size, and the GTK3 one before this change would reflow the text but without changing the label's height, now the text reflows and the controls below it move up and down when the number of lines of wrapped text changes. (As far as I'm concerned, that's a nice demo of GTK3's new abilities but not a critically important UI feature for this app. The more important point is that switching to the modern layout model removes one of the remaining uses of the deprecated gtk_widget_size_request.)
2015-08-23 13:50:47 +00:00
#endif
Reference in New Issue Copy Permalink