Re: misc questions

On 23 Jul 1999 14:40:27 -0400, <> wrote:

>Window placement and size: GtkWindow doesn't seem to have an easy way to get
>geometry information. Am I just plain stupid and looking in the wrong place?
>Would it be acceptable to use gtk+ style geometry handling for gnome session
>type stuff, or should I write in gnome style session handling in addition to
>plain gtk+?

IIRC it's the window manager's duty to save & restore window positions.
Problem is, I haven't seen a window manager that does it, yet.

>Bypassing themes: I like using gtk+ themes, but I need to control the background
>of a GtkText area over-riding my default theme. I've tried hacking up a quick
>gtkrc file to bypass it, and I've tried to over-ride it in my code, but no luck.
>I'd like to put in some kinda widget to allow users to select the background
>color and/or pixmap. (I can force the color on a non-pixmap theme, but those
>pixmap themes are so beautiful... :)

You should be able to assign a new GtkStyle to your particular GtkText
widget that has the desired settings in it. See gtkstyle.h and
gtkwidget.h. Something like mycopy = gtk_style_copy(widget->style);, then
modify mycopy, then gtk_widget_set_style(widget, mycopy);.

>Session management: The docs on session management aren't very clear on what
>really needs to be saved with the session. I know some apps need different
>things saved, but there should be a set of information common to all gnome apps,
> that I'm not totally clear on. 

Actually, the only thing that you have to save is the application-specific
information - the generic gnome stuff is supposed to be taken care of by
gnome-libs ;-)

>Autoconf: this one's really stupid :) is there a good way to detect where to put
>the help, desktop, and image files? Last tiem I actually compiled gnome, it
>defaulted to /usr/local (.30 cvs). I've been using the debian packages which
>default to /usr. Both ways make sense to me how they're done, but if someone
>downloads and installs my software, I want it to put itself in the right places
>without making people hunt down where their install is. My concern is for newbie
>and neophyte users who're used to that other os which has static places where
>the desktop files *WILL* be, so they get that brainless dropin install. If there
>isn't a slick cool way to automagically detect that, should it default to 
>/usr/local ?

You just install to whatever --prefix the person building the package

>Config files: I've been using ~/.bmud/ for my config files. Is this blatantly
>breaking some gnome convention? Should I plan on converting the gnome port to
>use gnome-config when gnome-config is finished?

I'd say that would be part of using GNOME to the fullest. :)

> Or should I attempt to keep the gnome and gtk+ ports using the same files? I don't wanna confuse someone
>who has a box with gnome and one without and is playing iwth my program :)

That depends if you expect the user to be editing ~/.bmud/* manually or

> Scripting language: mud clients have to have scripting languages, and
> I'm running a poll to see which one I should use. Perl seems to be the
> choice so far. If I do end up implementing perl, how important would
> putting in something like gtkperl or gnomeperl?

It would only be important if you wanted to allow the scripts to put up a
user interface of their own.

In the perfect world, you would have a generic scripting API in your
program, and then allow plugging in different scripting languages (such as
perl, python, guile, etc.).

> Gnomes coming along real nicely, it's stable and fairly fast. It seems
> fairly heavy memorywise, tho :( I only got 48m ram, when ya add on
> netscape, X, and all the other stuff, the gnome stuff goes straight into
> swap. Panel sits on like 4-10 megs, then there's half a dozen background
> things each sucking up a couple megs. I think the nicer gnome is
> memorywise, the better it'll be all around. Has there been serious efforts
> to reduce its memory footprints? Shared memory and service brokering can
> cut memory consumption down a lot (I know gnome does both, but could it
> do more/better?).

We've gone through in the past and tried to cut down memory usage, but I'm
sure there's more room for improvement. I'm not clear what you mean by
"shared memory" and "service brokering" and how they relate to memory
consumption, though.

-- Elliot

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