@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
I am trying to build+debug ... without success
I get
2: Task failed with an exception.
Where:
Build file 'D:\arn\downloadTools\hadoop\hdfs-explorers\mucommander\apache-bzip2\build.gradle' line: 16What went wrong:
A problem occurred evaluating project ':apache-bzip2'.Could not get unknown property 'revision' for task ':apache-bzip2:jar' of type org.gradle.api.tasks.bundling.Jar.
Any idea ??
hi @/all , there is an ongoing discussion about switching to Discord (https://github.com/mucommander/mucommander.github.io/pull/3#issuecomment-782229116) and as this group has not been active for a while, I'm wondering whether it has something to do with the tooling itself (gitter) and if so, whether Discord would be better. I'll appreciate your feedback on this!
if it managed to support OneDrive, Box and GDrive, even with third party plugins, I´d be all set.
@fcassia_twitter , google-drive was added in 0.9.6 . I was about to write you that I'm working on adding dropbox but I see that 'box' is a different thing :) it's now easier than ever to add new services like that - how about filing an issue on github for 'box' (we already have one for onedrive) and see if someone will pick it up?
Hi Arik, many thanks for your work, my donation will be soon :) I almost managed to reconfigure muC to mimic win TC with all keybindings (even Alt+F5 +F7 etc) trying to replace TC to unified work on linux and macosx and have only few quirks. One is SCALING, when linux ubuntu gnome is at 125% fractional, then muC is TINY - appearance fonts to 24pt helped, but rest of UI tends to be tiny still - is somewhere possible to direct java to scale it with -Dsun.java2d.uiScale.enabled=true or so? Another thing which is weird is nonpersistence of remote connections (I tried FTP, SFTP along with gdrive too, which is fastest, but nothing was persisted - always needed to enter password and each service has then only one instance?) but again, thanks a lot, it elps me to live in lin/mac :)
@apws thanks for the feedback :) iirc tuning scaling by default was addressed by a later version of Java - but the one I previously upgraded to (11) was buggy so it was reverted back to Java 8. need to give it another shot. persistency - yeah, we generally store the credentials but it's different with those cloud storages (google drive and in the next release also dropbox) that require authentication through the browser - their credentials are stored differently (in the .credentials folder)
and good to hear you plan to contribute key bindings! I had some thoughts about it in the past, like that it would be nice to configure them differently per-OS. do you intend to change the default bindings or to make more intrusive changes to the implementation?
hi, I summarized my approach here - its from the point of view of windows user, ya
mucommander/mucommander#437
mucommander/mucommander#437
one thing I dont know how to achieve yet is making separate virtual volumes (mimic win drives) on unix-like; its probably some symlinks mounted under /Volumes (on mac) ... in windows I use such few root "drives": H: ~/ O: ~/OneDrive W: ~/OneDrive/Documents P: ~/OneDrive/Pictures V: ~/Versioning X: ~/Downloads (easy by VisualSubst app)
in relation to code contribution, I am only few weeks back in java after 20 years (from C#), but commited to stay to death, probably )) ... peeking into muCommander source caused me some kind of fever though ... I know its organized and well done, but too much well done for my current abilities to help :))
and yeah, the separation to modules with OSGi definitely complicated the repo but on the other hand, should make it easier for us to provide an API for plugins
let me know if I can assist with questions or things that block you from contributing
ale nice thing would be to ensure only one instance - both things switchable in settings, sure
hi @ahadas ! is ADB protocol support something that you could see being merged if ported from trolcommander? I saw it being mentioned on issue mucommander/mucommander#18 and I was thinking of giving it a try
@elemongw hi, sure. It can be a nice addition. It won't be trivial to port it since in mucommander it needs to be an OSGi module that provides a new file protocol but there are plenty of existing modules that can be used as a reference. So yeah, this contribution would be appreciated!
Hi @edvbevan, from what I have seen up until now muCommander does not have special handling for mobile devices and most of them nowadays do not support mounting them as external storage (if your device does allows this though, muCommander should be able to see it). In the future, you may be able to connect to Android devices over ADB, I am working on a pull request for this but it is still in early stages.
Hey everybody, I'm having difficulties figuring out why muCommander is not getting my SMB shares connect that can be connected using plain Finder or alternatives like Nimble or Commander One. When I type the address of the share in the SMB tab of the Connect to server dialog, I'm getting a "SMB share does not exist or cannot be accessed". Mind that these are SMBs over the company VPN but muCommander has network access in the security settings.
hi @paullemmens , it might be because mucommander supports SMB1 and the server supports SMB2+ (mucommander/mucommander#101) . another reason I know of is when NTLM authentication is disabled (see https://github.com/mucommander/mucommander/blob/0.9.7-1/package/readme.txt#L81)
great to see that the work on connecting to Android devices over ADB is in progress on and that there's a demand for it. @elemongw I filed mucommander/mucommander#483 and labeled it with 0.9.8-1 so it will be on our radar
@edvbevan, thank you for your kind words. @ahadas deserves all the praise for muCommander through, I have only made a couple of contributions up until now. Regarding the ADB support, I'll try to finish up the port soon. In the meantime, you could try using an FTP Server on your Android device (like this one, altough do note that I haven't tried it yet) and then connect from muCommander to the URL reported by the application (PC and Android should be on the same network). This should allow you to avoid having to directly slot the SD card to your PC until ADB support is completed.
@ahadas I hope I will have something good enough ready by the time you would like to release 0.9.8. The state of the ADB support from trolcommander is not the best and there are many stub methods. I will probably submit the pull request once it is in a working state so you can provide your input on what it would need before being merged. I will also work into improving it over time.