Re: [wxhaskell-devel] Status/development of wxHaskell?
Atze Dijkstra wrote: > Heinrich Apfelmus wrote: > >> Personally, I'm betting on browser-based GUIs, and in particular Chris >> Done's "ji" project >> >> https://github.com/chrisdone/ji >> >> It's not on hackage and I get the impression that Chris has abandoned >> his little experiment, but he has still accepted a patch I've sent. A >> small experiment on my part >> >> http://apfelmus.nfshost.com/blog/2012/10/31-frp-ji.html >> >> has actually convinced me that implementing GUIs in this way is both >> viable and useful. If someone else were to take an interest in Ji as >> well, I'd be very happy to contribute. > > Although I think many GUI's will (eventually) run via a browser, > I also think there is a place for standalone (i.e. non client/server) > apps with a responsive interface with many bells & whistles. > In other words, until the time browser based GUI's like ji > are a reality wxHaskell (and/or gtk2hs) will have to do the job. Oh, I agree completely that desktop applications are still relevant. What I mean to say is just that the Haskell ecosystem currently does not really offer a low-cost and portable way to make simple GUI applications and I think that the browser could fill that niche. In other words, I'm thinking about the "I just want a button" desire, I don't really care that it's in the browser. Both WxHaskell and Gtk2Hs are barely maintained and hard to install. I have gotten so many emails from people that tried and failed to install wxHaskell in order to check out my reactive-banana-wx package. Another example is the hp2any suite for analyzing GHC performance profiles. Unfortunately, I can't use it, because I didn't manage to install Gtk2Hs on my OS X machine. Also, Conal Elliott once remarked that he has stopped working on his legendary graphical tool ideas because the GUI library situation was rather bleak. I think there is a considerable market for a low effort GUI thing that works everywhere. It doesn't have to be great, but I think we're missing out on a lot of brilliant GUI ideas that can't come to fruition because Haskell doesn't have a very simple GUI framework. > For some more ji like experiments see also: > > https://github.com/bertm/Modular-Haskell-GUI > https://github.com/UU-ComputerScience/js-asteroids (using UHC) > > The idea in the latter was to offer a wxHaskell implementation > minimally using code behind a FFI, therefore avoiding as much as > possible maintenance of a non-Haskell codebase. If not done that (or > similar) way we will still end up in a similar situation as is the case > with wxHaskell, i.e. reliance on C++ (or Javascript) code. Nice, these projects look promising and definitely more mature than Ji. What happened to Modular-Haskell-GUI? There's a paper draft in the repository, but I haven't seen it published anywhere. Concerning the non-Haskell code base, Ji uses a quick and dirty interpreter that can execute arbitrary JavaScript commands, so not too much code is spent in JS. This way, the GUI programs can still be written with GHC. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] Status/development of wxHaskell?
Atze Dijkstra wrote: > Related to this, both archives > are inactive anyway since summer 2012, both are also still mentioned > on the wxHaskell wiki, activity on this mailinglist is low, so is any > development/maintenance done at all? > > I am asking these questions as I am fixing a legacy wxHaskell app (7 > years old), and also trying to figure out whether wxHaskell is still > a good way to go for future GUI development. For the record, I like > wxHaskell, but I need to know (probably like others using wxHaskell) > whether wxHaskell (or for that matter, any GUI programming in > Haskell/GHC) is going to be used/maintained in the long run, and for > that some basics (like which repo is used) need to be clear. I can't speak for Jeremy, nor do I wish to step on anyone's toes, but looking at the current project status, I have to conclude that wxHaskell is not actively maintained anymore. I'm interested in GUI programming and I have got some ideas on improving the wxHaskell APIs that are "backported" from FRP, but sadly no one to address them to. So, I'm interested in contributing, but I don't have the time or inclination to maintain a large GUI project myself. Concerning future GUI development, there is GTK2Hs which works quite well on Linux, but is difficult to install on all other platforms. Personally, I'm betting on browser-based GUIs, and in particular Chris Done's "ji" project https://github.com/chrisdone/ji It's not on hackage and I get the impression that Chris has abandoned his little experiment, but he has still accepted a patch I've sent. A small experiment on my part http://apfelmus.nfshost.com/blog/2012/10/31-frp-ji.html has actually convinced me that implementing GUIs in this way is both viable and useful. If someone else were to take an interest in Ji as well, I'd be very happy to contribute. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] Darcs gets too little files
Henk-Jan van Tuyl wrote: > L.S., > > I am trying to fetch the whole repository with the command: >darcs get http://code.haskell.org/wxhaskell/ wxhaskell3 --complete > The command prints the messages: >Official wxHaskell darcs repository >** > It downloads a few files, but none of the source files. Is there something > wrong with the repository? > I used darcs version 2.8.1 and version 2.8.2 on a Windows XP system. As far as I understand, the project has move to github. https://github.com/jodonoghue/wxHaskell Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] Who is reviewing and committing patches
Mads Lindstrøm wrote: > > Who is committing and reviewing patches these days? > > I have made two fixes, which is attached to this email. One is for a fix > that both David Rogers and I experienced. See > http://article.gmane.org/gmane.comp.lang.haskell.wxhaskell.general/1278 > and http://article.gmane.org/gmane.comp.lang.haskell.wxhaskell.devel/861. > > The other fix is to make wxHaskell compile on GHC 7.6.1. > > I made the patches using: > >> darcs send --output "patch_name" --author "Mads Lindstroem" --from >> "Mads Lindstroem" -i If I am informed correctly, the code for wxHaskell lives on https://github.com/jodonoghue/wxHaskell though it appears to be a little dormant lately. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
[wxhaskell-devel] Design discussion - Composable Events
Dear list,
as you probably know, I'm the author of the reactive-banana package,
which is a library for functional reactive programming (FRP) which can
be used with wxHaskell. As such, I would like to propose a few changes
to wxHaskell which are informed by FRP. Of course, while my primary aim
is to gain better interoperability with my library, I think and hope
that my proposed changes are of independent benefit.
Today, I would like discuss *composable events* and event handlers.
In wxHaskell, event handlers are currently set with the on combinator.
set button [ on command := doSomething ]
Unfortunately, this approach has several problems that don't make it
very composable:
1. Currently, setting an event handler will also *remove* any previous
event handler.
2. The event handler may have have several curried parameters, or even none.
I have found that the most composable approach to events is the
following type
type Event a = AddHandler a
newtype AddHandler a = AddHandler { addHandler :: (a -> IO ()) ->
IO (IO ()) }
Example usage
doSometing :: () -> IO ()
...
removeSomething <- addHandler (on command button) doSomething
The idea is that Event a represents an event that carries data of type
a . If the event does not carry any data, then a = () . The
addHandler function registers an additional event handler with the
event, while keeping the old handlers intact. The return value of
addHandler can be used to remove the event handler again if desired.
(This is how GTK does it, by the way.)
With this type, we can easily define new events from old ones, for instance
instance Functor AddHandler where
fmap f e = AddHandler $ \g -> addHandler e (g . f)
filterJust :: AddHandler (Maybe a) -> AddHandler a
filterJust e = AddHandler $ \g -> addHandler e (maybe (return ()) g)
-- mouse click event
click :: AddHandler Point
click = filterJust . fmap matchClick $ mouse
where
matchClick (MouseLeftDown pt _) = Just pt
matchClick _= Nothing
Note that this only works well if the event data always given as a
single type, not multiple curried arguments.
I think this is very pleasant. In particular, it cleans up the confusion
about the current crop of write-only events like click and motion .
It also looks a bit like FRP, though it is not powerful emough to become
"true" FRP for reasons I don't want to go into right now.
The main drawback of the AddHandler approach is that we cannot keep
the current syntax
set button [ on click := .. ]
since setting an event handler rightfully implies that the old event
handlers are removed. I'm somewhat undecided about possible solutions,
but we could introduce a new assignment symbol
set button [ on click :+ .. ]
that only works on events.
What do you think?
Best regards,
Heinrich Apfelmus
--
http://apfelmus.nfshost.com
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] GitHub repo?
Jeremy O'Donoghue wrote:
> Hi developers,
>
> I wanted to canvas opinion about moving wxHaskell development from darcs on
> code.haskell.org to (git, obviously) on GitHub.
>
> Potential advantages:
>
>- Easier for new committers to commit code
>- GitHub provides some pretty decent tools (integrated issue tracker,
>particularly)
>- Easier handling of the wxWidgets 2.8/2.9 branches. I'm pretty
>impressed at the way git does this (and was not impressed by merging Dave
>Tapley's darcsden branch back into the code.haskell.org mainline using
>darcs - this turned out to be a completely manual operation which was no
>fun at all).
>
> Downsides:
>
>- I personally find darcs easier than git, and as Haskellers we should
>promote darcs if possible
>- Possibly a new tool for old hands to learn
>
> I would say that a move is probably only worthwhile if we think that it
> would help to attract new developer to the project.
>
> I have put up an experimental project at
> https://github.com/jodonoghue/wxHaskell which gives an idea how the two
> branches would look.
>
> One option might be to use wxHaskell as a test case for darcs-bridge, in
> which case we could allow commits to darcs or Github, but I'll leave it to
> Eric to decide whether darcs bridge is ready for such a use case.
I'm in favor of a move to GitHub. The barrier to entry is a lot lower.
When creating issues, people will often include a "pull request" (i.e.
patch) if they were able to solve it themselves.
I use Git it for all my projects, but that's mainly because I use a GUI
environment ("SmartGit") so that I don't have to learn the command line.
In other words: I never really learned how Git works and I can still use
it without (major) problems.
Best regards,
Heinrich Apfelmus
--
http://apfelmus.nfshost.com
--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] Happy New Year, wxHaskellers
Jeremy O'Donoghue wrote: > Following shortly afterwards, the very exciting news is that a number of > people (Dave Tapley in particular) have been putting a lot of work over the > last few months towards support of the wxWidgets 2.9 releases. This does > introduce a small number of breaking changes as the wxWidgets API has > changed in places, but brings with it quite a number of improvements: > >- wxC is built as a shared library. This means that wxHaskell works in >GHCi again, which has been one of the most requested bugfixes over the past >18 months or so. Hurray, that promises to be a really happy new year! The bananas will *dance*! Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] Patches to build wxHaskell with wxWidgets 2.9.2 GTK on Linux
Dave Tapley wrote: > Hmm, further to this: > > $ darcs pull > Pulling from "http://code.haskell.org/wxhaskell";... > Official wxHaskell darcs repository > ** > No remote changes to pull in! > $ cd wx > $ cabal configure > Resolving dependencies... > Configuring wx-0.13.1... > Warning: This package indirectly depends on multiple versions of the same > package. This is highly likely to cause a compile failure. > package wxcore-0.13.1 requires containers-0.3.0.0 > package wxdirect-0.13.1 requires containers-0.4.0.0 > package wxcore-0.13.1 requires parsec-2.1.0.1 > package wxdirect-0.13.1 requires parsec-3.1.1 You may need to bump dependency version. Are you using GHC 7.0? The easiest way to proceed is probably to copy the version constraints from the *latest* packages on hackage: http://hackage.haskell.org/package/wx http://hackage.haskell.org/package/wxcore http://hackage.haskell.org/package/wxdirect and then reconfigure, rebuild and reinstall these packages. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] Bug report: wxWidgets crashes when trying to text entry dynamically
Heinrich Apfelmus wrote: > Dmitriy Nikitinskiy wrote: >> Heinrich Apfelmus wrote: >>> Seems to be the same as this bug: >>> >>> http://sourceforge.net/tracker/index.php?func=detail&aid=1826548&group_id=9863&atid=109863 >>> >>> Any workaround? >>> >> On my side this example works ok. >> I have tested on openSuSe 11.4 and WinXp with ghc-7.0.2 and wxWidgets-2.8.11. > > Ah, I should have mentioned that I am on Mac OS X, version 10.6.8 . Apparently, I'm not very good at reporting bugs. I had wxWidgets-2.8.8 which came bundled with the OS. Installing a newer version (2.8.12) via MacPorts fixes the problem. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] Bug report: wxWidgets crashes when trying to text entry dynamically
Dmitriy Nikitinskiy wrote: > Heinrich Apfelmus wrote: >> >> I want to set the text of a text entry while the program is running, but >> wxWidgets/wxHaskell crashes with the following assertion failure: >> >> ../src/common/strinc.pp(410): assert "nStart<= length()" failed in erase() >> >> Here a minimal program that crashes when you click the button: >> >> import Graphics.UI.WX >> >> main = start $ do >> f<- frame[ text := "Test" ] >> e<- entry f [ text := "A" ] >> b<- button f [ text := "Button" >> , on command := set e [ text := "B" ] ] >> set f [ layout := row 5 [ widget b, widget e]] >> >> Seems to be the same as this bug: >> >> http://sourceforge.net/tracker/index.php?func=detail&aid=1826548&group_id=9863&atid=109863 >> >> Any workaround? >> > > On my side this example works ok. > I have tested on openSuSe 11.4 and WinXp with ghc-7.0.2 and wxWidgets-2.8.11. Ah, I should have mentioned that I am on Mac OS X, version 10.6.8 . Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
[wxhaskell-devel] Bug report: wxWidgets crashes when trying to text entry dynamically
Hello, I want to set the text of a text entry while the program is running, but wxWidgets/wxHaskell crashes with the following assertion failure: ../src/common/strinc.pp(410): assert "nStart <= length()" failed in erase() Here a minimal program that crashes when you click the button: import Graphics.UI.WX main = start $ do f <- frame[ text := "Test" ] e <- entry f [ text := "A" ] b <- button f [ text := "Button" , on command := set e [ text := "B" ] ] set f [ layout := row 5 [ widget b, widget e]] Seems to be the same as this bug: http://sourceforge.net/tracker/index.php?func=detail&aid=1826548&group_id=9863&atid=109863 Any workaround? Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
Re: [wxhaskell-devel] Haskell Platform roadmap?
Jeremy O'Donoghue wrote: > - Extend Graphics.UI.WX so that more of the core functionality has > high-level wrappers, e.g. for Grid, List boxes etc. I would love to > see an FRP wrapper around parts of wxHaskell, and think we could > reinstate one or more of the FRP libraries, for example. Making GUI > programming less like C programming would do a lot to promote Haskell > GUI development, but it requires much better Haskell-fu than I have > to offer. I'm currently working on the FRP part [1]. It turns out that FRP is completely orthogonal to wxHaskell; there is no need to add special support for FRP in the GUI library. A handful of convenience wrappers [2] are enough to transform wxHaskell into a fully featured FRP-GUI library. In other words, you can simply focus on the mid-level GUI bindings and get that into the platform. If anything, it would be very useful to fix the GHCi issue. Developing an FRP library is still a very experimental activity and having GHCi support makes prototyping a lot faster. (Conal Elliott would agree with that.) [1]: http://hackage.haskell.org/package/reactive-banana [2]: http://hackage.haskell.org/package/reactive-banana-wx Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ wxhaskell-devel mailing list wxhaskell-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
