October 2011 - YaST Development - openSUSE Mailing Lists

[yast-devel] RFC: fix for displaying bidirectional texts (e.g. mixed ASCII + Arabic)
by Ladislav Slezak 31 Oct '11

31 Oct '11

Hi all, I'm fixing bug https://bugzilla.novell.com/show_bug.cgi?id=583209 the problem is with displaying a bidirectional text. The dialog label contains Arabic traslation of "Joystick Configuration" which is written right-to-left (RTL) plus normal ASCII text with sound card model (written in LTR direction): sformat(_("Joystick Configuration - %1 (snd-card-%2)"), cardname, card_id); The problem is when the text is rendered on the screen the brackets are broken. See the attached screen shots (there is English and Arabic version, the last screenshot is fixed Arabic). It's caused by the fact that punctuation characters in bidirectional text are "weak". I.e. their direction depends on the direction of the surrounding text and that can cause troubles when one side is LTR and the other one is RTL. (See http://en.wikipedia.org/wiki/Bi-directional_text#Unicode_support) Fortunately Unicode has special controlling characters to explicitly set direction for one or more characters. To fix the problem with the string above I have added new String::ForceLTRPunctuation() function which forces LTR direction on some punctuation characters (,.()-) in the string using "LEFT-TO-RIGHT MARK" Unicode controlling character. See the result in the last attached screenshot. Another solution would be to directly fix the Arabic translation so it contains the LTR mark in it. But I'm not sure if it is possible to put binary values into translated pot file via some escape sequence... And some strings might be read from an external source and might not be marked for translation, so we need to fix them on the fly with the above function anyway... Because I'm not an I18N expert I'm asking here for review of this fix. I think the fix cannot be applied generally to any displayed text, sometimes the default direction might be desired and this would break it. The patch is attached for review. -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak(a)suse.com SUSE

2 2

[yast-devel] Branching openSUSE 12.1
by Lukas Ocilka 26 Oct '11

26 Oct '11

Hi, As you probably know AKA if I got it right ;) openSUSE 12.1 has been branched in the buildservice. Would it make sense to branch YaST SVN as well? And if not, then when? Bye Lukas -- Lukas Ocilka, Appliances Department SUSE LINUX s.r.o., Praha -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

3 2

[yast-devel] Re: [yast-commit] r66531 - /trunk/autoinstallation/doc/ENV-ay
by Lukas Ocilka 26 Oct '11

26 Oct '11

On 10/24/2011 10:34 AM, keichwa(a)svn2.opensuse.org wrote: > Author: keichwa > Date: Mon Oct 24 10:34:50 2011 > New Revision: 66531 > > URL: http://svn.opensuse.org/viewcvs/yast?rev=66531&view=rev > Log: > for building with daps > > Added: > trunk/autoinstallation/doc/ENV-ay > ... > +MAIN="ay_bigfile_docbook.xml" > +ROOTID="" > +PROFOS="sles" > +PROFARCH="ipf;x86;amd64;em64t;s390;zseries;ipseries" > +DISTVER="11 SP2" > +HTMLROOT="sles11" I'm afraid that trunk is now for SLE 12, not SLE 11. Was that intended? Lukas -- Lukas Ocilka, Appliances Department SUSE LINUX s.r.o., Praha -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

2 2

[yast-devel] Re: [yast-commit] r66507 - in /branches/SuSE-Code-11-SP2-Branch/slide-show/SLED/po: ar.po cs.po de.po en_GB.po en_US.po es.po fr.po hu.po it.po ja.po ko.po nl.po pl.po pt_BR.po ru.po sv.po zh_CN.po zh_TW.po
by Lukas Ocilka 26 Oct '11

26 Oct '11

On 10/20/2011 03:25 PM, keichwa(a)svn2.opensuse.org wrote: > Author: keichwa > Date: Thu Oct 20 15:25:44 2011 > New Revision: 66507 > > URL: http://svn.opensuse.org/viewcvs/yast?rev=66507&view=rev > Log: > update > > Modified: > branches/SuSE-Code-11-SP2-Branch/slide-show/SLED/po/ar.po > branches/SuSE-Code-11-SP2-Branch/slide-show/SLED/po/cs.po > branches/SuSE-Code-11-SP2-Branch/slide-show/SLED/po/de.po > branches/SuSE-Code-11-SP2-Branch/slide-show/SLED/po/en_GB.po > branches/SuSE-Code-11-SP2-Branch/slide-show/SLED/po/en_US.po > branches/SuSE-Code-11-SP2-Branch/slide-show/SLED/po/es.po > branches/SuSE-Code-11-SP2-Branch/slide-show/SLED/po/fr.po > branches/SuSE-Code-11-SP2-Branch/slide-show/SLED/po/hu.po > branches/SuSE-Code-11-SP2-Branch/slide-show/SLED/po/it.po > branches/SuSE-Code-11-SP2-Branch/slide-show/SLED/po/ja.po > branches/SuSE-Code-11-SP2-Branch/slide-show/SLED/po/ko.po > branches/SuSE-Code-11-SP2-Branch/slide-show/SLED/po/nl.po > branches/SuSE-Code-11-SP2-Branch/slide-show/SLED/po/pl.po > branches/SuSE-Code-11-SP2-Branch/slide-show/SLED/po/pt_BR.po > branches/SuSE-Code-11-SP2-Branch/slide-show/SLED/po/ru.po > branches/SuSE-Code-11-SP2-Branch/slide-show/SLED/po/sv.po > branches/SuSE-Code-11-SP2-Branch/slide-show/SLED/po/zh_CN.po > branches/SuSE-Code-11-SP2-Branch/slide-show/SLED/po/zh_TW.po Karl, IMO it would be better to mention at least the reason for such a big update or just a few words next time. Bye Lukas -- Lukas Ocilka, Appliances Department SUSE LINUX s.r.o., Praha -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

2 1

[yast-devel] fixed oscsubmit to not submit *.rej and *.orig files
by Ladislav Slezak 25 Oct '11

25 Oct '11

Hi all, I have slightly modified 'y2tool oscsubmit' command to not submit *.rej and *.orig files. The reason is that it happens quite often to me that I submit these files to factory, which of course leads to rejected submit. These files (usually *.changes.orig/.rej and *.spec.orig/.rej) are left after failed merge - it happens when I merge the same fix from SP2 to trunk, fix the conflicts, but when I forget to remove these files they are submitted (added) after running 'y2tool oscsubmit'. The fix removes all *.rej and *.orig files from the submit, so they cannot be used for regular files, but that should not be a problem. So install the latest devtools if you are as forgetful as me... ;-) -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak(a)suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

1 0

[yast-devel] YaST with GTK3 Frontend
by Lukas Ocilka 25 Oct '11

25 Oct '11

Hi, Ilya Chernykh at opensuse-factory (#1) asks for GTK3 support for YaST frontend. Any news on that subject? Is anybody hacking it already? Maybe it sounds like a good HackWeek (or YaST Workshop) project ;) Bye Lukas #1 http://lists.opensuse.org/opensuse-factory/2011-10/msg00570.html -- Lukas Ocilka, Appliances Department SUSE LINUX s.r.o., Praha -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

2 1

[yast-devel] Re: [yast-commit] r66463 - in /branches/SuSE-Code-11-SP2-Branch/theme: ./ SLE/icons/ SLE/icons/22x22/apps/ SLE/icons/256x256/ SLE/icons/256x256/apps/ SLE/icons/32x32/apps/ SLE/icons/48x48/apps/ SLE/icons/64x64/apps/...
by Ladislav Slezak 21 Oct '11

21 Oct '11

Dne 17.10.2011 11:15, tgoettlicher(a)svn2.opensuse.org napsal(a): > Author: tgoettlicher > Date: Mon Oct 17 11:15:41 2011 > New Revision: 66463 > > URL: http://svn.opensuse.org/viewcvs/yast?rev=66463&view=rev > Log: > added iucv icons > > Added: > branches/SuSE-Code-11-SP2-Branch/theme/SLE/icons/256x256/apps/yast-iucvterminal-server.png (with props) > branches/SuSE-Code-11-SP2-Branch/theme/SLE/icons/256x256/apps/yast-iucvterminal.png (with props) Um, do we actually need 256x256 icons? Any use case for them? -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak(a)suse.com SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

2 1

[yast-devel] Re: [yast-commit] r66467 - in /branches/SuSE-Code-11-SP2-Branch/product-creator: VERSION package/yast2-product-creator.changes src/Kiwi.ycp
by Ladislav Slezak 19 Oct '11

19 Oct '11

Dne 17.10.2011 14:04, jsuchome(a)svn2.opensuse.org napsal(a): > + ret_path = sformat ("%1/config%2.xml", > + Directory::tmpdir, > + mergestring (splitstring (xsl_file, "/ ."), "-")); Um, why is there "/ ." -> "-" change? Looks strange, could you add a comment so it's clear why the change is needed? -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak(a)suse.com SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

2 2

[yast-devel] Re: [yast-commit] r66466 - in /trunk/storage: package/yast2-storage.changes storage/src/inst_disk_proposal.ycp
by Ladislav Slezak 19 Oct '11

19 Oct '11

Dne 17.10.2011 13:02, fehr(a)svn2.opensuse.org napsal(a): > @@ -149,8 +167,15 @@ > { > map prop = StorageProposal::get_inst_prop(Storage::GetTargetMap()); > y2milestone( "prop ok:%1", prop["ok"]:false ); > + SCR::Write(.target.ycp, "/tmp/prop_first", prop ); Do not use a fixed path when writing to /tmp as root (security issue). (This seems to be used only during installation, so probably no real problem here, but if someone calls the function in the installed system or copy&past part of the code then there is a security problem...) -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak(a)suse.com SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

2 1

[yast-devel] YaST++: the API discussion
by Jiri Suchomel 19 Oct '11

19 Oct '11

Hi, YaST++ is divided into two layers, the low-level for accessing system (behind D-BUS) and high level library. We are calling them "config agents" and YLib library (the 'Y' in YLib is the remaining reference to YaST). Potential application could actually want to use both layers, so we have to define some API that's reasonably stable and nice to use. For config agents, we've agreed that thay should basically return the file structure of the file they are accessing to. One way is e.g. the augeas structure covering whole file (when augeas is used, of course). For YLib, we discussed something close to REST model. We want to use one Read function and 3 ones for writing: Add, Modify, Delete. Read function has one argument, write functions have 2 of them, first for providing some "directing data", second for the real data to be written. To see the examples, go to https://github.com/yast/yast--/wiki/YLib-Use-Cases The discussion is not finished yet, so feel free co comment. Jiri -- 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 To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

1 0