Re: [Setup-tool-hackers] src/common/tool.[ch]



> The first thing I'd like to do after this next release is to make it
> so that the tool_*() functions take a ToolConext * as their first
> argument.
> 
> What I am running into with the network config is that basically each
> connection has a config dialog.  This dialog sadly looks and acts just
> like a main tool (same buttons etc) but I get to redo a lot of the
> code from tool.c.
> 
> Is there a really really good reason not to do this?

It's done this way to save code and make the frontends less complex (think
about callbacks), and because I thought one tool context per tool would be
enough for anyone. The alternative would be to have a global ToolContext
declared in each tool's frontend code, which would accomplish the same, or
keep it local and pass it around all the time.

What parts of the ToolContext are you re-using in the dialogs? I'm thinking
we could have something like a ToolDialogContext to satisfy the family of
complex dialogs. After all, ToolContext is intended for the entire tool, and
dialogs don't load/save configuration parameters from/to the backend. Or are
your dialogs behaving entirely like sub-tools?

--
Hans Petter



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