konqueror as filemanager/browser
Moderator: Moderator Team
konqueror as filemanager/browser
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..
Re: konqueror as filemanager/browser
Any chance you could give it a go and post the results?
Re: konqueror as filemanager/browser
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.
-
- Posts: 68
- Joined: Thu Jan 19, 2012 6:49 pm
- Contact:
Re: konqueror as filemanager/browser
i think windows explorer is the best, so if developers can make a good clone of it this will be better
-
- Posts: 483
- Joined: Tue Nov 30, 2004 5:44 pm
- Location: Canada
Re: konqueror as filemanager/browser
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
-
- Posts: 68
- Joined: Thu Jan 19, 2012 6:49 pm
- Contact:
Re: konqueror as filemanager/browser
+1jonaspm 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
Re: konqueror as filemanager/browser
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.
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.
Re: konqueror as filemanager/browser
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, Tony Bark.
Re: konqueror as filemanager/browser
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.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.
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.
Who is online
Users browsing this forum: No registered users and 43 guests