Insufficiencies in Karmic's battery behavior
Karmic's adoption of DeviceKit-Power and the latest Gnome-Power-Manager has changed the way the GUI reports remaining battery time. The old method built a profile of how long, on average, it took for each percentage point of the battery to be depleted. From that, it could estimate fairly accurately, given the user's average use pattern, how long the battery would last. This was a huge step up from the old way of reporting the battery remaining time reported by the BIOS, which didn't take battery charge/discharge profiles into account and relied on current power draw measurements, leading to unstable results. Now, we've gone back. We do profile the battery in terms of how far off it is from the BIOS-reported remaining time, but this brings us back to the problem with traditional BIOS-reported remaining times: the reported time remaining can change drastically based on current usage. While adapting to what the user seems to be doing can be a good thing, this method leads to things like 3-minute YouTube videos or slightly long compression operations causing a large drop in estimated battery time when in fact it really won't have much of an impact in the long run, and the estimated time goes back up immediately after the operation is over. In my experience, the Jaunty behavior of profiling the battery and ignoring brief spikes in power usage produced a much more useful, accurate estimation of the remaining battery life. The current behavior leads to an almost completely useless metric -- I've attached two screenshots taken during normal usage that illustrate fairly vividly the problem with Karmic's behavior: a) the estimated time should always go down, never go up, and b) it should be a smooth line. Note that in the screenshots, the line goes up and down, in one case dropping down by an entire hour and then going back up. http://img188.yfrog.com/img188/6031/screenshotpowerstatisti.png http://img188.yfrog.com/img188/2706/screenshotpowerstatistiy.png -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Install Wizard 'Looks Too Complicated'
I'm not sure if I like this proposal -- I believe splitting things up into small steps makes it easier on the user. For one thing, the first questions we ask are the language and the keyboard layout, which are essential to the user's understanding of the rest of the installer. Many users won't set their language at the CD bootloader because there's a timeout on it anyway. By making it all one step, non-English speakers may have trouble figuring out how to change the language, for one thing. Also, having side-effects like having the keyboard layout change depending on the selected language, in one screen of the dialog, may be confusing and unfriendly. In addition, I believe dropdowns for long lists such as languages should be avoided -- they're less intuitive to scroll through, and more transitory. Selecting the language for your operating system is a BIG step -- and deserves a screen to itself, with appropriate widgets, and setting the language first on its own screen will create a more seamless transition to the installer in the language of the user's choice. The other problem is that partitioning is an inherently confusing operation for most users. By having a screen dedicated to it with visual cues like the ones we have already, such as showing a bar chart with amounts of space allocated to different operating systems, a user who may not know what exactly a partition is will come to an understanding of what it means. Splitting the installer into several steps leads to a less overwhelming first impression of the installer. 2009/12/1 Ryan Dwyer > I'm picturing a single dialog with an overview of the current values and > options to change them. The fields I've marked as buttons would have the > current value as the button text so the user only has to click the value to > change it. > > Language: [English (US)] (this would be a droplist) > Location: [New York, United States] (this would be a button that opens the > map) > Keyboard: [USA] (droplist) > Partition: [Use unpartitioned space (120GB)] (button which opens advanced > partitioning dialog) > User details: [Not yet provided] (button to open dialog for full name, > username and password) > [_] Log in automatically (that's a checkbox) > [_] Encrypt home directory > Computer name: [Not yet provided] (button to open dialog) > > [Quit] [Install] > > Default for language is determined by what they chose after entering the > CD. > Default for location can be determined by IP geolocation if they are set up > with local DHCP and have internet access. > Default for keyboard can be USA. > Default for partition can be determined based on whether another OS exists, > size of unallocated partitions and whether there are any completely empty > partitions. "Not yet provided" if the user needs to manually choose a > partition to erase. > No default for user details. > Default for log in automatically: Unchecked. > Default for encrypt home directory: Unchecked. > No default for computer name. > > The button text for user details could change to something like [Fred Smith > (fredsmith)] after the user has entered their info. > > This would make it faster to install as you can skip sections that already > have correct defaults. It also gives the user an immediate overview of what > needs to be configured. > > And the concept of having the installer automatically determine where you > are is completely awesome. If the service is hosted by Canonical it may give > a clue as to how many installations are being done. > > -Ryan > > On Tue, Dec 1, 2009 at 7:13 PM, Mohammed Bassit wrote: > >> On Mon, 2009-11-30 at 21:54 -0400, Derek Broughton wrote: >> > James Westby wrote: >> > >> > > On Mon Nov 30 13:47:34 -0500 2009 John Moser wrote: >> > >> List some not-silly reasons. >> > > >> > > You're serious? Ok. >> > > >> > > * Takes a long time to crack any password that's not in the >> dictionary >> > > and >> > > more than a few characters long. >> > > * Rainbow tables would be too large to fit on the CD. >> > >> > Actually, that's probably the best reason right there. >> > >> > -- >> > derek >> > >> > >> >> Can anyone tell me why nobody actually cares about what Conrad Knauer >> was talking about in the first place ? >> >> How in did a discussion about making the Ubuntu installer look >> simpler, become a debate about whether some password or network security >> mechanism (or whatever) is crackable or not ? >> >> Focus people, any real thoughts about simplifying the Installer ? >> >> For me the Ubuntu install process doesn't get any easier, but I have to >> agree that it still LOOKS (as in what you see, not what you actually >> get) a bit complicated. And I also agree that hiding some of the >> options, people usually don't change, can help. >> >> Any thoughts ? >> >> >> P.S: no rumble about cracking password or I'll send the tooth fairy to >> hunt you down :) >> >> >> >> -- >> Ubuntu-devel-discuss mailing list >> Ubuntu-devel-discuss@lists.ubuntu.com >> Modify
Re: Install Wizard 'Looks Too Complicated'
In fact, the Ubuntu installer used to use an embedded GParted editing box. I much preferred that to the current setup. On Tue, Dec 1, 2009 at 1:29 PM, Shentino wrote: > One of my pet peeves with the installer is how long it takes to detect the > partitioning...and redetect it every...single...operation...so...slowly. > > My suggestion is that GParted be used to handle this. In fact I often use > that to do the partitioning BEFORE I do the installer because I don't want > to slog through it. > > On Tue, Dec 1, 2009 at 8:40 AM, John McCabe-Dansted wrote: > >> On Wed, Dec 2, 2009 at 12:06 AM, Daniel Hollocher >> wrote: >> > password. Any sort of password automation would simplify the >> > situation for a few people at the expense of making it more >> > complicated for the rest of us. The level of encryption doesn't seem >> > to matter. >> >> OK. The issue where we want to migrate multiple users for whom the >> admin does not know the password may be better handled by the >> Migration Assistant. >> https://wiki.ubuntu.com/MigrationAssistant/Karmic >> >> -- >> John C. McCabe-Dansted >> >> -- >> Ubuntu-devel-discuss mailing list >> Ubuntu-devel-discuss@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss >> > > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Solang or Shotwell vs. F-Spot for Lucid
The bizarrely obnoxious bit about F-Spot import is that it copies everything to your photos folder BEFORE you actually accept the import. Then, if you don't accept it, it deletes them... which is just Bad Behavior. On Tue, Dec 8, 2009 at 4:57 AM, Sebastien Bacher wrote: > Le lundi 07 décembre 2009 à 21:24 -0500, Danny Piccirillo a écrit : > > Before too much effort is invested into making F-Spot good enough to > > meet all of the needs outlined at the UDS Default App Selection > > session, i thought i should bring up Solang and Shotwell to see if it > > might be worth including instead of F-Spot in Lucid, or if it's too > > late, in Lucid +1. > > Hi, > > Thank you for raising the topic. What effort are you speaking about > exactly there though? The only change we needed was the edit options to > be available in view mode basically and upstream already fixed that one. > > > GTumb has been discussed, but it doesn't seem to deliver the goods. > > Why not? Somebody pointed recently a post about gthumb, the code has > been refactored recently apparently and the new version looks quite good > > > Solang is new, yet it's developed quickly and is showing a lot of > > promise. Shotwell might also be a contender worth discussing, but i am > > unfamiliar with it. Hopefully someone else has some insights as to how > > Shotwell compares to Solang and F-Spot. > > We have something not perfect right now but working ok for common use, > it seems risky to want to change to some new codebase in a lts cycle > especially when we don't know how reliable upstream is and when those > softwares have not been exposed to real user testing and feedback yet. > > > * A major issue with F-Spot that Solang doesn't have is that you > > have to move images to import them into the library. > > Do you? The import dialog has a checkbox about copy that you can uncheck > > > * F-Spot is much more resource intensive than Solang > > Do you have numbers on that? > > > Solang, Shotwell, and F-Spot are all fine image managers/organizers, > > but the current plan is to work on F-Spot to get it to meet the > > following needs: > > * Quickly viewing images by folder [currently handled by EOG] > > * Solang and F-Spot both have view-modes but still > > require importing the image. Shotwell might not. > > No, the f-spot --view mode doesn't require to import anything... > > > * Editing images without importing (Shotwell does this) > > * Rotating [currently handled by EOG] > > * Red-eye removal [currently handled by GIMP] > > * Cropping [currently handled by GIMP] > > those are done by f-spot as well > > > Although the interface has been cleaned up, it just feels heavy. > > The comment there is about the user interface or the opening speed, > reactivity to actions, ...? > > > It's worth reconsidering how much work should be put in to F-Spot when > > other projects seem to be progressing faster. If this much work is > > going to be invested as it is, we should consider whether it might be > > better to focus on Solang instead. Shotwell might already meet many of > > these needs, and need significantly less work. > > We don't put too many efforts in f-spot, the work is done mostly by > upstream and the packaging is done mostly by Debian, we just try to > issues reported on launchpad and work with upstream on the ones we > consider worth trying to fix for the next version. > > Where did you get that the other projects are moving faster too? They > might have extra work to put to catch up with what f-spot does now. The > timeline view is rather nice to use and f-spot has quite some other > options. > > Did anybody looked at how those other software handle exporting to > flick, picasa or other web services? > > > Please look into both Solang and Shotwell and post your thoughts. > > Thanks! > > I will let other people comment on those, but changing a known codebase > for new project in a lts cycle doesn't seem a good move from there > > > > Sebastien Bacher > > > > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Solang or Shotwell vs. F-Spot for Lucid
Actually, it seems to start importing as soon as you select a folder... then the dialog remains locked until it reads all the files in it. 2009/12/8 caleb.marcus+u-d-d > > The bizarrely obnoxious bit about F-Spot import is that it copies > everything to your photos folder BEFORE you actually accept the import. > Then, if you don't accept it, it deletes them... which is just Bad Behavior. > > On Tue, Dec 8, 2009 at 4:57 AM, Sebastien Bacher wrote: > >> Le lundi 07 décembre 2009 à 21:24 -0500, Danny Piccirillo a écrit : >> > Before too much effort is invested into making F-Spot good enough to >> > meet all of the needs outlined at the UDS Default App Selection >> > session, i thought i should bring up Solang and Shotwell to see if it >> > might be worth including instead of F-Spot in Lucid, or if it's too >> > late, in Lucid +1. >> >> Hi, >> >> Thank you for raising the topic. What effort are you speaking about >> exactly there though? The only change we needed was the edit options to >> be available in view mode basically and upstream already fixed that one. >> >> > GTumb has been discussed, but it doesn't seem to deliver the goods. >> >> Why not? Somebody pointed recently a post about gthumb, the code has >> been refactored recently apparently and the new version looks quite good >> >> > Solang is new, yet it's developed quickly and is showing a lot of >> > promise. Shotwell might also be a contender worth discussing, but i am >> > unfamiliar with it. Hopefully someone else has some insights as to how >> > Shotwell compares to Solang and F-Spot. >> >> We have something not perfect right now but working ok for common use, >> it seems risky to want to change to some new codebase in a lts cycle >> especially when we don't know how reliable upstream is and when those >> softwares have not been exposed to real user testing and feedback yet. >> >> > * A major issue with F-Spot that Solang doesn't have is that you >> > have to move images to import them into the library. >> >> Do you? The import dialog has a checkbox about copy that you can uncheck >> >> > * F-Spot is much more resource intensive than Solang >> >> Do you have numbers on that? >> >> > Solang, Shotwell, and F-Spot are all fine image managers/organizers, >> > but the current plan is to work on F-Spot to get it to meet the >> > following needs: >> > * Quickly viewing images by folder [currently handled by EOG] >> > * Solang and F-Spot both have view-modes but still >> > require importing the image. Shotwell might not. >> >> No, the f-spot --view mode doesn't require to import anything... >> >> > * Editing images without importing (Shotwell does this) >> > * Rotating [currently handled by EOG] >> > * Red-eye removal [currently handled by GIMP] >> > * Cropping [currently handled by GIMP] >> >> those are done by f-spot as well >> >> > Although the interface has been cleaned up, it just feels heavy. >> >> The comment there is about the user interface or the opening speed, >> reactivity to actions, ...? >> >> > It's worth reconsidering how much work should be put in to F-Spot when >> > other projects seem to be progressing faster. If this much work is >> > going to be invested as it is, we should consider whether it might be >> > better to focus on Solang instead. Shotwell might already meet many of >> > these needs, and need significantly less work. >> >> We don't put too many efforts in f-spot, the work is done mostly by >> upstream and the packaging is done mostly by Debian, we just try to >> issues reported on launchpad and work with upstream on the ones we >> consider worth trying to fix for the next version. >> >> Where did you get that the other projects are moving faster too? They >> might have extra work to put to catch up with what f-spot does now. The >> timeline view is rather nice to use and f-spot has quite some other >> options. >> >> Did anybody looked at how those other software handle exporting to >> flick, picasa or other web services? >> >> > Please look into both Solang and Shotwell and post your thoughts. >> > Thanks! >> >> I will let other people comment on those, but changing a known codebase >> for new project in a lts cycle doesn't seem a good move from there >> >> >> >> Sebastien Bacher >> >> >> >> >> -- >> Ubuntu-devel-discuss mailing list >> Ubuntu-devel-discuss@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss >> > > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Solang or Shotwell vs. F-Spot for Lucid
nautilus-image-converter provides some very useful tools, but it does feel a bit kludgy. For a simple viewer, I like EOG -- its UI is simple, and just what's needed. However, if it had a few more very basic editing tools, I'd be happy. 2009/12/12 Otto Kekäläinen > > > Solang, Shotwell, and F-Spot are all fine image managers/organizers, > > but the current plan is to work on F-Spot to get it to meet the > > following needs: > > * Quickly viewing images by folder [currently handled by EOG] > > * Solang and F-Spot both have view-modes but still > > require importing the image. Shotwell might not. > > * Editing images without importing (Shotwell does this) > > * Rotating [currently handled by EOG] > > * Red-eye removal [currently handled by GIMP] > > * Cropping [currently handled by GIMP] > > * optional: Annotating (like making lolcat) [currently > > handled by GIMP] > > * optional: Painting on it [currently handled by GIMP] > > Resizing and saving the file in another file format are also common > in-folder image manipulation tasks. > > Personally I prefer Gthumb over EOG or F-Spots view-mode, since it is > fast, easy to use and has enough features. If I had the power, I'd > replace EOG with Gthumb and make Gthumb the default program associated > to all image file types. Current situation sucks. Even Windows XP's > in-folder image manipulation is better.. > > Shotwell looks nice, but I'm a bit sceptic about new software and how > mature they are. > > > > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Backup application in default install
Yes, yes, yes. I fully agree. Currently I use an anacron job running rdiff-backup, but this is CLEARLY not right for non-techie users. I stopped using Simple Backup ages ago... it was really deficient. For one thing, its incremental backups had to be restored like so: 1) restore last full backup 2) restore next incremental 3) rinse and repeat until you're restored to the right date. On Wed, Jan 27, 2010 at 3:14 AM, Aaron Whitehouse wrote: > Hello all, > > According to: > https://help.ubuntu.com/community/BackupYourSystem > "Backup is essential." However, no tool to backup the system is > available in the default installation. > > By contrast, Mandrake (as it was then) included an excellent simple > option built-in when I used it around five years ago: > http://wiki.mandriva.com/en/Docs/Howto/Drakbackup > > I have just read through all of the Wiki pages I could find on the topic: > > https://wiki.ubuntu.com/Home?action=fullsearch&from=0&context=180&value=backup > and it seems that each release brings a new spec to include a backup > program by default and, each release, people write out the use-cases, > set out the alternative backup programs available and argue about > missing features. Then the release happens and no backup program is > installed by default. > > Simple-backup-suite appears to be the most officially-sanctioned backup > solution for the simple use-case and I understand that it was designed > for Ubuntu (during the 2005 GSoC) for this purpose. Unfortunately, the > project does not seem at all maintained, which makes it unlikely that > bugs will be fixed or features added. The facility to restore backups is > also pretty primitive (as far as I can tell), requiring the user to > search through each backup file one-by-one to find the correct > version(s) of a file, rather than having any master indexes. > > I would really like to see Canonical/Ubuntu officially support this > crucial part of the desktop. There are so many choices for backup, each > with subtle differences, that having a recommendation would be very > valuable to all but the most skilled backup experts. Canonical/Ubuntu > supporting one backup program would also no-doubt encourage further > activity in that program. Finally, there could be excellent > (revenue-generating?) opportunities to offer an option to backup to > Ubuntu One etc. > > I understand and appreciate the differences between the backup programs > (some using inotify and hard-links, some using diffs and archive files > etc.), but I feel that it is one of those cases where it is more > important to encourage the user to backup the system in any of the > available ways than to keep arguing about the most technically-correct > approach. > > Regards, > > Aaron > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
