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@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org