Jump to content
Sign in to follow this  
ylee

i386 python-efl docs, wrong symlink _gv.i686-linux-gnu.so

Recommended Posts

Yak-shaving seems to be the story of my life when programming. 
 

 





 Aug 14 2013 ... Wow has it been that long ago?...  tbradbeer began work on eText a simple EFL based text editor. Shortly afterwards he abandoned work on the project, but Jeff started work on his ePad program apparently as a fork of eText. For the record I doubt eText functions with the more recent  EFL and python-EFLs. Anyway as some may remember I did a little work on ePad myself and one of the things I wished to add but never got it functioning correctly was a Font Selection dialog. We had alot of request for that. eText btw did have a simple not completely functioning Font Selection dialog:
 

 4Ts5tte.png

 

 
Examining eTexts code as well as looking at enventors code which also has a Font selection dialog, I quickly hacked up a simple Proof of concept Font selection dialog:
 

 OChYV7H.png


 

However in both cases my dialog and eTexts Font selection dialog We have no way to select Font style. For example compare with gtks Font selection dialog:
 

 fontselection.png


 

But it should be noted enventor's Font selection dialog, while in C code and NOT python was fully functional:


 noo2BqH.png


 

Now the code implementing this in enventor is rather complex as this dialog in enventor does more than simply allowing a font selection and further enventor makes heavy use of edje for interface details so to make a long story short I was unable to get my font-selection python code to implement the font style settings. Eventually I gave up or became distracted by something else or whatnot and stopped development on this dialog. A couple of days ago I was wondering about it and dug up my old code and started playing with it on Bodhi 4.x. After all EFL has matured as has my understanding of EFL , maybe I will have better luck now.

 



 
So to summarize my original problem was to code a font-selection dialog in py-efl as fully functional as the gtk or other toolkit versions complete with a  font style setting. Sounds simple enough and a little research revealed I should have access to the style information of a font using the py-efl function:  elementary.font_properties_get. After all enventor does the same thing using the c function: elm_font_properties_get. In a perfect world the python version of the function would function exactly like the C version. 
 
Well no such luck :(  A little testing and all attempts to use  efl.elementary.font_properties_get() resulted in an error similar to one below:
 
 

Traceback (most recent call last):
  File "efl/evas/efl.evas_object_smart.pxi", line 446, in efl.evas._smart_callback (efl/evas/efl.evas.c:78724)
  File "font.py", line 164, in font_demo_set
    print elementary.font_properties_get("Liberation Sans Narrow:style=Bold Italic")
  File "efl/elementary/__init__.pyx", line 1037, in efl.elementary.__init__.font_properties_get (efl/elementary/__init__.c:17689)
TypeError: efl.elementary.__init__.FontProperties.__new__(): not enough arguments

This led naturally to me looking thru the Source code for py-efl itself. Didn't help much probably because I am not that familiar with the cython stuff that implements py-efl. So I rewrote my tests in C and low and behold it worked fine. The mystery deepens and a couple of hours had passed completely unproductive. Now I usually am not the sort to ask anyone  for help but considering I do know Kai Huuhko pretty well and he works on py-efl and is a Bodhi team member I ask him on FB about how to use this function. After explaining the error and what I was attempting to do, his response:
 
 

Oh there's a bug there
Should have the object type as arg for __new__
...
I'd better get a working env setup then so I can fix it :)
...
Yeah it didn't have tests written for it and no one needed it, so it's been just sitting there for years with that issue you just found

 
And fix it he did, in of course py-efl git. I suppose it pays to have friends that are e-devs. Much thanks Kai :D
 
Now this explains my difficulty three or four years ago getting a py-efl font-selection dialog implemented and may in fact be one of the reasons  tbradbeer gave up work on eText.
 
But nonetheless this led to my next problem I had to compile and install EFL from git and py-efl also from git to test Kai's fix. Fortunately I keep some VMs around for such tasks and have one with Bodhi4.x installed, moksha stripped out and EFL and e21 compiled from git already created. I fired it up and installed the latest py-efl and in my brief test it seems efl.elementary.font_properties_get functioned correctly. 
 
After testing the font_properties function I decide to go ahead and create the Docs for py-efl as I had already went thru the build process and assuming i have the needed packages installed it should  be a simple:
 

python setup.py build_doc

Plus I like having the docs around as it is a fairly common occurrence for the enlightenment documentation online to be down. Of course the documentation is in the source files BUT that is not nearly as nice as having it in HTML or similar format.
 
Well the documentation built but sadly it lacked the inheritance and other diagrams, wtf :( 
 
So I re-examined the dependencies needed and took another look the at the README and INSTALL files in py-efl to no avail. Googled the issue again with no results. 
 
Now for the record and for the google juice this problem had became the fact the python-efl documents fail to build correctly on bodhi 4.x so we may as well say python-efl documents fail to build correctly on Ubuntu 16.04,  xenial.

 

bodhi@bodhi-VirtualBox:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Bodhi Linux
Release: 16.04
Codename: xenial

All needed packages seem installed:
 
 

bodhi@bodhi-VirtualBox:~$ dpkg -l | grep graphviz
ii  graphviz                            2.38.0-12ubuntu2.1                       i386         rich set of graph drawing tools
ii  libgv-python                        2.38.0-12ubuntu2.1                       i386         Python bindings for graphviz
ii  python-pygraphviz                   1.3.1-0ubuntu2                           i386         Python interface to the Graphviz graph layout and visualization package

Note one thing this is a 386 virtual image that is is to say I installed 32 bit Bodhi/ubuntu in my Virtual machine.
 
So after more research I end up taking a look at the python-efl/doc/config.py file, since I read:
 
 

Besides using raster images (PNG, JPG, etc.), diagrams can be included with the `sphinx.ext.graphviz`_ extension.
 
Graphviz_ is an open source graph visualisation software. Graph visualisation is a way of representing structural information as diagrams of abstract graphs and networks.
 
It must be installed before the extension can be used.
 
Including the extension in the project configuration file
The Graphviz extension is included with Sphinx, but the extension must be enabled in the conf.py file:

 

In said file I find the code:
 

# -- Inheritance Diagram ------------------------------------------------------


try:
    import gv
except ImportError:
    pass
else:
    extensions.append('sphinx.ext.inheritance_diagram')

 
Hmm inheritance diagrams will not be created if python is unable to import the gv module. Maybe that is the problem so i opened a terminal and :
 
 

bodhi@bodhi-VirtualBox:~$ python
Python 2.7.12 (default, Nov 19 2016, 06:48:10) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gv
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/dist-packages/gv.py", line 28, in <module>
    _gv = swig_import_helper()
  File "/usr/lib/python2.7/dist-packages/gv.py", line 20, in swig_import_helper
    import _gv
ImportError: No module named _gv

 Yep module gv fails to load even tho libgv-python SHOULD install it: No module named _gv.

 

 Further examination reveals:
 
 

bodhi@bodhi-VirtualBox:~$ dpkg-query -L libgv-python 
/.
/usr
/usr/lib
/usr/lib/python2.7
/usr/lib/python2.7/dist-packages
/usr/lib/python2.7/dist-packages/gv.py
/usr/lib/python2.7/dist-packages/libgv_python27.i386-linux-gnu.so
/usr/share
/usr/share/doc
/usr/share/doc/libgv-python
/usr/share/doc/libgv-python/copyright
/usr/share/man
/usr/share/man/man3
/usr/share/man/man3/gv.3python.gz
/usr/lib/python2.7/dist-packages/_gv.i686-linux-gnu.so
/usr/share/doc/libgv-python/changelog.Debian.gz

Now I have no idea what you gather from that but after a few moments of looking at it it looked fishy to me. Notice libgv_python27.i386-linux-gnu.so and _gv.i686-linux-gnu.so. Why the mismatch and why does it seem I have a 686 file stuck in here. As noted above this is a 32 bit install. Another WTF moment.
 
Indeed _gv.i686-linux-gnu.so is a link to a non-existent file :(
 
 

bodhi@bodhi-VirtualBox:~$ cd /usr/lib/python2.7/dist-packages/
bodhi@bodhi-VirtualBox:/usr/lib/python2.7/dist-packages$ ls -l *gv*so
lrwxrwxrwx 1 root root    32 Jan  5 16:17 _gv.i686-linux-gnu.so -> libgv_python27.i686-linux-gnu.so
-rw-r--r-- 1 root root 93880 Jan  5 16:17 libgv_python27.i386-linux-gnu.so
bodhi@bodhi-VirtualBox:/usr/lib/python2.7/dist-packages$ 

 

Shown perhaps more clearly in pcmanfm:
 

8cqcaOJ.png


Well fortunately, this is not the first time I have saw broken links or problems like this. To fix the issue:
 

bodhi@bodhi-VirtualBox:/usr/lib/python2.7/dist-packages$ sudo ln -s libgv_python27.i386-linux-gnu.so _gv.i386-linux-gnu.so 
 

And verification:
 

bodhi@bodhi-VirtualBox:/usr/lib/python2.7/dist-packages$ python
Python 2.7.12 (default, Nov 19 2016, 06:48:10) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gv
>>> 

Now cding to the right location and:
 

python setup.py build_doc

Works as expected and builds the documents complete with diagrams :D
 
NZryhQZ.png

 
 
It should be noted about half way thru this meandering debugging I finally had enough to google and found that this issue with building python-efl docs is the 386 version of a reported Ubuntu/Launchpad bug: libgv-python: wrong symlink from _gv.x86_64-linux-gnu.so.
 
Sounds simple enough and after the fact it usually does but this tale illustrates what i mean by yak shaving as well as why seemingly simple things seem to take so long for me. Now gotta get back to my font selection dialog which is what brought all this up in the first place  B)  B)

 

EDIT:

 

For the record I have reported this issue upstream: LP: 1678532

  • Like 4

Share this post


Link to post
Share on other sites

The rant above was inspired by my recent work in continuing an old abandoned EFL programming project, namely trying to implement a Font Selection Dialog in python-efl. So this is just an update, my first fully functional py-efl Font Selection demo program beta version 1 (lol):

 

c5iwx6P.png

  • Like 3

Share this post


Link to post
Share on other sites

Looks good, even including previews. Kudos.

 

Any ideas about getting a wordwrap function done in Epad?

 

Enjoy,

Charles

 

Thanks Charles :D

 

Word wrap I had implemented once in ePad. Jeff broke it with the way he implemented line numbers. It was either removed or commented out, forget which and too lazy to look. Anyways it was hard to add back and preserve his line number feature so I sorta left it at that.

 

I haven't forgot about it tho. And I am pretty sure I know how to do it in C but had issues trying to implement in python-efl. Doing it in C requires low level access to efl-evas textblock in  the entry. Something I never figured out how to do in python and may not be possible. Low level access to stuff is not what python usually allows. But I need to re-examine it, things may have changed, I may be able to find another way, I may have been mistaken back then, py-efl may be able to be patched to allow such a thing, and so on.

 

But i agree, ePad needs word wrap, the font selection dialog above as well as a preference dialog implemented to be fully functional. And perhaps some way to deal with its slow load speed. Anyways hopefully I will get around to it  B)  B)

Share this post


Link to post
Share on other sites

Font selection looks sweet especially after all the hard work. Only one question remains: Ylee, when are we going to drop the word "beta" and simply call it version 1?

Share this post


Link to post
Share on other sites

Font selection looks sweet especially after all the hard work. Only one question remains: Ylee, when are we going to drop the word "beta" and simply call it version 1?

 

Much thanks for the kudos DOOMguy :D

 

While I have a degree in computer science and have coded all my adult life, in reality I am a brick mason and as a mason I have to say there is nothing at all hard or difficult about programming. Frustrating sometimes certainly, time consuming yes. Hard ... hard is when you work in mud up to your knees and move over 25 tons of concrete block as fast as possible, it is not sitting in an air conditioned room, typing googling and thinking. lol

 

Anyway, my attention right now is jumping back and forth between several things I think I need to implement, learn or do. So beta will be dropped from the font selection dialog once I solve a couple more outstanding issues to my satisfaction. One being the 'proper' and easiest way to determine what font is used in an elm-entry from the elementary theme in use ( In python-efl, straight C code offers several ways of doing so not available in py-efl as far as I can tell). Another being trying to decide what to do about font families: The gtk Font selection dialog will display Sans and Serif for example in the list of fonts, these are not really fonts but font families so do not show up in my py-efl dialog (nor in enventers) and what font is displayed when a user selects say Sans will depend upon how the user has fontconfig set up. This is a design question for me more than a coding problem. Should I include Sans and Serif family in the font list or ignore it? If I do how about Cursive or other possible families? If I do decide to include it is it relevant to non-latin non-english users? Speaking only english and using only english locales I'm completely clueless about the latter.

 

There is also one or two other minor design choices I need to decide upon ... nor really worth going into here. 

 

So lets assume I decide on all the above solve what remaining issues my OCD nature is focusing on currently and add this code to to ePad (its intended usage). Then I will remove Beta from its description once enough users have tested it with a variety of fonts, locales, config options and whatnot that I feel fairly confident that it works at least as reliably as EFL itself.

 

Depending on my motivation and time availability it should be added to ePad within a week or two. Maybe sooner but I can't promise that and it seems unlikely thinking about my RW concerns ...

 

One more thing than should be noted updating epad in bodhis repos to include this font selection dialog is not as simple as simply updating the epad deb file. Python-efl deb files both 386 and 686 have to be rebuilt with Kai's patch added to py efl (see my first post here). Maybe also py3-efl debs file too. That in itself is time consuming busy work altho not really hard to do ...

  • Like 1

Share this post


Link to post
Share on other sites

Something I intended to do but never got around to was making it so when you toggled word wrap on it simply turned line numbering off. 

  • Like 2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×