Re: Top down layout
On 9 June 2010 06:16, Matthew Allen l...@sydneyband.com.au wrote:
GtkWidget *vp = gtk_viewport_new(GTK_ADJUSTMENT(h), GTK_ADJUSTMENT(v));
if (vp)
{
On a tiny style point, by design gtk cannot get out of memory errors.
You can set a handler to run on out-of-mem, and allocations you
perform yourself with g_try_malloc() can test for oom, but no part of
gtk either tests, or can fail.
The reasoning (as I understand it) is that oom conditions are almost
impossible to recover from in GUI programs. If you can't allocate
enough memory for a new widget (somewhere around 100 bytes), your
chances of being able to save state or even display a warning are
almost nil.
You can set an oom handler and perhaps, depending on your app, there
are some caches you can drop safely without disturbing the GUI. Even
that is a little unlikely :-( The oom can be triggered by almost
anything and it's hard to be certain you don't have races.
John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Top down layout
When I tried putting putting a scrollable area into a window... I didn't get very convincing results. The code below attempts to put a very large button into a 300x300 size window. I made you a tiny example program. This puts a 400x400 button into a 300x300 window. If the window is too small, you get scrollbars. If the window is too big, the button expands to fill the available space. Hope I've not misunderstood what you need. Thats good in the way that I can resize the window smaller than the scrollview... but the problem I have now is that because I'm catching the configure-event on the GtkWindow (to adjust my internal position/size variables) the scrollview doesn't update to the client area of the window as I resize it. In the case where I comment out the configure-event signal connect it works well, the scrollview tracks with the window as you resize. So I guess now I want to know how to catch the configure-event and then pass it on to the next handler so I get normal behaviour AND have access to that event. (I'm a signal noob) Thanks. -- Matthew Allen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Top down layout
On 9 June 2010 12:40, Matthew Allen l...@sydneyband.com.au wrote: the problem I have now is that because I'm catching the configure-event on the GtkWindow (to adjust my internal position/size variables) the scrollview doesn't update to the client area of the window as I resize it. That's an easy one (phew): all _event signals are bool-valued. Return TRUE to indicate that you've handled the event, return FALSE to propagate further. http://library.gnome.org/devel/gtk/stable/GtkWidget.html#GtkWidget-configure-event John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Top down layout
I'm trying to port an application to GTK that uses top down layout... i.e. given a window of size 1000x700 it knows how to fill that space with widgets. However GTK seems adamant to do layout in a bottom up fashion... i.e. given buttons and lists and splitters it'll work out how big the window needs to be to show those items. These 2 ideologies seem to be incompatible. So what I want to ask is there some way I can make this work? Clearly I could rewrite the application to use GTK layout, but I think that would take a long time and it's not really what I want anyway. I would like some way of using maybe a custom GTK widget that sits in the GtkWindow and does it's own internal layout (top down) of it's children but appears to GTK to be a normal widget. The problem I have is in getting that root widget to fill the GtkWindow without forcing it's size to be anything in particular. I still want the window to be resizable, so if I set the requested size to the current client area of the GtkWindow than sure enough the root widget fills the window initially, but I can't resize the window to smaller than that original size, and neither does the root widget increase to follow the GtkWindow as it gets larger. This sort of behaviour might not be possible with GTK. But at least I thought I'd ask. -- Matthew Allen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Top down layout
This sort of behaviour might not be possible with GTK. But at least I thought I'd ask. Actually whats the first signal generated when the user attempts to resize the GtkWindow? I should hook that and stop it get limited to the requested size... then my window is free to resize arbitrarily, and I can sort out the layout from there. Is there some way of seeing the signals being fired? -- Matthew Allen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Top down layout
On Tue, Jun 8, 2010 at 10:36 PM, Matthew Allen l...@sydneyband.com.au wrote: This sort of behaviour might not be possible with GTK. But at least I thought I'd ask. Actually whats the first signal generated when the user attempts to resize the GtkWindow? I should hook that and stop it get limited to the requested size... then my window is free to resize arbitrarily, and I can sort out the layout from there. Is there some way of seeing the signals being fired? Do you need to let the window be smaller than the space that its children occupy ? You could just put everything in a scrolled window and hide the scrollbars if thats what you wanted. Otherwise GTK+ should only restrict your window size to the smallest possible size needed to hold all visible child widgets. Assuming a sensible UI design; all the window contents easily fit on screen so you can then stretch/maximize your interface, at this point the bottom up method of requesting space allows you to further tweak out which child is going to be allocated extra space at resize time. Does that help at all ? maybe you can explain exactly what part of the application you are porting that you are having difficulty representing with a UI in GTK+. Cheers, -Tristan -- Matthew Allen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Top down layout
-- Original Message -- To: Matthew Allen (l...@sydneyband.com.au) From: Tristan Van Berkom (t...@gnome.org) Subject: Re: Top down layout Date: 9/6/2010 12:55:44p On Tue, Jun 8, 2010 at 10:36 PM, Matthew Allen l...@sydneyband.com.au wrote: This sort of behaviour might not be possible with GTK. But at least I thought I'd ask. Actually whats the first signal generated when the user attempts to resize the GtkWindow? I should hook that and stop it get limited to the requested size... then my window is free to resize arbitrarily, and I can sort out the layout from there. Is there some way of seeing the signals being fired? Do you need to let the window be smaller than the space that its children occupy ? Yes. The GtkWindow should not be limited to the contents at all, thats what I want. You could just put everything in a scrolled window and hide the scrollbars if thats An interesting idea... I might have a look at the implementation details of the scrollable area widget. I'm currently reading through gdkevents-win32.c in an attempt to find where it enforces the minimum window size. I was hoping that somewhere in the WM_SIZING handler it would get the current allocation and set the RECT pointed to by lParam to that size. Or something like that, but so far I haven't got my head around it. Or maybe it's happening in WM_WINDOWPOSCHANGING? GDK_NOTE is just debugging right? -- Matthew Allen http://www.memecode.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Top down layout
-- Original Message --
To: Matthew Allen (l...@sydneyband.com.au)
From: Tristan Van Berkom (t...@gnome.org)
Subject: Re: Top down layout
Date: 9/6/2010 1:44:30p
On Tue, Jun 8, 2010 at 11:09 PM, Matthew Allen l...@sydneyband.com.au
wrote: -- Original Message --
To: Matthew Allen (l...@sydneyband.com.au)
From: Tristan Van Berkom (t...@gnome.org)
Subject: Re: Top down layout
Date: 9/6/2010 12:55:44p
On Tue, Jun 8, 2010 at 10:36 PM, Matthew Allen
l...@sydneyband.com.au wrote: This sort of behaviour might not
be possible with GTK. But at least I thought I'd ask.
Actually whats the first signal generated when the user attempts to
resize the GtkWindow?
I should hook that and stop it get limited to the requested size...
then my window is free to resize arbitrarily, and I can sort out
the layout from there. Is there some way of seeing the signals
being fired?
Do you need to let the window be smaller than the space that its
children occupy ?
Yes. The GtkWindow should not be limited to the contents at all, thats
what I want.
You could just put everything in a scrolled window and hide the
scrollbars if thats
An interesting idea... I might have a look at the implementation details
of the scrollable area widget.
I'm currently reading through gdkevents-win32.c in an attempt to find
where it enforces the minimum window size. I was hoping that somewhere
in the WM_SIZING handler it would get the current allocation and set the
RECT pointed to by lParam to that size. Or something like that, but so
far I haven't got my head around it.
Or maybe it's happening in WM_WINDOWPOSCHANGING?
For a clearer answer on that particularly, GtkWindow size is
constrained by the minimum size
of its contents, scrollable area widgets exist to allow encapsulation
of larger areas that dont
fit on screen.
When I tried putting putting a scrollable area into a window... I didn't get
very convincing results. The code below attempts to put a very large button
into a 300x300 size window. The scrollable does not track with the size of the
GtkWindow as I resize it... and I don't know why. I was expecting that as I
resize the GtkWindow the child scrollable would resize along with the client
area of the window. But it doesn't it just stays there the same size as it was
created.
GtkObject *h = gtk_adjustment_new(0, 0, 2000, 1, 10, 300);
GtkObject *v = gtk_adjustment_new(0, 0, 2000, 1, 10, 300);
GtkWidget *root;
GtkWindow *Wnd; // created before this code
if (root = gtk_scrolled_window_new(0, 0))
{
gtk_container_add(GTK_CONTAINER(Wnd), root);
gtk_widget_show(root);
GtkWidget *vp = gtk_viewport_new(GTK_ADJUSTMENT(h), GTK_ADJUSTMENT(v));
if (vp)
{
gtk_container_add(GTK_CONTAINER(root), vp);
gtk_widget_show(vp);
GtkWidget *btn = gtk_button_new();
if (btn)
{
gtk_widget_set_size_request(btn, 2000, 2000);
gtk_container_add(GTK_CONTAINER(vp), btn);
gtk_widget_show(btn);
}
}
}
I still fail to see the point, what is supposed to be in the UI ?
buttons labels text areas treeviews and notebooks and menubars and normal
stuff ?
Yes... but I want to use my own layout, not GTK's. It won't make me popular
here, but thats not my aim, I just want the app to look and behave the way it
does now. Most of the controls I have are owner draw, so they aren't GTK
buttons/labels/lists etc, but just need a drawable area that they can address.
Eventually I might migrate to GTK native layout for NEW projects, but the
existing code isn't going to be rewritten as I don't have time to do that.
is it a big canvas that you need to scroll around in ?
Nope.
Rather, what does an interface look like when you shrink it smaller
than its contents ?
Not much, it just starts clipping.
Do you just let buttons clip off to the right and the bottom ?
Yes.
--
Matthew Allen
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
