Hi Florent,
It is not really up to the application developper. It is more up to how
the JobViewer while behave on new jobs (i.e. will it pop up the jobview
window, will it behave silently with a notification icon...). So even if
it is not state literally in the spec, you'll not really have
Hi Aaron and Rafael,
I'll not reply point by point, because i think that we don't really have
the same point of view on how things should works.
If i understand correctly, you idea is to get ride of all progress bar
of all applications and to have a common application for controlling
this
Hi Florent,
If i understand correctly, you idea is to get ride of all progress bar
of all applications and to have a common application for controlling
this progress. This sound cool, but i don't think that this is the right
approch, i'll do my best to explain why.
I probably misexplained
Rafael Fernández López a écrit :
Hi Florent,
If i understand correctly, you idea is to get ride of all progress bar
of all applications and to have a common application for controlling
this progress. This sound cool, but i don't think that this is the right
approch, i'll do my best to
Hi all,
I would like to start to work on a specification proposal for Freedesktop that
we have named JobViewServer/JobView.
The goal of this specification is being able of implementing this idea
http://dot.kde.org/1169588301.
This is really a good idea.
We and David Sedeño (from gwget) are
Le jeudi 10 avril 2008, Rafael Fernández López a écrit :
Hi,
I propse a 'middle case' solution. Bring a default
ones 'bytes', 'files', 'folders', 'contacts', 'mails', 'events', for
example, and tell in the docs what you've proposed. That if the
developer
wants another 'amount type',
On Thursday 24 April 2008, Florent Mertens wrote:
1. Client app don't show a progress window/bar, and provide it only
via the JobView server
2. Client app still show a progress window/bar, and provide it also
via the JobView server
isn't this an implementation detail for the application to
On Wednesday 09 April 2008, Ethan Osten wrote:
On Wed, 2008-04-09 at 19:40 +0200, Rafael Fernández López wrote:
However I really agree this is for sure not the best solution. What other
alternatives we have assuring that they are cross-desktop ?
Specify some file type, perhaps based on the
Le jeudi 10 avril 2008, Rafael Fernández López a écrit :
Hi,
I propse a 'middle case' solution. Bring a default
ones 'bytes', 'files', 'folders', 'contacts', 'mails', 'events', for
example, and tell in the docs what you've proposed. That if the developer
wants another 'amount type', it would
On Tuesday 08 April 2008, Rafael Fernández López wrote:
The main idea is that when an application needs a new amount type, we
review the specification (if the change is for that purpose we can update
it almost inmediatly if the new type has sense, and notify all interested
parties).
that
On Wed, 2008-04-09 at 19:40 +0200, Rafael Fernández López wrote:
However I really agree this is for sure not the best solution. What other
alternatives we have assuring that they are cross-desktop ?
Specify some file type, perhaps based on the same principle as desktop
files, with allowance
Hi,
Interface, signal, method, and property names are WindowsStyleCaps,
note that the first letter is capitalized, unlike Java.
So, it shouldn't it be eg. org.freedesktop.JobView.Terminate instead?
Yes, in theory, they should. I completely agree.
Also, regarding
Hi all,
At this point I plan to do a really verbose explanation of the D-Bus interface
that we designed with everybody in mind. Obviously this interface will
probably need improvements and corrections. After designing this interface,
we implemented it, so we have a real and working example to
On Tuesday 01 of April 2008, A. Walton wrote:
On Tue, Apr 1, 2008 at 2:50 PM, Rafael Fernández López
Maybe it's just me, but I've always found Mathusalem to be a bit
obtuse, as it'd require writing a lot of special-case code for
something that's little more than a very long running
On Wednesday 02 April 2008, Lubos Lunak wrote:
On Tuesday 01 of April 2008, A. Walton wrote:
What really needs to happen, IMO, is an expansion of this existing
standard and code to allow it to be flexible enough to be used with
Just having something listed from fd.o does not make it a
Le mercredi 2 avril 2008, Aaron J. Seigo a écrit :
On Tuesday 01 April 2008, A. Walton wrote:
[...]
and now on to the galago spec:
And it just so happens FD.O already has a specification for
notifications [1], a daemon and client implementation, and it's well
adopted code in the GNOME
Hi all,
I would like to start to work on a specification proposal for Freedesktop that
we have named JobViewServer/JobView.
The goal of this specification is being able of implementing this idea
http://dot.kde.org/1169588301.
Regarding this issue there are currently two main applications on
On Tue, Apr 1, 2008 at 2:50 PM, Rafael Fernández López
[EMAIL PROTECTED] wrote:
Hi all,
I would like to start to work on a specification proposal for Freedesktop
that
we have named JobViewServer/JobView.
The goal of this specification is being able of implementing this idea
Hi,
--- Rafael Fernández López [EMAIL PROTECTED] wrote:
Hi all,
I would like to start to work on a specification proposal for
Freedesktop that
we have named JobViewServer/JobView.
The goal of this specification is being able of implementing this
idea
http://dot.kde.org/1169588301.
Hi,
Don't forget KGet ;)
I think it would be great if kuiserver can take on all the features of
KGet, or alternatively if KGet can be modified so that it uses this
new DBus interface you are proposing. In the latter scenario, which
might be better given the large amount of work that has
Hi,
What really needs to happen, IMO, is an expansion of this existing
standard and code to allow it to be flexible enough to be used with
very long running applications. Not a lot needs to change to make this
happen either: to make the notification not expire until we want it
to, set the
21 matches
Mail list logo
