Re: Splitting files

[Stephen Kennedy]

> I'd also like to propose trying to transition to a more
> standard/pythonic directory structure. For example, moving *.py into a
> new meld/ subdirectory, maintaining vc/ (and maybe a new widgets/
> subdirectory?) inside that, and switching to install to
> python/site-packages/. If there is interest, I can do some looking at
> standard package structures, install scripts, etc.

Yes a reorganization is in order. How about this straw man proposal?

data/? (meld.applications, meld.desktop, etc)
data/icons (was glade2/pixmaps)
data/ui (was glade2/*)
help
po

Reorganizing the source is a little more difficult. If we're going to
install into
site-packages should all code be inside the "meld" directory? I know
theoretically
vc is standalone, but I don't think anybody else is using it.

I originally thought moving the widgets into a subfolder was a good idea
but perhaps there's enough non-meld specific library code there to justify
a new module which doesn't live under the meld folder. i.e. findbar,
historyentry,
gnomeglade, sourceviewer, notebooklabel. Certainly I find myself copying and
pasting a lot of skeleton code for mini projects or tests.

Stephen.
_______________________________________________
meld-list mailing list
meld-list@...
http://mail.gnome.org/mailman/listinfo/meld-list

[Kai Willadsen-2]

2009/5/24 Stephen Kennedy <stevek@...>:

>> I'd also like to propose trying to transition to a more
>> standard/pythonic directory structure. For example, moving *.py into a
>> new meld/ subdirectory, maintaining vc/ (and maybe a new widgets/
>> subdirectory?) inside that, and switching to install to
>> python/site-packages/. If there is interest, I can do some looking at
>> standard package structures, install scripts, etc.
>
> Yes a reorganization is in order. How about this straw man proposal?
>
> data/? (meld.applications, meld.desktop, etc)
> data/icons (was glade2/pixmaps)
> data/ui (was glade2/*)
> help
> po

That's pretty much exactly what I would have suggested. I'm not sure
what the last Gnome version was that used meld.applications, but I'm
pretty sure that it's no longer necessary and could go away. On my
desktop, Meld is the only thing installed that actually ships a
standalone .applications file.

> Reorganizing the source is a little more difficult. If we're going to
> install into
> site-packages should all code be inside the "meld" directory? I know
> theoretically
> vc is standalone, but I don't think anybody else is using it.

Having all of the code under the "meld" directory seems reasonable to
me. Even if vc (or other bits) are being used by other projects, this
stuff isn't currently being installed in any kind of standard
site-wide location.

> I originally thought moving the widgets into a subfolder was a good idea
> but perhaps there's enough non-meld specific library code there to justify
> a new module which doesn't live under the meld folder. i.e. findbar,
> historyentry,
> gnomeglade, sourceviewer, notebooklabel. Certainly I find myself copying and
> pasting a lot of skeleton code for mini projects or tests.

The non-meld specific code can be separated into widgets (findbar,
historyentry, notebooklabel, maybe messagearea in the future?) and
utility/shim classes (gnomeglade, prefs, sourceviewer). One option
would be to just create two subdirectories - meld/widgets/ and
meld/util/ or similar.

I'm not sure exactly what you had in mind in terms of a new module. Do
you mean a directory structure like:

  lib/meld (meldapp, filediff, vcview, etc)
  lib/pygtkgnomehelperwidgetshims [note: could use a better name] (the
non-meld specific stuff above)

...which might work. Most of these classes are at least a little bit
Meld-specific... the History* classes expose only what we use,
Preferences classes don't support list types, and so on. We could try
to make these classes more general, though I have no idea who the
external users of these classes would be. Also, I would have guessed
that other projects are likely to just copy-n-paste the classes they
need.

cheers,
Kai
_______________________________________________
meld-list mailing list
meld-list@...
http://mail.gnome.org/mailman/listinfo/meld-list