So,
Lets examine a few possibilities:
On Wed, 2006-10-25 at 09:20 -0400, G. Roderick Singleton wrote:
> > > A quick question. Why is the quickstarter enabler kept in a config
> > > directory outside of the user's OOo stuff.
perhaps I just made up a totally random place to put it ? ;-)
> > I suppose that's because this is really about desktop integration: The
> > desktop probably checks this location for things to, well, quickstart.
> > Just a guess.
Seems like some pretty inspired guess-work from Frank :-)
> Can someone confirm or direct me to some spec that will explain
> whether this is *NIX specific, WM specific (e.g. Gnome vs. KDE vs. ...)
> or mimics Windows integration?
It mimics Windows integration almost exactly in fact - there we create
a <foo> file in the magic directory that is checked for auto-started
apps on Win32 login - it is almost identical, and shares most of the
same code.
As for the spec. my 1st google: for config/autostart hits the XDG list,
I browse to that web site, and - there is a list of standards:
http://freedesktop.org/wiki/Standards
and here:
http://standards.freedesktop.org/autostart-spec/autostart-spec-0.5.html
is the [draft] spec. How well we conform may vary, inasmuch that the
spec. was still being written when I did the work & is not final etc.
but at least we overlap enough that it works :-) Interestingly the xdg
standards process is by no means rigorous, often they remain
'unfinished' for-ever once implemented. However, they tend to be
extraordinarily useful, standardising simple / common / 'obvious'
things.
> G.R.S wrote:
> > Frank wrote:
> > ROTFL.
> > You know that this thread started because there *is* no spec for
> > this Unix port of the existing feature, don't you?
>
> No I did not. A spec would be useful for my purposes but I think
> that a simple explanation would suffice for the doc project. At
> least that way we could offer users some idea how to cope with
> the new feature.
I'm well up for a simple explanation.
> Frank wrote:
> The existing Windows version of the quickstarter is covered by
> http://specs.openoffice.org/appwide/menus/desktop_menu_integration.sxw,
> reachable from http://specs.openoffice.org/.
Strange, I read this list of specs the other day to try and find which
one related to this, and I didn't find it at all; I looked at several
other specs, but ...
However - reading the win32 spec - it -seems- that the specification
for this feature is almost totally absent involving the immortal lines:
"...is kept unchanged to the implementation used in OOo 1.1".
There is a screenshot, but no technical detail - particularly of the
kind that mentions where links are created etc.
Before I say this, I must point out the typical circular answer to the
sort of analysis that follows, I predict the self stultifying argument
will go like this:
Step 1: Meeks: "you did all this paper work that is now broken"
=> the process is mostly useless but for creating waste
Sumone: "then we must do more paperwork, and introduce more
process to ensure it stays up to date"
... symptom fixing ... "look no symptoms !"
... delay of some months ...
Meeks: "the paper work is broken again"
... goto Step 1: ad Nauseum ...
Anyhow:
**If** I was a spec enthusiast, and I thought that *any* of this was
worth fixing, I would point out that the quality of this spec is not so
good.
* Bugs in the spec.
* The quality of English is not uniformly clear
* The document is incomplete and unfinished:
+ the OO.o icons column for example being empty
+ are the icons themselves out of date too ?
+ there is a huge table duplicating strings found in
the application itself that is rather likely to have
at least minor errors.
+ more recent file formats are omitted
+ critical Unix integration information eg. associated
mime type names are omitted.
+ the screenshots are out of date - many things (not
least the icons) have changed since
* The spec. has broken links:
"Note: Please find a detailed and complete list (different sized and
high contrast version) of the new
http://so-doc.germany.sun.com/Teams/StarOffice_Applications/Extras/Icons/Application_icons_SO8/OOo20_all-icons.html
icons for OpenOffice.org here and a separate
http://staroffice-doc.germany.sun.com/Teams/StarOffice_Applications/Extras/Icons/Application_icons_SO8/so8final_all-icons.html
list of icons for StarOffice / StarSuite here."
+ to internal web sites inaccessible outside Sun,
(are they even still there - be interesting to know)
And all this from 5 minutes of review, need I go on ?
* Points:
Basically, everything that you can (as a programmer) -easily- predict
will go wrong with duplicating state all over the place has gone wrong,
and more besides.
Perhaps it is necessary to have a (brief) specification for this
desktop integration, but the process should not:
* include screenshots
+ they are -really- hard to maintain (I'm sure the help
guys would back this assertion up)
* include duplicated icons / UI strings
+ duplicating things is really bad, you multiply the
number of necessary updates when you change anything
and eventually achieve either paralysis or
inconsistency
+ yes -someone- needs to verify the correct icons got
associated with the right file types, but this can be
done by the art team, who created the icons, with a
suitable set of test files from the test suite.
* include 19 pages, 7 screenshots & a 6 person iTeam
* have a screenshot of 2 versions of the Win32 Office layout,
is it really necessary to have this much detail ? even the
text seems to suggest it's a bit pointless.
* Why does it matter that it's broken ?
The rational I hear for the spec. process is basically one of
oppression by methodology: people cannot be trusted to infer what a
feature should actually do - therefore it is vital to specify it in
minute detail. Thus - (it is implied) that by reading the spec. you can
tell if a problem is a bug in the software (where it doesn't conform) or
a 'feature' (where it does).
The problem with this is of course, that clearly the bug could instead
be in the spec. - it is by no means given that the spec. is perfect.
Hence even more thought (and worse) work is required to deduce [ from 2
sources ] whether the spec. is borked, or is it the implementation ? or
the test ? or the design ? or ...
So - having agreed that the spec. is likely to be buggy too - we have
that final mythical consumer "Posterity" - is she going to enjoy reading
bit-rotted specs ? I suspect she'd be more happy if the process time was
instead spent fixing some of the bugs she falls over :-)
* Summary
We should write code that is efficient, minimal, maintainable and not
over-engineered, and we should create processes that are efficient,
minimal, maintainable and not over-engineered.
AFAICS the spec. process is not maintainable, is not efficient and is
applied in cases where it is not necessary, and we can produce a far
better one: one that makes all the stakeholders happy - QA, UI, Help,
Engineering, external developers etc. Of course, that will require a
little thought, effort, compromise - but I think if we invest the same
amount of time more sensibly - eg. in peer code review, or programmers
writing more unit tests themselves we can achieve better overall
quality.
HTH,
Michael.
PS. to avoid symptom-fixing making the links somewhat inaccurate, I
cloned the spec. to (warning bad mime-type handling ;-):
http://go-oo.org/~michael/desktop_menu_integration.sxw
--
[EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
