Re: Why Nautilus and GNOME applications use URIs?
On Thu, 2010-06-03 at 07:36 +0200, Aurélien Naldi wrote: Hi, when using Drag and Drop, nautilus switches from GIO/GVFS URI to local path, depending on the drop target (i.e. it will paste a local path if you drop to a gnome-terminal). I guess dropping on a gtk filechooser assumes that the application is using GIO. It may need some special casing for this case. On one hand, if an application is gtk-based it really should use gio, on the other hand I think at least firefox and openoffice use gtk file chooser and won't use it. For GIO-based applications, using the GIO URI is much better, but as far as I remember, several applications transform local paths into GIO URIs, so providing a local path should always work. Dragging files from nautilus and dropping on the file open dialog in OOo works for me. Ubuntu's OOo doesn't use URIs due to prior bugs and I converted it to using the local path (gvfs-fuse) which appears to work more reliably. Chris -- 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: Remove OO Draw from the default install
openoffice.org-presentation (Impress) currently depends on it. Assuming we would be keeping that on the CD it would need to be tested to see if the libraries in the draw package are needed by Impress to function, which I am pretty certain they are needed. In that case we would have to split them out into a separate package that stays on the cd for Impress, but that would make the space gained by removal very small. It could still be done if the overall effect is that we don't want users seeing the OpenOffice.org Draw icon in the menu. Also note that OpenOffice.org is a very monolithic office suite and the individual 'App' launchers really all just call the same code (soffice.bin). Each 'App' is just a particular view into that program and each 'App' depends on functionality of the other 'App's so splitting the packaging up to reduce install size has often lead to weird breakage. Its not all linkage via libraries linked at build time, there is code that is dlopened and other code that is called via a registry of sorts. So its nearly impossible to be competely certain which parts of the code are able to safely split into other packages that aren't installed by default which has led to numerous prior bugs in the various distributions that have attempted to do so. Chris On Sun, 2010-05-16 at 12:27 +0100, Shane Fagan wrote: Hey all, I forgot to mention this at the session for default app selection but can we remove Open Office Draw from the default ubuntu install? The reasons are quite obvious it just isnt any good and I dont think any of the regular users actually use it. --fagan -- 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: Remove OO Draw from the default install
On Tue, 2010-05-18 at 01:05 +0100, Shane Fagan wrote: On Mon, 2010-05-17 at 18:28 -0500, Chris Cheney wrote: openoffice.org-presentation (Impress) currently depends on it. Assuming we would be keeping that on the CD it would need to be tested to see if the libraries in the draw package are needed by Impress to function, which I am pretty certain they are needed. In that case we would have to split them out into a separate package that stays on the cd for Impress, but that would make the space gained by removal very small. It could still be done if the overall effect is that we don't want users seeing the OpenOffice.org Draw icon in the menu. Also note that OpenOffice.org is a very monolithic office suite and the individual 'App' launchers really all just call the same code (soffice.bin). Each 'App' is just a particular view into that program and each 'App' depends on functionality of the other 'App's so splitting the packaging up to reduce install size has often lead to weird breakage. Its not all linkage via libraries linked at build time, there is code that is dlopened and other code that is called via a registry of sorts. So its nearly impossible to be competely certain which parts of the code are able to safely split into other packages that aren't installed by default which has led to numerous prior bugs in the various distributions that have attempted to do so. Chris Hey Chris, So in short its not worth the time to remove it really. I really dont like open office in general but I suppose till something better comes along we will have to put up with it and its quirks. I just thought there was an easier way of splitting the office apart. --fagan It might buy us a little space but probably not too much so I would really only advise doing it if we intend the change to be just for hiding the Draw application. We might be able to actually remove it without any related crashes happening but I am pretty sure that at minimum the ability to draw items in Impress would be removed, which would probably confuse users. Chris -- 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: White-on-black terminal should be default
On Wed, 2010-03-03 at 11:40 -0500, Tom H wrote: Everybody knows that a terminal has white text on black background. Windows has a terminal like this. Mac OS X have a terminal like this. OS X's terminal is a very civilized black text on white background... True, funny enough their terminal icon shows it as white text on black background, although the actual terminal is the opposite. And yes I am one of the users who always changes gnome terminal back to white on black. Chris -- 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: White-on-black terminal should be default
On Wed, 2010-03-03 at 21:23 +0100, Remco wrote: On Wed, Mar 3, 2010 at 17:40, Tom H tomh0...@gmail.com wrote: Ugh. I really thought that only primitive systems use white text on a black background. It's ergonomically very bad. I never use such a terminal except in Windows, where I haven't figured out (nor spent enough time to need to) how to change it. I agree. I would rather not have my terminals look like a tty! Would it be possible to have black text on a white background for the virtual terminals, too? The current low-resolution white-on-black is not very comfortable. Its high resolution on Lucid with kms on systems that support kms anyway. Chris -- 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: karmic trashed in Tomshardware.com
On Mon, 2009-12-07 at 17:13 -0600, Patrick Goetz wrote: I've been out of the loop for a couple of months, so pardon me if this has already been discussed, but Karmic got thoroughly trashed in a TomsHardware.com review: http://www.tomshardware.com/reviews/ubuntu-karmic-koala,2484.html Some of these issues (system freezes when copying large files on ext4) I've never heard of before. If its anything like what I see on ext3, I have been plagued by that for many years. I have heard rumors 2.6.32 in Lucid traded off some performance to hopefully finally fix this issue, I sure hope so anyway. My personal gripes with karmic were finding out that fakeraid now doesn't work at all, a regression caused by grub2 (https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/392136) and that the network applet, nm-applet still doesn't work in a multi-user context: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/284596 Either of these is a deal killer for some significant fraction of users (e.g. dual booters or household shared PC users, respectively). -- 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: karmic trashed in Tomshardware.com
On Tue, 2009-12-08 at 22:53 -0600, Chris Cheney wrote: On Mon, 2009-12-07 at 17:13 -0600, Patrick Goetz wrote: I've been out of the loop for a couple of months, so pardon me if this has already been discussed, but Karmic got thoroughly trashed in a TomsHardware.com review: http://www.tomshardware.com/reviews/ubuntu-karmic-koala,2484.html Some of these issues (system freezes when copying large files on ext4) I've never heard of before. If its anything like what I see on ext3, I have been plagued by that for many years. I have heard rumors 2.6.32 in Lucid traded off some performance to hopefully finally fix this issue, I sure hope so anyway. After reading close 'freezes' above seems to refer to complete hang of the system, not just not being able to do anything else on the system while the system is doing a copy. That is what I see on my systems and was referring to having been fixed in 2.6.32. Chris -- 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: OpenOffice update
On Thu, 2009-10-22 at 13:50 -0400, Tim Gelvin wrote: When can we expect to see an update to OpenOffice? What do you mean? There is 1:3.1.1-5ubuntu1 in Karmic already. Chris -- 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: Oo.org Calc Pdf Export Issue
The issue you are talking about appears to be this: https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/244353 https://bugzilla.novell.com/show_bug.cgi?id=440055 Chris On Tue, 2009-05-26 at 16:27 +0200, Stefan Kachaunov wrote: Hello! I am writing to you because I (as well as others: http://www.oooforum.org/forum/viewtopic.phtml?t=78686highlight=arabic http://ubuntuforums.org/showthread.php?t=881853 )have been having problems with the PDF export feature in Open Office Calc. Almost every time a spreadsheet is exported (whether embedded as OLE or by itself) to PDF via the built-in pdf export system (not cups-pdf), a random number of the formula fields are exported in Eastern Arabic numbers, not the regular Arabic numbers that are standard today throughout the world. The most frustrating is, that only SOME of the fields get exported like this, and the corrupted fields are different with every export (eg. Cell A1-A9 are normal, A10-A12 are corrupted; upon next export A1-A6 are corrupted, A7-A12 are normal). A forum reply on the Ooo forums hinted that the problem might be due to the version provided in the Ubuntu repos. I am using Ubuntu 9.04 x64, other users have reported this problem mainly on x64 installations. Please, look into this issue and provide some feedback to the community to let us know when the problem is resolved, or if you need more specific information. Best Regards, Stefan K. -- 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: Large files under ubuntu do not appear to work
On Thu, 2009-03-26 at 13:57 +, Scott James Remnant wrote: On Thu, 2009-03-26 at 08:13 +0100, Stephan Hermann wrote: TBH, I just bursted into a laugh attackfor easyiness: 500 Gigabytes as written on a Harddrive label are not the same as 500 Gigabytes transfered over the Network (when you know HD vendor definition: kilo == 1000 and Network vendor definition normally kilo == 1024) The latter isn't true either. Network speeds are generally in thousands of bits per second and multiples thereof. The primary users of binary multiples is the RAM industry, since it's a fundamental multiple of how RAM works. Or anything relating in any way to storage other than hard drive sizes themselves, such as the size of sectors on various media (hd/optical/etc), filesystem blocks, filesystem overall size and file size limitations, etc. Chris -- 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: Large files under ubuntu do not appear to work
From an email from Colin Watson: == The partitioner has done this since November 2005. partman-partitioning (37) unstable; urgency=low [...] [ Frans Pop ] * Use gpt instead of msdos disklabel for disks larger than 2TB. [...] -- Frans Pop f...@debian.org Sun, 27 Nov 2005 20:19:17 +0100 == So this should only show up when creating partitions yourself, perhaps the partitioning tools need modification as well to default to GPT if they see a disk 2TiB Some further information about this topic can be found at: http://www.carltonbale.com/2007/05/how-to-break-the-2tb-2-terabyte-file-system-limit/ http://technet.microsoft.com/en-us/library/cc773223.aspx http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx http://wdc.com/en/products/products.asp?driveid=576 As soon as 2TiB desktop drives become available this will begin to be a problem even for Windows desktop users. Current Windows apparently will only boot off a GPT drive if the system has UEFI instead of BIOS and then only for Windows Vista SP1 x64. It is unclear to me whether Windows 7 will allow booting from GPT without needing UEFI. It appears that currently the only consumer systems with UEFI support are Macs, Intel motherboards, and some MSI motherboards. Chris -- 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: Default font size in gnome
On Sat, 2009-02-28 at 12:38 +0100, Markus Hitter wrote: This is likely all true, but with resolution independent rendering, it no longer applies. In the future, px is just a measurement unit, just like in or mm. Once the software gets this, it's perfectly fine for web developers to ask for a 12pt font. It just won't be rendered with characters 12 screen pixel high, but with this value, divided/multiplied with the screen dpi. I can understand this is difficult to get swallowed. For 40 (or more) years now, the rule was 1 pixel = 1 dot on the screen. A picture, 100px x 100px in size used to use exactly 100 x 100 dots on screen. Now, this is no longer true. To stir the mix additionally, there are many pieces of software respecting resolution independent rendering and many others not. Picture viewers still map one picture pixel to one dot on screen and call this 100%. Font/text displying tools still shortcut rendering engines and draw a 12pt font with 12-dot-on-screen character glyphs. Some software considers 72 dpi screens (Macintosh monitors were produced many years this way) as standard, others won't work with anything but a 96 dpi screen (Windows XP default setting). This makes comparisons so difficult. My personal hope is, this dust settles once people get used to set their screen dpi just right: it is a measurable fact. Then, they will start complaining a 12 px font is waaay to big for phone screens ;-) MarKus P.S.: There's no real need for an additional measurement unit besides mm and in, so I'd actually prefer to see px going away entirely. What a dream! Agreed that px should go away entirely in HTML. However, it seems you have gotten several things confused. Pt is point which was defined long before computers came into wide use. It was finally officially defined as 1/72 of an inch in 1959 but had been in that general range of size since at least the 1700s. Px means pixel which is a picture element and is an abomination that it was ever allowed into the HTML specification at all. 1 pixel definitely means 1 picture element (dot) on the screen. That is where the word pixel comes from. Redefining pixel to mean something else instead of just using Pt properly would be crazy. Also where is a 100x100 image not displayed as such? Only if you set zoom level to something other than 100% does this normally happen. Many (most?) image formats don't even have the concept of DPI or image size in inches. Additionally if you want 100% to always mean the images size you would need some other terminology for displaying the full image data. For most uses other than publishing having a size set for an image is useless since an image doesn't really have an inherent DPI, it is scaled to fit whatever medium you want it on. A 12MP image could just as easily be printed onto a 6x4 or 30x20 page. However, in cases where the image has DPI/size information a publishing program should take that into account. Actually, it would also be useful for web browsers to use this information so that developers could include higher resolution images that are scaled to fit the size they want to have displayed. Then web browsers could also have a user adjustable scaling factor that could be applied to an entire page in cases where smaller screens need to view an entire page. I'm not sure the last time general DPI has been 72 DPI, at least on Windows computers (or Macs afaik) for at least the past decade they have been kept their DPI settting set to 96 DPI. The last time a monitor was 72 DPI was probably when 15 CRT (13.8 viewable) were commonly at 800x600 resolution. My computer from 15 years ago was even higher than that running at 1024x768 on a 15 CRT (93 DPI). The main issue here is that operating systems are broken so a Web designer can't use a point based font and expect it to look the same everywhere, which it should. So sometimes they end up using pixel based sizes because of that reason, and in some cases they use pixel based sizes just from not knowing any better. Once there are enough operating systems that work properly hopefully it will pressure Microsoft into properly fixing this issue in Windows. Until then it will be hard to make a browser that will display properly on all platforms, unless there is some way for a browser to query the true DPI of a screen on Windows? Chris -- 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: Default font size in gnome
On Fri, 2009-02-27 at 02:55 -0500, Felix Miata wrote: On 2009/02/26 21:12 (GMT-0600) Chris Cheney composed: On Thu, 2009-02-26 at 21:08 -0500, Felix Miata wrote: On 2009/02/26 19:15 (GMT-0600) Chris Cheney composed: On 26/02/09 14:31, Felix Miata wrote: Real-world DPI has been steadily increasing from release to release. I don't see this to actually be the case. Even with laptops it seems that ~ 130 dpi is the maximum that most manufacturers are doing. I had a It wasn't that long ago that they switched from 4:3 to widescreen. Before that point, it was mostly 15 on 1024x768 (85 DPI), 17 on 1280x1024 (96 DPI) 19 on 1280x1024 (86 DPI) taking over from a lower average on CRTs. There's still a lot of those in use. They mostly aren't replaced or soon to be replaced yet. The switch to widescreen in laptops happened over 5 years ago. Even back It may have begun that long ago, which I doubt, but it certainly did not happen in anything resembling an instant. I bought one of the cheapest laptops I could find in Jan 2004, an eMachines, and it was already a 15.4 1280x800 at that time. So yes the transition at least started long ago, although some manufacturers laptops such as IBM/Lenovo didn't transition until recently, eg with the ThinkPad X61s - X200. You can actually still buy the 4:3 X61s at present. with 4:3 on laptops you could get 133 dpi screens (1600x1200 15 laptop) 5+ years ago. Could get does not equate to affordable or high sales volume. Much more common than 1600x1200 regardless of size was 1024x768 on 14 and 1400x1050 on 16. A 1600x1200 15.0 panel was already available in the IBM ThinkPad A21p as of 2000, and other laptops with that resolution screen probably were around even before then. It was at least as common at that point as 147 dpi screens are now. Also in that same timeframe (IBM ThinkPad T21 - 2000) you could get 14.1 laptops with 1400x1050 which is 124 dpi, which is the same dpi as my brand new ThinkPad X200. And the previous generation ThinkPad T61p, replaced by the ThinkPad T500, was available with a 15.4 1920x1200 147 dpi (Jul 2007). So there may be some very slow progression of increase in dpi in the past, but it seems to have essentially halted due to the lack of support from Microsoft due to the fact their OS has ~ 90% market share. Hopefully we can help Linux in general work which will put pressure on Microsoft to make it work on their OS as well. Once that happens we may see a return to 200 dpi (and above) monitors being available for purchase. So I still don't see a continual increase in dpi. I see an increase in dpi to about the maximal usable with the fact that Windows doesn't scale properly to higher dpi and then stagnation in the field. IBM had made 200 dpi screens around 5 years ago but they have been EOL'd since Windows still isn't resolution independent. These may not be the best around, but even if they're off by 50%, the real world still hasn't been anywhere near constant for the past 5 years: http://www.w3schools.com/browsers/browsers_display.asp http://www.thecounter.com/stats/2004/February/res.php http://www.thecounter.com/stats/2005/February/res.php http://www.thecounter.com/stats/2006/February/res.php http://www.thecounter.com/stats/2007/February/res.php http://www.thecounter.com/stats/2008/February/res.php http://www.thecounter.com/stats/2009/February/res.php The stats above do not include any 16:9 or 16:10 resolutions, so are of questionable value. w3schools lumps it all into 'higher' but thecounter doesn't seem to report those statistics at all. Unless thecounter is lumping all widescreen into unknown, which they report at only 12%, if that is the case I think their statistics are questionable. I'm sure there are more than 12% people using widescreen, as it is pretty much the only type of screen you have been able to get on laptops for at least several years now. Here are some interesting articles about High DPI from the Microsoft perspective. http://blogs.msdn.com/greg_schechter/archive/2006/08/07/690704.aspx http://blogs.msdn.com/e7/archive/2008/09/13/follow-up-on-high-dpi-resolution.aspx http://blogs.msdn.com/e7/archive/2008/09/16/more-follow-up-to-discussion-about-high-dpi.aspx Very good. Thanks! Visual perspective on the situation most experience now: http://fm.no-ip.com/SS/bbcSS.html Fortunately most web designers are smart enough not to use px for fonts. Chris -- 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: Default font size in gnome
On Fri, 2009-02-27 at 16:28 +, (``-_-´´) -- BUGabundo wrote: Olá Mackenzie e a todos. On Thursday 26 February 2009 18:59:28 Mackenzie Morgan wrote: I have a 1280x800 13 screen, and the fonts look fine to me. Hi have a 13 at 1280x800 (DPI 112 according to xorg log) and I have to increase mine, but I dont see as good as I used to. It seems strange that you needed to increase the font size when your DPI setting increased. Just changing the DPI from 96 to 112 should have made your font increase ~ 17% in pixels for the same given font size. eg: 12/72 * 96 = 16.0 px 12/72 * 112 = 18.7 px Chris -- 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: Default font size in gnome
On Fri, 2009-02-27 at 13:55 -0500, Felix Miata wrote: On 2009/02/27 10:09 (GMT-0600) Chris Cheney composed: On Fri, 2009-02-27 at 02:55 -0500, Felix Miata wrote: These may not be the best around, but even if they're off by 50%, the real world still hasn't been anywhere near constant for the past 5 years: http://www.w3schools.com/browsers/browsers_display.asp http://www.thecounter.com/stats/2004/February/res.php http://www.thecounter.com/stats/2005/February/res.php http://www.thecounter.com/stats/2006/February/res.php http://www.thecounter.com/stats/2007/February/res.php http://www.thecounter.com/stats/2008/February/res.php http://www.thecounter.com/stats/2009/February/res.php The stats above do not include any 16:9 or 16:10 resolutions, so are of questionable value. w3schools lumps it all into 'higher' but thecounter doesn't seem to report those statistics at all. Unless thecounter is lumping all widescreen into unknown, which they report at only 12%, if that is the case I think their statistics are questionable. I'm sure there are more than 12% people using widescreen, as it is pretty much the only type of screen you have been able to get on laptops for at least several years now. I think it perfectly valid, if lacking in meaning, that w3schools shows more than 5/8 are obviously using either widescreens or older displays running higher than 1024 wide. Essentially, more than half of users are running something that's higher than 8-10 years ago, and higher than the 800x600 many web designers feel compelled to support, and 1024 wide most of the rest think should be the widest necessary to support. Don't forget that what w3schools actually measures is data from w3schools users, not web users at large. Meaning it primarily measures web developers machines. Looking at the Firefox market share on w3schools it shows up as 45.5%, however it is generally believed to be much lower than that in the general population. Actually as of last month the amount of Firefox users is higher than IE users on w3schools. Since it is measuring web developers machines in many cases they may have their machine set up for the resolution they are designing their pages for instead of the actual native resolution of their monitor. That would also explain why there was such a large number of 800x600 users, up until a few years ago, given that the userbase is web developers. Several months ago I tried to inquire about the absence of widescreen at thecounter, but didn't get anywhere. Since they seem to provide 100%, I'm thinking they're going by width alone. That would put the major player 1280x800 laptops and 1280x720 HDTVs in the same box as the many 1280x1024 displays still on desktops. 1600x1200 seems too low to include 1680x1050, so I'm guessing 1440x900, 1680x1050, 1920x1080 HDTV 1920x1200 make up the bulk of unknown. There are also the users Microsoft and others mention that not everyone is using native LCD modes. That would put a of 1280x800 displays into 1024x600 mode, lumping them in with the many 1024x768s still out in the wild. I'd like to see obviously better stats somewhere, but the above are all I know about. -- 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: Default font size in gnome
On Thu, 2009-02-26 at 21:15 +0100, Siegfried-Angel wrote: 2009/2/26 Chris Cheney cche...@ubuntu.com: [...] personally I think they are already fine [...] I don't agree. Having fonts as displayed in http://launchpadlibrarian.net/23152448/10pt.jpg is clearly not right and would make, IMHO, a awful first impression. They didn't actually grow in size except on high dpi screens as has already been noted. My desktop monitor 23 1920x1200 was already roughly 96 dpi in hardware. -- 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: Default font size in gnome
On Thu, 2009-02-26 at 17:33 -0600, Ryan Hayle wrote: On 26/02/09 14:31, Felix Miata wrote: On the contrary, preference is about the difference between acceptable and unacceptable. There are two separate issues here. You seem to be arguing that the OLD size is too small, and want it to be larger. Fair enough--but that is a separate issue. What I am arguing for, is consistency with previous versions now that the DPI is set correctly. I am not a usability expert--maybe you're right and the default should be larger, but that is a separate issue. Actually the old font size will cause the font to actually become smaller on screen in many normal desktop cases. Even with the current selection of wide screen monitors the highest dpi screen I see that Samsung makes is 102 dpi, and they are fairly representative of the market at least in the USA. That is up to 15% smaller font size on screen on the low end of current desktop monitors and 6% larger on the high end of desktop monitors. Samsung --- 17 - 1280x1024 - 94/100 dpi 4:3 19 - 1280x1024 - 84/89 dpi 4:3 19 - 1440x 900 - 89 dpi 16:10 20 - 1600x 900 - 92 dpi 16:9 20 - 1680x1050 - 99 dpi 16:10 22 - 1920x1080 -102 dpi 16:9 22 - 1680x1050 - 90 dpi 16:10 24 - 1920x1200 - 94 dpi 16:10 27 - 1920x1200 - 84 dpi 16:10 30 - 2560x1600 -101 dpi 16:10 As far as I can tell the 200 dpi desktop monitors I mentioned before in the thread have been EOL'd and are no longer being produced. Intended by whom, mousetype lovers? My point was those who find it inappropriately large can easily manage to fix it. Those who find inappropriately small have to somehow manage to overcome a legibility obstacle to fix it - a chicken/egg situation. Intended by whomever set the default in previous Ubuntu releases.Real-world DPI has been steadily increasing from release to release. What may I don't see this to actually be the case. Even with laptops it seems that ~ 130 dpi is the maximum that most manufacturers are doing. I had a laptop about 5 years ago that was 133 dpi and even today it is hard to find laptops with higher than 133 dpi screens. Even most netbooks with their tiny screens are below 130 dpi. have been intended two years ago, when due to DPI fixed at 96 resulted in arbitrary sizes, can't necessarily be related to a correct size now that DPI is no longer arbitrary. Yes, and DPI will continue to increase. This should result in sharper fonts, NOT larger or smaller fonts. That's the whole point of this effort. We need a sensible default which looks good out of the box on the majority of systems. As noted above I do not see that this is the actually case. The larger of those was here preferable to the smaller, even on my lowest DPI system. The oldest of low-resolution screens still in use is probably 800x600 13 visible/14 advertised CRT - about 77 DPI. Lowest resolution desktop display in stores today is probably 20 1440x900 - about 85 DPI. That's only about 10% DPI difference. Ugly is in the eye of the beholder. To some, the definition of ugly is the functional equivalent of too small, just as well as others to whom it equates to too large. In any event, and regardless what nominal size is ultimately released as the default, it's still much easier to for a user to fix too large than it is to fix too small, which is the entire point of my original thread reply. I believe a sensible default needs to appeal to the majority of users, not cater to the visually impaired. I support accessibility 100%, but the majority of users with good eyesight should not have to decrease their fonts in order to accommodate those who need extremely large fonts to see. You're absolutely right that it's an easy change, however the 1st impression people get of Ubuntu (and all the screenshots which will be posted to the web) is extremely important. And sadly, defaults are more about marketing than usability. I think we all agree that we want the system to be as usable and customisable as possible. Like I said before, perhaps we need a script to set the default font depending on the DPI and screen size. A script might work here but it would probably need to be one that the user could check the settings and automatically revert if they could no longer read the text. Don't forget distance from the screen has a large effect on whether a font is too big or not. Distance from the screen on a laptop is typically much smaller than distance to the screen on a desktop monitor. FYI--It seems to me like there might possibly be another issue here. At high DPI, it seems as if the font rendering engine makes larger fonts (by that I mean 10pt) appear more bold than they should (in my opinion). Is this the intended behaviour? I really know nothing about this or typography in general, I just wanted to raise the idea. I often choose
Re: Default font size in gnome
On Thu, 2009-02-26 at 21:08 -0500, Felix Miata wrote: On 2009/02/26 19:15 (GMT-0600) Chris Cheney composed: On 26/02/09 14:31, Felix Miata wrote: Real-world DPI has been steadily increasing from release to release. I don't see this to actually be the case. Even with laptops it seems that ~ 130 dpi is the maximum that most manufacturers are doing. I had a It wasn't that long ago that they switched from 4:3 to widescreen. Before that point, it was mostly 15 on 1024x768 (85 DPI), 17 on 1280x1024 (96 DPI) 19 on 1280x1024 (86 DPI) taking over from a lower average on CRTs. There's still a lot of those in use. They mostly aren't replaced or soon to be replaced yet. The switch to widescreen in laptops happened over 5 years ago. Even back with 4:3 on laptops you could get 133 dpi screens (1600x1200 15 laptop) 5+ years ago. So I still don't see a continual increase in dpi. I see an increase in dpi to about the maximal usable with the fact that Windows doesn't scale properly to higher dpi and then stagnation in the field. IBM had made 200 dpi screens around 5 years ago but they have been EOL'd since Windows still isn't resolution independent. laptop about 5 years ago that was 133 dpi and even today it is hard to find laptops with higher than 133 dpi screens. Even most netbooks with their tiny screens are below 130 dpi. Overall the manufacturers are no dummies. They seem to know how poor is support for higher in available desktop environments. Support for 120 DPI in WinXP is poor, for higher, terrible. I've not heard that it has improved significantly in Vista. Poorer performance from more expensive products does not well generate sales and minimize returns. Manufacturers could be providing higher if poor support wasn't the norm for the foreseeable future. 1920x1200 on 15.4 proves 140+ technology already exists that could be provided in desktop displays. If and when real resolution independence happens, DPI will go up faster. Agreed and as Windows doesn't seem to actually be moving in the resolution independent direction, at least anytime soon, due to backward compatibility with third party apps. So I don't think dpi is going to increase significantly more any time soon as Ryan seemed to think. Here are some interesting articles about High DPI from the Microsoft perspective. http://blogs.msdn.com/greg_schechter/archive/2006/08/07/690704.aspx http://blogs.msdn.com/e7/archive/2008/09/13/follow-up-on-high-dpi-resolution.aspx http://blogs.msdn.com/e7/archive/2008/09/16/more-follow-up-to-discussion-about-high-dpi.aspx http://fm.no-ip.com/auth/Font/fonts-pt2px-tabled.html shows a bit about results of common pixel font sizes in context of the display population. Note at at 96 DPI, 16px is 12pt, 14px is one size larger than 10pt, and 12px is 9pt, while at 120 DPI, 16px is commonly the size used to render 10pt (16.667px to be somewhat precise in actuality). -- Do not let any unwholesome talk come out of your mouths, but only what is helpful for building others up. Ephesians 4:29 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- 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: Fake login screens
Even if Alt+SysRq+K does work for you it will likely cause your console (eg Alt F1-F6) to not work again until reboot, because it doesn't cleanly shut down the xserver like C-A-B does. I used it once recently after C-A-B was disabled by default and it worked well enough to get X back but after that I could not go to a console again until I had rebooted. Chris On Sat, 2009-02-14 at 20:31 -0500, Mike Jones wrote: Mackenzie, Please don't think I'm just trying to stir up more noise. In discussion with the people using this list I've seen the wisdom in taking a personal inconvenience for the greater good regarding the C-A-B issue. But I've tried Alt+SysRq+K on many different computer systems I have access to. It doesn't seem to do anything. Could you please explain what I'm doing wrong? Or help me find out if I should file a bug report? Thanks so much. -Michael Jones Message: 9 Date: Sat, 14 Feb 2009 18:12:25 -0500 From: Mackenzie Morgan maco...@gmail.com Subject: Re: Fake login screens To: ubuntu-devel-discuss@lists.ubuntu.com Message-ID: 200902141812.25625.maco...@gmail.com Content-Type: text/plain; charset=iso-8859-1 On Saturday 14 February 2009 5:43:20 pm Mario Vukelic wrote: On Sat, 2009-02-14 at 16:52 -0500, Mackenzie Morgan wrote: And *YOU* are missing the point that Ctrl+Alt+Delete on Ubuntu *already* does what Windows does when you hit Ctrl+Alt+Delete but are actually already logged in: it asks if you want to log out. Nope it does not. The windows *kernel* intercepts C-A-D, user processes can't. It's specifically designed as a way to prevent fake login screens: pressing C-A-D *guarantees* a kernel-approved login. http://blogs.msdn.com/larryosterman/archive/2005/01/24/359850.aspx Guys, doing your homework before posting would make developers more likely to stay subscribed. The point was just a way to get logged out with a keyboard shortcut but if you would like to still have it kill session, the kernel *does* intercept Alt+SysRq+K as pointed out a billion times already. Seriously, we have a userspace and a kernelspace way around this one. -- Mackenzie Morgan http://ubuntulinuxtipstricks.blogspot.com apt-get moo -- 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: Go-OO.org?
I maintain OOo for Ubuntu. The OpenOffice.org in Ubuntu is the go-oo.org version. go-oo takes the original sun tarballs then patches it heavily with somewhere around 500 patches. Pretty much all Linux distributions use the go-oo.org build system and patches, except for Fedora, which just takes a few of the patches and does the build differently. Of course we have a few Ubuntu specific patches as well which are actually located in the go-oo (ooo-build) repository at svn.gnome.org. We add things like the Human icon theme and launchpad integration. And we also use a different splash screen for the Ubuntu version which has the Sun logo on it by Sun's request. Chris On Mon, 2008-12-29 at 16:48 -0500, John Moser wrote: I was considering filing a bug for package request or creating a spec for Go-Ooo.org for inclusion in Ubuntu, or possibly as a replacement for OpenOffice.org vanilla. Start-up time is faster and feature set is expanded. There seems to be some contention between the world in general and Sun over OOo; people have forked or threatened to fork the project several times, and Go-OOo seems to be the most active as far as I can tell. I'm not sure where this will lead in the future-- possibly to a stagnating OOo from Sun and then to a completely different office suite, or possibly to a new fork, or possibly to Go-OOo, or possibly to some improvement in community view and/or management of Sun's OOo-- but I think the current political atmosphere and the availability of a more featureful fork warrants some investigation. Has anyone else tried this thing? I'm curious to know any opinions (political and technical, but please if you must pick one than go more technical than political) on the software, as well as any better or more active forks out there, or other viable alternatives entirely. -- 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: Go-OOO.org?
On Tue, 2008-12-30 at 08:46 -0500, Mackenzie Morgan wrote: On Mon, 2008-12-29 at 16:48 -0500, John Moser wrote: I was considering filing a bug for package request or creating a spec for Go-Ooo.org for inclusion in Ubuntu, or possibly as a replacement for OpenOffice.org vanilla. Start-up time is faster and feature set is expanded. Given we have had support for docx, etc. in Ubuntu since, I think Gutsy, I was under the impression we already used Go-OOO.org Yes, but it doesn't have save support (even 3.0 doesn't support saving) and didn't have mime support in nautilus which is why Onkar may not have noticed it worked in the older versions. Chris -- 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: You lost a new Ubuntu user
On Sun, 2008-12-28 at 12:03 +0100, Markus Hitter wrote: Am 28.12.2008 um 07:49 schrieb Chris Cheney: Thus it would take a very long time to download for a large percentage of the world. Although perhaps this is not as big an issue since many places have a bandwidth cap as well so people wouldn't be downloading the image in the first place? You propose to intentionally get rid of a significant number of users? Hmm. For me, the limited size of the CD is one of the great features of Ubuntu as it not only allows a reasonable quick download, but obviously stops Ubuntu from bloating as well. MarKus Well this discussion did start out due to the fact that the install CD currently needs an internet connection to install language packs since they don't fit on the cd. Which brought up the issue of installing them over an internet connection which in many countries is prohibitively expensive. So going to a default DVD release could possibly alleviate this issue, assuming that the users in those countries could get access to the DVDs via shipit or some other means. Of course they couldn't download the DVD image for the same reason they can't download updates and language packs today, that is their internet connection is too limited and expensive. With respect of the cost of pressed CDs vs DVDs for shipit, I don't know how much they cost. However, some newspapers in the UK give away DVDs with their newspapers, of course they may be advertising subsidized to offset the cost. Chris -- 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: You lost a new Ubuntu user
On Sat, 2008-12-27 at 16:47 +, richard wrote: -snip- He knows that if he buys a copy of windows 1 CD maybe 2 -snip- Windows is a DVD now MacOS is a DVD as well Perhaps its time to move the default Ubuntu release to a DVD also. ;-) If I remember correctly the main reason it hasn't been so far is due to distribution issues as a DVD is 4.5GiB vs 700MiB for a CD. Thus it would take a very long time to download for a large percentage of the world. Although perhaps this is not as big an issue since many places have a bandwidth cap as well so people wouldn't be downloading the image in the first place? Chris -- 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: tracking bug for ext4
John, 2.6.28 will come out around January and Jaunty will probably ship with 2.6.29 but it very well might not be a good idea to use it by default for Jaunty which is what shirish seemed to be talking about. Just because it is not considered development status doesn't necessarily mean it is stable enough to use as the default for all Ubuntu installs. Chris On Tue, 2008-11-04 at 09:30 -0500, John Dong wrote: Please stop filing nonsense bugs without first understanding the situation. ext4 will become the default filesystem once upstream recommends it for adoption (i.e. 2.6.28). GRUB still does not support reading ext4 so we will probably need a separate /boot on ext2/ext3, or wait for one of the SoC projects to magically finish. There is no need to clutter the bug tracker with this. -- 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: OpenOffice 3 and Firefox 3.1 in Intrepid?
On Sat, 2008-09-27 at 11:53 +0300, Timo Jyrinki wrote: 2008/9/5 Chris Cheney [EMAIL PROTECTED]: released on Sept 8 which puts the final release around Oct 20. That doesn't leave enough time to make it even marginally stable, since that would be only 3 days before the Intrepid release candidate. Note that there are also dependencies like openoffice.org-voikko which would need upgrading to a new version too if OOo 3 would be put into intrepid. -Timo The OpenOffice.org release has shifted to possibly Oct 7 now, maybe even later than that as the page has a '?' on it still. That is much too late to have OpenOffice.org 3.0 be the main version in Intrepid. However, I have uploaded OpenOffice.org 1:3.0.0~rc2-1ubuntu2 today to the openoffice-pkgs ppa so that people can use if they would like. Chris -- 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: OpenOffice 3 and Firefox 3.1 in Intrepid?
On Thu, 2008-09-25 at 19:22 -0500, Tony Yarusso wrote: On Fri, Sep 5, 2008 at 10:48 AM, Chris Cheney [EMAIL PROTECTED] wrote: On Sun, 2008-08-31 at 11:30 +0530, Vishal Rao wrote: What is the latest status of the possibility of including OOo 3 and FF 3.1 by default in Intrepid? OpenOffice.org 3.0 will be in Intrepid but it is looking like it will not be as the primary version that is installed by default. The release candidate and final dates for OOo 3 were originally set to Jul 25th and Sep 2 respectively, but OOo has slipped a lot from those dates. OOo 3.0rc1 is still not released yet, it is currently expected to be released on Sept 8 which puts the final release around Oct 20. That doesn't leave enough time to make it even marginally stable, since that would be only 3 days before the Intrepid release candidate. If OpenOffice.org had been able to keep closer to their originally stated schedules then this problem wouldn't have occurred. Chris Now that RC2 has been out a couple of days, and that http://wiki.services.openoffice.org/wiki/OOoRelease30 states that they are currently shooting for final release on Oct. 7 rather than 20, is there any news on this front? Granted, it's still very tight, but at least looks more promising. Meanwhile, default or not, I still don't see OOo3 packaged and in the Intrepid repos at all, which scares me a lot. Any progress on that portion? I will hopefully have OOo 3.0.0~rc2 uploaded to the PPA by later today. I am working on a few bugs still before uploading it. Chris -- 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: OpenOffice 3 and Firefox 3.1 in Intrepid?
On Sun, 2008-08-31 at 11:30 +0530, Vishal Rao wrote: What is the latest status of the possibility of including OOo 3 and FF 3.1 by default in Intrepid? OpenOffice.org 3.0 will be in Intrepid but it is looking like it will not be as the primary version that is installed by default. The release candidate and final dates for OOo 3 were originally set to Jul 25th and Sep 2 respectively, but OOo has slipped a lot from those dates. OOo 3.0rc1 is still not released yet, it is currently expected to be released on Sept 8 which puts the final release around Oct 20. That doesn't leave enough time to make it even marginally stable, since that would be only 3 days before the Intrepid release candidate. If OpenOffice.org had been able to keep closer to their originally stated schedules then this problem wouldn't have occurred. Chris -- 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
