Mailinglist Archive: yast-devel (66 mails)

< Previous Next >
Re: [yast-devel] Ruby code in SCR

Hello,

On Jun 20 12:51 Klaus Kaempf wrote (excerpt):
* Johannes Meixner <jsmeix@xxxxxxx> [Jun 20. 2013 10:52]:

Regardless how it will be implemented, what you say is basically:

Even after YCP was replaced by Ruby in YaST, arbitrary
contributors cannot just do Ruby programming as usual
to contribute something to YaST.

Exactly. You still cannot use 'puts' or 'printf' to output a
string to the UI, you need UI-specific calls. And the backend
is no difference.

No programmer expects that 'puts' or 'printf' must work
to output a string to a graphical UI.

The UI calls in YaST provide the obvious advantage that the
programmer does not need to care about the details of the
actual UI that is used by the user (ncurses / Gtk / Qt).
I.e. one same code for all those UIs (by the way: this
is the only thing that I really like about YCP).

In contrast the YaST concept of a backend running on the
target system while the actual YaST program runs on another
system does not provide an obvious advantage for the programmer
because first of all it makes programming more complicated
because one cannot just do the usual calls to read from
and write to the system.


Where I agree with you, is the need to explain to contributors
the reason behind this decision.

Is there perhaps already documentation available so that
novice contributors would understand the reason behind?


Therefore I like to have it discussed here in advance if it is
possible to drop the whole idea behind SCR.

And replace it by what ?

I wrote "drop" because I meant "drop".


Ruby printf to write (arbitrarily complex) config files ?

All contributors are forced to use an artificial looking
abstraction layer in any case even for reading and writing
really simple stuff (that works everywhere except in YaST) ?


The idea behind SCR was to provide a simple API hiding the
complexity of config files from the programmer. I strongly
believe this idea is still valid.

This is another different idea behind SCR.
But this is not what I was talking about.

Generic calls to read and write config files would provide
an obvious advantage when the programmer does not need to care
about the details of his particular config files (as long as
the config file syntax is sufficiently simple that those
generic calls actually work correctly).

But I know that the SCR INI agent destroyed the cupsd.conf file
several times (the cupsd.conf syntax is not too complex)
during the time when the YaST printer module was made by
YaST developers.

Theoretically it is perhaps possible to use the SCR INI
agent to modify cupsd.conf but in practice the YaST
developers failed to do so.

This indicates that in practice there is no such thing as
"a simple API hiding the complexity of config files"
when the config file syntax becomes a bit complex.


Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany
HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups