Project donation
I've been pleasantly surprised few days ago by Daniel Hertrich. He wanted to show his support for the Notecase project and he bought me a DVD title from my Amazon wish list
Thank you Daniel!
Daniel is currently the person who reported a highest number of bug reports, and he made some very cool feature suggestions. The next Notecase release will definitely profit by his great work.
He is also a member of a growing sub-community of Notecase users, the ones that run it on Sharp Zaurus!
Zaurus seems like a really cool machine. It is small, portable, and yet it can run Linux (using pdaXrom or similar X11 based ROM for Sharp Zaurus). I don't own one of these, but I am seriously tempted :)
BTW, Daniel has some great plans for Zaurus. Through his company named Hermocom, he plans to make a full-featured Zaurus/Linux based platform, composed of some chosen open-source programs.
In his words, Notecase is one of the main software components of this project. It will allow the user to record brainstormings and organize ideas. Or, with its HTML export feature, it will allow to record meeting notes and directly, after the meeting, create handouts for the attendants in professional looking HTML format.
You can read more details of this project (named "weeXpc") on his website.
Tuesday, November 14, 2006
Thursday, November 09, 2006
Notecase bugfixes
It's been a few days after the new release (v1.2.6) and I've got few bug reports from the users. The result is the new pre-release code (and the Windows .exe file) waiting for you at http://notecase.sf.net/temp/
Detailed change log can be found within the source code archive (inside docs/help.ncd file).
BTW, if you are interested in the latest sources, take a look at the address above from time to time.
It's been a few days after the new release (v1.2.6) and I've got few bug reports from the users. The result is the new pre-release code (and the Windows .exe file) waiting for you at http://notecase.sf.net/temp/
Detailed change log can be found within the source code archive (inside docs/help.ncd file).
BTW, if you are interested in the latest sources, take a look at the address above from time to time.
Sunday, October 29, 2006
Notecase news
My personal pet-project named Notecase (http://notecase.sf.net) is an hierarchical notes manager, written using GTK+ and C++.

Lately, I've started to receive much more user feedback on it than before, mostly due to the fact that it started being used on Sharp Zaurus platform. Thanks to the feedback I got some quality ideas and bug reports to fix for the new release.
So, expect new release soon with the following news:
My personal pet-project named Notecase (http://notecase.sf.net) is an hierarchical notes manager, written using GTK+ and C++.

Lately, I've started to receive much more user feedback on it than before, mostly due to the fact that it started being used on Sharp Zaurus platform. Thanks to the feedback I got some quality ideas and bug reports to fix for the new release.
So, expect new release soon with the following news:
- default HTML format no longer uses PRE tag to store text formatting. This will enable better CSS formatting when Notecase document is exported to HTML
- some memory leaks fixed
- I've managed to find and fix serious problem with CBlowfish encryption class when compiled in 64-bit environment
- CSHA1 class was updated to new version, solving another problem with x86_64 architecture
- "cut branch" operation was implemented
- Ctrl+T now cycles through the 3 view modes: text view only, tree view only, both views visible
- menu items for tree branch operations were merged with "Copy/Paste/Cut" items from Edit menu
For those who can not wait for the new release you can always fetch latest pre-release code at:http://notecase.sf.net/temp/
Saturday, October 14, 2006
GTK+ file open/save dialog review
Last few years I've been programming with GTK+ toolkit (coming from Win32/MFC world) and I think some remarks gathered over time could help the community to make this toolkit better.
Why not use bugzilla and report the bugs directly, you might say? It's not that I haven't tried, but I have a bad experience with it. Most of my reports for Gnome/GTK still rott there waiting for someone to do something with them :(
One of the things that always bothered me with GTK+ is file open/save dialog.
Starting with GTK 2.6 developers decided to improve on the old dialogs, and created a new GtkFileChooserDialog class, that IMO still needs a lot of work to become usable.
Let's try to see why:
1. In the Save mode, dialog starts in the collapsed state (see "Browse for other folders" in the image below), hiding the file list and optional filter drop down list.
And guess what, you can not controll this behaviour! There is no API to display the dialog expanded from the start!!!
I've managed to make it expanded myself, by writing really really ugly code that can easily become invalid with the next GTK release
(find child #x in the dialog, find child #y within children of #x, ... you got the picture :)

2. Using the dialog in a mode to select only folders, there is no way to use a mouse to select a root directory (or root of a disk drive on Windows) as a destination target!!!
The dialog in this mode of work, allows you to select any other non-root directory, but to select root path, the only workaround I found so far is to use keyboard to type "/" into the folder name. Windows solves this in a much more elegant way, having a special dialog for directory selection.


3. The default version of the dialog is not very usable for real-life programs
The best proof of this is that most major programs implement their custom open/save dialogs (packing additional controls below GtkFileChooserWidget). For example see screenshots below for custom implementations in AbiWord and OpenOfice.org packages (I'm sure I could find many more).
I do not claim, that default version must guess all the extra widgets needed, but the basic ones should be covered. The biggest problem is following:
in Windows API, file open dialog uses filter combo box in two ways - to filter the file list and to pick file format for the document to be saved;
GTK dialogs, on the other hand, hides this filter combo by default in the save mode (see problem #1). The result is that the programmer needs to add additional combo (with almost the same content as in filter combo) for user to pick target file format in Save dialog.
So, any programmer whose software uses more than one file format, must use its own custom Save dialog in order to save its users for confusion.





4. IMO, the dialog layouts are somewhat ugly
Conclusion:
GTK+ file open/save dialogs (GtkFileChooserDialog class) could use some polishing in layout to make them more usable and more pretty. The layout shoud be simplified and more intuitive to use.
Last few years I've been programming with GTK+ toolkit (coming from Win32/MFC world) and I think some remarks gathered over time could help the community to make this toolkit better.
Why not use bugzilla and report the bugs directly, you might say? It's not that I haven't tried, but I have a bad experience with it. Most of my reports for Gnome/GTK still rott there waiting for someone to do something with them :(
One of the things that always bothered me with GTK+ is file open/save dialog.
Starting with GTK 2.6 developers decided to improve on the old dialogs, and created a new GtkFileChooserDialog class, that IMO still needs a lot of work to become usable.
Let's try to see why:
1. In the Save mode, dialog starts in the collapsed state (see "Browse for other folders" in the image below), hiding the file list and optional filter drop down list.
And guess what, you can not controll this behaviour! There is no API to display the dialog expanded from the start!!!
I've managed to make it expanded myself, by writing really really ugly code that can easily become invalid with the next GTK release
(find child #x in the dialog, find child #y within children of #x, ... you got the picture :)

2. Using the dialog in a mode to select only folders, there is no way to use a mouse to select a root directory (or root of a disk drive on Windows) as a destination target!!!
The dialog in this mode of work, allows you to select any other non-root directory, but to select root path, the only workaround I found so far is to use keyboard to type "/" into the folder name. Windows solves this in a much more elegant way, having a special dialog for directory selection.


3. The default version of the dialog is not very usable for real-life programs
The best proof of this is that most major programs implement their custom open/save dialogs (packing additional controls below GtkFileChooserWidget). For example see screenshots below for custom implementations in AbiWord and OpenOfice.org packages (I'm sure I could find many more).
I do not claim, that default version must guess all the extra widgets needed, but the basic ones should be covered. The biggest problem is following:
in Windows API, file open dialog uses filter combo box in two ways - to filter the file list and to pick file format for the document to be saved;
GTK dialogs, on the other hand, hides this filter combo by default in the save mode (see problem #1). The result is that the programmer needs to add additional combo (with almost the same content as in filter combo) for user to pick target file format in Save dialog.
So, any programmer whose software uses more than one file format, must use its own custom Save dialog in order to save its users for confusion.





4. IMO, the dialog layouts are somewhat ugly
- most of the screen area is wasted with huge "Add"/"Remove" buttons (making the bookmarks list above them too wide). It would be good to lose those buttons completely and to tranfer those rarely used options in a context menu (currently there exists "Remove", but not "Add" option in a context menu - GTK+ v2.8.20)
- by default, the dialog could be less wide
- the "bookmark" list should have a different background color than main file list,
so that user can intuitively percieve the file list as the main widget - the "bookmark" list is too wide compared to file list, file list should be by far the most dominant widget on a dialog
- I would recommend removing this "expand" widget/state in file save mode (dialog should be always expanded). This is important because it makes the dialog more simple/less complicated to use
- filter combo box should have bigger width and some label left to it (having no descriptive label makes it look strange)
- it would be nice to have few colored icons somewhere, to make this dialog less grey
Conclusion:
GTK+ file open/save dialogs (GtkFileChooserDialog class) could use some polishing in layout to make them more usable and more pretty. The layout shoud be simplified and more intuitive to use.
Subscribe to:
Posts (Atom)