pygtkmvc-users — The public mailing list of python-gtkmvc

Re: [gtkmvc-users] SVN aligned with master branch

[Roberto C. <rob...@gm...>]

On Sun, 2010-10-10 at 16:20 +0200, Tobias Weber wrote:
> On 09.10.2010, at 23:48, Roberto Cavada wrote:
> 
> > I just closed the activity for aligning master branch to SVN trunk.
> 
> Great! Sorry I hadn't done it yet, was waiting for some tickets to be resolved.
> 
> I ran the tests and committed small fixes, hopefully using svn correctly.
> 
> http://github.com/Wile/gtkmvc/commit/756cd391ce577854b76c733a1f96c0187a6fe887
> 
> ^ you left out the createTables method, which breaks tests/sql.py. Is this on purpose? It might create unnecessary tables depending on what you import, but usually it's very convenient, and users can still do it manually.

I am afraid I left it out by mistake :( 
I saw the commitment, but I thought I already ported it in.
Thaks, fixed in rev. 168


> > After I have stabilized the trunk, I'd like to close and merge my experimental branches which are not public.
> 
> You mean merge them into the public trunk? Do you want to discuss first?
Sure! They address:
1. Renaming custom value properties to "logical properties" (LP)
2. Making LP  getter/setter pair explicit, using decorators instead of
implicit naming convention
3. Support for dependencies among LP

We can discuss 'em in details if you want.
r.

Re: [gtkmvc-users] From names to widgets

[Tobias W. <to...@ce...>]

On 10.10.2010, at 00:02, Roberto Cavada wrote:

> I am resuming this one:

Should we use?
https://sourceforge.net/apps/trac/pygtkmvc/ticket/3

> What is AbstractView view for (common base class?)

Yes

> We may even change View to GladeView, and keep View deriving from AbstractView and being the base class for both GladeView and BuilderView.

Why only change the name?
What code would go into View that couldn't go into AbstractView?

> Of course GladeView would break compatibility, but we are addressing 2.0 here.

So you would introduce GtkBuilder support in 1.99.1 and already change it in 2.0? I think we need some stability to attract users.

>> If desired there could be automating switching based on the presence of the glade/builder attribute using __new__.

> You mean building a either a GladeView or BuilderView depending on the presence of one of the two attributes?

Yes. But now that I think of it users whould have to eschew direct parent calls for super(), which is a problem.

Re: [gtkmvc-users] SVN aligned with master branch

[Tobias W. <to...@ce...>]

On 09.10.2010, at 23:48, Roberto Cavada wrote:

> I just closed the activity for aligning master branch to SVN trunk.

Great! Sorry I hadn't done it yet, was waiting for some tickets to be resolved.

I ran the tests and committed small fixes, hopefully using svn correctly.

http://github.com/Wile/gtkmvc/commit/756cd391ce577854b76c733a1f96c0187a6fe887

^ you left out the createTables method, which breaks tests/sql.py. Is this on purpose? It might create unnecessary tables depending on what you import, but usually it's very convenient, and users can still do it manually.

> After I have stabilized the trunk, I'd like to close and merge my experimental branches which are not public.

You mean merge them into the public trunk? Do you want to discuss first?

> I see there are also some other branches, what is their status?

Those are features I experimented with. They work, but break compatibility. Should I create tickets? One already exists:

https://sourceforge.net/apps/trac/pygtkmvc/ticket/17

> Should I explore the opportunity to merge some of them as well?

I think they're worth a look, but probably not before 2.0

Re: [gtkmvc-users] From names to widgets

[Roberto C. <rob...@gm...>]

Hi,
 I am resuming this one:

On Wed, 2010-03-24 at 12:15 +0100, Tobias Weber wrote:
> I propose two new classes, AbstractView and BuilderView, so that
> libglade is restricted to View. This makes for much cleaner code. 

I like the idea. View is currenlty overwhelmed. What is AbstractView
view for (common base class?)

We may even change View to GladeView, and keep View deriving from
AbstractView and being the base class for both GladeView and
BuilderView.

Of course GladeView would break compatibility, but we are addressing 2.0
here.  

> If desired there could be automating switching based on the presence
> of the glade/builder attribute using __new__.

I don't get this one. You mean building a either a GladeView or
BuilderView depending on the presence of one of the two attributes? 

r.

[gtkmvc-users] SVN aligned with master branch

[Roberto C. <rob...@gm...>]

Hi Tobias, 
 I just closed the activity for aligning master branch to SVN trunk.
After I have stabilized the trunk, I'd like to close and merge my
experimental branches which are not public.

I see there are also some other branches, what is their status? Should I
explore the opportunity to merge some of them as well?

Thanks,
r.

Re: [gtkmvc-users] Backwards compatability

[Tobias W. <to...@ce...>]

On 27.09.2010, at 11:14, Roberto Cavada wrote:

> Do you have a list of the tests which have to be updated/fixed?

Almost all
http://github.com/Wile/gtkmvc/tree/master/tests/

> General issue: I would like two have tickets on the tracker to keep track of issues we deal with.

I don't like Trac, but something has to happen. It should now cover at least this mail.

Re: [gtkmvc-users] Backwards compatability

[Roberto C. <ca...@fb...>]

Ciao Tobias,

[A-side note for the users: feel free to jump-in if you have 
something to tell the list]

Il 09/26/2010 04:46 PM, Tobias Weber ha scritto:

> the very next thing I would do to SVN is update the 1.2 tests.

Do you have a list of the tests which have to be updated/fixed?

General issue: I would like two have tickets on the tracker to keep 
track of issues we deal with.

> The question is whether to copy them first to check future releases for backwards compatibility.

1.99.x family was thought right do break compatibility with 1.x 
until 2.0 comes. However when easy, we may think to try keeping 
compatibility by exploiting conditional code (depending on some 
option). In general I prefer to keep the code smooth and clean, so 
the criteria for deciding if an incompatible feature is supported 
with conditional code may be:
1. importance/diffusion of the feature
2. was the issue public (i.e. documented)
3. impact on the code base (limited to a few local lines?)
4. impact on the documentation (do we need to keep the old behaviour 
documented? will the old behaviour become deprecated and eventually 
disappear? Or will it remain stable?)

In this specific case, I would keep the old behaviour for 
1.99.0-based applications as it has a very limited impact on the 
code. 1.99.1 will feature the new behaviour. We need to document the 
choice, and make available the options set for controlling the 
framework.

About copying tests: not needed, if we break compatibility, we can 
rely on a svn tag (to be created) for testing old version.

 > Where do we make the cut?
In 1.99.1

 > Is a 1.99.0-comatible release with backported fixes necessary?
No, provided the user can have some control on some 
backward-compatible behaviours via the options.

 > Is GtkBuilder support enough to warrant 2.0?
Mmm, this opens the general question: what 2.0 will bring?
I think we should aim to release 1.99.1 first, as 2.0 requires some 
further discussion.

 > BTW gtkmvc.require would have to raise if it is too *high*
Indeed, until we reach a stable point.

ACTIONS:
1. open issue for the changed behaviour, to keep track of it.
2. add options to the framework (to be analyzed)
3. make the changed behaviour code backward-compatible depending on 
a specific option (iff impact on code is low)
4. document it
5. fix tests

Cheers,
r.

ps.From Oct 4 to Oct 15 I will the chance to dedicate 2 hours a day 
to the project (at last!!). By the 15 I hope we are in good shape to 
think about a possible release date. I am working this week on the 
release plan.

[gtkmvc-users] Backwards compatability

[Tobias W. <to...@ce...>]

Hi,
the very next thing I would do to SVN is update the 1.2 tests. The question is whether to copy them first to check future releases for backwards compatibility.

The 1.99.0 documentation did not promise anything, but as long as users replace the positional argument, old code should work:

- View.__init__(self, ctrl, "adapters.glade")
+ View.__init__(self, "adapters.glade", controller=ctrl) 

Right up to r154 that is: "if an adapter was passed prop_write on creation this is now called *instead of* casting the value from the widget to the type of the old property value. It used to be called after the cast. This was the intended behaviour all along, but breaks even some of our sample code."

Where do we make the cut? Is a 1.99.0-comatible release with backported fixes necessary? Is GtkBuilder support enough to warrant 2.0?

BTW gtkmvc.require would have to raise if it is too *high*

Re: [gtkmvc-users] Problems using SQLObjectModel

[jon l. <mo...@ca...>]

Hi,

El lun, 20-09-2010 a las 19:07 +0200, Tobias Weber escribió:
> On 20.09.2010, at 18:05, jon latorre wrote:
> 
> > Now, going to the subject, I can't use the SQLObjectModel. I'm very interested in using it and have beeing playing with the example code found in python-gtkmvc-1.99.0/examples/sqlobject/
> 
> SQL support was a preview in that release, you need the development version. SVN will be updated, until then http://github.com/Wile/gtkmvc
> 
> See tests/sql.py
> 
> Be aware that the API may change!

Now it runs! Thanks for the help. If I will decide to use svn version
I'll will have and eye on the API in case it changes. by the way if I
can help in anyway tell me how.

Bye.

Re: [gtkmvc-users] Problems using SQLObjectModel

[Tobias W. <to...@ce...>]

On 20.09.2010, at 18:05, jon latorre wrote:

> Now, going to the subject, I can't use the SQLObjectModel. I'm very interested in using it and have beeing playing with the example code found in python-gtkmvc-1.99.0/examples/sqlobject/

SQL support was a preview in that release, you need the development version. SVN will be updated, until then http://github.com/Wile/gtkmvc

See tests/sql.py

Be aware that the API may change!

[gtkmvc-users] Problems using SQLObjectModel

[jon l. <mo...@ca...>]

Hi,

I'm new to this fantastic framework. First of all, thanks for creating
it! It's very usefull! 

Now, going to the subject, I can't use the SQLObjectModel. I'm very
interested in using it and have beeing playing with the example code
found in python-gtkmvc-1.99.0/examples/sqlobject/

If I launch it without any changes it runs OK. But it doesn't create the
sqlite database. Ok, i check the code and edit it so it looks like:

....
__connection__ = "sqlite:///tmp/person"


# ----------------------------------------------------------------------
class Person(SQLObjectModel):
  _connection = __connection__
  fname = StringCol()
  mi = StringCol(length=1, default=None)
  lname = StringCol()

....

Now it creates the database but fails to run. It throws the following
error:
----------------------------------------------------------------------
$ python basic.py 
Traceback (most recent call last):
  File "basic.py", line 39, in <module>
    p = Person(fname="John", lname="Doe")
  File "/usr/lib/pymodules/python2.6/gtkmvc/model.py", line 490, in
__init__
    InheritableSQLObject.__init__(self, *args, **kargs)
  File "/usr/lib/pymodules/python2.6/sqlobject/main.py", line 1223, in
__init__
    self._create(id, **kw)
  File "/usr/lib/pymodules/python2.6/sqlobject/inheritance/__init__.py",
line 384, in _create
    connection=self._connection)
  File "/usr/lib/pymodules/python2.6/gtkmvc/model.py", line 490, in
__init__
    InheritableSQLObject.__init__(self, *args, **kargs)
  File "/usr/lib/pymodules/python2.6/sqlobject/main.py", line 1223, in
__init__
    self._create(id, **kw)
  File "/usr/lib/pymodules/python2.6/sqlobject/inheritance/__init__.py",
line 391, in _create
    super(InheritableSQLObject, self)._create(id, **kw)
  File "/usr/lib/pymodules/python2.6/sqlobject/main.py", line 1271, in
_create
    self._SO_finishCreate(id)
  File "/usr/lib/pymodules/python2.6/sqlobject/main.py", line 1295, in
_SO_finishCreate
    id, names, values)
  File "/usr/lib/pymodules/python2.6/sqlobject/dbconnection.py", line
403, in queryInsertID
    return self._runWithConnection(self._queryInsertID, soInstance, id,
names, values)
  File "/usr/lib/pymodules/python2.6/sqlobject/dbconnection.py", line
262, in _runWithConnection
    val = meth(conn, *args)
  File
"/usr/lib/pymodules/python2.6/sqlobject/sqlite/sqliteconnection.py",
line 220, in _queryInsertID
    self._executeRetry(conn, c, q)
  File
"/usr/lib/pymodules/python2.6/sqlobject/sqlite/sqliteconnection.py",
line 186, in _executeRetry
    raise OperationalError(ErrorMessage(e))
sqlobject.dberrors.OperationalError: no such table: sql_object_model
----------------------------------------------------------------------

In debug mode I can see that it fails to check for sql_object_model
table in the database (it doesn't exits). I have tryed with mysql with
similar results.

What I'm doing wrong?

Thanks in advance.

Re: [gtkmvc-users] Bug and release

[Rob Brown-B. <r.b...@gm...>]

On Sat, Aug 21, 2010 at 7:12 PM, Tobias Weber <to...@ce...> wrote:
> On 20.08.2010, at 20:44, Rob Brown-Bayliss wrote:
>
>> What is broken in GtkBuilder?  Is it the naming of widgets?
>
> http://github.com/Wile/gtkmvc/commit/e4d1d4fc5e39aa17837af302c32a3aee2d4330fe
>
> You can probably get away with changing one line.
>

Ok,

I am doing this sort of thing (not using gtkmvc) where t is a gtk
container (table in this case) in a gtk builder glade file:

for c in t.get_children():
    name = gtk.Buildable.get_name(c)   # Can't use c.name but this
might change in the future.
    # Do stuff.

Sounds like the same issues, I used to just do c.name

>From what I discovered, though I didn't look to hard, it's not
considered a bug and wont be fixed.  Shame as it was a useful 'bug'

See https://bugs.launchpad.net/ubuntu/+source/pygtk/+bug/507739


Cheers

-- 
--

Rob

Re: [gtkmvc-users] Bug and release

[Roberto C. <ca...@fb...>]

Hi,

Il 08/20/2010 02:51 PM, Tobias Weber ha scritto:

> recent Gtk releases (e.g. shipped with Ubuntu Lucid) break the GtkBuilder support in the SVN version of pygtkmvc.

 >

> By now I seriously recommend using my collection of patches at http://github.com/Wile/gtkmvc instead.
>
> Even if Roberto is still busy we should continue working towards a release so people don't forget about the library. It'd be great if everybody could quickly run the tests on their system. It's easy and doesn't mess with any installed version:

To me is much more sensible to include in the official SVN repo the 
fixes you and others made in these months.

If you agree, I would ask you to send individual fixes/changes you 
made, in order to evaluate them one by one. I remember one which I 
did not like (which we will have to discuss about), and others which 
instead I would like to have in.

The main point delaying a new release is about:
1. new experimental features I have implemented, which have to be 
tested and documented.
2. documentation needs fixes wrt recent changes.

Many thanks for the extremely valuable support.
r.

[gtkmvc-users] Bug and release

[Tobias W. <to...@ce...>]

Hi,
recent Gtk releases (e.g. shipped with Ubuntu Lucid) break the GtkBuilder support in the SVN version of pygtkmvc.

By now I seriously recommend using my collection of patches at http://github.com/Wile/gtkmvc instead.

Even if Roberto is still busy we should continue working towards a release so people don't forget about the library. It'd be great if everybody could quickly run the tests on their system. It's easy and doesn't mess with any installed version:

apt-get install git-core # or equivalent
git clone http://github.com/Wile/gtkmvc.git
cd gtkmvc/tests
python adapter1.py
# compare output of running all those scripts to the results described at the top of each file

Thank you!

Re: [gtkmvc-users] Communicating between sub-models/sub-controllers

[Steve M. <smc...@gm...>]

On Fri, Jul 16, 2010 at 2:26 AM, Tobias Weber <to...@ce...> wrote:
> On 16.07.2010, at 06:53, Steve McGrath wrote:

>> Under appController I have a collectionController, and a playlistController, which each have their own respective view and model.
>
> I suppose only songs from the collection can be on the playlist, and that the playlist is persistant. Some day there may be multiple playlists. Almost as if playlists were part of the collection!

The playlist should also be able to take handle songs added directly
from the filesystem. But yes, there will be multiple playlists, though
they don't (yet?) live in the collection. Perhaps it would save me
some trouble if I did start treating them as part of the collection
now though.


>> I will also encounter a problem with my actual playback code, which I intend to create as another sub-model of appModel.
>
> But appModel doesn't know what to play. Maybe it should belong to collectionModel. Or even playlistModel, if you cannot play directly from the collection.
>
> That wouldn't leave much for appModel to do. So maybe collectionModel *is* your appModel. The program is about music, after all.

indeed. appModel, right now, exists only as the root node of a tree of
sub-models. Outside of instantiating those sub-models, it has no code
of it's own. appController and appView are the main UI, though. They
handle everything except for the playlistView/Ctrl which are embodied
by a TreeView in the main window, and the collectionView/Ctrl, which
have their own separate window.

>> Will signals emitted from a sub-model make it to the parent model's controller without help?
>
> No. Diagonal dependencies are bad. Horizontal is built in. Vertical is up to you:

I think I understand the difference, but to be sure; vertical
dependencies involve communication between a sub-model or
sub-controller and its parent? And horizontal dependencies would be
communication between models or controllers under the same parent?
Having thought about this, I think I can make this fairly simple as
long as I give the collectionCtrl and playerCtrl a reference to the
playlistCtrl, so the former can add data, and the latter can access
it.

>
> class appModel:
>    def init:
>        self.collection = collectionModel(self)
>
> class collectionModel:
>    def init(parent):
>        self.register_observer(parent)
>
> class appController:
>    def init:
>        self.collection = collectionController(self.model.collection, ..., self)
>
> class collectionController:
>    def init(m, v, parent):
>        # Keep for direct calls.
>        self.parent = parent

Thanks for the help, I'm still kinda new at this, and I don't want to
end up in cross-dependency hell like one of my last applications.

Regards,

-Steve

-- 
If it ain't broke, you're not using a new enough version

Re: [gtkmvc-users] Communicating between sub-models/sub-controllers

[Tobias W. <to...@ce...>]

On 16.07.2010, at 06:53, Steve McGrath wrote:

> This may be a dumb question, but I can't quite find a clear answer.

I'm no export on object oriented modelling, either.

> Under appController I have a collectionController, and a playlistController, which each have their own respective view and model.

I suppose only songs from the collection can be on the playlist, and that the playlist is persistant. Some day there may be multiple playlists. Almost as if playlists were part of the collection!

> I will also encounter a problem with my actual playback code, which I intend to create as another sub-model of appModel.

But appModel doesn't know what to play. Maybe it should belong to collectionModel. Or even playlistModel, if you cannot play directly from the collection.

That wouldn't leave much for appModel to do. So maybe collectionModel *is* your appModel. The program is about music, after all.

> Will signals emitted from a sub-model make it to the parent model's controller without help?

No. Diagonal dependencies are bad. Horizontal is built in. Vertical is up to you:

class appModel:
    def init:
        self.collection = collectionModel(self)

class collectionModel:
    def init(parent):
        self.register_observer(parent)

class appController:
    def init:
        self.collection = collectionController(self.model.collection, ..., self)

class collectionController:
    def init(m, v, parent):
        # Keep for direct calls.
        self.parent = parent

[gtkmvc-users] Communicating between sub-models/sub-controllers

[Steve M. <smc...@gm...>]

Hey list,

This may be a dumb question, but I can't quite find a clear answer.

I am implementing a music player using the gtkmvc framework, where the
parts relevant to this discussion are structured as follows.

I have a set of top level classes, appController, appModel, appView.
Under appController I have a collectionController, and a
playlistController, which each have their own respective view and
model. They represent the music collection in a database, and the
current playlist. I have a signal handler in collectionController
which should add a song to the current playlist. Thus,
collectionController needs to call a method in either
playlistController, or directly on playlistModel (a ListStoreModel).

The only apparent solution I can come up with is to pass a reference
to playlistModel into the constructor for collectionController, but
somehow this seems messy to me. Is there a better way to do this?

I will also encounter a problem with my actual playback code, which I
intend to create as another sub-model of appModel. Will signals
emitted from a sub-model make it to the parent model's controller
without help?

Thanks in advance,

-Steve

-- 
If it ain't broke, you're not using a new enough version

Re: [gtkmvc-users] Quickly templates feedback

[Tobias W. <to...@ce...>]

On 07.07.2010, at 06:53, Luke Morton wrote:

> 1.  Replace the Ubuntu icon.

No idea what this means.

> 2.  Add a persistance example via SQLObject, GConf or GSettings

From what I can see GSettings is just not ready yet.

We discussed GConf a bit here last month.

I wouldn't use SQLObject just for settings, unless you import it anyway to manage your data. There are samples for implicit storage in gtkmvc. I'm currently working on an application that can new/open/close files by passing an explicit connection on every call.

Building pickle support into the framework won't really work.

What I've been doing so far past was have the main Controller.__init__ call a method in its Model that cascades to the other models and decodes a JSON file. Same on quit. For this to get slower and use more memory than SQLObject you need several thousand records.

[gtkmvc-users] Quickly templates feedback

[Luke M. <luk...@in...>]

Hi,

I'm chasing some feedback for the Quickly templates.

My TODO list is now down to:

1.  Replace the Ubuntu icon.
2.  Add a persistance example via SQLObject, GConf or GSettings

I'm planning on solving 1 with a modified application-x-executable from
gnome-icon-theme (ideally with multiple sizes, but I don't know how to
do that yet).

What avenue does everyone think I should go down for 2?

Luke.

Re: [gtkmvc-users] Regarding a previous discussion about GConf

[Tobias W. <to...@ce...>]

On 15.06.2010, at 03:01, Steve McGrath wrote:

>> The most flexible way might be an Adapter class.

Just pushed a proof of concept to http://github.com/Wile/gtkmvc/commit/eaa9789ae785ef55b1b87b75d711bd4984a4ffa5

BTW there are other feature branches and working SQL tests in this repository

> It was my intention to whip this into shape, and hopefully have a drop-in module that could use GConf under Gnome, the Windows registry on win32, and flat files or perhaps sqlite on other platforms.

That'd be awesome.

[gtkmvc-users] Regarding a previous discussion about GConf

[Steve M. <smc...@gm...>]

> Hi,
> desktops like Windows, the Mac, and Gnome provide a key/value storage for user settings. Applications can request notification of external modification of their preferences. GTK does not abstract that functionality.
>
> I found two independant implementations using gtkmvc on Gnome, so there is demand for support in the framework:
> http://github.com/bouvard/nostaples/blob/master/utils/state.py
> http://bazaar.launchpad.net/%7Esmcgrath23/gvoicebox/trunk/annotate/head%3A/gvoicebox/models/prefs.py
>
> The most flexible way might be an Adapter class. Using a special Model class like gVoicebox means that either all or no properties of a particular model have to live in GConf. Nostaples works around that by explicitly replacing the setters for some properties. Our SQLObject persistence works similarly, using a metaclass for prettier syntax.
>
> Whatever we do, it should be easily replacable with a mock or dumb file implementation to support other environments. I am constantly annoyed by Glade not remembering how I want the sidebar on the Mac...
>
> Outside modification (e.g. using gconf-editor) can introduce bogus information. Schemas don't prevent that. gVoicebox ignores the problem, Nostaples checks against an internal list of possible values (not just types). Currently gtkmvc does not support validation.
>
> Opinions please :)

Just for the record, my implementation of GConf (Second link above)
should definitely not be used by anyone with a history of high blood
pressure, mental illness, or seizures. I looked at it today intending
to re-use it in another pygtkmvc application, and it gave me
heartburn. I agree that having a sane GConf model included in pygtkmvc
would rock. My implementation rapidly de-generated into a horrible
mess, relying on several layers of mapping between properties, GConf
keys, and their value types. It was my intention to whip this into
shape, and hopefully have a drop-in module that could use GConf under
Gnome, the Windows registry on win32, and flat files or perhaps sqlite
on other platforms.

Also, on a not-quite-related note, I've been using the
gtkmvc-application template for Quickly, and I am so happy that it
exists.

Regards,

-Steve McGrath

--
If it ain't broke, you're not using a new enough version

Re: [gtkmvc-users] Quickly

[Luke M. <luk...@in...>]

On Thu, 2010-05-13 at 22:42 +0200, Tobias Weber wrote:
> The subclasses of gtk.Window or Dialog that the Ubuntu template uses
> can be removed, along with the Glade catalogs. Just replace them with
> the regular ones in the XML. 

Victory is mine! There are no longer separate Glade catalogs and views
don't contain subclass definitions to support the now obsolete catalog
files.

> I notice you include gtkmvc from SVN. I'm all for copying the
> framework into each application, but it should probably be a release,
> or at least have a version number that makes it clear that the
> documentation on the website may not apply.

I added a README file in the gtkmvc folder, as well as a note in the
GtkLabel in the main window.

As before, it's all available at:
bzr branch lp:~luke-morton/quickly/gtkmvc-application

Re: [gtkmvc-users] Quickly

[Luke M. <luk...@in...>]

On Thu, 2010-05-13 at 22:42 +0200, Tobias Weber wrote:
> On 13.05.2010, at 06:02, Luke Morton wrote:
> >>> I'd remove the widget subclassing stuff. It's not necessary in
> gtkmvc and potentially confusing.
> That's not what I meant. The subclasses of gtk.Window or Dialog that
> the Ubuntu template uses can be removed, 

I thought that might be what you meant. I'll have a go, but last time I
tried that I made a mess of things (I'm relatively inexperienced in GTK+
programming). I have had a bit of experience writing gtkrc themes
though, and being able to write a rule for a particular application is
nice, and only possible if that application can be uniquely identified.
So from that perspective, I think the subclasses are actually a good
idea.

> along with the Glade catalogs. Just replace them with the regular ones
> in the XML. You already moved all code into the gtkmvc.View
> subclasses.

I'll try, but again, I'm not 100% sure what I'm doing :)

> I notice you include gtkmvc from SVN. I'm all for copying the
> framework into each application, but it should probably be a release,
> or at least have a version number that makes it clear that the
> documentation on the website may not apply.

I had to do that for builder support. But you're right, it should have a
version number.

If the changes to templates regarding subclassing and glade catalogs
mean that significant portions of the code inherited from
ubuntu-application have to be changed then I'd rather not do that. In
Quickly 0.4 it's possible to inherit commands (like quickly design) so
we benefit from any future bug fixes/improvements to those commands
Since Quickly isn't yet stable (from an API point of view), this is all
the more important.

Nevertheless, I'll look into both and and see if I can do them.

> This is a great chance to show more people how nice Observer is :)

Is there a particular example you'd like me to include? Or do you just
mean in general?

Luke.

Re: [gtkmvc-users] Quickly

[Tobias W. <to...@ce...>]

On 13.05.2010, at 06:02, Luke Morton wrote:

>>> I'd remove the widget subclassing stuff. It's not necessary in gtkmvc and potentially confusing.
> 
> I've removed the subview stuff

That's not what I meant. The subclasses of gtk.Window or Dialog that the Ubuntu template uses can be removed, along with the Glade catalogs. Just replace them with the regular ones in the XML. You already moved all code into the gtkmvc.View subclasses.

I notice you include gtkmvc from SVN. I'm all for copying the framework into each application, but it should probably be a release, or at least have a version number that makes it clear that the documentation on the website may not apply.

This is a great chance to show more people how nice Observer is :)

Re: [gtkmvc-users] Quickly

[Luke M. <luk...@in...>]

> On Wed, 2010-05-05 at 13:32 +0200, Tobias Weber wrote:
> 
> > Thanks! Maybe you could put up a repository somewhere?

I've chatted with the Quickly devs, and they suggested branching Quickly
and adding the new templates there. Once everyone is happy they they can
be merged into trunk. So that's what I did. You can get the source from
launchpad: 

bzr branch lp:~luke-morton/quickly/gtkmvc-application

(Note that this includes the Quickly source as well as the template
which is located in quickly/data/templates/gtkmvc-application.)

> > I'd remove the widget subclassing stuff. It's not necessary in gtkmvc and potentially confusing.

I've removed the subview stuff and created a new command to generate a
dialog which adds the AboutView as a subview. This way it's still there
as an example but not cluttering the main template.

I changed the templates substantially to take advantage of changes to
Quickly 0.4. Most commands are now inherited from ubuntu-application.

The main commands to review are:

add [dialog|demo|subview]
doc