Re: Scaffold API proposal 0.2

["John (J5) Palmieri" <johnp martianrock com>]

On Fri, 2004-01-23 at 18:36, Samuel Kaufman wrote:
> On Fri, 2004-01-23 at 05:17, John (J5) Palmieri wrote:
> > > 
> > > In the Document interface: what's the point of get_editable()?  Am I
> > > missing something?
> > 
> > If the document can be edited or if it is read only.
> 
> Sorry.  Bad phrasing.  I meant to ask for examples of when it might
> actually be used.  It certainly couldn't hurt, but I'm curious.

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();

> > > UIDataTarget: This interface seems like overkill.  It seems intended to
> > > solve such a small, specific set of problems.  It could be much more
> > > cleanly and easily handled by each specific interface/plugin.  My two
> > > cents.
> > 
> > Not realy.  The problem extend to other plugins which may have small
> > scopes but in the presence of other plugins their functionality is
> > expanded in ways the origonal developer did not think of.  For instance
> > the code editor has no concept of breakpoints but a dubuger needs to
> > visualy show them.  It can get a path to the editor's sidebar and
> > implement breakpoints.  Yes this can also be put into the editors code
> > but in reality the editor should have not knowledge of breakpoints.  I'm
> > not sure I like the interface as it is right now but I haven't had time
> > to read it in depth.  The idea is sound however.
> 
> That makes sense, but wouldn't the plugin writer have to place
> UIDataTargets into their interface in the first place?

Yes but you miss the purpose of an interface.  An interface defines how
objects will interact in a standard way.  This way we don't have a
different way of doing this for multipule plugins. The usage might vary
from plugin to plugin but the API stays the same.

> > >  - /Documents
> > >  - Text documents collection (each child of this node implements the
> > >  - TextDocument interface)
> > > TextDocuments?  Not the Document interface?
> > 
> > TextDocument would be a child of the Document interface.  Documents
> > would be a collection of document interfaces I belive.  There are other
> > such documents such as a GladeDocument for widget canvases.
> 
> I understand.  It's just an error in the proposal.  "...each child of
> this node implements the Document interface."

I see the confusion.

> > > Will there be anything analogous to workspaces or "solutions" consisting
> > > of multiple projects?  Will multiple projects be able to be opened
> > > simultaneously?
> > 
> > I don't see why so much.  You can open up two or more instances of
> > Scaffold and with sessions opening up a project should bring you to
> > where you left off when you closed it.  Since loading a project is
> > fairly quick you could just use the recent menu to switch between
> > projects.  Is there a reason why you would want this functionality?
> 
> Nested projects and common projects.  An IDE is supposed to make the
> coding process faster and more efficient - I don't want to spend my time
> having two Scaffold processes running 

Not realy time consuming.

> or closing and opening other
> projects 

Like I said it is almost instantanious and if we do the projects right
it will open up right where you left off right down to the row and
column you were on when you last closed the project.

> when I'm working on, say... Scaffold and libscaffold at the
> same time.

Im not sure this is a good example because Scaffold and libscaffold
reside in the same project and you would have access to both.  A better
example would be Scaffold and one of its plugins such as Glimmer.  I can
see how having multipule projects open can be benificial.  It is a
question of whether the advantages outweigh the disadvantage of putting
complexity into the project code.  Please elaborate on how you would
like this done.

The way I see it the project manager could just load two projects and
display them in the same project tree with different roots.  Or it can
creat two tabs, one for each project (whcih means you have a project tab
and then the two tabs undernieth).  But then how would you deal with the
build button?  Which project gets built?  Both? And in what order?  I
suppose we could work it like the back button widget on a browser where
it has a main button and a dropdown list.  The dropdown list would list
the projects with a checkmark next to the default project.   Clicking on
either project would start the build on that project and make it the
default.  Clicking on the main button would just compile the default. 
But then you have to think about how all these componets would speak to
each other to say hey, I have more than one project.  If you can
identify what needs to change in order to support multipule projects
then perhaps it can be implemented :-)

--
J5