RE: Small question...



I'm in a similar situation, "swithering" between Gnome and pure GTK.
However, 
fortunately I'm not at the stage where I already "wrote the app the hard
way", 
though!

I'm using GnomeMDI at the "top level". Opening an object from here, I create
a 
new top-level window for editing (roughly the same way the GIMP works). I
was 
going to use

        gtk_window_new(GTK_WINDOW_TOPLEVEL)

at this point, but I'd rather use a Gnome app, so I can the UI builder for
the 
menus on this window.

Is it OK to create multiple gnome_app's? I've tried it and it seems to work,
but
am I slowly corrupting some "created-once-only" data structures, e.g. global

variables, or the equivalent of "Class Members" in C++ ?

Also, I don't know what effect this will have on session management.

I can't, unfortunately use the UI builder for the toolbars in the edit
window 
(at least not yet) since I need more than one, and also I need to put
arbitrary 
widgets in the toolbars, which libgnomeui doesn't (appear to) support (yet).

I guess the best way to handle this is to create toolbars manually (from a
table
which is as close as I can get to the UI builder data :-) and add them to
the 
gnome_app's dock. .... Yes?

Another couple of things that I've been trying to find an answer for, for a 
while: what's the best way of setting an initial size for an application's
main 
window? When my MDI window is created, the MDI has no children, so it
doesn't 
requisition any space, giving me a tiny window with only the menubar and
toolbar
in it. After adding a view to the MDI, it resizes itself, but is still to
small 
to be useful, so I then have to drag the WM's handle.

Question: what's the best way of setting a sensible default? Even if I have
to 
do a calculation based on, say, half the screen size - what widget would I
do 
the gtk_widget_set_usize on - the app's main window or the (childless) MDI?

I've also noticed some strange behaviour when an app's main window is
initially 
created. Some applications appear to resize the window immediately after it
is 
shown. This has happened to code I've written, so I don't think it's the 
application's code which is responsible, unless there's some trick to the
order 
things are created/shown in.

It's most evident if the WM is configured the way mine is: ActivePlacement, 
SmartPlacement (fvwm2). Starting up, e.g. gwp, the WM (if it goes for 
ActivePlacement) will offer me an outline of a small (something like
350x100) 
window. Once I've placed the outline where I want it, the window appears and

immediately resizes to something more sensible.

If, however, there is enough unused desktop space (rare :-) to fit in a
350x100 
window, the WM will "SmartPlace" it in, say, the bottom left of the screen,
and 
the window will immediately resize, resulting in about 90% of it being off
the 
bottom of the screen.

If, however, the window had been properly sized before it was mapped, the WM

would have offered me ActivePlacement of the correct-sized outline.

This is VERY annoying .... is there anything I can do about it? I'll hack 
gnome-libs if I have to :-)

I don't want to be forced to use RandomPlacement - one of the goals of Gnome
is 
that you can use any WM/WM-config you like.

Allan

______________________________ Reply Separator
_________________________________
Subject: Re: Small question...
Author:  "Havoc Pennington" [SMTP:hp@Mcs.Net] at Internet
Date:    3/3/99 6:32 AM


On Mon, 1 Mar 1999 hack@altavista.net wrote:
> I am thinking of porting a GTK+ app. to Gnome... but I won't add any
> Gnome menubars or something. Are there any reasons (advantages) that my 
> app will have ones it has been ported to Gnome? In other words: why the 
> hell would I port it to Gnome??
     
 - consistent look and feel (if you use GnomeApp and GnomeDialog,
   especially)
 - consistent, pre-written config file library 
 - nice session management infrastructure
 - gdk_imlib lets you load images
 - GnomeCanvas is nice if you app needs it
 - CORBA is available, and libgnorba authentication library 
 - lots of convenience functions and widgets, though this is
   less useful if you already wrote the app the hard way
 - ZvtTerm terminal widget
 - GnomeMDI
 - Global user-configurable preferences for many things Gtk apps
   hardcode
 - File metadata
 - Printing architecture
 - Online help facility (launches the help browser or user-configurable
   browser)
 - Internationalization built-in
 - popt argument parsing
 - Bonobo/Baboon object embedding architecture 
 - Special window manager hints
     
I'm sure other people can add more reasons. :-)
     
Some of these things are available as separate modules too, but it sure is 
easier to use gnome-libs now that gnome-libs is nice and stabilized.
     
Havoc
     
     
     
--
To unsubscribe: mail gnome-devel-list-request@gnome.org with "unsubscribe" 
as the Subject.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]