You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(6) |
Jul
(27) |
Aug
(17) |
Sep
|
Oct
(8) |
Nov
(23) |
Dec
(17) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(43) |
Feb
(12) |
Mar
(10) |
Apr
(12) |
May
(16) |
Jun
(15) |
Jul
(15) |
Aug
|
Sep
(1) |
Oct
(25) |
Nov
(39) |
Dec
(7) |
2004 |
Jan
(12) |
Feb
|
Mar
(1) |
Apr
(48) |
May
(44) |
Jun
(17) |
Jul
(38) |
Aug
(42) |
Sep
(17) |
Oct
(12) |
Nov
(7) |
Dec
(14) |
2005 |
Jan
(67) |
Feb
(59) |
Mar
(47) |
Apr
(78) |
May
(15) |
Jun
(59) |
Jul
(38) |
Aug
(28) |
Sep
(11) |
Oct
(16) |
Nov
(27) |
Dec
(7) |
2006 |
Jan
(11) |
Feb
(17) |
Mar
(16) |
Apr
(8) |
May
(16) |
Jun
(22) |
Jul
(5) |
Aug
(1) |
Sep
(6) |
Oct
(32) |
Nov
(42) |
Dec
(24) |
2007 |
Jan
(44) |
Feb
(25) |
Mar
(54) |
Apr
(21) |
May
(47) |
Jun
(13) |
Jul
(30) |
Aug
(34) |
Sep
(9) |
Oct
(37) |
Nov
(28) |
Dec
(27) |
2008 |
Jan
(21) |
Feb
(17) |
Mar
(38) |
Apr
(26) |
May
(15) |
Jun
(44) |
Jul
(62) |
Aug
(49) |
Sep
(66) |
Oct
(86) |
Nov
(43) |
Dec
(128) |
2009 |
Jan
(134) |
Feb
(120) |
Mar
(113) |
Apr
(39) |
May
(121) |
Jun
(81) |
Jul
(79) |
Aug
(87) |
Sep
(54) |
Oct
(40) |
Nov
(26) |
Dec
(21) |
2010 |
Jan
(30) |
Feb
(44) |
Mar
(57) |
Apr
(46) |
May
(117) |
Jun
(69) |
Jul
(51) |
Aug
(103) |
Sep
(62) |
Oct
(24) |
Nov
(37) |
Dec
(50) |
2011 |
Jan
(21) |
Feb
(12) |
Mar
(16) |
Apr
(9) |
May
(25) |
Jun
(19) |
Jul
(13) |
Aug
(8) |
Sep
(31) |
Oct
(26) |
Nov
(16) |
Dec
(10) |
2012 |
Jan
(5) |
Feb
(9) |
Mar
(19) |
Apr
(17) |
May
(7) |
Jun
(16) |
Jul
(11) |
Aug
(14) |
Sep
(10) |
Oct
(1) |
Nov
(10) |
Dec
(38) |
2013 |
Jan
(9) |
Feb
(16) |
Mar
(11) |
Apr
(1) |
May
(3) |
Jun
(3) |
Jul
|
Aug
(11) |
Sep
(11) |
Oct
(3) |
Nov
(4) |
Dec
(8) |
2014 |
Jan
|
Feb
(4) |
Mar
(13) |
Apr
(3) |
May
(17) |
Jun
|
Jul
(4) |
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(7) |
Dec
|
2015 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(4) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(10) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <gd...@iu...> - 2016-05-14 16:17:24
|
Is http://projects.haskell.org/gtk2hs/ still the home page for Gtk2hs? Both http://hackage.haskell.org/package/gtk3 and https://wiki.haskell.org/Gtk2hs identify it as the Gtk2hs home page, but when I visit http://projects.haskell.org/gtk2hs/ today, I get either "Error establishing a database connection" or another error message, but usually that one. Other project directories on http://projects.haskell.org/ are not showing this error message. -- Gregory D. Weber, Ph. D. http://pages.iu.edu/~gdweber/ Associate Professor of Informatics Tel (765) 973-8420 Indiana University East FAX (765) 973-8550 |
From: Brandon A. <all...@gm...> - 2015-06-26 14:47:19
|
On Fri, Jun 26, 2015 at 7:42 AM, Hi-Angel <hia...@gm...> wrote: > Aren't there just a function to move a cursor by one character > left/right in TextBuffer or TextView? > There isn't one in Gtk (or wasn't last time I looked), so there isn't one in gtk2hs. I suspect they believe that to be an abuse of something intended for user, not programmatic, control. -- brandon s allbery kf8nh sine nomine associates all...@gm... bal...@si... unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net |
From: Hi-Angel <hia...@gm...> - 2015-06-26 11:43:03
|
Sorry if it's silly question, I am new to the lib, but from what I've found so far from documentation I am approaching to a conclusion that for that simple operation I have to build an exuberant construction where I have to take a mark with "insert" name, then take a position of this mark, then somehow construct a new position by decrementing the position I got by one, then set the new position of the "insert" mark… Aren't there just a function to move a cursor by one character left/right in TextBuffer or TextView? |
From: David D. <D.J...@le...> - 2015-06-25 15:25:39
|
I’m porting some code (specifically, part of ThreadScope) from Gtk2 to Gtk3 and trying to get my head around the revised relationship between Cairo, Pixbufs, and Gtk widgets. In the Gtk2 implementation there is a function that uses Cairo to render onto a window, then extracts the pixbuf: renderToPixbuf :: DrawableClass dw => dw -> (Int, Int) -> Cairo.Render () -> IO Pixbuf renderToPixbuf similar (w, h) draw = do pixmap <- pixmapNew (Just similar) w h Nothing renderWithDrawable pixmap draw Just pixbuf <- pixbufGetFromDrawable pixmap (Rectangle 0 0 w h) return pixbuf In Gtk3, I can use renderWithDrawWindow, but am then unclear how to retrieve the Pixbuf: in particular, the following *doesn’t* work becasue the DrawWindow dw isn't itself a surface: renderToPixbuf :: DrawWindow -> (Int, Int) -> Cairo.Render () -> IO Pixbuf renderToPixbuf dw (w, h) draw = do renderWithDrawWindow dw draw pixbuf <- pixbufNewFromSurface dw 0 0 w h return pixbuf Online documentation for the stable release of *GDK* (3.16 - https://developer.gnome.org/gdk3/3.16/) notes a C function gdk_pixbuf_get_from_surface () but this doesn’t appear to be defined in the GTK3 0.13.8 package on Hackage. Can anyone point to how to get the pixbuf, or to a better approach? thanks, David. |
From: Ivan P. <iva...@gm...> - 2015-05-13 14:00:10
|
Thank you both for your insight. I've been looking around and I can't find any way to check if one has the gdk lock, so a general solution to this problem would require a global thread-id variable, a custom "pseudo-main" thread and a channel to post opts to be executed in the main thread with the gdk lock. I'm writing a reactive library that encloses all widget properties into reactive values, and should alleviate this pain (also, I'd say inversion of control goes away). Although users can still combine gtk event handlers with reactive values in the same application (should be safe), the idea is that they use this new API and all thread-handling is done for them. Best Ivan On 13 May 2015 at 08:48, koral <ko...@ma...> wrote: >> > (Since we don't have a Gtk monad, and to avoid passing the threadID >> > around, a dirty workaround could be to store the GUI thread ID in some >> > global variable and create wrapping functions that get the current GUI >> > thread, compare and use postGUI(A)Sync only if different.) >> > >> >> I think this solution might work and is not as bad as it seems since there already is some global state that ensures that gtkInit is not called several times. > > I had a try at this some time ago, and I noticed that, unexpectedly, `Control.Concurrent.myThreadId` doesn't return a constant value when it is called from a signal handler. > For example (I've just reproduced it with the demo program bundled with webkitgtk3): > > -- Main thread > print =<< myThreadId > > -- Open uri when user press `return` at address bar. > addressBar `on` entryActivated $ do > print =<< myThreadId -- Will print a distinct value each time it is invoked > -- (...) > > While the documentation says that signal handlers are run within gtk's main loop thread, this experiment suggests that a fork thread is created to run a handler, and that the main loop waits for its termination. > So unless I'm mistaken, it looks like you can't rely on the thread ID to decide whether you can safely call postGUISync. > > Cheers. |
From: koral <ko...@ma...> - 2015-05-13 07:49:15
|
> > (Since we don't have a Gtk monad, and to avoid passing the threadID > > around, a dirty workaround could be to store the GUI thread ID in some > > global variable and create wrapping functions that get the current GUI > > thread, compare and use postGUI(A)Sync only if different.) > > > > I think this solution might work and is not as bad as it seems since there already is some global state that ensures that gtkInit is not called several times. I had a try at this some time ago, and I noticed that, unexpectedly, `Control.Concurrent.myThreadId` doesn't return a constant value when it is called from a signal handler. For example (I've just reproduced it with the demo program bundled with webkitgtk3): -- Main thread print =<< myThreadId -- Open uri when user press `return` at address bar. addressBar `on` entryActivated $ do print =<< myThreadId -- Will print a distinct value each time it is invoked -- (...) While the documentation says that signal handlers are run within gtk's main loop thread, this experiment suggests that a fork thread is created to run a handler, and that the main loop waits for its termination. So unless I'm mistaken, it looks like you can't rely on the thread ID to decide whether you can safely call postGUISync. Cheers. |
From: Axel S. <Axe...@in...> - 2015-05-12 14:45:26
|
Hi Ivan, > On May 12, 2015, at 3:41 AM, Ivan Perez <iva...@gm...> wrote: > > Dear all > > I know that there exist postGUIAsync and postGUISync to execute code > in the GUI thread. > > However, the thread locks if one calls postGUISync from the GUI thread > (nested calls to postGUISync are therefore not allowed). I would like > to ask if there's a way to work around that, with postGUI(A)Sync being > called only if the current computation is not being executed in the > GUI thread already. > > (Since we don't have a Gtk monad, and to avoid passing the threadID > around, a dirty workaround could be to store the GUI thread ID in some > global variable and create wrapping functions that get the current GUI > thread, compare and use postGUI(A)Sync only if different.) > I think this solution might work and is not as bad as it seems since there already is some global state that ensures that gtkInit is not called several times. Cheers, Axel > Regards > Ivan > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Gtk2hs-users mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users |
From: Ivan P. <iva...@gm...> - 2015-05-12 10:42:06
|
Dear all I know that there exist postGUIAsync and postGUISync to execute code in the GUI thread. However, the thread locks if one calls postGUISync from the GUI thread (nested calls to postGUISync are therefore not allowed). I would like to ask if there's a way to work around that, with postGUI(A)Sync being called only if the current computation is not being executed in the GUI thread already. (Since we don't have a Gtk monad, and to avoid passing the threadID around, a dirty workaround could be to store the GUI thread ID in some global variable and create wrapping functions that get the current GUI thread, compare and use postGUI(A)Sync only if different.) Regards Ivan |
From: koral <ko...@ma...> - 2015-02-25 23:21:31
|
Hello, There are several issues: - the package from hackage (which you can get via 'cabal unpack arguedit') is missing many files, and obviously cannot build as is; - the project from github is (at least) missing the cabal files necessary to 'cabal build' the project; I guess I could merge files from hackage and github, but I'm too lazy for that :) - you put upper bounds on the dependency constraints of your project, so it's not surprising that a program made "a while ago" doesn't build anymore; the Haskell ecosystem evolves quickly, in a non-backward compatible way, and newer versions of the dependencies are required to simply stay up-to-date; I had to lift the constraints on base, HDBC, glib and gtk to be able to even start building the project. Friendly note: next time, please provide more detail about the error you're getting, rather than expecting us to try by ourselves. Also, as far as I've investigated, the issues aren't related to gtk2hs, so here may not be the right place to ask for help :) . Cheers. |
From: Michael S. <MS...@gm...> - 2015-02-24 17:28:44
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hi,</div> <div> </div> <div>I made a program a while ago that uses gtk2hs.</div> <div>But on a recent Ubuntu (14.10) I got problems installing it.</div> <div> </div> <div>Please let me know if you know how to install the relevant packages.</div> <div>It seems gtk2hs isnt inside of the repositories and cabals cairo also failed miserably to install.</div> <div>So I tried it without cabal.</div> <div> </div> <div>Feel free to test it, its here:</div> <div><a href="https://github.com/Hrazel/arguedit.git">https://github.com/Hrazel/arguedit.git</a></div> <div> </div> <div>https://hackage.haskell.org/package/arguedit</div> <div> </div> <div>And what OS do you use to haskell?</div> <div> </div> <div>Thanks a lot</div> <div> </div> <div>Best regards J.M.</div> <div> </div></div></body></html> |
From: Axel S. <Axe...@in...> - 2014-11-04 06:45:26
|
Hi Koral, On 03.11.2014, at 22:42, koral <ko...@ma...> wrote: >> what is the GUI supposed to do until your application logic decides whether the document should be opened or rendered? It can only wait. > > It doesn't make sense to me: thread A could very well keep processing pending GUI events, while thread B is busy taking a decision. > The mimeTypePolicyDecisionRequested signal is notably emitted when a link is clicked. I see no reason why GTK should block the GUI between the moment the link is clicked, and the moment the decision to render/download it is made. > If the decision takes some time, it makes perfect sense to be able to scroll the currently displayed webpage in the meantime. > Ok, fair enough. I guess the Gtk+ developers thought that this decision can and should be taken instantaneously. Implementing this asynchronously is harder, possibly acceptably harder in Haskell, probably too hard in C. > >> Hm, I always thought having the same Monad for the main loop and the event handlers is the difficult but desirable goal which can only be achieved by wrapping each code that serves an even handler with a lifting to the desired application monad. Aren't multithreading and lifting into a different monad two orthogonal things? > > Sure, I simply meant that separating signal emission/handling in distinct threads naturally leads to separate monad stacks, which is what I'm striving for. I can see that using a different thread forces you to pick a new monad stack. Cheers, Axel |
From: koral <ko...@ma...> - 2014-11-03 21:42:49
|
> what is the GUI supposed to do until your application logic decides whether the document should be opened or rendered? It can only wait. It doesn't make sense to me: thread A could very well keep processing pending GUI events, while thread B is busy taking a decision. The mimeTypePolicyDecisionRequested signal is notably emitted when a link is clicked. I see no reason why GTK should block the GUI between the moment the link is clicked, and the moment the decision to render/download it is made. If the decision takes some time, it makes perfect sense to be able to scroll the currently displayed webpage in the meantime. > Hm, I always thought having the same Monad for the main loop and the event handlers is the difficult but desirable goal which can only be achieved by wrapping each code that serves an even handler with a lifting to the desired application monad. Aren't multithreading and lifting into a different monad two orthogonal things? Sure, I simply meant that separating signal emission/handling in distinct threads naturally leads to separate monad stacks, which is what I'm striving for. -- koral |
From: Axel S. <Axe...@in...> - 2014-11-03 14:24:39
|
Hi, On 03.11.2014, at 13:40, koral <ko...@ma...> wrote: >> So it seems that you want to lookup the type of a file in parallel. If Gtk+ would allow you to arbitrarily delay a signal handler (so that you wouldn’t even have to spawn a new thread during the signal handler) then the GUI would be unresponsive until all these threads have returned a result. If determining the mime type means opening the file and this file sits on a network that is down then you need a timeout and your GUI would be unresponsive until this timeout has run out. > > Regarding the example of mimeTypePolicyDecisionRequested, the final decision is essentially whether to render or download a file. Why should the main GUI loop wait for this decision ? In other words, using my code example, why should thread A wait for thread B to end ? It kind of defeats the purpose of having thread B != thread A. It seems to me that this constraint imposed by gtk is unnecessarily too strong. > I’d be the last to defend the Gtk+ API design, but: what is the GUI supposed to do until your application logic decides whether the document should be opened or rendered? It can only wait. So there is little reason to raise the event and have a different API call deliver the answer (which would be the for, e.g. creating a preview of a file based on it’s content of mime-type, since here a generic icon could be displayed). So for querying this kind of information a two-thread solution doesn’t seem to be a win. > >> In a nutshell: a good (responsive) GUI is built by always returning immediately form an event; a true parallel event implementation would not make it any easier to fulfilling this goal. > > My concern is more about code separation/isolation rather than concurrency, notably I'd like to run the UI thread and the signal handlers in distinct monad stacks, and concurrency seemed a good way to achieve that. If you have an idea on how to do it differently, I'm all ears. Hm, I always thought having the same Monad for the main loop and the event handlers is the difficult but desirable goal which can only be achieved by wrapping each code that serves an even handler with a lifting to the desired application monad. Aren't multithreading and lifting into a different monad two orthogonal things? Cheers, Axel |
From: koral <ko...@ma...> - 2014-11-03 12:40:20
|
> So it seems that you want to lookup the type of a file in parallel. If Gtk+ would allow you to arbitrarily delay a signal handler (so that you wouldn’t even have to spawn a new thread during the signal handler) then the GUI would be unresponsive until all these threads have returned a result. If determining the mime type means opening the file and this file sits on a network that is down then you need a timeout and your GUI would be unresponsive until this timeout has run out. Regarding the example of mimeTypePolicyDecisionRequested, the final decision is essentially whether to render or download a file. Why should the main GUI loop wait for this decision ? In other words, using my code example, why should thread A wait for thread B to end ? It kind of defeats the purpose of having thread B != thread A. It seems to me that this constraint imposed by gtk is unnecessarily too strong. > In a nutshell: a good (responsive) GUI is built by always returning immediately form an event; a true parallel event implementation would not make it any easier to fulfilling this goal. My concern is more about code separation/isolation rather than concurrency, notably I'd like to run the UI thread and the signal handlers in distinct monad stacks, and concurrency seemed a good way to achieve that. If you have an idea on how to do it differently, I'm all ears. -- koral |
From: Axel S. <Axe...@in...> - 2014-11-03 08:04:39
|
Hi Koral, On 02.11.2014, at 19:33, koral <ko...@ma...> wrote: > Hello, > > I'm attaching to this mail a commented piece of code that exposes a design issue I'm having. > > Basically, I'm trying to separate the code that emits a GUI signal, from the code that handles it. > The issue is that some gtk2hs signals expect a result in return (e.g. Graphics.UI.Gtk.WebKit.WebView.mimeTypePolicyDecisionRequested). > I implemented this through MVar-s, but this creates a deadlock as detailed in the example code. > > I'm now wondering: > * was separating emitter and handler in distinct threads a good idea in the first place ? It looks to me that such design would provide a great isolation (e.g. running emitter and handler in separate monads) > * am I right to conclude that it is impossible to implement such design, as suggested by the attached example ? > > Thank you in advance for your insights. > Brandon said that the underlying Gtk library “pretty much prohibits this” which is true but it is a bit unfair since there are hardly any GUI libraries out there that are truly concurrent. I believe that the reason for this is the high conceptual complexity that full concurrency would entail and that this would lead to little gain: So it seems that you want to lookup the type of a file in parallel. If Gtk+ would allow you to arbitrarily delay a signal handler (so that you wouldn’t even have to spawn a new thread during the signal handler) then the GUI would be unresponsive until all these threads have returned a result. If determining the mime type means opening the file and this file sits on a network that is down then you need a timeout and your GUI would be unresponsive until this timeout has run out. How would one then make the GUI more responsive? By using an inaccurate mime type to start off with and then slowly fill in the actual mime types as the various files have been identified. This idea, however, can readily be implemented by the even-queue nonpreemptive multitasking that Gtk (and most other) toolkits implement: upon the initial signal, spawn a thread to determine the mime type and return immediately with the unknown type. Upon the thread’s completion, it uses postGUI to update the specific mime type of a file. In a nutshell: a good (responsive) GUI is built by always returning immediately form an event; a true parallel event implementation would not make it any easier to fulfilling this goal. Cheers, Axel > -- > koral > <example.hs>------------------------------------------------------------------------------ > _______________________________________________ > Gtk2hs-users mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users |
From: Brandon A. <all...@gm...> - 2014-11-02 18:53:18
|
On Sun, Nov 2, 2014 at 1:33 PM, koral <ko...@ma...> wrote: > * was separating emitter and handler in distinct threads a good idea in > the first place ? It looks to me that such design would provide a great > isolation (e.g. running emitter and handler in separate monads) > * am I right to conclude that it is impossible to implement such design, > as suggested by the attached example ? > It would be nice, but the design of the underlying gtk library pretty much prohibits it; it plays very badly with threads in any language. -- brandon s allbery kf8nh sine nomine associates all...@gm... bal...@si... unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net |
From: koral <ko...@ma...> - 2014-11-02 18:50:55
|
Hello, I'm attaching to this mail a commented piece of code that exposes a design issue I'm having. Basically, I'm trying to separate the code that emits a GUI signal, from the code that handles it. The issue is that some gtk2hs signals expect a result in return (e.g. Graphics.UI.Gtk.WebKit.WebView.mimeTypePolicyDecisionRequested). I implemented this through MVar-s, but this creates a deadlock as detailed in the example code. I'm now wondering: * was separating emitter and handler in distinct threads a good idea in the first place ? It looks to me that such design would provide a great isolation (e.g. running emitter and handler in separate monads) * am I right to conclude that it is impossible to implement such design, as suggested by the attached example ? Thank you in advance for your insights. -- koral |
From: Joachim B. <no...@de...> - 2014-09-12 14:23:10
|
Hi, it seems to me that upgrading gtk to 0.13 is not possible without removing glade, gstreamer, gtkglext and libtagc. What is the status of these packages: Are they obsolete, or just late to be updated? Thanks, Joachim -- Joachim "nomeata" Breitner Debian Developer no...@de... | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: no...@jo... | http://people.debian.org/~nomeata |
From: koral <ko...@ma...> - 2014-08-19 16:25:48
|
Hello, Since gtk2hs 0.13, every function that used to be fed with a String, can now be fed with either a String or a Text. This was implemented using the typeclass GlibString that has 2 instances: String and Text. In your case, GHC was unable to deduce alone which one to use for the last argument of pixbufSave: the value [] doesn't help disambiguating between [(String, String)] and [(Text, Text)]. To fix it, simply write the type explicitly: pixbufSave pb toPath jpegImageFormat ([] :: [(T.Text, T.Text)]) Regards. |
From: Antonin D. (lists) <li...@an...> - 2014-08-19 16:05:25
|
Hi! With GTK 3 (gtk2hs 0.12.5.7), this code compiles fine (at least on my system). Which version of gtk2hs are you using? Cheers, Antonin On 19/08/2014 16:44, Bram Neijt wrote: > import Graphics.UI.Gtk.Gdk.Pixbuf > import System.Glib.UTFString > import qualified Data.Text as T > > jpegImageFormat :: ImageFormat > jpegImageFormat = pixbufGetFormats !! 6 > > pixbufSaveJpeg :: Pixbuf -> FilePath -> IO() > pixbufSaveJpeg pb toPath = > pixbufSave pb toPath jpegImageFormat [] > > scaleFile :: FilePath -> FilePath -> IO () > scaleFile fromPath toPath = do > original <- pixbufNewFromFile fromPath > scaled <- pixbufScaleSimple original 800 800 InterpHyper > putStrLn toPath > pixbufSaveJpeg scaled toPath > > main = scaleFile "hanginthere.jpg" "scaledinthere.jpg" |
From: Bram N. <bn...@gm...> - 2014-08-19 15:44:33
|
Hi, I'm a Haskell beginner and wanted to use gtk2hs to load, scale and save a jpeg image. The code I have so far is: import Graphics.UI.Gtk.Gdk.Pixbuf import System.Glib.UTFString import qualified Data.Text as T jpegImageFormat :: ImageFormat jpegImageFormat = pixbufGetFormats !! 6 pixbufSaveJpeg :: Pixbuf -> FilePath -> IO() pixbufSaveJpeg pb toPath = pixbufSave pb toPath jpegImageFormat [] scaleFile :: FilePath -> FilePath -> IO () scaleFile fromPath toPath = do original <- pixbufNewFromFile fromPath scaled <- pixbufScaleSimple original 800 800 InterpHyper putStrLn toPath pixbufSaveJpeg scaled toPath main = scaleFile "hanginthere.jpg" "scaledinthere.jpg" The ghc 7.8.3 will complains with: src/Main.hs:18:9: No instance for (GlibString string0) arising from a use of ‘pixbufSave’ The type variable ‘string0’ is ambiguous Note: there are several potential instances: instance GlibString T.Text -- Defined in ‘System.Glib.UTFString’ instance GlibString [Char] -- Defined in ‘System.Glib.UTFString’ In the expression: pixbufSave pb toPath jpegImageFormat [] In an equation for ‘pixbufSaveJpeg’: pixbufSaveJpeg pb toPath = pixbufSave pb toPath jpegImageFormat [] How can I solve this? Are there any examples of using pixbufSave? Greetings, Bram |
From: Unknown <alf...@gm...> - 2014-07-27 21:23:34
|
Hello, first of all, thank you so much for making Gtk2Hs work with GTK 3. There is a problem with ComboBox and GTK 3: the combo boxes don't display their popup. ComboBoxText works right, though. Here is an example. If I compile it against the gtk package, everything works well. But if I compile it against the gtk3 package, only the ComboBoxText displays its popup. module Main where import Graphics.UI.Gtk list = [ stockOk, stockCancel, stockEdit, stockDialogInfo, stockDialogQuestion, stockDialogWarning, stockDialogError ] main = do initGUI w <- windowNew on w objectDestroy mainQuit set w [windowDefaultWidth := 100] b <- vBoxNew True 4 l <- listStoreNew list c1 <- comboBoxNew s1 <- cellRendererPixbufNew cellLayoutPackStart c1 s1 True cellLayoutSetAttributes c1 s1 l $ \r -> [cellPixbufStockId := r] comboBoxSetModel c1 $ Just l c2 <- comboBoxNew s2 <- cellRendererTextNew cellLayoutPackStart c2 s2 True cellLayoutSetAttributes c2 s2 l $ \r -> [cellText := r] comboBoxSetModel c2 $ Just l t <- comboBoxNewText mapM_ (comboBoxAppendText t) list boxPackStart b c1 PackNatural 0 boxPackStart b c2 PackNatural 0 boxPackStart b t PackNatural 0 containerAdd w b widgetShowAll w mainGUI After reading the documentation for both packages I could not find any implementation changes, so I think there might be a bug in the gtk3 package. Best regards, Alfonso Villén |
From: Hamish M. <ham...@gm...> - 2014-07-27 09:37:58
|
Sorry about the slow response, but I wanted to try it out first. Avoiding breaking existing code is my main concern. I don't want people to stick with Gtk2Hs 0.12. Switching from String to Text is not always easy. There might also be performance implications. I think Text is UTF16 and Gtk is UTF8 so String <-> Text <-> Gtk may be slower than just String <-> Gtk (assuming you still wind up with some String types. So here is what I have found while experimenting with Leksah. I had already updated Leksah to use the new GlibString class. But it was still relying on String support in Gtk2Hs quite a bit. I added a (Text ~ s) constraint to GlibString. Something like this... class (Text ~ s, ...) => GlibString s where ... This disabled the String support and avoided type inference problems. I went about fixing up Leksah. I could have added T.pack and T.unpack everywhere Gtk was used, but that would have been horrible. Instead I replaced String with Text in as much of Leksah as possible. It took 3 weekends to migrate from and there were some things I did not bother with. I then added support for String back into Gtk2Hs (took out the constraint). I was able to add the type annotations needed to fix up the code just a couple of hours. If people choose to stay with String for now I think we should not make them add any code (pack and unpack) that they would have to remove when they move to Text. If you are migrating to Text you may need to add a few more type annotations than you would have to if we just supported Text, but it is less annoying to do when you are updating your code to use Text anyway. I think we should wait until Text is more widely used before dropping support for String. On 10 Jul 2014, at 01:38, Felipe Lessa <fel...@gm...> wrote: > Just out of curiosity, why still support String? Any reason beside > avoiding to break the code even harded (needing more than just a type sig)? > > Cheers! =) > > -- > Felipe. > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft_______________________________________________ > Gtk2hs-users mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users |
From: Felipe L. <fel...@gm...> - 2014-07-09 13:38:51
|
Just out of curiosity, why still support String? Any reason beside avoiding to break the code even harded (needing more than just a type sig)? Cheers! =) -- Felipe. |
From: Hamish M. <ham...@gm...> - 2014-07-08 10:22:38
|
I have posted to the Gtk2Hs blog about adding Text support in 0.13 http://projects.haskell.org/gtk2hs/archives/2014/07/08/planned-013-release-to-add-text-support/ Here is the content of the blog post... I have prepared a 0.13 release that will add support for using Text (for functions that currently only work with String). It does this with a new GlibString type class that has instances for both String and Text. All the functions that currently use String have been changed to use this type class instead. This allows you to switch your code easily from String to Text or use a mix of the two if you wish (but not in the same function call as it would make for more type inference issues). This is a breaking change (hence the bump to 0.13). If you have issues with existing code then it will most likely be ambiguous type errors. The solution will probably be one of: * Stick with 0.12 for now - set an upper bound in the cabal file (existing code should really have a <0.13 upper bound for Gtk2Hs packages already). * Add type signatures - to help GHC infer the type of strings you are using. Leksah required the addition of around 20 type signatures. I think the most common issue will probably be when Nothing is passed to a function, because GHC cannot infer the type of thisNothing. One solution is to change it to (Nothing :: Maybe String). The 0.13 code is currently in the master branches of the various https://github.com/gtk2hs repositories. Please try it out and let us know if there is anything we need to address before releasing it to Hackage. We can still fix stuff after that, but it would be nice to know if there is anything major that we should address now. Hamish |