November 2007 - YaST Development - openSUSE Mailing Lists

[yast-devel] sw_single Acccessibility Category
by Bryen 29 Nov '07

29 Nov '07

We're working on figuring out what all the accessibility tools software already exists. For now, we're looking at gnome.org's accessibility documentation and then running searches in sw_single to determine whether we have it already. But some tools listed in their documentation is named differently on our end. For example: gnome-online-keyboard in the documentation is gok in our repository. We think it would be well worth it if an accessibility category could be added so users could easily narrow down what tools are available for download/already-installed. Would it be feasible to add such a category? I would be more than happy to compile a list over the next few months of such tools so we can populate the category. Thanks! -- ---Bryen--- -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

3 5

[yast-devel] Redesign of YaST Control Center
by Thomas Goettlicher 29 Nov '07

29 Nov '07

Hi everyone, we want to redesign the YaST Control Center. Therefore we are looking for a radical new design. This is your chance to share your ideas regarding YaST Control Center. Please feel free to contribute with mockups and (unconventional) ideas here: http://en.opensuse.org/YaST/Development/New_Control_Center Thanks, Thomas --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

5 6

Re: [yast-devel] Wt and Yast
by Wim Dumon 28 Nov '07

28 Nov '07

On Nov 26, 2007 4:32 PM, Stanislav Visnovsky <visnov(a)suse.cz> wrote: > Hi Wim! > > Cool to see you here! > It's our pleasure to see that Wt is considered for Yast. <snip> > > The biggest issue I've faced was the fact that almost every functionality in > the Wt classes went down to figuring out the session, and this info seems to > be depend on the boost thread-local storage. So, I needed to be very careful > in which thread I'm running, creating additional overhead. > See my other post, I think you should structure it differently so that you don't need any thread switching at all. > YaST has a base component library, which provides the main() function. This > function evaluates the commandline arguments, picking client (typically YCP > code) and server (typically UI). You should accept that a single web daemon will be able to serve multiple yast sessions, and thus it is started in a way not specific to a particular user, but rather as a plain daemon. The way you start yast from the command-line is on the same level as where a particular user surfs to the daemon and starts a new session. That will cause the 'create application' callback (argument of Wt::WRun) to get called, from which you have to return a WApplication object. If multiple users are surfing to the Yast website simultaneously, multiple Yast applications are running simultaneously, either as separate unix processes or within the same unix process, depending on your wt deployment options. > In threaded example, YCP code is started and when it first encounters UI call, > it calls the UI component (*). The component then finally creates a real UI, > starting a thread to handle events and redraws (call it UI thread). Every UI > call from YCP synchronizes with the UI thread via 2 pipes implementing > message passing, the real UI functionality is always evaluated in the UI > thread. > I suggest you do something like this, since it only changes the bootstrap, and considers the YCP as a "worker" thread spawned from the Wt event loop: - createApplication() [in the Wt thread], creates a YCP thread, and waits for a synchronization signal from the worker thread. - YCP thread triggers UI code which sets up synchronization pipes and signals the Wt thread - Wt thread creates the WApplication and (and anything else). From here on it should be the same story as the Qt UI, but instead of running app->exec() method, it returns the Application instance. Bottom line: As Wt is an 'application server', it can cause multiple Yasts to be started (one per user surfing to the application server). We recommend to write your program in such a way as if the 'create application' callback that you specified as parameter of Wt::WRun() is the 'main()' function of what you would have written in a Qt application. The main task of main() in a Wt application is to call Wt::WRun(). Regards, Wim. -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

2 1

Re: [yast-devel] Wt and Yast
by Wim Dumon 27 Nov '07

27 Nov '07

On Nov 26, 2007 3:24 PM, Duncan Mac-Vicar Prett <dmacvicar(a)suse.de> wrote: > > On Monday 26 November 2007 11:49:05 Wim Dumon wrote: > > Hello Duncan and others, > > <snip> > > Could you provide us with some insights about your architecture and > > how you integrate Wt? We may be able to help you out so that Wt and > > Yast become good friends (e.g. by implementing something similar to > > QSocketNotifier?) > > For me QSocketNotifier was the missing part, as Qt offers a way to react to a > socket event while still integrating the event loop. Working on it - we will let you know when it is in CVS. > Also, is there a way in Witty to get into and out of the event loop? What do you mean with that? > Anyway, in case of getting further, we still faced some basic design problems, > like the UI having to run as root, unless we used fcgi, for which there too > many missing pieces in YaST (authentication?) > I don't know why you would have to run a Wt process as root... It's probably not an issue to let Wt listen to a port >= 1024 (possibly using apache to forward connecitons from port 80 to the Wt process) - the rest depends on the Yast architecture. And yes, it is wise to implement some form of authentication, but the user interface part in Wt should be straight-forward. >From a user perspective, the way I would envision using a yast web GUI, is by having a (non-root) daemon spawned from init.d, thus at boot time. Then, instead of logging in to the server (authenticating through ssh) and starting yast, I surf to the web page, authenticate there and "start" yast. This assumes that your main() routine only starts whttpd, and in your 'create application' callback function, after authentication, you are at the same level as a Qt application. Remind that in Qt you have to call app->exec(), whereas in Wt you need to return a WApplication from the this callback function - by returning this WApplication object, you have created a new instantiation of the application. I can imagine that this is the main point of conflict with your current architecture? However, in this way, you don't need to spawn special threads for getting the Wt event loop going, and you can structure your application further as you do a Qt application (given that we add WSocketNotifier), since you are already running inside Wt's event loop? Regards, Wim. -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] Pkg-bindings - new wiki page at opensuse.org
by Ladislav Slezak 27 Nov '07

27 Nov '07

Hello developers, I have created a wiki page for pkg-bindings (http://en.opensuse.org/YaST_Pkg_Bindings) currently it's quite small but the most important for you are the change log pages where I summarized the changes which may influence other Yast modules. Here is a summary of changes in openSUSE 10.3 (compared to 10.2): http://en.opensuse.org/YaST_Pkg_Bindings-openSUSE_10.3 and in the current development branch (SVN trunk): http://en.opensuse.org/YaST_Pkg_Bindings-SVN_Trunk -- 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 For additional commands, e-mail: yast-devel+help(a)opensuse.org

2 1

[yast-devel] Wt and Yast
by Wim Dumon 26 Nov '07

26 Nov '07

Hello Duncan and others, We, the developers of Wt, are a bit surprised to see your efforts on integrating Wt with Yast causes crashes and other problems (we followed your progress on the yast mailing list and the comments on your blog). Normally, Wt runs uber-stable (e.g. on our public site) and we want to keep it that way, so we're very eager to know what exactly caused the crashes so that we can catch and fix the bugs. We picked up something about Wt's thread model being incompatible with Yasts use of threads. Therefore, we have patched Wt so that you can disable all use of threads completely (in our CVS version). Could you provide us with some insights about your architecture and how you integrate Wt? We may be able to help you out so that Wt and Yast become good friends (e.g. by implementing something similar to QSocketNotifier?) Thank you, Wim Dumon. -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

3 3

[yast-devel] How to preselect a table entry?
by Johannes Meixner 26 Nov '07

26 Nov '07

Hello, how can I have a particular table entry preselected like an entry in a SelectionBox? Or how can I show a table without any entry preselected? It seems by default the topmost entry ina a table is preselected. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

6 8

[yast-devel] SVN access
by Stephan Kulow 26 Nov '07

26 Nov '07

Hi! I picked up branches/tmp/sh/qt4-port/, merged with mod-ui and finished the port to integrate well into the event loop and the threading. What I wonder though: 1. Can I continue my experiments in yast svn? git is all fine, but I only trust $HOME :) 2. is there an easy way I can keep it in parallel to sh's qt? E.g. just install as yast2-qt4 for the time being? Greetings, Stephan P.S. cmake anyone? :) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

3 2

Re: [yast-devel] How to preselect a table entry?
by Thomas Fehr 23 Nov '07

23 Nov '07

Hi Again, Lukas kindly reminded me that this is an english mailing list, sorry for forgetting that. Here my reply again in english: > how can I have a particular table entry preselected like > an entry in a SelectionBox? Basically with the following: string tag = (string)UI::QueryWidget(`id(`table), `CurrentItem); UI::ChangeWidget(`id(`table), `CurrentItem, tag ); AFAIK nothing gets preselected, if one uses a value with ChangeWidget that does not exist in the table. Tschuess, Thomas Fehr -- Thomas Fehr, SuSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Markus Rex, HRB 16746 (AG Nürnberg) Tel: +49-911-74053-0, Fax: +49-911-74053-482, Email: fehr(a)suse.de GPG public key available. -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

3 3

[yast-devel] improvements in ruby bindings
by Duncan Mac-Vicar Prett 23 Nov '07

23 Nov '07

Copied from: http://duncan.mac-vicar.com/blog/archives/281 After quite lot of hacking nights, I managed to get some yast2 ruby bindings improvements working. You might know that ycp is not only a language, but a component technology. Every component using the YaST2 technology can be reused from other YaST components no matter what language they are written in, as long as there are bindings for that. That was the original intention of the ruby bindings. So for example, there is a component call Storage, which is written in the ycp language. The component (well, it is really a namespace, but YaST sees it as a namespace component) is located in /usr/share/YaST2/modules/Storage.ycp (.ybc for the bytecode compiled version) and offers some medium level functions that YaST uses. This component needs low level access to the system, for which there is another module called Libstorage ( located in /usr/share/YaST2/modules/LibStorage.pm ) which in this case is written in perl which is a language YaST supports as long as you follows some simple rules. The reason is because libstorage is a C++ library, and there is no easy way to bind it to the YaST environment, but as YaST supports perl, you can generate perl bindings for the C++ library and all the library functionality will be available to other components in YaST. So repeat after me. ycp is not only a language. It is a communication protocol, used by YaST component framework. So, with the ruby bindings, you where able to do: require 'yast' m = YaST::Module.new("Storage") dp = m.GetDiskPartition("/dev/sda1") dp.each do | key, value | puts "#{key} #{value}" end But I was never happy with the syntax. The idea was that you construct a dynamic proxy for a YaST component and then call methods on it. This had some disadvantages: * If the component did not exist, you did not get an error till the method call * It was not possible to do introspection to the component, because the methods call where implemented using the method_missing hook. So basically the proxy responded to all methods and only raised an error if the equivalent call to the YaST side was not possible. So I decided to look for a new approach. This is the result till now: require 'yast' require 'ycp/storage' dp = YCP::Storage::GetDiskPartition("/dev/sda1") dp.each do | key, value | puts "#{key} #{value}" end Oh yes, you notice. First, there is no need to instantiate the module, a classic require will do it. The bindings modify the built-in require method, so if you require something under ycp/, a module is created on the fly. A real module, a real symbol. You can also import it manually using YCP::import Now, you can do this: puts YCP::Storage.methods When the module is imported, the symbols are declared in the module, so you can ask for them in the module. I still need to work on other symbol types, but it should be straight forward. The last improvement is that I simplified the C part of the bindings a lot, and moved most of the magic to pure ruby code, which makes easier to work with. Next improvement, the other way around, making nicer how to call ruby components from any other component. -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0