[k3b] [Bug 382754] K3b complains about missing cdrskin at start up

[Thomas Schmitt]

https://bugs.kde.org/show_bug.cgi?id=382754

--- Comment #20 from Thomas Schmitt <scdbackup at gmx.net> ---
Hi,

Leslie Zhai wrote:
> it needs more detailed feature checker for cdrecord, growisofs, cdrdao
> and other K3bConcreteWriter.
> [...]
> it is better to provide detailed checkSystem at startup, so users might
> install missing packages if desire some features, thoughts?

If i may think big, then i imagine two checks: One at program start to
verify that a roughly sufficient set of burn backends is available.
The second check would be made late when all needs of the K3B task
are determined. It could choose a burn program which matches those needs.

Refining my rough struct sketch, i would create a class that represents
the program capabilities and the task needs. Probably with an array and
named indice instead of single "does_some_thing" integers.

  #define DOES_NEEDS_BYTES        2

  #define DOES_NEEDS_CD_DATA      0
  ...
  #define DOES_NEEDS_FAST_BDRE   11

  unint_8 capabilities_or_needs[DOES_NEEDS_BYTES];

A capability (e.g. DOES_NEEDS_FAST_BDRE) would be marked by value 1 in 

  (capabilities_or_needs[DOES_NEEDS_FAST_BDRE / 8] 
   >> (DOES_NEEDS_FAST_BDRE % 8)) & 1

Both the drive examinations and the task preparation would fill out
such class instances.
The arrays of capabilities_or_needs[] would be compared by logical AND
operations. If the result is the same as the needs array, then the program
is fully suitable for the task.
If the result has less bits than the needs array, then some capabilities
are missing. In this case another burn program would have to be chosen,
or the task would have to be refused (with hints how to get it doable).


Above bit array would work well if all capabilities are yes/no decisions.
If we expect to get more possible values for a single capability, then
one should rather use a byte or integer array:

  #define DOES_NEEDS_BYTES       12
  #define DOES_NEEDS_CD_DATA      0
  ...
  #define DOES_NEEDS_FAST_BDRE   11
  unint_8 capabilities_or_needs[DOES_NEEDS_BYTES];

Here the macros are not but indice but rather byte indice:

  capabilities_or_needs[DOES_NEEDS_FAST_BDRE]

Comparison would not be done by AND but rather by "==" comparison of the
single array bytes.


The DOES_NEEDS class would then become a member of a BURN_PROG_ASSESS
class which contains the rest of information from my sketched
struct burn_candidate: name, permission_problem, ...

The early burn program assessment would fill out BURN_PROG_ASSESS class
instances and record them for use with the later check for task needs.
It would already warn if some generally important capabilities are not
covered by the detected burn programs.

The K3B task preparation would fill out a DOES_NEEDS instance and submit
it for comparison with those registered BURN_PROG_ASSESS instances, which
have no fatal problems.
This comparison would yield a list of suitable BURN_PROG_ASSESS instances
among which K3B or its user may chose for that particular task.

------------------------------------------------------------------------

But before working on that big structural change, i would first roughly
fix the check for cdrecord and cdrskin, so that they are considered
as alternatives for the main use cases of audio and data burn runs.

Further i would examine the report that cdrskin is not used when it should.
As Wolfgang Bauer wrote:
> cdrecord is actually *mandatory* and cdrskin is not even used if it's
> installed, contrary to the message.

And this bug report should be made open again. Currently it says
"Status: RESOLVED FIXED" which seems not to be true yet.


Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are the assignee for the bug.