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
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
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
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
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
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
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
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
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