From: Brian M. <br...@gr...> - 2007-04-14 21:14:29
|
Doug: >[I submitted this feature request and patch to implement it, but thought >I'd post it here as it might be a little controversial as it adds some >code to the NameDisplay. It does not significantly impact the speed, >however. -Doug] > >Goal: Display callname in parentheses, if callname isn't empty. Currently, >the way that gramps works is that you can define custom display name >formats like: > >1) %l, %f %c -> "Smith, Frederick Fred" >2) %l, %f (%c) -> "Jones, Martha ()" > >The trouble with 1 is that it is impossible to see which is the callname >as it is not syntactically separated from the rest of the names. The >problem with 2 is that the parens will be there, even if there is no >callname. The trouble with both is that if the surname is empty, the comma will still be printed. ",Fredrick Fred" ",Martha ()" Does this fix that problem, too? >The attached patch . . . What attached patch? I think you forgot to attach it. > . . . creates a new set of patterns for which one can match >in creating a custom name display. The new patterns are exactly the old >ones, except that they can have parens around them, and the parens will >only display if the element being surrounded is not empty. For example: > >%l, %f (%c) > This pattern looks exactly like the one above. Did you add a function? Perhaps you could use Capital C ("%C") to indicate a call name in partenthesis. As before: %l, %f (%c) -> "Jones, Martha ()" -> "Smith, Frederick (Fred)" Using Capital C: %l, %f %C -> "Jones, Martha" -> "Smith, Frederick (Fred)" >will display "Smith, Frederick (Fred)" if Fred is the callname and display >"Jones, Martha" if Martha doesn't have a callname. >This patch takes extra care to make sure that there is minimal speed >impact on the display name function. Patch is against current SVN trunk >(2.2). I'm not really too concerned about speed. How long could you possibly make it take? ~Brian |
From: Brian M. <br...@gr...> - 2007-04-14 21:58:27
|
Doug, >> This pattern looks exactly like the one above. Did you add a function? > >Yes, I added some code that looks for the pattern "(%c)". Oh, now I see. You added the string "(%c)" as a valid pattern to be replaced. I was thinking that you could just take an unused letter (apparently not capital C) and use it to mean "Call name in partenthesis". I'll use "z" and an example because I'm pretty sure it is not already used. %I, %f %z -> Smith, Frederick (Fred) -> Jones, Martha But your way works, too. I guess the way I see it, we have 26 lower case letters, 26 capital letters, and 10 digits we can use, so there is no sense making things more complicated than they need to by. By the way, where do we store a list of all the possible patterns? How is it displayed to the user? ~Brian |
From: Douglas S. B. <db...@cs...> - 2007-04-14 22:07:39
|
On Sat, April 14, 2007 5:58 pm, Brian Matherly wrote: > Doug, > >>> This pattern looks exactly like the one above. Did you add a function? >> >>Yes, I added some code that looks for the pattern "(%c)". > > Oh, now I see. You added the string "(%c)" as a valid pattern to be > replaced. I was thinking that you could just take an unused letter > (apparently not capital C) and use it to mean "Call name in partenthesis". > I'll use "z" and an example because I'm pretty sure it is not already > used. > > %I, %f %z > -> Smith, Frederick (Fred) > -> Jones, Martha > > But your way works, too. I guess the way I see it, we have 26 lower case > letters, 26 capital letters, and 10 digits we can use, so there is no > sense making things more complicated than they need to by. Brian, Yes, I tried to make it so that the user wouldn't have to remember arbitrary letters. Also, if we add the ability to do: %l, %f -> "Martha" when Martha doesn't have a last name, there is no sense in making that be something other than "%l," (rather than, say, %z). So, "(%c)" makes sense and is only a few characters to add in the compiled regular expression. > By the way, where do we store a list of all the possible patterns? How is > it displayed to the user? Currently, it appears in the window when one is editing the name display format. I don't think that is automated, just a glade window display I think. -Doug > ~Brian > > > -- Douglas S. Blank Associate Professor, Bryn Mawr College http://cs.brynmawr.edu/~dblank/ Office: 610 526 6501 |
From: Brian M. <br...@gr...> - 2007-04-15 02:39:09
|
Doug, >Yes, I tried to make it so that the user wouldn't have to remember >arbitrary letters. Also, if we add the ability to do: > >%l, %f -> "Martha" > >when Martha doesn't have a last name, there is no sense in making that be >something other than "%l," (rather than, say, %z). So, "(%c)" makes sense >and is only a few characters to add in the compiled regular expression. I can see both sides and don't feel particularly strong either way. It's up to you do do what you feel is best. The nice thing is that if we change our minds later, the only changes need to be made in NameDisplay. Another option would be to make this the default behavior for all patterns when surrounded in parenthesis or followed by a comma. I can't think of a case where you wouldn't want that. Unless, perhaps you like to keep the comma to indicate that a person's last name is unknown. >> By the way, where do we store a list of all the possible patterns? How is >> it displayed to the user? > >Currently, it appears in the window when one is editing the name display >format. I don't think that is automated, just a glade window display I >think. I wonder if we should make this more obvious. It might be fine if you are changing your preferences for the default name display, but what if you are setting options for a report (like the ancestor and descendant reports)? ~Brian |
From: <bm...@ca...> - 2007-04-15 08:01:34
|
I think this patch is a bit biased to , or parenthesis. What about ; or, ... Automatically doing away with brackets as in (%c) has two problems: 1. what if users wants to see () 2. how is the users supposed to know that, eg user uses - %c, of which the - does not disappear. How should he know that (%c) would be better Therefore an option %z looks reasonable to me as it means (%c) if call name is present and nothing otherwise. %z can be added to the glade dialog, making it clear for the user he can use that. The problem is only that z is not very intuitive naming. Another option would be a conditional grouping in the format, say with {before|after}, where before is printed before the next identifier if it is present, and after is printed after the previous identifier if it was present. For example: %I{,} %f {-} %c, would print , only if %f is present and - if %c is present. For the brackets this gives: %I, %f {(}%c{|)} This setup is general, but perhaps a bit complicated. Benny Quoting Brian Matherly <br...@gr...>: > Doug, > >> Yes, I tried to make it so that the user wouldn't have to remember >> arbitrary letters. Also, if we add the ability to do: >> >> %l, %f -> "Martha" >> >> when Martha doesn't have a last name, there is no sense in making that be >> something other than "%l," (rather than, say, %z). So, "(%c)" makes sense >> and is only a few characters to add in the compiled regular expression. > > I can see both sides and don't feel particularly strong either way. > It's up to you do do what you feel is best. The nice thing is that if > we change our minds later, the only changes need to be made in > NameDisplay. > > Another option would be to make this the default behavior for all > patterns when surrounded in parenthesis or followed by a comma. I > can't think of a case where you wouldn't want that. Unless, perhaps > you like to keep the comma to indicate that a person's last name is > unknown. > >>> By the way, where do we store a list of all the possible patterns? How is >>> it displayed to the user? >> >> Currently, it appears in the window when one is editing the name display >> format. I don't think that is automated, just a glade window display I >> think. > > I wonder if we should make this more obvious. It might be fine if you > are changing your preferences for the default name display, but what > if you are setting options for a report (like the ancestor and > descendant reports)? > > ~Brian > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Richard T. <rjt...@th...> - 2007-04-15 08:37:25
|
If we were to follow this type of approach we should consider writting a better Name Format Editor. If the Name Format Editor presented a user friendly interface it would not matter if the format itself was more complicated. Then it would make sense to go for a more general syntax. Richard On Sunday 15 April 2007 09:01, bm...@ca... wrote: > I think this patch is a bit biased to , or parenthesis. What about ; or, > ... > > Automatically doing away with brackets as in (%c) has two problems: > 1. what if users wants to see () > 2. how is the users supposed to know that, eg user uses - %c, of which the > - does not disappear. How should he know that (%c) would be better > > Therefore an option %z looks reasonable to me as it means (%c) if call name > is present and nothing otherwise. %z can be added to the glade dialog, > making it clear for the user he can use that. The problem is only that z is > not very intuitive naming. > > Another option would be a conditional grouping in the format, say with > {before|after}, where before is printed before the next identifier if it is > present, and after is printed after the previous identifier if it was > present. > > For example: %I{,} %f {-} %c, would print , only if %f is present and - > if %c is > present. > For the brackets this gives: %I, %f {(}%c{|)} > > This setup is general, but perhaps a bit complicated. > > Benny > > Quoting Brian Matherly <br...@gr...>: > > Doug, > > > >> Yes, I tried to make it so that the user wouldn't have to remember > >> arbitrary letters. Also, if we add the ability to do: > >> > >> %l, %f -> "Martha" > >> > >> when Martha doesn't have a last name, there is no sense in making that > >> be something other than "%l," (rather than, say, %z). So, "(%c)" makes > >> sense and is only a few characters to add in the compiled regular > >> expression. > > > > I can see both sides and don't feel particularly strong either way. > > It's up to you do do what you feel is best. The nice thing is that if > > we change our minds later, the only changes need to be made in > > NameDisplay. > > > > Another option would be to make this the default behavior for all > > patterns when surrounded in parenthesis or followed by a comma. I > > can't think of a case where you wouldn't want that. Unless, perhaps > > you like to keep the comma to indicate that a person's last name is > > unknown. > > > >>> By the way, where do we store a list of all the possible patterns? How > >>> is it displayed to the user? > >> > >> Currently, it appears in the window when one is editing the name display > >> format. I don't think that is automated, just a glade window display I > >> think. > > > > I wonder if we should make this more obvious. It might be fine if you > > are changing your preferences for the default name display, but what > > if you are setting options for a report (like the ancestor and > > descendant reports)? > > > > ~Brian > > > > > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > Gramps-devel mailing list > > Gra...@li... > > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Douglas S. B. <db...@cs...> - 2007-04-15 12:07:05
|
On Sun, April 15, 2007 4:37 am, Richard Taylor wrote: > If we were to follow this type of approach we should consider writting a > better Name Format Editor. > > If the Name Format Editor presented a user friendly interface it would not > matter if the format itself was more complicated. Then it would make sense > to > go for a more general syntax. I'd vote for keeping it simple, but allow for the general. Having a weird, complicated language would be hard to use. One way to do that would be to add an "escape character". A sequence of characters would be a pattern to match and dependent on the existence of name part. However, if one of the characters was escaped, then it wouldn't be part of the sequence. Imagine that callname is empty and \ is the escaping char: %l, %f (%c) -> "Jones, Martha" %l, %f \(%c\) -> "Jones, Martha ()" %l, %f, %c -> "Jones, Martha" %l, %f\, %c -> "Jones, Martha," %c, %f -> "Martha" %c\, %f -> ", Martha" This could be done with the current system, and made to work with all punctuation. Most importantly, it makes simple things easy, and more complicated things possible. I think the default behavior should be not to show "dependent" punctuation, but make it possible to do so if one wanted. Another option would be a check box: [ ] Include punctuation verbatim, which would make it work the way that it currently does. I like that, combined with the simple rule that will remove "dependent punctuation." -Doug > Richard > > On Sunday 15 April 2007 09:01, bm...@ca... wrote: >> I think this patch is a bit biased to , or parenthesis. What about ; or, >> ... >> >> Automatically doing away with brackets as in (%c) has two problems: >> 1. what if users wants to see () >> 2. how is the users supposed to know that, eg user uses - %c, of which >> the >> - does not disappear. How should he know that (%c) would be better >> >> Therefore an option %z looks reasonable to me as it means (%c) if call >> name >> is present and nothing otherwise. %z can be added to the glade dialog, >> making it clear for the user he can use that. The problem is only that z >> is >> not very intuitive naming. >> >> Another option would be a conditional grouping in the format, say with >> {before|after}, where before is printed before the next identifier if it >> is >> present, and after is printed after the previous identifier if it was >> present. >> >> For example: %I{,} %f {-} %c, would print , only if %f is present and - >> if %c is >> present. >> For the brackets this gives: %I, %f {(}%c{|)} >> >> This setup is general, but perhaps a bit complicated. >> >> Benny >> >> Quoting Brian Matherly <br...@gr...>: >> > Doug, >> > >> >> Yes, I tried to make it so that the user wouldn't have to remember >> >> arbitrary letters. Also, if we add the ability to do: >> >> >> >> %l, %f -> "Martha" >> >> >> >> when Martha doesn't have a last name, there is no sense in making >> that >> >> be something other than "%l," (rather than, say, %z). So, "(%c)" >> makes >> >> sense and is only a few characters to add in the compiled regular >> >> expression. >> > >> > I can see both sides and don't feel particularly strong either way. >> > It's up to you do do what you feel is best. The nice thing is that if >> > we change our minds later, the only changes need to be made in >> > NameDisplay. >> > >> > Another option would be to make this the default behavior for all >> > patterns when surrounded in parenthesis or followed by a comma. I >> > can't think of a case where you wouldn't want that. Unless, perhaps >> > you like to keep the comma to indicate that a person's last name is >> > unknown. >> > >> >>> By the way, where do we store a list of all the possible patterns? >> How >> >>> is it displayed to the user? >> >> >> >> Currently, it appears in the window when one is editing the name >> display >> >> format. I don't think that is automated, just a glade window display >> I >> >> think. >> > >> > I wonder if we should make this more obvious. It might be fine if you >> > are changing your preferences for the default name display, but what >> > if you are setting options for a report (like the ancestor and >> > descendant reports)? >> > >> > ~Brian >> > >> > >> > >> > >> > ------------------------------------------------------------------------- >> > This SF.net email is sponsored by DB2 Express >> > Download DB2 Express C - the FREE version of DB2 express and take >> > control of your XML. No limits. Just data. Click to get it now. >> > http://sourceforge.net/powerbar/db2/ >> > _______________________________________________ >> > Gramps-devel mailing list >> > Gra...@li... >> > https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> ---------------------------------------------------------------- >> This message was sent using IMP, the Internet Messaging Program. >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel > -- Douglas S. Blank Associate Professor, Bryn Mawr College http://cs.brynmawr.edu/~dblank/ Office: 610 526 6501 |
From: Douglas S. B. <db...@cs...> - 2007-04-14 21:45:18
|
On Sat, April 14, 2007 5:14 pm, Brian Matherly wrote: > Doug: > >>[I submitted this feature request and patch to implement it, but thought >>I'd post it here as it might be a little controversial as it adds some >>code to the NameDisplay. It does not significantly impact the speed, >>however. -Doug] >> >>Goal: Display callname in parentheses, if callname isn't empty. >> Currently, >>the way that gramps works is that you can define custom display name >>formats like: >> >>1) %l, %f %c -> "Smith, Frederick Fred" >>2) %l, %f (%c) -> "Jones, Martha ()" >> >>The trouble with 1 is that it is impossible to see which is the callname >>as it is not syntactically separated from the rest of the names. The >>problem with 2 is that the parens will be there, even if there is no >>callname. > > The trouble with both is that if the surname is empty, the comma will > still be printed. > > ",Fredrick Fred" > ",Martha ()" > > Does this fix that problem, too? It could be used to fix that issue. See below. >>The attached patch . . . > > > What attached patch? I think you forgot to attach it. http://bugs.gramps-project.org/view.php?id=1018 >> . . . creates a new set of patterns for which one can match >>in creating a custom name display. The new patterns are exactly the old >>ones, except that they can have parens around them, and the parens will >>only display if the element being surrounded is not empty. For example: >> >>%l, %f (%c) >> > > This pattern looks exactly like the one above. Did you add a function? Yes, I added some code that looks for the pattern "(%c)". > Perhaps you could use Capital C ("%C") to indicate a call name in > partenthesis. No, that already has a meaning (it makes the word capitalized). >>will display "Smith, Frederick (Fred)" if Fred is the callname and >> display >>"Jones, Martha" if Martha doesn't have a callname. > >>This patch takes extra care to make sure that there is minimal speed >>impact on the display name function. Patch is against current SVN trunk >>(2.2). > > I'm not really too concerned about speed. How long could you possibly make > it take? When I computed "age" in a similar manner, there was concern about speed. But this shouldn't be an issue. The patch could also be used for commas afterwards. All you need to do is add a pattern "%l," -> "ifNotEmpty(surname,'',',')" and add an additional section in the compiled expressions. Good idea! I'll propose that next, if this is accepted (with a couple of other additions). -Doug > ~Brian |
From: Zsolt <zso...@gm...> - 2007-04-15 12:12:19
|
Hi All, The original idea for the NameDisplay coding language was just to replace the previous rigid (only built-in) name formats with freedom of choice, while keeping the interface as simple as possible. We achieved half success: now basically any kind of name format is possible, while the editor is already a bit too complicated for Aunt Martha, I believe. For the question whether we should suppress the extra formatting characters or not, that time we voted no, due to the same reason Benny mentioned: what if the user actually wants to see what is missing. I am not sure which solution is more correct. For the editor interface the original idea was to make it even more simple: have e.g. a button for each name segment and another one for some extra formatters (e.g. '(', ')', '-', etc.) and let the user put the name format together simply by clicking on these buttons (or something similar). Originally we wanted to hide the formatting language completely from normal users (not to confuse them), and make it available only from GConf. However, we had no very good idea for the interface and also were a bit lazy, so we left it as it is today and waited if users started complaining about it... So this is what I think: 1. I have no problem to make the internal logic, even the language if needed, more complex and intelligent until it will not cause problem in the main views (like last time). 2. Yes, a better and nicer editor would be good, however it should be not more complicated, but more clear and easier for Aunt Martha to create her beloved name format. 3. The formatting language should be hidden, and only available from GConf or an advanced editor, so that we still have the freedom and at the same time we don't scare normal users away from creating custom format. I believe that this advanced way of formatting is only sufficient for hackers, like you guys, and not for Aunt Martha. Cheers, Zsolt |
From: Douglas S. B. <db...@cs...> - 2007-04-15 13:22:45
|
On Sun, April 15, 2007 8:09 am, Zsolt wrote: > Hi All, > > The original idea for the NameDisplay coding language was just to > replace the previous rigid (only built-in) name formats with freedom of > choice, while keeping the interface as simple as possible. > > We achieved half success: now basically any kind of name format is > possible, while the editor is already a bit too complicated for Aunt > Martha, I believe. > > For the question whether we should suppress the extra formatting > characters or not, that time we voted no, due to the same reason Benny > mentioned: what if the user actually wants to see what is missing. I am > not sure which solution is more correct. > > For the editor interface the original idea was to make it even more > simple: have e.g. a button for each name segment and another one for > some extra formatters (e.g. '(', ')', '-', etc.) and let the user put > the name format together simply by clicking on these buttons (or > something similar). Originally we wanted to hide the formatting language > completely from normal users (not to confuse them), and make it > available only from GConf. However, we had no very good idea for the > interface and also were a bit lazy, so we left it as it is today and > waited if users started complaining about it... > > So this is what I think: > 1. I have no problem to make the internal logic, even the language if > needed, more complex and intelligent until it will not cause problem in > the main views (like last time). > 2. Yes, a better and nicer editor would be good, however it should be > not more complicated, but more clear and easier for Aunt Martha to > create her beloved name format. > 3. The formatting language should be hidden, and only available from > GConf or an advanced editor, so that we still have the freedom and at > the same time we don't scare normal users away from creating custom > format. I believe that this advanced way of formatting is only > sufficient for hackers, like you guys, and not for Aunt Martha. > > Cheers, > Zsolt I don't disagree. I would only add that I think the current system can be adapted. So I don't advocate throwing the baby out with the bathwater, but just fine-tune what is already there. (I'd like to have the developers spend more time on genealogy-related stuff.) Here are some specific changes that are easy (I think I can do them) but make the system easier to use, and more powerful: 1) Make the current system deal with commas and parens as dependent punctuation, with a method for dealing with verbatim syntax. We can add a limited set of punctuation, but no need to make it completely general. 2) Make the current system also recognize keywords "surname", "firstname", "prefix", "suffix", etc. Would be English only, I think. 3) Make the description of a custom name display automatic. It would be just like the fixed ones, ie. "Lastname, Firstname (Callname)". Would be internationalized. -Doug |
From: <bm...@ca...> - 2007-04-16 08:19:53
|
Quoting "Douglas S. Blank" <db...@cs...>: > On Sun, April 15, 2007 8:09 am, Zsolt wrote: >> Hi All, >> >> The original idea for the NameDisplay coding language was just to >> replace the previous rigid (only built-in) name formats with freedom of >> choice, while keeping the interface as simple as possible. >> >> We achieved half success: now basically any kind of name format is >> possible, while the editor is already a bit too complicated for Aunt >> Martha, I believe. >> >> For the question whether we should suppress the extra formatting >> characters or not, that time we voted no, due to the same reason Benny >> mentioned: what if the user actually wants to see what is missing. I am >> not sure which solution is more correct. >> >> For the editor interface the original idea was to make it even more >> simple: have e.g. a button for each name segment and another one for >> some extra formatters (e.g. '(', ')', '-', etc.) and let the user put >> the name format together simply by clicking on these buttons (or >> something similar). Originally we wanted to hide the formatting language >> completely from normal users (not to confuse them), and make it >> available only from GConf. However, we had no very good idea for the >> interface and also were a bit lazy, so we left it as it is today and >> waited if users started complaining about it... >> >> So this is what I think: >> 1. I have no problem to make the internal logic, even the language if >> needed, more complex and intelligent until it will not cause problem in >> the main views (like last time). >> 2. Yes, a better and nicer editor would be good, however it should be >> not more complicated, but more clear and easier for Aunt Martha to >> create her beloved name format. >> 3. The formatting language should be hidden, and only available from >> GConf or an advanced editor, so that we still have the freedom and at >> the same time we don't scare normal users away from creating custom >> format. I believe that this advanced way of formatting is only >> sufficient for hackers, like you guys, and not for Aunt Martha. >> >> Cheers, >> Zsolt > > I don't disagree. I would only add that I think the current system can be > adapted. So I don't advocate throwing the baby out with the bathwater, but > just fine-tune what is already there. (I'd like to have the developers > spend more time on genealogy-related stuff.) > > Here are some specific changes that are easy (I think I can do them) but > make the system easier to use, and more powerful: > > 1) Make the current system deal with commas and parens as dependent > punctuation, with a method for dealing with verbatim syntax. We can add a > limited set of punctuation, but no need to make it completely general. > > 2) Make the current system also recognize keywords "surname", "firstname", > "prefix", "suffix", etc. Would be English only, I think. > > 3) Make the description of a custom name display automatic. It would be > just like the fixed ones, ie. "Lastname, Firstname (Callname)". Would be > internationalized. I like this 3. About 2, I think only CLI arguments/options should not be internationalized, all the rest should. > -Doug > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: <bm...@ca...> - 2007-04-16 08:17:59
|
Some things I want to note here: 1/I don't necessarely want a certain name display I have in the GRAMPS program, to be on the reports. Having the possibility to override the GRAMPS setting for reports (like is the case now in some graphs) is important. A good general dialog callable from the reports and returning a setting like 'Firstname, Lastname (Callname)' would therefore be very usefull. 2/Gconf? Never used it, and hope I never have too. GRAMPS is supposed to be a GTK application fitting best with GNOME as I understand it. It looks just as good here on KDE, or in DSL with XFCE. and I would greatly appreciate it if any advanced user settings can be done easily in all the possible desktop managers available on linux (no idea if that is the case for gconf but I did hear somewhere about a GNOME gconf editor so I suppose not). Quoting Zsolt <zso...@gm...>: > Hi All, > > The original idea for the NameDisplay coding language was just to > replace the previous rigid (only built-in) name formats with freedom of > choice, while keeping the interface as simple as possible. > > We achieved half success: now basically any kind of name format is > possible, while the editor is already a bit too complicated for Aunt > Martha, I believe. > > For the question whether we should suppress the extra formatting > characters or not, that time we voted no, due to the same reason Benny > mentioned: what if the user actually wants to see what is missing. I am > not sure which solution is more correct. > > For the editor interface the original idea was to make it even more > simple: have e.g. a button for each name segment and another one for > some extra formatters (e.g. '(', ')', '-', etc.) and let the user put > the name format together simply by clicking on these buttons (or > something similar). Originally we wanted to hide the formatting language > completely from normal users (not to confuse them), and make it > available only from GConf. However, we had no very good idea for the > interface and also were a bit lazy, so we left it as it is today and > waited if users started complaining about it... > > So this is what I think: > 1. I have no problem to make the internal logic, even the language if > needed, more complex and intelligent until it will not cause problem in > the main views (like last time). > 2. Yes, a better and nicer editor would be good, however it should be > not more complicated, but more clear and easier for Aunt Martha to > create her beloved name format. > 3. The formatting language should be hidden, and only available from > GConf or an advanced editor, so that we still have the freedom and at > the same time we don't scare normal users away from creating custom > format. I believe that this advanced way of formatting is only > sufficient for hackers, like you guys, and not for Aunt Martha. > > Cheers, > Zsolt > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Don A. <don...@co...> - 2007-04-16 11:47:39
|
On Mon, 2007-04-16 at 10:17 +0200, bm...@ca... wrote: > 2/Gconf? Never used it, and hope I never have too. GRAMPS is supposed to = be a > GTK application fitting best with GNOME as I understand it. It looks just= as > good here on KDE, or in DSL with XFCE. and I would greatly appreciate=20 > it if any > advanced user settings can be done easily in all the possible desktop man= agers > available on linux (no idea if that is the case for gconf but I did hear > somewhere about a GNOME gconf editor so I suppose not). Actually, GRAMPS is a GNOME application that will run in a degraded manner in environments that cannot provide a GNOME environment (such as Windows). |