4 ms·

Sorry, didn't see this until now. We do cross platform gui apps in L/Tk for our source management system. We're pretty small so doing native apps for Windows/

Sorry, didn't see this until now. We do cross platform gui apps in L/Tk for our source management system. We're pretty small so doing native apps for Windows/Mac/Linux is a lot more work than doing it once. Yeah, the hassle of making them look good is true but not as true as people claim it is (see my other post above). We looked at Qt and I didn't want to bite of C++ on all our ancient platforms we support. I'm a C kinda guy, I like looking at things and understanding it quickly (when going into new code I tend to read the .h files and find the structure definitions, that tells me a lot). Most scripting languages don't have structs (they use a hash instead which means you never really know what is in there unless you find every single assignment to it and memorize all the keys).

hardwaresofton 12y ago
Hey thanks for the reply, was very curious what you were using it for... So, this is pretty crazy, but why not try a small rewrite of some non-trivial functionality in Go? Other than being a language hipster (which I admit I am a little bit), I point to these reasons: 1. Go's ease of cross-compilation is outstanding, so much so that everything else I think of (java, python, C/C++) are not as easy http://dave.cheney.net/2012/09/08/an-introduction-to-cross-compilation-with-go http://dave.cheney.net/2012/09/08/an-introduction-to-cross-c... 2. Go is trying to be used in a "systems language" context, so it's relatively quick 3. It's not C++, and is relatively safer If you're with me till now, then you've realized the real problem with something like Go for this is the GUI library -- unfortunately there are not enough that have been around long enough to be as stable/trusted as TCL/TK.... so that's a bit of a problem. You could also make the UI to your app a website, rather than a GUI application? -------------- OR -------------- What about a your-app-is-a-website type framework like TideSDK? http://www.tidesdk.org/ http://www.tidesdk.org/ You can encapsulate and separate your engine code (which is doing the heavy listing), and just have the client be something that sits on top of it. Sorry, these solutions are quite pie-in-the-sky and I'm sure that you guys are focusing on getting things done (for which L/Tk is perfectly fine), but if you guys are small, I think you might have the agility to move onto a different solution, and I can't help but suggest these things, because I think working on a TCL/TK stack might get things done, but you're gaining experience in a technology that is thoroughly antiquated... So yes, you'll get things done, and you guys will do a great job, but at the end of the day, when it comes time to move to something else, not a lot of the knowledge you gained will be useful?
- luckydude 12y ago
  So moving to anything is a pile of work, we have 10 different guis in L/Tk: bk citool - graphical check-in tool bk csettool - graphical changeset browser bk difftool - graphical differences viewer bk fm3tool - three-way merge tool bk fmtool - side-by-side merge tool bk helptool - graphical front-end to the help system bk renametool - graphical tool for finding renames bk revtool - graphical history browser bk setuptool - graphical front-end to the setup command bk explorer - file/repo/branch explorer which is about 26,000 lines of code. We're trying to relaunch the company, we've never done any marketing, just coasted on the rep we got from having the Linux kernel use us for a while. Rewriting all the guis is a big task - we need to focus on stuff that will make money or the whole thing will be a moot point :) And we're gonna open source L pretty soon here so maybe that will breath a little life into the tcl/tk ecosystem (and maybe not, I have no way of knowing). L is pretty pleasant, it has replaced perl as my goto scripting language. I'd love it if gcc had an L dialect.

hardwaresofton 12y ago

Hey thanks for the reply, was very curious what you were using it for... So, this is pretty crazy, but why not try a small rewrite of some non-trivial functionality in Go? Other than being a language hipster (which I admit I am a little bit), I point to these reasons: 1. Go's ease of cross-compilation is outstanding, so much so that everything else I think of (java, python, C/C++) are not as easy http://dave.cheney.net/2012/09/08/an-introduction-to-cross-compilation-with-go http://dave.cheney.net/2012/09/08/an-introduction-to-cross-c... 2. Go is trying to be used in a "systems language" context, so it's relatively quick 3. It's not C++, and is relatively safer If you're with me till now, then you've realized the real problem with something like Go for this is the GUI library -- unfortunately there are not enough that have been around long enough to be as stable/trusted as TCL/TK.... so that's a bit of a problem. You could also make the UI to your app a website, rather than a GUI application? -------------- OR -------------- What about a your-app-is-a-website type framework like TideSDK? http://www.tidesdk.org/ http://www.tidesdk.org/ You can encapsulate and separate your engine code (which is doing the heavy listing), and just have the client be something that sits on top of it. Sorry, these solutions are quite pie-in-the-sky and I'm sure that you guys are focusing on getting things done (for which L/Tk is perfectly fine), but if you guys are small, I think you might have the agility to move onto a different solution, and I can't help but suggest these things, because I think working on a TCL/TK stack might get things done, but you're gaining experience in a technology that is thoroughly antiquated... So yes, you'll get things done, and you guys will do a great job, but at the end of the day, when it comes time to move to something else, not a lot of the knowledge you gained will be useful?

luckydude 12y ago
So moving to anything is a pile of work, we have 10 different guis in L/Tk: bk citool - graphical check-in tool bk csettool - graphical changeset browser bk difftool - graphical differences viewer bk fm3tool - three-way merge tool bk fmtool - side-by-side merge tool bk helptool - graphical front-end to the help system bk renametool - graphical tool for finding renames bk revtool - graphical history browser bk setuptool - graphical front-end to the setup command bk explorer - file/repo/branch explorer which is about 26,000 lines of code. We're trying to relaunch the company, we've never done any marketing, just coasted on the rep we got from having the Linux kernel use us for a while. Rewriting all the guis is a big task - we need to focus on stuff that will make money or the whole thing will be a moot point :) And we're gonna open source L pretty soon here so maybe that will breath a little life into the tcl/tk ecosystem (and maybe not, I have no way of knowing). L is pretty pleasant, it has replaced perl as my goto scripting language. I'd love it if gcc had an L dialect.