| << September >> | ||||||
| S | M | T | W | T | F | S |
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | ||
i.Hex now on SourceForge
26/8/2010
I've create a SourceForge project for i.Hex here:
I've create a SourceForge project for i.Hex here:
https://sourceforge.net/projects/ihex
(0) Comments | Add Comment
Scribe/Mac unified toolbar
18/8/2010
I got this working today:
I got this working today:
Looks a little more native eh? I think the icons are still a little blurry, but to fix that I'll have to create full resolution source icons, which are 128x128. Currently they are 24x24, and they are getting scaled somewhat for display on the toolbar. First x4 to fill the 128x128 source image and then down to whatever size the HIToolbar wants to display them as. I've been playing for years now with getting native scrollbars working. But thats proven too difficult so far for this little black duck.
(0) Comments | Add Comment
i.Mage on SourceForge
4/8/2010
i.Mage is now on SourceForge:
i.Mage is now on SourceForge:
https://sourceforge.net/projects/image-editorAll the source is checked into SVN and it's builds on windows. Will check on Mac when I get a chance.
(0) Comments | Add Comment
Html editing.
30/7/2010
I'm making a serious effort to use Scribe's HTML editing in day to day use. So far I've resolved a number of issues that made it unusable and it's now just merely clunky as hell. Things I've yet to sort out:
I'm making a serious effort to use Scribe's HTML editing in day to day use. So far I've resolved a number of issues that made it unusable and it's now just merely clunky as hell. Things I've yet to sort out:
-
Home/End don't work. - I still get a bunch of asserts pop up when I delete text.
-
Enter with a selection doesn't do anything. - There are some stray spaces creeping in here and there.
-
No way to set a HTML signature yet. Although there are HTML reply/forward formats. - The HTML output has a lot of redundant style information in the elements. e.g. the anchor tags have explicit styles for "blue" and "underlined". I will eventually remove those on save. I'm working towards have a default style sheet, which most likely will exist as a 'default.css' in the resources folder. This means that yes, you could edit that to change the default appearance of HTML email in Scribe.
-
Also it doesn't yet allow you to reply to someone's else HTML email in HTML... it converts their email to text... adds that to your HTML reply template and then gives that to the editor. Although I'm working on a new DOM field called "BodyAsHtml" that you can use in the reply format to get the source email's HTML correctly formatted.It's unknown how arbitrary HTML email will work inside the editor. For instance, there is no way of editing tables at all, but it should render ok. - Oh yeah, and no inline spell checking like the text mode compose control. It's taken a long time to get that working right, and HTML adds a whole other level of complexity to it. But you know I'll find a way right!
- Doesn't support paste/working with images at all.
- Can't break out of the quoted text to put inline replies in.
i.Ftp on SourceForge
26/7/2010
As hinted I'm slowly moving to having my apps hosted on SourceForge. Starting with i.Ftp: https://sourceforge.net/projects/i-ftp/ It has the latest release, v2.20, in source and binary form, a screenshot+icon, svn etc. I guess i.Mage is next. There was no reason is keeping all my open source stuff on a private SVN server. If I had a catastrophic data crash or passed away it would just disappear. Morbid thoughts I know, but you get them occasionally. Anyway it's getting better, 2 projects down... um... er lots to go.
As hinted I'm slowly moving to having my apps hosted on SourceForge. Starting with i.Ftp: https://sourceforge.net/projects/i-ftp/ It has the latest release, v2.20, in source and binary form, a screenshot+icon, svn etc. I guess i.Mage is next. There was no reason is keeping all my open source stuff on a private SVN server. If I had a catastrophic data crash or passed away it would just disappear. Morbid thoughts I know, but you get them occasionally. Anyway it's getting better, 2 projects down... um... er lots to go.
(0) Comments | Add Comment
Gtk Progress
30/6/2010
:D
Most of the keyboard and mouse functionality is working. Painting windows is much improved. The skin engine is painting controls. Overall things are quite functional, but there are still broken things, like combo boxes on dialog seems to mess things up. And the account preview just seems to hang and go nowhere.It's Scribe Jim... but not as we know it.
25/6/2010
The GTK port boots... at least to something that resembles the main screen. So far I've had lots of build issues, crashes, asserts, missing functions and memory overwrites. But seeing the main screen for the first time is a milestone of sorts. The missing icons will be path issues. The menu... uh who knows. But it's getting there.
The GTK port boots... at least to something that resembles the main screen. So far I've had lots of build issues, crashes, asserts, missing functions and memory overwrites. But seeing the main screen for the first time is a milestone of sorts. The missing icons will be path issues. The menu... uh who knows. But it's getting there.
(0) Comments | Add Comment
Lgi back on SourceForge
23/6/2010
I've got sick of hosting Lgi privately and making source releases every other year, and so I've uploaded the latest code to SourceForge and I'm going to just use that from here on in. Some of my other apps may follow. I've structured the Lgi checkout to have a trunk and branches sub-folders which I think is fairly standard usage with svn. There is no auto-conf yet under Linux but I'd be interested in someone providing one as I build on the Linux/Gtk+ port. Hooray for open source! :-)
I've got sick of hosting Lgi privately and making source releases every other year, and so I've uploaded the latest code to SourceForge and I'm going to just use that from here on in. Some of my other apps may follow. I've structured the Lgi checkout to have a trunk and branches sub-folders which I think is fairly standard usage with svn. There is no auto-conf yet under Linux but I'd be interested in someone providing one as I build on the Linux/Gtk+ port. Hooray for open source! :-)
(0) Comments | Add Comment
Lgi/Gtk/Linux/Mac
18/6/2010
The GTK port lives. I've got it to a point where I can put a window, with menus, toolbar and splitter on screen and everything is behaving reasonably correctly. So now I need to add some keyboard support and then slowly throw more and more complex code at it and find / fix bugs. The big problems were getting Lgi's layout engine to work within the GTK layout engine. Ug... that was hard. But I got there eventually. Main issue was GTK layout wasn't even working because I borked up the configure signal due to a lack of understanding signal propagation. The next big issue was getting the equivalent of "PostMessage" working with GTK. Which ended up having a stack overflow question. Finally the images weren't loading. But that really was just a matter of hacking at the GMemDC class till it understood the GdkImage format and returned the right stuff through it's methods. We could be close to both new Mac and Linux releases soon... this month? Maybe. Mac build is working but I still have those hateful non-virtual thunk errors when I compile with _DEBUG defined in debug mode. So far looks like a gcc compiler bug from what I read on the interwebs. Developing code for the Linux port in Visual Studio is nice though :-) I seriously enjoy that IDE/Debugger combination, it still kills anything on the Linux + Mac platforms. And of course I do compile / run the code on Ubuntu to test things that I'm not sure about. I even valgrind'd it a bit while I was over there. I ❤ valgrind.
The GTK port lives. I've got it to a point where I can put a window, with menus, toolbar and splitter on screen and everything is behaving reasonably correctly. So now I need to add some keyboard support and then slowly throw more and more complex code at it and find / fix bugs. The big problems were getting Lgi's layout engine to work within the GTK layout engine. Ug... that was hard. But I got there eventually. Main issue was GTK layout wasn't even working because I borked up the configure signal due to a lack of understanding signal propagation. The next big issue was getting the equivalent of "PostMessage" working with GTK. Which ended up having a stack overflow question. Finally the images weren't loading. But that really was just a matter of hacking at the GMemDC class till it understood the GdkImage format and returned the right stuff through it's methods. We could be close to both new Mac and Linux releases soon... this month? Maybe. Mac build is working but I still have those hateful non-virtual thunk errors when I compile with _DEBUG defined in debug mode. So far looks like a gcc compiler bug from what I read on the interwebs. Developing code for the Linux port in Visual Studio is nice though :-) I seriously enjoy that IDE/Debugger combination, it still kills anything on the Linux + Mac platforms. And of course I do compile / run the code on Ubuntu to test things that I'm not sure about. I even valgrind'd it a bit while I was over there. I ❤ valgrind.
Scribe IMAP
7/6/2010
I've finally got sick of the way that Scribe doesn't seem to pick up on new email in the IMAP inbox. So I started watching what Thunderbird does and basically it's using the IDLE command to force the server to notify it when new email arrives (as well as other events). I was under the mistaken impression that IMAP server should be sending untagged data to the client to achieve that sort of "push" notification. So I've added IDLE support to Scribe's IMAP protocol stack and I'm now working on integrating the resulting events back into the IMAP thread code so that they do useful things like show new email. The next release should be more standard in it's new mail behaviour. One thing I did notice with the IMAP support in Thunderbird is that it regularly uses 2 socket connections. And I never attempt to open a 2nd connection (one is complicated enough). But it's something I'll have to probably look at in the future to avoid lag if the main connection is busy downloading a large email or something. With respect to Gmail support, I've read the spec and even tried some implementation of the OAUTH authentication method but so far it's a dark twisty maze of tokens, encryption hashing and parameter encoding. Sigh... and so far it's winning, not me. Unfortunately Gmail uses SSL and that means I can't spy on the traffic between Thunderbird and Gmail to try and get an "example" to follow. One thing I need to investigate is whether there is a way of dumping the unencrypted SSL traffic from inside Thunderbird. Worst case I could download the source and build a version that DOES dump the traffic. But thats worst case... I'm sure that's a non-trivial amount of effort. Anyway, enough drivel. Back to it.
I've finally got sick of the way that Scribe doesn't seem to pick up on new email in the IMAP inbox. So I started watching what Thunderbird does and basically it's using the IDLE command to force the server to notify it when new email arrives (as well as other events). I was under the mistaken impression that IMAP server should be sending untagged data to the client to achieve that sort of "push" notification. So I've added IDLE support to Scribe's IMAP protocol stack and I'm now working on integrating the resulting events back into the IMAP thread code so that they do useful things like show new email. The next release should be more standard in it's new mail behaviour. One thing I did notice with the IMAP support in Thunderbird is that it regularly uses 2 socket connections. And I never attempt to open a 2nd connection (one is complicated enough). But it's something I'll have to probably look at in the future to avoid lag if the main connection is busy downloading a large email or something. With respect to Gmail support, I've read the spec and even tried some implementation of the OAUTH authentication method but so far it's a dark twisty maze of tokens, encryption hashing and parameter encoding. Sigh... and so far it's winning, not me. Unfortunately Gmail uses SSL and that means I can't spy on the traffic between Thunderbird and Gmail to try and get an "example" to follow. One thing I need to investigate is whether there is a way of dumping the unencrypted SSL traffic from inside Thunderbird. Worst case I could download the source and build a version that DOES dump the traffic. But thats worst case... I'm sure that's a non-trivial amount of effort. Anyway, enough drivel. Back to it.
Linux / Scribe / GTK?
2/6/2010
Wondering where it is? Well I'm busy with life, but I found some time to make a Win32/GTK build of Lgi, which Scribe uses as a cross platform layer. The purpose of this is to work on getting a stable build of Scribe using GTK on a platform that I actually use. It seems I have no time to boot into Linux these days so if I had a windows port then at least I'd be 90% the way there in terms of functionality and it'd just be tweaking things for GTK/Linux rather than writing a GTK port from scratch. I very much doubt I'd ever release a GTK/Win32 build of Scribe as it's a bit pointless considering the native port is a) smaller, b) faster and c) better. So yeah, I'll work on that... it's not dead. Update: I have a working build of Lgi/Gtk2/Win32 but I fail to understand the Gtk layout internals enough to position widgets wherever I want. The allocation vs request stuff is doing my head in. I can get all the widgets into the right place by setting their size but then I can't resize the window any smaller than the initial size which isn't what I want. Basically I want something like the GtkFixed container that I can resize down to 1x1 if I have to. Yeah basically I want Gtk to butt out and let me put my widgets where I want using all my own layout. "Good luck with that" I hear the chorus from the peanut gallery ;)
Wondering where it is? Well I'm busy with life, but I found some time to make a Win32/GTK build of Lgi, which Scribe uses as a cross platform layer. The purpose of this is to work on getting a stable build of Scribe using GTK on a platform that I actually use. It seems I have no time to boot into Linux these days so if I had a windows port then at least I'd be 90% the way there in terms of functionality and it'd just be tweaking things for GTK/Linux rather than writing a GTK port from scratch. I very much doubt I'd ever release a GTK/Win32 build of Scribe as it's a bit pointless considering the native port is a) smaller, b) faster and c) better. So yeah, I'll work on that... it's not dead. Update: I have a working build of Lgi/Gtk2/Win32 but I fail to understand the Gtk layout internals enough to position widgets wherever I want. The allocation vs request stuff is doing my head in. I can get all the widgets into the right place by setting their size but then I can't resize the window any smaller than the initial size which isn't what I want. Basically I want something like the GtkFixed container that I can resize down to 1x1 if I have to. Yeah basically I want Gtk to butt out and let me put my widgets where I want using all my own layout. "Good luck with that" I hear the chorus from the peanut gallery ;)
(0) Comments | Add Comment
Scribe issues with Aspell and PHP
31/5/2010
If like me you do a little PHP as well as use Scribe, then you might find that one day your spell checking functionality in Scribe just stops working, and instead all words are returned as spelling errors despite having the dictionaries correctly installed and configured. This is because your PHP directory is in the PATH and also has an aspell-15.dll and Scribe is loading that instead of the one in your aspell install (usually C:\Program Files\Aspell\bin). The fix is to more the aspell folder so that it's before your PHP folder in the list of folders in your PATH. Btw I quite like Path Editor for that purpose.
If like me you do a little PHP as well as use Scribe, then you might find that one day your spell checking functionality in Scribe just stops working, and instead all words are returned as spelling errors despite having the dictionaries correctly installed and configured. This is because your PHP directory is in the PATH and also has an aspell-15.dll and Scribe is loading that instead of the one in your aspell install (usually C:\Program Files\Aspell\bin). The fix is to more the aspell folder so that it's before your PHP folder in the list of folders in your PATH. Btw I quite like Path Editor for that purpose.
(0) Comments | Add Comment