PkgQuery overhaul
Ricardo Cruz
I've added two new flags: --categories-top and --status-top.
They can be used in consonance with --dynamic-sidebar. Be warned
however GTK crashes when a combo-item is selected that suddenly
disappears. Not a trivial fix, so let's leave it in until we go
into the crystallization process.
As our main story, I've re-worked the criteria structure you pass
to PkgQuery in order to produce a filtered package listing. This
will make it possible to add new properties like search in provides,
as suggested by Alberto Passalacqua, without touching the backend.
The objects you'll find yourself dealing with mostly is the
QueryProperty that makes use of the recent string properties
mapping from Package (and you can easily derive new classes in
the UI if a given property can not be string mapped). Example:
QueryProperty ("is-installed", true);
QueryProperty ("provides", "libX", false, true);
You can then glue those together using QueryAnd or QueryOr.
QueryAnd *query = new QueryAnd();
query->add (new QueryProperty ("is-installed", true));
...
PkgQuery list (Ypp::Package::PACKAGE_TYPE, query);
view->setList (list); // widget
The search entry now splits the name query by whitespace in the
UI code. That reminds me -- do we want to apply google syntax
here: "(gtk OR gnome) AND 2.0". Here's Banshee take on it:
http://banshee-project.org/support/guide/searching/
A nice automata-like diagram on it:
http://xesam.org/main/XesamUserSearchLanguage
Does anyone want to structure that in some RAD language for us
to adopt in our code? Looks fun. *nudge* *nudge*
Cheers,
Ricardo
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Atri
I was trying the various package manager flags. I think it helps to
have the categories-top as the default view [categories_top.png in
Files]. I have a few suggestions to make about the interface:-
1. It would be good to not show empty "Install", "Upgrade", etc. boxes
in the sidebar. Instead it would be better probably if it were
possible to integrate the three categories [show recent history when
nothing is selected, or just show the text "any packages you select
for installation/upgrade/removal will be listed here"] and then format
the text output in the sidebar better. For example, we could arrange
the deps being pulled in automatically due to a package selection as
slightly indented to the manually selected package [also displaying
this in bold] in the sidebar listing.
2. The best thing I find about the action buttons being adjacent to
the package listing is the fact that there is no need to Ctrl+Click
anymore.
3. It would also be nice to try how the action buttons look with only
icons on them instead of text. That way we can show two adjacent
action buttons, necessary for packages with upgrades available [both
upgrade and remove buttons can then be displayed]. With action buttons
having text, having two buttons would consume a lot of space and look
ugly.
4. Action buttons in the sidebar should only show "undo"/undo icon and
should not be present against automatically pulled in dependencies.
5. It is also necessary to have repository selections. This is not yet
present, but it would definitely add a level of complication to the
interface; we have to figure out a way to avoid showing the
repositories by default, to keep things simple. Perhaps a button at
the top or bottom that says "show repositories" or something similar
and clicking it brings out a sidebar on the left that shows the
repositories.
For the search, I think it might be useful to follow the banshee
method. Also the find text-filed at the top should be similar to
banshee's [with the binocular icon] and show options like filter by
[name and summary, file-list, etc.]. I find it really easy to search
through my music collection using banshee's search.
Wishing everyone a very happy new year!
On Dec 30 2009, 4:27 pm, "Ricardo Cruz" <rpmc...@alunos.dcc.fc.up.pt>
wrote:
--
Atri
Ricardo Cruz
> 1. It would be good to not show empty "Install", "Upgrade", etc. boxes
> in the sidebar. Instead it would be better probably if it were
> possible to integrate the three categories [show recent history when
> nothing is selected, or just show the text "any packages you select
> for installation/upgrade/removal will be listed here"] and then format
> the text output in the sidebar better. For example, we could arrange
> the deps being pulled in automatically due to a package selection as
> slightly indented to the manually selected package [also displaying
> this in bold] in the sidebar listing.
>
That ideas of yours is starting to grow on me. While skeptical at
first, I do think it will make people much more comfortable to test
packages if they now they can easily roll back over. Together with
yast2-qt orphan package listing, this will be a cool addition.
libzypp does allow for this: parser/HistoryLogReader.h. I'm not sure
about whether we can tell if a package was installed as a dependency of
another. libzypp developers should have an ingenious hack for that
either way. I will implement a simple version for our proof of concept
process later today when I get home. One thing to think about however is
whether to present undo button for those old changes, as some might have
since been superseded by another. e.g. If you install then remove a
package, should we show both entries? Or only have an undo button in the
most recent change?
Cheers,
Ricardo
Atri Bhattacharya
libzypp does allow for this: parser/HistoryLogReader.h. I'm not sure
about whether we can tell if a package was installed as a dependency of
another. libzypp developers should have an ingenious hack for that
If you are reading history from the file /var/log/zypp/history then the files installed as dependencies have no associated user while those selected manually have the user root@[hostname] specified. For example in the following snip out of the history file the first one [Mesa-devel] has been installed automatically as a dependency while I manually installed the second one [libqt4-devel].
2010-01-03 14:55:22|install|Mesa-devel|7.6-3.1|x86_64||openSUSE 11.2-0|868d05c522b171ecb8f21219cbd6d54727a59d9a
2010-01-03 14:55:30|install|libqt4-devel|4.5.3-2.4.2|x86_64|root@xxx|openSUSE 11.2-0|155f3fc3a09536ef66466126705eb2210bff17bb
whether to present undo button for those old changes, as some might have
since been superseded by another. e.g. If you install then remove a
package, should we show both entries? Or only have an undo button in the
most recent change?
In my opinion, we should only show the most recent change to a package if possible. If a package has been installed and then removed, we could only show the removal of the package as an event and have an undo button against it [which will re-install the package of course], or we could just show packages recently installed && present in the system [i.e. not removed yet], and show the uninstall button against them.
--
Atri
Ricardo Cruz
>
> libzypp does allow for this: parser/HistoryLogReader.h. I'm
> not sure
> about whether we can tell if a package was installed as a
> dependency of
> another. libzypp developers should have an ingenious hack for
> that
>
> If you are reading history from the file /var/log/zypp/history then
> the files installed as dependencies have no associated user while
> those selected manually have the user root@[hostname] specified. For
> example in the following snip out of the history file the first one
> [Mesa-devel] has been installed automatically as a dependency while I
> manually installed the second one [libqt4-devel].
>
> 2010-01-03 14:55:22|install|Mesa-devel|7.6-3.1|x86_64||openSUSE
> 11.2-0|868d05c522b171ecb8f21219cbd6d54727a59d9a
> 2010-01-03 14:55:30|install|libqt4-devel|4.5.3-2.4.2|x86_64|root@xxx|
> openSUSE 11.2-0|155f3fc3a09536ef66466126705eb2210bff17bb
>
--
Cheers,
Ricardo
Ricardo Cruz
> That ideas of yours is starting to grow on me. While skeptical at
> first, I do think it will make people much more comfortable to test
> packages if they now they can easily roll back over. Together with
> yast2-qt orphan package listing, this will be a cool addition.
>
--undo-side=y --undo-old-style=y --undo-log-all=y
and
--undo-side=y --undo-old-style=y --undo-log-changed=y
--
Cheers,
Ricardo
Ricardo Cruz
> I was trying the various package manager flags. I think it helps to
> have the categories-top as the default view [categories_top.png in
> Files]. I have a few suggestions to make about the interface:-
>
I think that UI goes in the right direction, in that we must drop one
of the lateral bars. I'm not sure everybody will agree with your bar
choice however. We'll want to list the relative benefits of both
choices, and develop a better understanding of our demographics before
evaluating the different approaches.
> 1. It would be good to not show empty "Install", "Upgrade", etc. boxes
> in the sidebar. Instead it would be better probably if it were
> possible to integrate the three categories [show recent history when
> nothing is selected, or just show the text "any packages you select
> for installation/upgrade/removal will be listed here"] and then format
> the text output in the sidebar better. For example, we could arrange
> the deps being pulled in automatically due to a package selection as
> slightly indented to the manually selected package [also displaying
> this in bold] in the sidebar listing.
>
That sounds a lot like the 11.2 look. There is a flag for it:
--undo-side=y --undo-old-style=y
I've modified the look a little bit so it looks more like the text
field when you hit apply.
The changes sidebar will always be visible if you pass the flag:
--details-start-hide=n
> 2. The best thing I find about the action buttons being adjacent to
> the package listing is the fact that there is no need to Ctrl+Click
> anymore.
>
You could also double-click or hit the spacebar in a package entry, but
since those actions are the UI center of mass, it makes sense to make
them more explicit.
I'm still unsure about the relative benefits of the push-buttons
vis-a-vis the check-box. They worked particularly well in this UI:
http://en.opensuse.org/images/7/72/11_2-1.png
( That UI can be enabled via: )
--search-entry-side=n --search-entry-top=y --status-tabs-as-actions=y
--action-col-as-button=n --action-col-as-check=y --single-line-rows=y
Anyway, even with other UI approached, we might be able to pull-off
check-box-looking controls without suffering from the excesses that
plague yast2-qt check-boxes.
> 3. It would also be nice to try how the action buttons look with only
> icons on them instead of text.
Sure, added: --action-col-label=n
Looks a little better, and it should work better for localization. I
also changed their behavior.
> That way we can show two adjacent
> action buttons, necessary for packages with upgrades available [both
> upgrade and remove buttons can then be displayed]. With action buttons
> having text, having two buttons would consume a lot of space and look
> ugly.
>
Those buttons are only meant as shortcuts, to save user's time. For a
more comprehensive selection, the user can hit right-click or use the
description box.
For instance, in the case of your mockup, it makes more sense to me to
have an Add button for the Available tab, an Upgrade one for Upgrades
and a Remove one for Installed. If the user is checking for some package
under Installed and then decides he wants to upgrade it, he can perform
such a sporadic operation pretty easily already. There is little benefit
in having a handy Upgrade button when you sporadically come across a
package you want to upgrade under Installed. However there is
significant cost, in the form of wasteful and oddly-looking blank space,
to reserve space for such a button.
> 5. It is also necessary to have repository selections. This is not yet
> present, but it would definitely add a level of complication to the
> interface; we have to figure out a way to avoid showing the
> repositories by default, to keep things simple. Perhaps a button at
> the top or bottom that says "show repositories" or something similar
> and clicking it brings out a sidebar on the left that shows the
> repositories.
>
I have already tried to come up with an abundance of flags because the
difficulty of UI design is in fitting such complexity of functions. I
will be cooking some flags for the repositories in the future. Anyway,
such a button proposal seems odd. I propose we apply a similar treatment
to repositories as we do to categories.
> For the search, I think it might be useful to follow the banshee
> method. Also the find text-filed at the top should be similar to
> banshee's [with the binocular icon] and show options like filter by
> [name and summary, file-list, etc.]. I find it really easy to search
> through my music collection using banshee's search.
>
There are some problems with the search icon:
1. it's redundant since we'll want to add a label anyway.
2. unlike the monochrome icon of iTunes, the gnome search icon is flashy
and distracting. It isn't made to be placed there, and it shows.
3. the context menu is hard to spot. I've tried to amend that in this
UI: http://en.opensuse.org/images/7/72/11_2-1.png (the arrow no longer
overlaps the icon like in 11.2), but even there a sysadmin (in his 50s)
missed the context menu when I asked him to find me the package that
contained a given file.
4. plus, the context is not keyboard accessible (and while we don't need
a direct shortcut to everywhere, we should ensure you can tab your way
to anywhere).
If we're going to use the search icon, I'm more inclined to place it
next to the label, not inside the entry.
And while searching doesn't seem to warrant all the space that yast2-qt
gives it, it needs something bigger and more evident than a little icon.
I am inclined for a combo-box since you can see the current selection,
but an "Options" button that pops-up a dialog could also work. Or an
expander, if we opt to place it in the sidebar.
--
Cheers,
Ricardo