Mailinglist Archive: opensuse-gnome (216 mails)

[Ricardo Cruz <rpmcruz@xxxxxxxxxxxxxxxxxxx>]

Hi,

 Sorry for taking awhile.

 It seems people are interested interested in using PackageKit
(http://www.packagekit.org/) which is meant to be a common package and
update manager interface common for all distributions, they would just
adapt the backend.
 But such work would require quite some effort, and there doesn't seem
to exist any serious effort at the moment, so we should probably work
out yast-gtk's selector.

Qua, 2007-10-24 às 13:41 +0200, Christian Jäger escreveu:
> >  Something that you didn't show in your mockup is how can the user
> > revert some action. I guess we could use toggle buttons? About the
>
> I thought along the lines of 'click once to mark for install, click
> again to undo'. Perhaps a tooltip when hovering the mouse-pointer over
> the marked tile would be sufficient, or perhaps an optical hint like
> 'pressed-down-button'-look?
 Sure, you mean a Toggle Button, right? As in (paste to terminal):

python
import gtk
window = gtk.Window()
window.add (gtk.ToggleButton ("Package"))
window.show_all()
gtk.main()

> > descriptions and other info, I guess that the confirm dialog would
> > feature those, right?
>
> Yes; although I have to say, I'm a still a big fan of the way Ubuntu's
> 'add/remove' dialogue presents information about the applications

 I guess you don't mean Synaptic, do you? Could you get me a shot of
that program?

> (including those intriguing icons; lucky .deb-people... ;)).
 We could copy them, we don't need to use the ugly ones from yast-qt. :)

> In the mockup this information would only appear when the 'details'
> button is clicked

 Okay. I just think its too "buried", so I would vote to just have the
info (on tabpages, like now) already visible there. I think most user
would want to take a look at Details anyway, and it is much more
comfortable for those that want to check the Details of several packages
(e.g. when choosing a word processor).

> , but that really was laziness on my part. I think it
> would be better to present as much info as possible about the
> application - including small icons for alternate versions where
> applicable.
 I am not sure what you mean by small icons. I guess we would want to
have a combo box like:

Version: | 10.5 \/ |
Repo: opensuse.org
Details: ...........
 ...................
 ...................
  |Cancel| |Install|

 The repo and maybe other fields would change as the user chooses a
version.

> >  Anyway, I wonder whether it wouldn't make more sense to make a
> > dedicated Installer for the newbie. It could just feature all the
> > essential graphical applications. 
>
> Just like the app-browser does, agreed there. The everyday-user needs to
> install either specific graphical applications or patterns that enable
> him to do something, not packages; those should be pulled as
> dependencies without user-interactions (and that's the way it is done
> already, thank you!).

 Yep, the installer should just lists all applications available, e.g.
for word processing, and describe them, maybe even comparing them. Stuff
like openoffice-plugin-* wouldn't be another package, they would just be
displayed together with OpenOffice from some button or something...

 Anyway, what I want to do here is improve the yast-gtk package selector
(possibly the updater too). I just want something more friendly than
yast-qt for people comfortable with computers.

> I like drap-and-drop. My IDEAL package manager for computer-novices
> would consist of a window of available applications popping up from
> which you drag and drop icons into your application-browser. And
> uninstall packages by moving them to trash from the application-browser.
>
> How do you think about this as a long-term perspective?
 I think Apple's success here has more to do with the fact that
applications are self-contained. They are just some package file that
you double-click, and independently where it is, it runs.
 As a result, people see an application package, just like a document
file. So, they organize them, as they would organize their documents.
 In MacOS, the file manager is more integrated with the environment,
their windows are not very big, so drag-n-drop is easier and is more
used. But drag-n-drop is not what makes this friendly.

 Anyway, I think a nice installer's interface could very well compete
with that system in terms of ease of use. People are already familiar
with iTunes and other music repos apps, so it could very well work for
packages.

> This brings me to another important issue: On many users the wonders of
> the contextual dialogue within the app-browser to remove applications or
> add them to 'favorites' is completely lost. One will find again and
> again, reviewers and blog-writers complaining ' the main menu only has
> six entries, and it's all apps that I don't use'.
>
> *snip* *mockup* *snip*

 Yep, that's an issue, and your mockup solves it nicely. You should
definitively open some bug report on that
(https://bugzilla.novell.com/).

 What could be confusing about the mockup is that the Actions items
looks like the Group ones, so you get the feeling they are buttons... If
Actions was aligned to the bottom that might be enough to make it clear
they are distinct (and they really should be aligned to the bottom
anyway since they are not that frequently used to deserve such a visible
spot).

 And to make it clear that the user can drag things there, maybe they
should have a sunken shadow. Actually, I think you could just have the
three sunken medium-size icons, no labels. And the user would get a
tooltip on mouse hover.

 Something important about uninstall is that the user shouldn't care about
dependencies. So, if it tells Skencil to uninstall, but keeps Inkspace,
Skencil should not actually be uninstalled, just hidden. (Possibly a
dialog for the user to confirm that.)

> (BTW, it would be VERY nice if uninstalling from the
> app-browser wouldn't pop up the package-manager to (unncecessarily)
> refresh repositories and ask for user-action. A quiet uninstall without
> frills after one confirmation would be ideal.)
 Right, though I'd say the popups madness ought to be addressed
first. ;)

> >  Here's a mockup of mine:
> > http://www.alunos.dcc.fc.up.pt/~c0607045/trash/yast/ricado-split-use-cases.svg
> >
> >  We split completely the user cases. The other pool would be to revert
> > changes. (Surely, we want to have a one-pool option to keep those guys
> > happy. And of course, the tiles view.) I wonder whether this makes sense
> > or if there are use cases, where everything should be together.
>
> It does look like a mix of the current two-columns-approach and YaST-QT.
> Two columns made sense for the 'installed/not installed'-analogy, I have
> troubles finding an analogy here.

 The revert column would have a fixed size... But okay, simple check
marks should make more sense.

>  Could we not get rid of one column? I
> must say that for advanced package-management I personally prefer
> SmartPM's view - installed and uninstalled packages, and different
> versions, simply side-by-side. Such a look could perhaps be integrated
> as 'expert/packages-view' into an app-browser-like manager, too? 
 SmartPM is similar to yast-qt in this aspect, right?

 I like it more task oriented... Maybe we could have both worlds;
display all packages in the different actions. The package would just be
either enabled/disabled depending whether the action applies or not. :/

CU,
 Ricardo


-- 
To unsubscribe, e-mail: opensuse-gnome+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-gnome+help@xxxxxxxxxxxx