Re: GNOME Online Accounts 3.34 won't have documents support
(Hopping on to desktop-devel@ to follow up to this) Jeremy Bicha wrote on 23/01/2019 8:21 pm: >… > A few months ago, I talked with mpt about GNOME Online Accounts being > added to Ubuntu's version of gnome-initial-setup. I believe his > opinion was that the app itself should offer the "add a new account" > feature instead of the Initial Setup or Settings apps. >… Yes. This was for two main reasons. First, gnome-initial-setup is pretty much the worst possible time to expect someone to know which accounts, if any, are useful to configure. At that point, someone is unlikely to know even what apps are preinstalled, let alone which of them they’ll want to use, let alone which of them use GOA. For example, even if someone knew that Firefox is preinstalled, and knew in advance that they wanted to use Firefox rather than Chrome or Opera or another browser, and knew that Firefox integrates with Pocket, so they set up a Pocket GOA account from gnome-initial-setup … Even if all those stars aligned, eventually they’d discover that g-i-s had wasted their time, because Firefox doesn’t integrate with GOA. The second reason is more relevant to this discussion: It’s not sensible for any app to be beholden to GOA for its account setup in the first place. This in turn has many factors: * Many of the apps, that Gnome users spend their time using, also run in other environments where GOA doesn’t exist. So the developer has to do their own account UI for those platforms anyway. * As demonstrated by Michael Gratton in this discussion, app vendors can’t rely on GOA including the account type and service type they need in any particular release. This is impractical if they don’t read desktop-devel-list@ frequently, or if their release schedule doesn’t happen to coincide with Gnome’s, or if it doesn’t happen to allow time for suddenly introducing their own account UI because somewhere someone altered a selection of “default apps”. * For some reason that isn’t clear to me, GOA cares what you use each account for, rather than merely recording which apps the user has granted access to each account. Why was there such a thing as “Documents support” in GOA in the first place? This suggests that if Facebook or Google or Microsoft announced and released a new chat app XYZ tomorrow, which integrated with their usual account system, it couldn’t use your Facebook or Google or Microsoft account stored in GOA, because GOA wouldn’t include “XYZ support”. * Even if GOA does contain both the account and the toggle relevant to a particular app, the app may have settings that are account-specific, but which GOA does not include (for example, “which folder should sent messages be filed in” or “which words should be muted in this timeline”). In those cases the app needs per-account settings UI anyway, resulting in a weird bifurcation. * The combination of those reasons, plus all those apps that use accounts of types that GOA doesn’t provide in the first place, reinforces a mental model where GOA is generally not where people expect to find account UI. None of that is to say that GOA shouldn’t exist. It has the potential to save people time. “I set up an account in App A. Now it will be quicker to use the same account in App B.” Anything more than that is noise. Cheers -- mpt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: taking features away (compact view removed from Nautilus)
Allan Day wrote on 02/07/12 09:38: ... Jon has been doing some fantastic work on Nautilus recently. It was getting very little - if any - developer attention and he has stepped up to make dramatic improvements, including addressing long-standing complaints. I'm really excited about the next release of Nautilus thanks to his work; instead of having no movement whatsoever, we are going to have lots of great improvements to talk about. ... You are confusing movement with improvements. -- mpt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On the Interaction with the design team
Lapo Calamandrei wrote on 06/06/11 17:20: ... 2011/6/6 Dave Neary dne...@gnome.org: ... I feel that the current operation of the design team is hurting our relationship with Canonical, who also have designers who have, I believe, failed to influence design discussions in the same measure as the core members of the design team like Lapo, Allan, Jon. However good or bad Gnome's design processes are, I don't think those processes have anything to do with the relationship with Canonical. The reason Canonical designers have not influenced Gnome design discussions is that we are not instructed to take part, and most of us haven't even heard of #gnome-design. (To be clear, nobody's telling us *not* to take part, it's just not part of our jobs.) That may be a good thing or a bad thing. I can certainly see drawbacks: for example, I have lost count of the number of times one of my colleagues has sketched something that assumes the existence of gnome-about-me, and I've had to say uh, that doesn't exist any more. Or when they've talked about having a unified settings panel for online accounts, oblivious to the Web Accounts panel being designed and implemented upstream as they speak. I think the lack of documentation of the core design team makes it harder for new designers to get involved. I do agree with this. For most of the Gnome designs I come across, I think: What stage is this at? Is this supposed to be a draft, or the final design? What alternatives have been considered so far? What benefits and disadvantages have been predicted in each? Have any of the predictions been tested with users? How could I most productively suggest another alternative? Getting answers to those questions shouldn't require waiting for the right person to turn up on IRC. To sum it all up, I believe the current dynamic of the design team is doing damage to GNOME as a community. Would you elaborate this? Adding some facts please? For example, I think a lot of the discontent with Gnome Shell could be calmed if the wireframes of alternatives that were considered were published, and if user testing results were published too. Unfortunatelly IRC is the only tool which work fo us atm (since google pulled wave which was nice), we're very open and responsive on the channel, I listen to every suggestion I get and answer any question, just hang on the channel and see. An XMPP chat room (as used for Inkscape developer discussion, for example) has the relevant advantage that history can be easily available even to people who weren't in the room at the time. Also the repositories we are using are open and everybody can participate. Requiring designers to learn git limits the number and type of designers. I respect and esteem Matthew Paul Thomas which is the only canonical designer I ever interacted with on the channel and I think I have zero issues with him, while I'd like to see him more activelly involved. ... Thank you. The main reason I'm not more actively involved is that when I get home from work I try to focus on things that aren't software. -- mpt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: String change in vino
On Feb 2, 2009, at 12:38 PM, Jonh Wendell wrote: ... I have changed one string in vino capplet: _Configure network automatically to accept connections This is a check button, when checked, it uses UPnP to forward the port on the router, in order to make VNC accessible via Internet. Feel free to suggest other text for this option. As you can see on my blog, there were several suggestions: http://www.bani.com.br/lang/en/2009/01/new-vino-dialognova-tela-do- vino/ ... The other checkboxes in that window are fine, but this one has a common problem with checkboxes: the unchecked state isn't obvious. What does it mean to *not* Configure network automatically to accept connections? Why wouldn't you want Vino to do that? If the answer is You always would, the checkbox probably shouldn't exist. If the answer is You'd want to do X instead, then the checkbox probably should be a pair of radio buttons, with the second one mentioning X. Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: quo vadis, docs
On Feb 9, 2009, at 5:43 PM, Tristan Van Berkom wrote: On Mon, Feb 9, 2009 at 11:52 AM, Luis Villa l...@tieguy.org wrote: [...] Amen. I've often felt developers should be required to document their own UI changes :) Heck, simply asking 'what does this dialog mean' would be useful a lot of the time...[1] Luis do you write software ? Not that its important that you do, but just to clarify the issue; simply asking what does this dialog mean in the long run usually means: - Take a screen shot of the dialog I have good news: Usually taking a screenshot of a dialog for the help is a really bad idea, so you don't need to do it. ;-) Often it doesn't add any insight to the text, sometimes it gets mistaken for the actual interface (as both Novell[1] and Apple[2] have seen), if it's big it won't fit inside a usefully small help window, and it makes the help much harder to localize. [1] http://tinyurl.com/brtw4d (6 minutes video, 48 MB) [2] http://tinyurl.com/d65n9s - Open the html or whatever the docs are written in - take time to format the docs/text/images in a readable way Yes, that's the hard part. - take time to properly describe your feature or functionality More good news: That's also often unnecessary. A description of a feature in checkbox-by-checkbox detail is just as boring to read as it is to write. Instead, think: What are the most likely reasons someone will have trouble here? And what things are people most likely to be looking for under a different name? Answer those questions (without phrasing them as questions) in two or three paragraphs each. http://tinyurl.com/clrt3o Do that, and you'll have something more readable and more useful than ye olde Gnome Application Manuelle V2.7. ... I am going to generalize here and guess that if you are not GTK+, and you are not epiphany or gimp - then its pretty much safe to say you are a one man team plus the occasional extra guy, or a few randomly submitted patches (which often generate more work for the maintainer than bugs fixed or features implemented) - you can hardly find time to update the website when you make a release, much less spend time writing user docs. ... Maybe so, but that doesn't make a completely out-of-date set of help pages any less embarrassing than a completely out-of-date dialog or menu or splash screen. You could be relying on the assumption that no-one reads the help, so hey, doesn't matter if it's completely wrong -- but why take the risk? Instead, I suggest *not having help* unless you have someone on your project team willing and able to keep it up to date. Having the help author actively involved in your project makes it more likely that they'll ask you (or know the answer to) the questions that make the help insightful http://tinyurl.com/bov9oh. It also makes it more likely that they'll suggest you improve the interface instead, or at least embed the help into the application itself where it's much more likely to be read http://keycontent.org/tiki-index.php?page=Embedding+UA. And not having help until then protects users from the breach of trust that would keep them away from the help even after it became accurate http://www.uie.com/articles/documentation/: Once they’re burned by the docs, users typically won’t look there again. Unfortunately, this behavior can persist even after developers fix a problem. Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: notification-daemon+libnotify
Calum Benson wrote on 07/11/08 13:09: On 6 Nov 2008, at 17:38, David Zeuthen wrote: ... There is a high probability that one or more of your hard disk will malfunction within the next 24 hours Your laptop battery is being recalled Security updates available I'm not sure where we'd display stuff like this except for using icons in the notification area. Some sort of status icon change with an appropriate tooltip would probably be sufficient for things that don't need immediate attention. For things that do, or for which there is no status icon, an alert box is often more appropriate anyway. With my Ubuntu hat on, I'll go a little further than that, and say we really would rather application developers didn't use status icons *or* notification bubbles for critical situations like those in David's examples. (Other distributors may, of course, have different opinions.) Status icons are often ignored or not noticed, especially when there are many of them, and notification bubbles work best when they go away by themselves. So while both of them have a purpose, neither of them are suitable for things that people really positively need to respond to. If there is no more pleasant window in which to convey a critical situation like that, use an alert. Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Name vs GenericName (again)
[Sorry for the misthreading; I didn't receive the original.] On Jul 25, 2008, at 2:52 PM, Vincent Untz wrote: ... + when displaying a menu, use this algorithm: - if only one item for some value of GenericName, then display this item as GenericName - if two items for GenericName, then display both items with their names. This way, we'll have Movie Player when only totem is installed, and Totem Movie Player and VLC Movie Player when totem and vnc are installed. Opinions? This would be a clever way of making the menus simpler. However, it would be quite undesirable in two cases. One is where someone is having trouble performing a task, and a friend/relative/workmate is trying to give them phone or chat support. They may take a very long time to realize that they're actually using completely different applications. (What do you mean, there's no 'Navigation' menu? You do have Movie Player open, right??) The other is where an operating system vendor ships version N with application A, but decides to ship version N+1 with application B instead. (A might have been abandoned upstream, or B might have noticably overtaken A in usability.) If the menu gives B the same name as A had, that would cause rage and confusion for those familiar with A. (For a real-life example of this, look up what happened when Apple replaced iMovie with a completely different program also called iMovie.) Neither of these problems apply for programs with very simple scopes and interfaces: for example, if a distributor replaced gcalctool with galculator, it could still be Calculator and no-one would mind. But it does matter for non-trivial programs, such as a movie player, Web browser, or advanced text editor. To address the problem of Gnome programs having non-sequitur names, I have an alternative suggestion: stop giving them non-sequitur names. I know this is the sort of non-technical bug that programmers really don't enjoy fixing, but it's important nonetheless: it would be beneficial for all distributors, none of whom currently have the marketing budget to make (for example) Totem sound like a movie player. This could be done in a couple of ways. First, to avoid the problem getting worse, those considering new modules for inclusion could consider whether they have either a strong independent marketing effort to associate their name with their task (like Firefox and Miro do, to pick two non-Gnome examples), *or* a name obviously related to their function (like Gossip and Rhythmbox do). If they have neither, that's a point against them. Second, each cycle there could be a vote on which module needs renaming the most -- which application's name is least helpful in getting people to use systems that include it. Then it could be a Gnome Goal for that cycle to brainstorm a better name, rename the project, update its help, get it a cool new Web site, and make a new release with the new name. Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ---AV Spam Filtering by M+Guardian - Risk Free Email (TM)--- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Session Management in 2.24
Emmanuele Bassi wrote on 25/03/08 17:01: On Tue, 2008-03-25 at 11:37 +0800, [EMAIL PROTECTED] wrote: ... Is it possible to add a extra task to improve logout dialog GUI? The current dialog in new-gnome-session is exactly the same as gnome-panel. Can we do as Ubuntu's own dialog, such as change button layout, show button bigger and more striking, add icon and tooltip text for each button? If it makes sense, I would like try. no, please: don't. I personally loathe that logout dialog, and love the default GNOME one, as it's less in your face and flashy. ... FWIW, we're intending to change the logout/shutdown process substantially in future Ubuntu releases, and the current plan (though this may change) is to get rid of that big dialog. https://wiki.ubuntu.com/DesktopTeam/Specs/ExitStrategy So I agree Gnome shouldn't use our current dialog as a model. :-) Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Usability] application names in the application menu
Le vendredi 28 mars 2008 à 18:30 +0100, daniel g. siegel a écrit : ... recently, i showed some pupils the gnome desktop and what i noticed was, that they even didnt know what Cheese meaned, or what program would open if he had clicked on it. this wasnt only on cheese, but also on epiphany, dasher, and others (some choose their name like [name] [small description], e.g. f-spot photo manager, which is more understandable, even if the program name doesnt make sense for a person, which is new to gnome). They just could figure it out, by interpreting the icon. ... If a program has a name obviously related to what it does, *or* lots of marketing, you're fine. But if you're missing both, people will have trouble working out what the program is for. Programs that have both an obvious name, and lots of marketing: Illustrator, Internet Explorer, iMovie, iPhoto, iTunes, Photoshop, Windows Media Player, Word. Programs that have lots of marketing, without an obvious name: Access, Excel, Firefox, Opera, Outlook, Outlook Express, PowerPoint, QuickTime, Safari. Programs that have an obvious name, without lots of marketing: Calculator, Dictionary, Inkscape, Interface Builder, Notepad, OpenOffice.org, Photo Booth, Rhythmbox, TextEdit. Programs that have neither: Banshee, Blam, Bluefish, Brasero, Cheese, Claws, Dasher, Ekiga, Epiphany, Evolution, Exaile, Gimp, Glade, Jokosher, Kino, Miro, Muine, Pitivi, Serpentine, Sound Juicer, Straw, Synaptic, Tomboy. Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.23 Schedule
natan yellin wrote on 21/03/08 07:32: On 3/20/08, *Federico Mena Quintero* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: ... The problem we've had so far is that someone does a good analysis of login time, things get fixed, but then over time things get gradually worse. Mozilla uses Tinderbox to constantly rebuild software, and then tests each successful build to measure how long it takes to start up (amongst other things). http://tinyurl.com/2shnre This lets developers see performance regressions as soon as they happen. Perhaps something similar is possible for Gnome. It would be nice to be able to get a fresh profile at any moment, just to see that things didn't get screwed up. A Guest account, which has a fresh profile on every login, would also be a useful feature for those cases where I lend my laptop to someone for a few minutes so they can check their e-mail. (I don't want to have to set up a new user account for someone who probably won't use that computer again.) ... Ubuntu's new brainstorm page is pretty cool. Would you have time to implement something similar for GNOME? I quite like the idea of a digg for feature ideas that we could reuse in various places. It would be useful, but perhaps it would be better to just get our own category over there. The number of people who use Gnome without it being supplied as part of their operating system is tiny, so it would likely make little sense for Gnome to have its own Brainstorm site. However, Ubuntu is not the only operating system that uses Gnome, and it would be unreasonable for (for example) people interested in proposing an idea for Gnome in Opensuse to be pointed to an Ubuntu site. If we have our own brainstorm website, a lot of the ideas are going to be duplicates and there'll be two places to discuss and vote on everything. ... We already have that problem in Ubuntu itself, with at least four different places to propose ideas (Brainstorm, Launchpad Bugs, Launchpad Blueprints, and various pages on the Ubuntu wiki). Ideally there would be a way of linking and syncing feature requests between Ubuntu and the various other operating systems that use Gnome -- similar to how Launchpad links and syncs the status of bug reports in bugzilla.gnome.org and other bug trackers. However, the first step would be to have a semi-standard way of representing feature requests, and that hasn't happened yet (bug : bug report :: feature request : ???). Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: HIG says Page Setup not Page Setup...
On Feb 5, 2008, at 8:41 AM, Shaun McCance wrote: ... To me, the ellipsis indicates that you're going to see a dialog that's sitting *between* you and the action you've selected. [File-Print...] - [dialog] - [printer whis] [File-Save As...] - [dialog] - [icon appears in Nautilus] A dialog is one way of asking for further input, but not the only way. For example, Nautilus's Rename... item correctly has an ellipsis, but doesn't use a dialog. We specifically exclude this case though: [File-Frobnicate] - [really?] - [frobnicate] (Eventually I think we should abolish this exception. As far as I can tell, it exists mainly because of the Save changes before closing? alert: changing Close... to Close whenever you saved a document, and back to Close... when you next changed it, would be too much of a hassle for programmers. This could be avoided, eventually, by abolishing the idea of saving, which by itself would make confirmation alerts much rarer.) For Preferences or Page Setup, the dialog is what you're intending to do. I think the HIG's recommendation of Preferences over Preferences... is also a bug. http://bugzilla.gnome.org/show_bug.cgi?id=169447 With the exception of user interface designers, nobody ever intends to do a dialog. Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: HIG says Page Setup not Page Setup...
Luca Ferretti wrote: I've just opened bugs against eog, evince, evolution and gedit to remove the trailing ellipsis from File-Page Setup menu entry. Bugs are 514352, 524354, 514355, 514356. If you know other applications that need to be fixed, please let me know. ... That's a bug in the HIG, not a bug in the applications. Please report it against the HIG instead. :-) Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Web links integration in applications: bugs, translations, help...
On Nov 28, 2007, at 8:33 AM, Loïc Minier wrote: On Tue, Nov 27, 2007, Andre Klapper wrote: ... i love firefox because of explanations that even my parents would understand, if they'd touch computers. The page you are trying to view contains POSTDATA that has expired from cache. but currently, 30% of non-crasher evolution reports are already can't send mail. please help reports, because of the Submit Bug Report menu item. i have the feeling it will become more. ;-) Hehe, I heard from our Firefox maintainer that he receives all kind of non-bug reports thanks to the Help Report a problem menu entry in Ubuntu; My wife is gone, My cat is sick etc. :) I think linking to a bug tracker directly makes sense only if your user base is less than about five million (plus or minus a few million). Beyond that, the signal-to-noise ratio gets too low to be worth it. I guess the problem of receiving can't send mail bug reports might be helped a little by having two different entries in Help; Ubuntu currently has Report a Problem (it's report a bug in French though), and Get help online Not so helpful if the reason you can't send mail is that you aren't online. ;-) (this points to the community support portal). ... This requires people to choose immediately which source of help is more likely to answer their question -- Help Contents or Get Help Online -- without having any of the knowledge necessary to make that decision. A more humane approach would be to provide a smooth escalation path: built-in help - on-line help - support forums or paid support. That still means you need external URLs, just not in the Help menu itself. For example, if you do a search in Yelp and none of the results are what you're looking for, the search results page gives you a link to try the same search on gnomesupport.org. That link is designed to be customizable by distributors, so it can search the distribution's knowledge base or support forums instead. Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk_show_help and gtk_show_url
On Oct 26, 2007, at 10:14 AM, Shaun McCance wrote: On Thu, 2007-10-25 at 17:36 -0700, Matthew Paul Thomas wrote: ... I think that's a valid concern, but an annoying solution. I would rather that any updated API for opening a help page in Gnome had two compulsory parameters -- one for the page ID, and one for a fallback search string if Yelp can't find the page. That way the page-not-found error would only ever appear when debugging. This is an interesting idea. But it leaves me with a few questions. * Under what circumstances would the application and the help files ever become out of sync? We release them in the same package, so they should (in theory) always be in sync with each other. So I guess the answer is in practice. ;-) I've seen the The Uniform Resource Identifier ’file://some.long.and.scary.url’ is invalid or does not point to an actual file alert several times in Gnome, and I expect it to become more frequent as programs use context-sensitive help more often and that help becomes more extensive and frequently edited. Note that: - gnome-doc-utils contains a little-used utility that generates a header file with symbols for each page. That's good, but I think error recovery baked in to the API will inevitably be more robust than error recovery that relies on the use of a particular authoring tool ... - Both DocBook and Mallard provide a means of putting additional anchors on things. So when you do some sort of surgery on your document, you really ought to put an auxiliary ID somewhere so that links don't break. ... or error recovery that relies on authors remembering to do optional things. - In practice, I realize it's common for the help files not to keep up with the application. But this is not the sort of thing that causes broken IDs. Also, search strings wouldn't help much, because in these cases, the content just isn't there. Right, I'm not claiming a search string would fix all problems with broken IDs, just two of them: (1) the relevant file has been renamed, and (2) the relevant help has been merged into another file. * A search string really should be translated if it's pointing to translated help. But if it's pointing to English help, it shouldn't be translated, even if the application is translated. Currently, our application translations are much more complete than our document translations. So I'd be worried that this would cause a different sort of out-of-syncness: a German search string getting used on an English document. That's an interesting problem, but search results would be more useful more often than an error message, regardless of whether that error message was localized. (Namely, search results would be more useful whenever the topic being searched for contained untranslated words, such as proper nouns.) One approach would be to put (a more human-friendly version of) the localized error message at the beginning of the search results. That topic wasn’t found. Try these suggestions: * In my experience, when you have compulsory parameters that don't usually do anything, most people will just do what they need to shut up the compiler. So instead of this: gtk_help_show (user-guide, printer-configure, anchor, configure printer); They'll do this: gtk_help_show (user-guide, printer-configure, anchor, ); Alternately, they might write very unhelpful help strings, because they're in a hurry to write real code, and don't want to think about help stuff. ... I agree -- we've seen this in HTML with img alt=. This case would be different, though, in that people wouldn't be any *worse* off with search text of than they were with the error alert (especially if a brief explanation was prepended to the search results as I described above). Meanwhile, some authors would have been prompted into providing useful search strings when they wouldn't have otherwise, making help more reliable on average than if the parameter was optional. Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Panel++
On Sep 24, 2007, at 3:00 PM, Alex Jones wrote: ... What do we want from the next version of GNOME Panel? Do we want to evolve it or just replace the dependency on Bonobo for now? I think that unifying the concept of applets and more heavyweight widgets might be beneficial, unless anyone can think of any good reason why not to. Any GDesklets developers here? ... Besides the lack of a global menu bar, which John Stowers mentioned, another irritant interaction-wise is inconsistency in behavior between panel applets. Some applets do something on a single click, others don't, and there's no way to tell which just by looking. Some applets do something on a double click, others don't, and there's no way to tell which just by looking. Some applets open a menu or menu-like control, but they differ in whether they make it look like a menu, and if you mouse down on the wrong one you can't slide over to the correct one like you can with a normal menu bar. It would be really neat if the panel could make these behaviors consistent. Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Thoughts on patch for gcalctool bug #448263
On Jun 18, 2007, at 4:08 AM, Don Scorgie wrote: ... We're currently working on yelp (really, we are working on it!). It's hoped that soon, there will be a mechanism to launch yelp through dbus and improved the handling of starting through the command line. This will have an advantage for modules wanting to drop libgnome. Yelp will handle all parsing of uris. One thing I've been contemplating is how to handle invalid requests (i.e. asking for a non-installed document). If yelp handles it, it simplifies translators lives (as the strings won't occur in every module) and would improve consistency (error message is the same every time). However, would this look out-of-place (i.e. will the popped up unexpectedly placed)?. ... Yes it would ... regardless of where it was placed. People distrust computerized help at the best of times. If you want someone to never use the help in any Gnome program ever again, putting up an error message when they click a Help button is an *excellent* way of doing it. ;-) It's inevitable that occasionally programs will link to help pages that don't exist, or that help pages will link to other pages that no longer exist. But that's the kind of error that should be displayed only to developers, not to other users. Users should be shown relevant search results as a fallback instead. You can achieve this by giving the API for opening a particular help document two mandatory arguments (and giving the internal hyperlink syntax in Mallard two required attributes): one being the URI of the document, the other being relevant search terms for Yelp to fall back to if the document doesn't exist. Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: seahorse
On Jan 12, 2007, at 1:34 AM, Vincent Untz wrote: ... I love seahorse and I want it in. I liked how the maintainers quickly replied to our questions, and implemented additional features. Nate Nielsen has also been very responsive to reports of usability glitches, and even submitted Seahorse's worst dialogs to usability@ for redesign. Hooray for Seahorse! :-) -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Software installation using gnome
On Jan 6, 2007, at 12:21 PM, Toby Smithe wrote: On Wed, 2007-01-03 at 12:21 -0800, Sri Ramkrishna wrote: This is primarily why it's difficult to get commercial applications on GNOME. They have to make packages for every flavor of distributions out there. We have yet to get a standard in package management. Packages could just be installed, with all their dependencies, locally - like they are on Windows. However, this always seemed a waste of space to me: why have more than one copy of a library file installed? ... Because the cost of disk space is less than US$0.0005/MB, and dropping. Of course there are other reasons for applications to use the same copy of a library (such as lower memory consumption and easier security updates). But if you are optimizing for disk space consumption rather than for the ability of people to install software *at all*, you are solving the wrong problem. Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moving spellcheckers into the Gtk+ stack
On Dec 19, 2006, at 1:02 AM, Danilo Šegan wrote: On Friday at 23:42, Matthew Paul Thomas wrote: Right, and the reason Epiphany can't *solely* use the language from the locale is that (as I understand it) the locale can refer to only one language. There is no way to say, for example, I prefer reading stuff in Swiss German, but if that's not available, give me Swiss French or France French. It would be good if this list could be set system-wide. Isn't this provided by LANGUAGE environment variable on GNU systems? ... Oh cool, I didn't know about that. Now, anyone want to provide a GUI for it? ;-) Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moving spellcheckers into the Gtk+ stack
On Dec 14, 2006, at 10:48 PM, Danilo Šegan wrote: ... On Monday at 11:48, Matthew Paul Thomas wrote: Ideally Epiphany's language preferences wouldn't be in Epiphany, they'd be in a system-wide preferences tool (as they are for Windows Internet Explorer with the Regional Settings control panel, and for Safari and other Mac browsers with the International preferences pane). The language list it configured would also determine the default for Totem's subtitle/audio language, and for any other application that needs to know your preferred languages (such as an ISV's app that ships with its own translations). If I remember correctly, Epiphany uses the language from the locale as the default (I have since set my languages in there manually, since sr-CS, sr caused some web site to crash, and I wanted to add hr in my list as well). ... Right, and the reason Epiphany can't *solely* use the language from the locale is that (as I understand it) the locale can refer to only one language. There is no way to say, for example, I prefer reading stuff in Swiss German, but if that's not available, give me Swiss French or France French. It would be good if this list could be set system-wide. -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nine Months in Six Months
On Sep 10, 2006, at 8:31 AM, Nickolay V. Shmyrev wrote: ... [Shaun McCance wrote:] But now you want all these programmers to assemble their documentation piecemeal as they add features? Even if they all had perfect English (which they don't), and even if they were all really good at explaining things (which they aren't), this would still produce bad documentation. Why? Because it would only ever produce What's this? documents, and never How do I? documents. I find myself shooting down this idea every single release cycle. ... I humbly suggest that as long as you keep shooting it down, you will keep having the problem of not enough time to write documentation. Calling it documentation almost enforces the problem, suggesting that you're documenting something that has already been written. But just as with the interaction design, and just as with the test suite, you'll often get better results if the help for a feature is written before the code. The goal of all these disciplines is to maximize the proportion of people who use the software successfully, and it makes little sense to treat any of them as completely separate from the others. I haven't seen anyone claim that programmers are usually good at writing help; it would be surprising if they were. But whenever they're not, they should team up with someone who is. Just as they should team up with someone good at interaction design, and someone good at thinking up test cases. For each module in Gnome (as I said on gnome-doc-list last month), you should be able to ask, who is the maintainer, who is the interaction designer, who is the QA engineer, and who is the help author, and get three or four distinct answers. ... Agree, it's really a problem, but look at usability guys, they all just do a review, interface is created by developers. Developers are certainly not professional UI designers but HIG shows them the correct direction. It's much easier to review something and correct mistakes then to write it from scratch. ... That is very far from the truth. It is much, much easier to correct usability mistakes before the code has been written than after. http://urlx.org/upassoc.org/1f8d2 As for the HIGs, they mostly specify style for low-level things like appropriate window types, controls, spacing, and wording. Not having to constantly debate those things can save people a lot of time. But they are only a small part of design; they don't address fundamental design problems. (The most common such problem: This shouldn't be a separate program, it should be a menu item in program X.) No book of guidelines can turn a musician into a composer, a surgeon into a medical researcher, or a programmer into an interaction designer. -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Baobab
On Aug 11, 2006, at 2:47 PM, Alan Horkan wrote: On Fri, 11 Aug 2006, Chipzz wrote: ... Clueless user Baobab? WTF is Baobab? Two words: disk usage. It is also a type of tree. Chipzz was voicing a likely question of someone who hasn't seen Baobab before upon encountering Open in Baobab, not being a clueless user him-/her-self. Brand names should be used for things where competition or standards compliance is important (e.g. operating systems, Web browsers, Internet protocols, file formats). For something as mundane as a View by Size menu item, go for obviousness instead. This was discussed recently http://mail.gnome.org/archives/desktop-devel-list/2006-July/ msg00681.html Yes, Chipzz's message is part of that same thread. ... The third item listed by google for the word Baobab is the homepage for the Baobab disk usage program: http://www.marzocca.net/linux/baobab.html ... Are you suggesting that someone be expected to search Google to understand menu items in a file manager? -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy in Desktop
On Jul 26, 2006, at 9:43 AM, Alex Graveley wrote: ... Here's a status update on recent Tomboy happenings... I've applied a patch originally from Novell to use Tango icons and removed the possibly legally entangled Tintin icon. ... I don't mean to be a nuisance, but since Tomboy is licensed under the LGPL, Tango icons may be legally entangled too. http://lists.freedesktop.org/archives/tango-artists/2006-July/ 000621.html Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed Orca Migration
On Jul 25, 2006, at 11:41 AM, Bill Haneman wrote: ... I seem to recall that there was a reason why we didn't use 'startup programs' before. Can't remember what it was... but I seem to remember looking at and rejecting that before. Maybe because we wanted the ATs to launch first? Or is there a problem with the 'startup programs' API/interface itself? ... It might be that the accessibility settings window, because it is rarely used, could have at least some accessibility options (large text, spoken controls, etc) turned on all the time, to be more accessible to people who are trying to turn them on. It would be annoying if the Startup Programs window did that. -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: consistency (or lack thereof)
On Jul 22, 2006, at 9:42 AM, Reinout van Schouwen wrote: ... Ask dobey for the details, but IIRC Novell user testing showed convincingly that a majority of test subjects didn't know/expect that Close would save their changes. ... But it *didn't* save their changes, and renaming it to Finish doesn't change that. I can close the window using the button in the title bar instead, or even using xkill, and my new choice of background doesn't revert itself. Anyway, there are several bigger unfixed problems with this window. http://mail.gnome.org/archives/usability/2006-March/msg00213.html -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mac shipments up 12% [Was: focus!]
On Jul 21, 2006, at 12:53 AM, Alex Jones wrote: On Thu, 2006-07-20 at 08:23 -0400, Luis Villa wrote: They've had better software and better hardware than Windows for a full five years, and have still not cracked 5% market share, so I don't see why you're scared now- they've had good quarters before, and they end up getting lost in the noise. The current upward sales trend began in Q1 2005. http://daringfireball.net/2006/07/mac_os_x_tipping_point#fnr1-2006-07 -08 (You can mentally add Q3 2006: 1,327,000 units to the end of that list.) But the overall PC market has also been growing, so Apple's market share has been pretty static since 2001. http://pegasus3d.com/macmarketshare.gif (figures from IDC) (That Daring Fireball article addresses a couple of other points raised in this thread. First, Jeff is perhaps an example of people thinking that people at conferences I attend are switching to Macs = Mac market share is increasing substantially, when it ain't so. Second, it agrees with Havoc's music that the Mac user base of today is largely similar to the Mac user base of a decade ago.) This doesn't mean they suck, but I think it does speak strongly to Havoc's point- just being differentially better will not win big market share; we need to think about how to change the game completely if we're going to 'win' in any meaningful way- i.e., more than 5% market share. Agreed. Merely having better-in-degree software and hardware is not a practical way of achieving 10x10, because it will take until at least 2010 even to get the software to that stage (let alone to start selling it as being better), and the only way you could have hardware that's better would be for a company to make it specially targeted at a Gnome-based system. ... Take OpenOffice.org for example. It is quite evident that the aim is to make a free alternative to Microsoft Office. It has barely any unique features of its own. Look on the bright side: the radically different and highly detailed design of Office 2007 will force the OO.o team to do *something* different eventually, albeit probably five years later. :-) While I was running an idea past IRC last week, somebody mentioned that it would confuse people who are used to the way that other software behaves. This is, IMO, exactly the reason that many people see no benefit to using Linux and GNOME over Windows. Perhaps you could raise the problem on the usability@ list? Until then, here's a vague solution to that vague problem: Differences in behavior can be explained by differences in appearance. ... The fact that Ubuntu bundles Firefox (and turns off automatic session saving, as Firefox is incompatible with it) kind of saddens me. Session management is one of the benefits of GNOME, yet they sacrifice it in order to bundle something which Windows users are more familiar with. ... Join the Epiphany team then. :-) We have loads of unimplemented ideas, and browser wars are always fun. Epiphany vs. Firefox, and Abiword+Gnumeric vs. OpenOffice.org, are contests parallel to Gnome vs. Windows -- it's not enough to be better, you have to be *so* much better as to outweigh the familiarity people have coming from Windows (where, if they're using Gnome now, they were probably using Firefox and OO.o before). Being saddened won't change that battle. But it's not an impossible one: witness Safari vs. Internet Explorer for Mac. -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
On Jul 18, 2006, at 9:50 PM, Sankarshan Mukhopadhyay wrote: Havoc Pennington wrote: My first-order answer is that GNOME thinks of itself as making a desktop - even though the _reality_ is that the larger GNOME community/ecosystem is doing way more than that, and that the larger tech industry is doing still more. Would you consider junking the concept of GNOME as a desktop in favor of GNOME as an application development programming context or would think that the slicing should go deeper ? Namely, percolating the idea right down to the level where applications are developed around GNOME core (assuming the segregation of GNOME core and GNOME extras). ... If that happened, the platform developers would likely have less interaction with application developers on mailing lists like this one. So you'd be more likely to end up like the W3C's HTML Working Group has with XHTML 2.0 -- spending huge amounts of time producing an extremely elegant platform that's useless for real-world applications. To ensure usefulness of the platform for as many distributors as possible, perhaps it would be better for Gnome to contain *a representative sample* of software for various genres (office, artist, scientist, gamer), skill levels (cf. iLife vs. Apple's Pro apps, or Microsoft Works vs. Office), and hardware types (desktop, PDA, OLPC) -- so you can demonstrate that Gnome is a suitable development platform for all those audiences, rather than trying yourself to solve all the problems of any single audience. Gnome-wide efforts on things like usability, localization, library deprecation, etc would also be less effective if it was reduced to an application development programming context. Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
On Jul 18, 2006, at 11:54 PM, Sankarshan Mukhopadhyay wrote: Matthew Paul Thomas wrote: If that happened, the platform developers would likely have less interaction with application developers on mailing lists like this one. So you'd be more likely to end up like the W3C's HTML Working Group has with XHTML 2.0 -- spending huge amounts of time producing an extremely elegant platform that's useless for real-world applications. Why would that happen in the event GNOME decides to remould itself from being a kick-ass *desktop* to being a coherent platform ? ... Because I was using platform as shorthand for your application development programming context, which apparently excluded applications (applications are developed around GNOME core). I've used only one kick-ass desktop, and that's the one my computers sit on. -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
On Jul 18, 2006, at 12:09 AM, Nigel Tao wrote: ... I remember that, some handfuls of months ago, Jeff Waugh [1] proposed a Power User Tools suite outside of the traditional Platform / Bindings / Desktop (/ Admin). IIRC he was musing about things like Brightside and Devil's Pie, but one option might be to spin out Tomboy, Deskbar, and suchlike into that. Just one more idea to fling around the zoo. :-) [1] I think it was Jeff, but for some reason my GoogleFu is weak and I can't find a reference in the mail archives. ... http://mail.gnome.org/archives/release-team/2005-December/msg00069.html -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing the splashscreen for 2.16
On Jul 15, 2006, at 1:05 PM, Ritesh Khadgaray wrote: On Fri, 2006-07-14 at 23:26 +0200, Soeren Sandmann wrote: I would like to turn off the login splashscreen by default, for the following reasons: gconftool-2 --set -t boolean /apps/gnome- session/options/show_splash_screen False ... Since this is d-d-l, I suspect that by I would like to Soeren meant I propose that we, not How do I. :-) (I agree that the splash screen in its current state is more irritating than useful.) -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Some feedback
On Jul 6, 2006, at 1:08 AM, Radu Olaru wrote: I did not knew exactly to who should I write, nor did I found any explicit email on the gnome site, so here goes. Did you noticed how are modern desktops evolving? They try to be as dialog-less as possible. http://flickr.com/photo_zoom.gne?id=151250154size=o Gnome is great in evey way but it has too many dialogs opening at every step. Copying dialog, All versions of Windows (including Vista), and all versions of Mac OS X (including 10.4), use a progress window when copying. http://www.cdrinfo.com/Sections/Articles/Sources/ Windows%20Vista%20Beta%201%20Review/Images/CopyingFile.png http://inessential.com/images/TigerCopyWindow.png So which modern desktops are you referring to? :-) Package Update progress dialog and so on. As far as I know, Gnome doesn't have a Package Update program. (Maybe you are referring to Synaptic?) 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 a window? ... Because one of the use cases for progress windows is, Can I turn off the computer yet? And another is, Can I eject this CD yet? An applet would not be visible enough for either of these cases, because you may be glancing at the computer occasionally while doing other work relatively far away. You do have a point in that progress windows are overused. There are three common ways to reduce them: * If there is a parent window, show progress in the parent window instead. (Sound Juicer does this well; Synaptic does not.) * If two or more tasks should be queued for best performance (for example, copying/moving to the same disk), stack their progress into a single progress window. (Evolution does this well; Nautilus does not.) * If the same kind of long-lasting task (for example, uploads/ downloads) is often done intermittently, provide a normal window to list these activities. (Epiphany does this well; Evolution does not.) Cheers -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: opening a program with the middle button
On Jun 7, 2006, at 9:51 AM, David Prieto wrote: ... First thing I do when I switch on my laptop is open evolution to read my e-mails, liferea to get my news feeds and epiphany to browse some forums. Not necessarily when switching it on, but overall I usually run these programs together. You can set these programs to run automatically when you log in, using the Startup Programs tab of the Sessions preferences. (This could be much more obvious than it is, for example by giving the control panel a name better than Sessions.) You can also add the programs to the panel at the top/bottom of the screen by clicking on an empty part of it (if there is one) with the right mouse button (if you have one) and choosing Add to Panel (Again, this could be much more obvious than it is. For example, it should show up when you search the help for how can I start programs quickly.) -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Desktop as Nautilus
On Mar 15, 2006, at 11:58 AM, Calum Benson wrote: On 15 Mar 2006, at 09:55, Mike Douglas wrote: The trash applet was a great step forward for usability I'd somewhat dispute that, personally... no matter where on my panels I put the darn thing, nine times out of ten, it couldn't be further away from the thing I'm trying to delete if it tried, and dragging things that far is a royal pain. (That doesn't make it any worse than the desktop trashcan, certainly... just not notably better IMHO.) ... If it's in the bottom right corner of the screen (as it is in Ubuntu's default setup, for example), it's several thousand pixels wide and several thousand pixels high, making it the easiest thing to drag to in the whole of Gnome. If you can't easily drag from one side of the screen to the other, there's something wrong with your mouse acceleration settings. -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: System Monitor Graph Style Suggestions
On Feb 15, 2006, at 2:24 PM, David Malcolm wrote: ... On the subject of Tufte and gnome-system-monitor, I've implemented a GtkCellRenderer subclass for sparklines and implemented it for the per-process CPU usage: http://bugzilla.gnome.org/show_bug.cgi?id=319682 ... http://bugzilla.gnome.org/attachment.cgi?id=53853action=view That's gorgeous! Well done. ... Going much beyond, who is the intended user of gnome-system-monitor, and what is its purpose? Is it simply a GTK replacement for top, or is it intended to show something that's meaningful to: - end-users? - sysadmins? - software developers? (I don't think that top is particularly good for any of the above) I thought the most common use of it was for closing unresponsive programs. Maybe I'm just unlucky. :-) But if that is a common use, it's a bit awkward, since the list uses pretty unrecognizable names for many programs (soffice.bin, eog, esd, sol, wtf, bbq), and by default lists many things that aren't programs as most people would understand them (bonobo-activation-server, dbus-daemon, gam_server, etc etc). Maybe the list of processes could be filtered by default somehow, based on whether they were spawned from programs that have .desktop entries? Working towards giving the underlying executables human-readable names would help, too. -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New panel logout/shutdown alert - a mini ui review
On 10 Feb, 2006, at 8:56 PM, Vincent Untz wrote: Le jeudi 09 février 2006 à 07:46 -0500, Matthias Clasen a écrit : ... - The button order in the Shutdown dialog is a bit odd. Why is Cancel in the middle between Shutdown and Reboot ? I tend to agree here. Maybe we should not follow the HIG in this case since the menu item means: shutdown or reboot?. ... Restarting should be much less common than shutting down, so it's fine for Restart to be an alternative button to the left of Cancel. (Another factor is that Restart is only a shortcut, equivalent to Shut Down + start up again.) If you do need to restart nearly as often as shutting down, either you're switching kernels/OSes much more often than the average joe, or your OS badly needs fixing. :-) -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New panel logout/shutdown alert - a mini ui review
On 11 Feb, 2006, at 5:57 AM, Alan Horkan wrote: On Sat, 11 Feb 2006, Matthew Paul Thomas wrote: ... Restarting should be much less common than shutting down, ... so it's fine for Restart to be an alternative button to the left of Cancel. but I do not see how this arguement necessarily follows. http://developer.gnome.org/projects/gup/hig/2.0/windows-alert.html#alert-button-order Anything but the following layout would just look too weird: Mac OS uses the same button ordering as GNOME. http://guidebookgallery.org/screenshots/shutdownwindow#macos753 http://macgroup.infopop.cc/groupee/forums/a/tpc/f/148101437/m/358100019/r/3501014701 That alert is only ten years old this month, and you're calling it too weird? The young are easily hurt by such callous talk, you know. [ Cancel ] [ Restart ] [ Shutdown ] So when I click where the Cancel button is in every other confirmation alert in GNOME, the computer should restart? No thanks. If you do need to restart nearly as often as shutting down, either you're switching kernels/OSes much more often than the average joe, or your OS badly needs fixing. :-) My OS does badly need fixing but that is another story ;) If you know a better way to boot into a Live CD or partition containing another operating system I'd love to hear it but I quite often use Restart for exactly that purpose. (I had and installation of Mandrake and Redhat awkwardly coexisting on the etc etc etc... ... In many fewer words, you're switching kernels/OSes much more often than the average joe. And proposing an error-causing divergence from the HIG. -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Alt Mouse Modifier (Was: Adaptive mode)
On 8 Feb, 2006, at 11:39 AM, Rui Miguel Silva Seabra wrote: On Tue, 2006-02-07 at 16:34 -0600, Shaun McCance wrote: ... If you need anything more than Ctrl+letter in your application, you're pretty much screwed. ? I fail to see the relevance, this is window level, not application level, feature. ... Taking it for a window-level feature prevents it from being used for any application-level feature. For example, in a Web browser there are all sorts of things you can do with a link: open it in a new window, open it in a new background window, open it in a new tab, open it in a new background tab, or download the linked item. In Epiphany we would like to be able to use (Shift+)Alt+click for one or two of those things, like popular Web browsers on other platforms do. But we can't, because Metacity has taken it. I would much prefer that the easy way of moving a window was drag any part of the window that isn't for something else, with no modifier key necessary. Drag a window's title bar, status bar, an empty part of a toolbar, an empty space between controls, and so on. That would provide less target area than Alt+drag did (though still *much* more target area than on Windows or the Mac), but (1) it would be more obvious, (2) it wouldn't need two hands, and (3) it would remove the need for the clutter of a title bar and the rest of the window being visually distinct elements. -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Fwd: Document font pref [was: Re: asking for approval for bug 160454]]
On 27 Jan, 2006, at 5:37 PM, Shaun McCance wrote: ... My stance is that any application that shows you long blocks of text should use the document font setting, unless the text ought to be in a fixed width font. ... Pages in a help viewer usually shouldn't be long blocks of text in the first place. :-) Help viewer windows are also usually much smaller than a typical Web browser window (because you want them visible alongside the thing they're providing instructions on). And help authors -- unlike Web authors -- hardly ever use fonts smaller than the default (if this is even possible in DocBook). All these things make it appropriate for Yelp to have a smaller default font than Epiphany does. Other operating environments already do this: in all versions of Windows, and all versions of Mac OS since 8.5, the standard font for text in the help viewer has been a small sans-serif (often achieved with a deluge of font tags), while the default font for the bundled Web browser(s) has been a larger serif. Trying to combine default document font prefs also causes problems with ease of configurability. For example, in Windows 98, the text size in the Windows help viewer is determined by Internet Explorer's preferences; so if you set Internet Explorer's text size to Smallest, much of the text in the help viewer becomes unreadable for many applications without any way to fix this in the help viewer itself. An even closer precedent is that of classic Mac OS, where the Internet control panel had a Fonts pane quite similar to that in Gnome. But none of the major Web browsers paid attention to it, having their own font preferences probably partly because it was more discoverable that way. The same thing would likely happen for Epiphany and Firefox under Gnome: since it would make no sense for the minimum font size pref and the standard font size pref (for example) to be set in entirely different programs, the browsers would likely continue to have their own GUIs for setting their own individual font prefs. -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Adaptive mode (Was: Re: Browser Mode by Default)
On 17 Jan, 2006, at 6:32 AM, Calum Benson wrote: On Sat, 2006-01-14 at 09:08 -0500, William Lovaton wrote: ... Imagine you are using the List View and you have many folders in it (let's say your home directory) in a way that real files are not visible, located well down in the bottommost part of the window. Now suppose you want to drag a file from your desktop to your home directory... there is no easy way to do that because that file won't end up in your home directory but in one of the folders located in your home directory. And that's because you are hovering a directory no matter where you drop the file. ... Ah, yes. FWIW, the Mac Finder has exactly the same problem, and the same (non-obvious) solution... you have to drop on the column headers. Actually, from testing it in 10.3, to move something to folder X you can drop something in any part of X's folder window that is not text belonging to a subfolder or drop-savvy application. This includes the title bar of the window, the column headers, the scrollbars, the space between a subfolder's or application's name and its date, the space between its date and its size, and so on. Dropping on the window's status bar doesn't work, but that seems to be a bug. Nautilus could allow all of those, though recognizing a drop on the title bar would need help from the window manager, and recognizing a drop in the gap between text in adjacent columns would need help from GTK. Personally I'd like to see a blank row always inserted at the bottom of any file manager list view (like on Windows), so there's a guaranteed bit of 'background' to drop into. ... That should perhaps be done for all list views, not just lists of files. People I watch often have trouble recognizing that they've scrolled to the end of a list. -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
