quickly-talk team mailing list archive

[tony byrne <tony.badwolf@xxxxxxxxx>]

I think the refactoring is a very good idea, just that plenty of
thought needs to go into it. Having lots of classes hidden away in a
library simplifies the users work. However I think upgrade having
complete overwrite control of bin/<foo> is going too far.

Another argument for quickly developers having to put up with users
editing bin/<foo> is that sometimes you need thread support in your
project, which has to happen before gtk.main(). However if we look at
setup.py a solution presents itself.

##################################################################################
###################### YOU SHOULD MODIFY ONLY WHAT IS BELOW
######################
##################################################################################

if __name__ == "__main__":
   # Support for command line options.  See helpers.py to add more.
   helpers.parse_options()

   # Run the application.
   preferences.db_connect()
   preferences.load()
   window = camel_case_nameWindow()
   window.show()

    # a large project might need constructor code like this
    # model view presenter pattern
    from python_name import models
    from python_name import presenters
    foo_model = models.Foo()
    foo_presenter = presenters.Foo(window.builder)
    foo_model.connect('update', foo_presenter.on_model_update)
    foo_model.connect('complete', foo_presenter.on_model_complete)

   # a user might need to do this !
   glib.threads_init()

   gtk.main()
   preferences.save()

This makes update only a little more difficult for quickly upgrade,
which now has to respect the comment in setup.py and bin/<foo>.

On 16/02/2011, Michael Terry <michael.terry@xxxxxxxxxxxxx> wrote:
> On Wed, 2011-02-16 at 01:11 +0000, tony byrne wrote:
>> I think "upgrading" the user's code is fraught with risk. Most users
>> would not be contributors but could easily bug-fix some of the quickly
>> supplied code in their project. If an upgrade is automatic it would
>> need to compare the user's code with the maverick supplied code, or
>> perhaps even the lucid codebase, before overwriting. Perhaps the
>> upgrade could be a user controlled process similar to upgrade-manager,
>> listing the changes and allowing partial upgrades.
>>
>>  Do you intend to upgrade projects or the templates in
>> ~/quickly-templates or both ? What about chains of templates or
>> projects derived from ~/quickly-templates/my_template ?
>
> I think I wasn't clear.  When I say 'upgrade' I mean only upgrades of
> project_root code in the user's project when that user runs 'quickly
> upgrade'.  So it's a manually triggered process and doesn't touch
> templates.
>
> It's not that I think user modifications of the project_root code have
> broken anything, but that user modifications of the project_root code
> make it difficult to successfully upgrade code.  That's why I want to
> separate them a bit.
>
> But your feeling that we can just give them code and they'll deal with
> it is good.  That's by and large what we do, but I'd like the capability
> of upgrading if needed (i.e. some bug that we fix that not everyone may
> have fixed).  Usually though, we do it to add new features (like
> indicator support or whatever) and the new layout would make that much
> easier.
>
> Since you seem unconcerned about upgrading, I'm assuming your answer to
> the question of whether it is OK to refactor like this without allowing
> upgrading into it to be that it is OK.
>
> --
> mterry
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~quickly-talk
> Post to     : quickly-talk@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~quickly-talk
> More help   : https://help.launchpad.net/ListHelp
>