On Tuesday 11 January 2011 16:14:14 you wrote: > On Tuesday 11 January 2011 15:31:57 Lionel Chauvin wrote: > > Hi Martin, > > > > >Nevertheless they would still live in the browser. > > > > If I understand well your idea, some tabs of rekonq will have their own > > entries in the task list and some will not. > > I propose a better idea: > > Create a dedicated version of rekonq for web apps. > > This version will: > > - show the icon of the website as icon of the window > > - remove the name of rekonq in the title of the window (I don't know how > > but I am sure it is possible), only keep the name of the website (eg. > > Google map). - clic on a link: if it is a internal link of the website > > then open it in the web app window else open it in the normal rekonq > > version. > > - remove the urlbar > > - remove the tool button-menu > > - remove new tab button > > - hide tab bar by default > > - keep previous,next and reload buttons ? > > - adapt context menu accordingly > > > > In the normal version of rekonq: > > - add actions somewhere in the UI to register a website as a web app. > > - clic on a link: if it is a link of registered web app: open it in its > > dedicated window (perhaps in a new tab) and focus this window. > > > > I propose a related idea: > > create packages that depends on rekonq for easily install web > > applications. these packages will add entries in kickoff. > > Lionel Chauvin. > > From what I remember this pretty much sounds like what silk/selkie aimed > for. Yes that is exactly the silk usecase and completely orthogonal to what I presented. It would solve the "web applications need to be application" problem but it requires a different workflow and would not improve the situation for tabbed browsers. So having the one does not obsolete the need for the other.
Cheers Martin
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ rekonq mailing list [email protected] https://mail.kde.org/mailman/listinfo/rekonq
