konqueror as filemanager/browser

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

Post Reply
DOCF
Posts: 5
Joined: Mon Nov 03, 2008 2:01 am
Location: Cologne/Köln, Germany

konqueror as filemanager/browser

Post by DOCF »

Hi all. Is there a chance to integrate konqueror as a standalone-solution instead of explorer.exe? Working with many environments and file managers for about 13 linux-years I came to the conclusion that, to me, conqueror is the most flexible solution. Afaik there is also a win32-version of it in kde. we should "peel" it out of kdewin. It can be enriched with plugins, even mozilla plugins are told to work. It should be given a try, konqueror is also the mother of safari..

milon
Posts: 969
Joined: Sat Sep 05, 2009 9:26 pm

Re: konqueror as filemanager/browser

Post by milon »

Any chance you could give it a go and post the results?

Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Re: konqueror as filemanager/browser

Post by Z98 »

Unlikely. Konquerer's behavior from a Windows user's perspective can be very quirky. Also, its Qt dependency pretty much automatically disqualifies it from bundling.

alfanak.net
Posts: 68
Joined: Thu Jan 19, 2012 6:49 pm
Contact:

Re: konqueror as filemanager/browser

Post by alfanak.net »

i think windows explorer is the best, so if developers can make a good clone of it this will be better

cmoibenlepro
Posts: 483
Joined: Tue Nov 30, 2004 5:44 pm
Location: Canada

Re: konqueror as filemanager/browser

Post by cmoibenlepro »


User avatar
jonaspm
Posts: 585
Joined: Mon Nov 21, 2011 1:10 am
Location: Mexico
Contact:

Re: konqueror as filemanager/browser

Post by jonaspm »

Konqueror should be added to RAPPS, no more, since this is a clean OS that it just shows you useful programs you could like, it doesn´t force you to use only one... like Windows does

alfanak.net
Posts: 68
Joined: Thu Jan 19, 2012 6:49 pm
Contact:

Re: konqueror as filemanager/browser

Post by alfanak.net »

jonaspm wrote:Konqueror should be added to RAPPS, no more, since this is a clean OS that it just shows you useful programs you could like, it doesn´t force you to use only one... like Windows does
+1

DOCF
Posts: 5
Joined: Mon Nov 03, 2008 2:01 am
Location: Cologne/Köln, Germany

Re: konqueror as filemanager/browser

Post by DOCF »

hi all. I´ve tried to install latest kde-complete-installer which seems to be broken anyway, even in windows xp. What I am trying is: Download the things needed both to my xp-machine at work and several ReactOS installations, identify installation paths and copy these to a new/neutral ReactOS machine, including files needed. This WITHOUT other stuff that comes with kdewin.

Therefore at first I will try older installers. Then I´ll contact the dev-team there about that install-error to fix it, to use the latest one later.

When/if konqueror is running I report.

Like it or not, we´ve seen tons of filemanagers, latest development is this finder in Mac OS and the finder-like dolphin in OpenSuse, both 2-column-like with sliding effects. As the nice puke-icon said we all have likes and dislikes in filemanagers, but to me a good and practical filemanager is essential and could be shipped with the system.

But if it could be added to rapps amongst others (which one is your favourite?) would be nice.

User avatar
Zc456
Posts: 155
Joined: Fri Feb 11, 2011 10:42 pm

Re: konqueror as filemanager/browser

Post by Zc456 »

As nice as it would be see another file manager on ReactOS (not that it wouldn't be possible), right now the goal is to replicate Explorer.
Stay frosty, Squeaks.

zydon
Posts: 160
Joined: Tue Dec 18, 2007 9:03 am

Re: konqueror as filemanager/browser

Post by zydon »

Zc456 wrote:As nice as it would be see another file manager on ReactOS (not that it wouldn't be possible), right now the goal is to replicate Explorer.
Probably, the problem with existing file manager is redrawing technique issue. currently, it draw item-by-item and read from physical disk at the same time without off-screen buffer object.

For a quick rendering, an invisible listview buffer is required to read the items database from the physical storage. Once it's done, the visible listview append them from the invisible listview buffer. So, the contain displayed almost instantaneous.

The same thing goes to the treeview component for the the disk/folder column. Users will not feel it;s like waiting for all of the items get drawn one after another. Basically, it's the same goes to other application like text editor or web browser that keep buffer object for undo or history purposes.

Feeding bunch of items and redraw it's element into a listview or a treeview could be painfully slow and redundant without using a buffer.

Post Reply

Who is online

Users browsing this forum: Semrush [Bot] and 5 guests