Re: Generating .gitignore files
Behdad Esfahbod wrote: The idea is that .gitignore files are autogenerated and are NOT stored in the repository. To use, just copy git.mk into your toplevel, add it to git, run make -f git.mk and commit all changes it makes to your tree... If the generated .gitignore is not meant to be committed into the repository, maybe the script should edit .git/info/exclude instead ? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnomeweb-wml pushes not causing website updates. missing a hook?
On Sun, Apr 19, 2009 at 9:18 PM, Owen Taylor otay...@redhat.com wrote: On Sun, 2009-04-19 at 13:19 -0400, Owen Taylor wrote: On Sat, 2009-04-18 at 22:44 -0700, Sandy Armstrong wrote: Hi, Not really sure where to direct this, but I made an update to the Tomboy website 3 hours ago: http://git.gnome.org/cgit/gnomeweb-wml/commit/?id=3d1e649acdc765290de0f4a5abbec5ba0064d25f I would expect the live site to have updated by now. Are we missing a hook or some other infrastructure? Is there some manual step I can do to force an update? Indeed, not yet implemented. (The mails get sent on commit, but the scripts that parse them and trigger builds haven't been updated for changes in the mails.) I started working on it yesterday, but I got sidetracked with some GNOME Shell work. I'll try to finish up the procmail handling today. No real way you can force an update, though someone in the gnomeweb group could probably do it manually by looking at how the scripts work. I think I have this set up now, though I haven't really done any testing. I gave gnomeweb-wml a manual run after I set up the hook, so any changes to that done while the updates were unhooked should have been caught. The Tomboy website has still not been updated. Thanks, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Sat, 2009-04-18 at 21:54 -0400, Behdad Esfahbod wrote: Hey, I first wrote Makefile.am magic for Pango to generate ChangeLog from git on demand. Those macros have been modified and gathered in http://live.gnome.org/Git/ChangeLog to only generate ChangeLog for make dist. I wonder what people actually want to have, so I can work on canonical macros to copy across projects (and eventually find a better way to distribute). Pros and cons: I tweaked this macro a bit for gvfs and nautilus: Here is what I use: git log --stat -M -C --name-status --date=short --no-color | fmt --split-only Its uses less space and is imho just as useful for causual offline use. And if you want more there is git anyway. Example: - snip - commit 6fa515051dc7f082896151545a41a29853f4a3bc Author: Alexander Larsson al...@redhat.com Date: 2009-04-17 Add README.commits and dist it Add file explaining how we want commits to look. Also dist gvfs.doap and the ChangeLog.pre-1-2 M Makefile.am A README.commits commit 8cd532cf7715a4791d8156a711ecb7344b27cb46 Author: Alexander Larsson al...@redhat.com Date: 2009-04-17 Move ChangeLog to ChangeLog.pre-1-2 We're not using manual ChangeLogs anymore. R099ChangeLog ChangeLog.pre-1-2 - snip - Versus: - snip - commit 6fa515051dc7f082896151545a41a29853f4a3bc Author: Alexander Larsson al...@redhat.com Date: Fri Apr 17 10:24:37 2009 +0200 Add README.commits and dist it Add file explaining how we want commits to look. Also dist gvfs.doap and the ChangeLog.pre-1-2 Makefile.am|3 ++ README.commits | 63 2 files changed, 66 insertions(+), 0 deletions(-) commit 8cd532cf7715a4791d8156a711ecb7344b27cb46 Author: Alexander Larsson al...@redhat.com Date: Fri Apr 17 10:23:28 2009 +0200 Move ChangeLog to ChangeLog.pre-1-2 We're not using manual ChangeLogs anymore. ChangeLog | 6816 ChangeLog.pre-1-2 | 6822 + 2 files changed, 6822 insertions(+), 6816 deletions(-) - snip - ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnomeweb-wml pushes not causing website updates. missing a hook?
On Sun, 2009-04-19 at 23:58 -0700, Sandy Armstrong wrote: On Sun, Apr 19, 2009 at 9:18 PM, Owen Taylor otay...@redhat.com wrote: On Sun, 2009-04-19 at 13:19 -0400, Owen Taylor wrote: On Sat, 2009-04-18 at 22:44 -0700, Sandy Armstrong wrote: Hi, Not really sure where to direct this, but I made an update to the Tomboy website 3 hours ago: http://git.gnome.org/cgit/gnomeweb-wml/commit/?id=3d1e649acdc765290de0f4a5abbec5ba0064d25f I would expect the live site to have updated by now. Are we missing a hook or some other infrastructure? Is there some manual step I can do to force an update? Indeed, not yet implemented. (The mails get sent on commit, but the scripts that parse them and trigger builds haven't been updated for changes in the mails.) I started working on it yesterday, but I got sidetracked with some GNOME Shell work. I'll try to finish up the procmail handling today. No real way you can force an update, though someone in the gnomeweb group could probably do it manually by looking at how the scripts work. I think I have this set up now, though I haven't really done any testing. I gave gnomeweb-wml a manual run after I set up the hook, so any changes to that done while the updates were unhooked should have been caught. The Tomboy website has still not been updated. Oops, I forget the other half of the problem - to actually fix the update script to fetch from git. It doesn't look that hard. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning for GNOME 3.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Emmanuele Bassi schrieb: no need to Cc me in: I'm subscribe to d-d-l. On Sun, 2009-04-19 at 16:02 +0200, Sebastian Pölsterl wrote: what do applets provide, nowadays, and are they even remotely useful? what can deskbar-applet provide that cannot be implemented with something that does not sit inside a 24x24 icon on the most valued piece of screen real estate? isn't a gnome-do approach equivalent to the deskbar-applet? why tomboy-applet is so special? it's basically a launcher with a custom context menu. also, starting up deskbar-applet *and* tomboy as applets on my panel causes my desktop more to start up on login; not great turn ons, especially when there are developers out there trying to get the boot-to-UI process down in the seconds range. I agree that the current applet paradigm is outdated and it doesn't do well when you have a lot of applets or an applet that takes some time to load. But those are the problems we want to solve, right? I'm not saying that we should keep the whole applets system, but I want something similar to it. why? why should something continuously live on my panel and occupy space? Because you want to know which applets are currently running. In addition, applets like system monitor need to show up somewhere, otherwise they are useless. I don't care if it's called applet or widget or whatever, if it's in the panel or somewhere else. For me the idea of applets is that you can access information/functionality with minimum effort. Let's say deskbar-applet would be an application started from the menu. That would make deskbar-applet useless, because it should help you starting applications and doing tasks with less effort. Now if I have to start deskbar-applet first, I can just open the application I want to in the first place. then we don't need an icon, but we need something completely different; something that pops up (say) when you press F12; or something that comes up when I start typing on an empty workspace. I just don't see the need to have something constantly visible on a panel or on my screen, when it's all about user-initiated actions. the tomboy-applet doesn't need to stay in my notification area (why on earth does it stay in my notification area is another matter entirely, but let's overlook that for a second) when I don't need to write a note? why does it have to start when my desktop starts, when it can start when I do need to write a note and be unloaded afterwards? Keep in mind that not all applets require user interaction, some just show information and you don't have to interact with them at all (e.g. system monitor or weather applet). - -- Greetings, Sebastian Pölsterl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknsaDwACgkQ1ygZeJ3lLIfjPwCggi01Qx1YebODH5H44/K3VlDd wFoAoKccunKqZAcvp5Uuzkz8XUTJF0qc =nZbr -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning for GNOME 3.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matteo Settenvini schrieb: Just to give some ideas * do applets need to be in the panel No, and that's why Superkaramba - KDE, Google and Microsoft have come up with on-screen widgets, which may be the solution ebassi is searching for? I agree, it doesn't matter where the applets actually sit. But there must be an easy way to extend your desktop with applets that let you access informations or actions quickly. - -- Greetings, Sebastian Pölsterl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknsaQgACgkQ1ygZeJ3lLIcv8QCfRdwpVn254cemNxQojhSV9fy3 e7kAn3O8iQnP4VmqPQUIMXgRuYoRVcnh =LUln -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Owen Taylor schrieb: [...] The last thing I'll mention here is that I don't think we should be overly concerned with porting and applet parity. If there was no system monitor applet in GNOME 3.0, life would go on. What we should be concerned about is creating the ecosystem where it's easy and fun to do interesting things. And when we do there will inevitably be 23 competing system monitor applets whether we like it or not. I totally agree. As long as there's an easy way to write applets, there will be lots of applets. Unfortunately, I currently can't see what this ecosystem might look like. - -- Greetings, Sebastian Pölsterl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknsaggACgkQ1ygZeJ3lLIdHYwCeJKpIyyE1Jdx+WXAkhmtQSshA 0I4AoIDSd/3ZErkPibYO/00oC3W91d5V =jU8B -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: librsvg api
Kalle Vahlman schrieb: 2009/4/17 Stefan Kost enso...@hora-obscura.de: hi, I am using librsvg to get pixbufs for my app. I could not find a dedicated list, for it, hope this one is okay. First I am using deprecated api: rsvg_pixbuf_from_file_at_size as when using rsvg_handle_get_pixbuf I can specify the size it should be rendered (tried rsvg_handle_set_dpi and rsvg_handle_set_dpi_x_y). Any idea here? I would like to use not deprecated rsvg_handle_ API, as I need to resize the images and I'd like to keep the svg loaded. Just set new size and rerender. To do that, you'll need to render to a cairo surface with approperiate scaling and convert that to pixbuf. You can get the natural pixel size of the SVG with rsvg_handle_get_dimensions() to calculate the scaling factor. I was wondering if there is a direct way, as with the deprecated api there was. But thanks for your suggestions. Stefan The conversion can be done by either rendering to a GdkDrawable (ie. pixmap) and then using gdk_pixbuf_get_from_drawable() or using an image surface and then converting the image data to the format used by GdkPixbuf. GOffice has an example implementation of that conversion: http://git.gnome.org/cgit/goffice/tree/goffice/utils/go-cairo.c#n305 Personally I'd prefer the latter in the current X.Org driver landscape; drawing a complex SVG (specially with gradients) can seriously suck if the server needs to do lots of fallbacks to software rendering... Besides some more dom exposure would be sweet. Indeed! Not sure if anyone is actually even working on the lib still (which would be sad). It seriously lacks some loving, that's for sure. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, 2009-04-20 at 12:48 +0200, Alexander Larsson wrote: On Sat, 2009-04-18 at 21:54 -0400, Behdad Esfahbod wrote: Hey, I first wrote Makefile.am magic for Pango to generate ChangeLog from git on demand. Those macros have been modified and gathered in http://live.gnome.org/Git/ChangeLog to only generate ChangeLog for make dist. I wonder what people actually want to have, so I can work on canonical macros to copy across projects (and eventually find a better way to distribute). Pros and cons: I tweaked this macro a bit for gvfs and nautilus: Here is what I use: git log --stat -M -C --name-status --date=short --no-color | fmt --split-only Its uses less space and is imho just as useful for causual offline use. And if you want more there is git anyway. Could we get the ChangeLog generation added as a macro to gnome-common? That would make it easier, and more consistent. We should also use --since or --after so as to avoid duplicating data that's in the other ChangeLogs. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On 04/20/2009 09:02 AM, Bastien Nocera wrote: On Mon, 2009-04-20 at 12:48 +0200, Alexander Larsson wrote: On Sat, 2009-04-18 at 21:54 -0400, Behdad Esfahbod wrote: Hey, I first wrote Makefile.am magic for Pango to generate ChangeLog from git on demand. Those macros have been modified and gathered in http://live.gnome.org/Git/ChangeLog to only generate ChangeLog for make dist. I wonder what people actually want to have, so I can work on canonical macros to copy across projects (and eventually find a better way to distribute). Pros and cons: I tweaked this macro a bit for gvfs and nautilus: Here is what I use: git log --stat -M -C --name-status --date=short --no-color | fmt --split-only Its uses less space and is imho just as useful for causual offline use. And if you want more there is git anyway. I like the more verbose format clearly showing which changes are big and which are small. Could we get the ChangeLog generation added as a macro to gnome-common? That would make it easier, and more consistent. We should also use --since or --after so as to avoid duplicating data that's in the other ChangeLogs. That's basically why I'm trying to figure out how we want it to work. behdad Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, 2009-04-20 at 09:06 -0400, Behdad Esfahbod wrote: On 04/20/2009 09:02 AM, Bastien Nocera wrote: On Mon, 2009-04-20 at 12:48 +0200, Alexander Larsson wrote: On Sat, 2009-04-18 at 21:54 -0400, Behdad Esfahbod wrote: Hey, I first wrote Makefile.am magic for Pango to generate ChangeLog from git on demand. Those macros have been modified and gathered in http://live.gnome.org/Git/ChangeLog to only generate ChangeLog for make dist. I wonder what people actually want to have, so I can work on canonical macros to copy across projects (and eventually find a better way to distribute). Pros and cons: I tweaked this macro a bit for gvfs and nautilus: Here is what I use: git log --stat -M -C --name-status --date=short --no-color | fmt --split-only Its uses less space and is imho just as useful for causual offline use. And if you want more there is git anyway. I like the more verbose format clearly showing which changes are big and which are small. Well, I don't really disagree that its nice to know. However, all such info is readily availible in git, and can be posted in e.g. a release mail for all the recent changes. However, the autogenerated ChangeLog file will contain *all* post-git conversion changes, and especially with micro-commits this will be a lot, so it will eventually be quite large. So, it would be nice to do whatever we can to make our tarballs smaller that doesn't have a major impact on the usability, and while there is some loss of functionallity its not large, and we don't lose anything compared to the old ChangeLog entries. Same thing with the dates. The old ChangeLog only had dates, not time, so there is imho no loss in just using dates in the autogenerated file. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
Alexander Larsson wrote: On Mon, 2009-04-20 at 09:06 -0400, Behdad Esfahbod wrote: On 04/20/2009 09:02 AM, Bastien Nocera wrote: On Mon, 2009-04-20 at 12:48 +0200, Alexander Larsson wrote: On Sat, 2009-04-18 at 21:54 -0400, Behdad Esfahbod wrote: Hey, I first wrote Makefile.am magic for Pango to generate ChangeLog from git on demand. Those macros have been modified and gathered in http://live.gnome.org/Git/ChangeLog to only generate ChangeLog for make dist. I wonder what people actually want to have, so I can work on canonical macros to copy across projects (and eventually find a better way to distribute). Pros and cons: I tweaked this macro a bit for gvfs and nautilus: Here is what I use: git log --stat -M -C --name-status --date=short --no-color | fmt --split-only Its uses less space and is imho just as useful for causual offline use. And if you want more there is git anyway. I like the more verbose format clearly showing which changes are big and which are small. Well, I don't really disagree that its nice to know. However, all such info is readily availible in git, and can be posted in e.g. a release mail for all the recent changes. However, the autogenerated ChangeLog file will contain *all* post-git conversion changes, and especially with micro-commits this will be a lot, so it will eventually be quite large. So, it would be nice to do whatever we can to make our tarballs smaller that doesn't have a major impact on the usability, and while there is some loss of functionallity its not large, and we don't lose anything compared to the old ChangeLog entries. Same thing with the dates. The old ChangeLog only had dates, not time, so there is imho no loss in just using dates in the autogenerated file. I agree with alex. The changelog should be easily readable. big strings of +++-- make it harder to scan. If we want that detailed level of information, we can always extract it from git on demand anyway. -- jonner ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On 04/20/2009 10:00 AM, Dan Winship wrote:
Alexander Larsson wrote:
On Mon, 2009-04-20 at 09:06 -0400, Behdad Esfahbod wrote:
I like the more verbose format clearly showing which changes are big and which
are small.
Well, I don't really disagree that its nice to know. However, all such
info is readily availible in git
Right. People who want the full git history are also going to want to
have a full checkout handy, and they can just use git log with
whatever flags they like.
Here's something to generate a fairly traditional-looking ChangeLog
(though working on the assumption that you're doing the subject vs body
split in your git commit messages):
git log --date=short --pretty=format:%cd %an%ae%n%n%s%n%n%b |
perl -ne 'if (/^\s*$/) { if (!$blank) { print; $blank=1; } } else
{$blank=0; if (!s/^// !/^\t/) { print \t; } print; }'
I'd rather use awk. Listing of files is also desired, since old ChangeLog
files contained those.
behdad
%cd is commit date, %an is Author name and %ae is Author email. The perl
part indents every commit description line that doesn't already start
with a tab, and removes duplicate blank lines. Assuming the lines were
wrapped to 72 columns to start with, this will make them look too long,
but won't actually cause anything new to wrap.
-- Dan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
Alexander Larsson wrote:
On Mon, 2009-04-20 at 09:06 -0400, Behdad Esfahbod wrote:
I like the more verbose format clearly showing which changes are big and
which
are small.
Well, I don't really disagree that its nice to know. However, all such
info is readily availible in git
Right. People who want the full git history are also going to want to
have a full checkout handy, and they can just use git log with
whatever flags they like.
Here's something to generate a fairly traditional-looking ChangeLog
(though working on the assumption that you're doing the subject vs body
split in your git commit messages):
git log --date=short --pretty=format:%cd %an %ae%n%n%s%n%n%b |
perl -ne 'if (/^\s*$/) { if (!$blank) { print; $blank=1; } } else
{$blank=0; if (!s/^// !/^\t/) { print \t; } print; }'
%cd is commit date, %an is Author name and %ae is Author email. The perl
part indents every commit description line that doesn't already start
with a tab, and removes duplicate blank lines. Assuming the lines were
wrapped to 72 columns to start with, this will make them look too long,
but won't actually cause anything new to wrap.
-- Dan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Generating .gitignore files
On 04/20/2009 02:34 AM, Steve Frécinaux wrote: Behdad Esfahbod wrote: The idea is that .gitignore files are autogenerated and are NOT stored in the repository. To use, just copy git.mk into your toplevel, add it to git, run make -f git.mk and commit all changes it makes to your tree... If the generated .gitignore is not meant to be committed into the repository, maybe the script should edit .git/info/exclude instead ? Why? Other than being harder to generate (since current scheme generates per-dir .gitignore files) and generally a bad idea to touch the .git dir, man gitignore also suggests that that's the wrong place: Patterns which are specific to a particular repository but which do not need to be shared with other related repositories (e.g., auxiliary files that live inside the repository but are specific to one user´s workflow) should go into the $GIT_DIR/info/exclude file. behdad ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
On Sun, Apr 19, 2009 at 10:54:43PM -0400, Owen Taylor wrote: Crack === Brightness applet Inhibit Applet There will be often differences in opionions. I, for one, use above two applets very often. First, because changing brightness keyboard shortcut require two hands on my laptop, but operating mouse only one. Second one, because I don't want my laptop suspending when I move it, and moving is easier with closed screen. And it's way faster to single click applet instead of diving into preferences menu or rightclicking on battery indicator and navigating from there. One man's crack is another's basic functionality. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, 2009-04-20 at 10:00 -0400, Dan Winship wrote:
Alexander Larsson wrote:
On Mon, 2009-04-20 at 09:06 -0400, Behdad Esfahbod wrote:
I like the more verbose format clearly showing which changes are big and
which
are small.
Well, I don't really disagree that its nice to know. However, all such
info is readily availible in git
Right. People who want the full git history are also going to want to
have a full checkout handy, and they can just use git log with
whatever flags they like.
Here's something to generate a fairly traditional-looking ChangeLog
(though working on the assumption that you're doing the subject vs body
split in your git commit messages):
git log --date=short --pretty=format:%cd %an %ae%n%n%s%n%n%b |
perl -ne 'if (/^\s*$/) { if (!$blank) { print; $blank=1; } } else
{$blank=0; if (!s/^// !/^\t/) { print \t; } print; }'
%cd is commit date, %an is Author name and %ae is Author email. The perl
part indents every commit description line that doesn't already start
with a tab, and removes duplicate blank lines. Assuming the lines were
wrapped to 72 columns to start with, this will make them look too long,
but won't actually cause anything new to wrap.
You can rewrap with fmt --split-only.
That looks good though, but would be nice to have some reference to what
files changed. Makes it easy to search for that.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
Alexander Larsson wrote:
On Mon, 2009-04-20 at 10:00 -0400, Dan Winship wrote:
Here's something to generate a fairly traditional-looking ChangeLog
(though working on the assumption that you're doing the subject vs body
split in your git commit messages):
git log --date=short --pretty=format:%cd %an %ae%n%n%s%n%n%b |
perl -ne 'if (/^\s*$/) { if (!$blank) { print; $blank=1; } } else
{$blank=0; if (!s/^// !/^\t/) { print \t; } print; }'
%cd is commit date, %an is Author name and %ae is Author email. The perl
part indents every commit description line that doesn't already start
with a tab, and removes duplicate blank lines. Assuming the lines were
wrapped to 72 columns to start with, this will make them look too long,
but won't actually cause anything new to wrap.
You can rewrap with fmt --split-only.
Yeah, but that ends up looking bad if the lines were already wrapped
reasonably. (Also, that's a GNU-only option, so we'd probably want to
just reimplement it in the perl script if we did want.)
That looks good though, but would be nice to have some reference to what
files changed. Makes it easy to search for that.
You can do that in a slightly lame way by adding --name-only to the
git log command line. Doing something clearer than that would only take
a little more work.
But I've been including filenames or function names in most of my commit
messages, so I feel like adding them explicitly to the ChangeLog as well
would end up being redundant...
So, actually, what exactly IS the use case of ChangeLog if there is git
history on one end and NEWS on the other? Who are the people who need
more information than NEWS gives, but who would not want to actually
check out the source tree, and what information, exactly, do they need?
-- Dan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
On Mon, 2009-04-20 at 16:23 +0200, Tomasz Torcz wrote: On Sun, Apr 19, 2009 at 10:54:43PM -0400, Owen Taylor wrote: Crack === Brightness applet Inhibit Applet There will be often differences in opionions. I, for one, use above two applets very often. First, because changing brightness keyboard shortcut require two hands on my laptop, but operating mouse only one. Second one, because I don't want my laptop suspending when I move it, and moving is easier with closed screen. And it's way faster to single click applet instead of diving into preferences menu or rightclicking on battery indicator and navigating from there. One man's crack is another's basic functionality. Note that Crack was in quotes. I think it's legitimate for advanced users to want to configure their desktop in ways that simply would make no sense to the majority of the population. I'd like to foster that and extend to things that aren't just adding 24-pixel high controls to the edge of the screen. But we shouldn't confuse advanced user crack with normal customization. Think about the inhibit applet from a design point of view. A common use case that comes up for close lid without suspending is: User wants to listen to music on their laptop with the lid closed. (perhaps on a plane) Is it conceivable that the answer we'd come up with for that is: Let's have an applet available in Add to Panel described as Inhibit Applet: Allow user to inhibit automatic power saving - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, Apr 20, 2009 at 10:58 AM, Dan Winship d...@gnome.org wrote: [...] So, actually, what exactly IS the use case of ChangeLog if there is git history on one end and NEWS on the other? Who are the people who need more information than NEWS gives, but who would not want to actually check out the source tree, and what information, exactly, do they need? Generally its the tarball that is published and trusted, not the git repository. The ChangeLog comes with the published tarball like an exported history, for the use of anyone who receives the tarball (the NEWS is just a quick resume of what happened in a release). Cheers, -Tristan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, 2009-04-20 at 11:20 -0400, Tristan Van Berkom wrote: On Mon, Apr 20, 2009 at 10:58 AM, Dan Winship d...@gnome.org wrote: [...] So, actually, what exactly IS the use case of ChangeLog if there is git history on one end and NEWS on the other? Who are the people who need more information than NEWS gives, but who would not want to actually check out the source tree, and what information, exactly, do they need? Generally its the tarball that is published and trusted, not the git repository. Given that tags can be signed in Git, shouldn't it be about time that we move to a more modern way of trust, one that maintains a 1:1 mapping between changelog and changes? Kind regards, Ruben -- Ruben Vermeersch (rubenv) http://www.savanne.be/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, 2009-04-20 at 14:02 +0100, Bastien Nocera wrote: Could we get the ChangeLog generation added as a macro to gnome-common? There's a bug for it, but no apparent activity (yet): http://bugzilla.gnome.org/show_bug.cgi?id=579279 Philip That would make it easier, and more consistent. We should also use --since or --after so as to avoid duplicating data that's in the other ChangeLogs. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, Apr 20, 2009 at 11:35 AM, Ruben Vermeersch ru...@savanne.be wrote: On Mon, 2009-04-20 at 11:20 -0400, Tristan Van Berkom wrote: On Mon, Apr 20, 2009 at 10:58 AM, Dan Winship d...@gnome.org wrote: [...] So, actually, what exactly IS the use case of ChangeLog if there is git history on one end and NEWS on the other? Who are the people who need more information than NEWS gives, but who would not want to actually check out the source tree, and what information, exactly, do they need? Generally its the tarball that is published and trusted, not the git repository. Given that tags can be signed in Git, shouldn't it be about time that we move to a more modern way of trust, one that maintains a 1:1 mapping between changelog and changes? For someone that maintains a module, how you manage your ChangeLog and how much you trust your current revisioning system to do what you expect is your business, I personally feel safer populating my revision history with ChangeLog entries and not the other way around, but thats my perogative and besides the point here. On the other hand, for someone who receives your release, i.e. your tarball, they dont want to know how you manage your ChangeLog or your revision history, without forcing them to understand git, or understand branching schemes in GNOME, they still deserve an exported ChangeLog (which is why I answer to Dan, this is why we do at least need a ChangeLog, generated or otherwise). Cheers, -Tristan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning for GNOME 3.0
Emmanuele: we've been changing the platform gradually over the years, mostly by deprecating stuff and including new functionality. nevertheless, I haven't heard a single justification for the continued existence of applets. I wonder how this fits in with the gdesklets project, if at all. I know Calum Benson, UI engineer at Sun, has suggested that it would be nicer from a UI perspective if there were just one desklet/applet type interface. Perhaps moving to a gdesklets model would be nicer? Or do we need to reinvent the wheel here? Also, does the avant-window-manager fit into plans at all. In terms of providing a nice interface for keeping track of running applications and providing desktop shortcuts, it seems a nice alternative to consider. Perhaps I missed the discussion where such alternative designs are being considered, so please forgive if I'm asking a stupid question. Brian what do applets provide, nowadays, and are they even remotely useful? what can deskbar-applet provide that cannot be implemented with something that does not sit inside a 24x24 icon on the most valued piece of screen real estate? isn't a gnome-do approach equivalent to the deskbar-applet? why tomboy-applet is so special? it's basically a launcher with a custom context menu. also, starting up deskbar-applet *and* tomboy as applets on my panel causes my desktop more to start up on login; not great turn ons, especially when there are developers out there trying to get the boot-to-UI process down in the seconds range. any default GNOME installation on basically every modern distribution comes with: - menu applet - notification area - clock (+ weather) - audio volume applet - window list applet and not only I have yet to see any regular user change the contents of the panel (because it's mostly undiscoverable and because most people *just don't care*) but I also haven't heard any justification for allowing this in the first place. gnome-shell moves away from the menu and the window list applets; it embeds the notification area and the clock; and the volume is now becoming a notification area icon since basically everyone has media keys on their keyboard and don't need an on-screen slider anymore. yes, it was all good with GNOME 1.x, but even for 2.x the amount of applets has been steadily decreasing - also because writing an applet is not trivial (as it involves dealing with some of the most obscure and less documented parts of our development platform). people have been abusing the system notification area with all sorts of crap (beagle, tomboy, etc.) because writing an applet is *boring* (server files anyone?) and *hard* (weird build changes, hard to debug uses, completely different APIs for handling the menus), and it really doesn't provide you with much functionality (wow, an icon and a context menu!). so, please: saying it would be a mistake without providing reasons why it would be good to have applets support in the first place it's not going to convince me that we should keep them. ciao, Emmanuele. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
Tristan Van Berkom wrote: On Mon, Apr 20, 2009 at 10:58 AM, Dan Winship d...@gnome.org wrote: [...] So, actually, what exactly IS the use case of ChangeLog if there is git history on one end and NEWS on the other? Who are the people who need more information than NEWS gives, but who would not want to actually check out the source tree, and what information, exactly, do they need? Generally its the tarball that is published and trusted, not the git repository. The ChangeLog comes with the published tarball like an exported history, for the use of anyone who receives the tarball (the NEWS is just a quick resume of what happened in a release). But that doesn't answer the question. Who are these people who read ChangeLog, and what is it that they're doing with it, such that NEWS is too brief, but a fully-VCS-ed source tree is unnecessary. Eg, this subthread started when Alex suggested that we needed to put the names of all modified files into each ChangeLog entry. It seems to me that anyone who cares exactly which files got modified by a particular change is going to want to see the actual diff very soon after, and so those people are not actually part of the don't-need-a-full-checkout use case. But that's just a gut feeling and maybe it's wrong. The point is, ChangeLogs were invented back when RCS-files-on-an-NFS-server was the pinnacle of version control technology, and maybe what was most useful then isn't what's most useful now. -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning for GNOME 3.0
On 04/19/2009 05:38 PM, Shaun McCance wrote: The Tomboy applet is an extremely convenient way to access your notes. You think of it as wasting valuable screen real estate. But to a heavy note-taking person, it's just really convenient. Except that Tomboy using a status icon in the notification area has the exact same feature set. Just that the notification area does not offer so much possibilities in term of positioning. Hub ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning for GNOME 3.0
On Mon, Apr 20, 2009 at 9:24 AM, Hubert Figuiere h...@figuiere.net wrote: On 04/19/2009 05:38 PM, Shaun McCance wrote: The Tomboy applet is an extremely convenient way to access your notes. You think of it as wasting valuable screen real estate. But to a heavy note-taking person, it's just really convenient. Except that Tomboy using a status icon in the notification area has the exact same feature set. Just that the notification area does not offer so much possibilities in term of positioning. Sure, but it's cheating, and the goal is still the same: to have something like an applet in a predictable location. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning for GNOME 3.0
On Mon, Apr 20, 2009 at 12:24:38PM -0400, Hubert Figuiere wrote: On 04/19/2009 05:38 PM, Shaun McCance wrote: The Tomboy applet is an extremely convenient way to access your notes. You think of it as wasting valuable screen real estate. But to a heavy note-taking person, it's just really convenient. Except that Tomboy using a status icon in the notification area has the exact same feature set. Just that the notification area does not offer so much possibilities in term of positioning. Not the same. Fitts' law. Having Tomboy applet in border of screen makes it crazy big target to hit with mouse, which is good. Notification icon is many times harder to hit. The same story is now with Volume Applet. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning for GNOME 3.0
On 04/20/2009 12:37 PM, Tomasz Torcz wrote: On Mon, Apr 20, 2009 at 12:24:38PM -0400, Hubert Figuiere wrote: On 04/19/2009 05:38 PM, Shaun McCance wrote: The Tomboy applet is an extremely convenient way to access your notes. You think of it as wasting valuable screen real estate. But to a heavy note-taking person, it's just really convenient. Except that Tomboy using a status icon in the notification area has the exact same feature set. Just that the notification area does not offer so much possibilities in term of positioning. Not the same. Fitts' law. Having Tomboy applet in border of screen makes it crazy big target to hit with mouse, which is good. Notification icon is many times harder to hit. The same story is now with Volume Applet. +10 to the concept. I lost my infinitely large volume control applet with the recent rewriting These days it takes me some five seconds to find it. To anyone who thinks I'm exaggerating, put the same set of icons on your screen for years and stare at the display 12 hours a day and they fade into the backgrounds. Takes lots of brain power to see them again... Whereas my hand knew how to find the volume applet by just throwing the mouse outward to reach the top-right corner and clicking. behdad ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, 2009-04-20 at 10:58 -0400, Dan Winship wrote: So, actually, what exactly IS the use case of ChangeLog if there is git history on one end and NEWS on the other? Who are the people who need more information than NEWS gives, but who would not want to actually check out the source tree, and what information, exactly, do they need? Very good question! I used to think that a ChangLog was very nice for casual bug-fixers, who may want to fix a quickie bug without having a full clone, but maintaining those one-off patches is so cumbersome in the long run that you are much better off getting a full clone anyway. Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On 04/20/2009 12:45 PM, Federico Mena Quintero wrote: On Mon, 2009-04-20 at 10:58 -0400, Dan Winship wrote: So, actually, what exactly IS the use case of ChangeLog if there is git history on one end and NEWS on the other? Who are the people who need more information than NEWS gives, but who would not want to actually check out the source tree, and what information, exactly, do they need? Very good question! I used to think that a ChangLog was very nice for casual bug-fixers, who may want to fix a quickie bug without having a full clone, but maintaining those one-off patches is so cumbersome in the long run that you are much better off getting a full clone anyway. Indeed. These days I find it that just reading the ChangeLog comments is no where close to enough to find out *why* something is the way it is. And that's assuming that you can find the ChangeLog entry to begin with. I find myself doing the following more and more these days: - git blame, lookup the commit id of the line I'm interested in, - check the commit in full, including the patch, how things were, why they changed, and what may have been overlooked in that change. Read bug history on any bugs referenced in the commit, - If this looks like a patch in a series, do a git-log and check surrounding commits, - Only then fix the bug and have confidence in the fix. behdad Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
Le lundi 20 avril 2009 à 12:17 -0400, Dan Winship a écrit : Who are these people who read ChangeLog Hi, The ChangeLog are quite handy for distribution packages, they have a list of the changes you can look at quickly and the closed bug numbers. Usually NEWS summary are either not there or listing only main changes in the new version and not enough to know what bugs you can close while doing the upgrade for example Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning for GNOME 3.0
On Mon, Apr 20, 2009 at 6:42 PM, Behdad Esfahbod beh...@behdad.org wrote: On 04/20/2009 12:37 PM, Tomasz Torcz wrote: Not the same. Fitts' law. Having Tomboy applet in border of screen makes it crazy big target to hit with mouse, which is good. Notification icon is many times harder to hit. The same story is now with Volume Applet. +10 to the concept. I lost my infinitely large volume control applet with the recent rewriting These days it takes me some five seconds to find it. To anyone who thinks I'm exaggerating, put the same set of icons on your screen for years and stare at the display 12 hours a day and they fade into the backgrounds. Takes lots of brain power to see them again... Whereas my hand knew how to find the volume applet by just throwing the mouse outward to reach the top-right corner and clicking. Also I'd argue that notification area should sort the notifications by app name or some similar parameter that does not vary between two logons. Currently these are in a completely random order (due to multitasking and ordering notifications by start time). It wouldn't be a problem if they behaved the way I believe notification area was originally designed to work (no permanent icons, dismissable notifications) but now I get between 4 and 7 fixed icons there so finding for example volume control takes some time. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, Apr 20, 2009 at 7:10 PM, Sebastien Bacher seb...@ubuntu.com wrote: Le lundi 20 avril 2009 à 12:17 -0400, Dan Winship a écrit : Who are these people who read ChangeLog Hi, The ChangeLog are quite handy for distribution packages, they have a list of the changes you can look at quickly and the closed bug numbers. Usually NEWS summary are either not there or listing only main changes in the new version and not enough to know what bugs you can close while doing the upgrade for example Exactly, very useful when adapting downstream patches (and before you go to kick my ass, there are various kinds of patches that can't and won't go upstream including various distro-specific path customizations at build time). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, 2009-04-20 at 12:17 -0400, Dan Winship wrote: Tristan Van Berkom wrote: On Mon, Apr 20, 2009 at 10:58 AM, Dan Winship d...@gnome.org wrote: [...] So, actually, what exactly IS the use case of ChangeLog if there is git history on one end and NEWS on the other? Who are the people who need more information than NEWS gives, but who would not want tSysadmins, Package maintainersmo actually check out the source tree, and what information, exactly, do they need? Generally its the tarball that is published and trusted, not the git repository. The ChangeLog comes with the published tarball like an exported history, for the use of anyone who receives the tarball (the NEWS is just a quick resume of what happened in a release). But that doesn't answer the question. Who are these people who read ChangeLog, and what is it that they're doing with it, such that NEWS is too brief, but a fully-VCS-ed source tree is unnecessary. Eg, this subthread started when Alex suggested that we needed to put the names of all modified files into each ChangeLog entry. It seems to me that anyone who cares exactly which files got modified by a particular change is going to want to see the actual diff very soon after, and so those people are not actually part of the don't-need-a-full-checkout use case. But that's just a gut feeling and maybe it's wrong. The point is, ChangeLogs were invented back when RCS-files-on-an-NFS-server was the pinnacle of version control technology, and maybe what was most useful then isn't what's most useful now. Sysadmins and they take the decision if it worth an update/upgrade or when they should do it. If we ask people to read ChangeLogs from git, I wonder why do we bother in releasing tarballs when they could them from the repository also? (in the sense you can get a tar.gz/tar.bz2, they are tagged, etc.) -- Germán Póo-Caamaño Concepción - Chile http://www.gnome.org/~gpoo/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning for GNOME 3.0
Brian Cameron schrieb: Emmanuele: we've been changing the platform gradually over the years, mostly by deprecating stuff and including new functionality. nevertheless, I haven't heard a single justification for the continued existence of applets. I wonder how this fits in with the gdesklets project, if at all. I know Calum Benson, UI engineer at Sun, has suggested that it would be nicer from a UI perspective if there were just one desklet/applet type interface. Perhaps moving to a gdesklets model would be nicer? Or do we need to reinvent the wheel here? Also, does the avant-window-manager fit into plans at all. In terms of providing a nice interface for keeping track of running applications and providing desktop shortcuts, it seems a nice alternative to consider. Perhaps I missed the discussion where such alternative designs are being considered, so please forgive if I'm asking a stupid question. Brian one major difference between desktop applets and panel applets is that windows don't cover the panels. I brought a 24 screen for a good reason. On such a setup I can easily spare 24 pixels here and there for the desktop. This way I can easily see on gnome system monitor when my build is done and I don't need to minimize windows to see how late it is. Stefan what do applets provide, nowadays, and are they even remotely useful? what can deskbar-applet provide that cannot be implemented with something that does not sit inside a 24x24 icon on the most valued piece of screen real estate? isn't a gnome-do approach equivalent to the deskbar-applet? why tomboy-applet is so special? it's basically a launcher with a custom context menu. also, starting up deskbar-applet *and* tomboy as applets on my panel causes my desktop more to start up on login; not great turn ons, especially when there are developers out there trying to get the boot-to-UI process down in the seconds range. any default GNOME installation on basically every modern distribution comes with: - menu applet - notification area - clock (+ weather) - audio volume applet - window list applet and not only I have yet to see any regular user change the contents of the panel (because it's mostly undiscoverable and because most people *just don't care*) but I also haven't heard any justification for allowing this in the first place. gnome-shell moves away from the menu and the window list applets; it embeds the notification area and the clock; and the volume is now becoming a notification area icon since basically everyone has media keys on their keyboard and don't need an on-screen slider anymore. yes, it was all good with GNOME 1.x, but even for 2.x the amount of applets has been steadily decreasing - also because writing an applet is not trivial (as it involves dealing with some of the most obscure and less documented parts of our development platform). people have been abusing the system notification area with all sorts of crap (beagle, tomboy, etc.) because writing an applet is *boring* (server files anyone?) and *hard* (weird build changes, hard to debug uses, completely different APIs for handling the menus), and it really doesn't provide you with much functionality (wow, an icon and a context menu!). so, please: saying it would be a mistake without providing reasons why it would be good to have applets support in the first place it's not going to convince me that we should keep them. ciao, Emmanuele. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, 2009-04-20 at 15:37 -0400, Germán Póo-Caamaño wrote: But that's just a gut feeling and maybe it's wrong. The point is, ChangeLogs were invented back when RCS-files-on-an-NFS-server was the pinnacle of version control technology, and maybe what was most useful then isn't what's most useful now. Sysadmins and they take the decision if it worth an update/upgrade or when they should do it. If we ask people to read ChangeLogs from git, I wonder why do we bother in releasing tarballs when they could them from the repository also? (in the sense you can get a tar.gz/tar.bz2, they are tagged, etc.) This is a totally bogus comparison in so many way. First of all, not everyone has the setup necessary to dist from the repository, secondly a release that you can put on a ftp site, CD, in an rpm, or whatever is clearly necessary, whereas its not at all obvious exactly how and if a ChangeLog in the tarball is used. For instance, if a sysadmin wants to determine wheter to update to the new release of gtk+. Starting from zero data, how does he start? Does he download the tarball and extract the ChangeLog? Possibly so, but it seems vastly easier to look at e.g the release mail, the NEWS file on the ftp site, or even the gnome cgit instance. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning for GNOME 3.0
2009/4/19 Emmanuele Bassi eba...@gmail.com: On Sun, 2009-04-19 at 23:26 +0200, Luca Ferretti wrote: Fortunately Ubuntu is yet experimenting on alternate, ephimeral notifications ;) that has nothing to do with applets, gadgets/widgets/desktlets/whatever and resident application. I've a different point of view. If we want to redesign the GNOME shell, if we want to keep applets/gadgets/widgets/desktlets/whatever (or if we have to keep for users' sake[0]), we have to draw a line between *notifications* and *gadgets*. We have to choose if is better to maintain something abused as current notification area or, instead, to switch to a status area[1] supported by a different notification system. We were yet talking about a different approach to notifications[2], the Ubuntu experiment could be an interesting playground to investigate where and how we can move shell components. [0] and for vendors' sake too. A recent example: Dell is adding a stupid applet on Mini 9, a simple help icon to pop-up a menu, each menu entry pointing to a different section of Ubuntu guide (Internet, Music, Updates, Printers..). For me this is the most unuseful applet, but I started to use GNOME in 1.x times; instead it could be really useful for a new user as well as for Dell support (less request how can I do .. ?). GNOME is not a final product, it's a platform for vendors [1] Currently, on my screen, in notification area there are battery _status_ indicator, network _status_ indicator and bluetooth icon... not so much notifications ;) [2] http://live.gnome.org/AlternativeNotificationsUI ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
On Mon, Apr 20, 2009 at 10:07 AM, Owen Taylor otay...@redhat.com wrote: On Mon, 2009-04-20 at 16:23 +0200, Tomasz Torcz wrote: On Sun, Apr 19, 2009 at 10:54:43PM -0400, Owen Taylor wrote: One man's crack is another's basic functionality. Note that Crack was in quotes. I think it's legitimate for advanced users to want to configure their desktop in ways that simply would make no sense to the majority of the population. Actually, one man's crack can still be another man's crack. Just because you find it useful (or legitimate, or necessary) doesn't mean it's not still crack, not bad UI practice, and that you're not simply addicted. It just means you don't want to admit it. :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
2009/4/20 Owen Taylor otay...@redhat.com: The last thing I'll mention here is that I don't think we should be overly concerned with porting and applet parity. If there was no system monitor applet in GNOME 3.0, life would go on. What we should be concerned about is creating the ecosystem where it's easy and fun to do interesting things. And when we do there will inevitably be 23 competing system monitor applets whether we like it or not. I like gnome-system-monitor a lot. It is on all gnome installations I use and it is the first thing I customize when installing a new computer. It's the best applet there is and if you disagree it's because you haven't given it a chance. :) It is the perfect tool for quickly detecting abnormal memory usage and monitoring cpu intensive batch jobs (such as compiles). Life does not go on and no gnome-system-monitor equivalent in 3.0 is deal breaker for me, personally. It is also the only system monitor applet, so why would 23 new ones pop up with the new system? Why wouldn't it be possible to port the good applets we have to 3.0? A lot of work has gone into them and just throwing them away seems wasteful to me. -- mvh Björn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
Hey Owen, The main open question for gnome-shell is not how to implement them. It's the user interface question. And when we look at the user interface question I think the label applet is a bit deceptive. We have all sort of different things that are applets, and their only commonality is that they go on the panel. The better approach is to start from the tasks and functionality Not really responding to this directly since, as usual, your analysis is very good. I think one of the most important cases against applets (as they are currently defined in GNOME) is that they are extremely detrimental to the Identity of the product or platform. Today, our entire desktop identity is defined by a configurable number of horizontal or vertical bars filled with any number (even duplicates) of random Things that may launch stuff, open menus, open dialogs, operate on windows, switch workspaces, and more! Boxes-o-crap as I lovingly (in the eulogistic sense) refer to them. Each time I see Remove from panel when I right click on the notification area or the menu system I weep and my mascara runs and god is it awful. Let's say that we are trying to define either a product or a product platform. I don't think it is possible to do this without some brand coherence. And it is arguably impossible to do this effectively with such an ad-hoc/individually-customized design identity. Even those of us in the developer community would have a difficult time identifying a GNOME desktop in 3-5 steps. Let's try this with Windows: Start or Windows symbol menu, (usually) bar at the bottom. This works from Windows Server products all the way to embedded Windows on smartphones. With OS X: Apple logo menu, menu bar at the top, (usually) a dock. Even though the iPhone doesn't have the same software identification experience it retains the platform design branding on the hardware and uses familiar themes in the software visual design. There is usually no doubt that it is an Apple platform. With Android: who knows... So, one of the many very exciting things about GNOME Shell is that for the first time we may have ability to really shape the user experience and form an identity for the GNOME platform. That said, I agree that it is very important to have a number of extension points. * At the platform level to shape a different user experience (usually for devices with different form-factors and goals). I would expect this to probably be only at build/integration time. * Something like a new status area where extensions behave in a very consistent and well-defined manner - the current notification area applets are neither * A place where the rules are more relaxed and fun things can happen - maybe a sidebar - maybe Vegas... As you mentioned the current applet design conflates these things. I think we can do a lot better. Better default experience, more consistency, more fun! Unity! We're doing something together here and it is about time we started looking like it. Jon ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
Applets in general are broken because they are no different in functionality from regular applications, or from each other (in terms of desklets vs panel applets vs. the notification area). Many applets are applets because they have very small, simple interfaces; too small to justify having big top-level windows, too big to sit entirely in the background. The big usability disaster this distinction creates is that the application menu goes from being The Way to run applications to being A Way to run applications; another bunch of them are run by right clicking on the panel and choosing to add an applet. Lots of applets act as launchers. For example, timerapplet[0]. The user clicks it, it opens a little dialog, the applet becomes a stylish countdown timer with a nice icon. This could have been done differently. Alternatively, timerapplet could be opened from Applications-Accessories, create a notification icon and be reasonably close to the HIG. The problem there is Accessories would become bloated with stuff like Wanda the fish, stock tickers, eyes and alarm clocks, and also timerapplet would be jumping from one corner of the screen (where it's a launcher) to another (where it's a window). Hence the panel applets; a dumping ground for accessories that don't quite deserve to take up 30 pixels of vertical space in the Applications menu but can go somewhere else we never expect the user to use. Instead, because timerapplet is too small and insignificant to consume menu space, it is opened with the panel every time the user logs in! (Wait, what?...) Similarly, all sorts of applications choose to hide within the notification area because they want to stay out of the user's way and window managers fail to provide the necessary functionality themselves. Thus, they take window management upon themselves and start playing with system trays. This should remind you, tenacious reader, of tabbed document interfaces, notification-daemon abuse (for fancy looking dialog boxes), anthropomorphic dogs and rabbity things. So here are some questions to answer: What is so vastly inferior about the application menu that necessitates applet software to provide another distinct list of less important applications? Why can't we have big and small applications in the same place? I do have a guess what could be done. Firstly, abolish applets as things which must be run differently from other applications; the user should not Ever see the word applet again. Enhance running applications and how they connect with application launchers and their windows; one of the things GNOME Shell seems to be doing. Maybe one way about this is to build on that part of the window manager where it's up to The User whether he wants to minimize a window, shade it or put it beside another on the right side of the screen. How about window management hotspots, such as a panel and a sidebar, each with unique properties for how they treat windows? The user places a window in one of those and, depending on whether it supports some fancy extensions, it becomes a docked window like any file in the panel or the desktop (eg: a window icon that when clicked opens into a full window again). Super awesomeness could extend that so the docked window gains desklety / applety functionality when supported. Basically, kill the distinction and leave it up to the user to say what he wants a window to do rather than have them making unpredictable guesses, and have the window - or whatever other object - do what it can to meet the user's commands. [0] http://timerapplet.sourceforge.net/ Thanks, sorry for the hugeness, Dylan McCall PS: I wrote this bit by bit over a couple /days/, so I'm sending this at risk of it being completely incomprehensible. Forgive me if that's the case. Mockup almost at the ready if it'll help. PPS: A nice process here is writing out key features of different parts of the desktop environment which implement window management. Lots of overlap, but also lots of examples for how existing infrastructure can be beefed up as an alternative, tidier solution. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bumping required version of DeviceKit-power to 007
Le samedi 18 avril 2009, à 10:03 +0100, Richard Hughes a écrit : Can I bump the external dependencies version of DeviceKit-power from 006 to 007 for 2.27.x please? 007 was released a few weeks ago, and fixes many bugs I don't want to work around in gnome-power-manager anymore. Sounds good. Please update the wiki page and the jhbuild moduleset to make this official :-) Thanks, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Sat, 2009-04-18 at 22:23 -0400, Tristan Van Berkom wrote: I first wrote Makefile.am magic for Pango to generate ChangeLog from git on demand. Those macros have been modified and gathered in http://live.gnome.org/Git/ChangeLog to only generate ChangeLog for make dist. I wonder what people actually want to have, so I can work on canonical macros to copy across projects (and eventually find a better way to distribute). Pros and cons: Personally, I prefer maintaining an actual revisioned ChangeLog file, simply because I like having the ChangeLog as a part of the project data, revisioning tools come and go, projects get exported and imported, but the ChangeLog always remains in the repository or published tarball. Yeah, but the thing that sucks about versioned ChangeLogs is merging/rebasing your code. Typically you always leave writing a ChangeLog last for this reason, but it just makes so much more sense to be able to write your entry when you do your commit. If you're posting a branch for review or something, people can read your commit logs as well as the code.. but if you post patches for review, you probably don't post the ChangeLog with it because it'll get clobbered when you have to merge it into the tree. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How to remove remote branch with git?
Le samedi 18 avril 2009, à 22:28 +0200, Frederic Peters a écrit : Jaap A. Haitsma wrote: I just did my first commit with git (Yay!!). However I first made a mistake and made a new remote branch called jaap in the cheese project. I now want to remove that branch because it was a mistake. How do I do this? What I read from the web I need to do the following git push ssh://jhait...@git.gnome.org/git/cheese origin :jaap What about git push origin :jaap ? Added to http://live.gnome.org/Git/FAQ Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Adding module descriptions
Le vendredi 17 avril 2009, à 11:46 -0400, Owen Taylor a écrit : B) Drop MAINTAINERS and move the information to the DOAP file. (There would be some sort of transition period where we would support both.) I like B) better; I'd rather one file than a collection of little files. Here's another +1. Can we just go ahead and do it? :-) (I saw no objection so far) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Adding module descriptions
Le vendredi 17 avril 2009, à 20:55 +0200, Patryk Zawadzki a écrit : The point is deps are not changed at random, the person merging code changes is the best person to update build deps. This is unfortunately not something you can always find in ChangeLog/NEWS. What about reminding maintainers that they really should mention this kind of stuff in NEWS each time you see this not happening? I mean, this should really be in NEWS anyway... Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
On Mon, Apr 20, 2009 at 6:10 PM, Dylan McCall dylanmcc...@gmail.com wrote: Similarly, all sorts of applications choose to hide within the notification area because they want to stay out of the user's way and window managers fail to provide the necessary functionality themselves. Thus, they take window management upon themselves and start playing with system trays. This should remind you, tenacious reader, of tabbed document interfaces, notification-daemon abuse (for fancy looking dialog boxes), anthropomorphic dogs and rabbity things. This one at least has been solved in Windows 7 by merging the QuickLaunch area with running applications. A dock would also solve this problem nicely. You'll notice OS X doesn't have a lot of applets on the menu bar. The only one I've seen a lot of people have is smcFanControl. -- Travis Watkins http://www.realistanew.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
