pfritz

August 14, 2008

What are the rules?

Filed under: elitaire — pfritz @ 12:10

After I put elitaire into CVS, and hence gave it a wider publicity, one of the first question was: “What are the rules of the game XY?” Most people know the rules of klondike, but some other games like Baker’s Dozen are unbeknown. So I had the plan to write a little help viewer for it for more than year.

And last weekend I’ve started to write one. First I was unsure what syntax I should use for the file format. For the writers html would be the easiest one, because almost every one has at least a little knowledge about html. So why didn’t I choose html?

  1. The help viewer is using ewl_text, so it suffers under the same limitations like Evas_Textblock does. Things like embedding images, tables and nice enumerations are not possible. I could only support a subset of html. Hence the author lost the advantage of knowing html, because he has to learn what he can use of the html syntax and what not.
  2. Html is tough to parse. If you have to deal with missing end brackets or misconstructions like this <em><a href=”…”> bla </em></a>.
  3. I don’t like html 🙂

Of course I could simply open the help page within a browser, but they are IMHO still too slow. I don’t want to wait some seconds untill I can see the help page.

How does the format look like? I have chosen a syntax that is inspired by tex, but much easier too parse. It has actually only one construction.

{\tag[parameter] text}

The parameter is optional, that means in most cases it looks like this:

{\tag text}

But also the text is optional, if you want for example a new line what is in html <br>, you have simply a new paragraph with no indentation.

{\noip}

The tags are very similar to the one of html:

{\h[x] text} is a header where x is a number between 1 and 6, default is 1. X determines the size of the header.

{\p text} is a paragraph with text.

{\a[url] } is a link

{\em text} italic text

{\st text} bold text

{\pre text} is a preformated text, it will not remove whitespace and the output is in monospace font

I still need to do some cleanups in the code and I haven’t integrated it in the elitaire code. But parsing and showing the text works already, even links :). And I need to write the documentation :(. Hopefully, I find a native-speaking volunteer, who helps me to eliminate my spelling and grammar mistakes.

August 2, 2008

Theme Specification

Filed under: edje,elitaire — pfritz @ 12:27
Tags: ,

Last weak I have finally written the theme specs for elitaire. I really didn’t thought that it’d take that much time to do that. But now it is ready and in cvs. I also namespaced the group parts, so new themes can now be shared on exchange. Hopefully it will lead people to write their own themes.

Here are some tips for those writing an edje based application. So you can learn from my mistakes.

  1. Use a name space for your theme groups. It used to unimportant, but now with exchange it is needed.
  2. Write a theme specification before or while your writing the c code for it. It is a hard to write it after your application is finished, because you need then to grep for all the relevant part names, groups, signals, etc. Writing the spec before you start to code serves you to get a consistent naming.
  3. Don’t write the theme specification with your own theme in mind. People can and want to arrange things different then you.

Of course I know that when you start to write an application you want something that works first, before you start worrying about things like theme specifications. But don’t forget to write it as soon as possible.

Blog at WordPress.com.