Hi! (First mail after mailing list migration - hope anything works and you updated your mail filter).
1. Separate, anjuta interfaces (which is anjuta specific) and classess (if any) into separate module and leave libanjuta and interface generation as more generic library. The interface generation is not something we are very proud of, but until a better substitute comes in, I guess we can live with it. Vala dependency may not be desired by some projects, so alternatives could be provided as a way to generation IDL in multiple other ways?
Good point, maybe just move in into "interfaces" in the top-level. The library will still be called libanjuta-interfaces I guess but that shouldn't be a problem.
2. Consider a small and basic reference implementation of anjuta-shell (currently, implemented by anjuta-app using gdl) so that simple apps don't have to do it. Complex ones can simply derive from it.
Don't know if it is worth the effort now but we can certainly try.
3. Possibly, ship it in separate package (to allow API management). I suppose it's mostly packaging issue, but having it as a separate module would definitely set the correct mindset for distro packagers.
Well, it is not that difficult to do if someone requests it but I am not sure if we should do it now. 4. Move most of the widgets into some libanjuta-widgets library. Those aren't part of the application framework but are mainly used by anjuta plugins. 5. Port libanjuta to libpeas for plugin management reduce our maintaince burden on the plugin stuff. Some little fixes are needed in libpeas but it should mostly do it's job already and will give us more flexibility with plugin languages together with introspection. Regards, Johannes
Attachment:
signature.asc
Description: This is a digitally signed message part