Re: Proposal: Replace all references to master/slave in GNOME modules
On 2019-04-25 10:17 a.m., Christopher Davis via desktop-devel-list wrote: That connection is the problematic bit, because in some countries slavery wasn't all that long ago, and in some places it's never left or it changed forms. Doesn't change the fact that it's accurate, and is the correct computer terminology. If we want to be an inclusive project, it would be beneficial to use language that do esn't scratch at scars when we have other metaphors we can use. I would suggest to you that trying to be "inclusive" turns a lot of people off, making it overall less inclusive. ie, negative gains. And I'm serious about that. If anything's been learned from the drama on LKML last year, it's that for every one person "triggered" by status quo, about three seemed "triggered" by forcing changes on that front. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: Replace all references to master/slave in GNOME modules
On 2019-04-25 9:58 a.m., Emmanuele Bassi via desktop-devel-list wrote: If you cannot maintain even a semblance of a civil discourse, the door is shown to you at the bottom of every email. Fine, if you want it stated a different way, the terms being used are as accurate as possible. There is a master process. It tells a slave what to do. The slave process does it, no questions asked. This is what machines do. It is accurate. It does not reflect on history, it is not a reference to it. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: Replace all references to master/slave in GNOME modules
On 2019-04-25 6:43 a.m., Bastien Nocera wrote: It's non-gender neutral, which was mentioned earlier in the thread. See the master/maiden section of: https://www.cs.cmu.edu/~mjw/Language/NonSexist/vuw.non-sexist-language-guidelines.txt Is this entire thread some weird, SJW-perverted joke? "Who the bleep cares?" If you're triggered by branch naming, go hide under a rock. Or maybe get a psychiatrist. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: I believe we should reconsider our sys-tray removal
On 2019-03-25 12:15 p.m., mcatanz...@gnome.org wrote: I wonder if there's been any serious design consideration of this proposal? The dash seems like it might be a safer place to put things than allowing applications to clutter the precious top bar. Not to be impertinent, but attached is my top bar. Please indicate where there is clutter? Is it the 24 pixels of the dropbox icon? --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: I believe we should reconsider our sys-tray removal
On 2019-03-25 11:07 a.m., Andre Klapper wrote: You may want to disable "Plugins > Notifications" in Rhythmbox to not flood your notification area with things you don't consider helpful. I think you have just corroborated my point. You can hide notifications you don't want. The notification system treats all notifications as equals. They are not all equal. Maybe I want a notification area for important messages and one for everything else. I don't mind an extra icon for that. If it needs to flash to get my attention, fine. That's a preference. I can disable it. Should icons be shown all the time? No, usually. But that should be up to the program. If I'm annoyed by it, I won't use it. Or I'll hide it. Or disable the notification. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: I believe we should reconsider our sys-tray removal
On 2019-03-25 7:19 a.m., Emmanuele Bassi via desktop-devel-list wrote: Which would achieve nothing except, once again, shoving icons and menus into one of the most important pieces of screen real estate we have just because some application developers simply cannot live without their application icons being visible at all times. Is that a joke? On a default gnome install on any modern screen, only about 25% of the top bar contains any information at all. It can't be "the most important real estate" and be so underutilized. Same reasoning why it is rare to have a park in the middle of downtown. That said, notification icons are literally the most useful information points for the many applications I have running in the background. So they deserve prominent placement. You think "application developers simply cannot live without their application icons being visible at all times"? That's why Windows lets you hide them. Problem solved. Like, since XP in 2001. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: I believe we should reconsider our sys-tray removal
On 2019-03-25 10:37 a.m., Emmanuele Bassi via desktop-devel-list wrote: On a default gnome install on any modern screen, only about 25% of the top bar contains any information at all. It can't be "the most important real estate" and be so underutilized. It's important because it's the UI element that is *always visible* at all times. So let me hide it. Everyone's happy. Same reasoning why it is rare to have a park in the middle of downtown. I literally have no idea what this even means. It's not important real-estate if it is completely underutilized. The only time empty space is important real estate is when that empty space is more important than information that could be there. Same applies to buildings. That was the analogy. That said, notification icons are literally the most useful information points for the many applications I have running in the background. So they deserve prominent placement. If an application is in the background, why do you need to see an icon all the time? Because I got an IM while I was away from my desk. It shows up in the completely useless notification menu that is under the clock. Its notification got clobbered by Rhythmbox's notification that the song changed while I was on the can. I wonder why I never see my original notification. Alternative: oh hey, the Pidgin icon is flashing! If the application needs to notify you of any state change while it's hidden, it can use a notification; if you need an icon to interact with a background application, you can literally re-launch it from the dash or from the applications grid, and you'll get an application window. Keepass: I want the icon so I can click it and it makes the correct password available o nthe clipboard. Screen recording: I want a place on screen to click to stop it without recording a window change. There are a gazillion uses. Screen sharing: icon shows me that someone is connected (this information is useless hidden in a menu). I can think of dozens more. If there are no state changes and you don't need to interact with it, then the icon is pointless waste of space. And yet, on my Mac, I'm not overwhelmed with icons. A balance can be struck. Anyway, all that to say, I'm perfectly happy with KNotifier, but it's a no-brainer that it should be core and it should be modernized for all of the *technical* reasons mentioned in other messages. If you don't want to see it, hide it. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On 2017-05-16 07:10 PM, Mattias Bengtsson wrote: How did you install GitLab? We use the omnibus RPM package for CentOS and have had no dependency problems while upgrading from some 7.x release all the way to 9.1.x over the last few years. A lot come bundled in the omnibus package and the rest gets installed from the host operating system repositories. There's the difference. I don't trust the current omnibus package, so I install from source. That decision is old, but at the time we installed, there wasn't an omnibus package. In general, IMO it's not appropriate to run whatever random libraries they threw into their package. It's very large, and if you don't use the host specifically for gitlab, it gets tricky using it with port 80 and 443 with Apache. A proper package would rely on system libraries only. Could it be that Debian stable is just very old? I think it's proper to expect at least a 3 year lifecycle out of software that runs on a server, no? Can you imagine if Windows Server 2012 was considered too old for a package equivalent to Gitlab? That just wouldn't happen. Anyway, this is getting off-topic. Using the only appropriate install method for this package takes considerable effort. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On 2017-05-16 09:22 AM, Allan Day wrote: We are confident that GitLab is a good choice for GNOME, and we can’t wait for GNOME to modernise our developer experience with it. It will provide us with vastly more effective tools, an easier landing for newcomers, and lots of opportunities to improve the way that we work. We're ready to start working on the migration. I only lurk here, so I don't often offer an opinion, but I do maintain the GitLab install at my medium-sized company. My problem with GitLab is how fluid it is. The underlying technologies keep changing, and it's a real pain staying up to date. If you get behind at all with the updates, it's quite a chore to upgrade, and half way through you find out you need a new Ruby, need to upgrade through a couple of packaging systems for node, and really, you should just upgrade to Debian unstable (that last one is a bit of an exaggeration). Expect a new user interface experience every four months. That's not to say that it's fragile. It's been rock-solid for us. It's just hard to recommend something you can't predict, running ever-changing technologies that no sysadmin can comfortably stay on top of. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: En-dash versus em-dash
On 12-12-10 09:57 AM, Philip Withnall wrote: Disclaimer: I’m en_GB. I’m not entirely sure that en_GB speakers should be deciding the style to use in the C locale, given that manuals of style differ between the UK and the US. You must mean en_US. The C locale should not have unicode in it. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Cantarell? (Was: Re: Planned GNOME Shell UI changes (was Re: String and UI Change Announcement))
On 12/01/11 10:52 AM, Maciej Piechotka wrote: According to my fast check (which may be wrong) it seems that it does not cover still used Greek alphabet (tech people aside it is still used in greek language). It does not cover Cyrilic (used among others in Russian) and Chinese and Hindi (I copy the names of national anthem from wikipedia) as well. That alone would make early 40% of world's population according to Wikipedia (sure - probably most Hindi users are bilingual but they would still want to see their documents' titles - fonts are even more important then translation)[1]. Maciej, That in itself is not a very big problem. If Cyrillic characters from DejaVu are put into a titlebar file name by fontconfig, they won't look terribly out of place. The problem is if characters that really need to blend well do not, say if you had the word Journée, and the é was pulled from DejaVu. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Mutter
On 30/03/10 07:17 PM, Owen Taylor wrote: Mutter packages exist for most major Linux distributions as part of packaging GNOME Shell. Mutter is also key component of the Moblin 2.0 and 2.1 releases. With the uncertain future of Moblin, is this appropriate? Will Meego continue with Mutter? What is the relation of Meego going forward and GTK; is Meego going to turn into a large multi-toolkit monster? Not that my opinion matters, but I think these are all good questions. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome-panel Improvement?
On 10/03/10 05:02 PM, rAX wrote: http://0rax0.deviantart.com/art/Gnome-panel-improved-156723192 I really need someone to think about this, and whether or not it should/could be implemented. Seems to me that would severely complicate theming. If the custom icon was saved in ~/.icons, it would be saved for a specific theme only. There isn't much preventing the user from doing this without a UI right now, I think. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
Tristan Van Berkom wrote: Sure, on the other hand projects with ChangeLogs that are hand-tended to are, in my personal experience richer than logs of arbitrary commits, if only by the simple virtue of forcing you to spend time caring for it. I use ChangeLogs a lot. My preference for hand-made ChangeLogs is that the author involuntarily tends to order things by priority. The fact that he bumped the solib version is much more important than that he cleaned up whitespace, fixed an include flag that breaks on some obscure platform, etc. The latter of examples of the kind of entries frequently seen in auto-generated logs. As Murray says, increased entropy. I'll take a weak wine to a high-powered beer any day. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
My objection may seem silly, but since there is no way to type it on any keyboard out there, that's a bit of a hindrance. Short of using the character map and searching, one has to resolve to using smart substitution editors like OpenOffice to get the characters. They also tend to fail horribly when pasting into a non-Unicode terminal, which is still often the case over SSH. Probably not a huge desktop consideration, though. Every distribution I know of uses Unicode by default on the local terminal at this point. --Pat Christian Neumair wrote: Alex Jones proposed [1] to change the quotation marks in Nautilus strings from the ASCII representation ... to the unicode variant “...”. I think the proposed quotation marks are aesthetically more pleasing, but I don't want to change this unless there is a GNOME-wide policy. I hereby propose to establish a GNOME policy of using “...” for quotations. Comments, objections? best regards, Christian Neumair [1] http://bugzilla.gnome.org/show_bug.cgi?id=532777 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
Alan Cox wrote: Put the English quotes in the en_US and en_GB translations, put German quotes in the de ones and so on. This, if course, makes something like the very tiny en_CA locale into a rather full locale. I suppose many generic messages can go into just en. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of
As Shaun points out, it gets a little convoluted. Alan Cox wrote: Which rules does Canada follow for the ending of a sentence with quoted text ? quoted text. or quoted text. That might need a locale anyway Assuming that British is punctuation outside of the quotes, en_US: “That color is nice.” en_CA: “That colour is nice.” en_GB: “That colour is nice”. en_AU: Yet another variant? Leads to a possibility of 4 translations where there were two before. Anyway, this is probably not particularly constructive to the debate. Not sure where you were going with the question, but the point is that's it's mostly minutia that just isn't needed. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Low memory hacks
Brian Nitz wrote: Third, there's no such thing as locale-specific fonts. If a font happens to cover Chinese only, so be it. Finally, if you don't need those fonts, simply don't install them (or uninstall them). I know it doesn't make sense from a developer's point of view, but it has been a request for end users, We don't ever use (X language) fonts in our Hospital/Bank/University/Government Office, why are we installing these fonts? It may be a distribution specific issue, but it's probably an issue with nearly every distribution. I think that there are very much two sides of the coin on this one. 1) Regular user's do _not_ like seeing Unicode boxes 2) Specific applications require running under specific conditions Obviously, most distributions using GNOME are targeted at Case #1. That's probably okay, since it covers 95% of the users, and specific resource-tight projects can limit the number of fonts to suit their needs. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: State of gvfs in Gnome 2.21
Matthias Clasen wrote: For preview, open the font selector, select font, type text... The advantage of fonts:// is that is has previews, which is a very nice feature. It never occurred to me that anyone would want to uninstall fonts. At the very least, uninstallation of the fonts the user installed is necessary. As for the accessible alternative to dnd install, does fonts:// have one ? Maybe there should be an Install this font in the right-click menu for font files. That would be nice, but I don't think it applies to anything with GFS. Anyway, I don't want to sound negative; if somebody reimplements fonts:// for gvfs that would be great. I just don't think it has a high priority. My fear is that it will then get all politicized. Well, such and such a language doesn't use 'Aa', so let's develop a system so that... and it will never get done. Not to sound negative. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: State of gvfs in Gnome 2.21
On Wed, 23 Jan 2008, Matthias Clasen wrote: Well, currently the Go to fonts folder button runs nautilus fonts://. What I meant was to replace that with specimen. But I think nuking the button is better. Isn't that button the only UI connection from a user's point of view to where to dump font files? It might not be the right location for this button, but it's more useful there than nowhere. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: About SSL Trick or Treat Dialogs
Murray Cumming wrote: On Tue, 2007-12-04 at 12:12 -0500, Adam Schreiber wrote: Unfortunately, one of the main UI elements that indicate a secure connection is the https:// URL in the URL bar. Are you proposing to disguise that as well? Maybe just not shade it yellow. It will still be running over ssl like Stef said, just not securely. People don't pay much attention to those hints anyway. They think that a site is secure if they clicked on a Secure Payment link, if they even have a concept of secure sites. There's no real answer to this, I'm afraid, so sorry for the noise. I know we are considering the average user here, but there are many average users who consider what the box tells them anyway. The box tells them that the connection is still secure, but that whoever is hosting the site hasn't shelled out 600 bucks to Verisign. I've thought about this quite a bit in my spare cycles, and I think the dialog is just too big, at least in Firefox. It was a positive step when they made the default to accept the connection. But the dialog should just be a simple OK/Cancel messagebox with a line saying that it the certificate could not be verified, with a button to more details. The *incorrect* way of doing it is how it is done in IE7, which replaces the content area of the browser with something that looks just like their Error page. There are two links which look similar to the usual useless MS KnowledgeBase links to accept and deny. They really go out of their way to prevent people from using such sites, apparently. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: About SSL Trick or Treat Dialogs
Owen Taylor wrote: If you are connecting on an insecure network (say coffee shop wireless) then a https connection to an untrusted certificate is a distinctly weak form of security. It tells you that you have a encrypted connection to *somebody*. That is correct, of course. It is, however, more secure than an open connection. Case in point, on my mail server, which I know I connected to properly on my wired network, and which I told Thunderbird to remember, is not signed by a trusted authority and looks different by host name on an outside network. When I connect to it from outside, my password is still not traveling through the net in plain text. Whether by broken design or broken economics, there will always be a lot of certificates that cannot be authenticated against a CA. Yes, the security is weakened, but there still needs to be something informing the user that their data isn't flying through the air in clear text. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: boost default thumbnail limit?
Olafur Arason wrote: I think it should be format related because I don't want a 10mb gif file being indexed, because it's very slow and can crash the application. Other formats are relatively safe, maybe this should be a gconf option. It brings up the question of Exif thumbnails. I know that in general the idea of using them has been shot down for one reason or another. But they might prove useful as an intermediary for large files. For example: 5M: generate thumbnail 5M 10M: use exif thumbnail 10M: show icon. This is all assuming that as the file size increases, the complexity of retrieving the exif thumbnail increases as well. If that is not the case, this proposal makes no sense. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Helper to collect more info in bug-buddy
Federico Mena Quintero wrote: I recently added code to Nautilus to collect logging information. This log is dumped to a file in the user's home directory when Nautilus crashes [1]. (...) since ~/nautilus-debug-log.txt is where Nautilus dumps its own debug log. Not entirely on-topic, but users who swear by home-as-desktop would probably prefer a less noticeable filename. Then again, putting it right in front of the user might make them do something with it. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
David Trowbridge wrote: What in particular isn't possible with the 6-month cycle? Nothing's impossible, but a longer cycle every so often would encourage larger and better thought-out changes. I always get the feeling that GNOME contributors hold back on a lot of excellent ideas because they feel it will take longer to implement properly and test than the time they have before the next release. In a 12-month cycle, 9 months could be dedicated to development, 3 months to documentation and testing. What an amazing amount of time that would be to get things right. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: getting on a longer release cycled
Hubert Figuiere wrote: I would like to suggest at one point to try to break with the 6 month release schedule of Gnome to do a major release with a certain number of feature that would involve possible infrastructure changes in the platform. I have been thinking about this as well, just from observing how shit hits the fan near the end of the cycle. I'd like to throw out a suggestion that perhaps GNOME should alternate on a six-month-twelve-month release cycle, regardless of major release or not. It might make planning a little more complicated, but I'm sure it would be appreciated by developers and users alike. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Contribution
Maxim Udushlivy wrote: Well, perhaps this dispute is in fact an innovation vs tradition philosophical conflict :) If this is true, there must be a place for both; and HIG's should exist, but only as recommendations, not as constraints. I think that's why they're called guidelines as opposed to rules or requirements. They are recommendations, and many apps break them when they have sufficient reason. The idea is that if there is enough of a reason to break a guideline, then eventually that case should be added to the HIG document itself. So, if the latest fad is to put a Trash my system button right next to the Save button on the toolbar, and enough programs see it as useful, then it will be added at some point. :) On the project I work on, Celestia, my goal is to have a UI that is consistent with the Windows UI, so that it's literally a port. To that end, some things follow the HIG (I have dialog buttons at the bottom of the window as opposed to the side), and other elements from the Windows UI are kept for consistency. I think I've reached a fairly decent balance. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: sticky-notes - tomboy conversion
Alex Jones wrote: Are we really deprecating Sticky Notes? :( I hope not. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: icon naming spec and gnome-vfs
David Zeuthen wrote: On Mon, 2006-07-31 at 18:06 -0400, Rodney Dawes wrote: I will however, disagree that we need to provide such explicit icons as to state what method a hard disk is connect to the computer through, or what type of data is contained on an optical disc, in a base GNOME install. Speaking of which: the latest GNOME has a castrated icon theme that does not show me what type of image the icon represents, nor what type of audio file I'm clicking on. These icons have succumbed to being treated as such explicit icons in the base GNOME install during the last release cycle. The problem is, as a user, I can't get the old icons back, and certainly not from an official source. So we have to treat the base GNOME install as the de facto GNOME install. David is right: the more information the icons can provide, the better. I don't know where you get the funny idea that the less information the icons provides, the better. Please stop destroying the wonderful icons. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: icon naming spec and gnome-vfs
Jakub Steiner wrote: An image thumbnail will give you much more information than a text label on a tiny icon and that is likely to be the default case on the GNOME desktop. Unless, like me, you're always converting images that are large and you don't want to thumbnail, but you want to quickly distinguish between the TIFF and the JPEG. This leads in to the further discussion. I always intended to draw the specific media icons, but I really hope to see infrastructure for getting the generic fallback in place first so that theming is actually a solution and not an excuse. In the past I've been adding specific icons to gnome icon theme, while not being able to make them properly in all the required sizes, only to see distributions fail to theme the set properly. The concept of themes makes us look unpolished without a decent concept of generic fallback. So let's go from generic to specific -- properly providing all sizes, ending up in a consistently looking desktop sooner. It sounds like the old argument that we need a generic overlay mechanism, like the emblems. Nautilus (or a level higher) needs to be able to overlay information over a generic-ish icon. Then we can have device icons with added information. Then we can have thumbnails with something distinguishing between the types. I know some people think this is useless, I couldn't disagree more. Then we have a configuration switch to turn that all off if the person doesn't want it or the overhead that would go with it. Then everyone is happy. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: icon naming spec and gnome-vfs
Jakub Steiner wrote: I don't know how much time exactly went into gnome icon theme over the years, but I do feel like we failed to provide a good icon theming platform for distributions. Back then we had old Gnome 1.0 styled icons inconsistency. Then I tried to create an icon for every single random mimetype people requested. Yes we had all the various CD media icons. But there's less artists than there are free software hackers, and there isn't too many of those either. Ad-hoc naming, missing sizes and thus blurry icons for small sizes and a general mess was the result. In my opinion, while 1.x was horribly inconsistent with icons, you guys did an amazing job for the early 2.x days, which had a good balance of icons. So yea, a specific tiff icon would be nice, but does it have to come now? Does it have to be in the core icon theme? Before we make sure all icons are named properly, have all the sizes provided, include the artwork source I don't think we should worry about those yet. I'm talking about the filetypes now, I'm going a bit soft on the device icons now.. :) In my opinion, yes, it has to come now, or it will never come. It is already a regression that it was there and is no longer there. I prefer the look of my 2.8 desktop with icons that were consistent enough to my 2.12 desktop where I've lost information that was presented to me before. I agree that the old way was not maintainable. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Workplace: a bright new idea
Alexey Rusakov wrote: Pat Suwalski пишет: My question regarding usability is: so now I have to move all my windows out of the way to get to the desklets that provide the functionality that is currently in my panel? This is the main problem with gdesklets, I think. You have to move/resize windows away manually, to show gdesklets. Of course, there is 'Show desktop', but it's much easier just to glance at a certain part of the screen, without pressing real or virtual buttons. I actually got a private response to that message. Apparently one of the goals of the panels is that they can float. So, the panel would be a lot like the current panel except that it would house desklets. The idea is apparently similar to what Vista is doing, where (at least in screenshots) you can see panels usually on the right side of the screen that are not stuck to the desktop. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Workplace: a bright new idea
Shaneeb Kamran wrote: I have a new idea to discuss from the top of my head about the so-called desktop interface. The idea is mainly derived from Mac Os X Dashboard and the upcoming Windows Vista 'Gadgets'. Please note that the following paragraphs are just my plans, and nothing of that sort actually exists. After reading the entire eMail, I don't see a very large distinction between what you propose and using the existing desktop, writing a few new gdesklets (you might want to look these up if you're not familiar with them), and removing the traditional panels. The idea of grouping the desklets into panels is something that is new to me, but while a nice feature, it's not the main innovative element. My question regarding usability is: so now I have to move all my windows out of the way to get to the desklets that provide the functionality that is currently in my panel? Please comment as to how you think of the idea as i want opinion and advice before i start this project. Moreover, being a newbie programmer(i am just a 16 year old hacker) i want help and support to go ahead, so please tell me if your interested in helping me. Don't let age get in the way. As I'm sure you know, the internet has the fantastic ability to let people's skills and talents get through without worrying about things that don't matter. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Some feedback
Radu Olaru wrote: step. Copying dialog, Package Update progress dialog and so on. My suggestion would be to make a small applet responsable of showing every background task's progress and cut down every progress dialog. This way the whole desktop will be cleaner and less windows will pop when you least expect. If it's a background job, why displaying it's progress in This is interesting. So you are suggesting a sort of menu, perhaps similar to NetworkManagers that simply drops down a list of combined progress bars? That would be a very cool feature, though it would require GTK (or something) to have a common interface for percentage setting and communicating it over dbus. Anyone else think this would be an interesting approach? --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Desktop as Nautilus
Who wrote: Given that we currently use Nautilus for the desktop, it is not much hacking to include at least a Gconf key to enable users to browse using their desktop? It breaks the analogy of the desktop being (mostly) static. Anything activated from the desktop goes in a new window, though the state of the desktop can be moved around. Having live content on the desktop necessitates more widgets and more complication. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Desktop as Nautilus
Your ideas are interesting: TRANS wrote: My idea is this. I would really like it if my Desktop actually were the File Browser. In other words instead of having a seperate Desktop/ directory in my home directory, the desktop could actually reflect my home directory (or any other defaut directory I tell it too for that matter), but more that this, to be able to navigate thru the file heirarchy like one normally does with Nautilus, but without the need for a seperate window. An optional split pane mode would also be useful in this design (like MC). And if you want to go a step further, some cool transition effects between directory changes ;-) Having desktop-as-home is actually a Nautilus option already, though the people who wrote it do not support it. I use it, because like you, I think it's a very natural approach to where things are. See the gconf key: /apps/nautilus/preferences/desktop_is_home_dir (bool) As to actually making it a browsable interface, I'm not sure I can visualize how that would work. Most people are not fans of live desktops, like what Microsoft tried back in 1996. I think it is generally believed that it makes sense to do a fundamental task like browsing folders in a window that does not get covered by other windows. To me this would be a much more natural way of working with my system. Just by hitting the Desktop icon on my toolbar, up pops file Is this so much different than hitting the Nautilus browse launcher icon? --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
Federico Mena Quintero wrote: - how long does nautilus take to pick up the pixmap and repaint its desktop window. That takes about 1 second for me, due to XRENDER bugs. This last one should be better on Radeon cards if you cvs update your GTK+. I put a workaround for the relevant Cairo/XRENDER bugs. I applied the patch (gtk2-117163-cairo-repeat-pattern-workaround.diff), to Gentoo's gtk+-2.8.11 and it makes Gnome much smoother and snappier, even running at 600MHz off of battery. I feel that combined with the removal of the 300ms delay, the problem is solved. Now, if only to get the useful icons back... sigh... --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Science/Engineering Menus.
Hello, While I'm bug-mongering gnome-icon-theme, could someone look at: http://bugzilla.gnome.org/show_bug.cgi?id=140900 I've been trying to get attention with it, as it's a minute change that would make a fair bit of difference to a lot of third-party applications. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
Matthias Clasen wrote: 2) We also want the icons back Yes, this is definitely still a big issue. Unlike the instant-apply behaviour, this particular change was never explained in detail. The dialog looks very much out of place without them. I find the dialog harder to use without them. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
Rodney Dawes wrote: 1) GtkOptionMenu is deprecated. 2) GtkComboBox makes it very difficult to add icons to the drop-down. These two are valid points. 3) The icons were a total hack anyway, and broke a11y functionality 4) We have too many icons in use in the desktop, and so I, as well as the artists who maintain the icons, want to reduce that number 5) To help separate the controls within the dialog for managing the wallpapers and properties on them, and the buttons for the dialog These I have a hard time buying. Taking this from the opposite approach, how on earth is a user supposed to know the difference between Scaled and Fill Screen without that little icon to show what's going to happen? I personally find the tiled icon very helpful, as well as the Add and Remove icons. They tell me a lot, help me make a quick decision. The gradient icons are less useful, but they show a little preview of what will happen without the composed textured like in the larger preview icons. They are needed. It used to be that adding icons to interfaces would help dumb users (or me on a Monday morning). Now we're being told the opposite? --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nautilus Unable to Preview GIMP Files with Hidden Background
Hello, Chris Spencer wrote: I've noticed that Nautilus doesn't create a preview for GIMP xcf files if you hide the background layer. It doesn't seem to mind if any other layers are hidden or not, but if the background layer is hidden then Nautilus won't display a thumbnail. Has anyone else noticed this? Is there a reason for this behavior, or should I submit a bug report? To the best of my knowledge, the Nautilus thumbnailer simply extracts and displays the thumbnail in the .xcf file, so this would be a Gimp bug. However, creating an image with two layers and toggling the background, I cannot reproduce this. This is Gimp 2.2.10. If you feel it's a genuine bug, please file it. If your Gimp is older, see if there is a bug against its thumbnail generation that has already been marked fixed. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
Thomas Wood wrote: I was thinking of doing some work on the theme manager UI for 2.16. Should the theme manager be switched to explicit apply too? It often takes more than a second to apply a theme. The best way to see what your desktop will look like is to click one of the themes and see what your desktop looks like! There's a handy revert button, and it should be quite discoverable to click back on the theme that was previously selected. Is this not the case? --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
Thomas Wood wrote: Is this not the case? This isn't really the issue. The problem is that the apply procedure takes more than a second to complete, thus violating the previously mentioned section of the HIG about instant apply. Then the solution should be to paint the desktop with the selected background colour until the image is ready. The colour could be applied instantly, which would give some notion of progress. But the painting speed could definitely be fixed. Unfortunately, I've noticed severe slowdowns in painting throughout the desktop since Cairo came in. It's a worthwhile change, but optimization is required. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
Owen Taylor wrote: I think the first step is for someone to simply spend a little time figuring out what is slow: - Gradients - Scaled images - Solid color backgrounds? 30 seconds of experimentation shows me that scaling and filling are slow, while tiling is very fast. The very strange discrepancy is that when setting an image smaller than the screen, centering is slow! If we are scaling images *via Cairo* that is known to be slow with older X servers; if investigation proves that actually is the problem, it can be worked around. All of my observations are on X.org 7.0.0 with the radeon driver. There were previously (6 months ago?) bigger performance problems, but when I opened a freedesktop bug about it, the whole XaaOffscreenPixmaps issues was brought up. I don't know how that concluded. Adding the Exa extension slows down my r200 card another 2-3 times. But that is getting off-topic. It used to be relatively simple to spot gtk/gdk drawing problems. Now, it's difficult to say where the problems are, given the gtk-cairo-exa-newX stack. For people interested, there is a good discussion in a now-closed bug that addresses some of the slow drawing issues, which I think at this point are history: http://bugzilla.gnome.org/show_bug.cgi?id=314616 But I wonder if the relevant functions don't need to be revisited? Does anyone have any suggestions on how to profile these issues? --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
James Livingston wrote: One thing I noticed is that the time is greatly affected by whether Nautilus is drawing the desktop or not. I normally don't, but when turned on the time was up to around a second. Drawing the icons and text might take extra time, but is there something Nautilus is doing that causes it to go that much slower? BINGO. This narrows in on the culprit. Disabling show_desktop makes the whole desktop 3-4 times more snappy, especially with EXA. It appears that (at least with radeon), nautilus' desktop drawing breaks very drastically. But even with top-of-the-line nVidia (with closed driver), desktop scaling speed is very much improved without nautilus. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
Owen Taylor wrote: So if things roughly double in speed when you disable nautilus, this is about what is expected. Perhaps this is one of those lovely O^2 operations or something, but it's a transition from about 30 fps to about 1 fps. There is almost certainly more to it --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
Elijah Newren wrote: http://bugzilla.gnome.org/show_bug.cgi?id=327335. I'm with Federico though in thinking we should make it fast instead. If memory serves, the background resampling and applying used to be very snappy and got significantly slower when everything moved to cairo. At this point, I have the X hashed background until a few seconds after my panels show up. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
Mark Rosenstand wrote: Without actually using the stuff, I think this sounds pretty much like what HAL does (and g-p-m uses.) HAL avoids doing policy. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Trying to reach consensus for the proposed modules
Elijah Newren wrote: gedit 2.13.x also depends on g-p-e, for the new python plugins (like the Snippets Plugin [1]). It requires at least the gtksourceview module, and perhaps the gnome-print bindings (I'm not sure). The previous consensus and agreement was that desktop modules could depend upon python bindings found in the bindings release set. gnome-python-extras isn't part of that set. As pointed out in Murray's email, it's not suitable for that set either. So we need to determine what we want to do and reach consensus on this point as well. A variety of options exist: I'll bring a conservative point of view forward: binding inclusion aside, does this make gedit any faster? Does it make it slower? Slower is not acceptable, as gedit has been feeling slower and slower every release. Maybe it's time for a gedit-lite that bears much more resemblance to Windows notepad than where gedit is going. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Trying to reach consensus for the proposed modules
Steve Frécinaux wrote: You must agree that Notepad is just a piece of crap. Yes and no. For viewing things it would be perfectly okay if it could handle foreign forms of line breaks. But I digress. The keyword is simple. As Paolo Borelli said, the new gedit is faster than the old one. It has been partly rewritten and gained some needed features. Some of them, rarely used, has even been removed to be reimplemented as optional plugins. When a developer says it is faster, I cannot necessarily take it at face value. For example, Gimp 2.x is undeniably faster than Gimp 1.x, but its startup time is longer. Is it, therefore, faster? So, if I use Gimp as an image viewer, it's slower from my point of view. I use gedit more as a viewer than an editor. If startup time is any longer than before, then it is slower, from my point of view. I'm simply sounding a note of caution. There were some plans at one point to rewrite large parts of EOG in Python. Thankfully it fell through, as that would have been pointless breakage of a near-perfect application. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Browser Mode by Default [Was: Nautilus]
Shane O'Connor wrote: In all fairness, do you expect that the ones who like spatial would ask why browser isn't default? Perhaps, but in all the time we had browser as the default I never once heard anyone complain about it or ask why we couldn't have spatial mode as default. Sir, your history is wrong. Your statement is hardly conclusive, seeing as there was no spatial when browser was default. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Browser Mode by Default [Was: Nautilus]
Shane O'Connor wrote: I didn't mean to open a can of worms ;) The only reason I posted was because quite a few users have asked me recently why the default is spatial, all of whom don't like it. In all fairness, do you expect that the ones who like spatial would ask why browser isn't default? --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Color independent themes
Jason J. Herne wrote: Now, I may not understand everything to due with themes, but wouldn't it be relatively easy to create themes that allow the user to change the color scheme? The theme author would simply define a set number of colors (with default RGB values) and name them something like WINDOW_BORDER_GRADIENT_A and WINDOW_BORDER_GRADIENT_B and then if you want your window border to fade from blue to blank instead of red to black, you would simply edit the RGB values of the colors on a nice GUI form, part of the Gnome theme manager. A side effect of this may be that graphics created for themes should be grayscale? Just some thoughts... let me know what you think. The problem here (for a GUI) is the sheer variety of capabilities in a theme engine. Some might have gradientA-gradientB, some might have 3 or more gradients. No generic GUI could handle that. If you look at Clearlooks as an example, there are three themes with it, and they each specify all of the colours that the theme engine itself understands. IIRC, back in the Gnome 1.x days, the theme engine provided the interface for setting colours. Maybe going back to something like that would make sense? --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: EOG features
Stanislav Brabec wrote: This calls for: - Not creating thumbnail, if it is already present in the image itself and can be extracted in miliseconds. - Not creating thumbnails for small images. - Use of jpeg for thumbnails of jpeg images. - Not saving rotation, if it is already OK in the EXIF tag. And perhaps having Nautilus use the exif thumbnail if it exists? I'm told this is broken when it comes from many cameras, but it could sure speed things up. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: EOG features
Lucas Rocha wrote: with a Save copy one, like Evince; 3) auto-rotate images based on EXIF data. Very few cameras seem to have the mercury sensor needed to make the tag required here. Apart from the D-SLRs I've never encountered one. I also want to raise a few issues, in advance. Lots of programs simply get this rotating wrong. gThumb rotates the image and the tag after that. For programs that handle viewing correctly, it puts it an extra 90-degrees too far. My patch for that (hint, hint!): http://bugzilla.gnome.org/show_bug.cgi?id=318828 f-spot does this right, though it also updates the DateTime field in the exif tags. Larry's convinced me that that is the correct way to do it, and EoG should probably do the same. However, I'm working on a trivial patch to the Nautilus image properties tab, which uses DateTime instead of DateTimeOriginal (if available) as the original Date. On images rotated with f-spot, the date Nautilus shows becomes the rotatation date. Just my 0.02 zł on an pet peave. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: EOG features
Scott J. Harmon wrote: A question I have, is how does EOG relate to gthumb? (i.e. why should I have both? If I should, when should I use EOG instead of gthumb?) It seems that gthumb does all that EOG does and allows simple editing. It also doesn't handle the factor of simplicity very well. When I double-click on a photo, I want to see the photo. Not thumbnails, a directory browser, two rows of toolbars, packed menus, etc. EoG is more of Windows Image Viewer or MacOS Preview.app than Picassa or f-spot. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal for inclusion in Desktop: pessulus
Jeff Waugh wrote: Could we have a separate 'Administrator Tools' release set? I suppose we could, but what would be the point? We aren't categorizing any of our other modules. Which is a problem. I fully support the creation of an admin release suite. How would this look in terms of the release? The release would obviously coincide with the gnome-desktop release. The source tarballs would be in the same place. So the only difference would be suggested grouping to indicate to distros how to categorize their packages and/or create a gnome-admin metapackage? --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal for inclusion in desktop: gnome-screensaver
William Jon McCann wrote: How about... 3. Unlocking the screen with the root password should do the same as choosing switch users, and logging in as root. Not doing so is a privacy and security issue, as it may allow root access to remote hosts, that root normally does not have access to. Surely you aren't suggesting that people log in to GNOME as root? I'm not sure I understand the use case here. I was thinking that the root password could unlock the screensaver regardless of whose screensaver it is. So, in order: - User password - Success: close screensaver - Failure: - Root password - Success: close screensaver - Failure: continue --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: MOTD implementation in gnome-session
Mark McLoughlin wrote: What kind of information is it especially handy for? Perhaps when you upgrade the desktop and you want to warn people that stuff has changed? But not for stuff like internet will be down for a while today because people may not actually log out that often? At a university, people will typically log in for 15 minutes, check eMail, course sites, etc. Then they will log out and go to class or lunch and come back and hour or two later. In the Windows network at my school they actually fullscreen-mode IE to show this sort of stuff. Extremely annoying. A notification-area message would be infinitely better. Is login the best time to show this information or would you prefer if the user saw it immediately? It might be nice to have GDM display this kind of information, polling for changes to /etc/motd every minute or so instead. Would you expect each user to see this information only once? i.e. if you immediately logged out and back in again should you see the same message? Sure, why not? snip I do get that something along these lines would be useful for admins, but it strikes me that some crufty old unix hacker designed /etc/motd at least a couple of decades ago and perhaps we could put some thought into how whether that design best meets a desktop admin's requirements? I think a very simple solution that is not overcomplicated (like remembering which messages have been read, etc) is a good thing. Anything more complicated is what eMail exists for. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcing: Project Ridley
Grzegorz Dąbrowski wrote: It would be nice also include http://gtkglext.sourceforge.net/ I definitely concur here. gtkglext works very well as a GTK based OpenGL widget. I never thought to ask if there is interest in making it part of GTK, but Project Ridley seems a good opportunity to think about it. --Pat ___ desktop-devel-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Trademarked icon in gnome-icon-theme
Jeff Waugh wrote: gnome-icon-theme ships the mozilla.org trademarked firefox logo. Not only do we not have the right to ship this under their licensing requirements, but it would impact on our distributors too. While the obvious solution is to remove it, is there any chance that the Mozilla Foundation could let Gnome ship the logo? How formal of a dialogue would have to be made to make this possible? Is it worth the effort? --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: building GNOME 2.11 on x86_64 using jhbuild
Jeroen Zwartepoorte wrote: Hi, In the last couple of days i've built gnome-2.11 using jhbuild about 10 times so far. It builds fine (uncovered some gcc4-related bugs, filed them and they're fixed; apply a hal patch to n-c-b etc.). This is on a Fedora system, with up-to-date packages from rawhide. However, after it has finished building and you look at which libraries the binaries are linked to, most of them are linked to /usr/lib64 libraries instead of /home/jeroen/Gnome/built/lib64. I've tried *lots* of things, but nothing helped. LD_LIBRARY_PATH is pointing to /home/jeroen/Gnome/built/lib64. I even went as far as to strace gnome-about and it *doesn't even look* in /home/jeroen/Gnome/built/lib64: I was hoping to test your theory this evening, but I can't get very far in the build, which dies at gtk because of: ./.libs/libgtk-x11-2.0.so: undefined reference to `g_utf8_collate_key_for_filename' Anyway, using the libraries that had already been built, Gentoo ldd reports that they're all linked to libraries in my build target: [EMAIL PROTECTED] /opt/g212/lib64 $ ls /opt/g212/ bin etc include lib64 man share [EMAIL PROTECTED] /opt/g212/lib64 $ ldd /opt/g212/lib64/libatk-1.0.so libgobject-2.0.so.0 = /opt/g212/lib64/libgobject-2.0.so.0 (0x2abcb000) libgmodule-2.0.so.0 = /opt/g212/lib64/libgmodule-2.0.so.0 (0x2ad0b000) libdl.so.2 = /lib/libdl.so.2 (0x2ae24000) libglib-2.0.so.0 = /opt/g212/lib64/libglib-2.0.so.0 (0x2af27000) libc.so.6 = /lib/libc.so.6 (0x2b0b2000) /lib64/ld-linux-x86-64.so.2 (0x5000) [EMAIL PROTECTED] /opt/g212/lib64 $ Is this different than what you have? --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: building GNOME 2.11 on x86_64 using jhbuild
Pat Suwalski wrote: I was hoping to test your theory this evening, but I can't get very far in the build, which dies at gtk because of: ./.libs/libgtk-x11-2.0.so: undefined reference to `g_utf8_collate_key_for_filename' On further thought, this must be because it's trying to link against what's in /usr rather that /opt/g212. This appears the same problem you have, except that I cannot explain how you got past the gtk+ build. This is clearly because the libraries are explicitly specified (/usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so /usr/lib/libglib-2.0.so): gcc -g -O2 -g -Wall -o .libs/gtk-query-immodules-2.0 queryimmodules.o ./.libs/libgtk-x11-2.0.so -L/opt/g212/lib64 /home/pat/cvs/gnome2/gtk+/gdk/.libs/libgdk-x11-2.0.so -L/usr/lib64 /usr/lib/libatk-1.0.so ../gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so ../gdk/.libs/libgdk-x11-2.0.so -lXrandr -lXinerama /opt/g212/lib64/libXft.so -lXfixes -lXcursor /usr/lib/libpangoxft-1.0.so /opt/g212/lib64/libpangocairo-1.0.so /opt/g212/lib64/libcairo.so /opt/g212/lib64/libpixman.so /opt/g212/lib64/libpangoft2-1.0.so /opt/g212/lib64/libpango-1.0.so /opt/g212/lib64/libfontconfig.so /usr/lib/libcairo.so -lXext /usr/lib/libglitz.so /usr/lib/libfontconfig.so /usr/lib/libfreetype.so /usr/lib/libexpat.so /usr/lib/libpixman.so /opt/g212/lib64/libXrender.so -lX11 -lpng12 -lz /usr/lib/libpangox-1.0.so /usr/lib/libpango-1.0.so /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so /usr/lib/libglib-2.0.so /home/pat/cvs/gnome2/gtk+/gdk-pixbuf/.libs/libgdk_pixbuf-2.0.so /opt/g212/lib64/libgmodule-2.0.so -ldl /opt/g212/lib64/libgobject-2.0.so /opt/g212/lib64/libglib-2.0.so -lm -Wl,--rpath -Wl,/opt/g212/lib64 -Wl,--rpath -Wl,/usr/lib --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Evince as universal Viewer
Thom Holwerda wrote: I am a proponent of having an uber image viewer because it greatly improves ease-of-use and consistency; as users are presented with the same interface whether they open a .jpg, .png, or .pdf. Barely anyone edits .pdf files, so I guess that that's the reasoning by Apple to integrate pdf viewing into the image viewer application. There is, however, a very, very large drawback. Right now, Evince is to eventually replace gpdf and ggv. That's okay, but what if it also did replace eog? Then when you have such a large application, what can ever replace it? It becomes a behemoth of a component that can never be removed, is hard to modify, etc. Right now, if (for example) the release team wanted to exchange eog for gthumb, it would be completely possible without duplication of features and minimal headaches. I've always understood the Gnome usability guidelines as one program for one task (I'm paraphrasing here). Same as no MDI; one window for oen document. Perhaps it works in OSX because they treat PDFs as images rather than documents. After all, even screenshots are PDFs. Maybe I'm wrong here, but I would hate for it to be integrated like that, if only because eog starts up really, really quickly; adding anything more to it would make it slow. That's just my point of view on application conglomeration. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Exciting GNOME?
Gabriel Bauman wrote: Most folks I know install GNOME, shudder, then install Bluecurve and never look back. Is it a Red Hat licensing issue perhaps? I would say it's a little more than that. Bluecurve is what identifies RedHat. I don't think that it would be appropriate to use it, legally possible or not. The same applies to Ximian/Novell and Industrial. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
