December 2007 - YaST Development - openSUSE Mailing Lists

[yast-devel] New YCP module: Icon
by Lukas Ocilka 06 Dec '07

06 Dec '07

Hi, I've just finished a short introduction of new YCP Module "Icon" in the openSUSE wiki: http://en.opensuse.org/YaST/Development/Modules/Icon This new YCP module simplifies using icons in your dialogs. By now it only supports 32x32 icons but could be extended if needed. "Icon" YCP module can be found in yast2-2.16.16 and later. Dialogs, especially pop-ups should use icons to emphasize the message to a user. Moreover it's better to use unified icons for the same tasks (one icon for warnings, another one for errors, ...). This is how Icon module deals with it: Icon::Simple ("warning") -> returns UI term Icon::Simple ("error") -> returns UI term Bye Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic

5 9

[yast-devel] RPM Dependencies in General (...and How to Fix Them)
by Lukas Ocilka 05 Dec '07

05 Dec '07

Dear developers, ==About== Most of you have probably already ran into problems with binary-incompatible YCP modules after updating to newer yast2-core. It happens when new core is changed internally and it's caused by wrong RPM dependencies in yast2-* packages. ==Solution in yast2.rpm== Only yast2.rpm contained Requires: yast2-core but even that definition hadn't been enough. By now, yast2.spec.in contains: Requires: yast2-core >= %(echo `rpm -q --queryformat '%{VERSION}' yast2-core`) (suggested by Coolo) ==Solution for All YaST RPMs== Nowadays, all (?) YaST packages require yast2.rpm but only some of them define a version they rely on. To fix the problem with binary-incompatibility, we could adjust all YaST RPMs to either Require the last yast2-core.rpm (or Conflict older than the current one) or Require the last yast2.rpm Hard to say what is better: /sbin/yast2 is owned by yast2-rpm (how we usually start a YaST module) /usr/lib/YaST2/bin/y2base is owned by yast2-core Side note: This does not affect YaST RPMs that don't contain any YCP modules (YCP scripts are compiled on the fly -- no binary incompatibility). ==Conclusion== I'd vote for requiring the last (and newer) yast2.rpm bu I'd like to hear from you what do *you* think of that. Please, let me know. Thx && Bye Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic

4 7

[yast-devel] typedef
by Benji Weber 04 Dec '07

04 Dec '07

Greetings all, Today I discovered the "typedef" keyword in the ycp langauge. I'd not realised this existed because I hadn't seen it in any documentation, or used in modules. It seems it's very occasionally used. Is there any reason for this? It seems to provide a mechanism to avoid having to deal with lists of maps of lists all over the place. The typedefs can't be imported out of a module, but one can work around this by "including imports". See example. // Test.ycp { include "Car.ycp"; include "CarBrand.ycp"; Car car = Car::newInstance(); y2milestone("New car speed is %1",Car::getSpeed(car)); Car::setSpeed(car,100); y2milestone("Now car speed is %1",Car::getSpeed(car)); y2milestone("This car is a %1",Car::getBrand(car)); Car audi = Car::newBranded(CarBrand::AUDI); y2milestone("This car is a %1",Car::getBrand(audi)); } // output 2007-12-03 18:00:06 <1> padd(5080) [YCP] yast/Test.ycp:6 New car speed is 0 2007-12-03 18:00:06 <1> padd(5080) [YCP] yast/Test.ycp:8 Now car speed is 100 2007-12-03 18:00:06 <1> padd(5080) [YCP] yast/Test.ycp:10 This car is a `FORD 2007-12-03 18:00:06 <1> padd(5080) [YCP] yast/Test.ycp:12 This car is a `AUDI // modules/car.ycp { module "Car"; include "CarBrand.ycp"; include "Car.ycp"; global Car newInstance() { Car car = $[ "speed":0, "brand":CarBrand::FORD, "colour":"red" ]; return car; } global Car newBranded(CarBrand brand) { Car car = $[ "speed":0, "brand":brand, "colour":"red" ]; return car; } global void setSpeed(Car & instance, integer speed) { instance["speed"] = speed; } global integer getSpeed(Car & instance) { return instance["speed"]:0; } global CarBrand getBrand(Car & instance) { return (CarBrand)instance["brand"]:nil; } } // include/Car.ycp { import "Car"; typedef map<string,any> Car; } // modules/CarBrand.ycp { module "CarBrand"; include "CarBrand.ycp"; global CarBrand FORD = `FORD; global CarBrand BMW = `BMW; global CarBrand AUDI = `AUDI; } // include/CarBrand.ycp { import "CarBrand"; typedef symbol CarBrand; } -- Benjamin Weber -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

2 4

[yast-devel] dynamic SCR
by J. Daniel Schmidt 04 Dec '07

04 Dec '07

Hi YaSTies, I'm looking for a nice solution to the following problem: I have to read and write simple ini files from a module, but I can not use SCR with an ini-agent, because the names and locations of the config files are not fixed. They are created on request and and have dynamic names. Even the number is variable. Yes, each config has to go to a separate file. Is there a nice solution to this other than to let my module create a new agent if I need a new one?? In the worst case I have to parse the files in ycp - but I'd prefer a more elegant solution. Thanks for any hint. Ciao, Daniel -- J. Daniel Schmidt <jdsn(a)suse.de> SUSE Linux Products GmbH Research & Development Maxfeldstr. 5 GF: Markus Rex, HRB 16746 (AG Nürnberg) D-90409 Nürnberg -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

2 2

[yast-devel] Czech YaST2 team (Prague) meeting 2007-11-21
by Jiří Suchomel 03 Dec '07

03 Dec '07

Czech YaST2 team (Prague) meeting 2007-11-21 ============================================ Present: dfiser, jkupec, jsuchome, juhliarik, kmachalkova, locilka, mvidner, mzugec Absent: jsrain Minutes: jsuchome Next Minutes: juhliarik libzypp/zypper jkupec, jsrain and mvidner attended zypp meeting in NBG - minutes to be found on zypp-devel. jkupec refactors zypper's code in order to make it better maintainable and extendable Mod-UI Mod-UI branch was merged into trunk, check your code a presence of obsolete widgets (read http://svn.opensuse.org/viewcvs/yast/branches/tmp/sh/mod-ui/core/libyui/src…) Docu YaST documentation moved to the external SVN: http://lists.opensuse.org/yast-devel/2007-11/msg00073.html Pkg:: Fixed desctructor, so zypp tmp files are correctly removed. Installation proposal now contains the download sum from all ftp and http repositories (#331538). -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome(a)suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0