GNOME Bugzilla – Bug 679419
Refactor the GtkSourceCompletion class
Last modified: 2013-02-12 21:32:55 UTC
The GtkSourceCompletion class is quite big, and doesn't follow the Model-View-Controller principle. The purpose is to split this class into: - the GtkSourceCompletionManager class; - the GtkSourceCompletionView interface or abstract class; - GtkSourceCompletionViewFull implementing GtkSourceCompletionView. (The names are arbitrary: instead of "Manager", it can be "Controller"; instead of "View", it can be "UI"; …) We can imagine other implementations of the View, for example a more compact/minimal one. Another solution is to have only one View, but make it more flexible, with options like the height of the TreeView's rows; whether to display the little statusbar (with the 'Details' button); and so on. But it would make the code more complex. It's better IMHO to have several simple implementations than a single and complex one. Moreover, the interface/abstract class allows applications to implement their own View (and then proposing it for inclusion in GSV, hopefully ;). There would be a new API, and GtkSourceCompletion would be deprecated. But it's also possible to make all this refactoring internally, without changing the API. In any case, the GtkSourceCompletion would become an adapter to the new (internal or public) API. What do you think?
I think it sounds a lot like a case of javaitis :-) Jokes apart, splitting things in multiple classes can make things smaller but also increases the complexity for anyone working on it, not too mention the API footprint. I'd really prefer to have one and only completion that works out of the box. Stuff like proper sizing and the display of the Details button are things that need to be improved in the default implementation and should be driven by the content of the provider not by properties of the view itself
We can keep the Completion class for the GtkSourceCompletionManager that I mentioned above. I think it's anyway interesting to do the refactoring internally. The code of the Completion class is quite tricky, and there are more than 3000 lines of code. If we have only one View, for having a really compact completion window, there should be lots of options: - shrinking the height of the window, if there are only a few proposals; - shrinking the width of the window, if the proposals are short; - hiding the bottom bar, containing the details button and the label saying on which provider we are; - hiding the accelerators (1, 2, 3, …) on the right, for the first proposals; - reducing the height of each row of the GtkTreeView, if icons are smaller or hidden; - maybe other options. I think that only the option about hiding the details button and the bottom bar could be done automatically based on the contents of the providers. The other options require extra API. On the other hand, if we have different View classes, a full View would be used by default, so it doesn't add complexity for using the completion. If the application has basic needs, the CompactView could be used easily. And if the application has really specific needs, a custom View can be created.
Also, since the current API doesn't expose the completion window, there are some "duplicated" features that could be avoided with an exposed GtkWindow: - part of gtk_source_completion_show() - gtk_source_completion_hide() - the "show" and "hide" signals
Close, it's better to improve the current code.