> 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. > 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. Alright. I'm a bit new to Gtk 2 and didn't realize what a "cell" was. Google is our friend. > 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. This is was I was thinking of, and I still believe it'd be the least confusing solution. > 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 :-) 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. Thanks for putting up with my rambling. :-)
Attachment:
signature.asc
Description: This is a digitally signed message part