On Tue, 2005-02-22 at 23:09 +0100, Carlos Garnacho wrote:
> Hi,
>
> Sorry for the late reply
>
> --- Murray Cumming <[EMAIL PROTECTED]> escribiÃ:
> > GNOME System Tools 2.9 adds a "Shared Folders" control panel, using
> > Samba and NFS.
> >
> > Considering the lack of consensus about gnome-use
On Wed, 2005-02-23 at 10:17 +0800, Davyd Madeley wrote:
> On Tue, 2005-02-22 at 23:09 +0100, Carlos Garnacho wrote:
>
> > Yes, I could, but it leaves me some questions: will I have to pass through
> > the new modules process
> > for each new tool? won't the gst be considered an individual entity
Today at 3:17, Davyd Madeley wrote:
> FWIW, I am under the impression that Carlos should be given a clear head
> with what parts of his module he wants to add or remove. The same as I
> enjoy being able to make decisions on what applets we ship.
Seconded.
Cheers,
Danilo
_
On Tue, 2005-02-22 at 23:09 +0100, Carlos Garnacho wrote:
> Yes, I could, but it leaves me some questions: will I have to pass through
> the new modules process
> for each new tool? won't the gst be considered an individual entity for this?
>
> BTW, I'd really love to see it in, as it fills a go
Hi,
Sorry for the late reply
--- Murray Cumming <[EMAIL PROTECTED]> escribió:
> GNOME System Tools 2.9 adds a "Shared Folders" control panel, using
> Samba and NFS.
>
> Considering the lack of consensus about gnome-user-share or using a
> send-to idea, I don't think this should be installed by
> > i.e. the change has happened, you're going to have to deal with it. I
> > don't think this was neccessarily went against any policy, because we
> > don't have any policy on this other than "libwnck can change its API at
> > any time". I do think, though, that we should have a better policy th
Le mardi 22 fÃvrier 2005 Ã 10:19 -0700, Elijah Newren a Ãcrit :
>On Tue, 22 Feb 2005 17:05:39 +, Mark McLoughlin <[EMAIL PROTECTED]> wrote:
>> i.e. the change has happened, you're going to have to deal with it. I
>> don't think this was neccessarily went against any policy, because we
>
Minor correction...
On Tue, 22 Feb 2005 09:09:54 -0700, Elijah Newren <[EMAIL PROTECTED]> wrote:
> On Tue, 22 Feb 2005 13:12:30 +0100, Fernando Herrera
> <[EMAIL PROTECTED]> wrote:
> >
> > Elijah: would this timestamp be ok here?
>
> Actually, I don't know (I haven't looked close enough at the co
On Tue, 22 Feb 2005 18:43:21 +0100, Torsten Schoenfeld
<[EMAIL PROTECTED]> wrote:
> On Tue, 2005-02-22 at 10:09 -0700, Elijah Newren wrote:
>
> > I know the position you're in sucks, but I'm willing to help you out
> > with it. Note that Anders Carlsson changed API in libwnck for
> > wnck_window_
I think this is a reasonably restriction for APIs that are exported
(with installed headers), unless steps are taken to suppress export. It
doesn't make sense for truly "internal" APIs of course :-)
- Bill
Elijah Newren wrote:
On Tue, 22 Feb 2005 17:40:10 +, Mark McLoughlin <[EMAIL PROTECT
On Tue, 22 Feb 2005 17:40:10 +, Mark McLoughlin <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-02-22 at 10:19 -0700, Elijah Newren wrote:
>
> > > i.e. the change has happened, you're going to have to deal with
> > > it. I
> > > don't think this was neccessarily went against any policy, bec
On Tue, 2005-02-22 at 10:09 -0700, Elijah Newren wrote:
> I know the position you're in sucks, but I'm willing to help you out
> with it. Note that Anders Carlsson changed API in libwnck for
> wnck_window_close in an identical fashion *during* the 2.6 stable
> series. Given that kind of preceden
On Tue, 2005-02-22 at 10:19 -0700, Elijah Newren wrote:
> > i.e. the change has happened, you're going to have to deal with it.
> > I
> > don't think this was neccessarily went against any policy, because we
> > don't have any policy on this other than "libwnck can change its API at
> > a
On Tue, 22 Feb 2005 17:05:39 +, Mark McLoughlin <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-02-22 at 16:50 +, Bill Haneman wrote:
> > We still have the problem that we are 6 days from code freeze with a
> > change in API which we depend on. So the solution proposed below
> > (re-implementing
On Tue, 22 Feb 2005 16:50:49 +, Bill Haneman <[EMAIL PROTECTED]> wrote:
> We still have the problem that we are 6 days from code freeze with a
> change in API which we depend on. So the solution proposed below
> (re-implementing the libwnck calls) is not a runner for us.
Why? I can implement
On Tue, 2005-02-22 at 16:50 +, Bill Haneman wrote:
> We still have the problem that we are 6 days from code freeze with a
> change in API which we depend on. So the solution proposed below
> (re-implementing the libwnck calls) is not a runner for us.
Elijah's suggestion to implement
We still have the problem that we are 6 days from code freeze with a
change in API which we depend on. So the solution proposed below
(re-implementing the libwnck calls) is not a runner for us.
I still think that keeping the old API around and marking it deprecated
is a reasonable compromise g
On Tue, 22 Feb 2005 11:48:03 +0100, Kjartan Maraas <[EMAIL PROTECTED]> wrote:
> Hi.
>
> Tried building from CVS today and found that gok is broken after the API
> changes in libwnck. Looks like gok needs a 1.0.1 release to fix this...
It looks like bug 168093 has been created for this, so let's m
First, let me apologize for not being the one to notify you. I was
supposed to report this to the gok team when I made the libwnck change
(I did report the gnome-panel one, but was getting overloaded with
other tasks and missed reporting the gok one).
On Tue, 22 Feb 2005 14:54:50 +, Bill Hane
On Tue, 22 Feb 2005 09:05:16 -0500, David Bolter
<[EMAIL PROTECTED]> wrote:
> Hi I'm going to cross post to gnome-accessibility-devel as this is
> somewhat high priority I think. We really need a response on how to
> proceed to fix this one. Is this new API change going to stick? How
Yes, it wi
On Tue, 22 Feb 2005 13:12:30 +0100, Fernando Herrera
<[EMAIL PROTECTED]> wrote:
>
> Elijah: would this timestamp be ok here?
Actually, I don't know (I haven't looked close enough at the code).
In general, "current" time is dead wrong. See bug 166379, and how
gtk_get_current_event_time() caused
David Bolter wrote:
Hi I'm going to cross post to gnome-accessibility-devel as this is
somewhat high priority I think. We really need a response on how to
proceed to fix this one. Is this new API change going to stick? How
will GOK maintain compatability with new/old versions of libwnck?
(p
Fernando Herrera wrote:
Well, libwnck API is not stable at all and is subject to change again
during 2.11 development process. So the only thing we can do is to
require a concret version for compiling GOK:
This won't do, as GOK-1.0.0 is designed to work with the gnome 2.6 and
2.8 series as well
Well, libwnck API is not stable at all and is subject to change again
during 2.11 development process. So the only thing we can do is to
require a concret version for compiling GOK:
diff -u -r1.129 configure.in
--- configure.in21 Feb 2005 16:14:31 - 1.129
+++ configure.in
Hi I'm going to cross post to gnome-accessibility-devel as this is
somewhat high priority I think. We really need a response on how to
proceed to fix this one. Is this new API change going to stick? How
will GOK maintain compatability with new/old versions of libwnck?
(preprocessor directiv
Elijah: would this timestamp be ok here?
PS: I know that #error "libwnck should only be used if you understand
that it's subject to frequent change, and is not supported as a fixed
API/ABI or as part of the platform" but these internal API changes 6
days before hard code freeze are painful! :)
Hi.
Tried building from CVS today and found that gok is broken after the API
changes in libwnck. Looks like gok needs a 1.0.1 release to fix this...
Cheers
Kjartan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/m
27 matches
Mail list logo
