Re: Build and install a new input method?
On 10/6/10, Murray Cumming murr...@murrayc.com wrote: On Wed, 2010-10-06 at 07:56 +0700, John Matthewman wrote: http://www.openismus.com/misc/multipress-gtk-input-method/source/ Thanks for that - though I was hoping to see a simple makefile so I could make a bit more sense of what's going on. (Not a fan of autotools...) Just watch the output when you do make install then. I've got things working almost the way that I'd like them - now I just have one more question. What's the easiest way to toggle the system input method? I only use Simple and my Vietnamese (TELEX) input method, so ideally I would have a little script that I could bind to a function key and it toggles between the two input methods. Would I just write a little shell script that re-sets the GTK_IM_MODULE environment variable..? I wouldn't mind setting the input method on a per-application basis, but some apps mess with the right-click context menus so I can't change the input method that way. Thanks in advance for any tips! John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
No palette in GtkColorButton
Does anyone know if it is possible to show the palette widgets in the dialog started from GtkColorButton ? GtkColorSelection/GtkColorSelectionDialog widgets support showing the palette, but I can not seem to access this functionality through GtkColorButton widget. Does anyone know a way to get to the underlying GtkColorSelection widget when having a pointer to GtkColorButton ? Regards, Miroslav ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkSpreadTable ('spread-table' branch)
On Fri, 2010-10-08 at 23:31 +0900, Tristan Van Berkom wrote: For what its worth I finally applied this algorithm to the 'spread-table' branch. In the case that the trailing columns get no widgets, one widget is placed in each of the trailing columns (again, only happens with lots of columns and not enough widgets... and seems to look good this way IMO) I think you have broken the single-line case. No child widgets seem to appear for me now when lines=1. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: possible removal of GtkWrapBox
On Thu, 2010-10-07 at 12:36 +0900, Tristan Van Berkom wrote: Furthermore, the gimp's newer versions is now using GtkToolPalette in place of the older wrap-box (the gimp had been using a similar wrap-box widget to wrap items around in one of it's toolbars). Shouldn't GtkToolPalette (and maybe GtkToolbar) be using GtkWrapBox, or some similar code? -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkSpreadTable ('spread-table' branch)
On Mon, 2010-10-11 at 11:04 +0200, Murray Cumming wrote: On Fri, 2010-10-08 at 23:31 +0900, Tristan Van Berkom wrote: For what its worth I finally applied this algorithm to the 'spread-table' branch. In the case that the trailing columns get no widgets, one widget is placed in each of the trailing columns (again, only happens with lots of columns and not enough widgets... and seems to look good this way IMO) I think you have broken the single-line case. No child widgets seem to appear for me now when lines=1. Interesting I'll check that out, the current expected results is that it still lines up children on 2 lines (i.e. thats the current minimum for the lines property, so I would expect a warning message and a behaviour of 2 lines). Since having a single-line spread table is desired, I'll go ahead and change that (I suppose 2 lines is still a good default though). fwiw, there's another unhandled case; currently when there are less widgets in the table than there are lines declared; space is still allocated for the extra missing lines. Is it desirable to: a.) Only request and allocate space for columns we have enough widgets to fill ? or b.) Request and allocate space for a third column if only 2 widgets are in the box (leaving the impression that there is actually a third column that is simply unpopulated) ? I'm pretty sure that 'a' is the reasonable choice but I was not entirely sure. Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: possible removal of GtkWrapBox
On Mon, 2010-10-11 at 11:06 +0200, Murray Cumming wrote: On Thu, 2010-10-07 at 12:36 +0900, Tristan Van Berkom wrote: Furthermore, the gimp's newer versions is now using GtkToolPalette in place of the older wrap-box (the gimp had been using a similar wrap-box widget to wrap items around in one of it's toolbars). Shouldn't GtkToolPalette (and maybe GtkToolbar) be using GtkWrapBox, or some similar code? Unfortunately it cant be done that simply (actually; I initially wanted to implement GtkSpreadTable in terms of a GtkBox subclass with 'n-lines' child GtkBoxes lined up in the opposite orientation, i.e. an hbox filled with vboxes... this idea would have presented some problems when it would come to requesting and testing different configurations). The main problem here is that the GtkToolPalette is expected to contain toolitems, and calling gtk_container_get_children on it should generally return the toolitems, anything that invokes the forall vfunc expects toolitems, not a wrapbox (also calling gtk_container_add/remove() on the toolpalette is not expected to add/remove the child wrap-box). So I would have to say only the latter is really possible, i.e. the toolpalette should use similar code as the wrapbox. (this case kindof shows one of the advantages that Clutter has in terms of layout managers being separated code from the actual containers). Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkSpreadTable ('spread-table' branch)
On Mon, 2010-10-11 at 19:48 +0900, Tristan Van Berkom wrote: On Mon, 2010-10-11 at 11:04 +0200, Murray Cumming wrote: On Fri, 2010-10-08 at 23:31 +0900, Tristan Van Berkom wrote: For what its worth I finally applied this algorithm to the 'spread-table' branch. In the case that the trailing columns get no widgets, one widget is placed in each of the trailing columns (again, only happens with lots of columns and not enough widgets... and seems to look good this way IMO) I think you have broken the single-line case. No child widgets seem to appear for me now when lines=1. Interesting I'll check that out, the current expected results is that it still lines up children on 2 lines (i.e. thats the current minimum for the lines property, so I would expect a warning message and a behaviour of 2 lines). That seem rather arbitrary. Allowing lines=1 lets me use it more generically and dynamically. Otherwise I need to switch to a GtkBox just for that case. Since having a single-line spread table is desired, I'll go ahead and change that (I suppose 2 lines is still a good default though). Yes. fwiw, there's another unhandled case; currently when there are less widgets in the table than there are lines declared; space is still allocated for the extra missing lines. That sounds OK to me, as long as it's documented. It's giving the coder what he asked for. Otherwise, lines would be max-lines. Is it desirable to: a.) Only request and allocate space for columns we have enough widgets to fill ? or b.) Request and allocate space for a third column if only 2 widgets are in the box (leaving the impression that there is actually a third column that is simply unpopulated) ? I'm pretty sure that 'a' is the reasonable choice but I was not entirely sure. Cheers, -Tristan -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: possible removal of GtkWrapBox
On Mon, 2010-10-11 at 19:54 +0900, Tristan Van Berkom wrote: On Mon, 2010-10-11 at 11:06 +0200, Murray Cumming wrote: On Thu, 2010-10-07 at 12:36 +0900, Tristan Van Berkom wrote: Furthermore, the gimp's newer versions is now using GtkToolPalette in place of the older wrap-box (the gimp had been using a similar wrap-box widget to wrap items around in one of it's toolbars). Shouldn't GtkToolPalette (and maybe GtkToolbar) be using GtkWrapBox, or some similar code? Unfortunately it cant be done that simply (actually; I initially wanted to implement GtkSpreadTable in terms of a GtkBox subclass with 'n-lines' child GtkBoxes lined up in the opposite orientation, i.e. an hbox filled with vboxes... this idea would have presented some problems when it would come to requesting and testing different configurations). The main problem here is that the GtkToolPalette is expected to contain toolitems, and calling gtk_container_get_children on it should generally return the toolitems, anything that invokes the forall vfunc expects toolitems, not a wrapbox (also calling gtk_container_add/remove() on the toolpalette is not expected to add/remove the child wrap-box). Can't some vfunc implementation make it return the indirect children, instead, making GtkWrapBox purely implementation? So I would have to say only the latter is really possible, i.e. the toolpalette should use similar code as the wrapbox. (this case kindof shows one of the advantages that Clutter has in terms of layout managers being separated code from the actual containers). -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: possible removal of GtkWrapBox
On Mon, 2010-10-11 at 13:04 +0200, Murray Cumming wrote: On Mon, 2010-10-11 at 19:54 +0900, Tristan Van Berkom wrote: On Mon, 2010-10-11 at 11:06 +0200, Murray Cumming wrote: On Thu, 2010-10-07 at 12:36 +0900, Tristan Van Berkom wrote: Furthermore, the gimp's newer versions is now using GtkToolPalette in place of the older wrap-box (the gimp had been using a similar wrap-box widget to wrap items around in one of it's toolbars). Shouldn't GtkToolPalette (and maybe GtkToolbar) be using GtkWrapBox, or some similar code? Unfortunately it cant be done that simply (actually; I initially wanted to implement GtkSpreadTable in terms of a GtkBox subclass with 'n-lines' child GtkBoxes lined up in the opposite orientation, i.e. an hbox filled with vboxes... this idea would have presented some problems when it would come to requesting and testing different configurations). The main problem here is that the GtkToolPalette is expected to contain toolitems, and calling gtk_container_get_children on it should generally return the toolitems, anything that invokes the forall vfunc expects toolitems, not a wrapbox (also calling gtk_container_add/remove() on the toolpalette is not expected to add/remove the child wrap-box). Can't some vfunc implementation make it return the indirect children, instead, making GtkWrapBox purely implementation? I think whatever implemented along those lines is going to be a mess if successful at all. For instance, in size requests and allocations we would need a real hierarchy (involving the wrapbox ofcourse), also when propagating events through container children we need to use the same logical heirarchy (propagate expose, child focus etc). Then when adding and removing we want to pretend the wrap-box isnt there... with the exception of when the toolpalette gets destroyed and then we want to destroy the child wrapbox and not only its children... probably some other implicit things about maintaining a logical hierarchy I'm missing (oh and maybe we want gtk_container_list_children() to also pretend the wrap-box isnt there, which is a call to forall() but then how do we detect the difference between a forall() call for external user code or a forall() call that propagates expose events or such ?). Anyway that's the kindof road we would be walking down, unless the toolpalette were documented to be a composite widget with an internal wrap-box (or internal wrap-boxes in the palette groups, either way)... in which case we would have extra apis for adding and removing children of the internal wrapbox. (kindof like GtkDialog must do to get at the internal vbox and action-area), but this approach would also be a big api break... Cheers, -Tristan So I would have to say only the latter is really possible, i.e. the toolpalette should use similar code as the wrapbox. (this case kindof shows one of the advantages that Clutter has in terms of layout managers being separated code from the actual containers). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Minimum height for minimum width
When we are doing height-for-width layout, sometimes we get a situation where we have a height-for-width object in a context that doesn't support height-for-with-layout. Examples: A) The height-for-width contents of a GtkWindow. X doesn't support height-for-width layout, the window hints are just the minimum size and the default size. [*] B) A height-for-width widget inside a container that is width-for-height. The current behavior of GTK+-2.9x is that the miminum size in such a context is the minimum-height-for-the-minimum width. This sounds obviously right, but I think it's not. For example, if a wrapping GtkLabel did the obvious thing and reported its minimum width as the minimum width as the width of the longest word, the result of putting this inside a GtkWindow would be: ++ |This| |is | (using the current default-size-of-GtkWindow is minimum size) |some| |text| ++ Or +-+ |This is some text| | | (using default-size-of-GtkWindow is natural size) | | | | +-+ Because that works out so badly, GtkLabel currently doesn't report it's real minimum width, but, as in GTK+-2.0, reports a guess of a good width to wrap to as the mininum width, so what you get is that the window starts off as: +--+ |This is | |some text | +--+ and can't be resized to a smaller width/height. That doesn't work badly for this case, but means that a wrapped GtkLabel always has that artificial minimum width, even in cases where it has a real height-for-width parent. (Unless overridden by the programmer.) In my opinion minimum-height-for-minimum width is just conceptually wrong - the minimum width should be the real minimum width, and at the real minimum width a height-for-width widget will be unnaturally tall. This is no a good miminimum height. What, to my mind, works better in every way is minimum-height-for-natural-width. The objection I was hearing to this is then the window ends up with: +-+ |This is some text| +-+ And can't be made any narrower than this, but unlike minimum width, the natural width has no inherent meaning for a widget that can adapt to any width, like a wrapping label. We can get identical results to the current results by making a wrapped GtkLabel report a good width to wrap to as the *natural* width. And we do this without breaking the minimum width of GtkLabel. - Owen [*] It actually works pretty well in X to report a dynamic minimum height depending on the current width. We start off with the minimum width of the window as the real minimum width, but the minimum height of the window as the height for the default/natural width. If the user starts shrinking the window horizontally, we set progressively bigger minimum height hints. This does work out slightly oddly with wireframe resizing, however. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
Agreed, GtkLabel needs to report min size = true min sane size and
natural size = either full width, or a good width
The full width is more correct imo, maybe we should figure out why
that doesn't work well.
A related patch attached, if you fix this you'll quickly want it.
Also, you said if doing minimum-height-for-natural-width the window
doesn't wrap the label and can't be made narrower. I don't understand
that... I would expect the min size of the window is the min height
for natural width as you propose, and the min width as returned by
get_preferred_width(). So the min width ought to be the true min
width?
Hmm. The a good width to wrap to thing seems like pretty much crack
to me. If people want their window to have some sort of pleasing
aspect ratio they should just pack the label to limit its width, or
set default size on the window, or whatever. Or maybe GtkWindow should
constrain the default size to nice aspect ratio somehow, solving
globally for the window instead of per-label.
Havoc
From 7ddeb49f1643799794bdc7d96a55fe9a885cd39f Mon Sep 17 00:00:00 2001
From: Havoc Pennington h...@pobox.com
Date: Mon, 6 Sep 2010 11:18:35 -0400
Subject: [PATCH] Make GtkWindow default to natural size not minimum size
Otherwise your ellipsized labels all start out ellipsized, unless
you manually gtk_window_set_default_size().
This probably makes it important to clamp the window's default
size to the size of the monitor's work area.
---
gtk/gtkwindow.c |4 ++--
tests/testgtk.c |1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/gtk/gtkwindow.c b/gtk/gtkwindow.c
index 5f75dae..b50a9ab 100644
--- a/gtk/gtkwindow.c
+++ b/gtk/gtkwindow.c
@@ -5725,9 +5725,9 @@ gtk_window_compute_configure_request_size (GtkWindow *window,
if (window-need_default_size)
{
- gtk_widget_get_child_requisition (widget, requisition);
+ gtk_size_request_get_size (GTK_SIZE_REQUEST (widget), NULL, requisition);
- /* Default to requisition */
+ /* Default to natural requisition */
*width = requisition.width;
*height = requisition.height;
diff --git a/tests/testgtk.c b/tests/testgtk.c
index cddb7df..8ea1117 100644
--- a/tests/testgtk.c
+++ b/tests/testgtk.c
@@ -8431,6 +8431,7 @@ create_window_sizing (GtkWidget *widget)
gtk_widget_get_screen (widget));
label = gtk_label_new (NULL);
gtk_label_set_markup (GTK_LABEL (label), span foreground=\purple\bigWindow being resized/big/span\nBlah blah blah blah\nblah blah blah\nblah blah blah blah blah);
+ gtk_label_set_ellipsize (GTK_LABEL (label), PANGO_ELLIPSIZE_END);
gtk_container_add (GTK_CONTAINER (target_window), label);
gtk_widget_show (label);
--
1.7.0.4
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
On Mon, 2010-10-11 at 14:45 -0400, Havoc Pennington wrote: Agreed, GtkLabel needs to report min size = true min sane size and natural size = either full width, or a good width The full width is more correct imo, maybe we should figure out why that doesn't work well. For an ellipsized label, the natural width is clearly the full width. In this case there's an obvious interpretation of natural size because there's a minimum size where we display all the information and above that we're just adding padding. But for a wrapped label, there are many different possibilities for displaying all the information. I'm not sure that there's anything more natural about the case where we put each paragraph on a single unwrapped line. Of course, if we take the position that there is never any reason to allocate an actor more than it's natural size - if the natural size is all the size that is useful - then using a narrower natural width could be problematical, especially if things like centering are added by the parent actor or GTK+, and not the actor itself. A related patch attached, if you fix this you'll quickly want it. Yeah, came up when I was fixing gnome-terminal behavior (see e.g., https://bugzilla.gnome.org/show_bug.cgi?id=631903) Also, you said if doing minimum-height-for-natural-width the window doesn't wrap the label and can't be made narrower. I don't understand that... I would expect the min size of the window is the min height for natural width as you propose, and the min width as returned by get_preferred_width(). So the min width ought to be the true min width? If you use those values, then you are telling the window manager that the window can be sized to a size that's too small for its contents. Since GTK+ 3 basically can't handle underallocation all, this isn't a good idea. (The behavior with underallocation is that widgets are allocated with their minimum size centered at their allocated location. Since there is no clipping this means you get a mess of overlapping widgets.) Setting the hints dynamically based on the current width can work, if we're willing to say screw wireframe resizing (wireframe resizing doesn't completely *not* work, you just have to release and retry a few times to get to certain sizes.) Hmm. The a good width to wrap to thing seems like pretty much crack to me. If people want their window to have some sort of pleasing aspect ratio they should just pack the label to limit its width, or set default size on the window, or whatever. Or maybe GtkWindow should constrain the default size to nice aspect ratio somehow, solving globally for the window instead of per-label. I certainly always saw the good width to wrap to thing as a workaround for GTK+ 1/2 geometry management. But picking a good aspect ratio from the toplevel will require a binary search. That might be fine if the binary search is done only once when picking a default size for the toplevel when first mapping it. - Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minimum height for minimum width
Hi, On Mon, Oct 11, 2010 at 3:30 PM, Owen Taylor otay...@redhat.com wrote: Setting the hints dynamically based on the current width can work, if we're willing to say screw wireframe resizing (wireframe resizing doesn't completely *not* work, you just have to release and retry a few times to get to certain sizes.) Uggghhh... so the h-f-w request/allocate stuff needs to be exposed to the WM ;-) I can't even think of a good solution in theory, offhand. I guess having labels pick a good width is the best option. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkGroupBox and layout ideas for Gtk3
On Sun, Oct 10, 2010 at 8:32 PM, Havoc Pennington h...@pobox.com wrote: Hi, On Sun, Oct 10, 2010 at 4:57 PM, Alexander Larsson al...@redhat.com wrote: First of all, what happened to Bug 628902 Add expand flags to GtkWidget. It seems to have stalled. This would be very useful. The latest code is on widget-expand-3 branch, fwiw. todo items are: * magic resizability behavior on GtkWindow * write equivalent of GtkBox patch for Table * remove expand child prop from WrapBox (if we keep wrap box, I guess) * possible do not propagate special cases see https://bugzilla.gnome.org/show_bug.cgi?id=628902#c24 I took care of GtkTable, GtkWrapBox and some of the 'do not propagate' cases, so from my perspective, the branch is pretty close to ready now. I may look into GtkWindow still, or leave that for after the merge. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[REMINDER] GTK+ Team Meeting, 2010-10-12
hi everyone; this is a reminder that the next GTK team meeting is scheduled for: Tuesday, October 12th, 2010 @ 20:00 UTC http://www.timeanddate.com/worldclock/fixedtime.html?day=12month=10year=2010hour=20min=0sec=0p1=0 channel: #gtk-devel on irc://irc.gnome.org agenda: • magic expand (628902) • fate of the tutorial and examples • Deprecate / remove gtk_init_add / remove* API (bug: 629955) • ::destroy - up or down ? (bug: 630690) • Deprecation of glib gettext macros 624186 • GtkComboBoxText subclass to supersede text convenience API, GtkComboBoxEntryText needed? (bug: 612396) • Miscellaneous as usual, changes in the agenda and/or time are going to be listed on the wiki: http://live.gnome.org/GTK%2B/Meetings ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
