On 08/05/2011, Jasper St. Pierre <jstpie...@mecheye.net> wrote: > 2011/5/8 Erick Pérez <erick....@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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list