http://bugzilla.suse.com/show_bug.cgi?id=922023 Martin Vidner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ancor@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=922023 Martin Vidner changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mvidner@suse.com) | --- Comment #4 from Martin Vidner --- Pepa's code so far is in https://github.com/yast/yast-ruby-bindings/tree/init_ui but there is some kind of a linking problem. Regarding the questions in comment 2, I think it is better to require explicit initialization than too much smart guessing. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=922023 --- Comment #7 from Martin Vidner --- The above test, with 13.2 code, failed with: 2015-04-24 16:49:01 <1> dhcp139(878) [ui-component] YUIComponentCreator.cc(createInternal):124 Creating UI component for "" 2015-04-24 16:49:01 <3> dhcp139(878) [ui-component] YUIComponent.cc(createUI):144 createUI() called before setServerOptions() ! With the linking problem fixed, we get a little further: 2015-04-24 16:57:54 <1> dhcp139(1086) [ui-component] YUIComponentCreator.cc(createInternal):124 Creating UI component for "" 2015-04-24 16:57:54 <2> dhcp139(1086) [ui-component] YUIComponent.cc(createUI):156 Using dummy UI, NOT creating a UI https://github.com/yast/yast-ruby-bindings/commits/347506fa098e9f847d95cf287... With ui_name changed from "UI" to "ncurses" in src/binary/Yast.cc, it does show the dialog (yay!) but then crashed during deinitialization (even if I add UI.CloseDialog) 2015-04-24 17:06:53 <1> dhcp139(1239) [ui] YUILoader.cc(deleteUI):104 Shutting down UI 2015-04-24 17:06:53 <1> dhcp139(1239) [ncurses] YNCursesUI.cc(~YNCursesUI):113 Stop YNCursesUI 2015-04-24 17:06:53 <3> dhcp139(1239) [ui] YUI.cc(~YUI):88 shutdownThreads() was never called! 2015-04-24 17:06:53 <3> dhcp139(1239) [ui] YUI.cc(~YUI):89 shutting down now - this might segfault (and it indeed crashes, though not with a segv, the details are better visible with strace -s999 -o strace.log -f ./ui-without-y2base.rb ) Branch updated. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=922023 --- Comment #9 from Josef Reidinger --- mvidner - ncurses is wrong, I do not want to open any window. I use UI intentionally as it is value for y2base when you need to setup no UI. Maybe it is just wrong UI server and we need to have something similar in libyui that provide same functionality, so something like Stefan suggested. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=922023 --- Comment #11 from Stefan Hundhammer --- Result of a quick video conference between mvidner, jreidinger, shundhammer: The goal of this would be to use part of the UI to do a sanity check on terms passed to the UI for building a dialog etc. so it could complain about syntax errors. There is the "dummy UI" that can be used to completely bypass all UI calls, but this is insufficient for those purposes: It simply always returns 'nil' for every call. What is required here is actually using the calls from YCPDialogParser.cc in yast-ycp-ui-bindings so they can check the arguments passed to UI::OpenDialog() and related calls. With the current architecture, however, this requires having a real UI with real concrete widgets (as opposed to abstract widgets on the libyui level) and a real widget factory that instantiates them: The YCPDialogParser is a "recursive descent" parser with code generation in each node of the parsing tree. It calls the respective YWidgetFactory methods for creating a VBox, a HBox, a PushButton as each of those terms is evaluated in the UI dialog description term. As of now, there is no simple way to mock all this since each factory method is required to return the correct pointer type (e.g., a YPushButton * for a PushButton etc.). It's not as simple as having two or three simple widget types that could be used at will; many widgets have pure virtual methods that need to be implemented correctly. Some of them are called in the YCPDialogParser already. This makes it not trivial to create a special TestUI that does little more than allow this kind of parsing and checking without actually creating UI elements: Each of the widget classes described in libyui/YWidgetFactory would have to be implemented at least in principle with implementations for the required pure virtual methods. This can be done, and it's not exactly rocket science, but it is substantial work. And the result would have to be maintained along with the other UIs, of course. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=922023 --- Comment #13 from Josef Reidinger --- to summary advantages and disadvantages: Martin VNC approach: advantages: - non-intrusive - test real code disadvantages: - need explicitelly specify if need qt or ncurses - adds requirements for tests, can increase significantly build env Test UI approach: advantages: - quick as it do not create anything real - no special initialization needed, so can be default when require yast without any ui component disadvantages: - more code and work - code to maintain - can have bugs that are not in production env -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=922023 --- Comment #15 from Martin Vidner --- Finalizer is taken care of, names to be discussed in the PR: https://github.com/yast/yast-ruby-bindings/pull/142 -- You are receiving this mail because: You are on the CC list for the bug.