From: Gary B. <bur...@ya...> - 2007-10-30 17:17:06
|
Brian=0A=0A>>Could we possibly put the mime type under the picture/icon in = really small gray letters? Or put it somewhere else on the page?=0A>>Anyone= have any other ideas? =0A=0A=0A=0A=0AHow about using the 'alt' attribute o= n the <img> tag to show the media title, gramps ID and the mime type inform= ation.=0A=0AThat way the information does not need to be explicitly shown o= n the page but the user can still see the information when they move their = mouse pointer over the image.=0A=0ABye=0A=0AGary=0A=0A=0A=0A=0A ______= _____________________________________________________=0AYahoo! Answers - Go= t a question? Someone out there knows the answer. Try it=0Anow.=0Ahttp://uk= .answers.yahoo.com/ |
From: Brian M. <br...@gr...> - 2007-10-30 18:16:23
|
Gary,=0A=0A>>>Could we possibly put the mime type under the picture/icon in= really small gray letters? Or put it somewhere else on the page?=0A>>>Anyo= ne have any other ideas? =0A=0A=0A=0A=0A>How about using the 'alt' attribut= e on the <img> tag to show the media =0A>title, gramps ID and the mime type= information.=0A=0A>That way the information does not need to be explicitly= shown on the =0A>page but the user can still see the information when they= move=0A their mouse pointer =0A>over the image.=0A=0AThat's EXACTLY the cr= eative kind of solution I'm looking for.=0A=0A~Brian=0A=0A=0A=0A=0A |
From: <ste...@gm...> - 2007-10-30 18:23:31
|
The ALT tag is currently the title of the image. Do people want me to get rid of the title and replace it with the mime-type= ? Or maybe combine them? For example, we currently have something like: <img alt=3D"Uncle John at the cabin in 1943" ...> I could combine them such as: <img alt=3D"image/jpeg: Uncle John at the cabin in 1943" ...> ? St=E9phane |
From: James G. S. (jim) <jg...@sa...> - 2007-10-30 19:44:09
|
Stéphane Charette wrote: > The ALT tag is currently the title of the image. > > Do people want me to get rid of the title and replace it with the mime-type? > > Or maybe combine them? > > For example, we currently have something like: > > <img alt="Uncle John at the cabin in 1943" ...> > > I could combine them such as: > > <img alt="image/jpeg: Uncle John at the cabin in 1943" ...> > > ? My understanding of html is that alt is primarily intended to be short text that can substitute for the image, in the case of images being unavailable or disabled, or for audio rendering by a screenreader for the visually impaired. There is another attribute, title that can be added to (most) any tag, whose stated purpose is to provide tooltip content. The description of the alt attribute specifically uses the word "short", which I interpret as meaning it should not detract from the information flow when spoken. On a quick check with firefox, epiphany, and opera, title content shows as tooltips, but tooltips never show the alt content. Although that might be a configuration option, I suppose. In opera (only), titles (not alt) also show in the status line. So what is the best way? I personally do like the suggestion of putting mime time into the metadata just as SC has shown. But perhaps it should be in both alt and title? In recognition of the html spec use of "short", ideally the alt value should be truncated (with elipses, maybe) if longer than some limit (say 50 chars?). Regards, ..jim |
From: Brian M. <br...@gr...> - 2007-10-30 19:23:49
|
Stephane,=0A=0A>What is wrong=0A>in adding an option? I understand we don'= t want options for=0A>absolutely everything under the sun, but at the same = time, we often=0A>have people wanting things to remain exactly the same, an= d other=0A>people asking that we change stuff.=0A=0A1) Too many options are= confusing to the users (remember Aunt Martha. She doesn't think like you a= nd I do).=0A=0A2) Adding options adds complexity to the code. This increase= s the chances of bugs and makes it difficult to maintain. Some call this "f= eature creep". Others call it "code rot".=0A=0A3) Options are often a lazy = man's way of avoiding solving the real problem. It is best to identify the = use cases and find the right solution (and there is a RIGHT solution, not j= ust a best solution).=0A=0A>The narrativeweb pages are a good example of th= is. The pages are not=0A>created for me, for Brian, for Don, etc..., but a= re created primarily=0A>for the person who generates them. Yes, that perso= n is hoping family=0A>members will use the web site, but we should allow th= e generated web=0A>pages to conform to the preferences of the user that own= s the site.=0A=0A>Personally, I also like having the MIME type. (I just re= cently=0A>noticed it had been changed to "file type" when I upgraded to 2.2= .9.)=0A>But we already have 2 users asking that it be removed: this is=0A>= low-hanging fruit which will make those users and potentially other=0A>user= s very happy!=0A=0A>The good news is, those of you (like myself) who want t= o maintain the=0A>MIME-type information will still have it. Those who disl= ike it can=0A>easily remove it without having to manually edit all of their= .html=0A>pages.=0A=0A=0AYou're new, so this mistaken philosophy is underst= andable. But what you will learn is that YOU CAN'T MAKE EVERYONE HAPPY. Nor= should you try. If you spend your time chasing down all these "low-hanging= fruit" in order to satisfy every individual user's whim and desire, you wi= ll burn out quickly and Gramps will become a hacked up mess. You need to do= what is right for Gramps while keeping the majority of users in mind.=0A= =0AGood software design is about more than just writing code to make a prog= ram do stuff. It's about understanding the users needs (both the needs he k= nows about and the needs he doesn't know about). It's about writing code th= at is readable and maintainable. It's about elegant solutions that make peo= ple say "That's exactly the right way to do that" when they see it.=0A=0ATh= e narrative web report is a perfect example of how feature creep can ruin a= program. There are functions in there that are hundreds of lines long. The= re is code that runs way off the right side of my screen when I read it. So= metimes it takes me over an hour to figure out how a small part of it works= . But it didn't start out this way. It's the result of dozens of people eac= h adding in "one more little thing" for some user. If it continues on this = course, it will eventually rot into a pile of useless code.=0A=0ANow, we've= had at least one good suggestion. Let's keep thinking outside of the box a= nd see what else we can come up with.=0A=0A~Brian=0A |
From: Alex R. <sh...@gr...> - 2007-10-30 19:43:15
|
Just to chime in with a single bit of info. The ALT tag is there mainly for accessibility. That is, for the blind users to know what the image is, as well as for anybody when using text-only browsers that cannot display images. Whether or not it is right to shove the mime info into ALT tag should be considered with this in mind. Alex On Tue, 2007-10-30 at 12:23 -0700, Brian Matherly wrote: > Stephane, >=20 > >What is wrong > >in adding an option? I understand we don't want options for > >absolutely everything under the sun, but at the same time, we often > >have people wanting things to remain exactly the same, and other > >people asking that we change stuff. >=20 > 1) Too many options are confusing to the users (remember Aunt Martha. She= doesn't think like you and I do). >=20 > 2) Adding options adds complexity to the code. This increases the chances= of bugs and makes it difficult to maintain. Some call this "feature creep"= . Others call it "code rot". >=20 > 3) Options are often a lazy man's way of avoiding solving the real proble= m. It is best to identify the use cases and find the right solution (and th= ere is a RIGHT solution, not just a best solution). >=20 > >The narrativeweb pages are a good example of this. The pages are not > >created for me, for Brian, for Don, etc..., but are created primarily > >for the person who generates them. Yes, that person is hoping family > >members will use the web site, but we should allow the generated web > >pages to conform to the preferences of the user that owns the site. >=20 > >Personally, I also like having the MIME type. (I just recently > >noticed it had been changed to "file type" when I upgraded to 2.2.9.) > >But we already have 2 users asking that it be removed: this is > >low-hanging fruit which will make those users and potentially other > >users very happy! >=20 > >The good news is, those of you (like myself) who want to maintain the > >MIME-type information will still have it. Those who dislike it can > >easily remove it without having to manually edit all of their .html > >pages. >=20 >=20 > You're new, so this mistaken philosophy is understandable. But what you w= ill learn is that YOU CAN'T MAKE EVERYONE HAPPY. Nor should you try. If you= spend your time chasing down all these "low-hanging fruit" in order to sat= isfy every individual user's whim and desire, you will burn out quickly and= Gramps will become a hacked up mess. You need to do what is right for Gram= ps while keeping the majority of users in mind. >=20 > Good software design is about more than just writing code to make a progr= am do stuff. It's about understanding the users needs (both the needs he kn= ows about and the needs he doesn't know about). It's about writing code tha= t is readable and maintainable. It's about elegant solutions that make peop= le say "That's exactly the right way to do that" when they see it. >=20 > The narrative web report is a perfect example of how feature creep can ru= in a program. There are functions in there that are hundreds of lines long.= There is code that runs way off the right side of my screen when I read it= . Sometimes it takes me over an hour to figure out how a small part of it w= orks. But it didn't start out this way. It's the result of dozens of people= each adding in "one more little thing" for some user. If it continues on t= his course, it will eventually rot into a pile of useless code. >=20 > Now, we've had at least one good suggestion. Let's keep thinking outside = of the box and see what else we can come up with. >=20 > ~Brian --=20 Alexander Roitman http://gramps-project.org |
From: Duncan L. <dli...@gm...> - 2007-11-01 15:41:50
|
On Tue, 2007-10-30 at 12:43 -0700, Alex Roitman wrote: > Just to chime in with a single bit of info. > > The ALT tag is there mainly for accessibility. That is, for the > blind users to know what the image is, as well as for anybody > when using text-only browsers that cannot display images. > > Whether or not it is right to shove the mime info into ALT tag > should be considered with this in mind. ALT is not the place for this data, check W3C's website if you're unsure. ALT is for a description of the file's content, like: "GRAMPS logo" or "photo of our Jim". Duncan |
From: Gary B. <bur...@ya...> - 2007-10-30 20:00:57
|
Hello Jim=0A=0A>>My understanding of html is that alt is primarily intended= to be short=0A>>text that can substitute for the image, in the case of ima= ges being=0A>>unavailable or disabled, or for audio rendering by a screenre= ader for=0A>>the visually impaired. There is another attribute, title that = can be=0A>>added to (most) any tag, whose stated purpose is to provide tool= tip=0A content.=0A=0A=0AYes, sorry, the "title" attribute is the one I mean= t, not "alt". As you say, a screen reader will react to the "alt" tag where= as the "title" tag is the correct one for tooltips/mouseovers. Here we also= get into a difference between web browsers. Firefox (and other Gecko-based= browsers I guess) and Konqueror will use the "title" tag. Internet Explore= r, I believe uses the "alt" tag, although maybe version 7 has changed this = behaviour - don't know I've never used it.=0A=0AAnyway tooltips are one pos= sible way of showing this type of metadata. Any other ways need to take car= e not to bloat the overall size of the finished web report as it can get pr= etty big already.=0A=0ABye=0A=0AGary=0A=0A=0A=0A=09=09=0A__________________= _________________________________________ =0AYahoo! For Good - Sponsor a Lo= ndon Marathon runner - http://uk.promotions.yahoo.com/charity/london-marath= on |
From: James G. S. (jim) <jg...@sa...> - 2007-10-30 22:00:11
|
Gary Burton wrote: >.. > Yes, sorry, the "title" attribute is the one I meant, not "alt". As you say, a screen reader will react to the "alt" tag whereas the "title" tag is the correct one for tooltips/mouseovers. Here we also get into a difference between web browsers. Firefox (and other Gecko-based browsers I guess) and Konqueror will use the "title" tag. Internet Explorer, I believe uses the "alt" tag, although maybe version 7 has changed this behaviour - don't know I've never used it. > > Anyway tooltips are one possible way of showing this type of metadata. Any other ways need to take care not to bloat the overall size of the finished web report as it can get pretty big already. <heh> One might say that bloat is a pretty minor concern in html (or any markup) format. Useless bloat, however.. Regards, ..jim (doesn't much like javascript; doesn't like tables for layout) |
From: Benny M. <ben...@gm...> - 2007-10-30 23:41:52
|
As auser, I just want to say why I like the mime type. Not for jpeg or png that I can see anyway, but for pdf, odf or doc, that are shown as a generic icon. So the mime type avoids me having to go over the icon and see in the status bar blah.pdf or so, and know it is a pdf. So yeah, the mime type is also in my case useless in 95% of the cases. I don't mind a mouse-over effect instead, but the fact that I see the name of the file link on mouseover already covers that for me. Benny |
From: <ste...@gm...> - 2007-10-30 20:21:08
|
> 1) Too many options are confusing to the users (remember Aunt Martha. She > doesn't think like you and I do). Aunt Martha wont be checking ALT tags on images. And if Aunt Martha can figure out the "Character set encoding", "Note ID" and HTML headers/footers, then I'm certain she'll understand a simple on|off option called "Display 'File Type' on media pages". Let's leave her out of the current discussion. > 2) Adding options adds complexity to the code. This increases the chances= of > bugs and makes it difficult to maintain. Some call this "feature creep". = Others > call it "code rot". When I save a document in OO, or image in GIMP, I have the option to use several different formats. This is not code rot, nor feature creep. The same analogy applies when we want to add different ways to save -- or generate -- the HTML pages. For many of us, the NarrativeWeb tool is what we use most often to "export" our genealogy information and make it available to the rest of our family. Making things optional really shouldn't be that big of a deal. I ran into the same problem earlier this year when I wanted to add some new optional columns to NarrativeWeb. There is a lot of resistance to making changes, and the same people are reluctant to make things optional, meaning it seems unusually difficult to make any changes. > 3) Options are often a lazy man's way of avoiding solving the real proble= m. It > is best to identify the use cases and find the right solution (and there = is a > RIGHT solution, not just a best solution). No, in this case I see options as a ways of making changes yet keep NarrativeWeb the same for those who like how it currently works. On the other hand, there is no valid reason why "MIME-TYPE" or "FILE TYPE" needs to be included. I regularly browse the web, and just below all of the images on 99.9% of the web, there isn't a note telling me the image I just saw embedded in a web page happens to be "image/jpeg". If we're so opposed to having things optional, then why didn't we simply jump on board and tell the 2 users asking for this to be removed: "Yes, you're right, this is superfluous geek text, and needs not appear. We'll get rid of that asap"? > You're new, so this mistaken philosophy is understandable. But what you w= ill > learn is that YOU CAN'T MAKE EVERYONE HAPPY. Nor should you try. If you > spend your time chasing down all these "low-hanging fruit" in order to sa= tisfy > every individual user's whim and desire, you will burn out quickly and Gr= amps > will become a hacked up mess. You need to do what is right for Gramps whi= le > keeping the majority of users in mind. I'm trying to my hardest to not be insulted here. Note that I am not new at writing software. But with GRAMPS, what I find frustrating is that I spend more time convincing people to let me make changes. > The narrative web report is a perfect example of how feature creep can ru= in a > program. There are functions in there that are hundreds of lines long. Th= ere is > code that runs way off the right side of my screen when I read it. Someti= mes it > takes me over an hour to figure out how a small part of it works. But it = didn't > start out this way. It's the result of dozens of people each adding in "o= ne more > little thing" for some user. If it continues on this course, it will even= tually rot into > a pile of useless code. Good news is that we have an established means of providing options, especially on|off type of options, and that part of the code certainly isn't hard to read or maintain. And I should know, because other than FamilyLines, NarrativeWeb is the part of GRAMPS I've contributed to the most. I agree that parts of it are hard to read. There are sections I avoid because I still haven't figured it out. However, an on|off option that more than 1 user has asked for isn't the cause of the problem. > Now, we've had at least one good suggestion. Let's keep thinking outside = of > the box and see what else we can come up with. I have the code partially modified, but will not checkin until we get more suggestions, so I know which way this should run. At the moment it looks like the ALT and TITLE tags could both be used, and depending on the browser you may see one, or may see the other. St=E9phane |
From: <ste...@gm...> - 2007-10-31 06:54:37
|
> I have the code partially modified, but will not checkin until we get > more suggestions, so I know which way this should run. At the moment > it looks like the ALT and TITLE tags could both be used, and depending > on the browser you may see one, or may see the other. Just so we can say this was explored, here is someone who regularly uses the TITLE tag as well as the ALT tag...just in case you want to see it in your browser: http://xkcd.com/327/ Even after all this discussion, my preference is still to make it an optional item since some people want to retain the mime-type text in one form or another. I'll continue to wait and see if someone has more great ideas on where/when we should display it. St=E9phane |
From: Brian M. <br...@gr...> - 2007-10-30 19:26:50
|
Yeah, I don't think that is going to exactly work.=0A=0AI said it was "the = kind" of solution I was looking for, not "the" solution I was looking for.= =0A=0AWhat other ideas do we have? mouseovers? a details button? =0A=0Athin= k . . .think . . . think=0A=0A~Brian=0A=0A----- Original Message ----=0AFro= m: St=E9phane Charette <ste...@gm...>=0ATo: Brian Matherly <b= ri...@gr...>=0ACc: gra...@li...=0ASent: T= uesday, October 30, 2007 1:23:29 PM=0ASubject: Re: [Gramps-devel] [Gramps-u= sers] Web page clutter=0A=0A=0AThe ALT tag is currently the title of the im= age.=0A=0ADo people want me to get rid of the title and replace it with the= =0A mime-type?=0A=0AOr maybe combine them?=0A=0AFor example, we currently h= ave something like:=0A=0A<img alt=3D"Uncle John at the cabin in 1943" ...>= =0A=0AI could combine them such as:=0A=0A<img alt=3D"image/jpeg: Uncle John= at the cabin in 1943" ...>=0A=0A?=0A=0ASt=E9phane=0A=0A-------------------= ------------------------------------------------------=0AThis SF.net email = is sponsored by: Splunk Inc.=0AStill grepping through log files to find pro= blems? Stop.=0ANow Search log events and configuration files using AJAX an= d a browser.=0ADownload your FREE copy of Splunk now >> http://get.splunk.c= om/=0A_______________________________________________=0AGramps-devel mailin= g list=0AG...@li...=0Ahttps://lists.sourceforge.net= /lists/listinfo/gramps-devel=0A=0A=0A=0A |
From: Brian M. <br...@gr...> - 2007-10-30 21:44:29
|
Stephane,=0A=0A>> 1) Too many options are confusing to the users (remember = Aunt Martha.=0A She=0A>> doesn't think like you and I do).=0A>=0A>Aunt Mart= ha wont be checking ALT tags on images. And if Aunt Martha=0A>can figure o= ut the "Character set encoding", "Note ID" and HTML=0A>headers/footers, the= n I'm certain she'll understand a simple on|off=0A>option called "Display '= File Type' on media pages". Let's leave her=0A>out of the current discussi= on.=0A=0ASorry, but we can't leave Aunt Martha out of the conversation. She= represents our target user. All changes have to pass the "Aunt Martha" te= st before they are considered valid. This has been our philosophy for a lon= g time.=0A=0A>> 2) Adding options adds complexity to the code. This increas= es the=0A chances of=0A>> bugs and makes it difficult to maintain. Some cal= l this "feature=0A creep". Others=0A>> call it "code rot".=0A>=0A>When I sa= ve a document in OO, or image in GIMP, I have the option to=0A>use several = different formats. This is not code rot, nor feature=0A>creep. The same a= nalogy applies when we want to add different ways to=0A>save -- or generate= -- the HTML pages. For many of us, the=0A>NarrativeWeb tool is what we us= e most often to "export" our genealogy=0A>information and make it available= to the rest of our family. Making=0A>things optional really shouldn't be = that big of a deal.=0A=0AI don't think you are understanding what I'm writi= ng. Your example isn't analogous to what I'm trying to say. Consider this: = When you save a document in OO, you get a standard save-as dialog with only= a small handful of options. You don't get multiple tabs each with a dozen = options to choose from. The designers could have added feature after featur= e to the save-as function and resulted in 20 options for the user to choose= from. But they didn't.=0A=0A>I ran into the same problem earlier this year= when I wanted to add=0A>some new optional columns to NarrativeWeb. There = is a lot of=0A>resistance to making changes, and the same people are reluct= ant to=0A>make things optional, meaning it seems unusually difficult to mak= e any=0A>changes.=0A=0AWe were trying to avoid featuritis (http://en.wikipe= dia.org/wiki/Creeping_featurism).=0A=0A>> You're new, so this mistaken phil= osophy is understandable. But what=0A you will=0A>> learn is that YOU CAN'T= MAKE EVERYONE HAPPY. Nor should you try. If=0A you=0A>> spend your time ch= asing down all these "low-hanging fruit" in order=0A to satisfy=0A>> every = individual user's whim and desire, you will burn out quickly=0A and Gramps= =0A>> will become a hacked up mess. You need to do what is right for Gramps= =0A while=0A>> keeping the majority of users in mind.=0A>=0A>I'm trying to = my hardest to not be insulted here. Note that I am not=0A>new at writing s= oftware. But with GRAMPS, what I find frustrating is=0A>that I spend more = time convincing people to let me make changes.=0A=0AThere is no reason to b= e insulted.=0A=0AJust because a person can enter program instructions into = a computer doesn't mean he can structure those instructions well.=0AJust be= cause a person can write well structured code doesn't mean he is good at de= signing that code into modules.=0AJust because a person is good at designin= g software modules doesn't mean he is good at assembling them into an archi= tecture.=0AJust because a person is good at building a software architectur= e doesn't mean he knows the best way to fill a user's needs.=0AJust because= a person is good at knowing how to best fill a user's needs doesn't mean t= hat he actually knows what the user needs.=0AJust because a person knows wh= at a user needs doesn't mean he can enter program instructions into a compu= ter . . . =0A=0AYou get the idea. I don't know exactly where you fit in the= re, but you can't be good at everything. It's just not possible.=0A=0AGramp= s is a community project. It takes all kinds of people to make it work. Tha= t's just the facts of an open source project. If you think this is tough, i= magine trying to get a new feature included in the Linux Kernel! It's hard = work and it can be frustrating at times. But if we all have the best intere= st of Gramps in mind, we eventually come to a solution.=0A=0AWhen a person = tells you that they think something should change (like a mime type), you s= hould respect their perspective.=0AAnd when another person tells you that t= hey have concerns about adding another option, you should respect their per= spective as well.=0A=0A>> The narrative web report is a perfect example of = how feature creep=0A can ruin a=0A>> program. There are functions in there = that are hundreds of lines=0A long. There is=0A>> code that runs way off th= e right side of my screen when I read it.=0A Sometimes it=0A>> takes me ove= r an hour to figure out how a small part of it works. But=0A it didn't=0A>>= start out this way. It's the result of dozens of people each adding=0A in = "one more=0A>> little thing" for some user. If it continues on this course,= it will=0A eventually rot into=0A>> a pile of useless code.=0A=0A>I agree = that parts of it are hard to read. There are=0A>sections I avoid because I= still haven't figured it out. However, an=0A>on|off option that more than= 1 user has asked for isn't the cause of=0A>the problem.=0A=0AReading this = article again (http://en.wikipedia.org/wiki/Creeping_featurism) just remind= ed me why I don't use Emacs.=0A=0A>At the moment=0A>it looks like the ALT a= nd TITLE tags could both be used, and depending=0A>on the browser you may s= ee one, or may see the other.=0A=0AI think you are moving down the right pa= th. You're doing all the right things and I believe you'll find the right s= olution. Thanks for hanging in there - you really do make a difference.=0A= =0A~Brian=0A=0A |
From: Brian M. <br...@gr...> - 2007-10-31 03:48:07
|
Benny,=0A=0A>As auser, I just want to say why I like the mime type. Not for= jpeg or png that I can see anyway, but for pdf, odf or doc, that are shown= as a generic icon.=0A>So the mime type avoids me having to go over the ico= n and see in the status bar blah.pdf or so, and know it is a pdf.=0A=0A>= =0A>So yeah, the mime type is also in my case useless in 95% of the cases.= =0A>I don't mind a mouse-over effect instead, but the fact that I see the n= ame of the file link on mouseover already covers that for me.=0A=0A=0AThat = is some good insight. And I think it is true for most of the mime-type prop= onents. The mime-type doesn't need to be displayed prominently like it is n= ow, but it shouldn't go away, either.=0A=0A~Brian=0A=0A |
From: Brian M. <br...@gr...> - 2007-11-01 11:56:54
|
Stephane,=0A=0A>I'll continue to wait and see if someone has more great ide= as on=0A>where/when we should display it.=0A=0AI think Don was right on whe= n he said:=0A=0A "The MIME type should not be shown for obvious file types= , such as=0A images or text documents (image/* or text/*). For other form= ats, we=0A should display the files type in a readable form if possible,= =0A falling=0A back to mime types only when the system does not provide a= =0A descriptive name for mime type."=0A=0AHave you looked into this? I re= ally think this might be THE answer. If we could display some file type inf= ormation only when we display the "document.png" icon for non-image types, = I think everyone could be satisfied. What do you think?=0A=0AThanks,=0A=0A= ~Brian=0A=0A=0A=0A |
From: <ste...@gm...> - 2007-11-03 04:54:45
|
Sorry about making a fuss several days ago about this feature. I agree Don's suggestion is a better solution than adding a new option. See my questions below: > "The MIME type should not be shown for obvious file types, such as > images or text documents (image/* or text/*). For other formats, we > should display the files type in a readable form if possible, > falling back to mime types only when the system does not provide a > descriptive name for mime type." Anyone know where I can get the "short" name for a mime type? Let me rephrase that -- is there an API I should be calling without reverting to implementing my own lookup dictionary? My fix is to not display the file type for image/*. I still show it even for text/plain, since it is strange to see the "document" icon for text/plain but not have a mime type. Some mime types, like OpenOffice documents ("application/vnd.oasis.opendocument.text") are quite a mouthful. St=E9phane |
From: Don A. <do...@gr...> - 2007-11-03 05:01:13
|
We already do this in multiple places in the program, so we have a nice API for it. You should be able to call: import Mime description = Mime.get_description(mime_type) Don On Fri, 2007-11-02 at 21:54 -0700, Stéphane Charette wrote: > Sorry about making a fuss several days ago about this feature. I > agree Don's suggestion is a better solution than adding a new option. > See my questions below: > > > "The MIME type should not be shown for obvious file types, such as > > images or text documents (image/* or text/*). For other formats, we > > should display the files type in a readable form if possible, > > falling back to mime types only when the system does not provide a > > descriptive name for mime type." > > Anyone know where I can get the "short" name for a mime type? Let me > rephrase that -- is there an API I should be calling without reverting > to implementing my own lookup dictionary? > > My fix is to not display the file type for image/*. I still show it > even for text/plain, since it is strange to see the "document" icon > for text/plain but not have a mime type. Some mime types, like > OpenOffice documents ("application/vnd.oasis.opendocument.text") are > quite a mouthful. > > Stéphane > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Don A. <do...@gr...> - 2007-11-03 05:16:15
|
I also wanted to reiterate that my major point on this subject was that that project needs to avoid the whole "add an option" approach. This is an easy trap to fall into, and most projects fall into this trap. I've always tried to advocate identifying the root of the problem and developing a solution that "did the right thing". And it works better if there is a good discussion about finding the right thing. Usually with a bit of thought, a clean "right" solution can be found. Adding an option should be the last resort, not the first solution. So, I would encourage issues like this continue to be brought up on the lists, and that *all* interested people should try to help find a "do the right thing" solution. When you do this, you solve to problem, not patch a symptom. I think this issue showed good participation by the mailing list, and I would like to see this continue. *Everyone* (even you lurkers out there) should feel free to participate. This is how a project succeeds. Don On Fri, 2007-11-02 at 21:54 -0700, Stéphane Charette wrote: > Sorry about making a fuss several days ago about this feature. I > agree Don's suggestion is a better solution than adding a new option. > See my questions below: > > > "The MIME type should not be shown for obvious file types, such as > > images or text documents (image/* or text/*). For other formats, we > > should display the files type in a readable form if possible, > > falling back to mime types only when the system does not provide a > > descriptive name for mime type." > > Anyone know where I can get the "short" name for a mime type? Let me > rephrase that -- is there an API I should be calling without reverting > to implementing my own lookup dictionary? > > My fix is to not display the file type for image/*. I still show it > even for text/plain, since it is strange to see the "document" icon > for text/plain but not have a mime type. Some mime types, like > OpenOffice documents ("application/vnd.oasis.opendocument.text") are > quite a mouthful. > > Stéphane > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Duncan L. <dli...@gm...> - 2007-11-03 21:11:56
|
I've been thinking about this one a bit for several reasons, but just at this moment I would like to ask a general question about adding options... What issues does having a config file raise? I expect we'll agree that Firefox is a good piece of software which has a good reputation of controlling feature creep and other clutter. But at the same time Firefox is extremely customisable. My small knowledge of programming, from writing PHP for my own websites, is that a simple IF statement can be used to check a config file which can switch on and off all sorts of options and features. Adding lots of options to the GUI dialogs would give the sort of problems KDE gets criticised for, but the other approach, a config file, means that if you think of an option you would like you can often find that it's a matter of a small edit in a config file. No clutter, more options. Of course if certain config options turn out to be very popular then they can have their default state changed. Naturally, the issue about extra options bringing extra bugs is real. But I assume much of this can be avoided by saying: * Take a backup before changing a config option * If something goes wrong, reset the config file to defaults * If a config option looks like the cause of a bug then a suitable warning is added to that option, or the option is removed until someone comes forward and fixes the bug. So, what issues does having a config file raise? Duncan |
From: Don A. <do...@gr...> - 2007-11-03 21:40:37
|
First off, we need to ask ourselves the question: Why is adding an option better than doing the right thing? But lets get back to the question of options. First, I would recommend that you read the following page: http://en.wikipedia.org/wiki/Feature_creep If you go back to my original message, look at points 2 and 3. I believe they explain this rather clearly. So, I add them here: 2) Code is hard to maintain. Adding options makes code ugly, hard to read, and hard to maintain. This leads to bugs. I'm speaking from=20 years of experience. Many, if not most, of the times when we've had a major bug, it has come from the addition of an option. The more options, the more difficult a program is to test. The more difficult to test, the more likely there will be bugs. 3) Documentation. Look at some of the descriptions for the existing options in the UI. We have very little space, and very little=20 ability to describe what the option does. Also, look at the manual. Very few options are documented. So how does the user know what=20 things are supposed to do? Your proposal of adding things in a config file is actually now even worse. Now, we have all the detriments listed above, but now the options will only benefit those who are advanced enough to handle a config file. Don On Sat, 2007-11-03 at 22:11 +0100, Duncan Lithgow wrote: > I've been thinking about this one a bit for several reasons, but just at > this moment I would like to ask a general question about adding > options... >=20 > What issues does having a config file raise? >=20 > I expect we'll agree that Firefox is a good piece of software which has > a good reputation of controlling feature creep and other clutter. But at > the same time Firefox is extremely customisable. My small knowledge of > programming, from writing PHP for my own websites, is that a simple IF > statement can be used to check a config file which can switch on and off > all sorts of options and features. >=20 > Adding lots of options to the GUI dialogs would give the sort of > problems KDE gets criticised for, but the other approach, a config file, > means that if you think of an option you would like you can often find > that it's a matter of a small edit in a config file. No clutter, more > options. Of course if certain config options turn out to be very popular > then they can have their default state changed. >=20 > Naturally, the issue about extra options bringing extra bugs is real. > But I assume much of this can be avoided by saying: >=20 > * Take a backup before changing a config option > * If something goes wrong, reset the config file to defaults > * If a config option looks like the cause of a bug then a suitable > warning is added to that option, or the option is removed until someone > comes forward and fixes the bug. >=20 > So, what issues does having a config file raise? >=20 > Duncan >=20 |
From: <ste...@gm...> - 2007-11-03 23:34:40
|
On 11/3/07, Don Allingham <do...@gr...> wrote: > First off, we need to ask ourselves the question: > > Why is adding an option better than doing the right thing? Note that this implies there is a single lone *ONE* way to do something rig= ht. Worded differently, that statement means that if two people cannot agree on exactly how something should look, one of them must be wrong. The problem I have with our reluctance to add options is that I actually would like to further customize the main "export" I have from GRAMPS -- the NarrativeWeb output. But there is a lot of pressure from within GRAMPS not to change it. I'm conflicted as to what to do. I was thinking I could factor out the base functionality of NW, and then have 2 derived classes...something like the "current" NarrativeWeb and then another version that outputs things slightly differently. But this means a whole new report to maintain versus several options within an existing report. I'm not certain having a new report which is 85% the same as an existing one is beneficial to GRAMPS. St=E9phane |
From: Douglas S. B. <db...@cs...> - 2007-11-04 03:26:31
|
I think everyone would agree that good software finds the right number of features. Not enough, and it might not be useful; too many and it might be hard to use and maintain. But "option" does not necessarily mean "feature". Sometimes, options help make code better defined and more abstract. When an option is like a parameter, then it can be a good thing and help keep code small yet flexible. How do we decide what options/features to add? I disagree with Don that there is usually a right answer. It depends on how you work, and changes over time. But I do think it is true that the first solution that comes to mind is usually not the best. Having a concrete patch to discuss is usually a good idea. For one thing, implementing the option/feature will sometimes reveal to the developer a better solution. Or it can demonstrate how the code can be improved to others. Other developers might tend to take a proposal more seriously if they can test it out. But the proposer should be prepared that it might not be accepted as is. Of course, if it isn't accepted, you still have code that does what you want---in your code. I think it is common that a lot of us have personal code in our copies of GRAMPS. Also, I think that writing tests and documentation should become a part of the development process. I hope that we can keep this process fun! We don't want to burn too much energy and drive away new developers just starting out with GRAMPS. -Doug On Sat, November 3, 2007 5:40 pm, Don Allingham wrote: > First off, we need to ask ourselves the question: > > Why is adding an option better than doing the right thing? > > But lets get back to the question of options. First, I would recommend > that you read the following page: > > http://en.wikipedia.org/wiki/Feature_creep > > If you go back to my original message, look at points 2 and 3. I believe > they explain this rather clearly. So, I add them here: > > 2) Code is hard to maintain. Adding options makes code ugly, hard to > read, and hard to maintain. This leads to bugs. I'm speaking from > years of experience. Many, if not most, of the times when we've had > a major bug, it has come from the addition of an option. The more > options, the more difficult a program is to test. The more > difficult to test, the more likely there will be bugs. > > 3) Documentation. Look at some of the descriptions for the existing > options in the UI. We have very little space, and very little > ability to describe what the option does. Also, look at the manual. > Very few options are documented. So how does the user know what > things are supposed to do? > > Your proposal of adding things in a config file is actually now even > worse. Now, we have all the detriments listed above, but now the options > will only benefit those who are advanced enough to handle a config file. > > Don > > > On Sat, 2007-11-03 at 22:11 +0100, Duncan Lithgow wrote: >> I've been thinking about this one a bit for several reasons, but just at >> this moment I would like to ask a general question about adding >> options... >> >> What issues does having a config file raise? >> >> I expect we'll agree that Firefox is a good piece of software which has >> a good reputation of controlling feature creep and other clutter. But at >> the same time Firefox is extremely customisable. My small knowledge of >> programming, from writing PHP for my own websites, is that a simple IF >> statement can be used to check a config file which can switch on and off >> all sorts of options and features. >> >> Adding lots of options to the GUI dialogs would give the sort of >> problems KDE gets criticised for, but the other approach, a config file, >> means that if you think of an option you would like you can often find >> that it's a matter of a small edit in a config file. No clutter, more >> options. Of course if certain config options turn out to be very popular >> then they can have their default state changed. >> >> Naturally, the issue about extra options bringing extra bugs is real. >> But I assume much of this can be avoided by saying: >> >> * Take a backup before changing a config option >> * If something goes wrong, reset the config file to defaults >> * If a config option looks like the cause of a bug then a suitable >> warning is added to that option, or the option is removed until someone >> comes forward and fixes the bug. >> >> So, what issues does having a config file raise? >> >> Duncan -- Douglas S. Blank Associate Professor, Bryn Mawr College http://cs.brynmawr.edu/~dblank/ Office: 610 526 6501 |