2014-08-10

mtCellEdit 2.4

https://sourceforge.net/projects/mtcelledit/files/mtCellEdit/2.4/

This release includes work on cruft removal, code correctness, and conformance with the GNU standards for C and C++ (i.e. -std=gnu11 -std=gnu++11 -pedantic -Wall -Wextra etc. don't produce warnings with gcc 4.8).

I added the powerpc and mips Debian platforms to the test suite.  Just like the ARM hardware platform I emulate this environment using QEMU.  This is a nice way to test the portability of my code regarding issues like endianness without wasting time and energy using real hardware.

These test environments also allow me to ensure that the whole suite builds and runs well on less powerful hardware with slow CPU's and just 256MB of RAM.  This makes it easy to spot problems after code changes as the test suite would not complete correctly or would take a long time to finish.

I also added an optional safety feature to prevent accidental data loss when a file is edited by 2 programs at the same time.  See the handbook section A.9 for a full explanation of the feature.

I have also uploaded a new development version here:

https://sites.google.com/site/mtcelledit/

16 comments:

djing said...

Dear Mark Tyler

mtcelledit is a very valuable effort to offer a simple but powerful program for daily tasks

I started to using intensively to test in depth its core features

I have two annotations to do:

regarding the:

max column width

as shown in this sceenshot:
https://www.anonimg.com/uploaded-360381a3001f0a1e25c17941e4c4d75e.png.html

max column width seems to be limited up to 100 chars; this is a problem for people like me that are accostumate to store passwords longer than 100 chars

second (related) problem I found is that mtcelledit has no wrapping option for text in columns (this is a great help for longer texts, like passwords, especially once we can have a max column width greater than 100 chars)

can these changes be made? (if there is a way to change by myself, I'm happy to do the works in first person)

Mark Tyler said...

Hello djing.

Thanks for sharing your feedback about mtCellEdit. Judging from your screenshot, I agree that the 100 character limit is too small. I decided that 250 would be about right as this should fit most larger monitors.

I have just uploaded a new development version with this fix:

https://sites.google.com/site/mtcelledit/

The issue regarding text wrapping is sadly more complex. The philosophy of mtCellEdit is to always remain simple and lightweight, which means more complex features like wrapping cannot really be allowed into the program. The feature you describe is very useful, but it really belongs in a program like Gnumeric or LibreOffice Calc which is what I tend to use for that job. Although I use mtCellEdit for about 90% of my spreadsheet jobs, I still use heavier spreadsheets for heavier work.

In other words my advice is to use the most appropriate tool for each job, and try to avoid the idea of a single program monopolising all of your spreadsheet tasks. Each program has its own strengths and weaknesses relative to the other tools.

I hope you find the program useful.

djing said...

many thanks; with the help of grep I found the location of max column width

mtcelledit.h

:#define CED_MAX_COLUMN_WIDTH 250

in path

libmtcelledit-2.4/src/

so. I can build, if I need, binaries with greater value without to disturb you

I understand your words about wrapping; if I need wrapping feature, I can import mtcelledit files into Gnumeric or other havier spreadsheets

It is the same thing also for FILTERS?

like in portabase; assuming I have a list like this:

http://www.iforce.co.nz/View.aspx?i=e0malbkg.nug.png

and I want to view only people which name is Smith

http://www.iforce.co.nz/View.aspx?i=mvcn0bsf.ofx.png

We can create a filter for "Smith"; but, if it is too complex, also this can be done importing records in another spreadsheet, even if it would be very useful to have filters in mtcelledit itself (if not too complex to implement or heavy)

I built mtcelledit in puppy linux 3.01 with gcc 4.1.2. Compilation ended out without too many pains (I needed to comment some rows in a source file but I'll post accurate info in another comment)

finally, if you not know yet, I can recommend this site:

http://freshcode.club/

that replaces the death freecode.com that stopped software updates since june; many people using smart linux distro would be very interested to follow mtcelledit development trough freshcode feeds

Mark Tyler said...

CED_MAX_COLUMN_WIDTH is indeed the constant for the maximum width, so if you change that and rebuild everything you should get exactly what you require.

Filters are useful, but again they are too complicated for a lightweight editor so I won't be able to add that feature. I tend to use other spreadsheet programs or Awk to do those sorts of jobs. Section 5.3.1 of the mtCellEdit handbook has some useful examples if you are new to Awk.

If there are compilation problems please do let me know so I can try to solve them. gcc 4.1.2 is quite old, but it may be possible to accommodate it even though I am targeting the most recent 2011 C and C++ standards.

Thanks for mentioning the freshcode site. I didn't know about it so I shall look into using it now that freecode has stopped.

Mark Tyler said...

I've just posted details about mtCellEdit to freshcode. The site seems to function well, so hopefully it will be useful to people. Thanks again for the suggestion.

djing said...

Many thanks for your replies; I'm glad freshcode was useful, there are many people that are ACTIVE users of linux; opposed to PASSIVE users of BAD distro replicating the evil windows behavior, and that are very interested to discover by themselves little useful and unbloated gems of software, a thing that freecode made possible

regarding issues I had in building mtcelledit companion in puppy linux 3.01 with gcc 4.1.2, these issues were essentially two (one solved with a workaround, another not yet solved)

my first attempt to build mtcelledit stopped due to an undefined reference to

cairo_ps_surface_set_eps

that caused the break of compilation

So I

commented lines 2604-2609 in: libmtcedui-2.4/src/u_graph.c
commented lines 1110-1116 in : libmtcedui-2.4/src/u_render.c

and compilation ended out successfully building a fully functional mtcelledit (except for the feature to export to eps, but this is not a real issue, since I can easily convert to pdfd and then, from pdf, obtain an eps using pdftops with -eps switch)

i guess it is a lack of cairo_ps_surface_set_eps into cairo version bundled with puppy 3.01, I'll try to see if with a newer cairo it is possible to solve this little issue, but it is not really urgent or important, all the rest is fully working in program

the second issue (I was not yet able to solve) regards

mtraft (that I was unable to build)

I attach the compilation log (as far I can understand, it seems to be related to gtk version)
----------------------------------------------------------------------------
./configure --prefix=/usr && make && new2dir make install

--------
Raft 2.4
--------



CC = gcc
CXX = g++
YACC = bison -y
CFLAG = -DVERSION="\"Raft 2.4"\" -DBIN_NAME="\"raft"\" -DU_TK_GTK2 -I/usr/X11R7/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12
CXXFLAG = -DVERSION="\"Raft 2.4"\" -DBIN_NAME="\"raft"\" -DU_TK_GTK2 -I/usr/X11R7/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12
LDFLAG = -lm -s -lmtkit -lmtcelledit -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0
BIN_NAME = raft
BIN_INSTALL = /root/spot/usr/bin
BIN_CFLAGS = -pie -fPIE
TK_OBJ = tk_gtk2_main.o


set -e; for DIR in src; do make -C $DIR all; done
make[1]: Entering directory `/root/mtcelledit_src-2.4.5_20140823.131801/mtraft-2.4/src'
g++ tk_gtk2_main.o be_misc.o be_prefs.o be_scan.o -o raft -lm -s -lmtkit -lmtcelledit -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0
tk_gtk2_main.o: In function `delete_event':
tk_gtk2_main.c:(.text+0x79): undefined reference to `gtk_widget_get_window'
tk_gtk2_main.o: In function `tab_add':
tk_gtk2_main.c:(.text+0x12af): undefined reference to `gtk_cell_renderer_set_alignment'
tk_gtk2_main.c:(.text+0x12c3): undefined reference to `gtk_cell_renderer_set_alignment'
tk_gtk2_main.c:(.text+0x12d5): undefined reference to `gtk_cell_renderer_set_padding'
collect2: ld returned 1 exit status
make[1]: *** [raft] Error 1
make[1]: Leaving directory `/root/mtcelledit_src-2.4.5_20140823.131801/mtraft-2.4/src'
make: *** [all] Error 2

djing said...

any other lib or program was built without pains, only, for mtcedutils, I needed to use the configure script for slackware 12, since the other generic script, linked to libreadline and this caused abort of compilation, while configure script for slackware 12 in mtcedutils dir, allowed to build successfully the mtcelledit cli without linking to libreadline

since I use Puppy Linux 3.01 not for snobism, but because is fully fitted for my hardware and my needs, it is important to can have software that compile with gcc 4.1.2. Bad programmers (or programmers in bad faith), today, trend to use without valid reason the newest gcc features, breaking the retrocompability of code and forcing people to use latest distro releases (a very bad behavior)

Mark Tyler said...

I've just posted an updated version which should now compile on older systems:

https://sites.google.com/site/mtcelledit/

The raft program is cosmetically different, but should function the same as on a more modern version of GTK+2.

djing said...

Many thanks, now also mtraft compiles with gcc 4.1.2 in puppy linux 3.01

http://iforce.co.nz/i/jc1w0agm.rky.png
(screenshot of running program)

What do you think to provide, for stable builds, also UNIVERSAL BINARIES STATICALLY LINKED for linux? So these statical binaries can be virtually used into any distro and spread the use of mtcelledit also for users able to compile but with compiling environment having issues related to gcc companion (not the gcc executabler itself, but the libraries that come together) that cannot to be easily solved

(for instance, even if I been able to build everything regarding mtcelledit companion in puppy 3.01 with gcc 4.1.2, I had serious issues to build some apps from mtcelledit companion in puppy Linux 5.2.5 - codename "lucid" (this because I use different puppy version from time by time, and I'm beginning to be a great mtcelledit fan and I want to have mtcelledit in any distro I use and with statically linked binaries this is possible).

the issues I had are not mtcelledit programmer faults, unfortunately for me, there are several issues with gcc provided with puppy 5.2.5 and the only way to solve is rebuild all gcc companion (an undertaking task)

for this reasons, statically linked binaries would be very useful (only for stable builds in order to not stress the developer)

as you probably already know, there is a simple way, for a developper, to build a statically linked binary: this is the use of

magicermine
http://www.magicermine.com/

in their faq they say:
"We develop non-commercial open-source software and would like to create and distribute stand-alone executables of it. Can you help us?"

"We actively support Free Software and OSS. Please contact us"

http://www.magicermine.com/faq.html

I guess they talk about a FREE LICENSE of magicermine, if you are interested can contact them. It would be great to have STATICALLY LINKED UNIVERSAL BINARIES ready to use without requiring too much effort or lacks of time from developer

this, between other things, furtherly spread the use of mtcelledit

sorry for verbosity and thanks for the work on mtcelledit

Mark Tyler said...

I'm glad to hear that you have been able to compile things successfully.

Sadly gcc does occasionally regress with new versions. The best thing to do is avoid these bad versions, otherwise they will create too many headaches.

I'm not a big fan of statically linking big binaries. Many years ago I did think this would solve problems that users have with different GNU/Linux systems, but I think there are too many social and technical problems associated with such a venture. Most importantly I think this creates a huge issue in terms of security and trust. Downloading a binary blob from the web and installing it onto a system may be convenient, but this could be a security trap with very dangerous outcomes.

My own view is that there are only 2 options for safe distribution of software:
1. Binary package distribution via the OS vendor directly. The vendor will have all sorts of security measures to protect users from bad influences.
2. Source package distribution from the original author for full transparency and freedom for all concerned.

Naturally in the case of niche software like mtCellEdit the potential audience will always be very small and so distributions will not bother packaging the program concerned.

I should also point out that in the case of Debian, Arch and Fedora I do supply custom built scripts that allow you to build binary packages yourself and avoid some of the hassle of manual compilation. Building from source for each distribution you use would be my best advice. It may take 10 minutes of your time but you will be guaranteed that the software has no hidden problems that shifting binaries between different GNU/Linux systems will involve.

In terms of getting a wider audience for mtCellEdit I think using the the new freshcode site is probably the best approach. As you mention this allows active users to evaluate the software for their needs.

djing said...

Well. I understand your point of view, even if this leaves me and other Puppy Linux 5.25 users without mtcelledit until we discover a workaround for compiling successfully mtcelledit in Puppy Lucid (for this reason a portable stand-alone build with magicermine would be very useful)

it is not a big issue, for now and for me (I use the 99% of time puppy 3.01, but it is an issue)

however, I was glad to discover that a thing I wanted to be possible since many years in a light spreadsheet, not possible in gnumeric, as far I know, was very easy to do in mtcelledit files

I wanted to have rows with alternate background (to improve reading of values)

like this:

http://iforce.co.nz/i/hupqznnu.dub.png

made thanks io the easily manageble format that mtcelledit adopts for its files:

it was sufficient to wrote a simple iteration with the help of seq and printf:

for i in `seq 1 2 60`; do printf "{ \"cell\" \"color_background\"=\"16762880\" \"ref\"=\"r"$i"c1\" }\n"; done

and paste to prefs into prefs/book.txt once unzipped the mtcelledit file I saved and then re-zipping again

more relaxing than set the background for any row manually. this is a little gem I discovered and I shared for other mtcelledit users

Mark Tyler said...

Thanks for the suggestion about using a script to create interesting preferences. I hadn't thought about this sort of thing before, but its amazingly how flexible text based file formats can be.

For example, this demonstrates 'cedeval', one of the mtCedUtils command line programs:

PRGB=$(cedeval "rgb(255,200,0)" | awk '{print $3}'); for i in `seq 1 2 60`; do printf "{ \"cell\" \"color_background\"=\"$PRGB\" \"ref\"=\"r"$i"c1\" }\n"; done

By doing this it makes it very easy to see what the RGB value is at a glance. Putting PRGB inside the loop also makes gradients very easy to create:

for i in `seq 1 2 60`; do PRGB=$(cedeval "rgb(255/60*$i,200,0)" | awk '{print $3}'); printf "{ \"cell\" \"color_background\"=\"$PRGB\" \"ref\"=\"r"$i"c1\" }\n"; done

These scripts work with version 2.4 of cedeval, but I just uploaded the latest test version in which I have tweaked cedeval so awk is not required to extract the result:

for i in `seq 1 2 60`; do PRGB=$(cedeval "rgb(255/60*$i,200,0)"); printf "{ \"cell\" \"color_background\"=\"$PRGB\" \"ref\"=\"r"$i"c1\" }\n"; done

djing said...

you uploaded a new development version

mtcelledit_src-2.4.5_20140917.120853

on september 17

there are new exciting features, or only coding refinement?

Mark Tyler said...

There are no new features, just refinements to the programs internal workings to make them cleaner and simpler. Much of my planned to-do list is this kind of work (with the remainder being smoothing rough edges such as desktop integration and improving the newer Qt versions). It is perhaps a rather boring set of housekeeping jobs, but very necessary to make the program a little bit better.

djing said...

Hi Mark

I tried to compile latest mtcelledit dev build

mtcelledit-2.4.2015.0504.1127.tar.xz

As I written, previously, I was unable to build mtcelledit in Puppy linux 5.2.5 with gcc 4.4.3

This time I was able to build (I built mtcelledit also in Puppy Linux 3.01 with gcc 4.1.2 and old gtk2 libs), however, in both cases, launching the executable I had a bad surprise

in fact, the GUI resulted messed up

http://www.imagebam.com/image/d40ec7410188695

while in older builds (like the stable 2.4)

http://www.imagebam.com/image/5125e3410188702

the GUI was fine

How can I help to track the issues?

Mark Tyler said...

Hi djing.

Thanks for testing the dev version and reporting back with this issue.

I have reproduced the problem on my system, and have been able to resolve it with a bugfix. Test out the tarball mtcelledit-2.4.2015.0517.1537.tar.xz that I have just posted here:

https://sites.google.com/site/mtcelledit/

Try reinstalling everything, and let me know if this works on your system.