So, a few days ago I had an idea knocking around to make a Pomodoro timer. I’ve used Pomofocus every now and again but wanted to take a spin at it myself in VB. I was thinking of having it as a desktop application but then thought it’d be more fun to write it as my first proper Compact Framework application. I jotted a mockup down before going to bed, and got to implementing it today.

One thing I really like about Compact Framework development is its close similarities to Winforms. You get a designer (with the option to have a skin for any targeted screen size) and a subset of the controls you’re already familiar with. After about an hour and I had my first minimum viable product, something that could run within an emulator and on my phone. I even found out how to make those CAB installers.

Remember how I said that mobile development was really similar to Winforms? Well, that also means Compact Framework executables are more than happy to run under desktop Windows. (So long as you aren’t using any fancy device APIs, of course.)

A chunk of my time was then spent scratching my head and reading StackOverflow at how to implement playing sounds from the project’s Resources; I ended up giving up on that front, but was able to play the \Windows\Standard.wav sound and just do a system beep if that was not available (Desktop). Couldn’t have the pleasant sounds from Pomofocus unfortunately, rather a smidge loud beep sound. Perhaps later down the line.

• 

• 

• 

• 

• 

• 

Here’s the final version. I had polished up the UI by adding the arrow indicators on both sides of the screen when the timer is stopped, and replacing the mainMenu control with my own Start/Stop indicator label. All of these have Click events so they’ll work on desktop and Pocket PC. On desktop you can also start with Enter and switch modes with the keyboard using the same key codes internally as Windows Mobile. Convenient!

As I was making a release on GitHub, I found out I could actually target older platforms all the way back to Pocket PC 2003 (a touchscreen platform) without losing support for Windows Mobile 6.1 Standard (a non-touchscreen platform). I had thought that it would refuse to run, but it just worked. That was really cool to see.

I’m very happy with what I got done in the end. One more crossed off my idea list, and something I can really see myself using.

Oh right! You can find Tomate on my site or GitHub. Send feedback and help out if you wish. The CAB’s for installation on mobile devices, and the exe file will work on desktop. Check the readme if you need prerequisites.

(Sidenote: I’m not sure why Visual Studio packages with the CAB extension, uppercase. Alas, possibly one of those fabled Microsoft mysteries we’ll never solve.)

It’s been forever! The last devlog was all the way back in early April, before I quietly released RC3 in May. Since then AutoSite’s stayed mostly put while I’ve tried out other things. That said I’ve got kicked back into my stride and work goes on.

Quick Insert

A brand new menu has been added that can be brought up with Control+Space or Control+J that gives you a quick list of attributes you can reference and define.

Tidying and streamlining

Some dialogs and message boxes are being revised somewhat to be (I’m hoping) clearer. These include the phrasing in the message box that comes up for a Sanitary Build and the Insert Conditional dialog.

New conditional help text has been brought to the Quick Insert menu, making the old dialog explanation a little redundant:

If you have any suggestions for how I could improve this further, let me know.

Minor editor tweaks

The editor will no longer automatically indent existing lines. This got annoying for me and maybe other people too idk

Testing it for yourself

I don’t remember if I actually pointed this out before in a devlog, but I’ve got AppVeyor set up to build AutoSite whenever I push out new code. What this means for you is that you get to test stuff out on the bleeding edge today! Seeing as I’m currently torn between a new RC and waiting to release a final version 1.0 (I’ve still got some plans before then), the next release may not be for a while.

Everything’s packed in a zip file just like a normal release. Just grab autosite_nightly.zip at http://ci.appveyor.com/project/dotcomboom/autosite/build/artifacts. Remember though that fresh builds can be buggy while I’m working on stuff.

If you run into troubles or just want to suggest something, I’ve now set up issue templates on the source repository. If you don’t want to use them that’s fine too.

You can now grab the absolute latest AutoSite development build on AppVeyor. This has the latest features/fixes/bugs but does not represent the final RC. Everything that is included in a regular GitHub release is included here, including Core and Windows 10 metadata.

Feel free to grab a testing copy of RC3 and let me know what you think.

23 days without a devlog! But rest assured that RC3 is coming along, and it could be one of the largest RCs yet.

Start Page

A basic startpage has been added for when no sites are open. This replaces the “create or open a site folder” message in earlier versions:

It displays the Create or open a site folder option alongside your recently opened sites. I wouldn’t consider the design finalized just yet, but it serves its purpose.

Known extensions added

More extensions have been added; these are now editable and render without Apricot asking to make sure:

• phtml (an alternative, lesser-known extension for PHP)
• gophermap

Additionally some fixes were made to accommodate for gophermap being, well, not an extension.

The Great 2010 Migration

Visual Basic 2010 Express Edition is now being used for development, stepping up from 2008. For the foreseeable future .NET Framework 2.0 will still be targeted, though 4.0 is a possibility should the need arise.

Fun fact: did you know registration still works for 2010 Express? It does! No need for registry hacks to keep the Express trial period from expiring.. at least while it’s still up.

in/ renamed

The in/ folder has been renamed to pages/. AutoSite will prompt to convert a site with the old format.

Build panel updates

A button for running a Sanitary Build has been added to the right of the regular build option, which is now captioned to make it stick out more.

Quickstart

A new Quickstart dialog has been adding to hopefully make the AutoSite Method™ (patent pending) seem less daunting to first time users.

Removed features

Please pay your respects for:

• Pack installation, which was introduced in RC1. Although the feature worked, it made AutoSite unable to launch on older versions of Windows due to using a shell32 interop to extract archives. Although it may come back in the future, it’s disabled for now for the sake of compatibility.
• Legacy AutoSite build support. This was a tricky decision but I decided that it’d be for the better to streamline the build process, and it relied on a pyinstaller-based binary anyhow.

AutoSite Core on Visual Studio Code

I’ve gotten AutoSite Core to run as a task in Visual Studio Code. If you’re into that, have a peek at this wiki page.

Escaping attributes and conditionals

I’ve implemented a new thing that’ll be coming to RC3 pertaining to escaping attributes and conditionals. It’s ultra-helpful for documentation, as I have had issues before in trying to keep samples from being processed by Apricot. To escape, you’d add $ to the start of it.

$[#content#]
$[path=index.md]Escaped conditional[/path=]

To compare, here’s what you would’ve had to do before:

<span>&#91;</span>#root#]

Ich.

4/6/2020 – hahaha future dcb here! this broke my photography page that uses php so I removed this. sorry!

Modified dates

Yes, modified dates in AutoSite now! [#modified#] will spit out a date according to your system locale settings. I’ve been using this currently on my site.

Multiple display bug fix

There was a bug where if you had AutoSite open on a second monitor (or even just a higher-res display) and closed it, then reopened AutoSite where that point was not a part of your display setup, the window would be stuck off-screen with no easy way to bring it over. This drove me mad so I fixed it. 8)

Cheat!

I had actually started on this about a week ago, got tired and then accidentally slipped into a Neopets obsession. But I still have made a bit of progress with it.

Here’s an early screenshot from the 18th, when I wrote both of the current pages on [#root#] and [#path#]:

On the 19th, I added a nifty warning, since classless.css, the light CSS framework I’m using, has some basic card stylings baked in and I tacked on some more CSS for flavor.

After a short period of inactivity that brings us to today, where I hacked on classless.css a bit to give it a more characteristic theme, and I. (Zoomed out for the screenshot.)

Only the [#path#] and [#root#] entries have been written as of right now, and it’s all still very much incomplete. I’ve yet to figure out quite where to go with it and how it should be organized, though the styling part’s almost covered, featuring that small thing with the footer I’ve been wanting to do forever with an Apple iWeb-esque silhouette to say that hey, this was made in AutoSite.

I should say, one annoying thing about writing this was getting attributes to escape properly for the input examples. Using HTML escape codes like [ for [ would have easily kept Apricot from replacing it in an HTML document, but due to how I have CommonMark set up to process Markdown files internally, what would happen is that by the time Apricot came to start replacing attributes, the Markdown parser would have (for some reason that’s beyond me) replaced the escape codes with that they represented, meaning that Apricot would treat the examples like they were actual attributes. Annoying, and there’s little I can do about it.

How I worked around it was by starting the line with HTML, which kinda bypasses the Markdown preprocessor altogether. It’s a.. little messy, but it’ll work.

All this is now up on the Github repository, so changes going forward are incremental. I added the output folder to the .gitignore so it doesn’t get messy.

Sooo I just released RC2

System icon improvements, Explorer hottracking

I resolved an issue that had plagued loading file icons since I first implemented it for RC1. What happened was that when you select a node it just goes to the default node icon (which is the folder icon). The way I resolved it was really as simple as loading the icon before setting the ImageKey and SelectedImageKey things instead of after.

On top of that, I also made it so new files added would get their icons loaded as well, wrapping up the implementation of the feature. I’m confident enough in it that using system icons is now the default.

Also notice that nodes in the Explorer have a hover effect like hyperlinks. In Winforms this is internally called hottracking, and while it doesn’t really do anything I think it looks nice.

Minor About box change

For the sake of having something more here, the icon in the About box is now gone. Here’s a fun comparison between it and Notepad’s:

Where to get RC2

Github or my site. Here’s the changelog:

1.0 RC2:
   + View Output in Default Browser added to editor
   + Pages and Includes can be dragged into the editor as paths from [#root#]
   + Site Tree node hover (hottracking) effect
   + Numerous system icon improvements
       - Load File Icons rephrased to Use System Icons
       - System icons switching to a folder icon when selected has been fixed, as well as 
       - Newly added files now use system icons properly
       - System icons are now used by default
   - Markdown [#root#] links in previews are now rendered out properly
   - Start menu tile small icon fixed
   - More About box tweaks
   - Preview button text is now "Preview" for pages, "Debug" for templates, and "View" for include files

The good fixes are the short fixes

So, it seems that around the time I released RC1 I did a bunch of reworking with the way Apricot walks through the input page folder. I had noticed that it had started processing files multiple times in the same run. Turns out that had been a borked fix, where I slipped in an extra few lines that ended up repeating what Apricot was to do.

As you can see in this commit of when I fixed it, the mistake was running the walking process for each subfolder.. after all of the files had already been found through a recursive search (.GetFiles(pattern, SearchOption.AllDirectories)). All I had to do was comment out those three lines. It was a rookie mistake.

Unknown file types

I added unknown file extension checking to Apricot, meaning that when you do something like slip an image into the Pages folder it will throw a dialog prompt to make sure that it is indeed a page.

AutoSite Core behavior is just continuing as normal with a warning, which is also displayed in the log in the AutoSite interface if you choose to continue:

The warning nor dialog will show if the file is a dotfile (starts with .) or doesn’t have an extension. The extensions list is this, which is shared with the editor in the AutoSite interface:

txt
md
css
ts
js
html
htm
php
xml
json
csv
lass
sass

Prompt layout improvements

The prompt that shows up when a site isn’t open has been around for the longest time, and for the longest time I haven’t been able to get aligned quite right. Now, I’d say it’s pretty alright. Additionally, a new brief description of the Attribute Map has been added when it’s empty. I’ve found it a little difficult to explain what it is to people, so hopefully that’ll aid a bit. Rather pleased with how these came out.

Editor clarifications

For a little bit, I thought of disabling the Preview button for templates, as it only previewed a skeleton of the page without any includes or Apricot support.

In the end I decided to clarify the text a bit instead, and it’s now called “Debug” for templates and just “View” for include files.

A dilemma

I’ve known about this issue with Markdown pages for a good, good while, all throughout the time I had the microblog in fact.

What happens here is that the library I use for parsing CommonMark markdown really doesn’t like spaces in paths, so it won’t render it out to an a tag. Initially, I swapped the backslashes for forwardslashes to no avail, and then I swapped spaces for %20 encoded spaces. Which, at first, appeared to work.

If local Then
    newHtml = newHtml.Replace("[#root#]", (siteRoot & "\includes\").Replace(" ", "%20"))   
    content = content.Replace("[#root#]", (siteRoot & "\includes\").Replace(" ", "%20"))
Else
     Dim root = FillString("../", CountCharacter(filename, "\"))
     newHtml = newHtml.Replace("[#root#]", root)
     content = content.Replace("[#root#]", root)
End If
```

The problem? The encoded spaces messed up the paths used in actual HTML tags for embedding images, stylesheets and whatnot.

I’ve still yet to resolve this, but I’m feeling what could work out is that Apricot could run some RegEx like [.*]\((.*)\) to selectively encode the spaces in the paths that are in Markdown links and images.

Hi while writing this I realized that the problem was really just that I should’ve written a proper file:/// url, cool

…And that means that four issues were closed on this very day. (Or, these two days, since it’s already tomorrow.) Time to rest easy. See you in the next one.

o7

Since its inception, w2krepo had lived on my personal dotcomboom.somnolescent.net domain. I’m excited to announce that it now resides at w2krepo.somnolescent.net.

Moving the files was fairly painless, as the subdomain had been set up under my current FTP account. What was next was redirecting the old URLs to match the new domain, also fairly simple when you get down to it: just this .htaccess file in the w2krepo folder:

RewriteEngine on
RewriteRule ^(.*)$ http://w2krepo.somnolescent.net/$1 [R=301,L]

That left one thing: trying to get my root directory on the subdomain to display the builtin Apache directory listing was a bit problematic, so I settled on using a basic PHP script scraped from what I could find online:

<?php
$fileList = glob('*');
foreach($fileList as $filename){
    if(is_dir($filename)){
        echo '<a href="', $filename, '/">', $filename, '</a><br>'; 
    }   
}
echo '<br>';
$fileList = glob('*.7z');
foreach($fileList as $filename){
    if(is_file($filename)){
        echo '<a href="', $filename, '">', $filename, '</a><br>'; 
    }   
}
?>

It’ll work as a root for now, and I intend on messing more with .htaccess to get the subdirectories’ listings all prettied up as well.

For the future, I intend to get some sort of system up for user submissions, whether that be by anonymous FTP or an upload form, as well as some more information on the indexes and homepage.

One of my more long term plans for AutoSite was to get it localized and eventually used in more languages. I’ve worked a little bit on this, and now have a system coming together.

In .NET Winforms, there’s a property you can check to generate localizable code in your project’s .resx files. All that I had needed to do to start making AutoSite translatable was to check it in each form. Now, AutoSite’s .resx files can now be edited for any string (or really, any property as I understand it) on the form.

While I could do localizations all manually in the Resource Localization Editor or Visual Studio if I wanted to, it’s not the most effective workflow nor very intuitive or open for contributors. So I looked into both PoEditor and Crowdin, two options that seem to be popular in the realm of GitHub. I eventually settled on Crowdin, for its completely free tier for open source projects and ability to use machine translations or “TM”s, or translation memory gathered from other projects on the site.

Setup was straightforward and aside from some encoded images (used for the Visual Studio 2017 and Windows XP icon themes) that I needed to hide, it all showed up flawlessly, allowing me, and anyone who would want to contribute, to edit strings for just about any language under the sun.

I already have 100% of the controls translated through TMs, Crowdin’s machine translations and mi Español mal. What this means is that there is something I have to test with and a proof of concept. It’s not.. good tacospeak, probably by any stretch, but it’s something to test with and have open for contributions.

As for when I get to implementation, what’s next? For one, figuring out how to get these translations in the program with a way to switch between them, and additionally hopefully moving strings used for message boxes out of the source code into the .resx file so all of that could be managed from one place, not only for localization but also just in good practice: currently, all of AutoSite’s dialog messages are just in the code, like this:

If MsgBox("AutoSite will create a site in the folder located at " & path & ". Is this OK?", MsgBoxStyle.Question + MsgBoxStyle.OkCancel) = MsgBoxResult.Cancel 
    Exit Sub
End If

I believe moving this text into the .resx resource files will not only help with translations, but also keeping all the wording consistent and easy to update.

There’s the plan so far; expect more progress updates in the future.