The collected works of jimmer - Page 2

Hello All,

Just reporting back to the kermunniti about New Ted (Ted v2.23) on IRIX.

Over the past few weeks I've been in touch with its developer and he's been looking at the bugs I was seeing on IRIX. Turns out that the main culprit is the IRIX system iconv which is missing the 1252 codepage. This codepage just happens to be the default for RTF, which is what Ted uses as its native dataformat. The developer has a hack in place to fallback to the ISO-8859-1 codepage which IRIX iconv does support natively. That said, he's unhappy with it so he hasn't released it. When he gets back from vacation he'll be looking into a more permanent fix.

In the meantime I thought I'd share my kwikfixes for compiling New Ted on IRIX. It's from memory so I might have missed something.

1. Get GNU iconv off ftp.gnu.org and compile/install it. I did not check the nekoware version coz unlike Hamei I have a house rule that says this stuff goes into /usr/local/

2. Make sure your IRIX box has access to:

- Freetype2
- Xft
- Fontconfig
- libRender
- PCRE
- GCC

I probably missed one or two other dependencies but this list should get you started.

3. In the ./Ted source directory you'll need to replace

Ted/tedListTool.c
Ted/tedInput.c

with the ones I've attached to this post. They contain my hack for the X11 keysyms #include bug on IRIX. Once the developer gets back from holiday we'll get a proper fix in place for this too.

4. Run a 'configure' with the switches you need to point to /usr/nekoware/* and/or /usr/local/*. The compile run should work fine till you get to the link stage when IRIX ld will do the o32/n32 complaining that it does... Just dive into ./Ted/makefile and find the definitions of:

MOTIF_STATIC_LIBS=
MOTIF_SHARED_LIBS=

and change /usr/lib to /usr/lib32. Then call 'make' again to complete the compilation of Ted.

5. Run 'make private' and all being well-ish you'll end up with a binary that does word processing on IRIX with a Motif UI and modern font handling. Drop any TTF/OTF font into a directory that fontconfig keeps track of on your system and hey presto - it's available for use in yer Motif word processor. nom nom nom.

Enjoy,

J.

PS. If you do get New Ted up and running well enough to send Pymbles' granny a letter, you might also want to drop the Ted developer a Thank You email. After all, this is Motif software that does something useful and has a living, breathing developer behind it. Recently I've seen more hens teeth, unicorns and flying pigs.

He's particular about having his email posted freely wrt. junk-email, so get the details here: http://www.nllgg.nl/Ted/

And of course I forgot one of the main steps, telling the linker where to find your GNU iconv...

In ./Ted/makefile find

SYS_STATIC_LIBS = -L/usr/local/lib -lpcre
SYS_SHARED_LIBS = -L/usr/local/lib -lpcre

(your system may have a different -L path) and add -liconv to the end of both lines.

Sorry for the omission.

J.

hamei wrote: Exactly ! but ... umm ... jimmer ? You attached ted Link tool.c to your post

Oopsiedaisy... my bad.

J.

ehh... as far as I can tell, you haven't added -liconv to the linker switches yet.

I suggest you look for:

-L/usr/nekoware/lib -lpcre

in your makefile and add -liconv to the end of it:

-L/usr/nekoware/lib -lpcre -liconv

J.

jodys wrote: The Indy has a further advantage; it is fast enough to be usable for my purposes, but slow enough that I can't run anything even approaching a modern browser. I simply can't waste time on the web

Ah, if only redbox were fast enough to warrant months of work getting Singularity ( http://www.singularityviewer.org ) to run on it

Trippynet wrote: So, once again I'm unfortunately forced to ask the question "am I missing something ridiculously obvious"?

Ehrmmmm, have you tried Samba? It mimics a full-blown Windows file-server. It's a 'free download' and though it can be a little fiddly to setup, it works really well.

Cute nekogirl holding an O2. Basic blue matches that of an Indy. What's not Silicon Graphics-like about the forum theme?

hamei wrote:

jimmer wrote: Ehrmmmm, have you tried Samba? It mimics a full-blown Windows file-server. It's a 'free download' and though it can be a little fiddly to setup, it works really well.

Jimmer, unfortunately if you want to share from the Winnders and Orphans box, Samba only works the wrong way

Woopsiedaisy... didn;t read well enough. my bad.

tardist's are regular uncompressed tar-archives. simply untar them on your debian server:

tar -xvf rara.tardist -C .

Nice. Proof of that old adage: "Unix is plenty user friendly, it's just picky about who its friends are."

Hi All,

New project is underway. Still very early days, but we gotta start someplace.

What does it do?

Comix unpacks a cbr/cbz file and then displays it page by page via OpenGL.

Where is it?

http://sillypages.org/sgi/comix/

How do I make it?

0. Build and install my VkNew library
1. Unpack comix and modify the Compiler flags at the top of the Makefile to suit your setup.
2. Build comix.

Both VkNew and comix should compile cleanly with MIPSpro and GNU make.

If you want to have a looksey at the code, run the 'resume' script. It will load the relevant files into nedit for you. As ever, I disclaim being any good at writing C++, all I can say is that the code compiles for me on redbox.

How do I use it?

0. File->Open to open a cbz/cbr file.

1. [right arrow] or [down arrow] to go to next page.
2. [left arrow] or [up arrow] to go previous page.
3. [PgUp] to jump to the beginning of the 'comic'.
4. [PgDn] to jump to the end of the 'comic'.

5. Resize the window to force comix to display the whole page.

Major Caveat: the filename handling in Comix is fragile. In particular, jpeg filenames inside the cbz/cbr files with CR/LF stuck to their names, wont display properly. Fixing this is on the TODO list.

Dassit for now.

J.

foetz wrote: in case of a dso that's only used for one program a static build usually is better. jimmer might consider that.

Fair point. I have removed the dependency on VkNew. For extra Hamei Happiness this means there's also nothing going on in /usr/local anymore. Downside is that there's no pretty splash screen for the moment.

hamei wrote: The splash screen is nice, could you replace the Help -> Product Information with that or is that something we are stuck with ? I've always thought that the About screens in Irix were awful. $10,000 application and the About looks like some spastic kindergartener created it.

ViewKit giveth, ViewKit taketh away. I'm using the stock viewkit 'about' stuff. That said, it is possible to override the default ViewKit help menu. Issue added to the very bottomest bottom of the TODO list.

hamei wrote: However, at high resolution, I can't see an entire page. And there's no sliders ... not that I'd want sliders, resizing the page would be better.

I've changed the scaling and centering in 0.3.1. Please report back if this issue is solved.

Changes in 0.3.1:

- removed dependency on VkNew
- better image scaling and centering in the viewing window
- added a little statusbar thingy

Comix version 0.3.2:

- Core: improved filename handling
- Core: rewritten unpack/load routines
- Core: opens CBZ/CBR file where you left off
- UI: filename now shown in window title bar
- UI: page numbers centered under image
- Makefile: a little more quiet

The opens-where-you-left-off thing is a little slow at the moment when you restart comix after having loaded a large comic. This will improve when the 'load each image from disk' option is implemented.

Also there's a buglet with the pagination on the first and last images; the usual off by 1 thing. Hopefully fixed in 0.3.3.

J.

Not really. I'll move up the FTR+packaging bullet on the TODO list so the next 'progress drop' will be a full tardist.

Hello All,

Apologies for the delay in dropping a new tarball, blame Real Life(tm) and all that jazz.

Comix can now load an entire CBR/CBZ file into memory or be told to load each page from disk one at a time. The obvious advantage is that Comix might run a little better on low-memory machines. The less obvious advantage is that this code can now be used as a base for a generic image viewer. The downside is that page display will be slightly slower in the 'load from disk' case as each time you flip a page the image data needs to be loaded from sloooow disk rather than fst memory.

Next release will be mostly UI related things.

J.

Comix 0.3.3

- Reworked memory handling
- Preferences dialog
- Code clear-up

BetXen wrote: Hi J !

Thanks for this little piece of software that gives another interest to our old machines

I was thinking about another trick to make the reader's experience smoother in low-end machines. Would it be possible to add another file reading option, I mean that three pages could loaded in the memory: the current one, the previous and the next one ? In that case, transition to those surrounding pages would be faster when flipping pages, while keeping the memory requirement to a reasonable amount.

BX

You're v welcome!

When I added per-image viewing I did consider implementing the 3-file configuration you're suggesting, but I think to do it properly you'd have to use threads to read the files in the background while the main X event loop does its thing. Unfortunately, I have no idea how threads work. Or maybe workprocs, but I dont think that's what workprocs are for. Anyhow, it got too complicated and time-consuming for my tiny brain so I just blundered ahead with what we have now

That said, I did stumble upon an ugly bug in the file loading this morning. If comix doesn't have record of a previous CBZ/CBR file and you have per-page memory handling set, comix crashes when displaying a menu. The menu appears over the underlying opengl surface which forces a redraw, which currently needs image data to be present. But there isn;t any, as there's no record of a previous file. To make things worse, the menu-display crash happens before the file-dialog is posted so it's impossible to load a new file... It makes comix 0.3.3 significantly less useful than I had hoped it would be

Will be fixed in 0.3.4.

J.

Hello All,

This new version of Comix fixes the horrible menu display/file loading bug in 0.3.3 and introduces basic CBZ creation. You can now point Comix at a directory filled with JPEGs and it will compress those files into a shiny new CBZ.

Known bugs:

- random issues where unpack directory isn't cleared causing a newly opened comic to be 'added on' to previous comic.
- sometimes 1st page doesn't show properly, or Comix crashes on initial image load.
- CBZ creation dialog doesn't check hard enough whether your JPEG source directory exists or if your output name is sane.

Comix 0.3.4

- Menu display/file loading bug fixed
- Menus are now placed in overlay planes to remove image flicker
- Dialogs are _not_ placed in overlay places as they look horrible there
- Basic CBZ creation
- Option to wrap comic at begining and end
- Code cleanup

hamei wrote:

jimmer wrote: Et voila!

Are you a virulent anti-commonist, jimster ? 'cuz you're blocked by the gfw

Wow. A claim to fame. Not a virulent anti-communist, just some bloke with a webserver.

vishnu wrote: Jimmer, seriously, that chair? At least it would force you to get up and move around a lot because no one could stand to sit in it continuously, no matter how intense the coding session was...

That chair is actually a kiddie chair from IKEA, and it's there on purpose. I always set any swivvelly office chair to its lowest setting so that my back isn't arched as much over the keyboard and I can look more or less 'straight ahead' at the screen. Since adopting this low seating (many years ago now) I've never again had any issues with neck strain and backache after long sessions at the machine.

hamei wrote:

jimmer wrote: ... just some bloke with a webserver.

I guess we just don't like your kind, fella. Are you now, or have you ever been, a member of the Republican Party ?

Nope. Not a member of the GOP.

I have on occasion had tummyache after eating chinese food and may have had muttered some choice words referring to xxxxx and xxxxx and xxxxx and even xxxxx!

I guess Chinese SIGINT picked that up.

Hey All,

I'm taking an extended leave of absence from Computing as a 'Hobby'. It's been much fun around here these past 10 years, but I'm done.

Take care,

Jimmer.

For this i had to come out of retirement?

Couldn't Oskar45 and Hamei throw digi-mud at each other, whilst Foetz quietly provided a perfect solution? Sigh.

@pip - perhaps this might work on your desired platforms?

https://github.com/tweakoz/twilight

Hello All,

I've been working on some new icons, backgrounds and other miscellaneous pretty pretty for IRIX and now that I've come to the tardist packaging stage I realise I do not know what the canonical IRIX place is for 'vendor'-supplied images or artwork. We know that IMD application icons live in /usr/lib/images and that the default IMD backgrounds sit in /usr/include/X11/bitmaps/sgidesktop/. But I don't think the stuff I'm packaging should be mixed with the stuff that comes with the IRIX default install or applications.

So, where do we think this kind of stuff should go?

J.

Hi All,

I pulled apart my spare Fuel the other day and took the opportunity to take some piccies and make the backgrounds you can see below. The Fuel ones are 1920x1080 and the generic SGI (r16k cpu board) ones are both 1920x1080 and 1280x1024. I also got round to making an clogin icon for 'root' to match the EZsetup one I made a decade ago.

The tardist installs a little script each user needs to run to install these new backgrounds to the 'backgrounds' panel in their toolchest. After installing Pretty via the Software Manager, run

/usr/sillypages/bin/pretty

from a terminal prompt. Pretty is semi-clever about backing up your current $HOME/.backgrounds file before it adds the new background details. However, if you uninstall Pretty via the Software Manager you'll have to copy $HOME/.backgrounds.old back to $HOME/.backgrounds by hand. I guess I could automate that too but me lazy.

If you have a custom root icon the tardist does a similar backup thing and copies your current root login icon to

/.icons/login.icon.old

When you uninstall Pretty, Software Manager will restore your old root login icon.

Tardist is here:

http://www.sillypages.org/sgi/sp_pretty.tardist

Caveat: Tested only on my Fuel with a V12 and 4Gb RAM. No idea what these (large) background images may or may not do to X11 colormaps or memory on other systems.

J.

ah - nice catch How do i make a subsystem mandatory?

Donald_ET3 wrote: Does IRIX always come with a C compiler and Motif toolkit development files, or would it be better to use the Nekoware GCC and GTK+?

A set of IRIX 6.5.x installation disks always comes with Motif 1.2.x and 2.1.x libraries. If memory serves IRIX 6.5.30 ships with Motif 1.2.4 and Motif 2.1.32. Stock IRIX does not provide a C compiler with a working C/C++ front-end.

If you do not have access to MIPSpro you will need something else. In most cases that something else will be GCC. Because it's just there and because you dont want to suffer GCC-ism headaches. That said, in my experience 'portable' code these days means: GCC will probably compile your code on some Intel or ARM-based GNU/Linux distro. Other build-targets probably wont work unless you port the 'portable' code.

As to GTK+. Yes, it's used by the GIMP and Firefox and some other major projects but I'm sure that given the chance they would all be using something else. If you want to keep you code portable to Linux/FreeBSD I guess GTK+ is one way of doing it, but it's going to be painful on IRIX.

If you do end up coding with Motif on IRIX, probably because you want to stay true to the classic IRIX look-and-feel, you really want to look into using ViewKit. ViewKit is a C++/Motif application development framework that comes with IRIX. It takes away a lot of the pain of developing with Motif but like any other framework it does mean you have to code in The One True ViewKit Way.

Unfortunately, the MIPSpro-compiled stock IRIX ViewKit runtime cannot be linked with your GCC-generated objects because the MIPSpro and GCC compilers have different internal C++ name-mangeling schemes. There is an OpenSource clone of ViewKit called 'ViewKlass' which you could compile with GCC and thus circumvent the name-mangeling issue, but it's only 90-95% feature complete as it lacks some of the more advanced ViewKit widgets.

Bottom-line: If you want your application to fit in with the classic IRIX Indigo Magic Desktop look-and-feel then you have to go with SGI Motif. If you're going to code with SGI Motif you really want to look into ViewKit. If you want to use stock IRIX ViewKit you can only use MIPSpro. If you do some homework and figuring-outing you might also be able to use GCC in combination with ViewKlass.

Either way, I for one would love to see somebody else joining me in writing the odd bit of Motif-on-IRIX stuff

Good luck!

J.

Erhmmm... you're thinking of grabbing a POWER box to explicitly run FreeBSD... or do you just need a box to run some service or to function as a daily driver workstation?

If to run FreeBSD... perhaps a recent-ish SPARC box? On the other hand, you could just also admit that desktop hardware is x86. Over. Out. Done. Dusted. Buy yourself some new x86 junk, restore your backups and immediately start putting pennies into the when-shit-happens-again fund.