I am primarily interested in doing more "big" rewrites, but I am willing
to do small changes as well. I may be able to take on projects of
greater magnitude, but I can't commit to do so categorically at this
point, meaning that I'll have to evaluate such projects going forward to
determine if they will fit into my schedule.
> You'll get mail for any new documentation bugs --
> that'll usually be small stuff, like a mistake that
> needs fixing.
If I see something minor that I want to fix, what procedure do I follow?
Do I just make the fix and then post a patch on buzilla?
> There's some more general stuff that needs doing here:
> http://live.gnome.org/DocumentationProject/Tasks
> but I'm not sure about some of the things listed there
> -- eg, what's happening with the gparted
> documentation? We've not heard from them in ages.
I plan to continue working on docs for gnome-games, but I'd like to do
other things as well to get some variety.
> * Kill the version number in the manual title -- just
> remove ' V&manrevision;' from the <title> tag (this is
> something nearly all older docs suffer from by the
> way)
> * I agree with whoever said we don't need the
> screenshot of the main window.
> * Furthermore, in 2.14 the look of ataxx has been
> radically improved (ie it's no longer impossibly
> dark!), so the one showing the possible moves needs to
> be redone.
> * I'd remove the preferences screenshot too, as I
> don't think it adds anything. The user can easily see
> the real thing for himself.
> * Nitpick zone: the application tag is used in the
> overall manual title but not in the subheadings, eg
> '<title>Customizing Ataxx</title>'. However, I'm not
> sure which way round is correct, as I've seen a bit of
> both in our docs. Shaun, any thoughts on this? My gut
> feeling is that the title is already emphasized (then
> again, I'm not sure why the name of an app needs to be
> italicized throughout anyway)
I can do those fixes if you haven't done them already.
>
> I'm happy to make these final tweaks myself and then
> commit :) -- though I'd appreciate someone supplying
> me with the scrneenshot of the possible moves. Perhaps
> this is a good time to use cropping and fading as
> discussed here:
> http://bugzilla.gnome.org/show_bug.cgi?id=348495
I can do the screenshots, including the cropping/fading. Are there
specific GTK/Metacity themes that I should use?
If there is sufficient interest, I am also willing to make a utility to
help automate the screenshot/crop/fade process. Last year I was writing
articles with lots of screenshots, and I started to get really
frustrated with the limitations of the GNOME screenshot utility. I
eventually made my own with Ruby and Glade. It does a lot of things that
the GNOME screenshot utility doesn't do. For instance, it can capture a
specific window or a specified screen region. It probably wouldn't be
that difficult to extend my utility so that it can optionally perform
the border fade operation. If enough doc writers are interested in using
something like that, I am willing to rewrite it in Python so that people
don't have to wrestle with the Ruby GNOME dependencies.
--
Ryan Paul <gae...@gmail.com>
_______________________________________________
gnome-doc-list mailing list
gnome-d...@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-doc-list
On Sun, 2006-07-30 at 12:56 -0700, Ryan Paul wrote:
<snip>
>
> I am primarily interested in doing more "big" rewrites, but I am willing
> to do small changes as well. I may be able to take on projects of
> greater magnitude, but I can't commit to do so categorically at this
> point, meaning that I'll have to evaluate such projects going forward to
> determine if they will fit into my schedule.
There are plenty of docs in need of some lovin'. I'll just take the
opportunity to suggest the gnome accessibility guide. There are plenty
of tasks in it and it needs a huge revamp. I started working on it last
cycle, but didn't get very far due to other commitments and such.
<snip>
> I can do the screenshots, including the cropping/fading. Are there
> specific GTK/Metacity themes that I should use?
I believe the preferred theme is the default (Clearlooks) theme.
>
> If there is sufficient interest, I am also willing to make a utility to
> help automate the screenshot/crop/fade process. Last year I was writing
> articles with lots of screenshots, and I started to get really
> frustrated with the limitations of the GNOME screenshot utility. I
> eventually made my own with Ruby and Glade. It does a lot of things that
> the GNOME screenshot utility doesn't do. For instance, it can capture a
> specific window or a specified screen region. It probably wouldn't be
> that difficult to extend my utility so that it can optionally perform
> the border fade operation. If enough doc writers are interested in using
> something like that, I am willing to rewrite it in Python so that people
> don't have to wrestle with the Ruby GNOME dependencies.
The screenshot utility does support only a single window (through
<alt>-PrintScreen). Although, a tool to automagically make screenshots
help-worthy might be pretty cool. Any tool that makes the doc writers
lives easier would probably be welcomed ;)
Don
> On Fri, 2006-07-28 at 08:50 +0100, Joachim Noreiko
> wrote:
> If I see something minor that I want to fix, what
> procedure do I follow?
> Do I just make the fix and then post a patch on
> buzilla?
That would be super.
> > * Kill the version number in the manual title
> > <etc etc -- snip>
>
> I can do those fixes if you haven't done them
> already.
Done, and committed to CVS.
And your rewrite of the gataxx manual is now in GNOME
:)
> I can do the screenshots, including the
> cropping/fading. Are there
> specific GTK/Metacity themes that I should use?
The GNOME default, which is Clearlooks.
Just post it to this list.
> If there is sufficient interest, I am also willing
> to make a utility to
> help automate the screenshot/crop/fade process.
> ...
> It
> probably wouldn't be
> that difficult to extend my utility so that it can
> optionally perform
> the border fade operation.
That could be very useful.
Though for the border fading feature I would wait and
see what Shaun has to say about whether it is
feasible/desirable to have yelp automatically do
border fading.
Joachim
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
> That could be very useful.
> Though for the border fading feature I would wait
> and
> see what Shaun has to say about whether it is
> feasible/desirable to have yelp automatically do
> border fading.
As I saw it, there would be two advantages to doing it
in yelp: it ensures consistency, and it's less work
for the person creating the image.
I've just spoken to Shaun on IRC who says it would be
tricky in yelp -- and your tool would address both of
these issues too. So if it's something you think you
can do, go for it :)