Hi, I expose here more in depth my ideas about the libgedit. First, for me the libgedit is a framework, not a library or toolkit (we could name it gedit-framework instead). A framework emphasize design reuse over code reuse. It dictates the architecture of the application. It defines the overall structure, its partitioning into classes and objects, how they collaborate, etc. A framework captures the design decisions that are common to its application domain (little summary of what is said in the Design Patterns book). And obviously the framework provides concrete classes so the application doesn't need to implement common things. Here for gedit, that means that a lot of classes should be put in the framework. And since a lot of them depends of GeditApp (it is a central point), my first idea was to begin with it. When I glanced through the code, I saw a lot of things that is interesting for any text editor or IDE. This includes almost everything, even the dialogs (except for the preferences) or some little things like tab-label, statusbar, rounded-frame, etc. But it includes also big classes like window, tab, commands-file, etc. For the window it is more for the design than for the code. When something is specific to gedit, we create a subclass which overrides some methods. That's how it would be done for other apps too for adding IDE specific stuff. As explained in this mail [1], to be able to do this framework, some design patterns like an abstract factory and a bridge have to be used. This doesn't solve the problem of what we do with the settings (see the discussion here [2]). Also, for some classes it is possible to be completely independent of the framework so an application can use directly some widgets without the need of using all the framework. So what are your opinions? [1] http://mail.gnome.org/archives/gedit-list/2011-January/msg00041.html [2] https://bugzilla.gnome.org/show_bug.cgi?id=640601
Attachment:
pgpRT7nkyTx6K.pgp
Description: PGP signature