YaST Development June 2007

yast-devel@lists.opensuse.org

32 participants
24 discussions

by Scott Reeves

GNOME uses the freedesktop menu and .desktop spec standards to generate all it's menus - the traditional menu, the application browser and the control center. This method uses a .menu file and the Category= line from .desktop files to determine which menu entry a .desktop file falls into. AFAIK KDE also uses this for it's main top level menu. As of sp1 we added the yast2 control center which also uses this method. I was not involved in the very start of this so I don't want to speak incorrectly but I think a .menu file was generated that simply contained all the menu categories that currently showed in the qt shell. Then it used the already existing Categories= lines in .desktop files like /usr/share/applications/YaST2/users.desktop Unfortunately, that means there is currently two ways to generate the yast2 menus - the yast2 specific way using the X-SuSE-YaST-Group key and the Category= way. Towards the end of SP1 we ran into some issues with this. Using the .menu/.desktop specs to generate the menus means we get common code shared between all the menus and we can use the standard gmenu library to parse all the relevant information from the .desktop files including supporting all the other tags such as OnlyShowIn, Hidden, ... Could we move to supporting the .menu/.desktop spec way of generating menus for the yast shells – given that almost all of the existing .desktop files contain some sort of “Categories=X-SuSE-YaST-*” line it appears something along that lines is already under way. -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

14 years

[yast-devel] yast-kdump screen shots

by Maneesh Soni

Hi Jozef There are few more changes which I think would be good to have. Please let me know if these are possible to make or not. 1. Start-up ----------- Please move the "kdump memory" settings from "Dumping" screen to "Start up". As, IMHO, the start-up setting should have the minimum things which are absolutely necessary for enabling kdump service. Without reserving memory one cannot enable kdump. 2. Save Dump Image ----------------- IMHO, we can rename the tittle to something like "Dump Target Settings". The other options looks great. Only a couple of issues, firstly, in case of "Raw Disk", I think the "Directory for saving Dumps" is not needed. Secondly, for NFS, I think "Share" is not needed. 3. Expert Settings ------------------ IMHO, this tab should contain all the settings which normally user will not change. Apart from kdump kernel command like options, we can move the setting wrt "No. of Old Dumps" from "Dumping" screen to expert settings. Also can we put one more option to use a custom kdump kernel initrd which can be used save/process the dump. 4. Dump-filtering ----------------- I think we should either merge this with "Dump Target Settings" or if there is not much space left there, then a separate screen. Please let me know if these make sense or not. Regards Maneesh -- Maneesh Soni Linux Technology Center, IBM India Systems and Technology Lab, Bangalore, India -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

14 years

[yast-devel] [RFC] QueryBuilder and (Resolvable)Query

by Jan Kupec

Hi! Here is my proposal of a new libzypp API for various metadata queries. It should be useful for YaST package managers, zypper, YaST online update and maybe others. Pease see attached QueryBuilder.h file and comment on the design and usability. QueryBuilder is meant to build an sqlite query for libzypp's metadata cache database and to be used by ResolvableQuery::query(QueryBuilder,ProcessingFunctor) function (or other Query class) to do complex resolvable data queries. Result of these queries will be processed by ProcessingFunctor (read on). The reason to create such an API is to have a convenient API for coding various kinds of user queries, so that apps using libzypp don't have to code the functionality by themselves by traversing the resolvable pool. And since we (will hopefully) have the new metadata cache database, there is another reason: to make use of the database to speed up the search and save memory requirements (don't load the pool, just query the database). I would have to code it once in zypper anyway, so this way it can be reused by others as well. CODE EXAMPLE: //////// code START ///////////////////////////////////////// bool is_regexp; // treat the search string as regexp? bool search_summaries; // search also in summaries? string search_string; // user given search string Resolvable::Kind kind; // the result will be limited to this kind <snip> zypp::cache::QueryBuilder builder; builder.addName(search_string, is_regexp); if (search_summaries) builder.addAttribute(zypp::cache::attrResObjectSummary(), search_string, is_regexp); builder.addKind(kind); zypp::cache::ResolvableQuery resquery; resquery.query(builder, processing_functor); //////// code END ///////////////////////////////////////// (the functor is function<bool( const data::RecordId &, data::ResObject_Ptr )> we can provide one which would use Selectables (or NameKindProxy) for yast as well) FEATURES - search by name, any cache attribute, kind, (future: installed status), version - uses simple strings or regexes - search by dependencies (select resolvables which are required by e.g. pattern X) - use multiple search conditions and choose to require all or any of them satisfied. IMPLEMENTATION - based on given arguments and options, an sqlite command will be built This command will be executed by a ResolvableQuery::query() or another Query class (see attachment - just a stub). - i decided to write field values into the sqlite command string itself. Using variable names and bind values to them would be too complex. - regexes - sqlite's REGEXP keyword will be used, bound to user (libzypp) defined regexp matching function of our liking. ISSUES - what regexp syntax do we want to support? - something missing/to be changed in the API? Cheers, Jano

14 years

[yast-devel] Regarding "Installation source" vs "Repository"

by Andreas Jaeger

Hi Guys, there have been quite some discussions regarding the terms "Installation Source", "Repository" and "Catalogs". Product Management had decided that for SLES10 and SLED10 - and products based on that the term "Catalogs" is to be used. We want to use the same name in all cases and therefore consider changing it for our products and this involves some discussions. There was no management decision at all to use "Catalog" for future products, Rebecca seems to have misunderstood something. As you've noticed, there's some confusion on how to move forward. I'm travelling right now and will continue this discussion to get everybody - both you as community and us Novell folks - aligned on this. I'm sorry for how this currently pops up and I'm not happy about it. Regards, Andreas P.S. As I'm travelling I haven't had time to read the complete discussion. Please bear with me - I might not be online before tuesday again. -- Andreas Jaeger, aj(a)suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

14 years

[yast-devel] Wizard dialogs without help?

by Johannes Meixner

Hello, for HackWeek I am working on an experimental YaST module, see http://idea.opensuse.org/content/ideas/usable-printer-setup-tool Currently I use for the dialogs something like -------------------------------------------------------------- Wizard::SetContentsButtons ( caption, contents, HELPS["basic_add_dialog"]:"", Label::BackButton(), Label::NextButton() ); -------------------------------------------------------------- Is it possible to get Wizard dialogs without help sub-window? I.e. have full-screen contents? Reason 1: My superb new innovative dialogs (TM) are fully self-explanatory so that there is no need for any help text at all. Reason 2: I read in books from usability experts that a UI is very likely bad designed when explanation texts (aka. help texts) are needed. Reason 3: My superb new innovative dialogs (TM) are perfectly designed ;-) 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

14 years

[yast-devel] Adding missing API to libzypp (or between libzypp and apps)

by Jan Kupec

Hi there! Check out this idea page and see what's needed and who intends to do what: http://idea.opensuse.org/content/ideas/better-api-for-applications-using-li… This idea might be of interest for people writing applications using libzypp who were missing some functionalities and libzypp devels. In particular: YaST package manager UI (qt, gtk, curses), zypper, YaST online update. If you have any comments or want to participate, edit that page and use the discussion facility there and describe what would you like to do. Jano -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

14 years, 1 month

[yast-devel] Redefinition of WizardStepsDialog

by Lukas Ocilka

Hi, For a Game Add-On during installation I'd (lmichnovic wants me to do it :)) like to redefine the "Help" button label and handling. The goal would be to have a "Game"-labeled button with a callback function assigned to handle it. Is there some possibility? UI::WizardCommand? Where can I find some documentation, please? Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic

14 years, 1 month

[yast-devel] hackweek, ruby support for yast progress

by Duncan Mac-Vicar

you can read it here: http://duncan.mac-vicar.com/blog/archives/245 cheers! -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg 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

14 years, 1 month

[yast-devel] New UI Widget -- Idea for Qt and GTK+ interfaces

by Lukas Ocilka

Hi, When YaST developer or designer are designing the YaST dialogs, they need to define some relative sizes between widgets. Unfortunately, the worst cases cannot be expected and we usually ignore them. Please, see the attachment in this mail. The 'Repository Description' is always replaced with a new one when some other repository is selected in the 'List of Repositories'. The worst case is that there fifty repositories in the 'List of Repositories' but most of the descriptions need thirty lines in the 'Repository Description'. Please, don't write that it would be a _wrong description_, such cases just happen time to time. My idea of a solution would be a user-controllable slider in UI - a new widget for graphical UI. Users could then themselves decide what is more important for them if the data don't fit the UI because screen is not inflatable ;) I'd like to ask YaST developers whether they feel this is worth a feature request and whether it makes even sense to want it. I know that both Qt and GTK+ could implement it but I don't have any idea how difficult would it be. Please, before writing "wrong UI design", "wrong data" ... think about that a few seconds :) If you always wanted such UI feature, write it too ;) Rather think about the advantages of it first :) Thanks & Bye Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic

14 years, 1 month

[yast-devel] Modified changelogs in YaST packages

by Lukas Ocilka

Hi, It seems that several YaST packages might have been changed just in the autobuild / build service. Please, merge those changes into your packages in trunk. For more information, please, read the attached mail. Thanks & Bye Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic

14 years, 1 month

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

YaST Development June 2007