The blog of the developers of Vienna, the free and open-source Mac OSX newsreader.
Sunday, February 05, 2006
Starting on 2.1
Now that build 2025 looks to be the final release build of 2.0, I've decided to make a start on coding on 2.1. As always, crucial bug fixes to the 2.0 code base will take priority. However I expect that to be done to the 2.0 branch while 2.1 will remain separate other than porting across the 2.0 bug fixes as appropriate.
So first out of the gate: 2.1 is Universal Binary by default. That means SQLite is rolled into the build as sources rather than as a static library. (And, before anybody asks, the reason I'm not using libsqlite.dylib is because that is only available on 10.4 and later). The other external dependency is support for Growl and now that 0.7.4 itself is supplied as a Universal Binary, I've upgraded to that. So now 2.1 should build and run on MacIntel machines as native i386 code.
The other change I've added is support for pop-up window blocking in the tabbed browser. By default, all pop-up windows are blocked unless the "Block pop-up windows" setting is turned off in the General Preferences. The Alt key can be held down when clicking on a link to override the current setting.
And I've added separate "Ascending" and "Descending" commands to the end of the View/Sort menu to explicitly state the sort order. In 2.0 you toggled between the two by selecting the sort column again. This confused some people.
None of this is in CVS yet. SourceForge have finally got around to supporting Subversion and that is due for release this month. So the 2.0 and 2.1 codebase will be migrating to Subversion as soon as it is ready. Instructions for enlisting will be on the Vienna developer web page and thanks for Subversion's support for file links and libsqlite3.a going away, the enlistment instructions will actually be a little simpler than for CVS.
So that's where we're at right now. No big changes in the UI yet. That, along with sync support, needs more up-front design work and planning first.
So first out of the gate: 2.1 is Universal Binary by default. That means SQLite is rolled into the build as sources rather than as a static library. (And, before anybody asks, the reason I'm not using libsqlite.dylib is because that is only available on 10.4 and later). The other external dependency is support for Growl and now that 0.7.4 itself is supplied as a Universal Binary, I've upgraded to that. So now 2.1 should build and run on MacIntel machines as native i386 code.
The other change I've added is support for pop-up window blocking in the tabbed browser. By default, all pop-up windows are blocked unless the "Block pop-up windows" setting is turned off in the General Preferences. The Alt key can be held down when clicking on a link to override the current setting.
And I've added separate "Ascending" and "Descending" commands to the end of the View/Sort menu to explicitly state the sort order. In 2.0 you toggled between the two by selecting the sort column again. This confused some people.
None of this is in CVS yet. SourceForge have finally got around to supporting Subversion and that is due for release this month. So the 2.0 and 2.1 codebase will be migrating to Subversion as soon as it is ready. Instructions for enlisting will be on the Vienna developer web page and thanks for Subversion's support for file links and libsqlite3.a going away, the enlistment instructions will actually be a little simpler than for CVS.
So that's where we're at right now. No big changes in the UI yet. That, along with sync support, needs more up-front design work and planning first.
posted by StevePa # 6:33 AM 
Comments:
<< Home
I've been thinking about the item on the wishlist to have Cmd+Enter open the current page in the opposite of whatever is set in preferences. That should be easy enough, but what do you want to do with the Article submenu of the main menu? If there is a way to override the preferences, you probably want a menu item for it. Would you want 4 menu items for opening article/home page in Vienna/default browser? The problem is that this is not the usual case of an item with a command-key shortcut, where you could have the alternative action show up in the menu when pressing the option key.
P.S. I ask because I'm thinking of coding this myself. I'd like to do the keyboard shortcuts, main menu, and contextual menus (in the various views) at the same time, so that they can all basically use the same methods.
Hmm... Didn't see your earlier comment for some reason.
I don't like the idea of 4 menu items that all do similar things. I suspect that most users will prefer to stick with whatever they've set in the preferences and only occasionally employ the shortcut to divert to the alternative approach such as when a home page is more complex than Vienna's built-in support can handle. So the challenge becomes how to make this sufficiently discoverable without overloading the UI?
I haven't spent much time thinking about this but Vienna does have a high bar for usability and UI simplicity so I do encourage you to code up a solution and submit the patch (base it off the 2.0.1 codebase) and we can see how well it works. A word of caution: I tend to take more convincing to accept UI patches than any other kind. :-)
I don't like the idea of 4 menu items that all do similar things. I suspect that most users will prefer to stick with whatever they've set in the preferences and only occasionally employ the shortcut to divert to the alternative approach such as when a home page is more complex than Vienna's built-in support can handle. So the challenge becomes how to make this sufficiently discoverable without overloading the UI?
I haven't spent much time thinking about this but Vienna does have a high bar for usability and UI simplicity so I do encourage you to code up a solution and submit the patch (base it off the 2.0.1 codebase) and we can see how well it works. A word of caution: I tend to take more convincing to accept UI patches than any other kind. :-)
Ok, I'm just going to get rid of all menu items for opening the article, because it can be done by hitting return or mouse clicking, and apps such as Mail and Safari don't have menu items to do that.
Moreover, I'm thinking of using the option key to override browser preferences rather than the command key. The problem is that in the browser view, command-click currently opens a link in a new tab, and I don't want to change that, especially since it's Safari-like behavior. However, this would require you to use a different modifier key to override the pop-up blocking preferences, perhaps the shift key. What do you think? Or now that I think of it, I could use the shift key rather than the command key to override browser preferences. Which would you rather have?
Moreover, I'm thinking of using the option key to override browser preferences rather than the command key. The problem is that in the browser view, command-click currently opens a link in a new tab, and I don't want to change that, especially since it's Safari-like behavior. However, this would require you to use a different modifier key to override the pop-up blocking preferences, perhaps the shift key. What do you think? Or now that I think of it, I could use the shift key rather than the command key to override browser preferences. Which would you rather have?
One problem with removing the menu commands is that you almost eliminate the discoverabiity of the actions. Unlike mail, there's no fundamental reason to believe that an article's web page or the feed's home page can be accessed at all. And unlike mail, opening up the current message is an incremental improvement over viewing it in the preview pane such that it isn't really a significant feature.
So I'd vote to retain the menu commands.
Post a Comment
So I'd vote to retain the menu commands.
<< Home
Archives
February 2006 March 2006 April 2006 May 2006 June 2006 August 2006 November 2006 May 2007 June 2007 July 2007 August 2007 September 2007 January 2008
