Re: [Geeqie-devel] Documentation and code standards
Hi > https://gitorious.org/geeqie/geeqie/archive-tarball/master > > You can find that link if you look at the log of a branch on the right > side. Thanks for the info. >> During copy/move/rename there is no thumbnail displayed when there >> is a destination file conflict (I've made a patch to do this, which >> is ok for me, but it is a poor technical solution to the problem). > Jup, that I was annoyed about once myself. Just post your patch, maybe > it can be used. It is the last patch in the cclark branch on github. The problem area is around line 407 of file_data_new.c where I use inodes. That's clearly not a general solution. I guess a better solution is to create a FileData structure for the target file before an entry is made into file_data_planned_change_hash. But there's also the problem of file_data_ref and file_data_unref. [The first patch in that branch is intended to solve the problem described in http://sourceforge.net/mailarchive/forum.php?thread_name=20110121140713.41f82358%40gmail.com&forum_name=geeqie-devel] > There is just one case I use an other tool -- xv -- is to view images > the fast way as there is no other application than xv out in the wild > that is that fast. (See also my own work on xv[0].) I remember that from years ago! I have no recollection of why I stopped using it - I'll take a look at your website. Colin Clark.. -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Documentation and code standards
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Am Do den 5. Mai 2011 um 8:50 schrieb Colin Clark: > What I find missing is high-level documentation, not low-level. An > overall description of the way the system is organised and how the > main functions and structures should be used. True. > But in my experience, programmers won't produce documentation even > when they are being paid to do it, Partly true. I think documentation is possible. Its not a nice job to do but it is possible and has its effort. > Line length was important to me when I used 72-character terminals > nearly half a century ago. Now I use a visual editor with line-wrap > enabled. No matter what size window I use, the code is readable. Also just partly true. Line length is not that important as it was in the past due to wrapping editors. However, it might be important as wrapping do not produce that readable code than manual wrapping can produce. For example if you have a if construct with many conditions it might be error prone to read it if you use automatic wrapping. If you break this expression manual you can group them together in logical parts. > But I do find it very surprising that Geeqie has a non-standard > coding format. Layout consistency could be achieved if the > developers selected a standard format - maybe Allman or Whitesmith - I do not know Allman or whitesmith without using google. But do you hear about Gnu-Style or Kernigan-Richie-Style? I think we are pretty near to the Gnu-Style. > and run all code through a code beautifier before putting it in the > repository. Bad idea as the current code would be globally changed. So that could only help for new code. However, with the most common code beautifiers you can define the style pretty flexible. > Would it be possible for source tars (or even .deb files) of the > latest files to be put on the Geeqie homepage on sourceforge? Is it > possible for this do be done automatically whenever one of the git > repositories is updated? https://gitorious.org/geeqie/geeqie/archive-tarball/master You can find that link if you look at the log of a branch on the right side. > I would also encourage the developers to try to make Geeqie at least > as good as GQview. There are two problems where I find GQview is > significantly better than Geeqie: > > During copy/move/rename there is no thumbnail displayed when there > is a destination file conflict (I've made a patch to do this, which > is ok for me, but it is a poor technical solution to the problem). Jup, that I was annoyed about once myself. Just post your patch, maybe it can be used. > When I work with folders containing several thousand files, any > operation on the files results in the view scrolling away from the > area I am working on. I guess this is the same as bug *3107316*, and > I assume it's because of gtktreeview being updated in the idle loop. That I am not the right person about. I was not diving into this part of geeqie too much. There is also one or two other but I did mention about them in earlier mails. > But whatever, when I'm doing this kind of work I have to switch back > to GQview! I did myself. However, as I pushed myself to not doing that, I can normally work well with geeqie. ;-) There is just one case I use an other tool -- xv -- is to view images the fast way as there is no other application than xv out in the wild that is that fast. (See also my own work on xv[0].) Regards Klaus [0] http://www.ethgen.ch/cgi-bin/gitweb.cgi?p=xv.git - -- Klaus Ethgenhttp://www.ethgen.ch/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBTcJ9K5+OKpjRpO3lAQr8xQf/UWLrC6jl/mmkNC1fKlnb9WeQ/FWexGa6 zeS7l6QiBz2SUEZSnZemLTI3KdludNfeDJPSmt1f95iCfqwI3VtDff5S8HxPX0l1 88svQLI1hYTrb+0kTGMELyDPYXpwdEiQm1BuJCDpzFTKcauo5AWQ6LHw7gSV3Cx+ tpKQxlzS4et2w6P+Wpcb3A6BUs10RE61UQgPTGbmlw3w+fFpH2X8y02X+/d4l/4v ghJl+AkQjH2F6bdHPLtQsG2t1ilXfW9+CJaKGVa75ijmido/IwXWWomLiY4csISW vI2eLFNInX4ESuwuJ5s6LXCzpbRZocR/5y2QE244OjwlG2jpA3ygaA== =eYQ/ -END PGP SIGNATURE- -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Documentation and code standards
On 05/05/2011 07:50 AM, Colin Clark wrote: > Hi > Perhaps I could make some comments here not as a developer, but as a user. >> 1) It's probably a good idea for us to start documenting the functions >> we write and the APIs we create. For one, it's a reminder to think >> about what specific problems the function/API is solving. Beyond that, >> it helps someone unfamiliar with the code figure out what's going on, >> and it helps them avoid misusing a particular function. > What I find missing is high-level documentation, not low-level. An > overall description of the way the system is organised and how the main > functions and structures should be used. But in my experience, > programmers won't produce documentation even when they are being paid to > do it, and no-one is being paid to work on Geeqie. Being realistic, I > don't think it is reasonable to expect people to do this. I agree that high-level documentation is missing; this is what Klaus also mentioned at the end of his email. I specifically mentioned function-level documentation because the pieces are easy, and as we gradually get more coverage, writing a higher-level document becomes that much easier. >> 2) We need to have a maximum line length. It can be long, sure, but >> it's pretty obscene when there are lines so long that they wrap on my >> 26" widescreen monitor (layout_util.c is a pretty bad offender). I'm >> going to suggest 160 characters; see * below. >> > Line length was important to me when I used 72-character terminals > nearly half a century ago. Now I use a visual editor with line-wrap > enabled. No matter what size window I use, the code is readable. I find it visually disconcerting when text wraps automatically at what is typically some arbitrary point in the line. I think it would be more readable if the breaks were made intentionally rather than incidentally. > But I do find it very surprising that Geeqie has a non-standard coding > format. Layout consistency could be achieved if the developers selected > a standard format - maybe Allman or Whitesmith - and run all code > through a code beautifier before putting it in the repository. Time > spent on code formatting by hand is not a good use of time and will > result in inconsistencies. I'm not a fan of auto-formatters because they typically make it hard to deviate from the standard, _even in situations where the deviation would make code that is more readable_. > > > May I also make a plea for the common user, people like me who can just > about do a configure/make. > > Would it be possible for source tars (or even .deb files) of the latest > files to be put on the Geeqie homepage on sourceforge? Is it possible > for this do be done automatically whenever one of the git repositories > is updated? Not to dismiss your plea, but please remember that Geeqie is a project whose development was essentially stalled for a year and a half, and is only now just starting to get back up to speed. Those things will undoubtedly come in time, but now is certainly not the time for people to overcommit again. We can probably wait for any sort of automated stuff until we average more than one commit to master per month. > I would also encourage the developers to try to make Geeqie at least as > good as GQview. There are two problems where I find GQview is > significantly better than Geeqie: At this point, I think it's most important for devs to work on whatever the heck they want; something (anything) is better than nothing. Later on down the line, we can probably start making a more concerted effort to fix the bugs that have been reported and add useful features, but at this point, I think the key first step is for people to get back in the habit of spending time working on geeqie, and coming up with changes that end up in master. --xsdg -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Documentation and code standards
Hi Perhaps I could make some comments here not as a developer, but as a user. 1) It's probably a good idea for us to start documenting the functions we write and the APIs we create. For one, it's a reminder to think about what specific problems the function/API is solving. Beyond that, it helps someone unfamiliar with the code figure out what's going on, and it helps them avoid misusing a particular function. What I find missing is high-level documentation, not low-level. An overall description of the way the system is organised and how the main functions and structures should be used. But in my experience, programmers won't produce documentation even when they are being paid to do it, and no-one is being paid to work on Geeqie. Being realistic, I don't think it is reasonable to expect people to do this. 2) We need to have a maximum line length. It can be long, sure, but it's pretty obscene when there are lines so long that they wrap on my 26" widescreen monitor (layout_util.c is a pretty bad offender). I'm going to suggest 160 characters; see * below. Line length was important to me when I used 72-character terminals nearly half a century ago. Now I use a visual editor with line-wrap enabled. No matter what size window I use, the code is readable. But I do find it very surprising that Geeqie has a non-standard coding format. Layout consistency could be achieved if the developers selected a standard format - maybe Allman or Whitesmith - and run all code through a code beautifier before putting it in the repository. Time spent on code formatting by hand is not a good use of time and will result in inconsistencies. May I also make a plea for the common user, people like me who can just about do a configure/make. Would it be possible for source tars (or even .deb files) of the latest files to be put on the Geeqie homepage on sourceforge? Is it possible for this do be done automatically whenever one of the git repositories is updated? I would also encourage the developers to try to make Geeqie at least as good as GQview. There are two problems where I find GQview is significantly better than Geeqie: During copy/move/rename there is no thumbnail displayed when there is a destination file conflict (I've made a patch to do this, which is ok for me, but it is a poor technical solution to the problem). When I work with folders containing several thousand files, any operation on the files results in the view scrolling away from the area I am working on. I guess this is the same as bug *3107316*, and I assume it's because of gtktreeview being updated in the idle loop. But whatever, when I'm doing this kind of work I have to switch back to GQview! But again, one must be realistic, and a combination of GQview and Geeqie works well for me as is. Colin Clark.. -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Documentation and code standards
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello folks, Am Mo den 2. Mai 2011 um 17:42 schrieb Omari Stephens: > Howdy, all. It's time for a thought on code cleanliness :-) That is my objective to. > 2) We need to have a maximum line length. It can be long, sure, but > it's pretty obscene when there are lines so long that they wrap on my > 26" widescreen monitor (layout_util.c is a pretty bad offender). I'm > going to suggest 160 characters; see * below. Well, personally I do not care about maximum line length. And I prefer long lines over to short lines. (Not to mean that long lines are preferable but short broken down lines are horrible to read.) 160 characters are ok for me. > 3) Indentation. First, we should probably document the size of the tabs > (currently 8 characters, at least from the one file I'm looking at). See also the vim modeline in the source files, yes. > Secondly, it would take a lot of effort to switch, but I think we should > at least consider a more compact indentation format. I'm personally a > fan of 4 spaces. But I think that the width of our indents is a > contributing factor to the immense lengths of lines in our code. I myself prefer to have an indent of 3 spaces. But however, that is personal preferences. I'll add one point. It would be nice if we have something like a map that shows which code parts are involved in which part of the UI. The most time I spend is searching where that particular function is implemented. This is more complicate with the asynchrony design of GUIs like GTK. (QT and other are not better ...) That was one of the reasons I once think of redesigning the GUI part with glade. But that was much to much to get finished in recent times. Regards Klaus - -- Klaus Ethgenhttp://www.ethgen.ch/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBTb7/65+OKpjRpO3lAQpnMQf+LOboAeTd15o8SSXvZ1lReNLJJduizKyd kM+Yuuz0XUVIkKw74PbIoYveKtQMr7mCCmjdB2zFZOX0Uwlgn0P6rGeRHuqiXyoS oVBBgeYP4/daH6IAtARwhqxAOZ5q+LsOQAf7NOI8ig/IFpHT8Jspbz6xDNT/gTqO hXIeL1bAq7D8iGUP1DktXVoKNa9oyA9BVCojRKkpfeYfTrCvXLbpz4JpxOZuTViM ZMk3h4zfPXsaftUaHUCiY21YAYU7ZOTgdBoC9EB1wxWZ2SFs72AL8OUkyZjgQNE3 qjK47fIvypOQ1Zu6qSdX9wvbkMnam3zRBBbMOClpUOdin07KcIeqlg== =+VVE -END PGP SIGNATURE- -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
[Geeqie-devel] Documentation and code standards
Howdy, all. It's time for a thought on code cleanliness
1) It's probably a good idea for us to start documenting the functions
we write and the APIs we create. For one, it's a reminder to think
about what specific problems the function/API is solving. Beyond that,
it helps someone unfamiliar with the code figure out what's going on,
and it helps them avoid misusing a particular function. That will help
keep the code clean because it'll decrease the likelihood that we have
to disentangle two bits of code that shouldn't have been coupled in the
first place. As mentioned in CODING, we use doxygen.
Note that my intention here isn't to have folks pick through the code
and document _every last thing right now_. But rather, it's for people
to document the code that they're working with, working on, and writing,
as they do so.
2) We need to have a maximum line length. It can be long, sure, but
it's pretty obscene when there are lines so long that they wrap on my
26" widescreen monitor (layout_util.c is a pretty bad offender). I'm
going to suggest 160 characters; see * below.
3) Indentation. First, we should probably document the size of the tabs
(currently 8 characters, at least from the one file I'm looking at).
Secondly, it would take a lot of effort to switch, but I think we should
at least consider a more compact indentation format. I'm personally a
fan of 4 spaces. But I think that the width of our indents is a
contributing factor to the immense lengths of lines in our code.
* Below is a histogram of line lengths in our .c files. I think 160
characters is sufficiently long that it won't be _too_ much of a chore
to shorten all of the super-long lines, but it's still short enough to
be feasible on most of today's monitors.
16:28:27> [xsdg{intercal}@~/files/compile/photos/gitqi/src]
$ruby -e 'lc = Hash.new{|h,k| h[k] = 0}; ARGV.each{|f|
File.new(f).each_line{|l| l.gsub!(/\t/, " "*8); lc[l.length/10] += 1}};
csum = 0; lc.sort.each{|(x,y)| csum += y; printf "%3d-%3d: %s %d\n",
10*x, 10*(x+1)-1, y.to_s.ljust(5), csum}' *.c
0- 9: 26174 26174
10- 19: 8520 34694
20- 29: 12967 47661
30- 39: 11622 59283
40- 49: 7885 67168
50- 59: 6237 73405
60- 69: 5867 79272
70- 79: 5349 84621
80- 89: 3516 88137
90- 99: 1951 90088
100-109: 1120 91208
110-119: 579 91787
120-129: 313 92100
130-139: 9392193
140-149: 4392236
150-159: 2192257
160-169: 2092277
170-179: 1892295
180-189: 2392318
190-199: 3692354
200-209: 5992413
210-219: 3992452
220-229: 5 92457
** an expanded version of the ruby one-liner above:
ruby -e 'counts = Hash.new{|h,k| h[k] = 0}; # default value of 0
ARGV.each{|fname|
File.new(fname).each_line{|line|
line.gsub!(/\t/, " "*8); # count a tab as 8 spaces
counts[line.length/10] += 1 # histogram with bucket size 10
}
};
csum = 0; # cumulative line counts
counts.sort.each{|(range, count)|
csum += count;
printf("%3d-%3d: %s %d\n",
10*range, 10*(range+1)-1, count.to_s.ljust(5), csum)
}' *.c
--xsdg
--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel
