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

Re: gEDA-dev: [PATCH] gschem: remember dialog size and position



On Tue, May 01, 2007 at 11:30:20AM +0100, Peter Clifton wrote:
> On Tue, 2007-05-01 at 11:16 +0200, Ivan Stankovic wrote:
> > On Mon, Apr 30, 2007 at 10:29:39PM +0100, Peter Clifton wrote:
> > > I'd not inline the functions - they don't appear to be called in a
> > > performance critical path. Also, they might be useful outside the
> > > x_dialog.c code?
> > 
> > Perhaps, I didn't spend much time thinking of it.
> > The functions are only inlined if glib is older that 2.6.0 in which
> > case there's no point in wasting either time or space.
> 
> Ok, I'm not sure myself what the use-cases are for the inline keyword.
> Does the compiler usually decide inline / normal functions when
> optimising?
> 
> Does anyone have any advice / info on usage of the inline keyword. DJ?

>From http://gcc.gnu.org/onlinedocs/gcc/Inline.html:

"When a function is both inline and static, if all calls to the function
are integrated into the caller, and the function's address is never
used, then the function's own assembler code is never referenced. In
this case, GCC does not actually output assembler code for the function,
unless you specify the option -fkeep-inline-functions. Some calls cannot
be integrated for various reasons (in particular, calls that precede the
function's definition cannot be integrated, and neither can recursive
calls within the definition). If there is a nonintegrated call, then the
function is compiled to assembler code as usual. The function must also
be compiled as usual if the program refers to its address, because that
can't be inlined."

> > Yes, this is the way to go.  However, I have no desire to dive into the
> > glib object system.  If you (or anyone else) could come up with a GschemDialog 
> > or GedaDialog, I would be very happy to modify all of x_dialog.c to use
> > that.  In this light, I see my patch only as a temporary solution, something
> > that's usable until we get our own dialog widget that will handle all 
> > resizing and positioning automatically.
> 
> Assuming any people more knowledgeable than myself about best-practise
> GTK agree that a subclass of GtkDialog is the way to go, I'll write an
> implementation next week. It shouldn't be very long or complex.

Great, looking forward to it!

-- 
Ivan Stankovic, ivan.stankovic@fer.hr

"Protect your digital freedom and privacy, eliminate DRM, 
learn more at http://www.defectivebydesign.org/what_is_drm"


_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev