Messages

51

Screenshot Captor / Re: Experimental Alpha Version with ConfigDir.ini - Choose Where to Store Settin

« on: September 28, 2006, 06:57 AM »

Hey Mouser,

Great new feature - think this will make quite a few people happy.

It seems to be working fine for me so far, with the exception that %MYDOCUMENTS% doesn't get expanded, so I just get a folder in the program directory called "%MYDOCUMENTS%". The others (%APPDATA%, etc. and explicit paths) work fine though.

Not sure if this is relevant, but I've got my "My Documents" folder in a custom location - however, the registry (at HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Personal) does point to it.

I also noticed that the filter type (under smoothing) wasn't getting saved into the ini. That just happened to be the first setting I changed when testing to see if changes were recorded in the correct ini file. I thought it wasn't working at all at first, until I tried changing different settings, and they were recorded in the correct ini file, so I think it's just an omission of that particular setting and not an issue with the new ini scheme. (BTW, it would be nice to have that fixed at some point - I'm not a massive fan of the FastLinear filter )

HTH,

- Neil.

52

Find And Run Robot / Re: comment on new version 1.10.02 beta

« on: September 27, 2006, 09:09 AM »

Mouser, just a thought about cacheing...

Rather than trying to coax the system to keep the relevant directories fresh in its cache, would the FindFirstChangeNotification/ReadDirectoryChangesW APIs maybe serve your overall purpose (minimising directory reads but dealing with changes) more efficiently?

FindFirstChangeNotification lets you get notifications of any changes to entire subtrees of the file system. When you get one of these notifications, ReadDirectoryChangesW lets you enumerate just the changes. If you combined this with an in-memory representation of the tree (which you probably already have?), it should be possible to achieve pretty instant results in FARR while minimising disk access.

Does this sound like a useful solution?

53

Mini-Reviews by Members / Re: XYplorer File Manager

« on: August 26, 2006, 07:05 AM »

I'm sure that has to do with how DOpus handles virtual folders. Or am I wrong on that?

-zridling (August 25, 2006, 10:23 PM)

I thought DOpus' virtual folders was just a way to tell it which folders to use Explorer's containers for, e.g. you might want the control panel to show up as it does in Explorer, but Windows/Fonts to be handled by DOpus?

54

Mini-Reviews by Members / Re: XYplorer File Manager

« on: August 25, 2006, 08:33 AM »

The ability to copy a whole folder structure, including all subfolders, to a different location, without copying the files inside those folders is a great time-saver.

-zridling (August 24, 2006, 06:04 PM)

Yeah, this is a nice facility.

I was wanting to get DOpus to do a (roughly) similar thing the other day, where I could copy a folder tree without the ".svn" folders (created by Subversion) or any of the files inside them. DOpus' file filters seemed like they would do the job, but it was a bit harder than I expected, because it behaves a little strangely with folders. Basically, if you set the file filter to simply ignore items with "name" matching ".svn", it will do nothing, because it seems to only consider the files and not the folders. However, if you tell it to ignore items with the "type" matching "[Folders Only]" AND "name" matching ".svn", it works.

Coming back to the feature you mention, the "type" matching "[Folders Only]" rule can be used on its own (as a "match" rather than an ignore) to perform a copy of the folder structure without any of the files. Pretty neat - I just need to figure out how to make it appear as an option on a right-button-drag. Might be easier to just add it as a toolbar button though.

55

Mobysaurus / Re: Mobysaurus Thesaurus v1.0 Released

« on: August 16, 2006, 01:23 PM »

The download link on the moby page gives me a "not found" error.

Looks great though. Looking forward to trying it out.

56

Developer's Corner / Re: Anyone ever used Swig or other c++ wrapping tools? recommendations

« on: August 12, 2006, 12:36 PM »

OK, so it looks like the C# generator is kind of doing the two steps you mentioned. It can probably get away with this since it can do them in tandem, whereas it would be much harder for SWIG itself to generate a set of C functions and then have each language generator build on top of that, if that makes sense.

So does the C# output (minus the extra .cs files) do what you want, or do you still have to make a lot of changes to it? I'm just thinking that if it's close, but not quite there, it might be fairly easy to use it as the basis of a proper C output module.

57

Developer's Corner / Re: Anyone ever used Swig or other c++ wrapping tools? recommendations

« on: August 12, 2006, 10:37 AM »

I don't think SWIG is actually split up into two pieces like that though.

Although it does generate C wrapper code, this wrapper is not a plain C interface to the C++ interface - it's a specific set of C wrappers that map C++ to the desired scripting language. It probably needs to do it this way so that it can preserve as much of the class structure for the scripting language to use (e.g. inheritance in your C++ classes would be represented as inheritance in Ruby).

BTW, is the C# output closer to what you need because you're using the "-noproxy" flag with it?

58

Developer's Corner / Re: Anyone ever used Swig or other c++ wrapping tools? recommendations

« on: August 12, 2006, 09:59 AM »

Ah, I think I get you now. You want the DLL to have a C API (generated from the C++) so that you can then interface to it from any language that can interface to a C API, is that right?

I thought you were just wanting a DLL that would go alongside your own app, hence my suggestion of just using C++ for both (along with a bit of "tunelling" so they could communicate).

On that note, say someone wanted to write a LauguageX client that used this DLL, wouldn't you also want some form of SWIG output that would wrap the original C++ interface into "LanguageX as tunneled through a C API", or would you just expect clients to use the C API directly? If you see what I mean?

59

Developer's Corner / Re: Anyone ever used Swig or other c++ wrapping tools? recommendations

« on: August 12, 2006, 09:21 AM »

I understood what you wanted it for. What I was asking was why you couldn't just write the DLL in C++ instead?

60

Developer's Corner / Re: Anyone ever used Swig or other c++ wrapping tools? recommendations

« on: August 12, 2006, 06:44 AM »

You're a hard man to please, Mouser.

Yes, I can see it being disappointing for someone if it doesn't provide support for the language they want to use, but it can't support them all.

I'm a bit confused by your C DLL example though. If you want to wrap a C++ interface so that you can access it from C code, then you're talking about new C code, aren't you? What I mean by this is that you won't have an interface to the C++ code yet, so any C code which would use this interface cannot exist yet.

If that's the case, couldn't you just write a C++ DLL instead?

61

Developer's Corner / Re: Anyone ever used Swig or other c++ wrapping tools? recommendations

« on: August 12, 2006, 06:06 AM »

SWIG is pretty amazing. I've only used it with Ruby (see Screenshot Captor scripting thread), although I did use a fair chunk of its features and I was constantly impressed by how flexible it was.

One of its best features is that the C++ parser is really pretty good, so you don't have to "sanitise" your code that much for SWIG to accept it, although you'll probably always end up generating a separate interface file anyway, just to make use of some of SWIG's extra features.

It also has a really flexible "typemap" system which allows you to control how types in C++ map to your scripting language. It comes with a decent set of defaults that will cover a lot of stuff for you, but having the ability to define your own mappings is extremely useful. The last project I did with Ruby integration would have been virtually impossible without this feature. It's not particularly easy to get your head round at first, but there's enough examples and documentation to get by.

Robustness wasn't an issue either. I was using it to generate a binding from an 16,000+ line interface file (several hundred classes) which resulted in a ~120,000 line binding implementation, and never had any problems with it. In fact, the only problem I had dealing at this scale was that Visual Studio really didn't like the 120,000 line source file (even though every other text editor I tried was quite happy with it).

One thing to note about SWIG is that it's really designed to build extensions for scripting languages, and not for embedding a scripting language into a C++ program, so the instructions are kind of geared towards extending. Having said that, you can use it for embedding (which is what I was doing) and it works very well for that.

It's also worth noting that it only deals with the scripting language's view onto the C++ program, and not the other way round. You can use some of the stuff it provides to access the scripting language from C++, but you'll probably need to write some sort of C++ wrapper for the scripting language yourself. Fortunately, this is normally pretty easy and doesn't usually require anything like the code generation required for the other direction.

Documentation: I really don't want to say anything negative about SWIG's documentation, because it really is a brilliant effort and clearly a lot of work has gone into it. The problem is that SWIG is so flexible that even the best documentation is going to leave you scratching your head on occasion, and this happened to me a few times. However, I think it's fair to say that I would have been scratching my head a lot more if the documentation wasn't as good as it was. It's certainly amongst the best documentation I've seen in an open source project.

All in all, I can happily say that if I ever decide to switch from embedding Ruby to some other language, then I'll be heading straight to SWIG again.

Oh, I've also use toLua in the past for Lua integration. It was small, simple and worked pretty well, but nowhere near as flexible as SWIG (although probably more than enough for many purposes). This was quite a few years ago, so I've no idea if it's still supported, or if it's more advanced now, or what.

I also know a few people who swear by Boost Python for Python integration, although I've never had any direct experience with it, so I can't really say much more than that.

HTH.

62

Screenshot Captor / Re: Scripting to be added to Screenshot Captor

« on: August 11, 2006, 10:41 AM »

I hope you realise I was kidding there. 

63

Screenshot Captor / Re: Scripting to be added to Screenshot Captor

« on: August 11, 2006, 09:59 AM »

I'm getting the distinct impression that we might be seeing something called "DCScript" on the horizon.

64

Screenshot Captor / Re: Scripting to be added to Screenshot Captor

« on: August 11, 2006, 09:13 AM »

however, i am a fan of strong static typing.  any programming language where you can just start using a variable without declaring it, or do some weird assignments between incompatible types without generating an error, is not going to be something i am happy with.

<snip>

-mouser (August 11, 2006, 08:57 AM)

So are you basically saying that you want a scripting language that's pretty much the same as C++?

What about something like Ch?

65

Screenshot Captor / Re: Scripting to be added to Screenshot Captor

« on: August 11, 2006, 09:04 AM »

Sorry mouser for dragging this so far of topic, but NeilS another option for C++ code is Boost.FOR_EACH .

-Eóin (August 11, 2006, 08:53 AM)

Of course, but that's a macro, and it was just an example.

66

Screenshot Captor / Re: Scripting to be added to Screenshot Captor

« on: August 11, 2006, 08:22 AM »

You wouldn't repeat those code sequences, though, you would factor them out to a function or similar. You might then argue that nothing has been won, but au contraire; it's easy to follow into a function call (visual studio or similar IDEs, or CTAGS based stuff), where you can then read the proper and verbose code.

-f0dder (August 11, 2006, 06:53 AM)

Not all code sequences can be converted into functions easily though, certainly not in a language like C++. The classic example is using a for loop with iterators into a container, e.g:

[Select]

for(AList::iterator it = list.begin(); it != list.end(); ++it)
{
  // Do something with 'it'
}

That's a pretty common code sequence in a lot of C++ programs. There are various ways to implement it so that the for loop is more concise (e.g. functors). But functors just add more code somewhere else and you still have the problem of not having access to any of the local variables in the function where the for loop resides.

Contrast that with the Ruby equivalent:

[Select]

list.each do |it|
  // Do something with 'it'
end

There's no reasonable way to achieve something this concise and readable in C++ by factoring out into functions.

In case you're wondering, I'm not trying to make some sort of language advocacy point here. I'm just trying to understand Mouser's philosophy about preferring verbosity, and what he actually means by that.

Compare that to some of the atrocious one-liners you can do in perl

Don't get me wrong, I'm in complete agreement that atrocious one-liners are, well... atrocious. But just because you can write such lines in languages like Perl and Ruby, that doesn't mean you have to. In fact, the Ruby community is trying to encourage people to stop using the various "Perlisms" available in Ruby because Ruby is plenty concise and very readable without them.

Besides, you can write pretty atrocious one-liners in C++ using macros or templates.

67

Screenshot Captor / Re: Scripting to be added to Screenshot Captor

« on: August 11, 2006, 06:48 AM »

yes i meant oop as in object oriented programming.

my philsophy of programming is that verbosity is good.  i find that some people are really drawn to languages like perl where you can write one line that does a lot.  i prefer having a longer function and bigger infrastructure that feels to me more organized.

-mouser (August 10, 2006, 09:17 PM)

I think what confused me was that it seemed as if you were implying that scripts weren't OOP programs, but you were actually talking about the verbosity of the code you would normally write in a language like C++ versus the average scripting language.

The idea that verbose code is more organised is an interesting notion. Say you have a sequence of code that you tend to write a lot in C++, but the same thing can be expressed in one line or one operator in, say, Ruby. Do you think that having to repeat those code sequences in C++ in lots of places is more organised than having a construct which does the same thing without the repetition? (I'm not saying that's wrong, btw, although I suspect it means that we have different definitions of "more organised").

>Are you likely to add scripting to any of your other apps?

yep, that's part of the calculus involved; even thought sc will have only minimal scripting, ill be using it more in other more substantial roles in other projects, so i have to take that into consideration yet.

Hehe, you read my mind.

68

Screenshot Captor / Re: Scripting to be added to Screenshot Captor

« on: August 10, 2006, 04:22 PM »

for some reason lua just didn't capture my heart from the book i read; ruby the same, though i feel more like i could maybe adjust to ruby.  my programming style in general lends itself more to big oop programs rather than scripts.  i always do things in 100 lines which could be done in 1 line of a scripting language, for better or worse.

-mouser (August 10, 2006, 12:39 PM)

I'm not quite sure what you mean by "big oop programs" versus scripts. Do you mean "big C++ programs", where the meaning of the code is more explicit, at the expense of being larger (not to mention about a squillion times faster)?

but squirrel (http://www.squirrel-lang.org/) really seemed to appeal to the c++ coder in me, so i may give that a try.

All I can say to that is that there's more than one type of coder inside every programmer. You just need to let the other ones come out and play sometime.

on the other hand, scripting for screenshot captor will be very light weight and minimal, and so lua might end up being perfect for that.

Are you likely to add scripting to any of your other apps?

69

Screenshot Captor / Re: Scripting to be added to Screenshot Captor

« on: August 10, 2006, 11:49 AM »

I've integrated Lua and Ruby into programs in the past.

Lua was pretty easy to get going, but the stack-based API was a pain to work with and pretty error prone, so you'd want to wrap that up so you don't have to deal with it. There's a mod of Lua called LuaPlus which adds some handy features and also wraps the stack-based API nicely for you. Not sure if any of that functionality has made it into the core since then (it was a while ago). In terms of the language, I never really liked it that much - the philosophy of a lightweight language that you can bend to your will is a nice one, but I think they could have built-in some decent OOP support by default.

Ruby was a bit harder to get going. It was never designed to be used as an embedded language, and the source is... interesting (very diplomatic term there). There's also not a lot of info on embedding it - mostly lots of scraps and slightly weird docs kicking around. It basically took a fair bit of digging and experimentation, but it's simple enough once you get used to it. In terms of language, well, I don't think I've ever used a language which is more enjoyable and productive - there's a reason a lot of people are getting into Ruby these days.

Lua is generally quite a bit faster than Ruby, although that's not really an issue if you're using it to automate a program. I wouldn't use Ruby in a game, for example, but then, I wouldn't use Lua either. Don't ask what I would use.

My overall opinion, having tried both, is that Ruby is worth the extra effort, so long as your program doesn't rely on it being really fast.

Mouser, if you decide to try Ruby out, I can give you some pointers to help speed things up if you want. I could probably help a bit with Lua if you decided to use that, although my Lua knowledge is a bit out of date, and there's lots of Lua info out there anyway.

70

Site/Forum Features / Re: Recent topics

« on: August 07, 2006, 07:16 PM »

carol said it all; in the battle for space, ive moved it above.

-mouser (August 07, 2006, 07:07 PM)

Phew, at least I wasn't imagining things. I get that sometimes.

what i can do however, is put links in the UNREAD POSTS screen and RECENT TOPICS screen back to each other, so its easy to move between them.  if people demans the RECENT TOPICS be moved back i can put it back.

Not a biggie for me, although the toolbar didn't seem that stuck for space before. Maybe my monitor's too big though.

71

Site/Forum Features / Re: Recent topics

« on: August 07, 2006, 07:10 PM »

It's at the top of the page to the right of your avatar.

-Carol Haynes (August 07, 2006, 04:56 PM)

Aha, so it is. 

Although I could have sworn it was on the toolbar just yesterday, roughly here:

72

Site/Forum Features / Recent topics

« on: August 07, 2006, 04:21 PM »

Is it just me, or has the recent topics button disappeared from the forum toolbar doohickey?

73

General Software Discussion / Re: IDEA: Visual FileSystem

« on: August 03, 2006, 05:30 AM »

This is something I've been looking at on and off over the years. In fact, I actually wrote one a long time ago which used a "2D disk" metaphor to represent a directory hierarchy. Imagine a segmented ring, where each segment is a file/folder in the root directory. The next level down in the hierarchy is represented by the next ring outwards, where the contents of each folder are contained within the same angular section of the ring as their parents. The result looked a bit like a fractal. It's hard to describe without a picture, but hopefully you get the idea. I can't remember what the folder traversal metaphor was, but I think it probably involved rotating the disk and moving up and down the folder levels by moving in and out along the radius of the disk.

Although it was a while ago now, I seem to remember it actually working quite well. One of the big advantages was that you could see several levels of the hierarchy and adjacent folders all at the same time, and it also gave you a reasonable sense of some kind of spatial structure to the contents of your hard disk. It also supported stuff like distributing the amount of angle (= size) given to a segment based on the size of the files/folders, or how many items they contained, etc.

Downsides were that the geometry of the disk tended to waste space as you went down the hierarchy (again, hard to describe - I wish I had a picture of it), and you could only really visualise the folder hierarchy as found on your disk (which is a fundamental problem with any hierarchical metaphor).

I also looked at a recursive "boxes within boxes" metaphor at the time, again with the ability to see inside boxes while also looking outside them (basically flattening a hierarchy into a big, zoomable space). It wasted a lot less space than the disk metaphor and probably had even better spatial awareness properties, but I think it lost out to the disk at the time because the disk's traversal metaphor seemed nicer. Plus the disk looked way cooler.

Anyway, neither method would really support the kind of arbitrary linking being mentioned in this thread (e.g. link all MP3s together), or rather, not as I've described them so far. I did have a few ideas about that though, but I've bored you enough for the moment.

Oh, and I agree that 3D visualisers don't really work (yet). The main problem is the input metaphor, although the display metaphor doesn't really seem to have been solved yet either.

74

Drag&Drop Robot / Re: Display Issues

« on: August 03, 2006, 04:11 AM »

To be fair, a lot of apps suffer from this problem on Windows. I had to stop using large fonts on my laptop (1680x1050 on a 15" screen) because so many programs' dialogs were clipping and overlapping text all over the place.

I suspect the real problem is that Windows encourages people to use statically-sized dialogs, whereas some other systems are more geared towards dynamic layout schemes, which can easily adapt to varying font sizes. Obviously you can do dynamic layouts within Windows, but it's not quite as easy as firing up a resource editor and drawing what you want. I also seem to remember reading that Vista solved the non-standard font size issue, but I don't know if that means they are doing some "magic" to statically-sized dialogs, or if it just means that WinFX makes dynamic layouts easier to work with.

Speaking of which - Mouser, what do you normally use for your GUIs? Do you use a framework, or good old Win32 calls?

75

General Software Discussion / Re: Recent Blog Discussions of Open Source Donations, etc.

« on: August 02, 2006, 04:56 PM »

nice take on it that i agree with:
http://haacked.com/a...FreeLikeAFlower.aspx

-mouser (August 02, 2006, 01:56 PM)

Yeah, good article. If you extend his flower analogy to the concept of financial donations, it's a bit like someone on your street offering to build a nice flower garden that everyone can enjoy, and they'll keep it up as long as they can, but any donations will help to ensure that it keeps going as long as possible, and maybe even allow them to spend a bit more on fancier flowers. It's hard to imagine anyone getting annoyed at the person making this offer, but that seems to be exactly what's happening when people start talking about using donations to help sustain software projects.

Coming back to Jeff Atwood's blog, his main argument seems to be that, since contributing code is far more useful than money (which somehow means contributing money is foolish), and since most people can't contribute code, we shouldn't do either. But - surely - if people take a view that they "do what they can", then lots of people contributing a small amount of money each will help to encourage the small number of people who can contribute code to do so?