Html SymboliZe / Blog: Recent posts

• Moving to GNU Autotools
• Adding support for reading and (maybe) writing to pipes (command-line version only)
• Adding command-line version to releases for Mac OS X
• Fixing Line-endings on Mac OS X version (sorry, I didn't have access to a Mac until very recent, so I had no idea that they were incorrect)

I have removed 'extras.7z' from the available Files, and will no longer be updating it or even developing the C port of Html SymboliZe. I have also decided to stop developing the command-line versions of Html SymboliZe after this upcoming release (version 20.1*). I will continue to develop Html SymboliZe's GUI for now.

• Changing Html SymboliZe's versioning schema:

  (Major)(minor...)((stage)).(changes/revision/patches)... read more

I may add support for unicode escapes--so that they'll be transformed into their corresponding characters--in future releases.

Here are some of things on my TODO list for version 2.0.1:

• removing future dependencies from hsz.py and unhsz.py (e.g. using the legacy version of print instead of the python3 version)

• removing unneeded imports from hsz.py and unhsz.py

I'm migrating Tickets to my Bitbucket repo for Html SymboliZe. I just like how Bitbucket has their Issues thingy setup and its format and that kind of thing better than Sourceforge's Tickets.

Release Notes

Version 2.0.0

---

Linux

• xhsz.py
  • (aboutmenu += m_Bugs; OnBugs +): New menu item, contains contact info
  • (ond, one): renamed to OnD and OnE, respectively.
  • (decode +- transcode.decode, sfilter +- transcode.processor, encode +- transcode.encode; OnD, OnE, OnClear): Fixed a bug that prevented the decode button from clearing the text area's contents when said contents consisted of--at least--a single space.
  • (license +- info.license, version +- info.version, Version, License): provide the same support for xhsz.py that info.py provided.
  • (- lookfor): No longer requires external python modules (wxPython is still a dependency).
  • Added lots of comments.
  • (OnStat; defs +): Replaced most instances of True, False, or debug (in the context of determining whether to print debugging info) with defs.debug

... read more

The extras.7z file located in Files contains some of the stuff that I have used in or was going to use in Html SymboliZe. This includes:

• The port of Html SymboliZe from Python to C/C++ (command-line only)
• The graphics used in Html SymboliZe (minus the hsz.ico file, which can be found in the windows version of Html SymboliZe)... read more

I haven't forgotten about the Windows version of Html SymboliZe--although I have been a bit more interested in the Linux release as of late. Despite the amount of time I've been devoting to the Linux release, I have managed to take some time and start working on some basic documentation for the Windows release, which will hopefully be a major part of the next and, for now, final release of Html SymboliZe for Windows. ... read more

Well, so far I've managed to port both hsz and unhsz to C/C++ (C for hsz, and C++ for unhsz) and I'm in process of porting xhsz (the linux graphical user interface) to C++ and Qt--I was going to use GTK+, but I couldn't figure out how to get it to compile correctly and there only seems to be the one tutorial for it. I think that I'll go ahead and re-release the pre_gamma of Html SymboliZe so that Linux users will be able to enjoy the fixed icon and stuff like that without having to switch to the new GUI, which may or may not appeal to some. ... read more

I'm in the process of re-writing the Linux version of Html SymboliZe in C--including the GUI--, and so far I've managed to create a working implementation of hsz, but I can't even think of how to approach unhsz at the moment. So I've decided to go ahead and deploy this pre_alpha release in the meantime. I haven't uploaded the tarball yet, but as soon as I get the Makefile ready to go and everything, then I'll upload the new tarball. ... read more

Well, after some thoughtful consideration I've decided to go back to using Makefiles because using Rake is nice and all, but it's just such a headache to wrap my head around and I already understand Makefiles pretty dang well.

I had to temporarily remove the pre_gamma release for linux, I forgot to make a few necessary changes in the hsz.py and unhsz.py files, which I only realized that I had left out when I tried to run hsz on Arch Linux, after the install, and received an error message saying that hsz couldn't find info.so. As soon as I get everything set I'll reupload the pre_gamma release and everything'll be back to normal. ... read more

I'll be rewriting Hsz's Makefile as a Rakefile during this, and possibly next, week.
Scratch that. I've rewritten part of Hsz's Makefiles--the part that I use to automate the release process, that is packaging the files into an archive--as Rakefiles, but I going to write a very basic Makefile for the Linux version in order to let Linux users install Hsz by simply running

    make DESTDIR=<dir> install

I'm in the process of transitioning from BSD licensing to GPLv3 licensing, so if you see a file or something that mentions that it is protected by the BSD-whatcha-ma-call-it license that can be read @ folder x, no worries. Everything will be updated in the next release, that is version 1.12.1

Tomorrow I'll be taking some time to go down to a nearby community college where they have a Mac--I was down there this past Friday, but I didn't have enough time to do much other than to try and get hsz to run. I know for a fact that the command-line version of hsz seems to run fine on their Mac, but I don't know if the GUI will work--I recall that there was some kind of issue with wxPython running correctly on the Mac.

I've decided to go ahead and use Apache Ant with another project that I'm just starting and if all goes well and I like what I see then I will be switching hsz from GNU Make to Apache Ant.

Assuming that I can even get Apache Ant to build Hsz--at this point, I'm not even sure if Ant supports anything but java-based projects.

Here's an excerpt from the release notes for the Linux version:

Version 1.12b.0
    + Added cut, copy, and paste items in the edit menu.  
    - Removed Boxsizers.  
    + Added GridBagSizer
    * Repositioned things slightly.  
    + Added some new functionality to the undo and redo menu items--that is, they can now grey out.  
    + Added clear menu item to edit menu. 
    + Added a taskbar icon/favicon thingy.  
    + Added a debug submenu to the Help menu
        + added Stats to the debug submenu

• • *... read more

Now that I've added an edit menu to the gui and changed the about dialog, I'll be uploading new screenshots soon to reflect these changes.

Things have been pretty hectic feeling for me today, what with suddenly creating a Mercurial repo and trying to get that all setup and everything--I've decided to go ahead and go through with the return to using an external link pointing to my Bitbucket repo instead of a local sourceforge repo for a handful of reasons:

1. I, presently, have three repos containing hsz's source code--this is just ridiculous, confusing, and it makes me feel extremely stressed out, mainly it's just way too much for me to focus on all at once.
   
   
2. I won't have to worry about where I put my documentation. I can have all of my READMEs in the same directory as long as I have a master README.md in the same directory to act as the weclome-mat.
   
   
3. I won't have three repos anymore--instead, I'll only have two:
   a. a git repo containing hsz
   b. a mercurial repo containing hsz... read more

Okay, so I will be reverting back to using bitbucket as the code hosting what-cha-ma-call-it--its just too hard to have two repos in the same local directory. And I don't want to have to duplicate data just so that I can share it with two repos.

Okay, I admit it, Mercurial is really really nice. I never have to re-add a file after I've changed it, and although I haven't figured out how to remove cached changes, like you can in git, without removing the actual file--I'm still considering switching, at least, my public releases bitbucket repo over from git to mercurial.

I may soon resort back to using my bitbucket git repo for hsz. I just don't like how I have to rename or move every single file named README--in bitbucket README.md files take precedence over README files, so you can have both a README and a README.md and the README.md will always be the one that is displayed.

But, I suppose this is more of a Sourceforge problem than an mercurial problem. I kind of like Mercurial, though it is still too early for me to tell for sure, all I ever have to type when I want to push updates is hg push

I'm considering opening up Tickets to anonymous users, that is people that don't have SourceForge accounts or who aren't logged in. My only concern is that people keep it professional and that things will get out of hand, but at the sametime I feel bad for people that just want to let me know that something isn't working but don't want to sign up for a sourceforge account...

To address the gui-bug-issue-thing (see Tickets for more details), I'll be re-writing the Windows version using python's built-in Tkinter toolkit-thingy, and if I don't like how Tkinter looks under Windows then I'll probably end up just writing this using PyQt.

I could use help with testing hsz on Mac OS X. I don't have access to a Mac at the moment, and anyone willing to try to get hsz to run on Mac, who will document how they did it, and email me about it will be appreciated.