Giter VIP home page Giter VIP logo

Comments (23)

kaikramer avatar kaikramer commented on August 11, 2024

Actually, I wanted to get rid of this dependency for a while now. It should be possible by using reflection. I will look after it during the next couple of days.

from keystore-explorer.

DevDef avatar DevDef commented on August 11, 2024

I’m glad to know that you were already concerned by this licensing problem. :-)
You’re doing a really great job. Thanks a lot!

By the way, may I suggest you to provide an SVG version of the application icon (kse.svg)?

from keystore-explorer.

kaikramer avatar kaikramer commented on August 11, 2024

It's done, AppleJavaExtensions.jar is not required for compiling anymore.

The application icon was made by a professional designer a long time ago. I only have PNGs in sizes from 16x16 to 512x512 pixels.

from keystore-explorer.

DevDef avatar DevDef commented on August 11, 2024

Don’t worry about the SVG... I tried to vectorize your icon by myself, but I’m really not good enough at this... :-/
I have a more important problem: the code doesn’t compile anymore. I’m screwed with 7 for-each errors in X509Ext.java looking like this:

Buildfile: /home/davy/rpmbuild/BUILD/keystore-explorer-master/kse/build.xml

init:

compile:
[javac] Compiling 302 source files to /home/davy/rpmbuild/BUILD/keystore-explorer-master/kse/build
[javac] warning: [options] bootstrap class path not set in conjunction with -source 1.6
[javac] /home/davy/rpmbuild/BUILD/keystore-explorer-master/kse/src/net/sf/keystore_explorer/crypto/x509/X509Ext.java:592: error: for-each not applicable to expression type
[javac] for (ASN1Encodable attributeValue : attributeValues) {
[javac] ^
[javac] required: array or java.lang.Iterable
[javac] found: ASN1Set
[...]

Any hint?...

from keystore-explorer.

kaikramer avatar kaikramer commented on August 11, 2024

Have you replaced the Bouncy Castle v1.53 jars (bcpkix.jar and bcprov.jar) with an older version? Or maybe you have included another BC version in your Java installation? It must be something like that.

from keystore-explorer.

DevDef avatar DevDef commented on August 11, 2024

Well done! I use the ones provided by Mageia Cauldron (developpement version) which are 1.52 versions, according to Mageia policy. Even Fedora Rawhide (often the most advanced GNU/Linux distro) versions are 1.52 due to other project dependencies...
So, it's a pity that BouncyCastle 1.53 (or the brand new 1.54) is mandatory. What would be nice is to provide a new 5.1.2 stable release of KeyStore Explorer that would compile without AppleJavaExtensions.jar and run with BouncyCastle 1.52 jars (it matches well: 5.1.2 for 1.52, same digits in a different order ;)).

from keystore-explorer.

kaikramer avatar kaikramer commented on August 11, 2024

Nah, the release of 5.2 is too soon to do another release before... Anyways, KSE did not use any important new features of BC 1.53, so I have simply restored compatibility with 1.52 in the latest commit.

from keystore-explorer.

DevDef avatar DevDef commented on August 11, 2024

Thank you very much for reverting to BouncyCastle 1.52 !
I‘ve finally successfully built my RPM, but I had to patch your source code in order to remove all references to Darcula, because even though it looks pretty nice, it’s not packaged in any GNU/Linux distro (and especially Mageia) and I really don’t want to add the burden of creating a specific package for it.
I noticed a little strangeness: the user preferences subdirectory name:

/home/username/.java/.userPrefs/net/sf/_!'s!~@"5!(:!d!"v!()!~@"f!'`!e!"w!'w!bw"y!'`!cg==/prefs.xml

Shouln't it be one of:

  • /home/username/.java/.userPrefs/net/sf/keystore-explorer;
  • /home/username/.java/.userPrefs/net/sf/keystore_explorer;
  • /home/username/.java/.userPrefs/net/sf/kse?

Moreover, for a better GNU/Linux integration, I think it would be interesting to default to GTK+ theme, at least for GTK+ based desktops (GNOME, MATE, LXDE, Xfce...) and keep Plastik 3D for Qt based ones (mostly KDE), as it integrates better with it, IMHO. After a rapid googling, I found that reading the XDG_CURRENT_DESKTOP environment variable should easily do the trick:
http://stackoverflow.com/questions/10235117/how-to-detect-if-linux-os-uses-kde-or-gnome-environment
http://askubuntu.com/questions/72549/how-to-determine-which-window-manager-is-running

Anyway, thanks for you involvement,

Davy

P.-S. : You should activate the display of spaces and tabs in your code editor/IDE to avoid mixed indentations (tabs and spaces) and trailing spaces at the end of lines. Your latest additions are using white spaces whereas the code is mainly using tabs...

from keystore-explorer.

kaikramer avatar kaikramer commented on August 11, 2024

Darcula is completely optional now (commit af3eee0).

The preferences subdirectory's name should indeed be .../net/sf/keystore_explorer. It's the same weird name in my Mint installation, but fine under Windows and Mac OS. I will take a look at the issue.

As for the default look&feel under Linux: I agree that GTK+ should be the default for GTK based desktop environments, but the value of XDG_CURRENT_DESKTOP seems pretty diverse and unreliable (e.g. for KDE it is sometimes empty, sometimes 'KDE'). Still, I could set GTK+ as LaF for all known values (basically all the values from your second link but KDE) and default to Plastik for the rest.

The mixture of tabs and spaces and the trailing spaces are caused by me experimenting with IntelliJ IDEA over the last few weeks (I usually use Eclipse). Obviously the formatting settings in IntelliJ are different from those in Eclipse... Thanks for pointing that out.

from keystore-explorer.

DevDef avatar DevDef commented on August 11, 2024

Once again, thank you for simplifying GNU/Linux packaging. I’m less surprised of your involvement now that I know that your a GNU/Linux user. ;)
I had to patch the source to disable the test stuff too. It should be disabled by default.

I have an ultimate request (at least for now ;)): use the desktop environment file chooser, i.e. GTK file chooser for GNOME and others GTK desktop environments, and KDE file chooser for KDE, provided that you finally find a reliable way to detect the use of a KDE desktop.
As I saw that you are already using the OS file chooser for Window$ and Mac OS X, I’m pretty sure it’s easily doable for GNOME and KDE...

I should also provide you my XDG keystore-explorer.desktop file to be integrated to the source code. Concerning the start script, it’s more complicated because it’s more distro specific, and it should be generated by ant. But if your are interested, just tell me...

Of course, the work will be really completed after a full localization. And, as I’m French, I will provide a French translation. :)

Davy

from keystore-explorer.

kaikramer avatar kaikramer commented on August 11, 2024

Compiling/running the tests is now separate from compiling the main code.

The file chooser only looks similar to the native one on Windows, but it behaves differently and if you look closely there are several minor visual differences. On Mac OS and Linux the file chooser does not even look like the native one. I am aware of that and I don't like it either, but right now other issues are more important.

I am not interested in the .desktop file (there are so many easy ways to create a launcher nowadays) or the start script (as you said it's distro specific), but I am actually interested in the rpm file. I would really like to take a look at it.

I am thankful for every contribution and a french translation of KSE would be great!

from keystore-explorer.

DevDef avatar DevDef commented on August 11, 2024

I am not interested in the .desktop file (there are so many easy ways to create a launcher nowadays)

Well, this time I must disagree. The XDG file remains the most standard way to do it and, anyway, there’s no constraint to use it. But, from a GNU/Linux packaging POV, it’s clearly a must have. The idea of providing it upstream is to centralize the translations. And it also contains the MIME types to bind the file managers (like Nautilus, Dolphin, etc.) with the different kinds of file handled by a software (i.e JKS, p12, p7, pem...).
keystore-explorer.desktop.zip

I will provide you my RPMS (the source RPM for building) and binary too, but I have to rebase them from your latest changes and that means to rediff the patches...

Is your code already ready for localization? I ask because I have no experience in Java l10n, my translations are usually gettext po files. But I know someone that could help me with the Java bundle stuff...

Davy

from keystore-explorer.

DevDef avatar DevDef commented on August 11, 2024

One more note about the patch:
As I build KSE with my distro’s JARs, some of them have different names:

  • JavaHelp is javahelp2.jar, so the trick is to patch the build.xml to rename jhall.jar as javahelp2.jar ;
  • MigLayout is a unique JAR miglayout.jar, whereas you have 2 separated JARS: miglayout-core.jar and miglayout-swing.jar, so the patch removes those two JARs and add miglayout.jar

I would prefer doing this differently, with some ant parameters, but I failed for now... :-/
keystore-explorer-5.2.0-rename-needed-jars.patch.zip

from keystore-explorer.

kaikramer avatar kaikramer commented on August 11, 2024

That was a misunderstanding, I wasn't saying that XDG .desktop files are the wrong way to do it, I was just saying that there are many tools to quickly and easily generate them. For example one can extract the KSE ZIP distribution file somewhere, right click on the desktop, select "Create launcher/shortcut" (or however it is done in the respective DE), select kse.sh as command, select the application icon and that's it. Of course that generates a much simpler .desktop file than the one you wrote, but it might be enough for many users. However, I like the idea of centralizing translations and MIME-bindings.

Yes, KSE is ready for localization. All display texts are in resource bundles (resource.properties in the various sub-folders).

from keystore-explorer.

DevDef avatar DevDef commented on August 11, 2024

OK, I’m glad to read that it was just a misunderstanding. :-)
So, as I promised, here is ZIP containing a source RPM (all the needed stuff to build a binary RPM) based on your latest code and a resulting built RPM.
keystore-explorer-5.2.0-0.git20160107.1.mga5.zip

Now, I have to take a look at the bundles French translations...

from keystore-explorer.

kaikramer avatar kaikramer commented on August 11, 2024

Thanks for the RPMs. Be warned that there are more than 10.000 text snippets to translate. That might be a bit too much for one person. However, many strings are something like "Authority Key Identifier Extension" which might not be worth translating.

I have found the reason for the strange directory name (.java/.userPrefs/net/sf/_!'s!~@"5!(:!d!"v!()!~@"f!'!e!"w!'w!bw"y!'!cg==): When Java creates the sub-directories, it checks for "inappropriate" characters in the directory name and if it encounters one the name is translated to alternate Base64 and an underscore character is prepended. While it is a good idea to make surethat the directory contains no problematic characters, it makes no sense at all to include the underscore character into the list of "inappropriate" characters and then prepend it after making the string "safe". Also it is rather questionable to use the alternate Base64 encoding. However, I doubt that Oracle would accept a bug report for that and as I cannot simply change the package name, there is not much I can do about it.

from keystore-explorer.

DevDef avatar DevDef commented on August 11, 2024

Translation is in progress. It will take a while to fulfill, step by step... You shouldn’t have told me that there were 10,000 strings to translate, it is discouraging. ;-)
I found some strings (the 5 first strings) in this file https://github.com/kaikramer/keystore-explorer/blob/master/kse/src/net/sf/keystore_explorer/resources.properties that shouldn't, IMHO, be part of translations and sould rather be defined as static strings in a class:

KSE.Name=KeyStore Explorer
KSE.SimpleName=kse
KSE.Version=5.2
KSE.SimpleVersion=52
KSE.AppUserModelId=SourceForge.KeyStoreExplorer52

Concerning the strange user preferences directory name, I've found a very old bug report from 2002 considering it’s not an issue and won’t be fixed: https://bugs.openjdk.java.net/browse/JDK-4696941
IMHO, it’s a shame that it hasn’t been considered an issue as it really hurts the eyes!

Of course, renaming the package from keystore_explorer to the more compliant (though not very elegant) name "keystoreexplorer" could be a simple way to fix this (using the powerful refactoring function of Eclipse).
I wonder if the package’s prefix should even be renamed according to where the code is now hosted, i.e.: "com.github.kaikramer.keystoreexplorer".
WDYT?

from keystore-explorer.

DevDef avatar DevDef commented on August 11, 2024

French translation completed (except the help and HTML pages)! \o/
I haven’t tried to recompile and test yet, though. I’ll try tomorrow and let you know...

I think I deserve a credit for such a hard work. ;-)

Davy

from keystore-explorer.

kaikramer avatar kaikramer commented on August 11, 2024

Wow, that's great news! I didn't expect the translation to be completed so soon. Well done! Of course you will get full credit for it.

I just realized that I didn't answer your last comment, so I'll do that now:

Those 5 strings have have to be in a properties file (and not in the code), because I want all version info in one place and a properties file can be accessed from both Java code and the build file. Until now there were no translations, so it was basically just a properties file. I guess I'll have to move them in a separate file now...

I'll think about changing the package name to "org.keystoreexplorer" (looks bad without a seperator), but not before the next release. I registered that domain so I don't have to change the package names again when github falls from grace.

Ah, and btw, native file dialogs are now implemented. It requires JavaFX (and probably Java 8), which unfortunately might be a problem for Linux distributions. If KSE doesn't find JavaFX, it will fall back to the Swing file dialogs. It works pretty well with Oracle Java 8 on all three platforms. There might be a way to make it work with OpenJDK 7 as well, but I haven't found it.

from keystore-explorer.

DevDef avatar DevDef commented on August 11, 2024

First build was the good one!
But I had hard time tweaking Git to get your very latest nice changes (GTK default :-)...) because I’m a Git rookie.
Now, how can I submit my work? I don’t have permissions to push my changes...

from keystore-explorer.

kaikramer avatar kaikramer commented on August 11, 2024

The GitHub way to submit your work is to send me a pull request. First you have to fork my repository, then apply your changes there and finally create the pull request.

Some links about this topic:
https://help.github.com/articles/creating-a-pull-request/
https://help.github.com/articles/using-pull-requests/
https://yangsu.github.io/pull-request-tutorial/

from keystore-explorer.

DevDef avatar DevDef commented on August 11, 2024

Done: #12

from keystore-explorer.

DevDef avatar DevDef commented on August 11, 2024

Hi Kai,

Apparently there’s no private messaging (any more) in GitHub, hence why I write you here because it’s kinda related and it doesn’t deserve a new issue...
I’ve completely missed the release of KSE 5.2 because I was daily monitoring your commits waiting for something like “bumping 5.2 release” that has never came...
I had a look on the main Web site this week-end and I saw the 5.2 release notes. So, I’ve rebuilt and submitted a source RPM of KSE 5.2 yesterday. It has been accepted and built this morning. So, as I promised, KSE is now officially included in the upcoming Mageia 6. :-)
FYI, I also started to write an article about KSE on LinuxFr.org, but it’s not finished yet...

Cheers,

Davy

P.-S. : I’d like to have your e-mail address for these private discussions, if you don’t mind. I think you already have mine...

from keystore-explorer.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.