Angus Thinks

Category: SQLEditor

  • Dark mode canvas in SQLEditor

    Finished, see the blog post:

    SQLEditor 3.7.2

    🙂

  • SQLEditor javascript plugins

    There is some new sample code for writing javascript plugins on our shiny new organisation github page:

    https://github.com/malcolmhardie-software/SQLitePluginJavascript

  • SQLEditor 3.0 release

    SQLEditor 3.0 is ready!

    I’ve feel like I’ve been working on this for ages, so I’m really happy that it’s now ready.

    The most visible change is the new user interface, which has been merged into a single window. Single window interfaces are something that I wasn’t initially convinced by, I liked palettes and life was good. But since then, I’ve come to see the benefits of the single window. Keeping the panels in a relatively fixed position means that you know where they are. There’s also less busy-work managing the panels.

    The tradeoff is obviously that it’s less flexible and on a large screen it can lead to more and larger mouse movements. Feedback has generally been good on this, I don’t think there have been any complaints (so far). If you have an opinion on this please do send in comments!

    For me the most interesting new feature is the Javascript plugin system. Export dialects can now be written in Javascript. You can even edit them while SQLEditor is running and see the results immediately.

    The new plugin system grew out of the report generating code (also new in 3.0) which was targeting html and using a javascript template language. But then I started looking at this code and realised that there was no reason that export dialects couldn’t be in Javascript as well. The difference between a report and an export is minimal. Both take a data structure and return a string (or possibly a file).

    So far all of the built in dialects use native code, but my eventual plan is to convert them to javascript too.

    Early code for my own javascript version of the SQLite dialect is already up on Github and further progress is planned for this.

    There are lots of other improvements in SQLEditor 3 and I hope to write further about them soon.

    Or see for yourself 🙂

    SQLEditor 3 Download (58MB zip)

     

     

  • SVG Explanations

    Working on SQLEditor SVG improvements (arriving soon in 3.0), and found this excellent series of articles by Sara Soueidnn on several of the details.

    So SQLEditor in future will be using the same object icons in SVG as are drawn in the main document and each will be its own beautiful SVG symbol, rather than being separately drawn.

    (Object icons in SQLEditor 3 are now little images rather than being individually, because this improves performance quite noticeably and allows nicer styling)

  • SQLEditor 2.7 – the customizable object palette

    The newest and latest feature to arrive in SQLEditor 2.7 [55MB Zip] is a customizable object palette.

    For a long time, the object palette in SQLEditor has looked like this:

    Old Palette (pre 2.7)

    There were three fixed objects, that could be dragged from the palette into the document. The images have changed, but the basic functionality is little changed from v1.0, which also had a three object palette that worked like this.

    In version 2.7 though, there is a new palette, that initially looks like this:

    New palette in default mode

    It doesn’t look that much different at first, however it’s much more than it used to be.
    The biggest change is that you can now add your own items to the palette.
    To add an object, you can hold option (alt) and drag it to the palette.

    alt+drag

    SQLEditor create a new palette item, with a small preview of the objects. You can rename the item by double clicking on the label. Or delete it by right clicking and choosing delete.

    You can also add palette items from the clipboard. Add items to the clipboard using the normal cut or copy commands, then click on the small gear icon in the bottom left to see a menu. The New from clipboard command adds the contents of the clipboard as a new palette item.

    Or use the gear icon menu to add from the clipboard

    You can the use the new palette item just like the default ones. The palette item contains a copy of the original objects, so you don’t need the original document they came from.

    There are lots of possible uses for this, the obvious one is templates for tables. If you frequently create the same kinds of databases, you’re probably also creating the same kinds of tables.

    For example, there always seems to be a “user” table, with a fairly similar set of columns. In the above example the user table has been added and now we can instantly create a user table in a single action that contains the four important columns in every user table: unique id, first name, surname and shoe size. You can also set things like table type=INNODB, or set colors and styles (although not yet object labels).
    SQLEditor will save the objects and bring it out ready for use.

    You can also add groups of objects, including any relationships between them.

    This feature has been on the wish-list for some time, I’m glad it’s now finished and I hope that people will like it.

    SQLEditor 2.7 is available now via the in-app update system or from the website:

    SQLEditor 2.7 [55MB zip, 10.6.8+]

  • SQLEditor 2.5 – now with native database drivers and process separation

    I’m really happy to say that SQLEditor 2.5 [60MB zip]  has just been released. This has some interesting new features that have been in development for some time. Native database drivers have been something I’ve been hoping to support for ages, while process separation should improve stability and performance.

    Native database drivers

    SQLEditor 2.5 now includes native database support bundled with the app.
    Native drivers are bundled for SQLite (using standard sqlite), MySQL/Drizzle (using the Drizzle driver library) and Postgres (using Postgres client libraries).

    The native drivers don’t use Java at all, which gives a marginal performance improvement. Although if you’re using SQLEditor in standard, graphical mode you probably won’t notice.

    Native driver support means that SQLEditor should now be zero configuration for many users. Just install the app and start using it. This should be a big win, as opposed to finding, downloading and installing the JDBC drivers. It also gives a predictable and standard configuration to test, which should reduce bugs.

    SQLEditor still supports JDBC drivers as before, but if you definitely don’t require them, the JDBC driver loading can be turned off entirely.
    (Preferences->Database->Database Options->Enable Java (JDBC) Driver Support)

    Database process separation

    SQLEditor 2.5 now splits off database operations and anything involving Java into a separate process. This was primarily to provide more protection with native drivers, if they crash. However it also means that there is no Java VM running in the main process at all, which should make SQLEditor open an editable document faster from cold start. The worker thread is started, but can then load java separately, you don’t need to wait for this to happen.There is also better stability should JDBC driver discovery hang or crash, because this is running in a third process.

    Overall there are more processes, but it doesn’t seem to make that much difference memory wise. Plus Chrome does something similar, so SQLEditor is in good company (or so I’m hoping).

    The new version is available to download today:

    SQLEditor 2.5 [60MB zip, 10.6+]

    Alternatively the in-app updater should be offering the upgrade right now.

    Upgrading via the in-app updater also reduces the download size, because, in many cases, it only downloads the changes between versions, rather than the whole app.
    (thanks Sparkle)

    I hope that you like the new release, if you have comments or wish to report a bug please do email at support@malcolmhardie.com 

  • SQLEditor, SVG and Cocoa

    One of the new features in the latest SQLEditor 2.1 beta release  (v2.1.0b2, about 5.7MB) is SVG export. This allows you to create a diagram in SQLEditor and then export it to SVG format.

    SVG format is a vector diagram format that can be rendered by many web browsers or edited in vector drawing programs like Inkscape.

    Here is an embedded svg file:

    viewbox

     

    The neat thing is that if the image gets scaled it should scale fairly cleanly.
    (The lines get a bit fuzzy due to the anti-aliasing)

    viewbox

     

    Click on the image and you should see the file displayed full size (no separate preview image!)

    This should work in Chrome, Safari and Firefox. There are currently some issues with Opera which doesn’t draw the text. I think this is an error in the SQLEditor export code somewhere because I have some early test versions that do work in Opera.

    I haven’t tested this with Internet Explorer, but SVG is apparently supported in v9.

    I’m still fine tuning the details on this, the examples on this page were tweaked to include a defined view port so that they clip properly and don’t include a lot of white space. This should get done during the export in the next release.

    I’m hoping to write another post about how SQLEditor is doing this, it proved to be fairly easy, except for the difficult bits.

     

  • Using NSDockTile for debug info

    Often when I’m working on an app or something I end up running several different versions of it in a short period of time. There’s usually some bug that I’m trying to fix and I want to make sure that the bug occurs in the old version and doesn’t occur in the new version.

    Sometimes though I get confused which version I’m running. Is the app in the dock the old version, or the new version or something else?

    So today I had an idea: Why not put the version number on the dock tile?

    Here’s the code to do it:

    if (DEBUG) {
  id badgeText = [NSString stringWithFormat:@"D-%@",[[[NSBundle mainBundle] infoDictionary] valueForKey:@"CFBundleVersion"]];
  [[NSApp dockTile] setBadgeLabel:badgeText];
}

    This assumes that you’ve got DEBUG defined somehow and that you have an infoDictionary with the relevant keys and values set.

    And here’s what it looks like in the dock:

    Regular version on the left, development version on the right.

    I’m not sure how useful this will actually be, but it seemed a handy trick for development.

  • Versions, validateMenuItem: and NSMenuItem

    If you find when developing in 10.7 that you get a versions menu with a NSMenuItem as one of the items, it might be worth checking to see whether you’re correctly using validateMenuItem:

    This problem may happen if you return YES from validateMenuItem in a NSDocument subclass for menu items that you don’t actually control. (If you just return YES as a default for example)

    If instead you return

    [super validateMenuItem:item]

    You should get the correct “Revert to Last Saved Version” menu item

    I ran into this when I was doing testing on 10.7 and although documentation clearly states that you must call the super method in validateMenuItem: , it wasn’t immediately obvious to me what was causing the problem.

    Hope this helps if you have the same problem.

    Edit: This may have been fixed in OS X

  • SQLEditor upgrades

    One of the big questions I’ve been thinking about recently is how to price upgrades for SQLEditor. So far upgrades have all been free as 1.0 became 1.1 and eventually 1.7. But with the new 2.0 release appearing soon, the question is what should be charged.

    Personally I’ve been annoyed with products where I paid money and a new release appears two weeks later which requires a paid upgrade. On the other hand, SQLEditor 2.0 will be a considerable upgrade from SQLEditor 1.0 (the first paid version), so I do think some additional fee is justified to fund development efforts.

    But obviously I don’t want people who haven’t bought yet to have doubts as to whether they will be required to pay for the upgrade.

    The stated policy is that anyone who bought SQLEditor within 12 months of a paid upgrade being released gets a free upgrade.

    However given that the release date for the new version hasn’t been decided yet, I’ve decided to improve the arrangements for version 2.0:

    Customers who bought SQLEditor 1.x after August 1st 2010 will get a free upgrade to SQLEditor 2.0.

    This means that if you buy SQLEditor today you get 1.7.8 and when 2.0 is released you would get an upgrade to it free of charge.