Re: Backtracing, Invalidated Bugs and Quality

[Krzysztof Lichota]

2008/8/21 Christopher James Halse Rogers <[EMAIL PROTECTED]>:
> In what way is this different to the current Apport infrastructure?  My
> understanding is that the client sends in the crashdump and the apport
> retracers on launchpad replay it on a system with the debugging symbols
> installed.
>
> The retracable crashdumps are already nicely handled; how does the
> symbols server help in cases when the retracers would fail?

I don't know apport architecture, but the people in this thread were
discussing installation of debug packages on client to improve
backtraces, so I assumed they are needed for something...

-- 

Krzysztof Lichota

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Backtracing, Invalidated Bugs and Quality

[Sense Hofstede]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Scott Kitterman schreef:
> On Wed, 20 Aug 2008 18:42:01 +0100 "Caroline Ford" 
> <[EMAIL PROTECTED]> wrote:
>> 2008/8/20 Alexander Sack <[EMAIL PROTECTED]>:
>>
>>> But there are also many crash reports where the retracers fail and we
>>> dont have any testcase. You want those to stay open as well?
>> But what do we do with these then? They are still bugs, and with some
>> crashes we never seem to get a backtrace with symbols.
>>
>> Currently we just close them and hope they go away..
> 
> Personally, I think closing them after some period if similar crashes stop 
> coming is reasonable.  For me I think the period should be rather long 
> (like most of a development cycle) unless there is reason to think 
> something's actually been fixed.
> 
> There are a wide range of styles project can using for managing their bug 
> database.  I've worked on projects that never closed bugs that they 
> couldn't tie to a specific fix.  I worked for another one that had a bug 
> status called OTO for One Time Only.  This was treated as very close to 
> closed, but was actively checked for dupes.  I recall another where the 
> project manager routinely ordered bugs to be closed (because he'd told 
> someone it was fixed) without reference to the state of the code base.  
> That one did not end well.
> 
> I think we have veered to far in the direction of closing bugs.  It's 
> almost as if someone, in homage to Emporer Joseph II in Amadeus said, 
> "There are simply too many bugs".
> 
> I'd probably find it more useful if bug triagers invested more time in 
> trying to reproduce bugs and get them to Triaged and less of finding ones 
> they might close.
> 
> Scott K
> 

You've got a good point here. Our main goal should be turn as much bugs
is possible into bugs that contain enough information for the other
teams to fix them, not to close as much invalid bugs as possible.
Triaging bugs correctly is something that is good for a lot of people,
closing invalid bugs is just good for the bugsquad and people searching
the bug database. That doesn't mean it isn't important, of course.  
However, I feel that our task is kind of like the assistants of the
prime-minister that prepare his state visit. They look up background
information about the destination, create a scheme and brief the
prime-minister about his visit. We too make sure all information is in
place for the fixer to start. If (s)he has to look up a lot of
information that's easy to find before (s)he can start, less bugs will
be fixed. Of course it isn't a bad thing when the fixer needs to look up
some things by himself, but I think that (s)he should at least know what
(s)he's supposed to fix.
That's why I think that making bugs good should be the main task of a
bug triager. It's not about how much you can mark as triage, but how
good you triaged them. Marking bugs as invalid can be a good thing, but
only when it's really necessary. Specifically looking for them is a
waste of time. I don't really like the idea of marking bugs that could
be a bug invalid. When a bug has a reasonable description -- not
something like "NO SCREN! ATI What shuld I do?" -- I think it shouldn't
be marked as invalid unless the author specifically tells that it has
been fixed for him(like Scott already said). I really like the OTO
status, I think it would be good to implement it in Launchpad.

It's not bad to have a lot of incomplete bugs. What matters is that as
much bugs as possible get fixed as quick as possible. Whether some bugs
are marked as invalid or incomplete doesn't matter there, maybe it can
even make things better since bugs would stay in-sight for a longer time.

- --
Sense Hofstede


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIrreQxft9JZoh5JwRAjAoAKC85BmXCHjIwIieRVR1wYHN5n0TLQCgrsOj
UvlOmhjQZu6tauHq/nnqW6s=
=pOJY
-END PGP SIGNATURE-

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Backtracing, Invalidated Bugs and Quality

[Brian Curtis]

I haven't been following along very closely, but I have an idea on something
that might help out with bug management (assuming this hasn't been talked
about).

I went through and marked a bunch of bugs as incomplete yesterday because it
seems that pidgin was updated and their problems were resolved and the bug
creator didn't come back to close their bug out.

My idea is to have launchpad send out an e-mail to the bug creators of bugs
relating to packages that were recently updated asking them to check with
the update (provide instructions on how to update) to see if their problem
is resolved, while also marking the bug reports with something like "package
update check" which will expire the report if the bug creators (or
subscribers) find their problems resolved and don't attempt to close their
reports.  In my opinion this would help close out many bugs only leaving the
important ones to devs/triagers.

Opinions?/Possibility?/Comments?

~Brian C.

Research is what I'm doing when I don't know what I'm doing.
--Wernher Von Braun
"The second law of thermodynamics: If you think things are in a mess now,
JUST WAIT!!"


On Fri, Aug 22, 2008 at 8:56 AM, Sense Hofstede <[EMAIL PROTECTED]> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Scott Kitterman schreef:
> > On Wed, 20 Aug 2008 18:42:01 +0100 "Caroline Ford"
> > <[EMAIL PROTECTED]> wrote:
> >> 2008/8/20 Alexander Sack <[EMAIL PROTECTED]>:
> >>
> >>> But there are also many crash reports where the retracers fail and we
> >>> dont have any testcase. You want those to stay open as well?
> >> But what do we do with these then? They are still bugs, and with some
> >> crashes we never seem to get a backtrace with symbols.
> >>
> >> Currently we just close them and hope they go away..
> >
> > Personally, I think closing them after some period if similar crashes
> stop
> > coming is reasonable.  For me I think the period should be rather long
> > (like most of a development cycle) unless there is reason to think
> > something's actually been fixed.
> >
> > There are a wide range of styles project can using for managing their bug
> > database.  I've worked on projects that never closed bugs that they
> > couldn't tie to a specific fix.  I worked for another one that had a bug
> > status called OTO for One Time Only.  This was treated as very close to
> > closed, but was actively checked for dupes.  I recall another where the
> > project manager routinely ordered bugs to be closed (because he'd told
> > someone it was fixed) without reference to the state of the code base.
> > That one did not end well.
> >
> > I think we have veered to far in the direction of closing bugs.  It's
> > almost as if someone, in homage to Emporer Joseph II in Amadeus said,
> > "There are simply too many bugs".
> >
> > I'd probably find it more useful if bug triagers invested more time in
> > trying to reproduce bugs and get them to Triaged and less of finding ones
> > they might close.
> >
> > Scott K
> >
>
> You've got a good point here. Our main goal should be turn as much bugs
> is possible into bugs that contain enough information for the other
> teams to fix them, not to close as much invalid bugs as possible.
> Triaging bugs correctly is something that is good for a lot of people,
> closing invalid bugs is just good for the bugsquad and people searching
> the bug database. That doesn't mean it isn't important, of course.
> However, I feel that our task is kind of like the assistants of the
> prime-minister that prepare his state visit. They look up background
> information about the destination, create a scheme and brief the
> prime-minister about his visit. We too make sure all information is in
> place for the fixer to start. If (s)he has to look up a lot of
> information that's easy to find before (s)he can start, less bugs will
> be fixed. Of course it isn't a bad thing when the fixer needs to look up
> some things by himself, but I think that (s)he should at least know what
> (s)he's supposed to fix.
>That's why I think that making bugs good should be the main task of
> a
> bug triager. It's not about how much you can mark as triage, but how
> good you triaged them. Marking bugs as invalid can be a good thing, but
> only when it's really necessary. Specifically looking for them is a
> waste of time. I don't really like the idea of marking bugs that could
> be a bug invalid. When a bug has a reasonable description -- not
> something like "NO SCREN! ATI What shuld I do?" -- I think it shouldn't
> be marked as invalid unless the author specifically tells that it has
> been fixed for him(like Scott already said). I really like the OTO
> status, I think it would be good to implement it in Launchpad.
>
> It's not bad to have a lot of incomplete bugs. What matters is that as
> much bugs as possible get fixed as quick as possible. Whether some bugs
> are marked as invalid or incomplete doesn't matter there, maybe it can
> even make things better since bugs would s

Drag Window from anywhere in Metacity?

[Dylan McCall]

I recently noticed a really awesome feature in Matchbox. When it is set
to have windows in free mode (rather than fixed), one can drag those
windows from /anywhere/. As long as the widget being dragged does not
handle the necessary click events itself (eg: Is a button, text box,
scroll bar, etc), the event is handled by Matchbox and used to drag the
window. I found that very smooth and very smart. It is quite a unique
feature in the world of operating systems.

Now for the question: Why is such awesome functionality currently only
found in a window manager intended for PDAs?

Has there been discussion of implementing this feature for Metacity? It
would be particularly useful with the discussion of changing window
decorators, since this would keep moving windows on Metacity's end so we
never lose that functionality.


Thanks,
-Dylan


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Drag Window from anywhere in Metacity?

[Mackenzie Morgan]

On Fri, Aug 22, 2008 at 12:12 PM, Dylan McCall <[EMAIL PROTECTED]> wrote:
> I recently noticed a really awesome feature in Matchbox. When it is set
> to have windows in free mode (rather than fixed), one can drag those
> windows from /anywhere/. As long as the widget being dragged does not
> handle the necessary click events itself (eg: Is a button, text box,
> scroll bar, etc), the event is handled by Matchbox and used to drag the
> window. I found that very smooth and very smart. It is quite a unique
> feature in the world of operating systems.
>
> Now for the question: Why is such awesome functionality currently only
> found in a window manager intended for PDAs?
>
> Has there been discussion of implementing this feature for Metacity? It
> would be particularly useful with the discussion of changing window
> decorators, since this would keep moving windows on Metacity's end so we
> never lose that functionality.

I don't know if you know this already but think it's insufficient, but
if you hold down Alt you can click and drag a window from anywhere
too.

-- 
Mackenzie Morgan
Linux User #432169
ACM Member #3445683
http://ubuntulinuxtipstricks.blogspot.com <-my blog of Ubuntu stuff
apt-get moo

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Drag Window from anywhere in Metacity?

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dylan McCall wrote on 22/08/08 17:12:
> 
> I recently noticed a really awesome feature in Matchbox. When it is set
> to have windows in free mode (rather than fixed), one can drag those
> windows from /anywhere/. As long as the widget being dragged does not
> handle the necessary click events itself (eg: Is a button, text box,
> scroll bar, etc), the event is handled by Matchbox and used to drag the
> window. I found that very smooth and very smart. It is quite a unique
> feature in the world of operating systems.

All brushed-metal windows in Mac OS had this behavior, starting with
QuickTime Player 4.0 in 1999 and iTunes in 2001. As of Mac OS X 10.5
(which abolished brushed-metal windows), it is standard behavior for all
windows.

>...
> Has there been discussion of implementing this feature for Metacity?
>...

I've suggested it occasionally, but haven't seen anyone else express any
interest.

> It would be particularly useful with the discussion of changing window
> decorators, since this would keep moving windows on Metacity's end so
> we never lose that functionality.
>...

What discussion are you referring to?

Cheers
- --
Matthew Paul Thomas
http://mpt.net.nz/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIrvLB6PUxNfU6ecoRAkB8AKCV8E7Sd1rkr7z9N+njvnel2RA47ACgq1D6
e8+rN7ZcxJ0BTeJT2ceD3vw=
=4IQg
-END PGP SIGNATURE-

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Drag Window from anywhere in Metacity?

[Mackenzie Morgan]

On Fri, Aug 22, 2008 at 1:09 PM, Matthew Paul Thomas <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Dylan McCall wrote on 22/08/08 17:12:
>>
>> I recently noticed a really awesome feature in Matchbox. When it is set
>> to have windows in free mode (rather than fixed), one can drag those
>> windows from /anywhere/. As long as the widget being dragged does not
>> handle the necessary click events itself (eg: Is a button, text box,
>> scroll bar, etc), the event is handled by Matchbox and used to drag the
>> window. I found that very smooth and very smart. It is quite a unique
>> feature in the world of operating systems.
>
> All brushed-metal windows in Mac OS had this behavior, starting with
> QuickTime Player 4.0 in 1999 and iTunes in 2001. As of Mac OS X 10.5
> (which abolished brushed-metal windows), it is standard behavior for all
> windows.

Brushed metal windows were Carbon, I think.  I'm also pretty sure what
you're saying of Cocoa is not true though.  Just got a Mac user nearby
to demonstrate it, actually.   You have to click in the titlebar to
move the window.  Not having Alt-Click-and-move-from-anywhere is one
of my big complaints about Apple's window manager.

-- 
Mackenzie Morgan
Linux User #432169
ACM Member #3445683
http://ubuntulinuxtipstricks.blogspot.com <-my blog of Ubuntu stuff
apt-get moo

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Drag Window from anywhere in Metacity?

[Dylan McCall]

> Brushed metal windows were Carbon, I think.  I'm also pretty sure what
> you're saying of Cocoa is not true though.  Just got a Mac user nearby
> to demonstrate it, actually.   You have to click in the titlebar to
> move the window.  Not having Alt-Click-and-move-from-anywhere is one
> of my big complaints about Apple's window manager.

What I'm talking about with Matchbox is very different from that. It
basically lets me drag a window from any area where it is not using
mouse input. That's with a normal click, not an Alt+Click.
Thus, I am not reliant on the title bar to move the window and the
system gets a much more consistent and physical feel. The user no longer
has to arbitrarily aim at a small title bar.
A similar concept to kinetic scrolling, really. It is simple, but makes
the are the user must click more logical and ergonomic.

With MacOS and Windows Vista, they have this sort of behaviour in some
windows, but not in all. For example, one can drag Windows Media Player
by the toolbar, but can not do so with Photo Gallery (even though it
uses the same UI style). MacOS is of course way more consistent, but
even it sometimes has a point in the UI where a window arbitrarily stops
being draggable. With this behaviour being handled by the same thing
that does title bar dragging, we can have it completely consistent.


Bye,
-Dylan


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Drag Window from anywhere in Metacity?

[Markus Hitter]

Am 22.08.2008 um 19:16 schrieb Mackenzie Morgan:

> You have to click in the titlebar to move the window.  Not having  
> Alt-Click-and-move-from-anywhere is one of my big complaints about  
> Apple's window manager.


In Mac OS X, drag-from-anywhere is a feature not of the window  
manager, but implemented on the widget set level (Cocoa, Carbon). A  
developer decides at interface design time wether his app has this  
feature or not. Some developers prefer their app to be drag-from- 
titlebar-only, others don't. Both types of apps coexist smoothly.


To add my $ o.o2 to the Ubuntu discussion: the drag-from-anywhere  
feature isn't always useful, but as well never gets into the way. I'd  
drop the requirement to hold down the Alt key.


MarKus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/





-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Drag Window from anywhere in Metacity?

[Mackenzie Morgan]

On Fri, Aug 22, 2008 at 2:00 PM, Markus Hitter <[EMAIL PROTECTED]> wrote:
>
> Am 22.08.2008 um 19:16 schrieb Mackenzie Morgan:
>
>> You have to click in the titlebar to move the window.  Not having
>> Alt-Click-and-move-from-anywhere is one of my big complaints about Apple's
>> window manager.
>
> In Mac OS X, drag-from-anywhere is a feature not of the window manager, but
> implemented on the widget set level (Cocoa, Carbon). A developer decides at
> interface design time wether his app has this feature or not. Some
> developers prefer their app to be drag-from-titlebar-only, others don't.
> Both types of apps coexist smoothly.

Developer option?  Ugh, that's a good way to get rid of that
consistency they brag about.  Well, Apple's own apps don't do
drag-from-anywhere.  I haven't really used many 3rd party
ones...NeoOffice, Fink, Camino, Adium...about it.  If it's added to
GNOME/GTK/Ubuntu, can we please make it something that affects all
apps, not just ones where the dev decided to be different?  "I can
click here and move my Firefox, but not Pidgin, is Pidgin broken?"
doesn't sound like a good situation.

-- 
Mackenzie Morgan
Linux User #432169
ACM Member #3445683
http://ubuntulinuxtipstricks.blogspot.com <-my blog of Ubuntu stuff
apt-get moo

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Announcing Michael Casadevall as an Xubuntu Developer

[Cody A.W. Somerville]

Hello Developers,

 I'd like everyone to give a warm welcome to Michael Casadevall (
https://launchpad.net/~sonicmctails )
who (after impressing me with his kung-foo) is joining the Xubuntu Team as a
Xubuntu Developer. Michael is an exceptionally dedicated individual with a
strong, diversified pool of talent and skill who is eagerly working towards
becoming a MOTU. Michael, an Xfce4 user for close to a year, will be
assisting us with general packaging and development tasks for the most part
but I'm sure his keen ability to fix FTBFS; experience with ports, debian,
and gnome; and demonstrated initiative in other teams to identify and refine
infrastructure and processes for the better will be a huge asset to our
team. In fact, I think Michael is tackling packaging the unreleased alpha of
xfce 4.6 into our team PPA as we speak :-).

You can contact Michael via e-mail at [EMAIL PROTECTED] or tackle him
on IRC in #xubuntu-devel (look for NCommander).

Cheers,

-- 
Cody A.W. Somerville
Release Engineer
Canonical OEM Solutions Group
Cell: 506-449-5899
Email: [EMAIL PROTECTED]
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Drag Window from anywhere in Metacity?

[Dylan McCall]

Woohoo! I (sort of) figured it out and created a branch implementing
this change on Launchpad. So far it's more a proof of concept than
anything else.

The branch is here:
code.launchpad.net/~dylanmccall/metacity/drag-from-anywhere

To test this, you will need to run "./src/metacity --replace" after
building. I don't recommend installing this over your current Metacity.
(Yet).

Works beautifully for preferences dialogs. Strangely, the expected
behaviour does not occur with menu bars or toolbars, which seems a bit
odd. Perhaps GTK is handling the events when it doesn't need to.
Everywhere else it is wonderful -- and yes, that includes the status bar
in F-Spot. (Eat that, Windows Photo Gallery!).
No broken functionality detected so far, but I should get in touch with
the Metacity developers to make sure...

At the moment, a middle click and a right click in the client area pops
up the respective actions as if the area is in fact a title bar. It's
kind of neat, but I think it would be better with different operations.
For example, middle click could do a resize operation (dealing with the
small window borders problem in a small way).

I should make this a gconf option. Maybe "touch screen mode", with
another added bonus being kinetic window dragging?



-Dylan


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Drag Window from anywhere in Metacity?

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dylan McCall wrote on 22/08/08 20:12:
> 
> Woohoo! I (sort of) figured it out and created a branch implementing
> this change on Launchpad. So far it's more a proof of concept than
> anything else.
>...

Wow, that was quick. :-)

>...
> Works beautifully for preferences dialogs. Strangely, the expected
> behaviour does not occur with menu bars or toolbars, which seems a bit
> odd. Perhaps GTK is handling the events when it doesn't need to.
> Everywhere else it is wonderful -- and yes, that includes the status bar
> in F-Spot. (Eat that, Windows Photo Gallery!).

To avoid unpleasant false negatives, you may also need to tweak GTK to
treat all checkboxes and radio buttons as if their "fill" property was
set to false, regardless of what the app developer has set. Otherwise
when people drag what *looks* like empty space to the right of a
checkbox or radio button label, instead of moving the window it will
unexpectedly check/uncheck the control.

>...
> I should make this a gconf option. Maybe "touch screen mode", with
> another added bonus being kinetic window dragging?
>...

If it's just made standard behavior, then app developers can start using
Alt-clicking and Alt-dragging for advanced functions. I know the
Epiphany developers would appreciate this, and I expect the developers
of Inkscape, Dia, and other graphic programs would too.

Cheers
- --
Matthew Paul Thomas
http://mpt.net.nz/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIrxsu6PUxNfU6ecoRAqbJAKCrCNlCnFlugtK89AuPsMU/IEl/uwCeP4oW
5G+Dph9tm0zRDfQzmrbJI/w=
=RSMk
-END PGP SIGNATURE-

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Can Evolution calendar reminders pop-up automatically?

[Tim Zakharov]

On Sat, 2008-07-26 at 09:39 -0400, Paul Smith wrote:
> On Sat, 2008-07-26 at 05:57 -0700, Tim Zakharov wrote:
> > Have Ubuntu developers modified this behavior as someone on the
> > Evolution mailing list suggested?  Can someone help me get Evolution
> > to behave in the manner I am looking for?
>
> I think the behavior you're seeing is the default behavior for
> Evolution.
>
> If you want a direct popup, I think you need to install separate
> packages for that on Ubuntu.  Maybe those other distros install those
> packages by default.
>
> Try using Synaptic to add the "mail-notification" and
> "mail-notification-evolution" packages.  Note that these are part of the
> Universe repository so if you haven't enabled that, you'll need to do
> so.
>
> If you have problems let us know.
>   

Hi,
Here is some new information on this problem.  Read this Ubuntu Forums post:

http://ubuntuforums.org/showthread.php?t=874333

In particular, read this thread the OP from above refers to:

http://ubuntuforums.org/showthread.php?t=444342

Could this issue be due to a setting in gconf?  Is that a default Gnome 
setting, or do Ubuntu devs customize this?  Could this be why the 
problem is present in Ubuntu but not in OpenSUSE?  See this thread:

http://www.nabble.com/Can-calendar-reminders-be-made-persistent--td18317635.html

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Can Evolution calendar reminders pop-up automatically?

[HggdH]

On Fri, 2008-08-22 at 15:22 -0700, Tim Zakharov wrote:
> Hi,
> Here is some new information on this problem.  Read this Ubuntu Forums
> post:
> 
> http://ubuntuforums.org/showthread.php?t=874333
> 
> In particular, read this thread the OP from above refers to:
> 
> http://ubuntuforums.org/showthread.php?t=444342
> 
> Could this issue be due to a setting in gconf?  Is that a default
> Gnome 
> setting, or do Ubuntu devs customize this?  Could this be why the 
> problem is present in Ubuntu but not in OpenSUSE?  See this thread:
> 
> http://www.nabble.com/Can-calendar-reminders-be-made-persistent--td18317635.html
> 

Actually, no, it is not a Ubuntu-specific change. I looked up both
2.23.90 (Intrepid) and SVN, and both versions have the following in
evolution/calendar/gui/alarm-notify/config-data.c, @
config_data_get_calendars:

...
state = gconf_client_get_bool (conf_client,
  
"/apps/evolution/calendar/notify/notify_with_tray",
  NULL);
if (!state) /* Should be old client*/ {
GSList *source;
gconf_client_set_bool (conf_client,
  
"/apps/evolution/calendar/notify/notify_with_tray",
  TRUE,
  NULL);
...

So... BANG! gconf notify_with_tray is magically set...

I think this is worth a bugzilla, or a launchpad bug.

And... I am curious on what OpenSUSE offers...

.hggdh..

p.s. I have just unset notify_with_tray, and I will check what happens
when I restart Evo ;-)


signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss