PATCH - HOME URL and profiles

[Dawit A.]

On Sunday 19 September 2004 06:39, Alexander Neundorf wrote:
> Hi Dawit,
>
> On Saturday 18 September 2004 12:01, kfm-devel-request at kde.org wrote:
> > Hello,
> >
> > I know this issue has been a point of much discussion as can be seen by a
> > bug report with high number of votes and comments (BR# 8333) as well as a
> > recent article on the dot that show how to hack around a solution.
> >
> > With the attached patch my intention is not to start another long debate,
> > but to see if we can easily solve this problem without a need for a hack
> > and without breaking the current behavior while at the same time allowing
> > people to change what the "HOME" button does per profile. I have actually
> > not coded up the GUI changes yet. It is going to be pending the outcome
> > of this discussion. I do however have a UI file that shows what the
> > changes to the profile config dialog might look like:
> >
> > http://members.cox.net/kdelists/screenshots/konq-profile-dlg.png
> > http://members.cox.net/kdelists/uifiles/konq_profiledlg_ui.ui
> >
> > Any suggestions, comments, feedback, opposition, support, icecream, cake
> > and cookies are all welcome...
>
> Nice that finally somebody does something about it :-)
> Some comments:
>
> your patch assigns a home url to a profile. Now you can switch in one
> profile between web browsing and file management. A per-profile home will
> also take you to the web-home if you are currently looking at your local
> files. Another way to do this would be to have a profile-global web- and
> filemanagement url. The web home is used if your current url in http/https,
> the file management url is used for other protocols. I don't know if this
> would be better, just an idea.

Well the problem with the approach you suggest is that it can easily get too 
complicated since we have protocols other than http/https that can be 
considered web based, e.g. ftp, webdav. So where does one draw the line ? And 
how can we prevent hard coding of such information so that the code does not 
need to be modified everytime a new protocol is added ? 

> Now a comment to the implementation: is it necessary to reload the profile
> file everytime in slotHome() (searching the file, loading the file and
> parsing it) ?  It would be better to do this only when loading the profile
> I think.

It would be better to do what you suggest if this was a critical path. But how 
many times does one press the Home button ? If not all the time, then why 
store the Home URL in memory ? My patch is not the only one that does this 
btw. In fact I based the code that reads from the config file on the function 
that creates a new window when a user requests one. Anyways, I am also too 
lazy to check the many paths that might be invoved in switching profiles and 
ensure a proper Home URL is loaded when that profile gets activated. :)

-- 
Regards,
Dawit A.
"Preach what you practice, practice what you preach"