lineart broken in conky #97

Open
b46 opened this Issue Aug 5, 2013 · 14 comments

Projects

None yet

5 participants

@b46
b46 commented Aug 5, 2013

Hi!

I try to setup gcalcli and conky to show a weekly calendar. Here is the line in my .conkyrc file:
${execp ~/gcalcli-master/gcalcli --locale fr_CH.UTF-8 --military --conky calw}

The screenshot shows a portion of the result.
screenshot-20130805-687398823

I have to use the "--nolineart" flag for it to work, but it's kind of ugly...

Is there a way to make it work?

Thanks for you work!

@insanum
Owner
insanum commented Aug 5, 2013

Correct me if I'm wrong but I don't think Conky supports ascii line art. All the lines, graphs, scales, etc you see in Conky are driven by compiled plugins.

If you come across Conky documentation on how to do it I'll look into adding support for it into gcalcli.

@insanum
Owner
insanum commented Aug 5, 2013

I think that the Unicode box drawing characters should work. gcalcli spits out terminal escape sequences for that so that output would have to be changes to spit out proper unicode strings for conky. Can anyone confirm this?

@b46
b46 commented Aug 6, 2013

Yes, the Unicode characters work (you have to use a font that includes them):

screenshot-20130806-534405956

@AloisJanicek

I am having same issue on Arch Linux. I tried different fonts without success.
2013-08-06-155018_1366x768_scrot

@insanum
Owner
insanum commented Aug 6, 2013

@b46 how did it work for you? gcalcli spits out vt100 escape sequence for box drawing. Even when using a unicode font in conky it won't work.

Can you post your conky config and some more details?

@insanum
Owner
insanum commented Aug 6, 2013

Workaround hack to get this working. This script uses sed to translate the vt100 escape sequences to Unicode box drawing characters. Note the '^[' needs to be the actual escape key (i.e. Ctrl-V ESC in vim).

gcalcli --conky calw 1 |
    sed -e 's/^[(0\x71^[(B/─/g' \
        -e 's/^[(0\x78^[(B/│/g' \
        -e 's/^[(0\x6A^[(B/┘/g' \
        -e 's/^[(0\x6B^[(B/┐/g' \
        -e 's/^[(0\x6C^[(B/┌/g' \
        -e 's/^[(0\x6D^[(B/└/g' \
        -e 's/^[(0\x6E^[(B/┼/g' \
        -e 's/^[(0\x74^[(B/├/g' \
        -e 's/^[(0\x75^[(B/┤/g' \
        -e 's/^[(0\x76^[(B/┴/g' \
        -e 's/^[(0\x77^[(B/┬/g'
@AloisJanicek

For me it works, thank you.

@b46
b46 commented Aug 6, 2013

@insanum : sorry, my post was confusing. I was just trying to say that you can use the unicode characters to draw boxes in conky (which was obvious). I used almost the same sed script as you.

I looked at the gcalcli code and at first I thought it could be easy to add a third variant in the ART classes, to have the strings fancy, unicodefancy and plain and an argument for --lineart (for example --lineart vt100, --lineart unicode or --lineart ascii) . But adding unicode strings in the script seems to be too complicated for my python skills:

$ ./gcalcli --lineart unicode calw

┌──────────┬──────────┬──────────┬──────────┬──────────┬──────────┬──────────┐
│Sunday    │Monday    │Tuesday   │Wednesday │Thursday  │Friday    │Saturday  │
├──────────┼──────────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│04 Aug    │05 Aug    │06 Aug ** │07 Aug    │08 Aug    │09 Aug    │10 Aug    │
│          │          │          │          │          │          │          │
Traceback (most recent call last):
  File "./gcalcli", line 2293, in <module>
    BowChickaWowWow()
  File "./gcalcli", line 2189, in BowChickaWowWow
    gcal.CalQuery(args[0])
  File "./gcalcli", line 1571, in CalQuery
    self._GraphEvents(cmd, start, count, eventList)
  File "./gcalcli", line 1017, in _GraphEvents
    str(CLR_NRM()))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 7: ordinal not in range(128)
@insanum
Owner
insanum commented Aug 6, 2013

Too funny. This morning I started the same exercise with the same idea as you. Ran into the same issue. Gave up. Unicode can be such a pain...

Pull requests always welcome! :-)

@tresni
Collaborator
tresni commented Aug 6, 2013

I thought I resolved most of the unicode issues.. Did you have a branch
with the code you have to date?

On Tue, Aug 6, 2013 at 4:52 PM, Eric Davis notifications@github.com wrote:

Too funny. This morning I started the same exercise with the same idea as
you. Ran into the same issue. Gave up. Unicode can be such a pain...

Pull requests always welcome! :-)


Reply to this email directly or view it on GitHubhttps://github.com/insanum/gcalcli/issues/97#issuecomment-22217990
.

@b46
b46 commented Aug 9, 2013

I'm new to git (and github)... I think I created a branch here: https://github.com/b46/gcalcli/tree/unicodelineart with my progress so far. Can you do something with it?

@tresni
Collaborator
tresni commented Aug 10, 2013

You now need to apply locale encoding to weekColorStrings and weekEventStrings if they are unicode type.

diff --git a/gcalcli b/gcalcli
index 4f313b9..b9da0c3 100755
--- a/gcalcli
+++ b/gcalcli
@@ -1011,8 +1011,8 @@ class gcalcli:
                     printLen, cut = self._GetCutIndex(weekEventStrings[j])
                     padding = ' ' * (self.calWidth - printLen)

-                    line += (weekColorStrings[j] +
-                             weekEventStrings[j][:cut] +
+                    line += (weekColorStrings[j].encode(locale.getpreferredencoding() or "UTF-8", "ignore") +
+                             weekEventStrings[j][:cut].encode(locale.getpreferredencoding() or "UTF-8", "ignore") +
                              padding +
                              str(CLR_NRM()))
                     weekEventStrings[j] = weekEventStrings[j][cut:]

This seems really dirty and may fail if you pass it a non-unicode object. Trying to make it fail hasn't worked out for me yet, but likely needs to be wrapped in an isinstance(x, unicode) test.

@tresni
Collaborator
tresni commented Aug 10, 2013

Side note - --[no,unicode]lineart should be changed to a different type instead of 2 different flags. Potentially something this:

--lineart=no/off/plain
--lineart=fancy
--lineart=unicode
diff --git a/gcalcli b/gcalcli
index 4f313b9..85e37e0 100755
--- a/gcalcli
+++ b/gcalcli
@@ -1011,8 +1011,8 @@ class gcalcli:
                     printLen, cut = self._GetCutIndex(weekEventStrings[j])
                     padding = ' ' * (self.calWidth - printLen)

-                    line += (weekColorStrings[j] +
-                             weekEventStrings[j][:cut] +
+                    line += (weekColorStrings[j].encode(locale.getpreferredencoding() or "UTF-8", "ignore") +
+                             weekEventStrings[j][:cut].encode(locale.getpreferredencoding() or "UTF-8", "ignore") +
                              padding +
                              str(CLR_NRM()))
                     weekEventStrings[j] = weekEventStrings[j][cut:]
@@ -1953,8 +1953,7 @@ gflags.DEFINE_bool("started", True, "Show events that have started")
 gflags.DEFINE_integer("width", 10, "Set output width", short_name="w")
 gflags.DEFINE_bool("monday", False, "Start the week on Monday")
 gflags.DEFINE_bool("color", True, "Enable/Disable all color output")
-gflags.DEFINE_bool("lineart", True, "Enable/Disable line art")
-gflags.DEFINE_bool("unicodelineart", False, "Enable/Disable unicode line art")
+gflags.DEFINE_enum("lineart", "plain", ["plain", "fancy", "unicode"], "Sets the type of lineart to use")
 gflags.DEFINE_bool("conky", False, "Use Conky color codes")

 gflags.DEFINE_string("color_owner", "cyan", "Color for owned calendars")
@@ -2046,11 +2045,15 @@ def BowChickaWowWow():
     if not FLAGS.color:
         CLR.useColor = False

-    if not FLAGS.lineart:
-        ART.useArt = False
-
-    if FLAGS.unicodelineart:
+    if FLAGS.lineart == "unicode":
+        ART.useArt = True
         ART.useUnicode = True
+    elif FLAGS.lineart == "fancy":
+        ART.useArt = True
+        ART.useUnicode = False
+    else:
+        ART.useArt = False
+        ART.useUnicode = False

     if FLAGS.conky:
         SetConkyColors()
@daryltucker

Thanks for introducing --nolineart. It's allowed me to see my calendar using conky.

Subscribing to see if anything 'fancier' makes it in :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment