further thoughts on file manager vs web browser

[Aaron Seigo]

hello all...

after reading Waldo's recommendation to split file manager and web browser 
into two modes in konqi, i sat back and let it ferment in my head for a few 
days. here are the the elements i see it affecting:

sidebar: only show contextually appropriate items. e.g. why is there an RS web 
sidebar in file manager mode?

menus: why do we have all the file destinations in the "Go" menu in webbrowser 
profile? we also have so many greyed-out items in the Edit menu in web 
browser mode because they don't make sense in that context. menus should be 
tuned to each modes to make sense within the context of those actions.

toolbars: we already can define which toolbars to have associated with a 
profile, but this needs to be extended. in file manager mode i should have 
the location bar in it's own toolbar, but not in web browser mode. and this 
needs to span across all file management profiles.

profiles: show only "file management" profiles in file manager mode, for 
instance. this is the one aspect i'm least convinced of.

tabs and window behaviour: as defaults it may make sense to have tabs always 
shown in web mode, but not in file manager mode. it may also make sense to 
have different "new window opens in...." settings for file vs web browsing.

config dialog: by having two types of apps it allows us to split out the huge 
number panels into to much more manageable sets, and even remove the web 
browser panels from kcontrol (which we can't really do right now since we 
should have the file manager ones there and since they are shown with web 
panels in the app config dialog need to stay together in kcontrol too)

Tools and other plugin stuff: right now our Tools menu is cluttered with an 
amazing number of plugins. these need to be made "file manager", "web 
browser" or "universal". this is already managed to some degree via 
kpart-specific plugins, but things like Run Command and Show Terminal are not 
really appropriate in a web browser. neither is a Javascript console needed 
in a file manager.

so, as we can see, virtually every area of the UI benefits from such an 
awareness of what we are trying to do

now, we can't implement this completely in profiles because there are many 
things that need to be shared ACROSS profiles. unless we implement "profile 
inheritance" so that profiles can "inherit from" file manager or browser (or 
whatever) then we'll have a lot of setting duplication and syncing to worry 
about.

we can't implement this completely based on the URL since there's no 
meaningful difference between local and remote these days. ftp:// versus 
file:// versus smb:// versus....

we can't implement this completely based on the loaded KPart either, since we 
have parts like (for instance) document viewers. taking PDFs as an example, 
when one clicks on a local PDF the UI should be "file manager stuff" + "PDF 
stuff". when browsing the web, it should be "web browsing stuff" + "PDF 
stuff". clearly this isn't a content-centric UI change, then.

this leaves us with creating a way to have (at least?) two modes in Konqueror 
and allow it to masquerade as (e.g. via a symlink with a different name, and 
check argv[0]) either a file manager or a web browser.

i would say that's my "two cents" on the matter, but it seems like it's at 
least a nickel's worth of typing ;-)

-- 
Aaron J. Seigo