Re: Gnome Feature Request

[Andre Klapper]

Hi Thorsten,

On Wed, 2013-02-13 at 22:56 +0100, Thorsten Alge wrote:
> hope this is the correct list for a feature request.

Specific and well-defined feature requests (that don't need a lot of
brainstorming first how to do it) are best placed in bugzilla.gnome.org.

>  * while copying files from one place to another it should be possible
> to pause the process (just like the pause button in the Firefox download
> dialogue)

Filed as https://bugzilla.gnome.org/show_bug.cgi?id=124783

>  * It should be possible to group copy processes or to put them in a row:

Same as above in the end.

andre
-- 
Andre Klapper  |  ak...@gmx.net
http://blogs.gnome.org/aklapper/

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Gnome Feature Request

[Thorsten Alge]

Hi,

hope this is the correct list for a feature request.

For years now I miss a certain feature on desktop systems (not only on
the GNOME Desktop).

 * while copying files from one place to another it should be possible
to pause the process (just like the pause button in the Firefox download
dialogue)
 * It should be possible to group copy processes or to put them in a row:
-> sometimes its a bit inconvenient to mark all files and folders at
once(especially when spread over different subfolders) so you start
different copy processes. But it would be more efficient to copy one
file after another so it makes sense to have a function to merge to one
copy process.
-> when starting different copy processes from one device to another
its often slowing down the copy process (especially when the source is a
cdrom) so it would be an advantage to copy them one after another.

kr

th.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Gnome Feature Request

[jose.ali...@gmail.com]

Hi,

Please see comments inline.

2011/5/8 Erick Pérez :
> On 08/05/2011, Jasper St. Pierre  wrote:
>> 2011/5/8 Erick Pérez 
>>
>>> > Why not at the time of the menu?
>>> Cause it will be to slow, way to slow. Making choices based on the
>>> data you think we should send to the service will be slow, any
>>> decision at all will take to long for a responsive UX to act.
>>>
>>
>> What makes you think that? Profile it and then make decisions. Don't degrade
>> the experience a user has because it could possibly be "too slow".
> Fair, enough, anyway what's make think like my programming experience.
>
>>
>>> > I'd rather see "No definitions" inline in the menu than having a new
>>> popup window tell me the new thing.
>>> No one is talking about new popup windows. That's a pretty rushed
>>> thought for something is still an idea, and, it's up to the app
>>> developer how they will handle the data and the interaction with the
>>> service, so It's kinda naive to assume you will have popup windows
>>> informing you of the results of anything.
>>>
>>
>> If the app developer already has to implement a UI for a dictionary result,
>> then why don't they just call gnome-dictionary directly?
>
> No one says that. You just assumed it that way.
>
>>  > You said that you didn't want a daemon started, so we can't use D-Bus in
>>> that case, unless we use D-Bus autostart, but I don't see the value in
>>> that
>>> either.
>>> You miss-understood me, when I said I didn't want a daemon, I was
>>> talking about a daemon of each application registered. In the first
>>> email I said that D-Bus should provide the infrastructure for the
>>> service/module
>>>
>>
>> A D-Bus daemon needs to be running for you to be able to call it. D-Bus can
>> start the daemon for you if it isn't started or it crashes, but the daemon
>> needs to keep running.
>
> You keep miss-understanding, when I talk about daemon, I meant, I
> didn't want a dictionary daemon, and a daemon for every app publishing
> actions/services, course it has to be a daemon for the apps to query
> it, and to answer back
>
>> Now the hard part:
>>> > The only tangible idea I can extract out of this is querying a service
>>> with something akin to a mimetype, and getting a list of programs that can
>>> handle it. I query the service with SEMANTIC_WORD, and I get
>>> "/usr/bin/gnome-dictionary-lookup-word %s" back.
>>> That's more or less the whole point of it. With SEMANTIC_WORD would
>>> return gnome-dictionary, and some others too, and even more than not
>>> regular gnome-dictionary, but gnome-dictionary called in a way that
>>> the app show just a small overlay with the definition, and nothing
>>> else
>>>
>>
>> If they have to implement a UI for every result that could be possibly
>> returned, they can only implement a certain number of actions... so the
>> middleman aggregator that you're suggesting is useless. Every time you add a
>> UI, you add support for the tool.
> I don't see how this is an answer to what I said before
>
>>
>>> > ... and I still can't see how you would build jumplists out of this
>>> Ohh, that so easy, the jump list are composed of two main things,
>>> recent files opened with that app, and sub-actions other than the main
>>> purpose of the app. Well the for recent files part there's already
>>> zeitgeist for that, but for a list of sub-actions of every app that
>>> allow it, then you can query the service I'm proposing. Because you
>>> should already know by now that querying the service about a specific
>>> action is not the only way of interacting with it.
>>>
>>
>> We already have a way to find the programs that have the ability to open a
>> file. It's been around for a long time now, too, and even works with KDE:
>>
>>   http://portland.freedesktop.org/xdg-utils-1.0/xdg-mime.html
>>
>> This is what nautilus talks to with its "Open With" dialog, for instance.
> Yeah, already know that, but xdg-open still handles just files based
> on a mime-type. I'm thinking more generally.
>
>>> There might be an inch of value in that idea, but I don't see it.
>>> > I don't see the value in this service
>>> Hopefully, you're not the main man behind Gnome.
>>
>> I'm not. I don't even know who the main man is, or even if there is one.
>>
>>> Gnome Desktop
>>> actually needs integration/communication between applications, to
>>> start looking as whole, like is already doing with the system settings
>>> trying to provide a niche for a bunch of somewhat different settings,
>>> and the way to provide that is centralizing communications and
>>> interactions, acting as a middle man between desktop apps.
>>>
>>
>> Of course gnome desktop would be better if it had integration. It would be
>> excellent if everything "just worked", but like any other timely, shipped
>> system, there are warts. GNOME 3.0 certainly isn't as "integrated" as we
>> would have liked it to be, but we have a schedule, we have time constraints,
>> and we have manpower constraints. If we had infinite t

Re: Gnome Feature Request

[Milan Bouchet-Valat]

Le lundi 09 mai 2011 à 00:58 -0400, Erick Pérez a écrit :
> Finally, I do think this childish behavior is not getting anything
> useful for no-one of us. If the spirit of the Gnome Team, is: 'Bring
> some code/mockups, then we will judge' Ok.
Mockups would help understanding your idea, but code isn't necessary at
this point. I think you'd best write a few use cases that are enough to
prove that your project would be beneficial to the user experience, and
that the implementation you suggest is really needed to achieve them.

Have a look at the "Online Accounts panel for 3.2" thread to get an
insight on what kind of rationale people are expecting.

> I'll do it myself. And then maybe, you find it interesting, or not.
That's also a possibility, of course, but you might waste time if it's
not going to be accepted in the end... Mockups and use-cases are
cheaper. ;-)


Regards


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Gnome Feature Request

[Erick Pérez]

On 08/05/2011, Jasper St. Pierre  wrote:
> 2011/5/8 Erick Pérez 
>
>> > Why not at the time of the menu?
>> Cause it will be to slow, way to slow. Making choices based on the
>> data you think we should send to the service will be slow, any
>> decision at all will take to long for a responsive UX to act.
>>
>
> What makes you think that? Profile it and then make decisions. Don't degrade
> the experience a user has because it could possibly be "too slow".
Fair, enough, anyway what's make think like my programming experience.

>
>> > I'd rather see "No definitions" inline in the menu than having a new
>> popup window tell me the new thing.
>> No one is talking about new popup windows. That's a pretty rushed
>> thought for something is still an idea, and, it's up to the app
>> developer how they will handle the data and the interaction with the
>> service, so It's kinda naive to assume you will have popup windows
>> informing you of the results of anything.
>>
>
> If the app developer already has to implement a UI for a dictionary result,
> then why don't they just call gnome-dictionary directly?

No one says that. You just assumed it that way.

>  > You said that you didn't want a daemon started, so we can't use D-Bus in
>> that case, unless we use D-Bus autostart, but I don't see the value in
>> that
>> either.
>> You miss-understood me, when I said I didn't want a daemon, I was
>> talking about a daemon of each application registered. In the first
>> email I said that D-Bus should provide the infrastructure for the
>> service/module
>>
>
> A D-Bus daemon needs to be running for you to be able to call it. D-Bus can
> start the daemon for you if it isn't started or it crashes, but the daemon
> needs to keep running.

You keep miss-understanding, when I talk about daemon, I meant, I
didn't want a dictionary daemon, and a daemon for every app publishing
actions/services, course it has to be a daemon for the apps to query
it, and to answer back

> Now the hard part:
>> > The only tangible idea I can extract out of this is querying a service
>> with something akin to a mimetype, and getting a list of programs that can
>> handle it. I query the service with SEMANTIC_WORD, and I get
>> "/usr/bin/gnome-dictionary-lookup-word %s" back.
>> That's more or less the whole point of it. With SEMANTIC_WORD would
>> return gnome-dictionary, and some others too, and even more than not
>> regular gnome-dictionary, but gnome-dictionary called in a way that
>> the app show just a small overlay with the definition, and nothing
>> else
>>
>
> If they have to implement a UI for every result that could be possibly
> returned, they can only implement a certain number of actions... so the
> middleman aggregator that you're suggesting is useless. Every time you add a
> UI, you add support for the tool.
I don't see how this is an answer to what I said before

>
>> > ... and I still can't see how you would build jumplists out of this
>> Ohh, that so easy, the jump list are composed of two main things,
>> recent files opened with that app, and sub-actions other than the main
>> purpose of the app. Well the for recent files part there's already
>> zeitgeist for that, but for a list of sub-actions of every app that
>> allow it, then you can query the service I'm proposing. Because you
>> should already know by now that querying the service about a specific
>> action is not the only way of interacting with it.
>>
>
> We already have a way to find the programs that have the ability to open a
> file. It's been around for a long time now, too, and even works with KDE:
>
>   http://portland.freedesktop.org/xdg-utils-1.0/xdg-mime.html
>
> This is what nautilus talks to with its "Open With" dialog, for instance.
Yeah, already know that, but xdg-open still handles just files based
on a mime-type. I'm thinking more generally.

>> There might be an inch of value in that idea, but I don't see it.
>> > I don't see the value in this service
>> Hopefully, you're not the main man behind Gnome.
>
> I'm not. I don't even know who the main man is, or even if there is one.
>
>> Gnome Desktop
>> actually needs integration/communication between applications, to
>> start looking as whole, like is already doing with the system settings
>> trying to provide a niche for a bunch of somewhat different settings,
>> and the way to provide that is centralizing communications and
>> interactions, acting as a middle man between desktop apps.
>>
>
> Of course gnome desktop would be better if it had integration. It would be
> excellent if everything "just worked", but like any other timely, shipped
> system, there are warts. GNOME 3.0 certainly isn't as "integrated" as we
> would have liked it to be, but we have a schedule, we have time constraints,
> and we have manpower constraints. If we had infinite time to design and work
> on GNOME, we'd all be staring at the perfect desktop environment: It would
> literally be the most usable, most customizable, least crashy desktop

Re: Gnome Feature Request

[Jason D. Clinton]

2011/5/8 Erick Pérez 

> >But if you want to go ahead and build whatever your idea appears to be,
> nobody's going to stop you.
> And this is just rude and useless.
>

This is how free software works. If you want something, you just do it. And
then show everyone how awesome it is. Or you find other people who already
agree with you and you all go off and "just do it" together. And then show
everyone how awesome it is.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Gnome Feature Request

[Erick Pérez]

> Why not at the time of the menu?
Cause it will be to slow, way to slow. Making choices based on the
data you think we should send to the service will be slow, any
decision at all will take to long for a responsive UX to act.

> I'd rather see "No definitions" inline in the menu than having a new popup 
> window tell me the new thing.
No one is talking about new popup windows. That's a pretty rushed
thought for something is still an idea, and, it's up to the app
developer how they will handle the data and the interaction with the
service, so It's kinda naive to assume you will have popup windows
informing you of the results of anything.

> You said that you didn't want a daemon started, so we can't use D-Bus in that 
> case, unless we use D-Bus autostart, but I don't see the value in that either.
You miss-understood me, when I said I didn't want a daemon, I was
talking about a daemon of each application registered. In the first
email I said that D-Bus should provide the infrastructure for the
service/module.

Now the hard part:
> The only tangible idea I can extract out of this is querying a service with 
> something akin to a mimetype, and getting a list of programs that can handle 
> it. I query the service with SEMANTIC_WORD, and I get 
> "/usr/bin/gnome-dictionary-lookup-word %s" back.
That's more or less the whole point of it. With SEMANTIC_WORD would
return gnome-dictionary, and some others too, and even more than not
regular gnome-dictionary, but gnome-dictionary called in a way that
the app show just a small overlay with the definition, and nothing
else.

> ... and I still can't see how you would build jumplists out of this
Ohh, that so easy, the jump list are composed of two main things,
recent files opened with that app, and sub-actions other than the main
purpose of the app. Well the for recent files part there's already
zeitgeist for that, but for a list of sub-actions of every app that
allow it, then you can query the service I'm proposing. Because you
should already know by now that querying the service about a specific
action is not the only way of interacting with it.

> There might be an inch of value in that idea, but I don't see it.
> I don't see the value in this service
Hopefully, you're not the main man behind Gnome. Gnome Desktop
actually needs integration/communication between applications, to
start looking as whole, like is already doing with the system settings
trying to provide a niche for a bunch of somewhat different settings,
and the way to provide that is centralizing communications and
interactions, acting as a middle man between desktop apps.

>But if you want to go ahead and build whatever your idea appears to be, 
>nobody's going to stop you.
And this is just rude and useless.

Erick

-- 
El derecho de expresar nuestros pensamientos tiene algún significado
tan sólo si somos capaces de tener pensamientos propios.
El miedo a la libertad, Erich Fromm
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Gnome Feature Request

[Jasper St. Pierre]

2011/5/8 Erick Pérez 

> >Why at startup?
> Nothing more that it sounded to me that you were suggesting that
> Evince will look for service at the time of rendering the menu,
> occupational hazards. I hit send to soon, I should now you're too
> smart to suggest that.
>

Why not at the time of the menu? We'd probably need to send the actual data
to the service in advance so that an app can make a more reasonable
decision... I'd rather see "No definitions" inline in the menu than having a
new popup window tell me the new thing.


> >Sure, OK, so evince looks for "applications that can handle words", and
> the service replies "well, the Dictionary can look up a word, that's an
> option". "Your web browser can search for the word"...
> > So this is a very specific concept based around some data, and a known
> piece of information about the data, and getting context-sensitive results
> about a piece of data.
> >Suggesting something that can gather all these interfaces given the query
> "what are some things I can do with a word" could be useful, but we'd need
> to design the data types so that the service can actually be useful for
> everyone.
>
> As I said in my first mail there a bunch of design/definitions
> missing, like a well designed set of verbs or actions the apps can
> export. Course
>

Aren't the verbs the arbitrary things the service returns? I thought we were
passing the service the data, and we get back a list of verbs.

 >If we want collaboration between apps, we need a very specific list of
> actions that an app can register for, and that an app can search for
> Anyway It seems like you got the main idea. that's good, now we can
> pass to the useful part of the discussion


... that was supposed to be a strawman I was trying to knock down in the
next sentence. The only tangible idea I can extract out of this is querying
a service with something akin to a mimetype, and getting a list of programs
that can handle it. I query the service with SEMANTIC_WORD, and I get
"/usr/bin/gnome-dictionary-lookup-word %s" back. There might be an inch of
value in that idea, but I don't see it. You said that you didn't want a
daemon started, so we can't use D-Bus in that case, unless we use D-Bus
autostart, but I don't see the value in that either.

If you want to define a new service so that you can call
GetProperApplication(LOOKUP_WORD_DEFINITION), I'm sorry, but that's even
more useless.

Just define a new D-Bus interface spec with the proper methods, and D-Bus
will use whatever the user has configured as the higher prority when you try
to call it.

Now, what we should decide is it a piece of software like this could
> fit into Gnome, so we can start designing/coding.
> I'm not use to Gnome Development dynamics so
>

I don't see the value in this service... and I still can't see how you would
build jumplists out of this. But if you want to go ahead and build whatever
your idea appears to be, nobody's going to stop you.


> Erick
>
> On 08/05/2011, Jasper St. Pierre  wrote:
> > 2011/5/8 Erick Pérez 
> >
> >> First, the word 'service' here give the wrong impressions that the
> >> Dictionary have to be running, and that's not what I meant, not even a
> >> dictionary module.
> >
> >
> > What registers the association if not running code?
> >
> >
> >>  On 08/05/2011, Jasper St. Pierre  wrote:
> >> > OK, let's take your first example: Evince + Dictionary
> >> >
> >> > Let's imagine your system exists, along with the Dictionary service
> >> that's
> >> > registered with it.
> >> >
> >> > Would this act upon specific things? So... the Dictionary registers
> that
> >> for
> >> > a "WORD", it has the ability to "Look up on GNOME Dictionary"
> >> For 'Word' or 'Text', Dictionary can 'Show Definition'
> >>
> >
> > Sure, OK, so evince looks for "applications that can handle words", and
> the
> > service replies "well, the Dictionary can look up a word, that's an
> option".
> > "Your web browser can search for the word"...
> >
> > So this is a very specific concept based around some data, and a known
> piece
> > of information about the data, and getting context-sensitive results
> about a
> > piece of data.
> >
> >
> >>  > And then, when right-clicking, along with the usual results, evince
> >> would
> >> > try and send out to the service "What are all the things that you can
> do
> >> > with a WORD?"
> >>
> >> Not when right clicking. Evince will check at start-up for things it
> >> will be interested on, for instance, which app can 'handle text' or
> >> 'lookup word definitions', or 'handle image', or anything else,
> >> Then on right click there will be and item which will cal dictionary
> >> the way it should be to show the window with the definition. and
> >>
> >
> > Why at startup?
> >
> > "handle text" and "handle image" are completely different than "lookup
> word
> > defintitions"
> >
> > If we want collaboration between apps, we need a very specific list of
> > actions that an app can register for, and that an

Re: Gnome Feature Request

[Erick Pérez]

>Why at startup?
Nothing more that it sounded to me that you were suggesting that
Evince will look for service at the time of rendering the menu,
occupational hazards. I hit send to soon, I should now you're too
smart to suggest that.

>Sure, OK, so evince looks for "applications that can handle words", and the 
>service replies "well, the Dictionary can look up a word, that's an option". 
>"Your web browser can search for the word"...
> So this is a very specific concept based around some data, and a known piece 
> of information about the data, and getting context-sensitive results about a 
> piece of data.
>Suggesting something that can gather all these interfaces given the query 
>"what are some things I can do with a word" could be useful, but we'd need to 
>design the data types so that the service can actually be useful for everyone.

As I said in my first mail there a bunch of design/definitions
missing, like a well designed set of verbs or actions the apps can
export. Course

>If we want collaboration between apps, we need a very specific list of actions 
>that an app can register for, and that an app can search for
Anyway It seems like you got the main idea. that's good, now we can
pass to the useful part of the discussion.

Now, what we should decide is it a piece of software like this could
fit into Gnome, so we can start designing/coding.
I'm not use to Gnome Development dynamics so

Erick

On 08/05/2011, Jasper St. Pierre  wrote:
> 2011/5/8 Erick Pérez 
>
>> First, the word 'service' here give the wrong impressions that the
>> Dictionary have to be running, and that's not what I meant, not even a
>> dictionary module.
>
>
> What registers the association if not running code?
>
>
>>  On 08/05/2011, Jasper St. Pierre  wrote:
>> > OK, let's take your first example: Evince + Dictionary
>> >
>> > Let's imagine your system exists, along with the Dictionary service
>> that's
>> > registered with it.
>> >
>> > Would this act upon specific things? So... the Dictionary registers that
>> for
>> > a "WORD", it has the ability to "Look up on GNOME Dictionary"
>> For 'Word' or 'Text', Dictionary can 'Show Definition'
>>
>
> Sure, OK, so evince looks for "applications that can handle words", and the
> service replies "well, the Dictionary can look up a word, that's an option".
> "Your web browser can search for the word"...
>
> So this is a very specific concept based around some data, and a known piece
> of information about the data, and getting context-sensitive results about a
> piece of data.
>
>
>>  > And then, when right-clicking, along with the usual results, evince
>> would
>> > try and send out to the service "What are all the things that you can do
>> > with a WORD?"
>>
>> Not when right clicking. Evince will check at start-up for things it
>> will be interested on, for instance, which app can 'handle text' or
>> 'lookup word definitions', or 'handle image', or anything else,
>> Then on right click there will be and item which will cal dictionary
>> the way it should be to show the window with the definition. and
>>
>
> Why at startup?
>
> "handle text" and "handle image" are completely different than "lookup word
> defintitions"
>
> If we want collaboration between apps, we need a very specific list of
> actions that an app can register for, and that an app can search for. Having
> "lookup word definitions" is completely useless for that, because I doubt
> anything besides the dictionary service will implement it.
>
> D-Bus already has the concept of interfaces, so if you wanted to search for
> an application that implemented "lookup word definitions", you'd make a new
> "org.gnome.Dictionary" interface wtih "LookupWord" or so, define a
> signature, and then have applications implement and use that.. D-Bus will
> automatically reroute to whatever it thinks is the correct application --
> anything implementing the D-Bus interface is fair game, so it's not quite
> the same "gnome-dictionary".
>
> Suggesting something that can gather all these interfaces given the query
> "what are some things I can do with a word" could be useful, but we'd need
> to design the data types so that the service can actually be useful for
> everyone.
>
> Erick
>>
>>
>> --
>> El derecho de expresar nuestros pensamientos tiene algún significado
>> tan sólo si somos capaces de tener pensamientos propios.
>> El miedo a la libertad, Erich Fromm
>>
>


-- 
El derecho de expresar nuestros pensamientos tiene algún significado
tan sólo si somos capaces de tener pensamientos propios.
El miedo a la libertad, Erich Fromm
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Gnome Feature Request

[Jasper St. Pierre]

2011/5/8 Erick Pérez 

> First, the word 'service' here give the wrong impressions that the
> Dictionary have to be running, and that's not what I meant, not even a
> dictionary module.


What registers the association if not running code?


>  On 08/05/2011, Jasper St. Pierre  wrote:
> > OK, let's take your first example: Evince + Dictionary
> >
> > Let's imagine your system exists, along with the Dictionary service
> that's
> > registered with it.
> >
> > Would this act upon specific things? So... the Dictionary registers that
> for
> > a "WORD", it has the ability to "Look up on GNOME Dictionary"
> For 'Word' or 'Text', Dictionary can 'Show Definition'
>

Sure, OK, so evince looks for "applications that can handle words", and the
service replies "well, the Dictionary can look up a word, that's an option".
"Your web browser can search for the word"...

So this is a very specific concept based around some data, and a known piece
of information about the data, and getting context-sensitive results about a
piece of data.


>  > And then, when right-clicking, along with the usual results, evince
> would
> > try and send out to the service "What are all the things that you can do
> > with a WORD?"
>
> Not when right clicking. Evince will check at start-up for things it
> will be interested on, for instance, which app can 'handle text' or
> 'lookup word definitions', or 'handle image', or anything else,
> Then on right click there will be and item which will cal dictionary
> the way it should be to show the window with the definition. and
>

Why at startup?

"handle text" and "handle image" are completely different than "lookup word
defintitions"

If we want collaboration between apps, we need a very specific list of
actions that an app can register for, and that an app can search for. Having
"lookup word definitions" is completely useless for that, because I doubt
anything besides the dictionary service will implement it.

D-Bus already has the concept of interfaces, so if you wanted to search for
an application that implemented "lookup word definitions", you'd make a new
"org.gnome.Dictionary" interface wtih "LookupWord" or so, define a
signature, and then have applications implement and use that.. D-Bus will
automatically reroute to whatever it thinks is the correct application --
anything implementing the D-Bus interface is fair game, so it's not quite
the same "gnome-dictionary".

Suggesting something that can gather all these interfaces given the query
"what are some things I can do with a word" could be useful, but we'd need
to design the data types so that the service can actually be useful for
everyone.

Erick
>
>
> --
> El derecho de expresar nuestros pensamientos tiene algún significado
> tan sólo si somos capaces de tener pensamientos propios.
> El miedo a la libertad, Erich Fromm
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Gnome Feature Request

[Erick Pérez]

First, the word 'service' here give the wrong impressions that the
Dictionary have to be running, and that's not what I meant, not even a
dictionary module.

On 08/05/2011, Jasper St. Pierre  wrote:
> OK, let's take your first example: Evince + Dictionary
>
> Let's imagine your system exists, along with the Dictionary service that's
> registered with it.
>
> Would this act upon specific things? So... the Dictionary registers that for
> a "WORD", it has the ability to "Look up on GNOME Dictionary"
For 'Word' or 'Text', Dictionary can 'Show Definition'

> And then, when right-clicking, along with the usual results, evince would
> try and send out to the service "What are all the things that you can do
> with a WORD?"

Not when right clicking. Evince will check at start-up for things it
will be interested on, for instance, which app can 'handle text' or
'lookup word definitions', or 'handle image', or anything else,
Then on right click there will be and item which will cal dictionary
the way it should be to show the window with the definition. and


Erick


-- 
El derecho de expresar nuestros pensamientos tiene algún significado
tan sólo si somos capaces de tener pensamientos propios.
El miedo a la libertad, Erich Fromm
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Gnome Feature Request

[Erick Pérez]

Yeap, course, if we/you agree it wold be useful, and good, and shien,
and useful.



2011/5/8 Andre Klapper :
> On Sun, 2011-05-08 at 12:27 -0400, Erick Pérez wrote:
>> I hope the term for proposing stuff to Gnome 3.2 isn't over yet, It
>> took me a while to made my mind about this.
>> So here it goes:
>>
>> What I think Gnome needs now:
>
> Do you plan to work on the design and/or code needed for your proposals?
>
> I'm asking as the feature proposal period is not intended to create a
> random wishlist and as features should ideally have an assignee who will
> work on them when proposing them.
>
> andre
> --
> mailto:ak...@gmx.net | failed
> http://blogs.gnome.org/aklapper | http://www.openismus.com
>
>



-- 
El derecho de expresar nuestros pensamientos tiene algún significado
tan sólo si somos capaces de tener pensamientos propios.
El miedo a la libertad, Erich Fromm
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Gnome Feature Request

[Erick Pérez]

No, I'm not,  DBUS will provide the gears to made it happens. any
application can use DBUS and any client can consume services from
other, the problem with Linux desktop in general and in Gnome in
particular is the lack of consistency and integration.
Have u used Mac OSX some time ? There every application knows it is
not along, knows where it is running and who to call to make whatever
it wants to make. That's how a desktop charms people, and that's how
it becomes useful and productive, by not being a bunch of app running
using the same toolkit and no knowledge of each other. But anyway that
last rant it is not the point.

The point is provide the same kind of integration the other platforms
provide. And I showed useful samples, at least, I thin is better
implement jump list like these and not like ubuntu does.

2011/5/8 Jasper St. Pierre :
> So... you're suggesting D-Bus?
>
> 2011/5/8 Erick Pérez 
>



-- 
El derecho de expresar nuestros pensamientos tiene algún significado
tan sólo si somos capaces de tener pensamientos propios.
El miedo a la libertad, Erich Fromm
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Gnome Feature Request

[Nick Glynn]

I think leveraging dbus would be the way to do it but presented in a way
similar to Android's intents/receiver system.
On May 8, 2011 5:30 PM, "Jasper St. Pierre"  wrote:
> So... you're suggesting D-Bus?
>
> 2011/5/8 Erick Pérez 
>
>> Hi:
>>
>> I hope the term for proposing stuff to Gnome 3.2 isn't over yet, It
>> took me a while to made my mind about this.
>> So here it goes:
>>
>> What I think Gnome needs now:
>> A centralized, gnome controlled place for applications to
>> share/offers actions: I think this might me more easy to understand by
>> using examples.
>>
>> Example 1:
>> I'm reading a pdf file in Evince, and I want to look for a
>> word
>> definition on Dictionary. Evince could look at this central place of
>> apps services, and send Dictionary a signal to look for the word
>> selected and show a window with the results.
>> Example 2:
>> I want jump list in Gnome, Gnome-Shell would look at this
>> place and
>> for every application in my favorite list would retrieve the suitable
>> actions for place in the jump list
>> Example 3: QuickLook apple-like, I'm looking for a file in nautilus,
>> and nautilus would look at this place for an app that can show me a
>> preview of this file-type and fire it.
>>
>> I think I made my point.
>> There still some definitions left.
>> 0. More than anything, It would be necessary to define some verbs for
>> applications to use it to understand each others
>> 1. App could offers services based on file, clipboard content, etc.
>> 2. App could offers services based file type
>> 3. We should define a way for apps to get the results of and operation
>> back, no matters is a true or false, or a file packed, or something
>> else
>> 3. Gnome will need some way to manage the apps actions offered, and
>> some way to prevent ones and allows others
>>
>> Finally, what I'm thinking of is something very alike to Contractor
>> elementary module
>> <
>>
http://www.omgubuntu.co.uk/2011/03/contractor-brings-seamless-file-sharing-between-apps-to-the-linux-desktop/
>> >
>> but I want something more general, not just file, but others stuff
>> too, not even sharing, but doing something for me, sending tweets,
>> cropping pictures, converting ebooks, etc. Giving the ability of
>> application to communicate each other is one step to make the Gnome
>> Desktop a more consistent and integrated ecosystem.
>> There's one thing to note, the underlying structure, the code bits,
>> are a lot ahead since dbus exist already and I can't think of a better
>> way to handle communication
>>
>> Now: Which is the course from here.
>> I'm ready to collaborate programming or doing something else
>>
>> Erick
>>
>> --
>> El derecho de expresar nuestros pensamientos tiene algún significado
>> tan sólo si somos capaces de tener pensamientos propios.
>> El miedo a la libertad, Erich Fromm
>> ___
>> 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: Gnome Feature Request

[Andre Klapper]

On Sun, 2011-05-08 at 12:27 -0400, Erick Pérez wrote:
> I hope the term for proposing stuff to Gnome 3.2 isn't over yet, It
> took me a while to made my mind about this.
> So here it goes:
> 
> What I think Gnome needs now:

Do you plan to work on the design and/or code needed for your proposals?

I'm asking as the feature proposal period is not intended to create a
random wishlist and as features should ideally have an assignee who will
work on them when proposing them.

andre
-- 
mailto:ak...@gmx.net | failed
http://blogs.gnome.org/aklapper | http://www.openismus.com

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Gnome Feature Request

[Jasper St. Pierre]

So... you're suggesting D-Bus?

2011/5/8 Erick Pérez 

> Hi:
>
> I hope the term for proposing stuff to Gnome 3.2 isn't over yet, It
> took me a while to made my mind about this.
> So here it goes:
>
> What I think Gnome needs now:
>A centralized, gnome controlled place for applications to
> share/offers actions: I think this might me more easy to understand by
> using examples.
>
>Example 1:
>I'm reading a pdf file in Evince, and I want to look for a
> word
> definition on Dictionary. Evince could look at this central place of
> apps services, and send Dictionary a signal to look for the word
> selected and show a window with the results.
>Example 2:
>I want jump list in Gnome, Gnome-Shell would look at this
> place and
> for every application in my favorite list would retrieve the suitable
> actions for place in the jump list
>Example 3: QuickLook apple-like, I'm looking for a file in nautilus,
> and nautilus would look at this place for an app that can show me a
> preview of this file-type and fire it.
>
> I think I made my point.
> There still some definitions left.
> 0. More than anything, It would be necessary to define some verbs for
> applications to use it to understand each others
> 1. App could offers services based on file, clipboard content, etc.
> 2. App could offers services based file type
> 3. We should define a way for apps to get the results of and operation
> back, no matters is a true or false, or a file packed, or something
> else
> 3. Gnome will need some way to manage the apps actions offered, and
> some way to prevent ones and allows others
>
> Finally, what I'm thinking of is something very alike to Contractor
> elementary module
> <
> http://www.omgubuntu.co.uk/2011/03/contractor-brings-seamless-file-sharing-between-apps-to-the-linux-desktop/
> >
> but I want something more general, not just file, but others stuff
> too, not even sharing, but doing something for me, sending tweets,
> cropping pictures, converting ebooks, etc. Giving the ability of
> application to communicate each other is one step to make the Gnome
> Desktop a more consistent and integrated ecosystem.
> There's one thing to note, the underlying structure, the code bits,
> are a lot ahead since dbus exist already and I can't think of a better
> way to handle communication
>
> Now: Which is the course from here.
> I'm ready to collaborate programming or doing something else
>
> Erick
>
> --
> El derecho de expresar nuestros pensamientos tiene algún significado
> tan sólo si somos capaces de tener pensamientos propios.
> El miedo a la libertad, Erich Fromm
> ___
> 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

Gnome Feature Request

[Erick Pérez]

Hi:

I hope the term for proposing stuff to Gnome 3.2 isn't over yet, It
took me a while to made my mind about this.
So here it goes:

What I think Gnome needs now:
A centralized, gnome controlled place for applications to
share/offers actions: I think this might me more easy to understand by
using examples.

Example 1:
I'm reading a pdf file in Evince, and I want to look for a word
definition on Dictionary. Evince could look at this central place of
apps services, and send Dictionary a signal to look for the word
selected and show a window with the results.
Example 2:
I want jump list in Gnome, Gnome-Shell would look at this place 
and
for every application in my favorite list would retrieve the suitable
actions for place in the jump list
Example 3: QuickLook apple-like, I'm looking for a file in nautilus,
and nautilus would look at this place for an app that can show me a
preview of this file-type and fire it.

I think I made my point.
There still some definitions left.
0. More than anything, It would be necessary to define some verbs for
applications to use it to understand each others
1. App could offers services based on file, clipboard content, etc.
2. App could offers services based file type
3. We should define a way for apps to get the results of and operation
back, no matters is a true or false, or a file packed, or something
else
3. Gnome will need some way to manage the apps actions offered, and
some way to prevent ones and allows others

Finally, what I'm thinking of is something very alike to Contractor
elementary module

but I want something more general, not just file, but others stuff
too, not even sharing, but doing something for me, sending tweets,
cropping pictures, converting ebooks, etc. Giving the ability of
application to communicate each other is one step to make the Gnome
Desktop a more consistent and integrated ecosystem.
There's one thing to note, the underlying structure, the code bits,
are a lot ahead since dbus exist already and I can't think of a better
way to handle communication

Now: Which is the course from here.
I'm ready to collaborate programming or doing something else

Erick

-- 
El derecho de expresar nuestros pensamientos tiene algún significado
tan sólo si somos capaces de tener pensamientos propios.
El miedo a la libertad, Erich Fromm
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list