On Sat, Jan 22, 2011 at 09:36:19PM +0100, Nacho wrote:OK.
> Hey,
> I would start with the document loader/saver etc, and once this is in a
> standalone library
> I would go for the widgets.
At first glance it looks better, but now I'm facing a problem with
> In relation to the settings, I feel like they should be properties of the
> widget, so the
> widget doesn't make a directly use of gsettings and it is the app using
> the library the one that
> it does.
> What do you think about this?
gedit-document-loader which depends on one setting from GSettings. If I
replace this setting by a property, when we create a new instance of
document-loader, we must fill this property with the value from
GSettings, right? The application doesn't use directly document-loader,
instead it is created in gedit-document (and only there). But
gedit-document shouldn't depend on GSettings too, so here is the
problem. At first I thought creating the property directly in
gedit-document would solve the problem, because document-loader has a
reference to a gedit-document. But gedit-document is not created
directly by the app, it is created in several other files:
gedit-view-frame, gedit-output-stream, gedit-document-saver and a few
others.
The approach that I explained previously is easier for this case. We
could create an interface with a getter and/or a setter for each
setting, the lib would use this interface which would be implemented in
the apps by using GSettings (or whatever).
Another way is to have a virtual function (or with an interface) that
returns the string "org.gnome.gedit", so we use directly GSettings in
the lib.
Also, what I did for gedit-metadata-manager could have been made
differently: create an interface for gedit-dirs and use directly these
functions inside the lib.
What do you think?
> On Sat, Jan 22, 2011 at 9:31 PM, S*bastien Wilmet
> [1] [2]http://en.wikipedia.org/wiki/Bridge_pattern> Hi,
>
> I've read a little all the code, and most of it can be reused easily. In
> some files there is just the strings "gedit" or "org.gnome.gedit" (for
> GSettings) which must be moved in functions (e.g. in GeditApp).
>
> GeditWindow is quite big and a lot of things are specific to Gedit
> there, so it will involve more work.
>
> For GeditApp and its subclasses (GeditAppX11 etc), some work must also
> be done to be able to subclass GeditApp independently of the
> implementation. For doing this we can use a bridge [1].
>
> And since GeditApp is a singleton, GeditApp must be instantiated with
> the subclass. For this I've thought adding a static function in GeditApp
> like gedit_app_set_instance (). We call gedit_sub_app_get_default ()
> first, which call gedit_app_set_instance () with the instance of
> GeditSubApp. It works but there is maybe a better approach.
>
> For creating objects, an abstract factory [2] is a good choice I think.
>
> If an application wants to override a method in a subclass, this method
> has to be declared virtual in the parent class. Therefore all (or just
> for some classes) public methods should be virtual.
>
> There are some other things to handle, for example:
> * * * *- which names will we give to subclasses? Or we rename all
> * * * *Gedit* classes to LibGedit* or whatever?
> * * * *- libpeas and plugins support should be optional.
> * * * *- the preferences dialog can not be reused, but the majority of
> * * * *its sentences can be reused (so translators have less work).
> * * * *- what to do with config.h?
> * * * *- how to reuse gedit-ui.h?
> * * * *- and a lot of other little things...
>
> What do you think? The first thing I want to do is the bridge for
> GeditApp and resolve the problem of subclassing the singleton.
>
> [2] [3]http://en.wikipedia.org/wiki/Abstract_factory_pattern
> On Sun, Jan 02, 2011 at 01:05:28AM +0100, Nacho wrote:
> > * *Hey,
> > * *cool then, but I feel like this is going to be quite a lot of work
> :) also
> > * *I suggest you to drop
> > * *by irc and discuss about the ways to do it.
> > * *Regards and thanks for caring about doing this.
> >
> > * *On Sun, Jan 2, 2011 at 1:00 AM, S*bastien Wilmet
> [5]gedit-list gnome org> > * *<[1][4]sebastien wilmet gmail com> wrote:
> >
> > * * *Hello,
> >
> > * * *I don't know if you remember, in August I had a discussion on IRC
> about
> > * * *libgedit, i.e. creating a framework based on the source code of
> Gedit
> > * * *for creating new IDEs easily.
> >
> > * * *You agreed with the idea and you said that the API could change
> from
> > * * *versions to versions, so the applications must follow the
> development
> > * * *and make some changes if needed. There is also the possibility to
> stay
> > * * *with a particular version, either by copying all the source code,
> or by
> > * * *having several versions of the libgedit installed (different
> *.so), but
> > * * *it will annoy packagers I think, especially if it's only for one
> or two
> > * * *apps.
> >
> > * * *I'll do all this work during the next months as part of my
> studies, as
> > * * *Steve Fr*cinaux already knows*.
> >
> > * * *This framework will be integrated to Gedit itself obviously, but
> also to
> > * * *LaTeXila, an Integrated LaTeX Environment written in Vala. The
> "text
> > * * *editor" part is inspired from Gedit, so the port won't be so
> difficult I
> > * * *think.
> >
> > * * *I hope it will be useful for other projects too. For some tasks
> an
> > * * *independent application is easier for the user than plugins.
> Although
> > * * *the profile feature would make the life easier too.
> >
> > * * *Best regards,
> > * * *S*bastien
> >
> > * * *PS: Happy new year!
> >
> > * * ** I'll do an internship where he works :) But the Gedit stuff is
> not
> > * * *part of the internship.
> _______________________________________________
> gedit-list mailing list
> [6]http://mail.gnome.org/mailman/listinfo/gedit-list
>
> References
>
> Visible links
> 1. mailto:sebastien wilmet gmail com
> 2. http://en.wikipedia.org/wiki/Bridge_pattern
> 3. http://en.wikipedia.org/wiki/Abstract_factory_pattern
> 4. mailto:sebastien wilmet gmail com
> 5. mailto:gedit-list gnome org
> 6. http://mail.gnome.org/mailman/listinfo/gedit-list
> _______________________________________________
> gedit-list mailing list
> gedit-list gnome org
> http://mail.gnome.org/mailman/listinfo/gedit-list
_______________________________________________
gedit-list mailing list
gedit-list gnome org
http://mail.gnome.org/mailman/listinfo/gedit-list