synaptic-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fwd: Re: [Synaptic-devel] synaptic-0.52-17 interface]


From: Michael Vogt
Subject: Re: [Fwd: Re: [Synaptic-devel] synaptic-0.52-17 interface]
Date: Thu, 29 Jul 2004 12:30:01 +0200
User-agent: Mutt/1.5.6+20040523i

On Thu, Jul 29, 2004 at 02:02:15AM -0400, sashko wrote:
> on 07/26/04 10:25 Sebastian Heinlein wrote:
> >>Example:
> >>1) I want "new in repository" packages to be sorted into sections. Can I 
> >>do that? - The right answer is NO.
> >As I have already said before, the main focus is not on pure providing
> >of functionality. Why do you want to accomplish this? In which task?
> I thought it is obvious.

This is a common mistake :) Developer think all the time that certain
stuff is obvious for the user and learn the hard way that it is not.

> Look, today I added three more repositories to my sources.list and that 
> brought me another 300 pieces of software. However right now I'm 
> absolutely not interested in super-duper-extra-special CPAN-Perl 
> libraries, network sniffers, and tons of new dev-libraries mixed with 
> all possible kinds of kernel modules. Instead of that I'd like to see 
> what they offer for multimedia and office. That was pretty simple with 
> the version prior to 0.5 (I guess). But now I can spend 2 hours 
> "fishing" the packages I'm interested in.
> And that is just because filters "New in archive" and "section" are in 
> the same bunch and not applicable simultaneously.

This is a nice example. I agree that we need something here to
organize the tree according to sections (or components). 

If you know what section you are looking for, you can just select this
section and then sort the list for the status (click on the small
"S"). New packages will be on top of the list.

If you want to see packages that are new and don't belong to a certain
section, you can define a filter that excludes e.g. the section "lib"
and has the status "new". 

Another options would be going back to a tree. But I don't think that
a tree works well for the massive amount of packages we have to deal
with in debian (~15000). Some sections like libraries are 1500
packages big. You can easily get lost in there :)

A third option would be a new (optional) column in the package list
with the section. We can make it sortable and it's possible to easily
skip sections one is not interessted in. 

I thought about a new column (optional) for the component a packages
is in too (component for debian is "main", "contrib", "non-free"; for
suse: "base", "suser-rbos", "gnome2" etc).

I hope one of the above ideas suits your needs, if you have a new
idea, pleasae tell me.

> The same problem I meet with "Upgradeable" packages. I don't want to 
> upgrade all dev libraries because I know definitely that there is some 
> kind of software which is tied to certain versions of libs, and I need 
> that software. But I still would like to update the rest of packages...

You could define a filter that displays everything that is upgradable
but not in section "libs". You could browse the sections with the list
sorted for status. Basicly every idea above should work.

> Sebastian,  the question is not about the editor. I can do that in vi 
> easily. But I have to edit my sources.list MANUALLY. Then, what is 
> gui-frontend for??? I usually add all new repositories to the end of the 
> file, and believe me - to click on radiobutton with correct version was 
> much simpler than to rearrange the address of repositories.

We are working on a improved dialog for the sources.list. It will be
possible to rearrange the order of the sources.list lines with nice
buttons. Sebastian send me the glade file already and they look
terrific. The problem is just that we don't have enough developers and
not enough time. Help is welcome though :) The sources.list editor
update is a perfect nice lilttle project for someone who wants to get
started.
 
> Oh, yeah. I've noticed it. Main menu-->Package-->Force version, it opens 
> additional dialog window which contains ONE drop-down box and the OK 
> button! That is what you call easily accessible simple interface?
> For some reason I suggest that even to have that drop-down box on 
> "info"-panel would be more obvious.

We can't include it into the properties window of the package for
technical reasons. This needs to be modal (you can't do anything until
the dialog closes), but the package propties window is not modal (it
is updated on every click). Do you think a shortcut to the "Force
version" menu item would help?
 
> 3) Sometimes on my home machine I'm just browsing through "not 
> installed" expecting to find something interesting which I've missed 
> before. Obviously I again want it to be split into section, just because 
> there are section which I'm not interested at all. I believe that is 
> what the normal user usually would do.

So it looks like we have a common pattern here. You can achieve it by
sorting by version (click two times on it). Then the uninstalled
packages are on top of the list. But it's pretty similar to the above
tasks. So I would be interessted what solution you like the most.

> 4) I dont know exact name of the package I need, but I remember that has 
> something to do with phyton. Before I was able to type "phyton-" in 
> search box and clicking "next" button few times, get to the searched 
> rpm. Now it is posible. Alphabet sorting is completely useless if you 
> have 4500 and more packages .
> The same is if accidentally user decides to look for some xmms plug in? 
> It was so simple, just type "xmms-" and here you are! And what we have 
> now instead?

We have the "search" button in the taskbar. A search is faster now
than it was before. But if you are looking for a search in the current
package list, this is a regression, I agree. You can search with
"CTRL-s", but it's really a bit hackish (opens a small box in the
middle of the synaptic window where you can type in your querry). We
tried various stuff like a instant filter search but it didn't worked
very well. I think the gtk hackers are working on a instant search for
the treeview. You just start typing and the cursor jumps to the
package. But this is gtk2.6 stuff (if at all).

> Now that "properties" window which I can call via right-click. Right now 
> I'm working at 17" monitor. That additional window hides quarter of 
> initial synaptic window. If I click in a list of packages - main window 
> pops-up and covers Properties-window. It is just impossible to see them 
> both clearly in the same time!

Yeah, this is a very common complain. Personally I'm still unusre
about it. I wonder what information is missing and if it would be
feasible if we could put it in the current description window also
(just a thought for now). So if everybody misses the dependencies, we
could add them as text after the description. What information exactly
do you miss? Or is it just "everything" :) ?

> alright, i got you. I'll try to make myself more clear.
> 1)  As for me, to have two separate set of filters ([sections, alphabet] 
> and [new, upgradeable, installed, not installed... etc]) is a great 
> benefit because you can apply different filters  simultaneously and in 
> arbitrary combination. That makes the job of package management much 
> more convenient comfortable and fast.  (at least for me).

First of all, thanks for you mock-up. We actually had this design with
two sets of filters during the development cycle. It was abandoned
because I was constantly confused that I needed to click on two
different "All" to really get all packages. I don't think this will
work very well. But I very much agree with the idea of having two
orthogonal means to organize the packages. I think this works pretty
well most of the time with the sortable columns. But we may need to
add more (optional) columns for it. What do you think?

> 2) To keep those tabs means present very useful information about every 
> package in convenient, easily-accessible way. Personally I always want 
> to see:
> - description: just for case if i never saw that package before
> - dependencies, if half of them are in red, probably I won't try install 
> that package (now I have to wait until synaptix resolve all the 
> dependencies for me)
> - expert (that is how you call it in 0.48) - that is the third most 
> important thing

Thanks, this is interessting. I wonder if it would be feasible to put
it into the current description window as additional information. Do
you think the scrolling in this window is too much overhead?

A additonal question, does it take long before the "Mark additional
required changes" window comes up if you click on a package? Too long
to wait for it? If so, may I know what kind of machine you have? 

> 3) keep search field with those two button (<first> and <next>). That 
> was extremely useful thing in former synaptic. That "find" button cannot 
> compensate the lack of search field.

We are working on that one. Lack of time is a big problem right
now. I hope CTRL-s will help you in the meantime (use the cursor keys
to navigate in the set of matches).

> By the way. One more question. I discovered new filter called 
> "obsolete" in v 0.52. However when I'm applying it marks as obsolete 
> half of software I'm using on a regular basis. Would you be so kind to 
> explain the principle how that filter make desididion about whis 
> software is obsoletted?

You mean the "installed (obsolete)" under "Status"? This means that
this package is no longer downloadable. This happens if you
e.g. installed a package locally or if you installed it from a entry
in the sources.list that is disabled later. We may think about
renaming it to "Installed (local or obsolete)" or something like
this. 

bye,
 Michael

-- 
The first rule of holes is: when you find yourself in one, stop digging. - PJ
Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]