Note: when I view the example site using FF v2.0.0.12 on 64-bit
Ubuntu 7.10, it does not come up with Nebraska as the default
stylesheet. Each page I view, I have to click on View->Page
Style->Nebraska.
Just mentioning it for those of you wanting a quick view of what Jason has done.
(By default it looks like it comes up in Modern/GRAMPS style.)
Stéphane
On Feb 17, 2008 2:03 PM, Jason Simanek <jsimanek@...> wrote:
> Hello,
>
> I have finally prepared a working example of my updated NarrativeWeb.py
> script output as well as my Nebraska CSS stylesheet, an updated
> rendition of the Modern CSS stylesheet and a default Print CSS
> stylesheet.
>
> http://bohemianalps.com/GRAMPS/index.html
>
> I was going to build a test database, but that would take too long.
> Maybe in the future. For now, this is my complete database, so please be
> kind to my personal information.
>
> I took advantage of the 'alternate stylesheet' option in XHTML so that
> you can review these three stylesheets without going to different sites.
> I exported it with the Modern stylesheet as default, but you can pick
> and choose between the others. All of the existing stylesheets are there
> too, but I have only worked with the three specified above. Here's how
> to switch stylesheets:
>
> Firefox
> Main Menu/View/Page Style
>
> Konqueror
> Main Menu/View/Use Stylesheet
>
> Opera
> Main Menu/View/Style (and go all the way to the bottom)
> Toolbar/Author mode (and go all the way to the bottom)
>
> Safari and Internet Explorer
> (From what I know, you can't do this with these browsers. Maybe in
> IE7...)
>
> If you aren't familiar with media-specific stylesheets:
> http://www.w3.org/TR/REC-CSS2/media.html
>
> Basically, the Print stylesheet would only be used if you try to print a
> page from the site. However, for this example, I have also set the Print
> stylesheet as an alternate so that you can view it on-screen.
>
> If you have it, Konqueror is pretty slick since it keeps the stylesheet
> you choose active until you change it again. The other browsers keep
> flipping back to the default style sheet every time you go to a new
> page.
>
> I hope you find my version of the Modern Style a refreshing update.
> Also, the print stylesheet is focused on a classy and efficient printed
> presentation. The Nebraska style feels a little inflated, but it is easy
> on the eyes and I think will be good for older viewers as well.
>
> Let me know what you think,
>
> Jason Simanek
>
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

Hello,
I have finally prepared a working example of my updated NarrativeWeb.py
script output as well as my Nebraska CSS stylesheet, an updated
rendition of the Modern CSS stylesheet and a default Print CSS
stylesheet.
http://bohemianalps.com/GRAMPS/index.html
I was going to build a test database, but that would take too long.
Maybe in the future. For now, this is my complete database, so please be
kind to my personal information.
I took advantage of the 'alternate stylesheet' option in XHTML so that
you can review these three stylesheets without going to different sites.
I exported it with the Modern stylesheet as default, but you can pick
and choose between the others. All of the existing stylesheets are there
too, but I have only worked with the three specified above. Here's how
to switch stylesheets:
Firefox
Main Menu/View/Page Style
Konqueror
Main Menu/View/Use Stylesheet
Opera
Main Menu/View/Style (and go all the way to the bottom)
Toolbar/Author mode (and go all the way to the bottom)
Safari and Internet Explorer
(From what I know, you can't do this with these browsers. Maybe in
IE7...)
If you aren't familiar with media-specific stylesheets:
http://www.w3.org/TR/REC-CSS2/media.html
Basically, the Print stylesheet would only be used if you try to print a
page from the site. However, for this example, I have also set the Print
stylesheet as an alternate so that you can view it on-screen.
If you have it, Konqueror is pretty slick since it keeps the stylesheet
you choose active until you change it again. The other browsers keep
flipping back to the default style sheet every time you go to a new
page.
I hope you find my version of the Modern Style a refreshing update.
Also, the print stylesheet is focused on a classy and efficient printed
presentation. The Nebraska style feels a little inflated, but it is easy
on the eyes and I think will be good for older viewers as well.
Let me know what you think,
Jason Simanek

On Mon, 2008-02-11 at 09:31 +0100, Benny Malengier wrote:
> Jason,
>
> as you where looking at header, see bug
> http://bugs.gramps-project.org/view.php?id=1741
>
> So the header could contain php in 2.2.x branch. In that perspective,
> are the changes you plan still correct, that is, will that work too
> after change of position of this code?
Benny,
This is a problem with how text in a GRAMPS Note is formatted,
specifically when used by the NarrativeWeb.py script. I noticed this
also when I heard that this could be used as a way to include custom
markup. It's not possible to include markup from what I've tried because
any markup that is included in a note is either discarded or converted
to HTML entities.
Occasionally I even find a <gramps></gramps> tag being inserted into the
HTML output. It's only occasionally and I can't figure out what causes
the issue. Regardless, that element shouldn't be in the HTML output.
I think we need to revisit the Note formatting. I am confused by the
options available in the edit menu and none of them seem to change the
output generated by NarrativeWeb.py.
Another way to go about allowing users to include custom markup or
'code' would be to allow them to browse to a text file from the
Narrative Web Report dialog. That way it wouldn't have anything to do
with the existing 'Notes' element in GRAMPS.
My changes, as far as where some script element is dropped in to the
HTML document, shouldn't change the possibilities from the existing
location. Regardless, we really need to decide who our target audience
is with that feature and then develop it accordingly. My approach at the
moment is to make it an elegant way to allow users to include additional
text in the header or footer element.
If our intention is to allow users to include custom script elements,
the feature would probably be more helpful if it inserted the custom
script element in the <head/> element rather than the <body/> element
where both the existing and my new update do.
-Jason

2008/2/17, Dave Walton <dw-gramps@...>:
>
> Gerald Britton wrote:
> > While we're at it, let's address an old itch of mine:
> >
> > ==Reconcile Places and Addresses===
>
> Yeah, that's been nagging at me for some time, too.
>
> > Both Places (the Location tab) and Addresses hold address data. They
> > mostly overlap with a few differences:
> >
> > Addresses in gramps have dates, Places do not.
> > Places have Church Parish, Addresses do not.
> > Places separate City and County, Addresses lump them into one field
> > Addresses label one field State/Prov, Places labels the same field State
>
> Also, an Address has a field for a phone number. One phone number.
> Plenty of people in my family have two lines at home, so I'd have to add
> a second Address to enter their second line. And then there are cell
> phones, which aren't tied to an address anyway.
>
> Thinking about it now, addresses, phone numbers, email addresses, web
> sites, etc are all ways of locating someone, in one way or another. So
> the current Addresses and Internet tabs could be combined into a single
> tab (still called Addresses? or Contacts? or ?). That tab could
> contain a list of entries of all those types, each with a date range,
> source and notes (which Internet tab items currently do not have).
Gramps is a genealogy application, not a PIM suite, so I suggest you use one
of the many good addressbooks out there ;-)
Apart from that, read:
http://www.gramps-project.org/wiki/index.php?title=Why_residence_event_and_not_Address%3F
It would be nice to improve on address in GRAMPS, but we would need a
motivated developer for that first. Then a good design, then developer
agreement.
Benny
Dave
>
>
> >
> > Suggestion:
> >
> > Have one class to handle both Place Locations and Addresses and one
> > object to capture them. Let the attributes be the union of both
> > current objects. Manage addresses as objects by themselves.
> >
> > In the Place Location dialog, add dates to show when the location (or
> > alternate location) is meaningful for the place.
> >
> > In both the Address dialog and the Place Location dialog, add the
> > ability to lookup an address object.
> >
> > Add a button to both dialogs directly access a user-definable GIS
> > service like Google Maps, Google Earth, Mapquest, etc.
> >
> > Use one dialog for both purposes.
> >
> > Benefits:
> >
> > Code consolidation for easier maintenance and easier feature addition
> > (such as hierarchical searching)
> > Consistent presentation of civic address data for both Place Locations
> > and Addresses
> >
> >
> >
> >
> > On Feb 3, 2008 5:55 PM, Dave Walton <dw-gramps@...> wrote:
> >> Your suggestion (appended below) of a selectable place structure is an
> >> interesting idea, and touches on something I've been pondering. As my
> >> list of places grows, it becomes increasingly difficult to find a
> >> particular place in the list, just because the list is so long. It
> >> would be much tidier if places could be displayed as collapsable
> >> hierarchy which one could drill down into to find a specific location.
> >> Which then leads to the issue of how that would work with
> the different
> >> structures used in different regions.
> >>
> >> It occurs to me that the issue could be broken down into two (hopefully
> >> separate) parts: data and labels.
> >>
> >> Looking at the data first, without labels, your NZ example would look
> >> like this:
> >> level 1: New Zealand
> >> level 2: Auckland
> >> level 3: Waitakere
> >> level 4: New Lynn
> >> level 5: 15 William's St
> >>
> >> Where the levels map to country, region, town, suburb, street.
> >> (Or, perhaps country would be level 5, after galaxy, star, planet, and
> >> continent. But I digress...)
> >>
> >> Meanwhile, in England, you might see this:
> >> level 1: UK
> >> level 2: England
> >> level 3: West Midlands
> >> level 4: Warwickshire
> >> level 5: North Warwickshire
> >> level 6: Arley
> >> level 7: Old Arley
> >> level 8: Church Ln
> >>
> >> Where the levels map to [?], country, region, county, district, parish,
> >> town, street.
> >>
> >> But within the database, and for purposes of grouping, I don't believe
> >> it matters whether country is level 1 or level 2, or whether town is
> >> level 3 or level 7. All that matters is that you've got a set of
> fields
> >> which form a hierarchy, and entries which share the same values at the
> >> upper levels (regardless of what those values "mean") can be grouped
> >> together, down to the level where their values differ.
> >>
> >>
> >> With that in mind, we move on to labels. Your proposal becomes a
> method
> >> of mapping varying sets of labels to the fields for display purposes.
> >> In a way, that simplifies things, because the messy details of varying
> >> hierarchy styles has become a UI issue, separate from the database.
> >> Which is a good thing. The varying place structures is challenging
> >> problem, and any simplification is a blessing.
> >>
> >>
> >> What I've been carefully avoiding up to now is non-hierarchical data
> >> about a place. A good example of this would be postal code. In one
> >> place you might have multiple towns within one postal code, and just a
> >> few miles away you might have multiple postal codes within one
> city. Or
> >> a postal code can cover part of one city and all of one or more
> >> neighboring towns.
> >>
> >> This suggests that at the data level you could have some number of
> >> hierarchical fields (a dozen?), plus some number of non-hierarchical
> >> fields (half a dozen?). Then the place structure labeling system can
> >> select labels for the non-hierarchical fields appropriate for that
> >> region and time, as well. There would probably also need to be an
> >> option to display unlabeled fields, so that if you changed your
> >> selection from England to NZ, for example, you wouldn't lose access to
> >> the data in levels 6-8.
> >>
> >>
> >> The place where these thoughts become challenging is in sorting the
> list
> >> on a particular value. One possibility would be to sparsely populate
> >> the hierarchical fields, so that, for example, 'City' is always level
> 7,
> >> whether or not there are 6 levels above it in a given structure. Or
> >> perhaps it would be possible to do something like "sort this list by
> the
> >> contents of the fields which have the label 'City'". More thought is
> >> needed here.
> >>
> >>
> >> Anyway, getting back to your suggestion, I like the sound of it.
> >> Building the list of structures would be a significant project, but one
> >> that non-devs could easily contribute to. And once it was built, it'd
> >> be a huge help to the countless users struggling with the question of
> >> how to map some random locale to the generic data structure. Though a
> >> Generic structure selection would definitely still be necessary.
> >>
> >> Comments, anyone?
> >>
> >> Dave
> >>
> >>
> >>
> >>
> >> Duncan Lithgow wrote:
> >>> On Sun, 2008-01-13 at 11:41 -0800, James G. Sack (jim) wrote:
> >>>> Perhaps some of this has already been considered by others, and we
> might
> >>>> steal some ideas from there:
> >>>>
> >>>> Gedcom has something called a
> >>>> PLACE_HIERARCHY within a PLACE_STRUCTURE
> >>> Jim, I've been thinking about this for a while now and it seems to me
> >>> that the only way to do this properly is to have a setting for each
> >>> place which specifies which hiararchical structure to use. For example
> >>> If I enter an address from New Zealand it would be:
> >>>
> >>> Structure: New Zealand post 1950
> >>> Street: 15 William's St
> >>> Suburb: New Lynn
> >>> Town/ City: Waitakere
> >>> Region: Auckland
> >>> Country: New Zealand
> >>> (with some fields for Parish and electorate outside the hierarchy)
> >>>
> >>> Whereas if I have an address from Denmark for where my wife's families
> >>> tree is it might be:
> >>>
> >>> Structure: Danish 1818-1865
> >>> Street (gade): Nansensgade 14
> >>> Parish (sogn):
> >>> Municipality (kommune):
> >>> Region (amt):
> >>> Country (land):
> >>> (again maybe some fields outside this structure would be useful)
> >>>
> >>> I simply can't see any other way around it.
> >>>
> >>> This approach has some good and bad sides:
> >>>
> >>> Good:
> >>> * Solves the structure problem which solves a number of other problems
> >>> like data consistency, structured reports...
> >>> * Includes useful information for the genealogist about how the
> >>> geographical names work
> >>>
> >>> Bad:
> >>> * Would require the collection of lots of data to make the system work
> >>> well
> >>> * Might be confusing to start with (could also start with Structure:
> >>> Generic)
> >>>
> >>> Maybe we should start by adding to those two lists...
> >>>
> >>> Duncan
> >>>
> >>>
> >>>
> -------------------------------------------------------------------------
> >>> This SF.net email is sponsored by: Microsoft
> >>> Defy all challenges. Microsoft(R) Visual Studio 2008.
> >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >>> _______________________________________________
> >>> Gramps-devel mailing list
> >>> Gramps-devel@...
> >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
> >>
> >>
> -------------------------------------------------------------------------
> >> This SF.net email is sponsored by: Microsoft
> >> Defy all challenges. Microsoft(R) Visual Studio 2008.
> >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >> _______________________________________________
> >> Gramps-devel mailing list
> >> Gramps-devel@...
> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel
> >>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

2008/2/16, Dave Walton <dw-gramps@...>:
>
> Benny Malengier wrote:
> >
> > 2008/2/3, Dave Walton <dw-gramps@... <mailto:dw-gramps@...
> >>:
> >
> > Before I dive back in on these scripts, the recent Beta of 3.0 makes
> me
> > wonder if there's any point, since it seems they'll quickly become
> > obsolete. Would it be better to just shelve it for 2.x and start
> > tinkering with 3.x?
> >
> > About the first question, as it took you a while to get back to this, I
> > think you best play with the 3.0 code. It shouldn't be too long before
> > 2.2.x development is dropped completely.
>
> Ok, I'll do that.
> I've got 3.0 running now, and there sure is a lot to like about it!
>
> I have a question about the db log files...
> Looking inside them, I see many instances of the full path to the .grdb
> file (in 2.x) or .db files (in 3.0). Yet it seems that there is no
> problem moving the database as long as (in 2.x) you are very careful to
> also move the log files to the correct location under the env dir. So
> I've reached the conclusion that the paths in the log files (in both
> versions) isn't really important, and all that matters is that the log
> files be available. Is this correct, or am I missing something important?
I'm pretty sure relatively to each other they cannot change. In howfar the
absolute path can change, I have no idea. Somebody should try, and see with
sleepycat (who makes the db) if he finds info if what he does is supported.
Benny
Thanks,
> Dave
>

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details