Scratch Pad - Ideas, Features, Enhancements

Self-installing dependancy code

It would be really cool if FP could identify those python modules that it requires and, if they are not installed, initiate a procedure to go and fetch and install them!

The PIL bug with some fonts

PIL segfaults and python cannot stop it. Perhaps we can patch PIL, include the source code and have FP compile it on the first install?

Another idea I had about that crash; as one loops through each font file, just before the call to create a PIL object from it, write the paf of that font to a text file (say "lastfont"). After the PIL object is made, delete that file.

This way, should a font cause a segfault, when the app is restarted it can determine whether that file is still there, get the bad font's paf and display a dialogue to the user saying that font is dodgy and do they want to move it out of the way? ( And most humble apologies for the crash, most esteemed user :) )

GUIs

I wanted to make the gui code separate somehow so that we could create QT or GTK versions (other?) of the app for ease of installation. The basic idea was to have the app assess what the user was using and then fit that. I found, however, that I am too thick to abstract the code to that degree. Perhaps this is still a good idea, assuming someone can help us pull that trick.

Fontconfig issues

I have written about this to mailing lists and one or two blogs. It seems to be one of those "things" that will never be addressed until Gnu/Linux becomes more desktop-oriented.

Here is my short version: In my humble understanding of things, Fontconfig collects fonts. It makes them available to other things like the Gnome font chooser, for example.

Fontconfig (FC) keeps a list of every last font that is installed on your system. It is controlled by arcane config files which, like noodles, snake around various directories and point to stuff. All fine and well. The problem is that CONSUMERS of FC's lists do not include management filters -- you cannot choose to hide stuff from them -- and you are left with looooong font lists when all you want is the stuff you need right now.

This means an app like FP is of limited use *if* a user has done a lot of font installing. Even a standard install of something like Ubuntu comes with a really long list of fonts. All this clutters-up font choosers.

What to do? I am not sure. One of my nightmare projects is to lift the lid off the Gnome font dialogue and try to graft-on some management capabilities. This would render FP moot; anyway, I am not fast or bright enough to hack at that level.

Another idea is to create a font cleaner-upper (I wanted to call it a "fenema": cleanse your system of those unwanted fonts!) which will allow a user (with root permissions) to step through what FC supplies and literally tick each font that they want to hide from the system. This would be a temporary thing; hidden fonts would be either renamed or moved, but under the control of this app such that they can be brought back again by un-ticking them. Once the user is done, FC is told to update it's lists and, bingo!, a new, shorter list is produced.

Perhaps this interface could be included in FP -- a 'tools' menu maybe?

Tagging fonts

Baptiste came up with this idea and I think it's valid. For those users who want to tag fonts (if they really have that kind of time), a lot of work is already done to support this. It helps with filtering. Perhaps once a user has chosen all the "fantasy, bold" fonts, an automatic pog can be generated to contain all of them.

I am not 100% sure how to distinguish tagging from the act of collecting pogs in the first place.

Plugin system

Other ideas have come from Baptiste too. The 'font cloud' is one, related to his tagging code. It's like those tag clouds we often see on the net these days, but showing which fonts are most popular.

I am not saying the cloud should be optional, but it does make me wonder what other cool ideas there are and whether we shouldn't invent a way to plug them in.

The Interface

I confess, FP is fugly. The interface works for me, but I have had negative feedback and perhaps the way it's laid-out should be tackled.

There are two things I despise; drag and drop, and right-clicking. I intentionally left these out of FP, opting for a left-to-right kind of flow across the screen.

Still, if the opinion is strong, perhaps adding fonts to a pog should be a matter of right-clicking the fonts selected and then having a list of pogs appear in the context menu. Or (gasp) dragging them to a pog.

Sliding panels - I tried to allow the right-hand panel (the pogs) to slide (resize) but my wxPython skillz just weren't L337 enough. This would be cool.

In the About dialogue, I could not engineer a hyperlink to email that would work properly, I cheated and made a text box so that the email could be copied.

There should be a slider (or something) for quick resizing of fonts.

Perhaps the text displayed should be directly editable by double click on the fonts and just plain typing!

Shorcuts are horrible. The Esc key doesn't always escape -- it depends on wxPython voodoo and focus etc. I would like to iron those kinks out.

i18n

I started many little test apps to experiment with a few things: * Weird font names * Localisation and sorting in lists * General i18n of the interface. I have some initial solutions. * #1 Is a real problem -- often fonts are named using unicode or other systems and they can crash the app just by trying to open them! I suggest an "attempt read, attempt unicode, attempt decode, ask user to rename" approach. * #2 Is a PITA. I was helped by the fine people on the wxPython list and will submit some code to do this. It is, however, tied to #1 in that not all filenames are created equal. * #3 This has been started by Baptiste and I used his example to begin learning the GNU tools to handle this. It will mean some attention must be paid to where we use quotes and perhaps the strings module (string.py) should be extensively used to actually contain ALL printed strings -- just to centralise them.

Oh yeah, we will need a way to display the help file by language too.

Sundry Ideas

* Bold, Italic, Mono, etc buttons. More ways to filter fonts. * A font sheet showing many differing sizes of a font. * Font properties exposed -- whatever info we can drag out of a font should be available in some way. Perhaps by a property sheet. * Have some cool tools to actually generate font effects right there on the fly. We can hook into imagemagick (or use PIL) to let things like drop-shadows and colour be experimented with. * Save a displayed font to a file -- for quick use. * Baptiste (again) suggested (and wrote code) to generate a font cache. This could really speed display up. I say "could" because I am not convinced that picking up bitmaps is much slower than PIL just rendering the font. We could certainly test this. * Properly extend the app to OTF and Type 1. Others ? * Hey, just popped into my head, imagine a hook (via python) into Blender (or some Python 3D libs)! You could get a tilted, bevelled, 3D version of your string! Sweet. This I would file under 'plugin'.