On Mon, Jan 24, 2011 at 10:45:52PM +0100, Nacho wrote:> On Mon, Jan 24, 2011 at 10:40 PM, S*bastien Wilmet
> Hey
>
So if I understand there will be several times the same property in the> On Sat, Jan 22, 2011 at 09:36:19PM +0100, Nacho wrote:
> > * *Hey,
> > * *I would start with the document loader/saver etc, and once this is
> in a
> > * *standalone library
> > * *I would go for the widgets.
>
> OK.
> > * *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?
>
> At first glance it looks better, but now I'm facing a problem with
> 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 document is only created in the gedit-view-frame so this would be the
> one
> taking care of setting all the construct properties for the document and
> this one
> the properties for the loader and saver.
different classes that need this setting?
>> the same settings struct as gedit which is not correct.*
> 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).
>
> dunno, not sure I like this approach. Paolo/jesse can you give your
> opinion here?
> *
>
> 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.
>
> I don't like this, the reason is that the applications would depend on
> having
The app can return something like "org.gnome.app.libgedit", so all the
stuff specific to libgedit is in one place.
What I want to achieve with the libgedit is to be able to create new
IDEs in GTK the easier way. But it should be flexible enough. Here it's
more the fact that GSettings is needed that could be problematic I
think.
>
> 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.
>
> Maybe the dirs could be a singleton? So the app sets the dir for the
> application,
> i.e "gedit" or the init method could just take the name of the
> application.
> Opinions here also?*
>
> What do you think?
>
> > * *On Sat, Jan 22, 2011 at 9:31 PM, S*bastien Wilmet
> > * * *[1] [2][3]http://en.wikipedia.org/wiki/Bridge_pattern> > * *<[1][2]sebastien wilmet gmail com> wrote:
> >
> > * * *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][4]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][6]gedit-list gnome org> > * * *> * *<[1][4][5]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][7]http://mail.gnome.org/mailman/listinfo/gedit-list
> >
> > References
> >
> > * *Visible links
> > * *1. mailto:[8]sebastien wilmet gmail com
> > * *2. [9]http://en.wikipedia.org/wiki/Bridge_pattern
> > * *3. [10]http://en.wikipedia.org/wiki/Abstract_factory_pattern
> > * *4. mailto:[11]sebastien wilmet gmail com
> > * *5. mailto:[12]gedit-list gnome org
> > * *6. [13]http://mail.gnome.org/mailman/listinfo/gedit-list
> > _______________________________________________
> > gedit-list mailing list
> > [14]gedit-list gnome org
> > [15]http://mail.gnome.org/mailman/listinfo/gedit-list
>
> _______________________________________________
> gedit-list mailing list
> [16]gedit-list gnome org
> [17]http://mail.gnome.org/mailman/listinfo/gedit-list
>> 3. http://en.wikipedia.org/wiki/Bridge_pattern
> References
>
> Visible links
> 1. mailto:sebastien wilmet gmail com
> 2. mailto:sebastien wilmet gmail com
> 4. http://en.wikipedia.org/wiki/Abstract_factory_pattern
> 5. mailto:sebastien wilmet gmail com
> 6. mailto:gedit-list gnome org> 7. http://mail.gnome.org/mailman/listinfo/gedit-list
> 8. mailto:sebastien wilmet gmail com> 9. http://en.wikipedia.org/wiki/Bridge_pattern
> 10. http://en.wikipedia.org/wiki/Abstract_factory_pattern
> 11. mailto:sebastien wilmet gmail com
> 12. mailto:gedit-list gnome org
> 13. http://mail.gnome.org/mailman/listinfo/gedit-list
> 14. mailto:gedit-list gnome org
> 15. http://mail.gnome.org/mailman/listinfo/gedit-list
> 16. mailto:gedit-list gnome org
> 17. 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