Registration fails

[TaniaT]

Hello,

I'm aware of the fact that it's been quiet around here for the past year, but since the Linux version of OPUS is still available for download, I thought I'd give it a try.

It involved a lot of handwork, but I managed to manually install OPUS on my Ubuntu 16. However, the registration (using the data sent to me by email) fails, so after the 30-day trial I can't use the programme any more.

Any ideas what causes the problem and how to solve it?

Regards,
TT

[Andreas Mohr]

Hello,

sorry for the delay! (no active new-topic notify here)

Side notes:
I'm non-mildly (i.e., very...) astonished that you actually managed to get this OPUS package to work on Ubuntu 16 (this is a rather non-simple effort I would think, given many dependencies that will not properly match any more on this distribution, despite huge OPUS build efforts to reduce dependency impacts).
For this reason, I'm tempted to usually recommend (e.g. for non-expert users) using our existing OPUS package(s) in a virtual machine which sufficiently matches the older environment (this will likely be accompanied by security [update] issues, though).
(sorry for the sad state of affairs - I am definitely not overly happy either...)

I have encountered such a registration issue with other customers, too, which is why I have relatively recently added a paragraph to the (current) README:

Code: Select all

@@ -499,6 +499,34 @@ This data should either be entered in the program's registration dialog
 (menu Setup -> Register OPUS...) or stored as a pre-distributed file
 (prior to starting OPUS)
 at ~/.config/opus/emulated.reg.conf (i.e. below the user's home directory).
+
+
+### Registration troubleshooting ###
+
+If during registration attempts OPUS reports errors such as:
+* "Illegal Input, please check for correct typing or click on Cancel"
+* "The OPUS-Serial, the package serials, the library serials or the key
+   contain non-alphanumeric values or spaces. Please check and retry."
+then it's quite likely
+that you entered the officially granted registration values incorrectly.
+
+Reasons for denial / failure of registration attempts might be:
+* manually mis-typed content
+  (in general, ALWAYS definitely avoid
+  manual, error-prone re-typing of any already computer-delivered records -
+  always use reliable copy&paste methods, such as:
+  select-text-via-mouse --> Ctrl-C --> Ctrl-V keys)
+* extraneous/superfluous white space
+  (very precisely copy the supplied contents, and only those!)
+* inappropriate editing of item fields
+  which have been supplied as empty only (blank) in registration data
+  i.e. have not been supplied
+  (copy only those item fields
+  which do in fact contain valid values)
+
+
+## Login ##
+
 To successfully make it beyond the initial
 user login authentication prompt window (dialog title "OPUS Login"),
 one may need to use the initial password "OPUS".

It would be very useful if you could then report whether these instructions manage to solve the issue (otherwise I will have to try to refine/correct them).

Thank you!

[TaniaT]

Hi and thank you for your reply!

What can I say, I'm grateful to the internet for launchpad and to linux for multiarch Obviously, I will never be able to cleanly uninstall OPUS from my system, though. I can't say it works perfectly, but it's ok for basic tasks. The main thing I'm unhappy with is printing/exporting spectra.

Concerning the registration issues, I must admit you were right. I would have sworn that I had covered all possible combinations of including/removing blank characters, but apparently I hadn't. Anyway, now I have my OPUS back, which is great.

Thanks a lot and have a great weekend!

[Andreas Mohr]

I can't say it works perfectly, but it's ok for basic tasks. The main thing I'm unhappy with is printing/exporting spectra.

I sure as h*ll can't say either it works perfectly, unfortunately...
(considering that it is a relatively initial port of the somewhat strongly Windows-only application)
But anyway, we're trying hard to get things improved nicely in general, certainly.

The main thing I'm unhappy with is printing/exporting spectra.

I had spent an awful lot of time (months) trying to get printing adaptation compatibility sufficiently fatally precisely (centrally) working to ultimately be able to have at least some confidence that there's a a snowball's chance in h*ll that printing will work to a semi-successful extent even in thoroughly different Non-Windows environments, too - but for some reason color me totally non-surprised that there are difficulties --> sorry!
("printing" is "Attribute Hell" - there are perhaps some 50 to 100 different printer-specific attributes to be supported properly: paper sizes, resolution, stapling, dithering, output feed, orientation, scaling, page count, color/bw, ... - and you'll have to support all these on the "other" side, too...)

If you happen to be able to list some usefully specific areas where you experience printing issues, then perhaps I actually manage to pinpoint some issues and fix them or at least take a note.

Thank you very much for your report!

[TaniaT]

I'm glad you haven't abandoned the idea of a Linux version of OPUS!

Unfortunately I'm not familiar with printer handling, so I can't identify the problem(s). But here's a description:
As far as I can see, there are 3 ways to print.
File > Print...
Print > Print Spectra
and Print > Print...
The first and third case lead to what seems to be the same window, which includes options for printing on paper or in file (ps). It produces a badly rendered spectrum (one at a time) without axes and peak markings.
The second case offers output to printer, bitmap, clipboard and pdf. Unfortunately it doesn't produce any output at all.

Via Print > Analysis report I face the problem that it doesn't save anything without a template, while Print > Setup Analysis Report Template leads to OPUS exiting without a word.

Print > Quick Print sends a spectrum but with axes and peak markings – but sorry to say, horribly rendered – to one of the printers.

At this point I should mention that it has some Gtk related problems, according to the log:

Code: Select all

Gtk-Message: Failed to load module "overlay-scrollbar"
Gtk-Message: Failed to load module "gail"
Gtk-Message: Failed to load module "atk-bridge"
Gtk-Message: Failed to load module "unity-gtk-module"

(opus:4647): Gtk-WARNING **: Unable to locate theme engine in module_path: "murrine"

Wishlist:
What I would like it to do is to export (multiple) spectra including axes and ideally peak markings to a clean vector graphics file for further use.

As I said, I'm glad you're at least still interested in a Linux version.

[Andreas Mohr]

It produces a badly rendered spectrum (one at a time) without axes and peak markings.

Since axes and peak markings are somewhat separately handled, it is somewhat understandable
(and perhaps there are issues with font use, too, leading to peak markings not getting printed)

Via Print > Analysis report I face the problem that it doesn't save anything without a template

You are (likely) not talking about a bug here, right? But rather that there's no template file available?

while Print > Setup Analysis Report Template leads to OPUS exiting without a word.

Known issue (object lifetime issues, relatively hard to fix)

horribly rendered

Oh well. This might be caused by several areas (in layered order, not in order of likelihood):
- OPUS printing implementation weakness
- porting issue (scaling / printer attributes not properly precisely handled)
- existing printing weakness in wxWidgets base toolkit
- adaptation issues of this properly modern platform to the much older release package's components

I have taken a permanent note of your bug details, and I will try to reproduce behaviour of these areas once being able (build infrastructure issues...) to resume my build work on Linux.

clean vector graphics file

Ah, achieving properly vectorized content...

[TaniaT]

Via Print > Analysis report I face the problem that it doesn't save anything without a template

You are (likely) not talking about a bug here, right? But rather that there's no template file available?

No, I wasn't talking about a bug. Here are a couple of other bugs tho:

1. Spectrum Subtraction: The active spectrum appears as "Principal file", but the field "File(s) to subtract" is empty.
2. Interactive baseline correction: Window distorted (gtk related?) and all(?) actions lead to opus not responding.
3. Not exactly a bug: At the bottom of the Edit menu, I'm reading "–OLE verbs go here–"


BTW, I was prepared to live with bugs, but since you asked...

[TaniaT]

It's me again

I ought to start a new thread, but chances you'll read it are higher with this one.
So my question:

Is there an option for concave ruberband baseline correction in a macro? (Linux or Windows, doesn't matter really)

Cheers,
TT

[Andreas Mohr]

It's me again

I ought to start a new thread, but chances you'll read it are higher with this one.

Good

Indeed, given the currently not existing global activity notification.

So my question:

Is there an option for concave ruberband baseline correction in a macro? (Linux or Windows, doesn't matter really)

Given that this ought to be one of the "usual" OPUS functions (well, possibly except for being of the "interactive" type), macro-based execution of this function ought to be doable
(according to my colleague as well).

Raw implementation of the [concave rubberband] baseline function appears to be consulting parameters BME (base method flags, default: RUBBERBAND; SCATTERING 1, RUBBERBAND 2, CONCAVERUBBERBAND 3), BPO (base points, default: 64), BIO (iterations, default: 10), BCO (exclude CO2, default: FALSE),
IBI (the IBI string has the following structure: <nPoints>, <x1>, <y1>, <x2>, <y2>, ..., <xnPoints>, <xnPoints>, <fPoly> fPoly = 0: Straight lines, 1: Polynomes).

Apart from this info, usual variants (interpreter, .MTX, .OBS etc.) for OPUS macro execution ought to apply here.

HTH & HAND,

Andreas Mohr

[TaniaT]

Indeed, it works. I had tried setting BME 0 but not 3 for some reason (no reference of concave rubberband and IBI in the programming manual).

So for the zillionth time, thank you very much Andreas & colleague!