Re: Scaffold API proposal 0.2

[Gustavo Giráldez <gustavo giraldez gmx net>]

Hi,

On Sat, 2004-01-24 at 14:38, Samuel Kaufman wrote:
> > The same way something similar is used in gedit.  If the user doesn't
> > have  rights to edit the file get_editable will return FALSE and input
> > would be dissallowed on the window.  Perhaps a better name would be
> > is_editable();
> 
> Ah.  Foolish of me.  Obviously the widget using the document would need
> to know if it's read-only or not.

More than a widget, a plugin who retrieves and uses a document object
would want to know whether it's editable or not.  Imagine the text
utilities plugin, for example.  They usually work on the currently
selected document, but they have to know somehow if they can edit the
text or not.

<snip>

> By simply implementing the concepts of multiple projects and
> dependencies into the project manager design.  I can't think of much
> else that would be affected.  In the Value Repository... /Project needs
> to be /Projects, etc.  It'd be reasonably trivial thing to code, though
> it would add some complexity to the design.   Project dependencies would
> be the only real challenge.
> 
> It depends heavily on whether Scaffold will be using a Makefile-based
> build process or an internal one.  Or offering a choice of either. 
> Using Makefiles, even the dependency idea could be more-or-less
> dropped... as make will handle building dependencies.  It would
> essentially boil down to calling "make" on each project - though that
> would be the slightly hackish solution.
> 
> As for the UI, I think just listing each project's root in the project
> manager is the cleanest solution.  The default build button could build
> all the projects.  There would be a "Don't Build" check in the context
> menu to keep it from being built by default.  There would also be a
> "Build" button in the context menu to build that specific project.

Another option I mentioned in another mail would be to implement a
meta-project Gnome build backend.  I.e. a backend which would open
several other gnome-build project.  Interdependencies would be set in
the meta project configuration.

I think this would be the cleanest and easiest solution.  For build
targets the meta backend can mangle the descriptions of the child
projects to present the user a coherent list.

I have yet to find a fundamental flaw in this approach :-)

> Thanks for putting up with my rambling. :-)

Absolutely no rambling.  Thanks a lot for your comments.

Regards,
Gustavo