Drafting "Tender for implementing support for a dedicated, built-in UNO object,inspection tool (Xray-built-in debugger)"

Hi Lothar,

a) (Completeness of the specification) Isn't it appropriate to assign the right Version of LibO and the UNO API to it, at least what is the version
(or with what LibO Version delivered) the "WatchCode"-Implementation should be used for the UI work? Which version of the XRAY and MRI tool is here
relevant, at least say "the latest" with a hint for a source for them.

I think the idea is that the work is developed on LibreOffice master, so
it gets released in the next major version after the work is done. This
is how all previous tenders were delivered. The result is part of
LibreOffice itself, so specifying a LibreOffice version adds no value.

XRAY and MRI are just examples of what's possible for an inspection
tool, so I would consider their version as not relevant.

b) (Feature request) I miss this great feature to have a code autocompletion, for example in VS you can set the "." as referenciator and that get the
possible services or DOM Tree alternatives or... and also complete the parameter part when hitting return (or is this meant with the Copy & Paste feature?)

My understanding is that we currently provide no good autocompletion
APIs, and such an inspection tool would build on top of it. If you add
autocompletion to the scope, it can easily double the amount of needed
work, so I would carefully avoid that.

c) (Completeness of the specification) It is mentioned, that "everywhere where possible" to lean on automatic testing. Well, to be honest, this is a
huge field. Shouldn't we specify this a little bit more in detail, what we do expect here? Are there automatic test tools we are already using which
we want to see or for which we want to have the automation scripts or ...?

I believe the current wording was used for previous tenders already,
without problems. The idea is that whenever a sub-task is done
(something gets fixed or implemented), it should be considered to add a
test for it. It's hard to specify this more than this: if you add
quantity requirements, then it's easy to add a lot of useless tests, and
it's not easy to measure test quality with numbers. :slight_smile:

I would prefer a reasonable amount of good tests, rather than a lot of
useless tests. The effort needed to add tests is also different for each
& every case: sometimes it's a shame that a test is not added, sometimes
it would be a heroic effort to cover some behavior with an automated
test.

d) (Details in the proposal) I would also expect a detailed estimation in the sense that it is not just a figure but at least one for each mentioned
feature in the mandatory as well as in the optional part. If they are proposing other features (not mentioned here) they should do it as well with a
figure for it. Is it mentioned anywhere?

It is possible it's hard to compare proposals if the proposals have
optional features. One consistent way is to asssume you order / not
order everything optional. I imagine if the proposal is detailed enough,
there is a brief description of each sub-task, how it would be done --
then you can get the impression at the end that the bidder did their
homework, and the number at the bottom of the offer is not just a
ball-park.

Regards,

Miklos

Hi,

Miklos Vajna wrote:

I think the idea is that the work is developed on LibreOffice master, so
it gets released in the next major version after the work is done. This

I've added a note to clarify that:

  "The work has to be developed on LibreOffice master, so it can get released in the next major version."

It is possible it's hard to compare proposals if the proposals have
optional features. One consistent way is to asssume you order / not
order everything optional. I imagine if the proposal is detailed enough,
there is a brief description of each sub-task, how it would be done --
then you can get the impression at the end that the bidder did their
homework, and the number at the bottom of the offer is not just a
ball-park.

I was thinking of that while publishing the first draft, but now added this:

  "Bidders are free to bid on the required features only. Bidders who bid on both the required and optional features are required to provide a breakdown in terms of costs for both."

Florian

Hello,

I've just published an updated tender draft, based on feedback I received.

One question raised is wrt. navigator overlapping with parts of the tender. Answers and insight to that highly appreciated!

I'd like to collect further feedback on this tender this week, and if there is nothing controversial, move to publication afterwards.

Thanks,
Florian

Hi Florian, all,

I'd like to collect further feedback on this tender this week, and if there
is nothing controversial, move to publication afterwards.

I wonder if it would make sense to link this old talk of mine in the tender or
supporting material, as it provides code hints to some core components that
might be helpful for this:

https://www.youtube.com/watch?v=WBNG6bVZPzw

Best,

Bjoern

Hi Florian,

One question raised is wrt. navigator overlapping with parts of the tender.
Answers and insight to that highly appreciated!

My understanding is that the navigator is created for end-users, while
this inspection tool would be created for consumers of the UNO API
(macro authors, extension developers, etc). So indeed there is some
overlap, but the two tools would rather complement each other than
duplicate functionality.

Regards,

Miklos

Seconded. The Navigator is to reach (and partially) to manipulate the instantiated objects in a concrete document, this inspection tool is far more for development purposes and also about the DOM itself, not just the instances in a concrete document.

ATB
Lothar

Am 23.07.2020 um 09:09 schrieb Miklos Vajna:

Hi Florian,

On Wed, Jul 22, 2020 at 04:58:40PM +0200, Florian Effenberger [<floeff@documentfoundation.org>](mailto:floeff@documentfoundation.org) wrote:

One question raised is wrt. navigator overlapping with parts of the tender.
Answers and insight to that highly appreciated!

My understanding is that the navigator is created for end-users, while
this inspection tool would be created for consumers of the UNO API
(macro authors, extension developers, etc). So indeed there is some
overlap, but the two tools would rather complement each other than
duplicate functionality.

Regards,

Miklos

Hello,

thanks a lot for the valuable feedback, everyone! I've just made an updated document.

I'd like to finalize this until tomorrow, and then send to the board for approval.

Happy for any feedback and change proposals you have, will try to incorporate everything I receive by tomorrow.

Florian