From: hermann <bru...@we...> - 2011-04-19 04:45:40
|
Am Sonntag, den 17.04.2011, 18:16 +0100 schrieb pete: > On 17/04/11 00:17, pete wrote: > > On 15/04/11 19:00, hermann wrote: > >> Am Mittwoch, den 13.04.2011, 18:27 +0100 schrieb pete: > > >>> put the entire gx_head window in a scrolled window. default to the > >>> full > >>> size with no scrollbars visible. this will allow the app to at least > >>> be > >>> usable with smaller screen resolutions. perhaps a "small" theme would > >>> be useful here too. > >>> > >> I have play a lot with size/resize widgets and can say it isn't as easy > >> special when you wont to let it resize automatic when load unload a > >> plugin. Make the widget un-resizeable for the user helps here a lot, > >> otherwise it often comes to a race condition for the size settings (auto > >> or user) specially when a plugin is removed. > >> In older revisions there is a resize function in gx_gui_helpers.cpp > >> witch work for auto and user resized racks. > > > > i have an idea that may work. i'll try it out and report back. > > > ok here's the idea: > > check window size and screen size at startup. > if the screen size is too small, put the top level vbox into > a scrolled window (via a viewport) and put *that* into the > top level window. otherwise continue as normal. > > of course the screen size could shrink to below the minimum after > guitarix is loaded, but i can't think of any circumstances where this > would cause a problem in practice. we could reparent the widget > on the fly if it turns out to be necessary though. > > now the problem is, how do we detect the real window size, including > window decorations? the docs claim gtk has no reliable way of doing > this. xwininfo seems able to get this information so perhaps i'll > poke around that to see if there's an applicable method that is > "good enough" for us. > > i was also hoping to be able to disable resizing on the viewport > window instead of the top window, but i'm having some difficulty > getting this to work. there is no GtkWindow in the viewport > and the convenience functions return GdkWindows which are not usable > with gtk_window_set_resizable. however, the packing constraints > mimic the behavior of a fixed size window if the scroll pane is > smaller then the minimum application window size. since this is > _always_ the case when we resort to a scroll pane, perhaps it's a > non issue anyway. > > there's also an issue with the themes as the menubar now matches the theme. > i'm not entirely sure whether i'm now seeing the intended behavior > or whether this needs correcting. (the menubar now seems to display > the styles that are set in the corresponding gtkrc so perhaps it's > now working properly?) > > also, i did find a note in the gtk docs wrt to possible race conditions > and the use of gtk_window_get_size: > > "Note 1: Nearly any use of this function creates a race condition, > because the size of the window may change between the time that you get > the size and the time that you perform some action assuming that size is > the current size. To avoid race conditions, connect to "configure-event" > on the window and adjust your size-dependent state to match the size > delivered in the GdkEventConfigure." > > perhaps this might help resolve the underlying problem? > > pete. one of the main problems is when loading the main settings, plugs are loaded and change the gui size one by one, therefore I have used a counter to avoid the reaction of the auto-size handler. Then I had used a g_timeout_add_full(loop) to set reaction always at the end of the mainloop called by a on_check_resize() overload function (gtkmm). hermann |