Re: Gnome Feature Request

[Erick Pérez <erick red gmail com>]

On 08/05/2011, Jasper St. Pierre <jstpierre mecheye net> wrote:
> 2011/5/8 Erick Pérez <erick red gmail com>
>
>> > 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
> environment that ever existed. Everything would be *perfectly* integrated
>
>
>> >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.
>>
> I hope you see that I'm not trying to be rude.
I didn't said you tried, I said you were rude. There's a different there.

> I'm not taking time out of my
> day to decypher what you mean by your emails, and cook up some mockups and
> code for you to yay or nay.
I never ask u or no one here to code/design anything for me, actually
if u keep reading the list someone ask me already about my disposition
to code/design and I said 'totally yes'.
I'm programmer and I know perfectly how to build things, I'm proposing
this here to find out what gnome people think about this, and if there
would be anyone wanting to, do it together.

> If you want to make the desktop better, you have to take the initiative and
> lead the project. Provide mockups. Provide code. Again, there's a big
> difference between "we need integration between apps" and "here's some
> integration between apps"... guess which one is more appealing for people to
> take shock at.
Yeah, after the Unity incident when two groups of people working on
improve Gnome couldn't get agree, I do think we first start
negotiating and then coding. No ones want a second Unity jerking
around, or at least I don't.

> And if you want to lead the project, let it be known that it takes an
> extraordinary amount of work: a proper leader should do the amount of work
> of each person on the team, and then some managing the team to make sure
> each part does their part.
Again, even if u think I'm not, I do know what takes to manage a team.
One thing it is necessary is the ability to hear/share/discuss someone
thoughts without attacking it or mocking of his ideas, moreover if u
can't solve the problem either.

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.
I'll do it myself. And then maybe, you find it interesting, or not.

Erick

Thxs anyway

-- 
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