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
pre-0.83
putty-source/unix/columns.c

1277 lines
38 KiB
C
Raw Permalink 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
/*
Update source file names in comments and docs. Correcting a source file name in the docs just now reminded me that I've seen a lot of outdated source file names elsewhere in the code, due to all the reorganisation since we moved to cmake. Here's a giant pass of trying to make them all accurate again.
2022-01-22 15:38:53 +00:00
* columns.c - implementation of the `Columns' GTK layout 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
*/
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;
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;
Improve the align_next_to mechanism. Various alignments I want to do in the host CA box have shown up deficiencies in this system, so I've reworked it a bit. Firstly, you can now specify more than two controls to be tied together with an align_next_to (e.g. multiple checkboxes alongside something else). Secondly, as well as forcing the controls to be the same height as each other, the layout algorithm will also move the later controls further _downward_, so that their top y positions also line up. Until now that hasn't been necessary, because they lined up already. In the GTK implementation of this via the Columns class, I've renamed 'columns_force_same_height' to 'columns_align_next_to', and similarly for some of the internal fields, since the latter change makes the previous names a misnomer. In the Windows implementation, I found it most convenient to set this up by following a linked list of align_next_to fields backwards. But it won't always be convenient to initialise them that way, so I've also written a crude normaliser that will rewrite those links into a canonical form. But I only call that on Windows; it's unnecessary in GTK, where the Columns class provides plenty of per-widget extra storage so I just keep each alignment class as a circular list.
2022-05-02 13:37:11 +00:00
bool need_layout = false;
if (gtk_widget_get_visible(widget))
need_layout = 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
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
Improve the align_next_to mechanism. Various alignments I want to do in the host CA box have shown up deficiencies in this system, so I've reworked it a bit. Firstly, you can now specify more than two controls to be tied together with an align_next_to (e.g. multiple checkboxes alongside something else). Secondly, as well as forcing the controls to be the same height as each other, the layout algorithm will also move the later controls further _downward_, so that their top y positions also line up. Until now that hasn't been necessary, because they lined up already. In the GTK implementation of this via the Columns class, I've renamed 'columns_force_same_height' to 'columns_align_next_to', and similarly for some of the internal fields, since the latter change makes the previous names a misnomer. In the Windows implementation, I found it most convenient to set this up by following a linked list of align_next_to fields backwards. But it won't always be convenient to initialise them that way, so I've also written a crude normaliser that will rewrite those links into a canonical form. But I only call that on Windows; it's unnecessary in GTK, where the Columns class provides plenty of per-widget extra storage so I just keep each alignment class as a circular list.
2022-05-02 13:37:11 +00:00
/* Unlink this widget from its valign list, and if anything
* else on the list is still visible, ensure we recompute our
* layout */
for (ColumnsChild *ch = child->valign_next; ch != child;
ch = ch->valign_next)
if (gtk_widget_get_visible(ch->widget))
need_layout = true;
child->valign_next->valign_prev = child->valign_prev;
child->valign_prev->valign_next = child->valign_next;
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
GTK: allow Event Log list box to grow vertically. Now, when you resize the Event Log window, the list box grows in both directions. Previously, as a side effect of the Columns-based layout, it grew only horizontally. I've arranged this by adding an extra wrinkle to the Columns layout system, which allows you to tag _exactly one_ widget in the whole container as the 'vexpand' widget. When the Columns is size-allocated taller than its minimum height, the vexpand widget is given all the extra space. This technique ports naturally across all versions of GTK (since the hard part is done in my own code). But it's limited: you can't set more than one widget to be vexpand (which saves having to figure out whether they're side by side and can expand in parallel, or vertically separated and each have to get half the available extra space, etc). And in complex layouts where the widget you really want to expand is in a sub-Columns, there's no system for recursively searching down to find it. In other words, this is a one-shot bodge for the Event Log, and it will want more work if we ever plan to extend it to list boxes in the main config dialog.
2021-12-21 10:53:41 +00:00
if (cols->vexpand == child)
cols->vexpand = 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
g_free(child);
Improve the align_next_to mechanism. Various alignments I want to do in the host CA box have shown up deficiencies in this system, so I've reworked it a bit. Firstly, you can now specify more than two controls to be tied together with an align_next_to (e.g. multiple checkboxes alongside something else). Secondly, as well as forcing the controls to be the same height as each other, the layout algorithm will also move the later controls further _downward_, so that their top y positions also line up. Until now that hasn't been necessary, because they lined up already. In the GTK implementation of this via the Columns class, I've renamed 'columns_force_same_height' to 'columns_align_next_to', and similarly for some of the internal fields, since the latter change makes the previous names a misnomer. In the Windows implementation, I found it most convenient to set this up by following a linked list of align_next_to fields backwards. But it won't always be convenient to initialise them that way, so I've also written a crude normaliser that will rewrite those links into a canonical form. But I only call that on Windows; it's unnecessary in GTK, where the Columns class provides plenty of per-widget extra storage so I just keep each alignment class as a circular list.
2022-05-02 13:37:11 +00:00
if (need_layout)
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_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;
Improve the align_next_to mechanism. Various alignments I want to do in the host CA box have shown up deficiencies in this system, so I've reworked it a bit. Firstly, you can now specify more than two controls to be tied together with an align_next_to (e.g. multiple checkboxes alongside something else). Secondly, as well as forcing the controls to be the same height as each other, the layout algorithm will also move the later controls further _downward_, so that their top y positions also line up. Until now that hasn't been necessary, because they lined up already. In the GTK implementation of this via the Columns class, I've renamed 'columns_force_same_height' to 'columns_align_next_to', and similarly for some of the internal fields, since the latter change makes the previous names a misnomer. In the Windows implementation, I found it most convenient to set this up by following a linked list of align_next_to fields backwards. But it won't always be convenient to initialise them that way, so I've also written a crude normaliser that will rewrite those links into a canonical form. But I only call that on Windows; it's unnecessary in GTK, where the Columns class provides plenty of per-widget extra storage so I just keep each alignment class as a circular list.
2022-05-02 13:37:11 +00:00
childdata->valign_next = childdata;
childdata->valign_prev = childdata;
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
}
Improve the align_next_to mechanism. Various alignments I want to do in the host CA box have shown up deficiencies in this system, so I've reworked it a bit. Firstly, you can now specify more than two controls to be tied together with an align_next_to (e.g. multiple checkboxes alongside something else). Secondly, as well as forcing the controls to be the same height as each other, the layout algorithm will also move the later controls further _downward_, so that their top y positions also line up. Until now that hasn't been necessary, because they lined up already. In the GTK implementation of this via the Columns class, I've renamed 'columns_force_same_height' to 'columns_align_next_to', and similarly for some of the internal fields, since the latter change makes the previous names a misnomer. In the Windows implementation, I found it most convenient to set this up by following a linked list of align_next_to fields backwards. But it won't always be convenient to initialise them that way, so I've also written a crude normaliser that will rewrite those links into a canonical form. But I only call that on Windows; it's unnecessary in GTK, where the Columns class provides plenty of per-widget extra storage so I just keep each alignment class as a circular list.
2022-05-02 13:37:11 +00:00
void columns_align_next_to(Columns *cols, GtkWidget *cw1, GtkWidget *cw2)
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
{
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);
Improve the align_next_to mechanism. Various alignments I want to do in the host CA box have shown up deficiencies in this system, so I've reworked it a bit. Firstly, you can now specify more than two controls to be tied together with an align_next_to (e.g. multiple checkboxes alongside something else). Secondly, as well as forcing the controls to be the same height as each other, the layout algorithm will also move the later controls further _downward_, so that their top y positions also line up. Until now that hasn't been necessary, because they lined up already. In the GTK implementation of this via the Columns class, I've renamed 'columns_force_same_height' to 'columns_align_next_to', and similarly for some of the internal fields, since the latter change makes the previous names a misnomer. In the Windows implementation, I found it most convenient to set this up by following a linked list of align_next_to fields backwards. But it won't always be convenient to initialise them that way, so I've also written a crude normaliser that will rewrite those links into a canonical form. But I only call that on Windows; it's unnecessary in GTK, where the Columns class provides plenty of per-widget extra storage so I just keep each alignment class as a circular list.
2022-05-02 13:37:11 +00:00
ColumnsChild *child1prev = child1->valign_prev;
ColumnsChild *child2prev = child2->valign_prev;
child1prev->valign_next = child2;
child2->valign_prev = child1prev;
child2prev->valign_next = child1;
child1->valign_prev = child2prev;
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 (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;
}
}
GTK: allow Event Log list box to grow vertically. Now, when you resize the Event Log window, the list box grows in both directions. Previously, as a side effect of the Columns-based layout, it grew only horizontally. I've arranged this by adding an extra wrinkle to the Columns layout system, which allows you to tag _exactly one_ widget in the whole container as the 'vexpand' widget. When the Columns is size-allocated taller than its minimum height, the vexpand widget is given all the extra space. This technique ports naturally across all versions of GTK (since the hard part is done in my own code). But it's limited: you can't set more than one widget to be vexpand (which saves having to figure out whether they're side by side and can expand in parallel, or vertically separated and each have to get half the available extra space, etc). And in complex layouts where the widget you really want to expand is in a sub-Columns, there's no system for recursively searching down to find it. In other words, this is a one-shot bodge for the Event Log, and it will want more work if we ever plan to extend it to list boxes in the main config dialog.
2021-12-21 10:53:41 +00:00
void columns_vexpand(Columns *cols, GtkWidget *widget)
{
g_return_if_fail(cols != NULL);
g_return_if_fail(IS_COLUMNS(cols));
g_return_if_fail(widget != NULL);
ColumnsChild *child = columns_find_child(cols, widget);
g_return_if_fail(child != NULL);
cols->vexpand = child;
}
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
/*
* 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);
Improve the align_next_to mechanism. Various alignments I want to do in the host CA box have shown up deficiencies in this system, so I've reworked it a bit. Firstly, you can now specify more than two controls to be tied together with an align_next_to (e.g. multiple checkboxes alongside something else). Secondly, as well as forcing the controls to be the same height as each other, the layout algorithm will also move the later controls further _downward_, so that their top y positions also line up. Until now that hasn't been necessary, because they lined up already. In the GTK implementation of this via the Columns class, I've renamed 'columns_force_same_height' to 'columns_align_next_to', and similarly for some of the internal fields, since the latter change makes the previous names a misnomer. In the Windows implementation, I found it most convenient to set this up by following a linked list of align_next_to fields backwards. But it won't always be convenient to initialise them that way, so I've also written a crude normaliser that will rewrite those links into a canonical form. But I only call that on Windows; it's unnecessary in GTK, where the Columns class provides plenty of per-widget extra storage so I just keep each alignment class as a circular list.
2022-05-02 13:37:11 +00:00
for (ColumnsChild *ch = child->valign_next; ch != child;
ch = ch->valign_next) {
gint childheight2 = get_height(ch);
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 (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;
GTK: allow Event Log list box to grow vertically. Now, when you resize the Event Log window, the list box grows in both directions. Previously, as a side effect of the Columns-based layout, it grew only horizontally. I've arranged this by adding an extra wrinkle to the Columns layout system, which allows you to tag _exactly one_ widget in the whole container as the 'vexpand' widget. When the Columns is size-allocated taller than its minimum height, the vexpand widget is given all the extra space. This technique ports naturally across all versions of GTK (since the hard part is done in my own code). But it's limited: you can't set more than one widget to be vexpand (which saves having to figure out whether they're side by side and can expand in parallel, or vertically separated and each have to get half the available extra space, etc). And in complex layouts where the widget you really want to expand is in a sub-Columns, there's no system for recursively searching down to find it. In other words, this is a one-shot bodge for the Event Log, and it will want more work if we ever plan to extend it to list boxes in the main config dialog.
2021-12-21 10:53:41 +00:00
gint i, ncols, colspan, *colypos, realheight, fakeheight, vexpand_extra;
if (cols->vexpand) {
gint minheight = columns_compute_height(cols, get_height);
vexpand_extra = ourheight - minheight;
} else {
vexpand_extra = 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
ncols = 1;
/* As in size_request, colypos is the lowest y reached in each column. */
colypos = g_new(gint, 1);
colypos[0] = 0;
Improve the align_next_to mechanism. Various alignments I want to do in the host CA box have shown up deficiencies in this system, so I've reworked it a bit. Firstly, you can now specify more than two controls to be tied together with an align_next_to (e.g. multiple checkboxes alongside something else). Secondly, as well as forcing the controls to be the same height as each other, the layout algorithm will also move the later controls further _downward_, so that their top y positions also line up. Until now that hasn't been necessary, because they lined up already. In the GTK implementation of this via the Columns class, I've renamed 'columns_force_same_height' to 'columns_align_next_to', and similarly for some of the internal fields, since the latter change makes the previous names a misnomer. In the Windows implementation, I found it most convenient to set this up by following a linked list of align_next_to fields backwards. But it won't always be convenient to initialise them that way, so I've also written a crude normaliser that will rewrite those links into a canonical form. But I only call that on Windows; it's unnecessary in GTK, where the Columns class provides plenty of per-widget extra storage so I just keep each alignment class as a circular list.
2022-05-02 13:37:11 +00:00
for (children = cols->children;
children && (child = children->data);
children = children->next)
child->visited = false;
GTK: fix y computation in align_next_to. The protocol selector widgets were misaligned in GTK as well as on Windows, but for a completely different reason. (I guess both bugs must have been introduced at the same time when I reworked the system to tolerate more than two aligned widgets in commit b5ab90143a2df7f.) To vertically align N widgets, you have to first figure out what range of y-coordinates they jointly occupy, and then centre each one within that range. We were trying to do both jobs in the same pass, which meant trying to place the first widget before finding out where the last one will be. To do this, we were separately computing the y-range's start and width, the former by taking max of the y-coordinates _seen so far_, and the latter by taking max of _all_ the widgets' heights. This has two problems. One is that if you later find out that the y-coordinate of the top of the range needs to be lower than you'd previously realised, it's too late to go back and reposition the widgets you've already placed. But that's a theoretical issue that would only come up with more complicated column layouts than we've actually used. (And probably more complicated than would even be _sensible_ to use.) The other, more immediate, problem: the y-coordinates we were using for already-placed widgets in the set were the ones _after_ we adjusted each one for vertical centring. So if the first widget is short and the second taller (say, heights 20 and 30 pixels), then the first widget will be offset downwards by 5 pixels, but the second widget will use that offset y-coordinate as the _top_ of the range to fit itself into, and hence, will also be 5 pixels downward from where it should have been. I think only the second of those problems is immediately concerning, but it's easier to fix both at once. I've removed the y-adjustment for vertical centring from the main layout loop, and put it in a separate pass run after the main layout finishes.
2022-09-06 10:13:50 +00:00
/*
* Main layout loop. In this loop, vertically aligned controls are
* only half dealt with: we assign each one enough _height_ to
* match the others in its group, but we don't adjust its y
* coordinates yet.
*/
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) {
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;
Improve the align_next_to mechanism. Various alignments I want to do in the host CA box have shown up deficiencies in this system, so I've reworked it a bit. Firstly, you can now specify more than two controls to be tied together with an align_next_to (e.g. multiple checkboxes alongside something else). Secondly, as well as forcing the controls to be the same height as each other, the layout algorithm will also move the later controls further _downward_, so that their top y positions also line up. Until now that hasn't been necessary, because they lined up already. In the GTK implementation of this via the Columns class, I've renamed 'columns_force_same_height' to 'columns_align_next_to', and similarly for some of the internal fields, since the latter change makes the previous names a misnomer. In the Windows implementation, I found it most convenient to set this up by following a linked list of align_next_to fields backwards. But it won't always be convenient to initialise them that way, so I've also written a crude normaliser that will rewrite those links into a canonical form. But I only call that on Windows; it's unnecessary in GTK, where the Columns class provides plenty of per-widget extra storage so I just keep each alignment class as a circular list.
2022-05-02 13:37:11 +00:00
int ymin = 0;
GTK: allow Event Log list box to grow vertically. Now, when you resize the Event Log window, the list box grows in both directions. Previously, as a side effect of the Columns-based layout, it grew only horizontally. I've arranged this by adding an extra wrinkle to the Columns layout system, which allows you to tag _exactly one_ widget in the whole container as the 'vexpand' widget. When the Columns is size-allocated taller than its minimum height, the vexpand widget is given all the extra space. This technique ports naturally across all versions of GTK (since the hard part is done in my own code). But it's limited: you can't set more than one widget to be vexpand (which saves having to figure out whether they're side by side and can expand in parallel, or vertically separated and each have to get half the available extra space, etc). And in complex layouts where the widget you really want to expand is in a sub-Columns, there's no system for recursively searching down to find it. In other words, this is a one-shot bodge for the Event Log, and it will want more work if we ever plan to extend it to list boxes in the main config dialog.
2021-12-21 10:53:41 +00:00
realheight = get_height(child);
if (child == cols->vexpand)
realheight += vexpand_extra;
fakeheight = realheight;
Improve the align_next_to mechanism. Various alignments I want to do in the host CA box have shown up deficiencies in this system, so I've reworked it a bit. Firstly, you can now specify more than two controls to be tied together with an align_next_to (e.g. multiple checkboxes alongside something else). Secondly, as well as forcing the controls to be the same height as each other, the layout algorithm will also move the later controls further _downward_, so that their top y positions also line up. Until now that hasn't been necessary, because they lined up already. In the GTK implementation of this via the Columns class, I've renamed 'columns_force_same_height' to 'columns_align_next_to', and similarly for some of the internal fields, since the latter change makes the previous names a misnomer. In the Windows implementation, I found it most convenient to set this up by following a linked list of align_next_to fields backwards. But it won't always be convenient to initialise them that way, so I've also written a crude normaliser that will rewrite those links into a canonical form. But I only call that on Windows; it's unnecessary in GTK, where the Columns class provides plenty of per-widget extra storage so I just keep each alignment class as a circular list.
2022-05-02 13:37:11 +00:00
for (ColumnsChild *ch = child->valign_next; ch != child;
ch = ch->valign_next) {
gint childheight2 = get_height(ch);
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 (fakeheight < childheight2)
fakeheight = childheight2;
Improve the align_next_to mechanism. Various alignments I want to do in the host CA box have shown up deficiencies in this system, so I've reworked it a bit. Firstly, you can now specify more than two controls to be tied together with an align_next_to (e.g. multiple checkboxes alongside something else). Secondly, as well as forcing the controls to be the same height as each other, the layout algorithm will also move the later controls further _downward_, so that their top y positions also line up. Until now that hasn't been necessary, because they lined up already. In the GTK implementation of this via the Columns class, I've renamed 'columns_force_same_height' to 'columns_align_next_to', and similarly for some of the internal fields, since the latter change makes the previous names a misnomer. In the Windows implementation, I found it most convenient to set this up by following a linked list of align_next_to fields backwards. But it won't always be convenient to initialise them that way, so I've also written a crude normaliser that will rewrite those links into a canonical form. But I only call that on Windows; it's unnecessary in GTK, where the Columns class provides plenty of per-widget extra storage so I just keep each alignment class as a circular list.
2022-05-02 13:37:11 +00:00
if (ch->visited && ymin < ch->y)
ymin = ch->y;
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
}
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;
Improve the align_next_to mechanism. Various alignments I want to do in the host CA box have shown up deficiencies in this system, so I've reworked it a bit. Firstly, you can now specify more than two controls to be tied together with an align_next_to (e.g. multiple checkboxes alongside something else). Secondly, as well as forcing the controls to be the same height as each other, the layout algorithm will also move the later controls further _downward_, so that their top y positions also line up. Until now that hasn't been necessary, because they lined up already. In the GTK implementation of this via the Columns class, I've renamed 'columns_force_same_height' to 'columns_align_next_to', and similarly for some of the internal fields, since the latter change makes the previous names a misnomer. In the Windows implementation, I found it most convenient to set this up by following a linked list of align_next_to fields backwards. But it won't always be convenient to initialise them that way, so I've also written a crude normaliser that will rewrite those links into a canonical form. But I only call that on Windows; it's unnecessary in GTK, where the Columns class provides plenty of per-widget extra storage so I just keep each alignment class as a circular list.
2022-05-02 13:37:11 +00:00
topy = ymin;
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++) {
if (topy < colypos[child->colstart+i])
topy = colypos[child->colstart+i];
}
GTK: fix y computation in align_next_to. The protocol selector widgets were misaligned in GTK as well as on Windows, but for a completely different reason. (I guess both bugs must have been introduced at the same time when I reworked the system to tolerate more than two aligned widgets in commit b5ab90143a2df7f.) To vertically align N widgets, you have to first figure out what range of y-coordinates they jointly occupy, and then centre each one within that range. We were trying to do both jobs in the same pass, which meant trying to place the first widget before finding out where the last one will be. To do this, we were separately computing the y-range's start and width, the former by taking max of the y-coordinates _seen so far_, and the latter by taking max of _all_ the widgets' heights. This has two problems. One is that if you later find out that the y-coordinate of the top of the range needs to be lower than you'd previously realised, it's too late to go back and reposition the widgets you've already placed. But that's a theoretical issue that would only come up with more complicated column layouts than we've actually used. (And probably more complicated than would even be _sensible_ to use.) The other, more immediate, problem: the y-coordinates we were using for already-placed widgets in the set were the ones _after_ we adjusted each one for vertical centring. So if the first widget is short and the second taller (say, heights 20 and 30 pixels), then the first widget will be offset downwards by 5 pixels, but the second widget will use that offset y-coordinate as the _top_ of the range to fit itself into, and hence, will also be 5 pixels downward from where it should have been. I think only the second of those problems is immediately concerning, but it's easier to fix both at once. I've removed the y-adjustment for vertical centring from the main layout loop, and put it in a separate pass run after the main layout finishes.
2022-09-06 10:13:50 +00:00
child->y = topy;
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->h = realheight;
Improve the align_next_to mechanism. Various alignments I want to do in the host CA box have shown up deficiencies in this system, so I've reworked it a bit. Firstly, you can now specify more than two controls to be tied together with an align_next_to (e.g. multiple checkboxes alongside something else). Secondly, as well as forcing the controls to be the same height as each other, the layout algorithm will also move the later controls further _downward_, so that their top y positions also line up. Until now that hasn't been necessary, because they lined up already. In the GTK implementation of this via the Columns class, I've renamed 'columns_force_same_height' to 'columns_align_next_to', and similarly for some of the internal fields, since the latter change makes the previous names a misnomer. In the Windows implementation, I found it most convenient to set this up by following a linked list of align_next_to fields backwards. But it won't always be convenient to initialise them that way, so I've also written a crude normaliser that will rewrite those links into a canonical form. But I only call that on Windows; it's unnecessary in GTK, where the Columns class provides plenty of per-widget extra storage so I just keep each alignment class as a circular list.
2022-05-02 13:37:11 +00:00
child->visited = true;
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
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;
}
}
}
GTK: fix y computation in align_next_to. The protocol selector widgets were misaligned in GTK as well as on Windows, but for a completely different reason. (I guess both bugs must have been introduced at the same time when I reworked the system to tolerate more than two aligned widgets in commit b5ab90143a2df7f.) To vertically align N widgets, you have to first figure out what range of y-coordinates they jointly occupy, and then centre each one within that range. We were trying to do both jobs in the same pass, which meant trying to place the first widget before finding out where the last one will be. To do this, we were separately computing the y-range's start and width, the former by taking max of the y-coordinates _seen so far_, and the latter by taking max of _all_ the widgets' heights. This has two problems. One is that if you later find out that the y-coordinate of the top of the range needs to be lower than you'd previously realised, it's too late to go back and reposition the widgets you've already placed. But that's a theoretical issue that would only come up with more complicated column layouts than we've actually used. (And probably more complicated than would even be _sensible_ to use.) The other, more immediate, problem: the y-coordinates we were using for already-placed widgets in the set were the ones _after_ we adjusted each one for vertical centring. So if the first widget is short and the second taller (say, heights 20 and 30 pixels), then the first widget will be offset downwards by 5 pixels, but the second widget will use that offset y-coordinate as the _top_ of the range to fit itself into, and hence, will also be 5 pixels downward from where it should have been. I think only the second of those problems is immediately concerning, but it's easier to fix both at once. I've removed the y-adjustment for vertical centring from the main layout loop, and put it in a separate pass run after the main layout finishes.
2022-09-06 10:13:50 +00:00
/*
* Now make a separate pass that deals with vertical alignment by
* moving controls downwards based on the difference between their
* own height and the largest height of anything in their group.
*/
for (children = cols->children;
children && (child = children->data);
children = children->next) {
if (!child->widget)
continue;
if (!gtk_widget_get_visible(child->widget))
continue;
fakeheight = realheight = child->h;
for (ColumnsChild *ch = child->valign_next; ch != child;
ch = ch->valign_next) {
if (fakeheight < ch->h)
fakeheight = ch->h;
}
child->y += fakeheight/2 - realheight/2;
}
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