Mailinglist Archive: yast-devel (191 mails)

< Previous Next >
Re: [yast-devel] Package-Bindings
  • From: Ricardo Cruz <rpmcruz@xxxxxxxxxxxxxxxxxxx>
  • Date: Fri, 21 Mar 2008 16:54:19 +0000
  • Message-id: <1206118459.4280.59.camel@xxxxxxxxxxxx>
Sex, 2008-03-21 às 10:36 +0100, Lukas Ocilka escreveu:
Ricardo Cruz napsal(a):
Qui, 2008-03-20 às 19:41 +0100, Klaus Kaempf escreveu:

Stefan already mentioned it, the UI currently offers 'update all in
this list' - updating just an arbitrary set of packages.
This makes a lot of sense in the context of 'just updates from this
repo' or 'just updates from this vendor'.

So (probably post-openSUSE 11.0) we should think about a API to define
(resp. restrict to) a set of packages.

[my comment]

Maybe libzypp should stay more low-level and such high-level API could
be created in Libzypp Application Layer. That IMO seems to be the right
place.

Sure, I was replying to the API comment. That is, the Application
Programmers Interface. Or Application Layer, as you kids call it. ;)
Seriously, if by low-level you mean all those files that seem to have
only internal garbage that nobody should care about, I agree those
things should not be published as currently they are.

You could have some constructs available like those. Preferably, it
would be a generic interface that would be implemented for the pools
too. But if you KISS the API, this would not be an issue. As it was
stated, it sounded like a patch trying to block the hemorrhage that is
libzypp. :/

Some cool stuff that we actually need is to have a proper channel to
get the package dependencies (not the raw strings), so that we can draw
some nice graphs, and let the user jump around.

http://en.opensuse.org/Libzypp/Application_Layer/API_Proposal

Okay, this is my proposal:
http://svn.opensuse.org/svn/yast/trunk/gtk/src/yzyppwrapper.h

A lot of it was done as I needed, so it could be beautified (and stuff
like categories should be abstracted as some package ancestor type), but
its simple and serves our interface fine.
e.g. If you'd like to populate your Table widget:

Ypp::QueryPool::Query *query = new Ypp::QueryPool::Query();
query->addType (Ypp::Package::PACKAGE_TYPE);
query->setIsInstalled (false);

Ypp::QueryPool *pool = new Ypp::QueryPool (query);
for (Ypp::Pool::Iter it = pool->getFirst(); it; it = pool->getNext (it)) {
Ypp::Package *pkg = pool->get (it);
table->addRow (pkg->name());
}

And you can setup an object to reflect pool changes in your table:

struct LiveTable : Ypp::Pool::Listener {
LiveTable (Pool *pool, Table *table)
: ... { pool->setListener (this); }
~LiveTable() { delete m_pool; }

virtual void entryChanged (Ypp::Pool::Iter iter, Package *package)
{ m_table->edit (toRow (iter), package->name()); }

virtual void entryInserted (Ypp::Pool::Iter iter, Package *package)
{ m_table->add (toRow (iter), package->name()); }

virtual void entryDeleted (Ypp::Pool::Iter iter, Package *package)
{ m_table->remove (toRow (iter)); }

int toRow (Ypp::Pool::Iter iter)
{ return m_pool->toPath (iter).first(); }
};

If possible, its better to extend the Table widget of the GUI toolkit
to avoid the overhead of copying the data around without the rows being
visible, but the same API is fine for that.

With regard to the abstract attributes in your proposal -- I'm not sure
if that really is worth the trouble. It means more work for Zypp
developers and API users just to make it a tad easier to extend for new
attributes.
Besides, you may want to use more data types than strings and integers;
like paths for the categories. So, some attributes may actually be more
work to extend, as you need to add more hooks to the data abstractor.

Either way, more important and tricky is to get nice ways to go through
the relations between packages-patterns and packages-categories. It
should be possible to navigate through a tree of those with the Pool
object. I never got to abstract those; just implemented Pools for those
purposes.

Cheers,
Ricardo


--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >