search

z1dev / zkanji

Japanese language study suite and dictionary
GNU General Public License v3.0
61 stars 10 forks source link

Install-aid for Linux & Dark-Theme Icons #8

Open am2del opened 6 years ago

am2del commented 6 years ago

A very basic script which helps those who are unfamiliar with Linux, or just lazy, to install and run zkanji, I'll attach it. Install_zKanji.txt UPDATE @: HERE

It's been tested in up-to-date ArchLinux, as of 2017-12-07. (Too lazy listing all versions.) ...and NO! The script is NOT fool-proof in terms of handling user input errors etc, however - when used as intended, did build successfully on two machines for v 0.0.3-alpha. The current GIT cannot be built due to missing object "charts". (Error occours using QT-Creator as well.)

I also included a 'Dark Theme' icons option in the script, as I noted during first install how some icons where impossible see when using a dark system theme. Also noted, in colour settings, the name of colours cannot be controlled by system theme - hence cannot be read. I made a variation of icons included in the source, which parhaps you could add to your base as optional icons - or just alter colours of to suit the project. Resources-for-DarkTheme.zip

z1dev commented 6 years ago

Charts were a paying part of Qt until 5.7 I think, but became available in newer versions. If it doesn't work, it might not be installed? It didn't match my expectations however, so I'll remove this dependency when I finish code to draw my own charts that I'm currently working on.

z1dev commented 6 years ago

QChart is no longer needed to compile.

am2del commented 6 years ago

First off: Thank you! Great work so far, looking forward to it comming along.

Also, I'd like to give a hand, however - I'm used to Python and not C++, which means you may need to rewrite any coding I do due to structure/optimization etc. Don't know to what extent you wish to do the project yourself, but if you like assistance with easier or general tasks - I can lend a hand when I got some time to spare.

I was concidering making a simplified Python-based thing similar to the old zKanji-project, but without the "study"-features when I found you had revived and turned zKanji into cross-platform. The old Windows-version itegrates poorly through WINE, would rather not even install WINE at all in fact... So I'm very thankful.

I'll open two additional "issues", one for issues/bugs and one for future feature requests.

-- Update -- Can confirm it now builds without charts. Tested interface scaling, and can confirm it working. Made some adjustments in the install script, allthough still too lazy for that dash. Usage instructions within the file:
Install_zKanji-rev1.txt

-- Issue/Bug -- Update on the colour issues: @ Examplebox: --> FG: Kana (カナ), underlining, majority of special characters (、。ー). --> FG & BG: Popup-info box/text. --> BG: Hover in examplebox as well as hover inside popup-info box. @ Settings: --> FG: Select/Drop-down box

All static FG are: BLACK/#000000 Static BG are: White/#FFFFFF & LightGray/#C0C0C0

@ Colour issues > Proposed solution(s): --> Allow system theme to control where possible, alternatively --> Add Select/Drop-down box for above mentioned @ Settings>Appearance>Colours

z1dev commented 6 years ago

Thank you for the offer to help with coding. I don't mind sharing the work at all. Currently the biggest help would be debugging and finding the source of problems on Linux, because the initial release is almost ready. It only misses the automatic updater (I'm not even sure how difficult this is on Linux) and of course fixing all the bugs. I don't know if some problems are caused by using a virtual machine to run Linux or Qt is just bad, or whether it's an inherent Linux behavior, but it behaves differently than on Windows.

I just switched my virtual Linux to the dark theme, and it does have problems.

am2del commented 6 years ago

Linux is my field, but as I'm primarily a hobby-person when it comes to scripting/programming, and only got official/professional experience from Python/ShellScript (for CLI) so I may not be the best debugger for C++ & QT - but I'll give it a shot, and browse around a bit for tips and tricks that may help narrow things down. It's the least I can do to contribute, and to thank you for your work. I'll also check more on coredumpctl/gdb and how to get more useful details out of those. They are roughly 200~250MB so should be possible to extract at least a bit more.

Automatic updater for Linux... may be annoying. There are primarily four families using different packaging systems, however - all (including other UNIX like BSD) can use source, e.g. from GIT or TAR-balls. Getting into official repositories you need to contact each distribution I suppose, but no doubt that is the best way for user-end; pre-compiled for their distribution. You may have a good chance they heed given, to my knowledge, there's no better offline-dictionary tool especially if it gets equal, or better than, the old v. 0.731. (Which was, and is great... just a mess given it relies on WINE and thus got plenty issues. Looks fine at first glance, but once you kept it up in a working environment a bit you'll start see issues like inresponsiveness, inability to accept key-input, draw-failures etc. etc. - also WINE itself is a security risk for Linux-systems.)

If you are to provide pre-packaged packages then .deb and .rpm, plus a TAR-ball, are what you should prioritize. Afterall, majority of Debian- & Fedora-family (Debian, Ubuntu, Mint, Fedora...etc.) users are used to the easy one-click-install and may panic if they see "paste this line into a terminal" or something along those lines. The TAR-ball is generic, but may require a little user knowledge depending on if a helpful install-script is provided or not. From my perspective - who's a bit lazy and prefer all-around generic solutions - the easiest way would be keeping a file (or two) at a repository/server containing version number and have your application try verify against that on startup, notifying user if a new version is available. Then use some script similar to the install-script I attached - I could make a more suitable version if so - fork a terminal and have it compile with minor user input. May require elevated permissions, some query... it depends. A scipt like this could also help with dictionary updates, they got a rsync-server setup and also possible to fall back on wget. By the way, on a sidenote, I'd recommend using dual versions - one for stable release and one experimental for GIT.

As for dark theme, take a look at the Dark-Theme-Resources I attached previously - they contain all icons which were troublesome for me and me acquaintances. An option to look into may be to apply system icon-theme. That way you can be assured there won't be no problem... however, a few unique icons may be required to tag along such as flags. Buttons such as, for example in the kanji dialog, "play", "pause", "next", "previous" etc. would really be preferred if possible to use system icon-theme as that will make it look nicer, integrating with system - and it's the users own fault if they changed to an icon-set which cannot be seen with system theme.

I will take a set of screenshots, and preferably from more than one environment, as I believe it'll be helpful when designing and deciding on colours. Will also help clear out any missunderstandings. But for now from ArchLinux/XFCE with dark theme: screenshot_2017-12-29_23-00-19_examples01 screenshot_2017-12-29_23-02-24_examples02 The first one shows the colours (White & LightGray, note the latter being from mouse hovering) at examplebox as well as the static Black for, currently visible: カナ「」、・ Also noted the scrollbar within examplebox doesn't follow system theme. The second screenshot is of "full" application, or at least as I usually have it set up. Screenshots are taken with the Dark-Theme-Resources.zip package (attached in previous post) for icons applied.

As for where system colours aren't provided, would it be plausible to store primary FG, primary select FG, primary BG, primary select BG and box outline colours in variables and apply there? Would be a generic solotion which (should) look nice with any theme. I'll take a look at settings.cpp within the next few days.

z1dev commented 6 years ago

The automatic updater would be optional, but if it's such an alien concept in Linux I will remove it completely from that version after making it available for Windows. The average Windows user expects this feature nowadays. What the old versions did was checking a file on the SF site, that lists what versions are available. That file also contains the download location for the installers, and if the user accepted, the file was downloaded and executed. It could be multiple files with the archived program and a script if that's more natural under Linux.

I have no idea how packaging for Linux works, so I hope people will magically show up and will be kind enough to help and do it for Linux users. Until then the only options are automatic updates or just a window telling the users to download the new version.

Using the default built in icon themes in every system does sound like the best solution, but it only works if someone creates the rest of the icons not available to match the systems. I took the lazy solution and achieved the unified look by making all icons myself. I'll check the ones you modified and change the originals to fit both dark and light themes.

am2del commented 6 years ago

-- Automatic Updater --

It's not too ailien to rig a solution - the main difference being if users install for multi-user (e.g. as the package manager normally would) whereas permissions will require user-input to update etc. *NIX-users (e.g. BSD, Linux, Mac etc.) usually let the package manager handle and sync everything, making things go transparent. Just look at any Andriod/iOS smartphone and you know what I mean. However, this requires pre-packed packages suited for the specific family/distribution.

Is it possible to ask you to keep two archives for the download - one source TAR-ball and one pre-compiled for stable releases? Whereas most should be able to use a pre-compiled version, it may not work fine for all - so it's good if there's a fallback, and some advanced users/administrators may wish to apply customization/patches for their unique build which easily could be automated through the update script checking and calling scripts at a specific location during the (e.g. within a sub-directory or something, easiest to control through an "update.conf"). To what extent is it possible to (eventually) integrate an "update dictionaries" function? Or should this be through script as well?

For the GIT/experimental a readme and combined install- & update-script can be available to guide the process for those who wish to be "on the edge", even if they are amateurs - also smooth for "lazy" people like me who wants things automated or semi-automated. (Could include setting to prefer GIT in the suggested "update.conf".)

Anyway, to make an outline for the script, up to which point can you handle things from within zKanji? --> Version check? --> Download archive? --> Extract archive? Also, can you pass the path to the running executable to the script, or shall the script handle this? One requirement is to execute bash, preferably in a terminal, so users can supply input if required and also get status report while the script is working. Also skipping the annoyance of applying GUI authentications as it cannot be taken for granted it's installed.

If zKanji can handle the above, it leaves ability to pack the script within the archive and thus adapt the script as/when needed for each update.

As a final touch, I'd suggest allowing multi-versions so if something goes wrong or new version doesn't work as expected for whatever-the-reason - there can be a fall-back option.

Regarding multi-user/system install, I haven't checked out the non-portable option yet at time of writing, but it should use like $HOME/.config/zKanji for user-specific config and $HOME/.cache/zKanji for files which should be writable without elevated permissions. Portable and system-wide keeping configs in (sub-)directory. The single-user/portable default install at like $HOME/.local/zKanji or $HOME/.zKanji to keep things clean?

The wrap-up after update, to be *NIX-frienly, the update itself shouldn't affect usage of the application - just simply take effect once application is restarted. Do you wish to handle this as an exit-procedure after confirmed successfull update? Or at startup? (Could use a simple placeholder file in case user closes zKanji during update, as long as the actual update is forked properly.)

Shall I let the script handle demanding things at nice-15 so the user is unaffected by any compiling or heavy IO.

Let me hear your thoughts, the solution is to suit you. Proposals and such which I've stated above are based on experience from the community, and what's commonly requested.

-- Colours/Icons --

Adwaita and/or Oxygen is commonly packed with any distribution, which makes a good referense for which icons are available. Note that either can be excluded depending on the relation Gnome or KDE, but those two pretty much set a standard for what icons should be present in any icon theme set.

z1dev commented 6 years ago

Everything is possible for the automatic updates, the question is merely what is the least work. I know this sounds lazy, but the user probably doesn't care as long as it works. Checking a version or downloading a file is easily done, but instead of extracting an archive by zkanji, asking the shell to do it is a better solution.

As for the folders, I'm using the paths Qt thinks are standard on Linux. You can check them here: http://doc.qt.io/qt-5/qstandardpaths.html And the documentation for the ini file's class is here: http://doc.qt.io/qt-5/qsettings.html

I don't plan having multiple versions to go back to a previous one. Since I started working on zkanji, I had to change the file format many times. When a new version opened the user data, it saved the data in the new format afterwards and old versions couldn't open it. There are ways to make file formats backward compatible but this is very limited and feels unnecessarily complicated for a hobby project, so I don't think I'll implement it.

I'm working on making the program follow the actual system theme better. I added color settings for the custom drawn scrollbars in the settings window. By default it now uses the default background and text color, because there is no way to access the scrollbar colors from Qt, but this can be fixed later. I think it's not crucial right now so it should wait until first release. The examples strip colors should be correct now, and hopefully many others too. What is difficult to change are the text input fields, because on Windows this doesn't work easily without losing the native look.

I haven't done anything with the icons yet, but I'll stick to the current style for now, while fixing those that look bad on dark background. I think the best option is to allow people to select their own icon set, maybe by putting the SVG files in a folder somewhere, and as people make icons for each system, users will be able to pick the matching ones.

am2del commented 6 years ago

Slight modification made to the old basic install script was made to include neccessary files and a build-stamp. (Just in case someone's using it.) Install_zKanji-rev2.txt

-- Colours/Icons --

Example box looks nice now, adapts nicely to system theme. Scrollbar in this box doesn't adopt system scrollbar style, but colours matching theme so it's fine. Also, this may be preferred the way it is now for a "slim" style - I think you can cross it off your todo-list.

Regarding the text-input fields, I think you should leave them as they are. I've taken a look at various environments and GUI-adaptation wrappers and - at least for Linux - there's absolutely no need to change anything here which I can spot atm.

Colourization issues: @ Handwriting: The drawn line, is forced black. In other words near invisible for any dark theme users. Proposed solution: Would it be reasonable to change those to Primary FG? That way it should adapt to system theme.

@ Handwriting: The background image/text is forced black. In other words near invisible for any dark theme users. @ Handwriting & Kanji Information Dialog: The background grid is forced black. In other words near invisible for any dark theme users. Proposed solution: Would it be reasonable to change those to Primary/Inactive FG? That way it should adapt to system theme. Inactive FG may be preferred as it would not interfere with the visual strokes.

@ Settings, default colours: Would it be reasonable to make default BG @ "Similar kanji bg.", "Kanji parts bg." & "Part of other kanji bg." the system default text BG? So it adapts from start like "Widget background" does.

-- Automatic Updater --

I'll have the script handle from extraction then, and probably just extracting then triggering an Install/Update script in the archive for better control of individual updates.

If I arrange the fallback version retains a copy of userdata as-is at time of update, I can adapt things so there's an easy-to-use fallback-mode for worst case scenarios like broken/failed/incompatable update. Then there will be no need for adding backwards compability. Ofcourse, in my oppninion, the fallback should be optional as it consumes some diskspace. (See 1.)

I'll make a quiet-mode available for updates, but I'd like an option available for non-quiet for several reasons - main one being that it's OpenSource, people should have the right to see what's going on if they want to. Windows-users probably doesn't care as they are used to things being hidden, but the Linux community are used to have a choice. (See 2.)

Another question is if to download the archive to user diskcache (e.g. $HOME/.cache) or RAM-cache (e.g. /tmp)? Both of which got pros and cons... personally I'd say RAM, but disk can be preferred on low-RAM configurations. (See 3.) Many users use Linux for the security so, only the actual "install" part of the script should have elevated permissions for security reasons. Any compile and everything except the actual install/update should be performed at regular user-level.

Anyway, completely quiet is impossible for system-wide install if lacking permissions. Default security is set so that regular users cannot write system-wide, only read. If they want to write system-wide they must provide an administration password, optionally supply login name and password for a user with those permissions.

It's a good thing to follow standard paths, I'll be sure to match those for the script.

Those who prefer patching or modification of stable versions, should have access to an option to simplify this. (Is handled in the Install/Update script, see 2 & 4.)

Proposal, could you add a flag/switch for importing userdata, such a flag would be useful to keep the update seamless. (Along the lines of: -u PATH_TO_DIRECTORY)

Possibly, but not neccessarily, controllable via GUI: 1.) A simple useFallback=bool in a config. 2.) A simple quietUpdates=bool in a config. 3.) A simple preferRAM=bool in a config. 4.) A simple preferSource=bool in a config. Probably best to use a dedicated config for this, e.g. update.conf or something. As then for platforms like Windows where this may not be relevant, it'd be easy to do like: if file "update.conf" exist show UpdateOptions @ Settings. The config for these should be system-wide and located in the zKanji-install directory - just with a different set of permissions (I'll control this through the Install/Update-script) to allow regular users to change these settings.

On a side note: Won't make no promises atm, but I may supply zKanji to the AUR (Arch User Repository) as stable & GIT. Will see later if I do. Anyways, if I do - it'd make zKanji easily available to all Arch-users as well as most of the sub-distros (such as Manjaro). Also improves chances of eventually getting adopted to the official repository. Other Linux-familes lack this type of repository so I won't bother with those... closest is Launchpad for Ubuntu, but it's annoying to use - and I believe most Ubuntu-users doesn't even know it exists anyway.

z1dev commented 6 years ago

I made some fixes to the colors of the handwriting tool and the kanji information. The dark background grid and text on the handwriting tool is due to the dark theme having hardly noticeable grid colors. I was using that till now but I might add a new value just for this.

The background colors for the different kanji listings at the bottom of the kanji information are now the default background. I removed the settings altogether because I feel it doesn't look good at all. It was all right in the old versions of the program that worked only with one theme and only on Windows but it feels out of place now.

Let's plan the automatic update later when everything is fixed. I might even release this version first without including the updater, since I wanted to do that for a while.

am2del commented 6 years ago

Make a release when the "Radical Filter"-bug/issue (#4) is resolved. It has re-appeared, see my post at Issues/Bugs.

-- Colours/Icons --

Colourization issues: (Update @ Build (UTC): 2018-01-04 @ 15:47) @ Handwriting: The drawn line, while drawing ("pressed"-action), is still pitch black - thus cannot see the line while drawing. However, upon "release"-action the line is shown in primary FG colour.

@ I can confirm default colours for Kanji Details Dialog "Similar", "Parts" & "Parts of" now matches system theme.

Others remain unchanged status.

Question: @ Settings > Colours > Kanji: The option "Example word bg." changes the colour... where? It's not the "Words" @ Kanji Details Dialog, if it's supposed to be for this then this setting currently doesn't apply as the background matches system theme just like "Similar" etc now do. Or is it for some study-option I haven't checked yet parhaps?

z1dev commented 6 years ago

The "example word bg." is indeed a kind of study option. In the kanji information dialog you can "select" words for each kanji, and then they will show up in that information's word listing with the example word background color. The buttons to select the words or only show these selected words ("ref.") need an SVG icon that I haven't done yet, and the tooltips for them will tell the user what they are for.

am2del commented 6 years ago

-- Colours/Icons -- Build (UTC): 2018-01-07 @ 15:43

Colourization issues remaining, FG/BG: @ Study-mode, Long-term study -> Study now -> Input-field: --> The field for answer-input is completely invisible/non-existant. (No frame, no marker, no nothing...) --> The text in the invisible answer-field is invisible/non-existant as well. --> ...if there's supposed to be an "submit answer"-button it's invisible/non-existant too. ! Impossible to answer... it seems. Bug or not yet finished feature? @ Other, previously listed, colourization issues: --> Seems all good now.

Colourization issues remaining, Icons: --> Not verified recently, but haven't seen no commits on this lately - so guessing they remain for later.

Colour-option: --> Settings -> Appearance -> Colours -> Kanji -> Example word bg. ----> Move this option to "Study" instead of "Kanji"? Seems a bit more logical.

z1dev commented 6 years ago

The long-term study should be functioning, at least the things you mentioned should be present. The only color issue there from what I know is that the "correct" answer is always a given green and the "wrong" answer is always red, which might not work for everyone. Can you please post a screenshot of the long-term study where this bug appears? That might help me find the issue.

I haven't touched the icons yet and I still need to make some additional icons too.

The example words for kanji is not directly a study option. It's an organizing option currently, and it's only shown in the kanji information window. Putting it on the study page might be confusing. Originally I planned the example words for kanji to be showing up on printed kanji cards (a feature planned but missing in previous versions too.)

I forgot to mention, but I'd like to request you that if there are any new bugs or problems, please open a separate "issue" here on github. I might overlook something when they are all in one big issues thread.

am2del commented 6 years ago

Moved the study topic: HERE

I'll sort remaining (if any) bugs into separate threads later. Want me to do the same with the feature requests?

am2del commented 6 years ago

Finally found the colourization-target for that "Example word bg.". Been wondering what that button was for, thought it was some not-yet-connected filter option like the button next to it.

z1dev commented 6 years ago

You can leave already discussed topics in these original threads. It's been a great help that you are reporting them already, no need for extra work with these. Just make a new thread for everything new.

I have updated the icons in the program to work on both dark and light windows. I would like to keep a single set of them, which means dark outline/shadow for light icons and light outline/shadow for dark icons. I have also changed the play-stop etc. buttons in the kanji information window to always use the system text color. This is not as elegant as using the default icons of each system, but at least this way they don't stand out much. I might get back to this later, but it's very low priority.

I'm currently considering removing the "inactive" text colors altogether from the settings because it's giving me problems. It's not clear whether they should be used when a widget is inactive, or this depends on whether the window containing the widgets is inactive. The Qt docs say this should depend on the window, yet some default Qt controls change color when the widget gets/loses the keyboard focus. There is no such distinction on Windows and I can't find such on KDE either. (KDE has active/inactive colors, but those have a very different function apparently.)

am2del commented 6 years ago

I will take a look at the new icons, hopefully during the weekend - haven't had a moment to spare since my last post (and honestly didn't have the time for that one either). Main focus still goes to the radical data file for now. After the 18th or 20th I should be back at normal pace with things, so - sorry I can't be of too much help until then.

As a rule of thumb, "inactive" colours for marked lines in Linux system themes SHOULD apply when: --> Widget loses focus, or --> Application loses focus. This has a little to do with how the active theme is set up as well... As for keyboard-focus, e.g. "tabbing" etc., if the theme is set up properly it should behave as above mentioned, however - there can be inconsistancies as Linux allow the freedom to adapt to the user.

If it's giving you a headache, how about commenting out these sections of the code for now and later on when the application is getting near completion concider giving it another shot or not as finishing touch?

am2del commented 6 years ago

I have to correct myself, there's one colourization issue remaining: --> FG forced BLACK (#000000) @ Settings -> Colours -> Select-box -> Text (E.g. the name of the colours.)

Good work on the icons, however - I can see three icons which need a minor adjustment to fit "any" theme. Should be easy fix as same method has been used for play-/pause-/etc-buttons: --> Unset the fill-gradient and pass Primary FG colour instead. Issue: Dark fill-gradient. Affected Icons: shadow.svg, strokedir.svg & strokenumber.svg Also, as for strokenumber.svg: The number "3" is halv-way outside of the frame... is this intentional?

z1dev commented 6 years ago

Fixed the black text of the color combo boxes, they should use the default system text color now.

I'll leave the icons as they are for now. It's simpler to recolor the button icons in the kanji info window because they were a single color only but it's not the same with the others. They are visible at least.

am2del commented 6 years ago

Great you fixed the colourization, I'll check it out on Saturday. Just found a bit of time for responding now.

am2del commented 6 years ago

Build (UTC): 2018-01-21 @ 15:01

I can confirm the last colourization issue fixed.