Dne 16.12.2010 20:13, Ulf-D. Ehlert napsal(a):
> Miroslav Šulc (Wednesday, 15. December 2010)
>> i have 10 patches in my local git repo now fixing various problems,
>> and now even in the proper format. i just did not want to spam
>> bugzilla more.
> Bugreports and bugfixes are obviously not spam. If you report bugs via
> bugzilla you make sure that we don't forget them. :-)
well, i hope you will not regret what you wrote :-P anyway, it's little
bit discouraging to see no reaction for the bugs at bugzilla but i guess
the docs team is busy with other things (like real life, christmas, end
of year related work etc). it's understandable as this is just volunteer
work, i just like to see things moving forward :-)
>>>> 3) there are some inconsistencies in capitalization of chapter
>>> I'm not sure, too. It seems that most documentors prefer
>>> BTW: What do the official rules say?
>> nothing as far as i can remember. but generally, chapter topic in
>> english should use capitalization except words like "the", "of"
>> etc. at least that is what i was taught at school long time ago.
>> about image titles, i am not sure whether they should be
>> considered as titles (so capitalized) or just as labels without
> If I remember correctly I had learned the same rule at school (also
> long time ago), but meanwhile I think it depends on the weather, on
> the day of the week, or on some random number...
yes, it looks that way when reading the documentation, each part was
written under different circumstances :-P in my opinion, all titles
should be capitalized, but label of images should not. i know this is
just style issue, it does not affect the quality of the content, but the
documentation would definitely look more professional with these things
fixed. in fact the documentation is really cool, but things like
duplicated words and these style issues are little bit distracting (to me).
>> well, i do not have account on git.gnome.org yet. and they say i
>> should create one only if somebody tells me it's a good idea to do
>> so :-)
>> also, i spent some time today on reading how git works exactly so
>> as i wrote above, i have the patches in the format-patch format
>> now too. i just don't know what to do with them, did not want to
>> create extra spam on bugzilla.
> Using bugzilla and creating patches with "git format-patch" is a good
> way to start.
well, as i think of it, the best way would be to create the patches on
gimp-help-2-6-0 branch (to fix current documentation) and then merge
them to master branch and update them to the changes in master branch
(to have the fixes at the latest changes too), but that would produce
even more work (now i have 10 patches and it's sure not final number)
and (afaik) i cannot do patches for merges so someone from the docs team
would have to spend his/her time on this.
also, i noticed that some changes in gimp-help-2-6-0 branch were not
merged into master branch which might complicate the merge little bit.
at least 'git log remotes/origin/master..remotes/origin/gimp-help-2-6-0'
shows some commits. though when looking at it more deeply, it seems some
changes from release reported as not merged are in master anyway, so
maybe they were done as different commits (which is not in my opinion
correct, they should be merged from the instead, this way it creates
little mess with the merges).
anyway, in my opinion my fixes should go both to gimp-help-2-6-0 and to
master, which means i should redo the patches for gimp-help-2-6-0 and
then someone with push rights should merge the commits to master (so the
list of unmerged commits from branch to master does not grow) and master
should be then scanned for the issues and fixed too in case some things
that the patches fix would be still left there (due to changes in
master). what is your opinion? and if you'd agree with this approach,
how will we do that? looks like it will take some time when several
people working on it. i just don't like wasting time, whether it is my
time or time of somebody else :-)
>>>> i was not able to make sample points
>>> It works: Ctrl-click on a ruler, hold the mouse button pressed,
>>> and move the pointer to the image.
>> well, just tried with latest 2.7 and does not work, neither with
>> mouse (that even does not catch click, weird) nor with stylus. in
>> fact i am not even able to put guide on ruler that way. i must
>> have something wrong in setup then.
> But your mouse works, so that you can, for example, create selections
> using the mouse?
well, to be exact, i have laptop with synaptics touchpad and wacom
tablet. as tablet gestures work weird in linux (they are not usable), i
have touch features of table disabled, but still, there is some issue
with loading synaptics driver for my touchpad as since i plugged the
tablet, some advanced features of the touchpad (like scrolling) do not
work and i did not have time to fix this yet.
anyway, clicking with mouse works everywhere except the image window it
seems (clicking into image window does not work, but clicking on menu in
image window works, so it looks like window manager can handle the
clicks but gimp cannot). so i can't paint with touchpad (nor trigger
context menu in image window) but i can paint with stylus. but even with
stylus i can't place guides nor create sample points.
also, i have one more question. i noticed that in some cases dialog
fields are not marked with tags so they appear in documentation as
regular text. i guess all references to dialog fields should be marked
with tags, am i correct?
Gimp-docs mailing list