Mailinglist Archive: yast-devel (156 mails)

< Previous Next >
Re: [yast-devel] Adding missing API to libzypp (or between libzypp and apps)
  • From: Katarina Machalkova <kmachalkova@xxxxxxx>
  • Date: Fri, 29 Jun 2007 12:47:41 +0200
  • Message-id: <200706291247.47606.kmachalkova@xxxxxxx>
> > Well, the idea steadily evolved into something like 'writing a wrapper
> > over libzypp' (called 'zypp4ui' for the time being) so that an
> > application that
>
> Not wrap - fix, improve and cleanup zypp.

Michaeli, mohl bys priste prosim psat sve komentare a pripominky v takovem 
jazyku, kteremu rozumi i normalni lide, jako treba ja? 
Dekuji 

Now let's get serious: Seems that we misunderstood each other and I admit that 
I was not that good at explaining what I am doing right now and what is the 
purpose of my work.

I am not a zypp developer and I very often do not completely understand the 
black magic of zypp. But what I perceive as a real problem is that there are 
hundreds of lines of zypp code in yast UI libraries. The code is mostly doing 
things such as listing and filtering objects (i.e. selectables) and it's 
almost identical in all UI's. 

Example (maybe more obvious than a previous one):

What do we want to do:  Show pending licence agreements to the user 
(i.e. iterate through zypp pool, find packages/patterns that have licence 
agreement and show EULAs to the user - and yes, what I call 'low-level zypp 
function' is e.g. iterating through zypp pool and looking for something)

How do we do it:  in yast2-qt in 62 lines of code 
(http://svn.opensuse.org/viewcvs/yast/trunk/qt/src/pkg/YQPackageSelectorBase.cc?revision=37469&view=markup( ), 
in yast2-ncurses in 56 lines of virtually identical code 
(http://svn.opensuse.org/viewcvs/yast/trunk/ncurses/src/pkg/NCPackageSelector.cc?revision=38309&view=markup)

My idea was to implement this function (showPendingLicenseAgreements()) in a 
wrapper library over zypp and have UI library link it and the code of UI 
library call it.
Why to have the same code doing the same things on N different places (where N 
is the number of applications using concept of selectables), implementing 
features and doing bugfixes on N libraries, if we can have the code and the 
functionality in the single place and make all N applications use it? It 
would make maintenance much easier than now

Just to make things work, I started up with function prototypes such as 
list <ZyppSell> filterFunction( some filter_variable)

but I'm aware of the fact that it would potentially slow the whole thing down. 
First zypp4ui would iterate through zypp pool, return filtered list of 
selectables, and only after that UI application would process this list.

I'm going to change it to something like;
void filterFunction (some filter_variable, consumerFunction(ZyppSelectable &)

where filterFunction would iterate through the zypp pool, check if selectable  
matches filter_variable and if so, call consumerFunction, which would be a 
function object actually processing the selectable - e.g. make a line in 
package table out of it, display its EULA text etc. All that in single pass 
through the pool.

Hopefully I've now expressed myself more clearly

B.
-- 
   \\\\\              Katarina Machalkova    
  \\\\\\\__o          YaST developer
__\\\\\\\'/_          & hedgehog painter
< Previous Next >