 My name is Alex Martin. I work for Red Hat. I do a lot of mail work. I mainly make tape, all of us, which I'll be a fan of. So I'm here to talk about all of us. I'm going to talk a bit about what it is. Some of the ideas behind it. Some of the history. And then I've got pretty pretty technical details. Like the power between man and I.O. And then I'll go into how you, as a third party developer, can extend all of us. But we'll start with what it is. I mean, the easiest way to describe it is to say it's the power manager for the known desktop. But really, there's like this mission behind it. That makes it more than the power manager. The original vision that the ESOL people, or like the original people had, what's that, a universal viewer? Better viewer in a DSR this morning. Kitty has a similar idea we compared. So basically the power manager would just be a shell that displays location and lets you navigate to a location. And then all the things in the middle of the window use their own plugins that depend on the type of power they're displaying. So we would have a couple of folder views when you fold. And we also have like displays for approaching files and images. Very exciting to talk to files. It became obvious that this wasn't really a good way. I mean, it's very nice. It's actually maybe from a design standpoint. But it's not very useful. People do really want to use really applications to view files. They don't really understand the difference between something, something opens in the new window. It looks a little different sometimes than it appears in the normal file manager window. The current vision analysis is to focus on managing the day-to-day managing files. And maybe not the extreme, deep hierarchies, but how you open files, how you browse your files. And conceptually it shouldn't be an application that you let launch. You want to look at the files, but it should be a part of desktop experience. It should always be there. It should be the file system. The way you think a folder should be... You should think of the window for the items in it. That's the folder, right? It's not this app that displays the files, isn't it? But the window is the file system. And we wanted to be easy to use. Even though sometimes this comes as a cost and a loss of power, we believe that simplicity sometimes triumphs with extreme power flexibility. The history of all this starts with EISL. It's a company that came out in 1999 in San Francisco who wanted to do no work. So they started doing file manager. Because that's what... We did have a file manager at a time. You know, the V90 Matter. But it was based on the V90 Matter code base, which didn't work really well in the UI. Because the internal design, it just didn't work well in a typical event-based UI app. So they started rewriting... We're running a new file manager. We had the V999. And then a year or so later, we finally got NOLIS 1.0 released. And then film 1.4, which is the first film with NOLIS and NOLIS stack. About this time, my first work with NOLIS is committed. It's a jaking, thumb-knitting performance fix. But it actually is somewhat interesting. The first time I heard about NOLIS was back in 1999 when I was working in a company in Sweden doing embedded Linux work. I was working with Silva and Rivera from Netscape approached me and asked me if I was interested in working. And this new company was doing this really cool file manager. And I was like, I'll make it. Yeah, I was excited. So I ended up not doing that, which is certainly interesting given how maintain it. Anyway, shortly after the release, in May 2001, 1-3, which was the final release from ESO was released because they had to shut down ESO after the funding. However, a lot of people at ESO, the main thing that I read was the main architect and the maintainer kept working on it far, far longer than that. So even after it was shut down, he was working on really known to report and all sorts of stuff. So this is where I committed. By this time, I had to open Red Hat and we were doing work in Red Atlantic 7.2, which was the first release to have done 1-4 on the whole NOLIS stack. So we were doing lots of work in it, performance work, maybe instability work. And it ended up being me doing lots of work in it and working with Aaron to get stuff back on stream. Thanks. He asked me to join him, so we both maintained it for a while and eventually I took over. He moved to Back to Apple. He ended up in Safari, actually. But then, NOLIS 2.0 was released. This was about the time NOLIS 2.0 was released too. It was basically the same app as NOLIS 1.0, but it was moved to a completely different platform, which helped a lot. We could trim away a lot of extra features that we had to implement. For instance, NOLIS 1.0 had a data stack, and it was done in a way that was not... It was not in GTK, but it had special case anti-dots codes. We could drop a lot of code. It was just a better release. And since then, we've had regular releases every six months, regular NOLIS schedule. And there's been a couple of major changes since then. September 2004, Dave merged it. Welcome to the Spatial Mode Ranch, which I'm sure some of you hate, and killed me later. And now, recently, I've landed the Label's Label Ranch, which removes the final use of, you know, the user interface, and thus finally kills this whole original universal browser idea. Even though we did remove that idea from the user interface a lot earlier, but now it's no longer a problem. They're troubled by the sun. And basically, we've got a new maintainer. Dave and I are sort of busy with all these stuff, so we need more people, more viewing patches, and whatnot. As we see, as we saw, there's been a lot of changes in NOLIS, both in the platform it's based on, and the UI. But there's one part of NOLIS that's always been the same. I'll call it the NOLIS IO model, which is the basic way that NOLIS works, doing the final layout. So NOLIS is a single-threaded application. Actually, it's not, but the user interface part, it is really single-threaded. So all Windows are displayed by the same thread. Then in blocking IO calls, do the main thread, and we do all IO using NOLIFES, which is a kind of library that abstracts poly tests. So the whole sort of stack application, which uses a sort of control or abstraction that helps abstract away the asynchronous of the NOLIFES sync operation later, which in turn uses a set of modules that implement various protocols and filesystems, such as file, the Unix file, system, FTP, or something like that. And I'll go through all these layers, starting from the bottom, quite similar to the virtual filesystem in the kernel, which uses URIs, instead of file names, the library module, in that you call them URI method, and each method implements a POSIX-like operation to code. I mean, it is very much like normal Cisco. In Unix, we have overview, right-close, or normal file operation. Hit file info is very similar to STAT. We have directory meeting operations, and this is some other tool. And this is the way, if you're implementing a method, you can start sort of, in PIs, you're implementing, where both you can sort of get, get, and the open call gets URIs, some other arguments, and what it does, it generates a method handle that contains some general information for the operation. And then it returns that encoder, and every time the caller wants to read something, you get the handle passed, and you get this buffer that you want to put to fill in. These are some sort of generic error codes, like internal, but it's not very variable. So these are very, these are synchronous calls, so if you call read, it will go up until it read some amount of bytes. And that might be sort of slow, if you're doing that. FTP call system might be a bit like, even if you're using a normal Unix file system, it could be on NFS, but forever. So we can't reuse this, in all this itself, so there's the asynchronous, you know, the FES operation, which is a layer built on top of these, and it's open call. You're booking, you're passing the call back, and it returns immediately, but eventually the operation will finish and you get the call back, and you get the results from the call back. They're in the call back from the operation. And the way this works internally is that when you call your VFS, a signal when it creates a job object, and queues it, or if you want to queue, and then there's the setup, or read thread, and then whenever they're free, they pick the most prioritized job and executes that. And when it's done, use the G-Lib main loop, and that handling system as an end to the main loop where they call back to the original, it calls the app. The app took my call back. And there's also support for cancelling jobs, so if you're no longer interested in long-running jobs, you can cancel it if you want to be called. This is sort of complicated to handle, so to make it easier to implement all this, we have a number of layer abstraction called all this file, which provides a much easier way to have a little asynchronous IO, at least from the perspective of doing the user invasions. So the way it works is you ask for an all this file object for your UI, and you get this object, and you just call and ask it for whatever data you want. So say you want the size, get size, it would just return that I don't know anything, I don't know the size. So what you do then is say you want to display the file, the file size, in a dialog, that you would register the monitor of the file, say I'm interested in these attributes, the file size attribute, and whenever the state changes in the file, you can get a callback, so you can update your label, display the new size, so initially you just display nothing, register the monitor, it will start the IO, eventually you get a callback, some sort of IO happens, so the file size changes, then you will get another callback, so you can always keep the latest information on the screen. And there's also one other thing, so sometimes you have a different sort of usage of it, for instance you want to type the file so that you know what to do, to launch it, so you click on the file, you want to know what type it is, so you register a callback ready, whenever Nolus knows what type it is it will call you and then you can do something, it will never get called again. That Nolus file is actually the way caching is handled internally, because whenever you ask for a file for a specific URI, you always get back the same object, so the Nolus file object itself caches information for as long as it lives, this means that whenever you do some sort of IO to a file, and Nolus is done through a file, Nolus file objects, so whenever you do something to validate, like if you rename something, you have to validate the name attributes on the Nolus file object, because otherwise it will easily end up with state your caches, and there's also a similar object called Nolus directory, which basically keeps a list of Nolus files, which are the unique callbacks like files and each window is playing at the directory, and thus all the Nolus files are in the directory, and this is the basic caching that Nolus does. Let's talk a bit about extending a list, I mean anybody can like hack Nolus and send me a pack, I might take it, or maybe not, but what I'm more interested in is external third party expansions, meaning that something that's not shipping the core Nolus part, and this is interesting is the less people experiment with stuff that people might not get ready for yet, I might want to like it, everybody might not want it, but it's also an excellent way to keep down the dependencies from the core, so maybe your extension depends on say an application, essentially only being installed when you have the application, or maybe it depends on if you require the original method of extending all this and it is tied to this original vision of the Nolus user, so you replace and you write a new component for same file time, or folder, but that's not really, it ends up not being a very good extend stuff, because say you're wanting to write a CVS view, now the CVS view shows a directory and lets you start the CVS, but it also replaces by the item view and list view, so you have to re-implement all those, if you want the CVS view to be able to rename a file, which have to actually implement a file renaming, instead of order using the code that does not have any Nolus, so it will also look completely different, now that you spend a lot of time making sure it looks exactly like Nolus, and it can't in any way extend existing views, the original approach also uses to put a Nolus, which is very handy for your work, it works of aid for the sort of total replace of the whole content of the window that we're giving originally, but it doesn't work as well if you want to have more fine-grained extension points, and it's also sort of complicated process communication, we have activation framework where you have a query that allows you to ask for plugins, so we decided to have a radical new approach, it's much simpler, it uses fine-grained extension points, so there is a set of places that are currently existing views where you as an extension author can't extend them, you can extend the context menu, so there's a place for that as a whole, and they're all simple shared library plugins, the problem is that any shared library will be blew in a specific place, Nolus will load all those plugins, and then there is a public interface library that everything links to that exposes some Nolus terms enough that you can write important extensions, so technically an extension is called a g-type module just some deep magic core of the object that lets you declare z-types which is the core types and g-objects lets you declare them in a shared library so you can be on load and type fill away, so you create this g-type module with these three functions initially I think all the terms, initially it shuts down, you can do it on load and extension and then there's this list of types which is what does most work, it returns a set of types that Nolus can create, this type is supposed to implement what we call a provider interface and the provider interface is defined in this library called lib-nolus extension which every extension links to and then each type of provider is for one specific extension point that we have and the provider wants them to work by returning or refer to its property object which is just a simple set of name properties that describe the object you're adding to the UI or whatever and these all run in the same process in Nolus you can crash stuff, you cannot control you can't hold on to an IO that will freeze the whole list and the main way that extensions work in Nolus is using the Nolus following for object and the Nolus following for object represent the file that Nolus has some interest in in some way and if you know something about the architecture of Nolus it's obvious that it's very similar to a Nolus file in fact it's just to face that Nolus file implements it lets us decide which part of the internal of Nolus will expose and these files is like Nolus files that live as well because Nolus has any interest in the files there's no way to to limit to just go for caches and whatever you want to do in extension and the file in for itself is extensible using extensions so you can create extension called Nolus InfoProvider that provides information for the file if you can give extra information I'm going to describe some of the current extension points we have the most simple one is the menu provider see these two extract here and right to this there are two extensions one is from the archive manager file roller the text that file roller can handle isos lets you extract them the other one is from Nolus Ebur lets you burn into that these are added to the the per file context menu you can also add stuff to the background context menu and you can add stuff to the toolbar just in browser mode if you get cold whenever Nolus tries to play a menu and you try to return a list of all this menu I have objects that you think matches this file you get passed in you describe the name, the label it's an internal thing that you use to find the object but the label is what you display in the menu the icon these objects also have a single typical dk signal that gets emitted when the user actually selects this the item you just connect to that object or that single in the object and when it gets emitted do whatever you want to do another simple type of extension is the property page provider which lets you add property page dialog so you can add what this is from the Nolus BZS extension which has some CGS it's essentially a CGS view but down to the new system so you can and you can decide whether you want to show something and if you do you can put any sort of dk widget in the dialog and then there's the more complicated thing column provider that's something we call column just not really something you see a bunch of user interface it's something you can show so a column could be actually a column that lists you like this is the version info there is something like that you can also use them in the item view that's extra information under split labels so the existence of a column doesn't mean that there's any information in it it's just you need to add something to this reference panel where you can select which column you want to display you need to have an actual null as the info provider that actually generates the information so the null as column refers to an attribute so you better have a null as the info provider that adds that specific attribute so in this case there's actually two extensions going on here one is the column that suits you like this and the other is the info provider that actually generates the information from the column and the info provider can also generate also add emblems to the CBS extension also add emblems to check down files or non check down files locally modify the files and this also works with the null system so whenever null is decided it's interesting information it will get you your extension will be called there's one of the methods info provider in the face is update file info that will be called when you need information when you get called you're supposed to call null as file info add emblem or add string attributes to the base information you're providing just immediately you do it in return operation complete or you can also schedule as soon as I owe and then eventually when the I owe finished you store a reference to the of the contingent closure which is basically a type of callback and you call that and say I'm telling this now and all this null aside you can also you can suddenly decide that it's not really interested in this anymore cancel it and they need to cancel all outstanding information and make sure you have a call as update complete function keep track of this stateless of an add if something happens to a file it changes the information you added you need to validate extension info and whenever something changes to a file all this tends to throw away all the extension information and regenerate it so if you have something that's really expensive to compute say you need to load like the CVS directory folder a good way to cache that is to use the golden references on the null as file info object which means that whenever that object goes away cache goes away this is sort of a limited set of extensions that you can do at the moment we have ideas of what you think what I let people extend for instance we have the sidebars and browser and sure we'd like to let you manage your own sidebar objects and there's also this idea about file reviews that I'm not sure yet how to implement file reviews but for instance KDE does it as a hover thing so when you hover over an icon you just like start display it it's an M3 file you can stop playing it it's an animation you start playing animation we haven't really figured out a great way to do this the whole hover thing and stop being so irritating but eventually you'll find out figure out a good way to handle this and then a great example bugging the generation extension you need to have extensions to play 3 files and play animations and live things like that we also want to pick up the column handling event right now you can just add columns and then the user has to manually add them to the user interface you want to have it so that say your CBS column version of the column sort of automatically gets used when you're in a directory that has CBS information but never otherwise we need to figure out all the details but hopefully we can make that work because without that we're hitting that we support this feature we're also looking at that you have better directory views T view is it's used in macOS X it's very interesting also we want it to start to view and then for both getting it to start these are not going to be implemented as extension but I'm really sure that they'll have lots of places where people want to extend them and it's also we need feedback from people who are interested in doing some kind of extension it's very easy to add them but we're only interested in adding extension points if somebody's actually interested in using them also if you have a good idea please come to us and ask us implement it for you there's some references to documentation there's some loving lists where you can get information about all of this all of this VCS is a very complicated extension that uses all of the possible things you can do right now whereas FABRO and all of C were more limited things than just add things to the news depending on what you're interested in one of those could be an interesting starting point we can have any questions we're always going to ask all of this and give them that there's some making lists and all of this where you can ask us things and then my it'll talk so does anybody have any questions will I get a billion new extensions after this is anybody interested in adding an extension is anybody interested in introducing it does anybody have an idea or something that you'd like to use I don't think you can use Python right now I know Dave from you can write on it you'd have to write right now you'd have to write the wrapper it does use the the object type system a lot it says pretty easy to integrate another type system it might not be hard to to get the Python thing going because you're already proud that you are doing all the interfaces a lot of people have an interest in Python and Mono so see if there's going to be work on extension support for those languages I suspect a lot of people would love to write extensions unless you're a hard on C hacker then it's quite difficult to get started