Re: Linux and application installing
While showing the user "applications" instead of packages might be a good idea for several use cases I think this approach misses the point here. The questions for redesigning the Updater dialog should be: What's the user supposed to decide and what information does he need to do so? The answer in 99.9% of the cases is either "Run the update now" or "Run the update later". Deselecting any packages for update is a rare corner case. If it would be an important case yum - or may be even rpm would/should/must support version pinning to ignore updates of given packages for ever (it's getting off topic here). So there are two things for the user to weight up: The cost of the update and how urgent it is. To decide how urgent the updates are it is probably sufficient to tell the use the most urgent level (bugfix, security fix, enhancement). Giving the number of updates and download size per level allows more fine grained decisions and whether further looking into the details might be worth. The cost is basically the time, CPU, IO and bandwidth used. It is hard to give a good estimation about that, but just giving the download size (as a sum) should be good enough for us. Additionally the connectivity is important but not so easy to find out automatically. May be the user knows how he hooked up his computer - may be we remember the connectivity we had while downloading the meta data. Another important cost is interruption of service. So you should state whether a reboot or new login is required or which (currently running) applications will require a restart. So I would suggest an UI that gives a summery (Didn't we already have that in the past?) and offers 3 buttons: [Show/Hide Details] [Do not install updates now] [Install updates now] The first being a toggle button hiding/showing the current or to be list of updates or to be updated applications. Btw. sorting the updates by severity and offer a check box by severity (may be using a tree view instead of a list) may be another improvement. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 09/15/2010 04:38 PM, FlorianFesti wrote: > [Show/Hide Details] Btw: If you do that right and save the state of this button in the user's home you can make beginners and power users happy without much UI overhead. Power users would just have to push the button once to get their beloved interface back. Beginners have the chance to push it twice to learn that they really don't care. Guess it won't get better than that... Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 09/16/2010 09:05 PM, Colin Walters wrote: > (I don't have a strong opinion on whether the data format is RPM or > repodata myself; maybe just a slight preference for the latter; the > most important thing in my mind is to come to rough consensus and > working code, and actually ship something) It is probably easier to add that information directly to the packages. Rpmbuild could inspect *.desktop file and produce Provides: from it or add a new tag. That way there'd be a distribution independent format and way to retrieve this data and the Fedora infrastructure doesn't have to deal with the generation on its own. Can someone please elaborate a bit what pieces of information are really needed? The .desktop files as a whole? Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 09/17/2010 05:05 PM, Richard Hughes wrote: > On 17 September 2010 13:36, Arthur Pemberton wrote: >> Wouldn't that require the tool to download every package just to get >> the embedded information. > Yes, that's what my generator tool does. Of course, it only downloads > the packages that contain .desktop files (which we can tell from the > metadata) otherwise that would take more than ages. > > That could actually even done by createrepo - just in case it runs too fast already. It has to open all the binary rpms anyway and could just sweep through the file list and then - if there are files of interest - open the payload and unpack the content of the desktop files. I have some basic support for reading the pkg content in MY generator tool. May be that can go into the rpm Python binding or some of the yum helper modules. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Linux and application installing - a second perspective
Sorry, for showing up late at the party. This mail should have been part of Richard's thread with the same topic but things took a while until they were ready enough to be presented here. There is a long history of package installers in Fedora (and it's predecessors). It feels like roughly every two or three years we switched to a new application for installing, updating and removing packages - most of them introduced as the default tool way before they reached the necessary maturity and being replaced before fulfilling the promises made on introduction. I find it pretty hard to see any progress in that area over the last decade - expect the current updater; it's actually the first one that really works. What has made the situation much worse is the insane (sorry) growth of Fedora during the last years. It puts every part of the distribution dealing with packages under stress. Design decisions that might have been reasonable (or at least not too relevant) turn out to be pretty stupid or at least insufficient. This is not only true for algorithms and data structures but also for user interfaces. Splitting the distribution up into a couple of groups and list the packages belonging to each group might have been a good idea while the distribution was still only 800 packages. Right now showing a list of packages won't work reasonably for the very most cases. Nevertheless this is the best we have to offer to the user right now... But just blaming PackageKit (or any of the other package installers) for not just being better is not really helping. They can only operate on the data available. So I tried getting an overview of what we already got and to find out how it could be used. As the number of packages and applications (about 20k and 2k) is too big for manual processing it was pretty clear I had to write a little application for viewing and browsing the meta data sets and the matching packages. It was also clear that such an application would be pretty close to a new package installer and I really didn't wanted to be the next one to replace the installer of the year by it's even worse successor - especially knowing that someone else will do that in a not too distant future anyway. So I wrote a little GUI program[1] with several things intentionally unimplemented. Most other stuff is just a mock up implementation short circuiting the normal data flows through Fedora infrastructure and the repositories. So it's just above 300 lines and tries hard to look harmless. Otoh it is also a mock up of a UI for browsing packages that - while not refined enough to be used in PK (or it's successor) as is - I consider a step to gain back control over the huge number of packages and applications. IMHO the goal is to allow the user filter down the list of packages of interest to one, at most three dozen packages. Typing in the right package name does not count as a solution! Back to the application itself: You can add tags/groups to the filter by double clicking on the entries in the treeview on the left or by entering a search term into the text field on top. To remove them from the filter just press the button representing it on the row above the result list. The numbers behind the tags are the number of packages in the current result and total. Starting the first time can take a while for downloading the repo data. The meta data it currently operates are: 1) Comps groups. Not even used by PK to the full extend. Nevertheless several groups are huge with over 100 packages (winner being "Games" with over 300). Sorry, 100 packages in one list view doesn't work for me. 2) PkgTags which are in the PackageDB but look like being in large parts autogenerated from the menu entry tags that are used to sort the applications into the menu entries. They look pretty outdated or incomplete, though. See [2] for a repo containing the data and the implementation in yum. You'll need the repo enabled to see those tags! PackageDB also allows to add tags by hand. Probably a good thing. Mixing them with auto generated ones - probably not. 3) Data found in the *.desktop files representing entries in the application menu. While I extracted them on my own the data set is basically the same as that used in PK. But here they are used to tag/group packages and not to make packages look more beautiful and less confusing - what seems to be the goal of the recent development in PK. There are two ways this data is used: 3.1) Attaching tags used to sort the applications into the menu to the packages. These allow different "views" on the packages, sorting them by different tags/aspects. Making a the tags available allows creating queries that are more narrow that the application menu itself. 3.2) Use the application menu (with additional *-menus packages) to sort the packages in. This is more easy to use but not as powerful as the tags. Every package/application is located where the user
Re: Linux and application installing - a second perspective
On 09/23/2010 06:09 PM, Bruno Wolff III wrote: > On Thu, Sep 23, 2010 at 15:51:37 +0200, >FlorianFesti wrote: >> 1) Comps groups. Not even used by PK to the full extend. Nevertheless >> several groups are huge with over 100 packages (winner being "Games" >> with over 300). Sorry, 100 packages in one list view doesn't work for me. > Games have meta data that allows them to be further subdivided in their > desktop files. This should up in the part of you app that takes that > data into account. > If you read on you'll see that I actually use exactly this data. When showing the packages in the Application menu tree the games are already subdivided. Try it out and see yourself! Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing - screen shots of UI mock up
Ok, I made some screen shots. It's a bit easier to understand if you see it actually working. They should still give you a idea. Looking at the PackageDB tags, filtering for the "Office" and "Qt" tags: http://fedorapeople.org/~ffesti/screenshots/PackageDBTags.gif Filtering for the "GNOME" menu tag and looking at the results found with the "Audio" tag. http://fedorapeople.org/~ffesti/screenshots/MenuTags.gif Still filtering for "GNOME" but looking at the stripped down Applications menu, showing the results in Applications->Games->Board: http://fedorapeople.org/~ffesti/screenshots/Applications.gif Searching for "circuit" and look at the results found in the comps groups - wondering why we found some games: http://fedorapeople.org/~ffesti/screenshots/Search.gif Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On 10/05/2010 10:35 AM, Richard Hughes wrote: > No, I think what we need to do is to teach GPM how to turn off the > internal panel when docked and with the lid closed. The only missing > piece is for the kernel to export some kind of sysfs boolean saying > "in-dock". From talks with mjg59, detecting a dock is pretty hard. Sorry for my may be naive question: Why do we need to know if we are docked or not. Isn't there exactly the same situation if the external Monitor is directly connected to the laptop? If there is an external monitor and the lid is closed don't we want to switch off the display regardless whether there is a docking station involved or not? Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On 10/05/2010 03:15 PM, Nathaniel McCallum wrote: > If the lid is open, both output should be enabled by default (you are > free to manually disable one). If the lid is closed on battery power > the system should suspend (unless you choose otherwise in GPM prefs). > I wonder if there are latops that can be booted with lid closed and that make a subtle sematic difference between the lid was just being closed and is lid was already closed when we booted up. Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Showing packages installed on the system: show-installed
Hi everyone! During Richard Hughes' "Linux and application installing" thread[1] I had argued that just showing a list of packages won't cut it for most use cases around package handling. One of those use cases is showing which packages are installed on a system. For getting an idea about a machine a list of about 1500 packages is not really helping. In a side note I came up with the following idea [2]: > Generate a packages section as found in a kickstart file and showthis as > "Installed Packages". Remove all packages required by others and reduce > packages to groups whenever possible. May be even to a group with some > packages missing. Minimizing the number of lines should get pretty good > results." This is now implemented as "show-installed" which is part of yum-utils-1.1.29-2.fc15 found in Fedora devel. It supports three different output formats: kickstart %packages, yum cli and human readable. It also supports a number of options for controlling the output and whether it should consider excludes to make use of even more groups. See "man show-installed" or "show-installed --help" for details. As the script also takes a list of package names it can be used to create a package list on/for a newer release. As it has not seen too many real world use suggestions and bug reports are welcome. While show-installed might be a useful tool I primarily see it as part of the package handing UI discussion. Tools like gpk-application or yumex could offer this as a condensed view. May be even the list of available packages could presented like this. I separated the logic from the actual formatting code so it should be easy to toy around with the Python class or to translate the pretty simple algorithm to another programming language. Feel free to ask me on #yum if you have question or need help with that. Florian [1] http://lists.fedoraproject.org/pipermail/devel/2010-September/thread.html#142599 [2] http://lists.fedoraproject.org/pipermail/devel/2010-September/143349.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
App Installer Miniconf
As you already may have read there was a cross distro meeting in Nürnberg about a shared app installer effort. For me - who didn't even know about the meeting two weeks in advance - the main concern was what kind of people would be there and how we ever could get to an agreement on anything. And even if we did how could this ever be transformed into something working. It turned out that the people from the different distribution have pretty much the same mind set and a very fine sense on what they don't want to have forced onto their own and onto everybody elses' distribution. So although there is a lot of actual (meta) data that we all considerd a) difficult to create and b) worth sharing we all very quickly came to a - not even spoken out - agreement not to share any actual data or infrastructure. Instead shared data should either live upstream or every one has it's own copy and we think - and talk - about sharing or syncing later. So for now this is basically about sharing code and formats. The second thing that became clear very soon was that if the whole project should come to life soon it needs to be build out of existing part. Sure there would be a lot of glue missing but writing things from scratch would not get us anywhere. Using a existing projects and infrastructure hopefully would make it easier to get the overall plan accepted. As a result each distribution is contributing a few pieces. So the overall plan has 4 parts: Static meta data that can be shiped within the repository and also works offline from a CD/DVD. This is not completely unlike the optional packages in comps but with a bit more data about the applications. The idea is to autocreate this data from desktop files - which may be enhanced a bit. We'll see how far this really works and if we need to add manually created data or not. So there is a mid term perspective to also add non GUI stuff to this but we'll go for desktop apps only in the first step. For fancy new things like comments and ratings there will be servers where this data is stored and can be maintained by a user community online. There already is an API that covers this. The Social Desktop API "Open Collaboration Server" (OCS) has a module for "content" - applications in our case. How exactly the OCS will be used is still to be determined. This is really not my area of expertise. As far as I understood you can have per user account and friends and suggestions and what ever or just comments and ratings. This is probably up to whoever is going to actually run the service. Screen shots will be stored on a different (http) server but linked from the OCS. As there already is screenshots.debian.net we might use that (via proxy) for the start before we setup something like that on our own. (Elite diplomats looking for a challenge can also go for an agreement for a shared server.) These three data sources are then brought together within the client. The idea is that as there are different repositories there also are different OCS servers - either providing information for different applications or different information on the same applications. This way comments or ratings could be shared between distributions without any of them loosing control over their own data. Details being determined by the per distro or even per user configuration. The client can be an GUI application or a server offering a web interface (IIRC one of the Mageia guys said he's going to write one). To get a GUI client there will be some steroids added to the Ubuntu Software Center which already has a similar functionality using it's own data formats and protocols. Ok, this is the overall plan. There already is an announcement containing more technical details and further pointers: http://lists.freedesktop.org/archives/distributions/2011-January/000411.html Be aware that there are still a lot of people to convince (including you) and technical issues to solve to really make that happen. Take the technical details with a grain of salt. Also there will need to get more people involved. I'll give a talk on the upcoming FudCon to help with that. Florian PS: There are two side project that I personally consider as interesting: The first is a way to match packages between different distros. I could imagine that the package db offers links to the specs and patches of the other distributions. May be someone in this area wants to pick that up. Second thing may be adapting the Debian tagging system (Debtags) for Fedora. With the package matching in place we could start with a quite big data set instead of zero. But there probably also is quite some work to do - and be it just porting their tools from dpkg to rpm... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
