sbazgui
Locked
 
|
...provides a simple GUI to some of sbaz's functionality (thanks to Lex
for a clean library -- I did not have a single problem while putting sbazgui together. sbaz install sbazgui ...will give you 0.1, and make it exceptionally convenient for you to stay up to date. Note that I have only tested on XP so far; I'll have to get some Linux installed and see what happens -- it should be OK, as it is quite "vanilla". Note that sbazgui looks particularly good if you have the Substance Look and Feel installed as a Java extension. Start it with "sbazgui", and ignore the ugly console junk that will be gone by 0.2 ;) The first time you run you'll be asked to find your sbaz directory (mine is d:\scala-2.1.0); that value is stored with Java's preferences facility. sbazgui always retrieves the latest package list on startup, shows you what you have installed, and where you can update. It can install individual packages, update them, or upgrade all (corresponding to sbaz commands). The gui clears away some of the version information so you can see what you have, and what the latest version is. sbazgui took about six hours (including sbaz packaging) to write in Sean's Eclipse environment, and a good part of that was spent on trying various forms of Scala syntax to handle common GUI issues. All in all, it's going to be depressing the next time I write GUI code in Java...I've got premonitions of irritation already. ;) Once you get the feel of the language _and the type system_, Scala's "it just works" factor starts to escalate rapidly. Some things I particularly liked: def loadNews = busyThread { val rss = xml.XML.load(new java.net.URL("http://scala.epfl.ch/rss.xml").openStream()); val html = (rss \\ "item" \ "description").foldLeft( new Stringer("<html><body style='font-size:small; font-family:sans-serif'>"))( (sb,d) => sb + repl(d.text, "<div>", "", "</div>", "","<hr />", "","<p />", "<br>","<br />", "<br>") + "<hr>") + "</body></html>"; swing { news.text = html.toString; news.root.setCaretPosition(0) } } That bit of code drops into a worker thread, sets up a wait cursor, reaches out to the Scala web site, pulls down the RSS feed, parses it into XML, does xpath across the XML to extract news article descriptions, chops them up into HTML more to Swing's liking, hops back to the swing thread to insert the text into a news pane, puts back the normal cursor, and ends the thread. All in all, not bad for 8 lines of code -- and it could have been less. ;) This declares a button and sets up a handler: val upgradeButton = new SButton("Upgrade All")({updateAll}) I assemble GUI elements like this: val main = new SPanel().inset(4) + North(titlePanel) + West(newsPanel) + Center(new SScrollPane(table)) val time = new SLabel("<time>").etched val status = new SLabel("<Status>").etched this + South(new SPanel().inset(4) + West(time) + East(status)) + Center(main) Again, very concise but readable syntax. When I pull away the library code, sbazgui is only 220 lines of code. RJ |
|
|
This looks really great, Ross! It is fun having a nice-looking GUI
app on the bazaar. By the way, there is a scala.home property that gets set automatically for you. It points to the sbaz directory that the program is run out of. All (sbaz-based) programs can use this to find any other files you need. For sbazgui in particular, you can use it as the default sbaz directory to manage. Do you intend to tinker on sbazgui any more? -Lex |
|
|
In reply to this post by Judson, Ross
There are quite a few things I'd like to add...
- change/handle multiple sbaz directories and switch between them - auto-create "news" of new/change packages - sorting/filtering - categories (I'd like to see sbaz support a notion of nested categories -- we'll need it sooner or later) - automatic filtering out of placeholders unless they can be removed - "peek" feature shows contents/structure of selected package - click on Scala logo goes to the website - tooltips for everything - right-click context menus - prefs for window size/position - Substance look and feel, if available - move GUI classes to a private package so they don't interfere with other stuff - "helper" mode (glass pane superimposes semi-transparent tooltips) on startup From sbaz, I'd like to see a "compile from source" command/standard (and accompanying meta description for packages), and support for nested categories. I like the way the CygWin installer lets you see what's available, auto-install groups, etc...that's probably the direction we should move. RJ -----Original Message----- From: news [mailto:[hidden email]] On Behalf Of Lex Spoon Sent: Tuesday, April 04, 2006 12:22 PM To: [hidden email] Subject: Re: sbazgui This looks really great, Ross! It is fun having a nice-looking GUI app on the bazaar. By the way, there is a scala.home property that gets set automatically for you. It points to the sbaz directory that the program is run out of. All (sbaz-based) programs can use this to find any other files you need. For sbazgui in particular, you can use it as the default sbaz directory to manage. Do you intend to tinker on sbazgui any more? -Lex |
|
|
"Judson, Ross" <[hidden email]> writes:
> There are quite a few things I'd like to add... > > - change/handle multiple sbaz directories and switch between them > - auto-create "news" of new/change packages > - sorting/filtering > - categories (I'd like to see sbaz support a notion of nested categories > -- we'll need it sooner or later) > - automatic filtering out of placeholders unless they can be removed > - "peek" feature shows contents/structure of selected package > - click on Scala logo goes to the website > - tooltips for everything > - right-click context menus > - prefs for window size/position > - Substance look and feel, if available > - move GUI classes to a private package so they don't interfere with > other stuff > - "helper" mode (glass pane superimposes semi-transparent tooltips) on > startup All very cool stuff. Also, do not forget feature completeness. If the GUI only offers a subset of the available functionality, then there is a limit on where it is useful. Browsing through all the "help" documentation for the command line is probably worthwhile. > > From sbaz, I'd like to see [...snip...] support for nested > categories. Sure. I'll put that on the list.... > > I like the way the CygWin installer lets you see what's available, > auto-install groups, etc...that's probably the direction we should move. > Actually, package groups are already present on one form. An example is the package named "scala". It contains no files itself, but it depends on all the development-tool packages. -Lex |
|
|
In reply to this post by Judson, Ross
> From sbaz, I'd like to see a "compile from source" command/standard (and
> accompanying meta description for packages) This is not as trivial as it sounds. The current strategy, at least for the scala-dev bazaar, is that people post built, ready-to-run packages. If a built package is broken with respect to other packages on the bazaar, then one package or the other needs to be fixed. The main advantage to compiling sources is that Scala source is more compatible than the resulting .class files. That is, interfaces can stay compatible even though the .class files change in incompatible ways. Distributing in source would increase the likelihood of two packages being able to be used together. Have I missed another advantage? There are a number of negative issues that seem to outweigh this benefit. Here are some that come to mind. First, build dependencies are much larger than install dependencies. Consider things like ant, ant-contrib, javac, perl, python, scsh, automake, jam, etc. If we build at the installation sites, then we have to figure out a way to ensure that installation sites have all of these extra dependencies. The dependencies either need to be on the bazaar, or we need to tell people that they must have them installed separately before they can build packages. This problem is compounded by build dependencies being difficult to work out accurately anyway. Speaking from experience with Debian packages, it is very easy to overlook things like using the "tree" utility or depending on "bash" when you meant to depend only on "sh". Both answers to "should we automatically compile at install time" give bad results. If we say yes, then install times become much slower. To contrast, if we do not build-at-install, then what hope do we have of getting the build-time install scripts working correctly for each package? Untested code is broken code. Compilation is not perfectly deterministic once you take into consideration all the build dependencies. If we compile-at-install time, then people will be installing code that is not exactly the same code the developer tested. As an alternative, I have thought about addressing this tradeoff by using a multi-stage build process. All code in packages would be pure Scala code. This approach would mean that we'd get the advantage of source-code compatibility (the main reason I can think of to have install-time building), while not having extra build dpeendencies like ant. However, as tempting as this is, notice that not all source code can be converted to Scala code! The Scala compiler, for example, contains a small number of non-Scala files that simply cannot be converted into Scala code. Worse, some packages, e.g. junit and servlet-api, are pure Java code! Finally, to curtail one dead-end path, notice that source packages never give the real source in practice. The real source is in a CVS or SVN repository somewhere. If you want to hack on a project, don't grab its source package--go to its web site and follow the directions you see. And if you don't want to hack, but instead just browse the code, you should look at the /src hierarchy in your sbaz directory.... -Lex |
|
|
In reply to this post by Judson, Ross
For those who've tried it, if you use it to catch up to the latest scala
packages, could you let me know if it works for you, or if anything goes wrong when you do the upgrade? [hidden email] Thanks! |
|
|
"Judson, Ross" <[hidden email]> writes:
> For those who've tried it, if you use it to catch up to the latest scala > packages, could you let me know if it works for you, or if anything goes > wrong when you do the upgrade? I have upgraded it a few times at this point via "sbaz upgrade" and it always seems to keep chugging along just great! I am usually thinking of upgrading something else when I do it, and happen to notice that there is a new sbazgui version coming down along with it. Cool! -Lex |
«
Return to Scala - Language
|
1 view|%1 views
| Free forum by Nabble | Edit this page |