Re: Passing thought about nautilus embedding
- From: Wesley Leggette <wleggette gate net>
- To: merchan phys lsu edu
- Cc: nautilus-list gnome org
- Subject: Re: Passing thought about nautilus embedding
- Date: 03 Apr 2003 17:26:37 -0600
On Tue, 2003-04-01 at 22:58, Gregory Merchan wrote:
> I've before stated my objections to Nautilus views, so I won't rehash that.
> I did want to say, in case it hasn't been mentioned, that I have no
> objections to app-embedding as an implementation detail. Indeed, I think
> it some things may be better that way. What I have in mind is two-fold:
> app-embedding becomes seamless so the difference is only visible in the
> process table; as part of that, the browsing method is removed.
>
> Things being connected in this way, I imagine it would be easier to make
> user objects seem persistent. If the folder showing a file's icon and the
> window showing the contents of the file are controlled by the same program,
> then that program could indicate the file is open and raise the view if the
> file is "re-opened." (That's just one example.) Nautilus-embeded apps might
> be made the GNOME-standard method of file handling and since almost every
> app deals with files in some way (e.g., the launching .desktop file),
> Nautilus truly becomes a shell for everything.
>
> It seems to me that this would reduce, slightly, the amount of
> app-programming needed.
What kind of code are you looking to replace? File handling? GUI? File
dialogs?
> (I've not written any bonoboized apps, so there may
> be no reduction; I'd be surprised to find an increase.) I think the amount
> of glue code (e.g., packing menubars) would be reduced. Writing a new app
> would be:
> 1) Creating a object that handles a data type.
> This is, I presume, most of the work.
> 2) Exporting the methods of that object, with some structure, to Nautilus.
> From this the menus and toolbars would be created, and these methods
> would be the verbs of a desktop-wide scripting language.
What kind of API are you imagining.
> 3) Crafting some secondary windows for commands needing qualification and
> for utility.
>
> In a way, I see this as making Nautilus and the entire desktop into a highly
> graphical and less obtuse Emacs.
Sort of like a monolithic desktop?
> App writing becomes more like writing
> extensions to Emacs, and customization becomes simpler in the same way.
> (I mean customization in the sense of MS Word macros as get shared within
> businesses for the purpose of making repeated tasks simler, not endless
> keybinding reconfiguation or the like.)
>
> That's what I have to say, as oversimplified as it is.
>
> Cheers,
> Greg
This is an interesting idea. I'm getting the impression that that's the
kind of thing that's meant with the embedded AbiWord capabilities.
Personally, I don't like this model. I prefer different and smaller apps
to handle different file types. But that's not saying that your idea
wouldn't work.
As a side note, I get the feeling that interaction between Nautilus and
other applications is a little bit unsound at this point. Is this what
you're addressing here?
--
Wesley Leggette <wleggette gate net>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]