Re: systemd as external dependency
Em Qui, 2011-05-19 às 15:15 +0200, Lennart Poettering escreveu: > On Thu, 19.05.11 00:50, Sergey Udaltsov (sergey.udalt...@gmail.com) wrote: > > > > > > I think the best way to save resources is not to run anything. For stuff > > > like hostnames/locale/time which is used only every other moonphase > > > having tiny single-purpose mini-services is perfectly appropriate. I > > > don't think there would be any benefit in merging these mini daemons > > > into one. Au contraire, I'd guess you'd waste even more resources with > > > dlopen() and friends. > > Can all those services be standardized using DBus interfaces (DBus > > activation if necessary)? IMHO that's the only way to remain friendly > > to non-linux OSes, not having any bits of systemd (or distros that are > > not using it)? > > Some can. Not all. > > The hostname mechanism is explained in very much detail here: > > http://www.freedesktop.org/wiki/Software/systemd/hostnamed > > As suggested a couple of times I believe the mode of cooperation with > the Solaris/BSD folks here should be to share those interfaces, not the > code behind it. > > Something similar is true for the locale/timezone/time mechanisms. > Would you propose a specific set of interfaces as blessed external dependencies instead of systemd entirely? I believe that would make this discussion quite a bit simpler. Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
Em Qui, 2011-05-19 às 14:16 +0200, Olav Vitters escreveu: > On Thu, May 19, 2011 at 08:39:12AM -0300, Evandro Fernandes Giovanini wrote: > > Telling people to switch distributions is a much bigger turn off than > > you realize. The barrier to contributing to GNOME should not be that > > high, and many will follow the "switch to a different OS" advice as > > "contribute to something else, this is too much". That doesn't help > > anyone. > > Anyone is welcome to help out on IRC. > > I don't really get your comment though. Sometimes people do not want to > switch, so ehr.. they say so and I continue giving the best advice while > keeping in mind that restriction. So sometimes I've said 'ask your > distro'. > Olav, I'm not trying to call you out or anything. I've seen you help out quite a lot of people on GNOME mailing lists and IRC and you do a great job. To clarify my point: some people don't mind at all being told "just install Fedora 15 and it'll be easy-peasy". Heck, I know people who seem to try every new live CD that's released because they love trying new distributions. It's just that for *some* installing a whole new system they're not familiar with is asking a *lot*. They'll have to spend hours to find, download, install and learn a whole lot before they can actually get to GNOME 3. "apt-get install build-essential" and such won't work anymore, etc. You may think you just gave them some helpful advice, they'll look at your response and think "that's a whole lot of work, maybe I'll go do something else". > > If you're not familar enough with Ubuntu to understand the problems > > people are having with the GNOME 3 ppa then simply redirect them to the > > GNOME 3 ppa mailing list, where they can find people qualified to help > > with those specific issues. > > It wasn't about GNOME 3 ppa, it was about how to contribute to GNOME. > > Due note: I gave the best advice what was known to me and nobody else > responded. Maybe what you suggested would've solved it, no idea, I > didn't know, nobody else responded. Right, but if they can't contribute to GNOME because of a Ubuntu GNOME 3 PPA problem then someone familiar with that PPA can help them get past that problem, and then they can easily contribute to GNOME. It might be that the problem they're having in Ubuntu is actually quite simple to solve, and much easier than installing a new system from scratch. :) Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
Em Qui, 2011-05-19 às 13:28 +0200, Olav Vitters escreveu: > On Thu, May 19, 2011 at 12:30:14PM +0200, Luca Ferretti wrote: > > Il giorno gio, 19/05/2011 alle 12.00 +0200, Olav Vitters ha scritto: > > > > > No, not at all what I meant. That would be really really bad. > > > > > > Just that if someone asks on #gnome which distribution to start his > > > jhbuild on, I'd make clear that Ubuntu would mean a lot of difficulties. > > > > Are you sure? There are good pages on live.gnome.org about how to use > > jhbuild on Ubuntu and which packages you could need to install. > > I'm not an expert on giving support. I try to help people as best as I > can. Which means I am going to provide my personal beliefs about what is > best. > > I give that advice on IRC in public channels. Anyone is free to jump in > if they have different experiences/opinions. Telling people to switch distributions is a much bigger turn off than you realize. The barrier to contributing to GNOME should not be that high, and many will follow the "switch to a different OS" advice as "contribute to something else, this is too much". That doesn't help anyone. If you're not familar enough with Ubuntu to understand the problems people are having with the GNOME 3 ppa then simply redirect them to the GNOME 3 ppa mailing list, where they can find people qualified to help with those specific issues. Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
Em Qua, 2011-05-11 às 11:37 +0200, Luca Ferretti escreveu: > Il giorno mer, 11/05/2011 alle 01.27 +0100, Bastien Nocera ha scritto: > > On Wed, 2011-05-11 at 02:15 +0200, Luca Ferretti wrote: > > > > #2 -- will gnome-c-c module englobe _all_ chosen panels? who will > > > approve them? g-cc maintainers? release team? design team? a pool on > > > doodle.com :P )? > > > > Maintainers and designers. Maintainers meaning that if it's not > > designed, it won't go in. So really, designers. > > Will designers approve external dependencies too? > > It's just an example, but... Deja-dup needs duplicity. Deja-dup, > converted to "Backup" panel inside gnome-control-center, will make > gnome-control-center depends on duplicity (unless maintainer will make > it optional, but I suspect designers can say "we want this feature by > design" and promote it to mandatory). gnome-control-center is part of > GNOME Desktop core. GNOME Desktop core depends on duplicity... I love > Aristotelian syllogism :) > > Just because deja-dup depends on duplicity doesn't mean the control center panel needs to as well. It doesn't even have to depend on deja-dup, instead proposing its installation like Totem and file-roller handle non-installed formats. > > More, you are staring from a negative point of view. Maybe someone will > be able to provide a beautiful and well integrated external panel for > system setting, deja-dup proposal is a perfect example. A project taking > care to be well integrated in chosen design. It could be a win-win game. > I think the starting point here is not a negative point of view, it's how GNOME evolved from 2.0 to 2.32 as shipped in most GNOME distributions. Inviting application developers that want proper integration with GNOME to work with GNOME designers is a perfectly valid way to handle this situation. Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Em Ter, 2007-10-09 às 15:47 +0100, Bastien Nocera escreveu: > On Tue, 2007-10-09 at 10:09 +0200, Sven Neumann wrote: > > Hi, > > > > On Tue, 2007-10-09 at 10:04 +0200, Dave Neary wrote: > > > > > GNOME seems like it's far too high in the stack to include a sound > > > server & API - shouldn't we simply depend on it, rather than integrating > > > it into the GNOME platform? > > > > Could you perhaps consider to integrate it nicely but not to depend on > > it? The majority of users doesn't need a sound server. While it would of > > course be nice to have one that nicely interoperates with the GNOME > > desktop, it would be a shame if you couldn't run GNOME without running a > > sound server. > > It's already a dependency, as it's used in libgnomeui and exported from > that API. You can already run GNOME without esound or Pulseaudio, and > that's not changing. > Given that libgnomeui is on it's way out, where does PulseAudio fit in? I thought the plan was to move apps using libgnomeui to use gstreamer instead. Is that correct? []'s, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Plugins vs Extensions
Hi, a lot of GNOME modules can have their functionality extended by third party code, through extensions or plugins. The interface to enable and disable them is different on most applications. For example, Evolution has an Edit -> Plugins window, Gedit uses a tab in the preferences dialog and Epiphany uses the Tools -> Extensions menu. There are several other modules as well as third party applications. The Evolution method has been adopted by some third party applications, and seems to be the most common. I was hoping the name (extension vs plugin) as well as the interface to enable/disable them could be standardized for the Desktop 2.20 release. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New Control Centre
Em Dom, 2007-02-11 às 20:49 +1300, Matthew Paul Thomas escreveu: > > The other thing that stands out between the Gnome Control Center and > System Preferences is that the latter is much more compact -- 600 > pixels wide, height varying dependent on the current panel. G-C-C has a > redundant category listing on the left, and labels icons to their right > rather than underneath. These both waste a lot of space, requiring a > scrollbar (ugh) to list all the categories. (System Preferences uses a > scrollbar as a last resort, if you're both at 640*480 or 800*600 and > have any third-party panels installed.) It's ironic that the list of > categories contributes to the need for a scrollbar, and the presence of > a scrollbar in turn justifies the list of categories. > I filed that as http://bugzilla.gnome.org/show_bug.cgi?id=405078 Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: gnome-main-menu
Em Ter, 2007-01-09 às 13:39 -0600, Scott J. Harmon escreveu:
> Evandro Fernandes Giovanini wrote:
> > Em Ter, 2007-01-09 às 14:27 +0100, David Prieto escreveu:
> >>> it does not integrate deskbar and nor should it - the search should only
> >>> be for applications (IE .desktop files)
> >> I could do with just application search, but as far as I know it doesn't
> >> even do that.
> >>
> >> As for beagle search, I never thought it was that all that useful. After
> >> all the search tool is right there under the places menu, why have it
> >> twice?
> >
> > Access to your bookmarked folders ("Places") with slab is slower[1], but
> > searching is faster and much more easily discoverable. These are two
> > different scenarios that cater to different computer users.
> >
> > For example, some users would really benefit if they could just type
> > "Beatles Let it Be" or "Family vacation photos" to open a document
> > rather than browsing the computer file system to find them.
> >
> > I can't count the times I've seen people "lose" files, and I believe
> > having Beagle so easily available is one of the main reasons slab did so
> > well in Novell's usability tests (which I haven't watched yet).
> >
>
> But Beagle is not in gnome, so this point is moot. I think we are
> really seeing that people who have Beagle like Slab, and people who
> don't have Beagle don't like slab...
>
I think it's more fair to say that people who currently use the "Places"
menu to access bookmarked folders a lot will not be a big fan of slab.
People who don't use Beagle or another indexer can still prefer slab
over the current menu as long as they don't use the "Places"
functionality too often, or prefer slab's other features enough to let
it go.
Cheers,
Evandro
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: gnome-main-menu
Em Ter, 2007-01-09 às 18:55 +, Iain * escreveu: > > But I use: > > - xchat-irc, gajim, liferea and such daily > > - epiphany, thunderbird, devhelp, gedit, terminal, matlab, pepito, > >"home folder" every now. > > So that makes obviously more than 6, and those are more easily and > > quickly available from launchers in the panel. One less click. > > Thats 10. I've just added another load of applications to my menu, its > now got 12. > I can only imagine how much panel space 12 application launchers would take > up. > *shrug* I don't think its much of an arguement against it. > Btw, 12 launchers in a 24 pixels panel make it look quite crowded, and the launchers are hard to hit (at least for me, as I often launch the wrong application with the default panel setup). One of the things I like about slab is that the target area to launch an application is much bigger. Plus I can have 10 or 12 launchers without cluttering the screen. Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: gnome-main-menu
Em Ter, 2007-01-09 às 14:27 +0100, David Prieto escreveu:
> > it does not integrate deskbar and nor should it - the search should only
> > be for applications (IE .desktop files)
>
> I could do with just application search, but as far as I know it doesn't
> even do that.
>
> As for beagle search, I never thought it was that all that useful. After
> all the search tool is right there under the places menu, why have it
> twice?
Access to your bookmarked folders ("Places") with slab is slower[1], but
searching is faster and much more easily discoverable. These are two
different scenarios that cater to different computer users.
For example, some users would really benefit if they could just type
"Beatles Let it Be" or "Family vacation photos" to open a document
rather than browsing the computer file system to find them.
I can't count the times I've seen people "lose" files, and I believe
having Beagle so easily available is one of the main reasons slab did so
well in Novell's usability tests (which I haven't watched yet).
Cheers,
Evandro
1. You can quickly access your bookmarks from Slab by launching Nautilus
(with its "Places" sidebar).
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: nm-applet
Em Seg, 2007-01-08 às 19:31 +0100, Vincent Untz escreveu: > You can learn about nm-applet here: > http://www.gnome.org/projects/NetworkManager/ > The project page mentions Linux specifically, but can we assume a port to systems that run other kernels is doable? (I'm thinking FreeBSD and Solaris, since they already have dbus and at least some of hal working). Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-{desktop,panel,session} branched for 2.16
Em Seg, 2006-11-06 às 22:47 +0100, Vincent Untz escreveu: > Hi all, > Hello :) > gnome-desktop, gnome-panel and gnome-session have been branched for 2.16 > (usual name: gnome-2-16). > > Trying to clean up bugzilla is probably the best plan for 2.18 I can > announce for now ;-) > Is the new applet lib planned for 2.18? Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing Tracker for inclusion into GNOME 2.18
Em Ter, 2006-10-24 às 17:09 +0100, Jamie McCracken escreveu: > The only thing slowing down further integration is getting into gnome or > being an accepeted dependency - hopefully a chicken and egg situation > can be avoided here > > Why don't you create a branch to work on Epiphany? Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: gnome-main-menu for inclusion in GNOME 2.18
Em Sex, 2006-10-20 às 13:30 -0400, Rodney Dawes escreveu: > > Looks really nice though. And congratulations and thank you for not > > using submenus. > > While we've avoided using submenus for the time being, I think they may > be necessary to solve some of the usability issues that exist with the > design. One thing I don't like about using the app browser, is that it > requires me to open a separate program, browse, then open an app. If I > want to open more than one application at some point, and they aren't in > my favorite or recent apps, I have to repeat this much slower process > multiple times to get to the apps. Having "More Applications" pop up a > menu which has the structure of the normal programs menu, would be more > useful I think. > You could turn the Search bar into a Run bar when the Shift key is held, so that "Enter" does a search and "Shift+Enter" runs the command. Also, the "More Applications" button could have a drop-down next to it, like the "New" button in Evolution's toolbar. The button would still launch the application-browser, and the dropdown would show a regular menu. Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: gnome-main-menu for inclusion in GNOME 2.18
Em Sex, 2006-10-20 às 13:27 +0200, Steve Frécinaux escreveu: > Rodrigo Moya wrote: > > > IMO, it should replace the menu applet currently in gnome-panel, they > > serve the same purpose but slab has a much better look and a few extra > > features that make it quite useful, so if I were decide, I would include > > slab in the panel, to replace the current menu > > IMHO the purpose of both of them is different. In particular I don't see > any equivalent to the Places menu in there (at least from the screenshot > I got from google). > The slab equivalent is the search bar. I think the idea is that instead of browsing the file system to find a file to open you simply type some search terms and beagle shows what you want immediately. One of the main advantages of slab over the current default is that search is a lot easier to discover. Also, I think Rodrigo meant replacing the old "foot" menu, not the menu bar applet. However, if slab is shipped in 2.18 it would be nice to ask for feedback on the release notes, and maybe this discussion can happen for 2.20. Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing Tracker for inclusion into GNOME 2.18
Em Qui, 2006-10-19 às 10:13 -0400, Hubert Figuiere escreveu: > > Aside from technical objections, are there any distributions that ship > > this by default? Do any of these enable it by default? > > > > New applications don't get into GNOME as they may be cool and > > interesting, they get into GNOME as they are used in the real world. As > > an example, Sound Juicer, IIRC, was the default CD ripper in released > > versions of Red Hat and Mandrake before it was proposed and accepted > > into GNOME. > > That is a very polite way to say no, but I don't think it is > appropriate. If the Gnome project want to try to driver innovation, it > has to make its own decisions, not wait for others like distribution to > make them. > I don't think anyone will disagree with that, and it probably explains why GNOME ships gnome-system-tools, epiphany and probably a few others I'm forgetting. I think the point is that Tracker needs to be mature before it can be part of the GNOME desktop release, and even more so if applications like Epiphany are going to depend on it. The fact that Tracker isn't yet shipped by the most popular distributions at all (not in Fedora Core or Extras, Ubuntu's main or universe, Debian unstable, Mandriva, etc) means that it's not very mature yet. That doesn't mean the GNOME community shouldn't discuss if Tracker should be integrated in the future, but it probably says that 2.18 (4 months from now) might be too soon. Another example I'd like to point out is that even gnome-power-manager was "rejected" for the 2.14 release for not being mature enough, even though distributions like Fedora Core and Ubuntu shipped *and* enabled that version by default. Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity Compositor
Em Qua, 2006-10-04 às 01:29 +0200, Chipzz escreveu: > This is very much not a detail, but the last time I tried compiz (which > was on ubuntu dapper), it lacked *ALL* of the keybindings to maximize, > minimize, etc windows. Certainly not a "minor detail". > It's quite possible that you tried an early version of the beryl fork, not compiz. Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Clarius
Em Sáb, 2006-09-02 às 00:43 +0200, Josselin Mouette escreveu: > Le mardi 29 août 2006 à 18:20 -0300, Evandro Fernandes Giovanini a > écrit : > > Clearlooks is still available, it's installed by the gtk-engines > > package. > > How about the metacity theme? > The metacity theme never changed. A Clarius gtk theme was created, and the Clearlooks metatheme was modified to use it instead of the Clearlooks gtk theme. This has been reverted now so 2.16 won't have the Clarius theme. Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Clarius
Em Ter, 2006-08-29 às 14:40 -0500, Shaun McCance escreveu: > On Tue, 2006-08-29 at 18:42 +0100, Calum Benson wrote: > > On Tue, 2006-08-29 at 10:01 +1200, Glynn Foster wrote: > > > Hey, > > > > > > Shaun McCance wrote: > > > > I'm going to coin a new term: key churn. This is when people > > > > make frivolous and unnecessary changes to GConf keys or their > > > > default values. It sucks for large deployments. Gnome is > > > > bigger than your personal desktop. > > > > > > I don't really care too much about the name change, but what I do > > care about is > > > the migration story between themes as new engines/icons/whatever are > > dropped in > > > and out. This stuff isn't as smooth as it should be - hopefully > > Calum can > > > provide details of what currently happens [we documented this for an > > ARC case > > > recently]. > > > > It seems to go something like this (at least on the 2.15 machine I was > > using to experiment with it): > > [snip] > > > 2. If a theme's index.theme file remains after an upgrade, but one or > > more of its three components are no longer installed, on opening the > > theme capplet your theme is shown as selected, as if nothing was > > wrong. > > When you drill down into the details dialog, though, the behaviour is > > the same as case 1... the 'phantom' theme components are shown as > > selected, until you select an alternative instead, at which point they > > disappear. > > This is the relevant point. The Clearlooks gtkrc file will no longer > be available (assuming you've done a clean install, or updated using > a package manager that removes old files). > > I'm less concerned about the theme manager's behavior than I am about > how your desktop will appear. If there's no gtkrc file, GTK+ has no > choice but to fall back to its boxy default. > Clearlooks is still available, it's installed by the gtk-engines package. Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: removing non-working things
Em Seg, 2006-08-07 às 16:54 +0100, Alan Horkan escreveu: > On Mon, 7 Aug 2006, Ritesh Khadgaray wrote: > > > Date: Mon, 07 Aug 2006 20:57:33 +0530 > > From: Ritesh Khadgaray <[EMAIL PROTECTED]> > > To: Alan Horkan <[EMAIL PROTECTED]> > > Cc: Matthias Clasen <[EMAIL PROTECTED]>, desktop-devel-list@gnome.org > > Subject: Re: removing non-working things > > > > On Sun, 2006-07-30 at 21:38 +0100, Alan Horkan wrote: > > > On Sun, 30 Jul 2006, Matthias Clasen wrote: > > > > > > > Date: Sun, 30 Jul 2006 14:47:39 -0400 > > > > From: Matthias Clasen <[EMAIL PROTECTED]> > > > > To: desktop-devel-list@gnome.org > > > > Subject: removing non-working things > > > > > > > > The gnome-ui-properties capplet contains a "Detachable toolbars" > > > > checkbox, which has three issues: > > > > > > > > a) It only affects BonoboToolbars, not for regular GtkToolbars > > > On a side-note > > With gedit 2.8, this feature works ( with the stated bug) > > With gedit 2.17 ( rawhide ) detach toolbar option has no effect. > > Sounds like either a regression or the Gedit developers have given up on > detachable toolbars like so many others. > Gedit moved from bonoboui to GtkUIManager in 2.13/2.14. Cheers, Evandro ___ 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
Em Qua, 2006-08-02 às 13:57 +0200, BJörn Lindqvist escreveu: > On 8/1/06, Rodney Dawes <[EMAIL PROTECTED]> wrote: > > On Tue, 2006-08-01 at 16:45 -0400, Pat Suwalski wrote: > > > 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. > > > > You haven't lost any information, you only think you have. You're > > looking for the information in the wrong place. > > > > If you have a suggestion for how exactly one might show the difference > > between tiff, jpeg, svg, wmf, gif, png, tga, and whatever else there is, > > without using meaningful text in the icon, I am all ears. Until then, we > > Use different images for different file types. The yellow-black > savannah icon for png files, another type of image for jpeg files. It > doesn't really matter what icons are used, as long as the icons for > png and jpeg images are DIFFERENT. Adding text to the icon just makes > it more explicit. I have read the GNOME HIG and I can't find where it > says that using text in icons is wrong and that different kinds of > images must share the same icon. And if it is written there, then the > HIG is wrong, IMHO. > While I don't mind having text with the file extension on the icons, different icons for the same type of file (image, audio, video, etc) is a nightmare in GNOME pre-2.14 that I'm glad to see fixed in 2.15. Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: SVN migration, any news?
Em Dom, 2006-07-30 às 16:02 +0200, Olav Vitters escreveu: > On Sun, Jul 30, 2006 at 03:12:02AM +0200, BJörn Lindqvist wrote: > > On 7/30/06, Guilherme de S. Pastore <[EMAIL PROTECTED]> wrote: > > > Em Sáb, 2006-07-29 às 17:47 +0200, Christian Neumair escreveu: > > > > As we all know SVN migration was cancelled due to problems with the > > > > migration script [1]. Maybe somebody from the SVN migration staff could > > > > come up with a short summary of what has happened since the failed > > > > migration and whether there are any plans to pick it up anytime soon. > > > > > > Ross can probably inform the nasty details better, but we had a couple > > > of unexpected problems (such as binary files corruption) during the > > > migration, fortunately spotted soon, which made us abort and reenable > > > CVS access. > > > > Is there anything you can do to help? So that the next migration > > attempt will actually work? > > I know having a Python 2.4 rpm that installs in a different location on > RHEL3 would help a lot. Haven't found time to do this yet, but IIRC > (from what Ross told) Python 2.4 needs some newer libs than available on > RHEL3. > atrpms.net seems to have python24 packages for RHEL3. Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time to heat up the new module discussion
Em Qua, 2006-07-19 às 06:48 -0500, Sean Kelley escreveu: > From an embedded developers standpoint working with Gnome as a part of > the Gnome Mobile and Embedded group, C and C++ are extremely relevant > for our devices. Mono like .NET are quite frankly a no go in terms of > memory and performance. > > Sean > Isn't that true for a lot of the modules in the current desktop set already? Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gtk# in 2.16
Em Seg, 2006-04-24 às 22:08 -0500, Mike Kestner escreveu: > > Technically, gnomeprint is a show-stopper for us. We expose its API in > gnome-sharp.dll and therefore could not split it out and still maintain > our API stability guarantees. > Isn't libgnomeprint* going to be removed from the 2.16 desktop set in favor of GTK's new printing API? Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applet infrastructure
Em Sáb, 2006-04-22 às 18:44 -0700, Michael Frank escreveu: > On Sat, 2006-04-22 at 09:05 +0200, Vincent Untz wrote: > > Le samedi 22 avril 2006 à 01:06 -0400, David Zeuthen a écrit : > > > Can I suggest to start a new thread here on d-d-l about the applet > > > infrastructure [1] > > > > FWIW, this is a proposed SoC project. I have lots of ideas (and other > > people also have) that I really should write down somewhere. > > > > Feel free to start a new thread here or send me mails about this. Right > > now, the main issue is to try to do it in a cross-desktop way so we can > > remove a good excuse for abusing the notification area :-) > > what i would like is to have a notification area *and* a 'systray' (for > lack of a better name at the moment), since i find both to be useful. > > perhaps what is now the notification area applet could become the > systray applet, so ppl who don't like the whole systray idea could > remove it. next the notification area could be merged into the window > list applet by creating a space for it (roughly the size of the show > desktop button) for it at the right end of the window list. when there > is a notification, this area lights up/flashes, maybe shows a > notification balloon, etc. there would be a need for some sort of > notification queuing, but that eliminates expanding and contracting the > notification area. > > i would like a systray similar to newer versions of windows, i.e. with > some provision for collapsing the systray area by hiding some of the > icons according to a user defined policy. > > other thoughts, comments? > > -Michael > I don't see how hiding some icons would be useful, since the default panel layout is not crowded like the 1-panel layout on Windows. I'm a bigger fan of the NeXT/GNUstep dock myself (I was a WindowMaker user for some time). For example, GNOME could have an applet for launchers, like quick-lounge-applet, that would also have icons for the hidden running applications. For example, two applications that are useful to hide are IM and the music player. When I want to bring up the music-player I have to look for it in: 1) the tasklist; 2) the notifications area / systray; 3) and finally, the launcher. In GNUstep you would just double click the music-player icon, which you'll always find in the same place in the dock. I think the systray/notification area is useful for things the user doesn't really care about. For example, nobody buys a laptop to monitor the battery status or other hardware related functions. They do it to run applications (like IM and music-player), and so I think it's a good idea to keep these things separated. The "quick-lounge"-like applet I mentioned could be useful for other things. For example, instead of launching Evolution to check for new mail the icon launcher would always display if I have new messages or not. This would save people a lot of time. Unfortunately I don't think this is exactly easy to implement. :( Cheers, Evandro ___ 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
Em Qui, 2006-02-16 às 04:09 +1300, Matthew Paul Thomas escreveu: > On Feb 15, 2006, at 2:24 PM, David Malcolm wrote: > > ... > > 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. :-) > Doesn't metacity take care of that for you? :) Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk-engines 2.6.x for GNOME 2.14
Em Sáb, 2006-02-11 às 17:09 +, Thomas Wood escreveu: > This is to confirm that the gtk-engines team have decided that, in light > of the recent issues raised on various mailing lists, and our own > assessment of the progress we have made towards the goals for > gtk-engines 2.8, we would like to suggest that GNOME 2.14 uses the 2.6.x > series of gtk-engines. > > We have had some excellent feedback and testing from our 2.7.x > development series by it being in the current GNOME 2.13 releases, and > we'd like to thank everyone for their help and comments. However we feel > that because of a number of unresolved issues, including the speed, > appearance, and general completeness, we cannot recommend it be included > in the GNOME 2.14 releases. > > I will be reverting jhbuild to use the gnome-engines-2-6 branch for the > 2.14 module set. The HEAD branch of gtk-engines should be used when the > 2.16 module set is created. > Any chance of adding the clearlooks engine from 2.7 with a name like libclearlookscairo.so or libclearlooks2.so? (the default theme, "Clearlooks", would still be based on the 2.6 version). Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sorry State [Was: NLD10 and GNOME]
Em Qua, 2006-02-08 às 12:16 +1100, Jeff Waugh escreveu: > > > > Two words: "bike shed"[1]. Or actually, "stop energy"[2] works too. Your > > pick. > > This is a very sorry state of affairs for GNOME. But it is not only Novell > and its employees who have adopted this commons-sapping, community-tearing, > morally and intellectually lazy approach to open design and development in > GNOME. > > In contributing organisations, it is rationalised as a faster approach, a > way to avoid massive discussions about inanities, and top of the list in > these modern times, a way to avoid "design by committee" or "stop energy". > How on Earth *do* we manage design out in the open? It is easier to avoid > that question, in the name of getting things done. > > Outside the contributing organisations, it's appeased as something we have > to accept to get the cool stuff, and a side-effect of our ability to involve > contributing organisations, who have their own priorities. It sounds a lot > like, "don't bite the hand that feeds you", whether that hand is delivering > cool drops of code, or your pay packet. > > But ultimately, this is *killing our community*. > > And it must be fought. > > - Jeff > I think the process used by Novell is very common in the GNOME community (and Free Software in general). For example take metacity. Sawfish was the default window manager, so Havoc could have started a discussion "should-our-window-manager-be-like-this-instead". But he didn't; what he did was write metacity following the design he had in mind in a window manager. Metacity was included in GNOME because most people adopted it and agreed that Havoc's design was better for the default window manager. The menu layout we use today is another example. If people had gone on discussions about which is better - the foot or the "menu panel" - perhaps things would have gone nowhere. But someone wrote the "menu panel" and eventually it became the GNOME default. Ubuntu has also done some changes in the panel, like the 'Add to Panel' dialog. From what I remember this was first done in Ubuntu and after a release using that configuration discussion started on the usability list. Another example is the log out dialog on the right top corner of the screen in Dapper, which wasn't proposed for discussion on mail.gnome.org, it was just implemented there when GNOME uses the window selector for the top right corner. There are some people posting mockups of "GNOME 3" and to be honest I see very little discussion about them. People know (or learn) that unless they code these mockups or convince someone to do it then most likely nothing will happen. But if someone comes up with a different concept for the panel and translates that into code then the community will review and pick it up or reject it. Spending time discussing the design first would IMO be a waste of time if the person has it clear in their head what they want from this hypothetical new panel. The review process will still happen, just not before the design. The design might even have small changes after suggestions from the community, but the basic idea of the original author is what makes this good or bad design. I'm not sure I agree that "you can't do design by comittee" but I would agree that a lot of the good design decisions we see in GNOME today came from only a few coders doing their vision. I'd love to play with the code as soon as possible but maybe there are other reasons for it not being released yet. What GNOME can do is encourage the companies making changes in their development branches to at least commit the patches in a CVS branch. There's also the issue of who you target with the changes. Novell might find in a usability test that the menu they designed is a lot better for their target audience but most people in the GNOME community would reject it in favor of the current panel layout (I'm one for example). Should that stop Novell from doing what's best for their customers (people used to Windows but now using GNOME because their company went with NLD)? My 2c. Cheers, Evandro ___ 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
Em Seg, 2006-01-30 às 15:06 -0500, Matthias Clasen escreveu: > On 1/30/06, Rodrigo Moya <[EMAIL PROTECTED]> wrote: > > Changes since 2.13.5.1 > > > background: > > - Added apply button (Rodney Dawes) (327335) > > - Fixed glib CRITICAL warnings (Rodney Dawes) (327327) > > > > So, Gnome 2.12 had a nice working immediate apply background changer. > Why did this get changed to an odd explicit model ? > Thats a step backwards. > I think it was done to follow the HIG: http://developer.gnome.org/projects/gup/hig/2.0/windows-utility.html#windows-instant-apply Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-system-monitor is now gnome-system-monitor
Em Qui, 2006-01-26 às 12:24 -0200, Guilherme de S. Pastore escreveu: > Hi all, > > sorry for the stupid subject. The CVS module "procman" has been renamed > to gnome-system-monitor, which has been the application and tarballs > name for quite some time. Aliases have been set up not to break things > instantly (only in 3 months from now), and I have updated everything I > could think of (the wiki page for the Desktop release of 2.14 and the > jhbuild modulesets). Olav Vitters should take care of the bugzilla > product soon. > > Cheers, > The l10n status pages for 2.14 also need updating. Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: High Contrast Icons
Em Ter, 2005-11-22 às 20:47 -0500, Rodney Dawes escreveu: > > Does this have anything to do with the relatively new icon naming spec? > > One thing I hope to add to the Icon Naming spec soon, is a set of > guidelines for naming application icons, that will help to prevent > the possibility of conflicts with other app icons. Maybe applications should just use the same name for the executable and icon (and other data as well). For example: /usr/bin/foo /usr/share/foo /usr/share/icons/hicolor/scalable/apps/foo.svg What do you think? Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cdda:// URIs and the default handler
On Thu, 2005-09-22 at 08:42 -0600, Elijah Newren wrote: > On 9/22/05, Alexander Larsson <[EMAIL PROTECTED]> wrote: > > On Wed, 2005-09-21 at 19:36 -0500, Federico Mena Quintero wrote: > > > On Wed, 2005-09-21 at 09:38 +0200, Alexander Larsson wrote: > > > > > > > I'm not sure where we should ship the script (or perhaps a c-based > > > > version of it) though. In gnome-vfs? If its in gnome-volume-manager then > > > > people with g-v-m not installed will get the bizarre cdda:// error > > > > message, which is pretty bad. If we want the script to have e.g. warning > > > > dialogs then it needs to link to gtk+ though, which isn't very nice for > > > > gnome-vfs. Maybe libgnomeui? > > > > > > I'd rather not scatter this particular piece any more - having two > > > barely-matching pieces in gnome-vfs and g-v-m is bad enough. > > > > > > Do we care about people who run gnome-vfs but don't run g-v-m? > > > > Is g-v-m part of the desktop these days? > > Yes, it is part of the desktop[1] since Gnome 2.7[2]. > > Cheers, > Elijah > It's only part of Linux distributions of GNOME though, as it depends on HAL which is still Linux-only as far as I know. - Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
