Ooh, I also found this which seems useful: https://techbase.kde.org/Development/Tutorials/Debugging/Debugging_IOSlaves/Debugging_kio_fish
@ahadas, not trying to pressure anyone, but do you think there is any interest in adding this protocol to mucommander? I really like the look and feel of mucommander.
Since I can't install Krusader on the latest MacBook Pro, I'm starting to wonder if I'll just have to run a VirtualBox VM for this. :-)
Since I can't install Krusader on the latest MacBook Pro, I'm starting to wonder if I'll just have to run a VirtualBox VM for this. :-)
@BobbyTBS , sorry for the time it took me to respond. It is an interesting RFE, and is well aligned with my ambition to attract more linux users. We can try doing the following - please open an issue to add it and I'll tweet this. Let's see if anyone will be interested in implementing it first (or maybe you want?). If not, I'll add this to my TODO list. I cannot promise when I can get to that though, since there seem to be missing things that having them would make a bigger impact than this.
Thanks for the help. No problem if you can't get to it. Maybe some day I'll have enough time to learn enough to take on a project like this... He he he.
Hi! So, I've been using muCommander to transfer files to tape drives with good results, though I'm wondering, how difficult would it be to add the option to use ltfscopy to transfer to tape drives. ltfscopy has the hability to verify the files copied on the fly and some other options. I'm assuming muCommander invokes cp under the hood? I'm totally uninformed on this matter.
Hi @ronalith_twitter , so a bit of a background - except for very few cases, muCommander doesn't invoke command line tools like cp. Instead, we use Java libraries that provide an API for streams. This has two benefits: 1. being implemented in Java allows us to use the same library in different operating systems 2. the stream-API enables us to execute file operations between two remote files without copying the whole file to your local machine. For instance, you can copy a file from one FTP server to another by opening an inpout-stream from the source and stream the input to an output-stream that writes to the target server.
@ronalith_twitter , I didn't find a Java library for ltfs in a brief google search. Do you aware of any Java library available for that?
@ahadas thanks for coming back to me. I didn't find anything as well, and because of the different compilations and versions provided by different manufacturers, it might be a better approach to find a library that adds CLI commands and then add the options required by the common copy and verify tasks. Again I barely know what I'm talking about. Perhaps the commons-CLI API?
@ronalith_twitter adding that kind of CLI tool handling would not be the best way to do for a cross-platform tool like muCommander. IMHO what muCommander really needs is a plug-in architecture (like TotalCommander has) to allow such extensions (that might not even be platform independent) to be made by the users and installed easily. The main selling point of TotalCommander is that it has such a huge amount of plug-ins: just take a look at some user plug-in here http://totalcmd.net/
a new os in the making, go check out https://friendup.cloud/
I can see mucommander living in the middle there! And thank you all for keeping developing mucommander!!
my current settings:
Gradle 4.3.1
java 9.0.4
when I run: gradlew run
I got: java.lang.IllegalArgumentException: Could not determine java version from '9.0.4'
when I run: gradle run
I got java.lang.NoClassDefFoundError: Lorg/gradle/listener/ActionBroadcast;
this happens since I updated from Java 8 to 9
I need Java 8 as a must to run muCommander ? there is no way to run it with Java 9 ?
@jsebasct That works around the linkage issue, but Proguard still fails the packaging step for JDK9+. I've issued a PR that works around this conditionally (#158, pinging @ahadas :-))
@addrian Uh, no, that's just a fork (and it doesn't even say what's changed). I meant that the JARs aren't officially available from a binary repository, e.g. Maven Central or BinTray, and the recommended practice is to build Proguard yourself and include the redistributable.
@holograph sorry again, I'll review the PR on the next few days
So as promised, I merged #158 (thanks @holograph!) and also published earlier today a blog post in which I share some thoughts regarding muCommander: http://ahadas.github.io/about-mucommander. Would love to get your feedback on this!
Hi guys, I just found out about muCommander and I really like it so far. Maybe I'm stupid or something but how do I get to the user documentation? Using Help > Online documentation in the application takes me to Home · mucommander/mucommander Wiki · GitHub. The bullet there that says "Documentation, to learn more about the way muCommander works." on that page doesn't have any link (the other bullets do). I can't find any in the github wiki side bar either, nor on the homepage :/
Hi Oscal, welcome :)
Unfortunately, that part never existed. You can find the original link at:
http://web.archive.org/web/20140814211713/http://trac.mucommander.com/wiki/Documentation
May I ask what were you trying to find in the documentation?
Unfortunately, that part never existed. You can find the original link at:
http://web.archive.org/web/20140814211713/http://trac.mucommander.com/wiki/Documentation
May I ask what were you trying to find in the documentation?
Hi @ahadas :) Thanks for your reply, that explains I couldn't find it ;) Mostly what I wanted to check was if there's a recommended way to backup my custom keyboard shortcuts + bookmarks as I've modified them quite a lot by now. I've also managed to restore the factory defaults once so I had to start over.
@ocyj , well, I'm afraid the only way is to back them up manually: browse to the folder that hold the customization files (it depends on the operating system you're using, see: https://github.com/mucommander/mucommander/wiki/Preference-Files) and copy action_keymap.xml and bookmarks.xml elsewhere.
Guys, I'm glad to announce that version 0.9.3 has been released! It is a relatively small release that includes few important fixes and some very nice contributions from the community. As a token of appreciation, @holograph and @thomasuebel were added to the list of contributors. Thanks guys and keep up the good work!
@ahadas hey mate, I was hoping .. could you please shed some light onto the release process ? The readme shadowJar seems to be commented out. What is the way to get the full jarfile to run with the runner script? (trying to run it this way for debugging purposes in other enviroment). cheers
@kousalik hi and welcome! :) not all the packaging options have been adjusted to OSGi yet. We will no longer the application as a single jar but as an OSGi application, like Eclipse, that is composed of a running script, the apache-felix framework (or any other framework that we prefer) and a folder of bundles. You can take the RPM packaging as a reference, I started to adjust it
If you like to fix the packaging for the specific distribution you work with and need an assistance, please let me know
cool, I figured that out at the end ... reseting to the last release commit should do for me at the moment. what about some prioritization? tasks to track progress or at least give some context around the work ppl could do? I guess not really necessary if you're the only active developer. Anyway I thought I could get my head around the source a little by looking at some of the issues. Anyway, I'll try to have a look at some of the issues working in the 9.3.4 branch.
If I'm successfull I'll fix it in both streams
@kousalik , yeah - so I think we're talking about two different things here. (1) progress tracking - we used Trac in the past and then tried Jira but that seems to be overkill at the moment, as you wrote; and (2) pool of features that newcomers could take something from - I started to write something in https://github.com/mucommander/mucommander/wiki/Roadmap. That being said, I think that our main focus should now be stabilizing the master branch (fixing stuff that got broken by the switch to OSGi, including packaging) and addressing some of the more important issues, in order to release 0.9.4
Then I think we can publish the artifacts needed to implement new plugins, which will make it easier for people to introduce new functionality, like a PDF viewer
But it was hard to keep them sync and we kind of mads duplicate efforts in few areas