On Wed, Aug 25, 2010 at 5:38 PM, Nicolas Chachereau < [email protected]> wrote:
> Cool! Do's not dead. This is great... or so I thought at first. But > now I have become a bit skeptical. I wonder: why did you make this > move? why is it important from an engineering point of view? Is this > the end of Do as we know it? > Not really, Do will look and behave similarly (a lot will change too though), but pretty much everything under the hood will change. > And, more importantly, what is it going to bring to the end user? We want Do to become a first class part of your desktop. To implicitly integrate with your system. We want the applications themselves to have more control over what Do does. This should increase the coherence between Do and *your* desktop. Another great engineering point is that it lets us also move the plugins into their own processes. Plugins will never again be able to crash Do. If a plugin crashes you won't get its items- but everything else will still work, as if nothing happened. > As far as I understand it, each and every plugin will have to be > rewritten... so there are big risks. Am I mistaken on this? I don't > understand the blueprints very well. > Yeah, pretty much. A lot of the code will be reusable but it will need ported. Most of the application interface logic will be the same. > Here are a two things I'd like to see in Do. I think they have been > discussed before, even though I don't remember where and when. Will > this rewrite make it any easier to get any of that pie-in-the-sky > stuff? If not, will it bring some other goodness I'm not even thinking > of? > > * A way to launch Do from Nautilus to do something on the selected > files. While I've never used Quicksilver, this seems to be one of the > feature that make it powerful. Right now, I don't use Do much to do > things with files: drilling down to the wanted file is a bit annoying, > and Ehh maybe. I'm not too into multiple ways of launching Do, and the selected file thing (I think) is waiting some changes in nautilus. I'd love to be able to act on selected file though. It's something I'll look back into when we're there. > multiple selection really doesn't work well (see bugs #268295 and > #320365). > I'l definitely be reworking multiple selection. I'm not sure what it will look like yet but it won't be as half-assed and confusing as it is now. > > * An easier way to develop plugins. I guess it is not really > complicated, but for simple plugins I shouldn't have to read about the > internals of Do, about its "Universe", You shouldn't really have to now. Simple plugins can be hacked up in about 20 minutes, with no real knowledge of Do's internals. > nor should I need to learn a > new programming language (at least for simple tasks). This will be possible! That's part of the benefit of the d-bus based api. You'll be able to write a plugin in anything that speaks d-bus, but for some languages it will be easier than others. Once we're confident enough that the d-bus approach works well enough, and our implementation is solid, we're going to write some wrapper libraries that will handle all of the d-bus and other crap that all plugins will have to do. Essentially all you'll have to do is override or implement a couple of methods. It will be no harder than it is (or is supposed to be...) now. We're going to do a pure C# wrapper (which should mean you also can use any .NET language), and GObject wrapper, which we'll use to generate Vala, Python, and whatever other language bindings can be generated from gobject-introspection. > I am still > impressed with the way Textmate (on the mac, again I have never used > it) allows extension: write a script in your favorite little language > (bash, python, ruby, whatever), you can use some environment variables > set up by the program, tell me what your input and output look like, > and that's basically it [1]. Could this maybe inspire Do? > I'll look. I'm not really sure the model is the same though. It will be more like what I described above. > Right now, I can easily set up a shell script as a program for Do to > run, even with the custom icon, by writing a .desktop file. I can't > pass arguments to it, however. If we could write a configuration file > that says "present an action with this name, this description, this > icon for items of standard type text or url or file or ..., this > action runs this shell script, or runs this external application, with > those parameters, passing the item as that parameter... and doesn't > return anything/returns a filepath/a url" > A lot of plugins are just running external applications any way: > AptURL, Archive, EOGSlideShow, Locate... > Yeah this is a good point. I don't know yet. I'm really not into the idea of custom configuration files people need to write, but there might be a more elegant solution. The fact that it will be possible to write plugins in Python might already solve this. > This was probably too long. My point really is: what should we expect? > This is not the best time for me to start helping on an open source > project, but if it seems worthwhile, I might try to give you guys a > hand - even though my knowledge of C# and Do's code base is limited. > Happy to answer all of your questions, I hope I did a sufficient job. If you have any questions about blueprints, or if you can identify parts that are unclear to you I'd like to know so I can clear the up. -- --Alex Launi -- You received this message because you are subscribed to the Google Groups "GNOME Do" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/gnome-do?hl=en.
