Re: how about modify and remove?

From: mitchell <>
Date: Sun, 8 Feb 2009 13:46:41 -0800 (PST)


> Mitchell, do you think it would be worth it to add two more functions
> to to allow modifying and removing browsers?

No I don't. My main reason for adding the combo box was to get rid of
the menus and to show which browsers are available. (As each browser
is loaded, it adds itself to the list; the menu system can't do this).

>, new_prefix)

Internally, the combo box is a simple list of strings. Adding a
browser is as simple as gtk_combo_box_append_text(). However, in order
to add the functions you mention, I'd have to create a list model to
store the data to. Adding data to a list model is more complicated,
iterating through it to find a matching browser to remove is even more
complicated, and modifying an existing browser is somewhere inbetween.

> Here is an example where remove_browser could be useful: I have
> implemented a feature (I really like from Textmate) whereby dragging
> and dropping a folder onto textadept window loads the folder as a file
> browser in textadept. At some point I want to be able to remove these
> entries in the list, but as it stands now they all have to stick
> around forever (until textadept is closed).

Maybe you could keep track of the last dragged folder's path and
either have a key command or new browser (e.g. "last directory")
activate it?

If you create a new browser, have it hook into the uri_dropped event
for saving paths. When activated, call the file browser's
'get_contents_for' function (remember full_path is a table) and return
the directory listing from it.
Received on Sun 08 Feb 2009 - 16:46:41 EST

This archive was generated by hypermail 2.2.0 : Thu 08 Mar 2012 - 11:37:13 EST